EIGRP Tunnel Hold Time Expires Top of the Hour

[Verbatim]

Spoke logs attached; hub seems to show corresponding “peer termination received” entries. Hold time seems to be expiring at the top of the hour in most cases shown (exceptions: Dec 2nd, 4th, 16th, and 17th). Unlikely enabling debugs on the hub will be acceptable, log load would be too high (unless there’s a way to only debug for this particular spoke).

Will show excerpts of the config for hub and spoke below. Note that there are 2 tunnels on the spoke; not experiencing any issues on the other tunnel, which I believe is configured very similarly to this one, to connect to a different hub.

Would it be a good idea to setup a capture filter on the hub?

rx57-409vt-2 (Spoke):
interface Tunnel1100
description Tunnel to rx7-208vt10 hub
bandwidth 20000
ip flow monitor MONITOR_IPV4 input
ip address 10.23.9.171 255.255.254.0
no ip redirects
no ip proxy-arp
ip mtu 1350
ip hello-interval eigrp 895 60
ip hold-time eigrp 895 180
ip nhrp authentication TunnAuth
ip nhrp map 10.23.8.1 aaa.bbb.ccc.ddd
ip nhrp network-id 10001
ip nhrp holdtime 300
ip nhrp nhs 10.23.8.1
ip tcp adjust-mss 1300
delay 1100
ipv6 flow monitor MONITOR_IPV6 input
tunnel source GigabitEthernet0/0/0
tunnel destination aaa.bbb.ccc.ddd
tunnel key 10001
tunnel path-mtu-discovery
tunnel protection ipsec profile DMVPN-PROFILE
!
interface GigabitEthernet0/0/0
description NNM-MON to Comcast (redacted), Boeing (redacted), 20M, RJ45
bandwidth 20000
ip flow monitor MONITOR_IPV4 input
ip address dhcp
no ip redirects
no ip proxy-arp
ip nat outside
ip access-group Protect-the-Router-Inbound in
load-interval 30
negotiation auto
no cdp enable
ipv6 flow monitor MONITOR_IPV6 input
service-policy output QOS-WAN-UPLINK
ip virtual-reassembly
!

router eigrp 895
network 10.6.125.72 0.0.0.7
network 10.23.8.0 0.0.1.255
network 10.23.72.0 0.0.1.255
network 10.28.68.171 0.0.0.0
passive-interface default
no passive-interface Tunnel1000
no passive-interface Tunnel1100
eigrp stub connected
!

rx7-208vt10 (Hub):
interface Tunnel1100
description From authenticated spoke routers
bandwidth 10000000
ip address 10.23.8.1 255.255.254.0
no ip redirects
ip mtu 1350
ip hello-interval eigrp 895 60
ip hold-time eigrp 895 180
no ip next-hop-self eigrp 895
no ip split-horizon eigrp 895
ip flow monitor MONITOR_IPV4 input
ip nhrp authentication TunnAuth
ip nhrp map multicast dynamic
ip nhrp network-id 10001
ip nhrp holdtime 600
ip nhrp max-send 500 every 10
zone-member security external
ip summary-address eigrp 895 0.0.0.0 0.0.0.0
ip tcp adjust-mss 1300
delay 1100
ipv6 flow monitor MONITOR_IPV6 input
qos pre-classify
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 10001
tunnel path-mtu-discovery
tunnel protection ipsec profile DMVPN-PROFILE
!

router eigrp 895
network 10.23.8.0 0.0.1.255
passive-interface default
no passive-interface Tunnel1100
!

[marce1000]

      - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCdv72353

 M.

[Georg Pauwen]

Hello,

apparently you have a ZBF configured on the hub ? If we call this hub the 'problem' hub, does the other 'non-problem' hub have a ZBF configured as well ?

[Verbatim]

Yes, it does.

[MHM Cisco World]

the answer from your Post 
not all time the eigrp flapping 
so sure there is EIGRP packet is drop due to high traffic flow 
this make neighbor assume the EIGRP is down 
I think the solution is use below command and make the percentage 50%
ip bandwidth-percent eigrp as-number percent

MHM

[Verbatim]

Competing for bandwidth and dropping the eigrp packets would explain what was going on. The spoke tunnels are both sourced from the one interface, and it is true the other tunnel on the working hub carries a lot more traffic than the problem tunnel. However, QoS on the spoke router source interface for the tunnels does not show drops taking place in the signaling class, which includes dscp cs3 (24) af31 (26) cs6 (48) cs7 (56). There were drops shown for the tunnel interface before the counters were cleared; in the last 16 hours, there are no drops shown on it, but the tunnel flapped again 11 hours ago.

With that said, all of that is on the spoke side; perhaps there's a bandwidth constraint problem on the hub side. That's something I'll have to dig into.

[MHM Cisco World]

when it happened again 
show ip eigrp interface detail 
if the counter is increase then the eigrp packet not ack from hub and eigrp reset.
MHM

[Verbatim]

[Verbatim]

I also posted show interface tunnel 1100 output as text file to the initial post; it shows there isn't a lot of traffic on this tunnel.

[MHM Cisco World]

Show ip eigrp neighbor detail 

Share this 

Also what is this platform' it not ios nor ios xe.

MHM

[Verbatim]

rx57-409vt-2#show platform
Chassis type: C1111-8P

rx57-409vt-2>show version
Cisco IOS XE Software, Version 16.09.04

System image file is "bootflash:c1100-universalk9_ias.16.09.04.SPA.bin"

[MHM Cisco World]

As I guess 

The retrans count is 1 and rto is 600 (little high).

Check qos and bw.

MHM

[Verbatim]

Problem does not appear to be a bandwidth constraint issue from the hub side. That doesn't mean that there isn't a bandwidth related issue causing drops somewhere in the route between the hub and spoke, but that's going to be quite a rabbit hole to dive down.

[paul driver]

Hello
As you are using phase 2 DMVPN with dynamic eigrp routing, trying mapping the spoke to the hub for multicast

rx57-409vt-2 (Spoke)
interface Tunnel1100
ip nhrp map multicast aaa.bbb.ccc.ddd
no tunnel destination aaa.bbb.ccc.ddd
tunnel mode gre multipoint

[Verbatim]

I'm not sure whether we are using phase 2 DMVPN with dynamic eigrp routing. What would I see if we were?