cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3832
Views
10
Helpful
20
Replies

EIGRP - adding backup routing

jvanii
Level 1
Level 1

I am distributing static routes into eigrp.at two sites.  Specifically, we are using NSX and SRM so that certain VMs have the same IP address at each site, Main and Backup.  At Main, I have two sets of IP addresses with a default route to each subnet.

ip route 10.0.10.0/24 10.20.29.5

ip route 10.0.11.0/24 10.20.29.5

 

At Backup we have the same subnets, but want to inject route or influence routing via eigrp so that when Main site goes dark/down the following routes would take over automatically.

ip route 10.0.10.0/24 10.20.39.5

ip route 10.0.11.0/24 10.20.39.5

 

 

 

20 Replies 20

jvanii
Level 1
Level 1

A continuation on this configuration.  The weighted configuration worked just fine.  But when the primary site came back up the original routes did not take precedence; the injected routes remained in the routing table. Usually the eigrp routing reconverges fairly quickly.  But i had to login to the backup site router and remove the routes from the config.

Or should i have added those weighted routes to both primary and backup router?  But isn't that would eigrp is for, so that the static route from one router can be injected into the routing table and propagated through the network.

I believe that in his suggestion Chris might have assumed that the static routes at the remote site would not be redistributed. If that is not right then I welcome Chris back into the discussion to clarify what he was suggesting. The behavior described in your update suggests that the remote static routes were redistributed. If the remote static routes are not redistributed then assigning a higher administrative distance to the static route is effective on the router where it is configured. But if the routes are redistributed then that higher administrative distance is not carried over. If the static routes are being redistributed and if you want to treat some of them differently than other then I believe that we are back to needing to use route maps to control the redistribution.

 

HTH

 

Rick

HTH

Rick

Looks like the redistribution of the weighted statics appear as valid routes when things get normalized so restoration then becomes a manual process. An unintended consequence and gotcha. Sounds like Rick's suggestion to use the route maps may be the way to go.

 

"Never say, 'oops'. Always say, 'Ah, interesting'."  Anonymous

To continue this discussion to its conclusion, I would add the route map configuration to the backup router only just as I did the higher weighted routes, or to both main and backup router.  This would be the configuration.

route-map STATIC_TO_EIGRP permit 10
 match ip address 101
 match ip next-hop 10
 set metric 100000 100 255 1 1500
exit

route-map STATIC_TO_EIGRP permit 20
 set metric 100000 1 255 1 1500
exit
!
access-list 101 permit ip 10.0.10.0 0.0.0.255 any
access-list 101 permit ip 10.0.11.0 0.0.0.255 any
!
access-list 10 permit host 10.20.39.5
!
router eigrp 128
 redistribute static route-map STATIC_TO_EIGRP

 

So when main site goes down, then the routes (and the devices in those subnets) in the access-list 101 will be accessed via the next hop address in access-list 10 which has the higher eigrp weight value.  Is that correct?  Then when the main site comes back on-line the original next-hop address (10.20.29.5) would then take precedence as it is propagated from the main site and the devices in access-list 101 subnets would be accessed via the original route.

Do I have all of this correct?

 

Again thanks for your help.

Or would adding the higher weighted routes to the main site also have the same effect? Once the main site comes back on line eigrp would noticed that the 39.5 route has a higher weighting and the 29.5 route would again take precedence. Just wondering and trying to think it through.

I believe that you would use normal redistribution of static routes into EIGRP on the main site and use the route map to control redistribution only on the backup site.

 

In the route map I understand and agree with the match statement on the routes. I am not sure about the statement matching on the next hop

 match ip next-hop 10

My inclination would be to remove this line.

 

HTH

 

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: