EIGRP flapping and unable to force default route on EIGRP

[bcp618]

So, I've been spinning my wheels on this for way too long now.

I have a remote network that has a small office that's pretty far from their main network. All that's available is a very slow and unreliable T1 connection, and PtP radio connections. They have a 900 MHz radio that isn't very reliable but has higher throughput and speed than the T1, EIGRP by default chooses this route.

The switch at 10.3.0.1 is neighbors with 10.2.0.1 and 10.1.0.2. The adjacency has formed with 10.1.0.2 without issue, and has maintained connection reliably, it's the 900MHz network that is constantly flapping. This is the error I see at 10.2.0.1

*Mar  3 19:15:28.942: %DUAL-5-NBRCHANGE: EIGRP-IPv4 7070: Neighbor 10.3.0.1 (Vlan95) is up: new adjacencyint fa0/5              
*Mar  3 19:15:58.587: %DUAL-5-NBRCHANGE: EIGRP-IPv4 7070: Neighbor 10.3.0.1 (Vlan95) is down: holding time expired

This is what I see at 10.3.0.1

*Jun 14 11:46:31.322: %DUAL-5-NBRCHANGE: EIGRP-IPv4 7070: Neighbor 10.2.0.1 (Vlan95) is up: new adjacency nei fa0/8

*Jun 14 11:47:14.373: %DUAL-5-NBRCHANGE: EIGRP-IPv4 7070: Neighbor 10.2.0.1 (Vlan95) is down: holding time expired

I have an SVI running in between the two networks, I have verified that everything matches between the two networks, I've tried tweaking the delay for both the T1 (Forcing it to be lower to set it as a preferred route) and the SVI (Forcing it to be the secondary by increasing delay/lowering bandwidth).

Here's the ridiculous difference in metrics.

P 10.1.0.3, 1 successors, FD is 3328
        via 10.2.0.1 (3328/3072), Vlan95
        via 10.1.0.2 (258816/2816), FastEthernet0/4

I've subbed out all of our IP's with just 10.X.0.X

The 2nd octet is the site identifier.

I'll generate logs, provide configs or whatever, really just need help with this one. Also I think I double uploaded the netmap I made. It's a super rough draft, but it gets the point across as to how everything is flowing. There's a firewall connected to 10.1.0.2 but it's not participating in EIGRP it's strictly for a secondary outside connection and for internet traffic. The 10.1.0.1 rtr is connected via bgp to an ISP for our WAN connection.

[paul driver]

Hello

Try and increase the hello and hold timers for the flaky eigrp neighbor so it doesn't as frequently flap its adjacency

10.3.0.1

Int x/x
ip hello-interval eigrp xxx 120
ip hold-time eigrp xxx 360

As for specifying the best path you can manipulate any shared advertised routes from 10.2.0.1 to be least preferred for via a distance command on rtr 10.3.0.1

10.3.0.1

router eigrp xxx
distance 171 10.2.0.1 0.0.0.0

[bcp618]

These switches are not capable of changing their hello timer unfortunately, I wanted to try that as well but had not luck.

The metrics are so vastly different between the two that changing any kind of delay would require a massive delay that would not work with our current usage type.

Please let me know if you've got anything else for me to try. Thank you!

[Georg Pauwen]

Hello,

on a side note, and not knowing how your EIGRP is currently configured, you might want to try the 'neighbor' command between these two neighbors instead of the 'traditional' multicast default:

router eigrp xxxx

neighbor 10.2.0.1 interface

You need to configure this on both sides...

[bcp618]

Hello,

Thank you for the reply, a static neighbor would definitely fix the flapping issue, it wouldn't fix the primary route issue. I can't force it to switch to the T1 as primary since the metrics are so vastly different. Any forced delay or bandwidth change would kill the traffic that we'd having running over it.

[Georg Pauwen]

Hello,

you could configure an EEM script that shuts the SVI and only enables it when the T1 is down (or experiences heavy jitter). Can you post the full config of your router ?

[bcp618 · Accepted solution]

While I was not able to get it working with the suggestions, I was able to provide SOME redundancy via ipsla, this site will just have to be statically routed. The connections that are available to it are just unreliable.

For anyone wondering how to do this for a network kind of like mine.

I configured a loop back at 10.3.0.1 and 10.1.0.1 (the rtr)

Here's the configs at 10.1.0.2

track 10 ip sla 10 reachability

 delay down 40 up 180

ip route 10.3.0.0 255.255.255.0 X.X.X.X track 10 (My T1 distant end IP)

ip route 10.3.0.0 255.255.255.0 10.2.0.1 250

ip route 10.3.0.3 (loopback IP @ distant end) 255.255.255.255 (My T1 distant end IP)

ip sla 10

 icmp-echo 10.3.0.3 source-ip 10.1.0.1

 frequency 10

 history hours-of-statistics-kept 25

ip sla schedule 10 life forever start-time now

At 10.3.0.1

track 10 ip sla 10 reachability

 delay down 40 up 180

ip route 10.3.0.0 255.255.255.0 X.X.X.X (Distant end T1) track 112

Ip route 10.3.0.0 255.255.255.0 10.2.0.1 250

ip route 10.1.0.3 (Loopback IP) 255.255.255.255 X.X.X.X (Distant end T1)

ip sla 10

 icmp-echo 10.1.0.3 source-ip 10.3.0.1

 frequency 10

 history hours-of-statistics-kept 25

ip sla schedule 10 life forever start-time now

At 10.2.0.1

ip route 10.3.0.0 255.255.255.0 X.X.X.X (IP of SVI at 10.3.0.1 location)

I hope this helps anyone that might have this weird network design in the future.