EIGRP and split-horizon

Not sure why you are concerned about split-horizon , perhaps you provide some further clarifications.

There are a couple of key things to look after in a dual hub topology:

1. You want to ensure that the stubs do not end up passing transit traffic between the two hubs because of inter-hub link failure. one way of accomplishing this is to only pass deafult to the spoke routers (using distribute-list out).

1. If you haven't already, you would want to enable the EIGRP stub feature on all of the spoke routers.

2. Control the amount of bandwidth that EIGRP consumes especially over low-speed links to remote hubs. See Cisco doc
   formatting link

I think you are confusing split-horizon with preventing a routing loop. Please see the following link on how EIGRP works.

In any event, I don't know why you should be concerned. I can only assume that what you are saying is that you have examined the topology tables and don't see feasible successors, and it doesn't matter. If you don't have access to CCO, get a copy of Routing "TCP/IP, Volume 1, 2nd Edition", by Cisco Press. It covers all of the IGP's (interior gateway protocols) and has a great chapter on EIGRP.

Scott

Here are my concerns: by design (much less bandwith) one of the two hubs is a backup only, so in normal conditions all the traffic must pass through the main hub, if the main hub is not advertising his routes due to split horizon for my knowlegde all the traffic will flow through the wrong hub, right? This is not happening, but I''d llike to be sure there is a technical reason for that and this is not just luck. Here is a little diagram of the net:

HUB1L3Switch(----Radio Link----)L3SwitchHUB2

Now split horizon is happening always on one of the two L3 switches, and always the same, never mind what happens.

Hubs are already configured as stub, this should also enhance stability.

This should be interesting, but the link is not reacheable from here now, I'll give it a try later. Tnx, Tosh.

Maybe, please read the answer I gave to Merv about my concerns. Tnx, Tosh.

As I said before, you are confusing split-horizon with preventing a routing loop. You stub sites will always receive routes from the hubs, so split-horizon would never be an issue at the stub. Your concern should be the hub sites not having routes to the stubs because that is where split-horizon would apply. Buy the Cisco Press book and all will be clear.

Scott

Hi Scott, surely I didn't made myself clear, my concern is not about remote peers, my concern is about local peers. Providing that the same routes from remote peers are coming to both hubs, is there any possibilities that the main hub stops advertising his routes

the nearest L3 switch when I issue a "show ip eigrp topology details"

Are you saying that hub1 does not have any of hub2's directly connected routes in its topology table ?

BTW what are the make & models of the two L3 switches and their IOS versions

Hub1 learns Hub2 directly connected routes through a Wan link (a direct one, not via a spoke), this is what the customer want, it's not seeing any route through the radio link. If I look at topology table of the two L3 switches and Hub2 I can see all the routes coming from both directions.

They are both cisco C3750 with ipservices 12.2(25)SEB4 image. Tnx, Max.

- not in routing table, not in topology database, or not in both ???

- are you filtering routes at any point between hub router 1 - L3 switch 1 - L3 switch 2 - hub router 2 ?

Topology confirmation:

1. there are two hub routers (make/model ???) and two L3 switches (3750)
2. two hub routers are connected by a WAN link (separate from spoke links)
3. each hub router connect to a L3 switch in each local site buidling
4. two L3 switches are connected via radio link

Can you post the output of "show ip proto" for the two hub routers and the two L3 switches

What kind of radio

Topology confirmed :-)

Mmmm, don't get angry but it's too much infos about the customer networks, if you tell me what you are lookin for I'll post some pieces. In the meantime I'm sure this will be of any purpose, this is an output of the "sh ip eigrp top" for a remote network issued on all the devices.

HUB2#sh ip eigrp top 192.168.8.0/24 IP-EIGRP (AS 10): Topology entry for 192.168.8.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2299392 Routing Descriptor Blocks: 172.17.5.1 (FastEthernet0/0), from 172.17.5.1, Send flag is 0x0 Composite metric is (2299392/2273792), Route is External Vector metric: Minimum bandwidth is 2048 Kbit Total delay is 41000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 172.17.5.1 AS number of route is 65522 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001) 172.16.5.11 (FastEthernet0/1), from 172.16.5.11, Send flag is 0x0 Composite metric is (5685760/5427200), Route is External Vector metric: Minimum bandwidth is 5000 Kbit Total delay is 202100 microseconds Reliability is 207/255 Load is 9/255 Minimum MTU is 1500 Hop count is 3 External data: Originating router is 172.17.3.1 AS number of route is 65535 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001)

Switch2#sh ip eigrp top 192.168.8.0/24 IP-EIGRP (AS 10): Topology entry for 192.168.8.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5427200 Routing Descriptor Blocks: 172.16.4.1 (Vlan4), from 172.16.4.1, Send flag is 0x0 Composite metric is (5427200/307200), Route is External Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 202000 microseconds Reliability is 255/255 Load is 9/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 172.17.3.1 AS number of route is 65535 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001) 172.16.5.4 (Vlan5), from 172.16.5.4, Send flag is 0x0 Composite metric is (7419392/2299392), Route is External Vector metric: Minimum bandwidth is 2048 Kbit Total delay is 241000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 172.17.5.1 AS number of route is 65522 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001)

Switch1#sh ip eigrp top 192.168.8.0/24 IP-EIGRP (AS 10): Topology entry for 192.168.8.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5427200 Routing Descriptor Blocks: 172.16.3.1 (Vlan3), from 172.16.3.1, Send flag is 0x0 Composite metric is (5427200/307200), Route is External Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 202000 microseconds Reliability is 255/255 Load is 9/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 172.17.3.1 AS number of route is 65535 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001) 172.16.4.2 (Vlan4), from 172.16.4.2, Send flag is 0x0 Composite metric is (7419392/2299392), Route is External Vector metric: Minimum bandwidth is 2048 Kbit Total delay is 241000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 172.17.5.1 AS number of route is 65522 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001)

Hub1#sh ip eigrp top 192.168.8.0/24 IP-EIGRP (AS 10): Topology entry for 192.168.8.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 307200 Routing Descriptor Blocks: 172.17.3.1 (FastEthernet0/1), from 172.17.3.1, Send flag is 0x0 Composite metric is (307200/281600), Route is External Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 2000 microseconds Reliability is 255/255 Load is 9/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 172.17.3.1 AS number of route is 65535 External protocol is BGP, external metric is 0 Administrator tag is 1 (0x00000001)

As you can see Hub1 is sending the route to switch1 but is not receiving it back, this for me is due to split horizon, again the question is..switch1 is following some kind of logic or is simply a russian roulette game? Tnx, Max

It's a link made by a couple of cisco 1300 bridges. Bye, Tosh.

These topology entries are external routes. Where is the redistribution being done and how.

Post the the EIGRP routing process for the router where it is being done if you can

The hop counts for the EIGRP topology entries that you posted make sense if the link between switch 1 and switch 2 is a bridged link (i.e. not routed interfaces on the switches) - please confirm.

Is there any route filtering done on hub1 or switch 1 (distribute-list in / out ) ???

Redistribution is done by service provider, since it's a mpls network, this is the same at the two hubs, that receive from the service provides, and advirtises into the local networks, the same eigrp announcements from peers. Sorry but no access to the service provider routers. Tnx, Tosh.

Looks like there is a routing issue on either hub1 or switch1 (not split-horizon)

hub1 should have a topo entry for 192.168.8.0/24 learned from switch1 and from 172.17.3.1 just as hub2 has two topo entries for

If the "link" (mpls network- PE routers) fails I suspect that hub1 will have NO routes to 192.168.8.0

Please send private email

I made some aestetichal changes to the output I posted, maybe I made some by mistake. But I don't want you to work so hard on it, all in all the topology is working as expected (for now), my question is more generic.....in a topology like this, is there something that drives one router instead of another to "split the horizon" or is simply a matter of luck? Do I have to disable split horizon in order to be sure that Hub1 will never stop advertising his routes to the local lan?

Yes, I'm allowing only the local and remote networks advertisements and filtering all the point-to-point andvertisements from service provider, this on both hubs at the internal interface level. For instance, switch1 and switch2 doesn't get announcement for the originating peers from service provider in the output I posted before (172.17.3.1 and 172.17.5.1), those are among the other routes filtered at the hub level, coult it be a problem? Tnx, Tosh.