EIGRP - adding backup routing

[jvanii]

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

[Rejohn Cuares]

Evaluate which one suits your circumstances from the following options.

1.Embedded Event Manager (EEM)

- Use EEM to track the routing table. If the route is not present and learned via EIGRP. EEM installs the static route and redistribute via EIGRP.

2. Static route tracking using IP SLA

- Configure the static routes with IP SLA. The use of IP SLA is to monitor the reachability of a particular host(s). If the host is not reachable, the static route would not be installed in the routing table and thus would not be redistributed to EIGRP.

3. Advertise both subnets from main and backup sites but make sure the backup site has higher EIGRP metric set.

HTH.

[jvanii]

I think it would be best to use number 3; setting a higher metric for the backup site routes, but I am not sure what metric to change.  Is not the default metric for eigrp  10000 1 255 1 1500?

So what would I need to change to make this happen?

This is what I have in my config currently

router eigrp 128
 distribute-list static_to_eigrp out static
 network 10.0.0.0
 redistribute static metric 10000 1 255 1 1500
 passive-interface default
 no passive-interface Vlan364
 no passive-interface Vlan368
 eigrp stub connected static summary

Thanks,

[Richard Burts]

It would be best to increase the value of the delay metric from the default to a higher value.

HTH

Rick

[jvanii]

Please can you be more specific what higher value might be and how I would add it into the config?

Thanks,

[Richard Burts]

In EIGRP redistribute default metric the second value represents the delay. You currently have this

redistribute static metric 10000 1 255 1 1500

I would suggest that you change it to this

redistribute static metric 10000 100 255 1 1500

HTH

Rick

[jvanii]

But only want to apply the higher metric to these routes, not my whole eigrp redistribution.
ip route 10.0.10.0/24 10.20.39.5
ip route 10.0.11.0/24 10.20.39.5

[Richard Burts]

If you want to change the metric on some but not all redistributed static routes then you need to use a route map to control your redistribution. In one instance of the route map you would match these routes and redistribute with the higher value of delay and in another instance of the route map you would match the remaining routes and redistribute them with the lower value of delay.

HTH

Rick

[jvanii]

Please, could you provide an example. I have yet to use route maps

[Meheretab Mengistu]

Hi,

Here is an example to use to redistribute using route-map:

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 1

 redistribute static route-map STATIC_TO_EIGRP 

!

HTH,

Meheretab

[chrihussey · Accepted solution]

I think the simplest way to accomplish this would be to just administratively weigh the statics at the backup site to something higher than the redistributed statics (170) at the primary site. So then:

ip route 10.0.10.0/24 10.20.39.5 200

ip route 10.0.11.0/24 10.20.39.5 200

As long as the primary routes are active and in the routing table, these routes shouldn't propagate. Once the primary site is offline, the secondary routes would then be advertised.

[Richard Burts]

The common way to manipulate redistributed routes is to use route maps. The solution suggested by Chris is very creative (wish I had thought of it) So +5 for it. It achieves the desired result without the complexity of using route maps.

HTH

Rick

[chrihussey]

Thank you Richard. I appreciate that.

[jvanii]

Thank you for your extremely helpful solution and dialogue which give me a better understanding of my network. I went with Chris's solution.

[Richard Burts]

I am glad that our discussion has been helpful and that you have a better understanding of your network as a result of it. The solution from Chris is simple and effective. This reminds us that frequently there may be more than one way to solve a problem. One of the excellent things about these forums is that we have multiple people looking at the issues and potentially suggesting alternative solutions.

HTH

Rick