Prefer Default route via EIGRP vice RIP

[config t]

Code Select Expand


Router#sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(666)/ID(10.10.4.11)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P x.x.50.96/27, 1 successors, FD is 28160
        via Connected, Vlan58
P 0.0.0.0/0, 0 successors, FD is Infinity
        via x.x.50.254 (26908416/54016), Tunnel50
P x.x.50.0/24, 1 successors, FD is 26880000
        via Connected, Tunnel50
P x.x.48.96/27, 1 successors, FD is 28160
        via Connected, Vlan59
P x.x.4.11/32, 1 successors, FD is 128256
        via Connected, Loopback1

Router#sh ip route
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 x.x.4.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/2] via x.x.4.1, 00:00:26, FastEthernet0/0
      10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks


What are some of the methods I can use to get this spoke router to prefer a default route learned via EIGRP instead of RIP?

We use RIP through SATCOM and modems to establish initial connectivity (because the modems can only pass RIP) and then after the router learns a default route to reach the tunnel hub source, the tunnel will come up, EIGRP will come up and the router learns a better default route that way and starts using it.

For some reason this kit just won't do it. The router thinks RIP is the best default route.

[config t]

Update - it seems a "default-information originate" type function is being injected into RIP. We are thinking this is coming from the underlying iDirect modem mesh network because it's definitely not coming from our backside infrastructure.

This would explain the 120 metric coming from the RIP default route which is pre-empting the 170 EIGRP external route.

Learning is occurring. Troubleshooting continues.

[icecream-guy]

yeah its all about administrative distance, you will need to lower the AD of EIGRP below RIP for it to take precedence.

[config t]

The wonky part is that the IOS behavior has not been predictable when we either lowered the EIGRP AD or raised the RIP AD.

It turns out when our iDirect infrastructure was set up it was never integrated into the network and validated (which explains why I had to do so much config cleanup), so the SATCOM guys are currently going through tech manuals and understanding that these things are more than just a point and click GUI.

The iDirect actually dos a lot. Routing, switching, QoS, Accelerated GRE, Packet Compression.. in addition to being a mesh modem network.. and injecting default routes into my RIP process 

The easy way out is to configure static routes on my spoke routers so the data and voice networks know how to get out through the tunnel, but I don't want to band-aid it, I want to fix it.

Never a dull moment around here.

[icecream-guy]

The wonky part is that the IOS behavior has not been predictable when we either lowered the EIGRP AD or raised the RIP AD.

It turns out when our iDirect infrastructure was set up it was never integrated into the network and validated (which explains why I had to do so much config cleanup), so the SATCOM guys are currently going through tech manuals and understanding that these things are more than just a point and click GUI.

The iDirect actually dos a lot. Routing, switching, QoS, Accelerated GRE, Packet Compression.. in addition to being a mesh modem network.. and injecting default routes into my RIP process 

The easy way out is to configure static routes on my spoke routers so the data and voice networks know how to get out through the tunnel, but I don't want to band-aid it, I want to fix it.

Never a dull moment around here.

nothing wrong with static routes, just document and identify purpose of them.

[deanwebb]

^ Document and identify so that when you move on and somebody screws up and they look at you, you can say, "HEY! I *documented* that! Due diligence, chump!"

[config t]

Actually I ended up doing just that. After a day of t-shoot they still hadn't figured out how to stop that default route being advertised into RIP. It may turn out to be something you can't turn off on that system.

I wanted to do a prefix and distribute list to filter it inbound on the process but I was told to keep it simple. Static route it is.

[Otanx]

If you really want to filter it I am pretty sure the L3 STIG says you have to filter inbound routes. Nobody argues with the STIG! Also if using statics don't forget about the "name" option to give a quick description...
ip route 0.0.0.0 0.0.0.0 10.10.10.10 name Override_iDirect_Route
Makes it much easier to remember why a static exists when there is a name attached.

-Otanx

[config t]

If you really want to filter it I am pretty sure the L3 STIG says you have to filter inbound routes. Nobody argues with the STIG! Also if using statics don't forget about the "name" option to give a quick description...
ip route 0.0.0.0 0.0.0.0 10.10.10.10 name Override_iDirect_Route
Makes it much easier to remember why a static exists when there is a name attached.

-Otanx

Yessir. I am a big fan of putting names on static routes and descriptions on prefix-lists! It drives nuts when I have to try and figure out what a static route is for or what a distribute-list is doing.