Solved: EIGRP Fail over

ciscoben2009 · ‎10-05-2011

Hi All

We currently have a site to site link between two of our offices and a backup VPN via the internet

the primary site to site link is connect to a primary router on each site and the VPN back is connected to a backup router on each site

If the primary link fails there is delay on the traffic moving over the backup link i think this is due to the hold timer waiting for the eigrp adjancey to fail

Is there anyone to speed this up i have read eigrp should do sub second fail over i know i am doing something wrong

Any help would be great

Thanks

Ben

Jon Marshall · ‎10-07-2011

Ben

I think you are going to have to do some debugging of eigrp to work out what is going on. You need to see the updates going between the backup and primary routers. Obviously this will have an impact on the router so do it during a quiet time if possible.

if your networks are summarisable from each site then there are alternatives ie.

1) don't send EIGRP updates down the VPN tunnel but instead use a floating static on each primary router pointing to it's relevant VPN backup router which will only kick in if the routes down the main link get lost

or

2) advertise a summary route down the VPN link only which should not conflict with any of the more specific routes and so hopefully should be installed in the routing table of the primary routers. But with the problem you are seeing this may or may not work.

But it would be good to try and work out why these routes are not installing.

Jon

View solution in original post

Marwan ALshawi · ‎10-06-2011

On the interface change the hold time and dead timers to few seconds this recommended to be same on both ends

Hope this help

Sent from Cisco Technical Support iPhone App

Richard Burts · ‎10-06-2011

Ben

It may help to think of failover as having 2 major components. First the router and routing protocol must detect that there is a problem (first major component) and then the routing protocol must converge (second major component). The convergence of EIGRP is very quick (and especially quick if there is a feasible successor for the lost route). It is likely that the delay that you experience is related to detecting the problem. And in that case the advice to reduce the hello timer and the hold time should be effective in speeding up the failover.

HTH

Rick

HTH

Rick

Jon Marshall · ‎10-06-2011

Ben

Just to add to the others.

It may be the hold timer but it may also be the EIGRP does not see the VPN tunnel as feasible successor. In which case it would need to issue an active query to find an alternate route via the VPN tunnel. How are you actually switching routes when the main link goes down.

It may be easier depending on your topology to simply configure a floating static route within your site that points to the VPN tunnel. As long as it has a higher AD than EIGRP (90) or EIGRP external (170) if you are redistributing EIGRP into that site then it would only be used when the main EIGRP route is lost.

Jon

ciscoben2009 · ‎10-06-2011

Hello Rick and Jon

thank you for your reply

after looking over it i think the problem is with london

the fail over is done using HSRP if the main link goes down the default gateway goes over to the back up router which using an offset list already has the VPN as it primary route to london i think the problem is london as the return traffic is trying to go via the main link

i have taken the hello/hold timer down to 1 second but it still takes a few second to see the failure and drops around 3 pings is this the fastest i would be able to get it?

many thanks

Ben

Jon Marshall · ‎10-06-2011

Ben

If the failover is done with HSRP does this mean you are using HSRP tracking on the primary router ?

If so then i'm not sure how EIGRP comes into this. Surely it is a case of how quickly HSRP fails over so it is these timers you should be looking at.

Perhaps i am not understanding your setup correctly.

Jon

ciscoben2009 · ‎10-06-2011

Hi Jon

the HSRP fails over within a second and the client move over to the backup router which sends traffic to our london office but when my PC sends the returns traffic it hits londons primary routes which trys to send traffic along the main line which is down instead of sending it via the back up router in london alogn the VPN to the back up rotuer in sheffield

When the end of the line in sheff is unplug the london end still shows up/up which i dont think it helping

thanks for the reply maybe i just expecting to much?

cheers

Ben

Jon Marshall · ‎10-06-2011

Ben

Okay, i understand now.

So once London realises the adjacency has gone down does it automatically install a route via the VPN tunnel ie. does it have the VPN path as a feasible successor in it's routing table ?

Jon

Kishore Chennupati · ‎10-06-2011

ben,

Try clearing the eigrp neighbor relationship between your primary and secondary routers in london.

when you do a " sh ip eigrp neighbor" check the time to ensure that the neighbor relationship has established and make sure the ip addresses are correct etc.

Then do a "sh ip eigrp topology ". See where it is learning that from. Is it learning that from Primary router or the VPN Tunnel. Also make sure to check the redistribution of static routes, default routes etc into the eigrp protocol on the back up router at London site.

When the site-to-site private link goes down and your HSRP fails over to the back up router at sheff then the primary router at london should loose all the routes and should start learning them from the backup router at london.

do a "sh ip route" on the primary router at london and check where its learning the sheff subnets from as well

HTH

Please rate if helpful

ciscoben2009 · ‎10-07-2011

that is what happing i am going to do a test today to be sure

i think the delay is coming from the time the primary router is taking to drop the adjacency with the primary router in sheff and use the back routers VPN path

is there anyway to tell the primary router that the site to site link is down and to drop its own route and use the ones from the back up router?

thanks

Ben

ciscoben2009 · ‎10-07-2011

Having done a test and looked at the config the primary routers of each end don't have a back up route via the VPN tunnel so it is sending query messages out

It is not even showing in the show ip eigrp top all links

I think they should appear in the topology table but even if they not a Feasible successor they should show in the all links shouldn't they?

thanks

Ben

Jon Marshall · ‎10-07-2011

Ben

If the VPN tunnel is a backup then does it only come up when the primary goes down. This is why i was asking about how the routing is done in terms of the VPN backup link. Because it may be that your delay is while the VPN tunnel is bought up and then the queries are sent.

So under normal operation when the main link is up what is the state of the VPN tunnel ie. is it up or not ?

Further question - is this a normal VPN IPSEC tunnel or is it using GRE because without GRE you won't be exchanging multicast EIGRP routing updates ?

It may be that a floating static solution could alleviate the problem but we need to know more about how the routing actually works.

Jon

ciscoben2009 · ‎10-07-2011

sorry i wasn't very clear the VPN tunnel is always up

looking at the eigrp topology table the primary router is not taking any routes from the back up router

It is just taking its own routes and dropping the rest

Below is a show ip eigrp topogly

BACK UP ROUTER

P 192.168.100.0/24, 1 successors, FD is 26887680
        via 192.168.60.249 (26887680/26885120), FastEthernet0/1
        via 192.168.224.1 (26936320/26885120), Tunnel1
P 192.168.101.0/24, 1 successors, FD is 26887680
        via 192.168.60.249 (26887680/26885120), FastEthernet0/1
        via 192.168.224.1 (26936320/26885120), Tunnel1
P 192.168.75.0/24, 1 successors, FD is 26887680
        via 192.168.60.249 (26887680/26885120), FastEthernet0/1
        via 192.168.224.1 (26936320/26885120), Tunnel1
P 192.168.65.0/24, 0 successors, FD is Inaccessible
        via 192.168.60.249 (30720/28160), FastEthernet0/1
P 192.168.70.0/24, 1 successors, FD is 26887680

       via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.93.0/24, 1 successors, FD is 297249792
        via 192.168.60.249 (297249792/297247232), FastEthernet0/1
        via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.94.0/24, 1 successors, FD is 297249792
        via 192.168.60.249 (297249792/297247232), FastEthernet0/1
        via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.95.0/24, 1 successors, FD is 297249792
        via 192.168.60.249 (297249792/297247232), FastEthernet0/1
        via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.80.0/24, 1 successors, FD is 30720
        via 192.168.60.249 (30720/28160), FastEthernet0/1
P 192.168.81.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.83.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.84.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.85.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 192.168.86.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.87.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.60.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 192.168.0.0/24, 1 successors, FD is 30976
        via 192.168.60.249 (30976/28416), FastEthernet0/1
        via 192.168.224.1 (310760/29160), Tunnel1
P 192.168.4.0/24, 1 successors, FD is 31232
        via 192.168.60.249 (31232/28672), FastEthernet0/1
        via 192.168.224.1 (310016/28416), Tunnel1
P 192.168.5.0/24, 1 successors, FD is 31232
        via 192.168.60.249 (31232/28672), FastEthernet0/1
        via 192.168.224.1 (310016/28416), Tunnel1
P 192.168.6.0/24, 1 successors, FD is 31232
        via 192.168.60.249 (31232/28672), FastEthernet0/1
        via 192.168.224.1 (310016/28416), Tunnel1
P 192.168.20.0/24, 1 successors, FD is 26887680
        via 192.168.60.249 (26887680/26885120), FastEthernet0/1
        via 192.168.224.1 (26936320/26885120), Tunnel1
P 192.168.224.0/24, 1 successors, FD is 307200

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

        via Connected, Tunnel1
P 192.168.230.0/24, 1 successors, FD is 297249792
        via 192.168.60.249 (297249792/297247232), FastEthernet0/1
        via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.231.0/24, 1 successors, FD is 297249792
        via 192.168.60.249 (297249792/297247232), FastEthernet0/1
        via 192.168.224.1 (297295616/297244416), Tunnel1
P 192.168.255.0/24, 1 successors, FD is 30976
        via 192.168.60.249 (30976/28416), FastEthernet0/1
        via 192.168.224.1 (310760/29160), Tunnel1
P 192.168.220.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.210.0/24, 1 successors, FD is 26885120
        via 192.168.60.249 (26885120/26882560), FastEthernet0/1
        via 192.168.224.1 (26933760/26882560), Tunnel1
P 192.168.211.0/24, 1 successors, FD is 298529536
        via 192.168.60.249 (298529536/298526976), FastEthernet0/1
        via 192.168.224.1 (298578176/298526976), Tunnel1
P 192.168.212.0/24, 1 successors, FD is 298529536
        via 192.168.60.249 (298529536/298526976), FastEthernet0/1
        via 192.168.224.1 (298578176/298526976), Tunnel1
P 192.168.213.0/24, 1 successors, FD is 298529536
        via 192.168.60.249 (298529536/298526976), FastEthernet0/1

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

        via 192.168.224.1 (298578176/298526976), Tunnel1
P 192.168.214.0/24, 1 successors, FD is 298529536
        via 192.168.60.249 (298529536/298526976), FastEthernet0/1
        via 192.168.224.1 (298578176/298526976), Tunnel1

PRIMARY ROUTER

P 192.168.100.0/24, 1 successors, FD is 26885120
        via 192.168.80.1 (26885120/26882560), FastEthernet0/1
P 192.168.101.0/24, 1 successors, FD is 26885120
        via 192.168.80.1 (26885120/26882560), FastEthernet0/1
P 192.168.75.0/24, 1 successors, FD is 26885120
        via 192.168.80.1 (26885120/26882560), FastEthernet0/1
P 192.168.65.0/24, 1 successors, FD is 28160
        via Rstatic (28160/0)
P 192.168.70.0/24, 1 successors, FD is 26885120
        via 192.168.80.1 (26885120/26882560), FastEthernet0/1
P 192.168.89.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.91.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.93.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.94.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.95.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.80.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 192.168.81.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.83.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.84.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.85.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.86.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.87.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.60.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 192.168.0.0/24, 1 successors, FD is 28416
        via 192.168.80.1 (28416/2816), FastEthernet0/1
P 192.168.4.0/24, 1 successors, FD is 28672
        via 192.168.80.1 (28672/3072), FastEthernet0/1
P 192.168.5.0/24, 1 successors, FD is 28672
        via 192.168.80.1 (28672/3072), FastEthernet0/1
P 192.168.6.0/24, 1 successors, FD is 28672
        via 192.168.80.1 (28672/3072), FastEthernet0/1
P 192.168.20.0/24, 1 successors, FD is 26885120
        via 192.168.80.1 (26885120/26882560), FastEthernet0/1

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 192.168.224.0/24, 1 successors, FD is 309760
        via 192.168.60.250 (309760/307200), FastEthernet0/0
        via 192.168.80.1 (310016/307456), FastEthernet0/1
P 192.168.230.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.231.0/24, 1 successors, FD is 297247232
        via 192.168.80.1 (297247232/297244672), FastEthernet0/1
P 192.168.255.0/24, 1 successors, FD is 28416
        via 192.168.80.1 (28416/2816), FastEthernet0/1
P 192.168.220.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.210.0/24, 1 successors, FD is 26882560
        via 192.168.80.1 (26882560/26880000), FastEthernet0/1
P 192.168.211.0/24, 1 successors, FD is 298526976
        via 192.168.80.1 (298526976/298524416), FastEthernet0/1
P 192.168.212.0/24, 1 successors, FD is 298526976
        via 192.168.80.1 (298526976/298524416), FastEthernet0/1
P 192.168.213.0/24, 1 successors, FD is 298526976
        via 192.168.80.1 (298526976/298524416), FastEthernet0/1
P 192.168.214.0/24, 1 successors, FD is 298526976
        via 192.168.80.1 (298526976/298524416), FastEthernet0/1

Shouldn't it keep the back up routes in its topology table?

The fail over is fine at sheff for example if the main link goes down it seem to be at london it has no back up route in its topology table and sends out quereys to get the back up route which i think it causing the delay

Jon Marshall · ‎10-07-2011

Ben

The fail over is fine at sheff for example if the main link goes down it seem to be at london it has no back up route in its topology table and sends out quereys to get the back up route which i think it causing the delay

Yes that will be the problem. You should see the routes in the "sh ip eigrp topology all-links" output from the London router. If you are not you need to work out why they are not being installed (or received) from the VPN tunnel.

How is the London setup done in terms of where the primary router is and the VPN backup router ie. how is everything connected.

Jon

ciscoben2009 · ‎10-07-2011

the primary router is connected to a ethernet line to sheffield and plugs in to our main switch

the back up router is connected to the internet with a GRE tunnel connecting the back up router in sheffield

both routers in london are on the same subnet and pluged in to the same switch and they are eigrp neighbors

Hope that helps

thanks

Ben