Eigrp q count increasing! Please help

[estradae2389]

Im trying to figure out why the q count in eigrp keeps increasing. Current setup is like this, dmvpn >>> firewall >>> Core. The dmpvn to core is fine but from core to dmvpn its not receiving the data. K values, hello timers, routes are all fine. let me know if you need more output. Thank you

Dmvpn
H Address Interface Hold Uptime SRTT RTO Q Seq(sec) (ms) Cnt Num
6 172.23.xxx.254 Gi0/1 14 00:01:10 1 5000 1 4107582058
5 172.23.xxx.15 Gi0/1 14 1w6d 2 100 0 35749366
4 172.23.xxx.5 Gi0/1 11 1w6d 1 100 0 130145330
3 172.23.xxx.177 Gi0/1 14 1w6d 21 126 0 138264638
2 172.23.xxx.176 Gi0/1 12 1w6d 43 258 0 107791987
1 172.23.xxx.8 Gi0/1 13 1w6d 4 100 0 16638966
0 172.23.xxx.253 Gi0/1 14 1w6d 12 100 0 3950219231

Core

H Address Interface Hold Uptime SRTT RTO     Q Seq
(sec) (ms) Cnt Num
10 172.23.xxx.16 Vlan248 14 00:00:10 1 5000 134 0

[Peter Paluch]

Hello,

The Q Cnt is the number of reliable packets that have been sent to the neighbor but have not yet been acknowledged as received by the neighbor. If the Q Cnt value remains non-zero for more than a couple of seconds, it suggests a communication problem between this router and the corresponding neighbor.

Very often, these problems are caused by differences in multicast and unicast reachability between these two neighbors - for example, these routers can hear each other through unicast, but multicast sourced by one of these routers is not reaching the other one; or vice versa. EIGRP uses a combination of unicast and multicast when bringing up adjacencies, so a problem in either of these functionalities can cause trouble.

I suggest doing a quick test to isolate the problem and please report any failure:

1. From the DMVPN router, ping 172.23.xxx.254 (Core)
2. From the Core, ping 172.23.xxx.16 (DMVPN)
3. From the DMVPN, ping 224.0.0.10 and make sure that one of the responses comes from 172.23.xxx.254 (Core)
4. From the Core, ping 224.0.0.10 and make sure that one of the responses comes from 172.23.xxx.16 (DMVPN)

In addition, the fact that the EIGRP packets are being queued suggests that there might actually be a problem in the unicast connectivity - this is because queued packets are retransmitted as unicasts, and so if they cannot be acknowledged then this is a problem in unicast connectivity. In any case, the test above will possibly point us in the right direction.

I wonder - the firewall you are using - is it setup to allow all packets between your DMVPN and Core routers in both directions? Is it possible to temporarily deactivate it, ot ar least, to fully open the communication between the public IP addresses of the DMVPN and Core routers? By the way, I assume that the firewall works as a "bump in the wire", considering the fact that the DMVPN and Core routers seem to reside on the same IP network 172.23.xxx.0/24 and so the firewall obviously cannot operate in routed mode.

Best regards,
Peter