Redistribute Routes between EIGRP and change route metrics

[Mathias Peter IT]

Hello,

I have a DMVPN scenario using EIGRP as routing protocol with

• two hubs (for device redundancy) in a DC,
• two routers as spoke (for connection and device redundancy) in an external location.

One of the spoke routers is connected to the Internet via DSL, the other via LTE. Both routers share a common network segment ("LAN"), which is in turn connected to an ASA (to firewall the traffic passing) before connecting to the "real" LAN. The EIGRP instance ID for the hub (reachable via DMVPN tunnels) is 178, and for the LAN side (to the ASA), it's 59.

The routing in the DC "terminates" on a L3 switch. The EIGRP instance ID is 178, consistent with the hubs.

Both EIGRP instances have a default-metric configured. Not sure if this is relevant for this case.

router eigrp 59
 redistribute eigrp 178 route-map ROUTES_IN
 network 172.31.59.8 0.0.0.7
!
router eigrp 178
 redistribute eigrp 59 route-map LOCAL_LAN
 network 172.16.178.0 0.0.0.255
!
route-map ROUTES_IN permit 10 
 match ip address ROUTES_IN
 set metric +16
!         
route-map LOCAL_LAN permit 10 
 match ip address LOCAL_LAN
 set metric +16
!
ip access-list standard LOCAL_LAN
 10 permit 192.168.59.0 0.0.0.255
!
ip access-list standard ROUTES_IN
 10 permit 10.178.0.0 0.0.255.255

As to be seen above, I'm using a route map with prefix list and the redistribute command in the router eigrp subcontext of the spokes to redistribute only select routes back and forth. This works as expected. On said ASA, I can see two entries for the routes in the DC. On said switch in the DC I can see two entries for the routes. Equal Cost Multipathing. Also what I'd expect, there are two paths appearing equal to the routing protocol.

Note: We're not> talking default-routes here. That's a local outbreak and not routed via DMVPN.

firewall# show route 10.178.20.0 255.255.255.0 longer-prefixes 

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is 87.193.61.137 to network 0.0.0.0

D EX     10.178.20.0 255.255.255.0 
           [170/26882816] via 172.31.59.11, 00:50:47, mapevpn-trans
           [170/26882816] via 172.31.59.9, 00:50:47, mapevpn-trans

switch#show ip route 192.168.59.0 255.255.255.0 longer-prefixes 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.178.20.253 to network 0.0.0.0

      192.168.59.0/24 is variably subnetted, 4 subnets, 4 masks
D EX     192.168.59.0/25 [170/26883072] via 10.178.20.249, 23:25:19, Vlan20
                         [170/26883072] via 10.178.20.248, 23:25:19, Vlan20
[…]

My goal is to prefer traffic flowing over the DSL attached router and using the LTE one as backup, should the DSL line fail. This preferring should be handled for both traffic directions.

So I added a "set metric +16" to both in and out route maps and (no) shut'ed the tunnel interface.

route-map ROUTES_IN permit 10 
 match ip address ROUTES_IN
 set metric +16
!         
route-map LOCAL_LAN permit 10 
 match ip address LOCAL_LAN
 set metric +16
!

There was no change. I still see two entries in the routing table with the same two metric values separated by a forward slash, as shown above.

What am I doing/understanding wrong?

[Octavian Szolga]

Hi,

For EIGRP you cannot use set metric and value.

You have to use set metric and bw, delay, reliability, load etc.

https://www.oreilly.com/library/view/cisco-ios-in/0596008694/re751.html

Also, 99% of people would just use delay on tunnel interface at both ends to influence routing.

BR,

Octavian

[Mathias Peter IT]

Thank you. Your mentioning of the individual EIGRP metric values and the link you posted helped to get me started

As MGM Cisco World points out below, you can't use the EIGRP metric values in route maps, though. While his mentioning lacks your initial aid to get me started, he provided the eventual solution.

I dimly remember from earlier tries that EIGRP route selection by setting the interface delay is only affected when that delay is set on the origin interface for that route (aka connected route being replicated into EIGRP via network statement). Adjustment of nonadjacent interface delay wasn't influencing EIGRP routing. Take this with a grain of salt.

Also, changing the delay on the DMVPN hub's tunnel interfaces (to influence route distribution to the spoke) would not help my case. The goal is to move traffic away from LTE, and the Hubs can't influence routes for tunnel peer interfaces in the GRE "cloud".

[Octavian Szolga]

Hi,

In the end, all that matters is that your issue is solved

I don't know the specifics of your DMPVN network, but my assumption was that you're using separate hub interfaces per transport (LTE vs DSL - DMVPN domain 1 vs domain 2).

In this case, if you change the delay for hub tunnel-LTE and spoke tunnel-LTE interface to just +1 the default delay you'll get this path to be less preferred without having to manipulate any route redistribution.

Modifying delay on a nonadjacent interface does change the route metric. It's only a matter of perspective - where does the route starts and on which router in the traffic path I want it modified.

Remember that EIGRP path selection takes into account the sum of all delays up until the receiving router (at least only one end of each network segment on which the route is being propagated; not exactly 100% semantically corect but it's late in the evening

It's useless to change the delay directly on the interface whose network is advertised into EIGRP using the network command, if you want to manipulate that specific prefix metric into EIGRP.

BR,

Octavian

[Mathias Peter IT]

Thanks for your clarifying input.

There is one common GRE cloud "containing" both hubs' and every spoke's tunnel interfaces. Does that answer your question?

I took that decision for simplicity of design and to conserve IP space. While there is hardly a shortage for RFC1918 networks in a given internetwork, the chance of overlapping address ranges increases with more networks being deployed. E. G. when there is a company merger, or business needs warrant a separate Site2Site-VPN.

In other DMVPNs I've set up, there is no clear distinction regarding transport (provider) preference. Preference can emerge dynamically when providers experience service degradation (increased packet loss). To counter this, I've planned to look into IP SLA for dynamically influence routing decisions. But since equal cost pathing traffic is (AFAIK) directed by flow and not by packet (as far as I've understood), there is currently little need to invest considerable amounts of time into a proven template configuration. One can even argue, it's beneficial for utilizing every (paid for!) link.

You are right, modifying interface delays on transit interfaces indeed influences routing decisions. After waiting for a minute, there was still no change visible in the EIGRP topology tables. I needed to clear neighbors to make the change show up. This is certainly not how I would have expect things to work. If a metric-influencing link property changes, I'd expect that to find it's way into the topology table without further intervention. This might be a show stopper for my IP SLA plans.

Changing the delay on the originating, connected interface for a route works for me for many years now. That's how I suppress equal cost routes showing up on spokes for a connected network (with accompanying network statement in router eigrp) at the hub; in the given dual-hub redundancy setup, sharing a single GRE "cloud", as described.

[Octavian Szolga]

Hi Mathias, 

Sorry, now I saw the line where you stated that each location has two spokes

It makes sense to change delay on the directly connected interface on one of the spokes in order to preffer one spoke over another.

As a side note, regarding your issues, it would make sense to migrate to SD-WAN if your hardware supports it.

BR,

Octavian

[Mathias Peter IT]

Not only two spokes in (some) locations, but mainly two hubs. In terms of directly connected interfaces. You stated, that's useless and I found a case where it's not.

I don't see the need to invest the time and effort to deal with SD-WAN. Until now, this seems to me just another buzzword.

No comment on my observation that changing an interface delay doesn't propagate immediately?

[Octavian Szolga]

Well, nothing to comment on It may be a bug or you didn't had patience.

I quickly tested between 2 devices in my network and it was ok.

It was immediately changed in eigrp topology (locally) and the change was reflected on the neighbour device.

Regarding SD-WAN, at first I thought the same. If you start study it, you'll see that end to end segmentation and sla based routing make a big difference compared to a classical solution.

BR,

Octavian

[MHM Cisco World · Accepted solution]

 redistribute eigrp 59 route-map LOCAL_LAN metric x x x x x

 redistribute eigrp 178 route-map ROUTES_IN metric x x x x x

you can use route-map to select the prefix you want to redistribute and use metric keyword for modify metric  

the set metric under route-map not work for EIGRP