EIGRP and split-horizon

I've got a couple of hub routers and some 40 spokes, each spoke is a stub
connected to both hubs.
Hub routers are located in separate buildings and connected to each other
via a radio link with a L3 switch at each side, that is, hubs are on
different L3 subnets.
Eigrp is driving the game with split horizon enabled globally on each
router and all is working fine.
My concern is about split horizon, I don't kow why but the device that is
"splitting the horizon" for all the routes is the same L3 switch all the
time, now, this is an optimal solution for me, but I'm afraid that it's all
about casualty and one day I'll see this behaviour migrate to one of the hub
routers, with catastrophic effects.
Is there a logic in that?
Do I have to disable split horizon to be sure this will not happen?
Do you think OSPF will be a better choice for a network like that?
Tnx,
Tosh.

 

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).

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

3. Control the amount of bandwidth that EIGRP consumes especially over
low-speed links to remote hubs. See Cisco doc
http://www.ciscotaccc.com/iprout/showcase?case=K98481773

 

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

http://www.cisco.com/en/US/customer/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

You need a CCO login to access this document.

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

 

Not sure why you are concerned about split-horizon , perhaps you

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:

HUB1<---->L3Switch(----Radio Link----)L3Switch<----->HUB2

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.

 

I think you are confusing split-horizon with preventing a routing loop.

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

 

As I said before, you are confusing split-horizon with preventing a

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
*locally* due to split horizon?
In this case, since there are other peers at the main site that learn routes
from eigrp, doesn't all traffic from local resources to the remote peers
flow though the secondary hub instead of the main hub?
This is the kind of thing I'm afraid of and, as long as it has any chance to
happen, should be avoided at any cost.
What I'm seeing now is the main hub that doesn't show any route coming from
the nearest L3 switch when I issue a "show ip eigrp topology details"
command, this seems to me that the L3 switch is breaking the routes due to
split horizon.
This is good for me, but I just want to be sure that it cannot happen to the
main hub instead of the L3 switch.
Tnx a lot,
Tosh.

 

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

 

Are you saying that hub1 does not have any of hub2's directly connected

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.

 

Hub1 learns Hub2 directly connected routes through a Wan link (a direct one,

- 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
3. 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 confirmation:

Topology confirmed

 

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

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

 

What kind of radio
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 ) ???

 

These topology entries are external routes. Where is the redistribution

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
192.168.8.0/24

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

 

The hop counts for the EIGRP topology entries that you posted make

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.