EIGRP neighbor flapping

[umeshunited]

I have configured neighborship between ASA and Router through Switch. EIGRP keeps flapping every 120 seconds.

ASA(inside,192.168.10.2) -------(gi1/0/5)SW1(gi1/0/6)-----(GigabitEthernet0/1.10 192.168.10.1 )2911 router

ASA Side configuration

interface GigabitEthernet0/1
description ***To 2911 Cisco Router***
nameif inside
security-level 100
ip address 192.168.10.2 255.255.255.0

router eigrp 100
no auto-summary
network 192.168.10.2 255.255.255.255

Switch config
interface GigabitEthernet1/0/5
switchport access vlan 10
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable

interface GigabitEthernet1/0/6
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk

Router config
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
no ip redirects
no ip unreachables

router eigrp 100
network 192.168.10.1 0.0.0.0
redistribute static route-map STATIC=>EIGRP
redistribute bgp 65000 metric 50000 1 255 1 1500

[Peter Paluch]

Hello,

All the best in 2019! :)

The fact that EIGRP flaps so frequently - and regularly - may be important. What we need to know now are the logging messages from both the router and the ASA since they might provide us with additional clues about what is going wrong. Here is a couple of mixed questions and suggestions:

• Would you mind sharing the logs (show logging) from both the router and the ASA? They will include the immediate reason for the EIGRP flaps. Ideally, I would like to ask for a complete unabbreviated log output if possible.
• Also, it would be helpful if you could provide the output of show ip eigrp neighbor and show ip eigrp neighbor detail commands some 10-20 seconds after the neighbors flap and come back up - from both the router and the ASA.
• It is possible that the flaps are caused by STP topology changes in your network. We can test this quite safely - let us try configuring spanning-tree portfast trunk command on the gi1/0/6 interface of the switch. Since this port connects to the router, there is no risk of switching loops, and if you run RSTP or MSTP, configuring the port as a PortFast port will prevent the port from becoming Discarding (Blocking) during a Proposal/Agreement exchange.

Thank you! Looking forward to hearing from you!

Best regards,
Peter

[umeshunited]

Hello Paul,

Good day !

Please find attached output.

[Meheretab Mengistu · Accepted solution]

Hello,

Please allow me to join the discussion.

R1#sh ip eig neighbors det
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   192.168.10.2            Gi0/1.10                 14 00:00:30    1  5000  1  8849
   Version 8.6/3.0, Retrans: 7, Retries: 7, Waiting for Init Ack
   Topology-ids from peer - 0 
    UPDATE seq 4438 ser 0-0 Sent 30452 Init Sequenced 

The Q count on both sides is non-zero. Also, the neighbor is terminating every 80 seconds on the router side; it looks like retry limit is reached.

Could you provide the output of the following commands from the router:  debug eigrp packets, and extended ping with size full MTU (eg. ping 192.168.10.2 size 1500 df-bit validate)? Also check whether there is an access-list which blocks EIGRP packets.

HTH,

Meheretab

[Peter Paluch · Accepted solution]

Hello Meheretab,

Thank you for joining!

Your observations are correct, and I see even more in the logs from ASA:

FW1# show eigrp neighbors  detail
EIGRP-IPv4 neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.10.1            Gi0/1            14  00:00:51 1    5000  2   0
   Version 12.0/2.0, Retrans: 11, Retries: 11, Waiting for Init, Waiting for Init Ack
   Topology-ids from peer - 0
    UPDATE seq 8863 ser 0-0 Sent 51250 Init Sequenced
    UPDATE seq 8864 ser 1-1 Sequenced

The indications highlighted in red say that this ASA is waiting for the initial unicast Update with the Init flag from the 192.168.10.1 neighbor but it has never arrived (Waiting for Init), and in addition, the ASA is waiting for an acknowledgment of its own Update+Init packet that was sent to 192.168.10.1, but this acknowledgment has not arrived either (Waiting for Init Ack). Both these packets are unicast packets, and so we are looking at a unicast communication issue here. I do not personally believe that MTU is at play here since these Update+Init packets, also called Null Updates, are only a few hundred bytes long.

The output from R1 you have also highlighted shows only Waiting for Init Ack. This means that the router received the Update+Init from ASA, but is unable to pass its own Update+Init and its own Ack to the ASA.

The way I see it, the unicast communication in the direction R1 -> ASA is broken. The multicast obviously works since the router and the ASA see each other as EIGRP neighbors but that is accomplished using multicast Hello packets. What is broken is the unicast EIGRP communication in the R1 -> ASA direction.

Indeed, it is necessary to check the ACLs on the ASA side to see if they are permitting EIGRP unicast packets.

Best regards,
Peter

[umeshunited]

Hello Mehertab,

Good day !

Thank you for your reply.

Unfortunately debug at this point of time is not possible. Though I'll ask client to provide it asap.

[Meheretab Mengistu]

It is okay. At this point we are suspecting an access-list could be blocking unicast traffic from R1 to the ASA. Please check for an access-list blocking eigrp unicast (protocol 88) on the path from R1 -> ASA.

HTH,
Meheretab

[umeshunited]

Hello Mehertab,

Good day !

Thank you for your reply.

Unfortunately debug at this point of time is not possible. Though I'll ask client to provide it asap.

[umeshunited]

There was an inline security device, installed transparently. 

Thanks you to all for your inputs.

[Julio E. Moisa]

Hi,

The config looks fine, have you seen errors into the interfaces? show interface <interface> or removing the following under the switchport:

spanning-tree portfast
spanning-tree bpduguard enable

Try to execute a debug in order to see what happen during the adjacency. 

[Peter Paluch]

Hello Julio,

Thank you for joining.

With all due respect, I humbly disagree with your suggestions. As I explained in my previous post, STP TCEs (topology change events) are one of the suspects here. The protection against edge ports being blocked for 30 seconds by the sync (Proposal/Agreement) operations in RSTP/MSTP during the handling of a TCE is exactly the PortFast feature which I suggested not only to keep on the port toward the ASA, but also add it with the trunk keyword on the port toward the ISR router as well. Since one of the switchports is connected to a router while the other is connected to an ASA, these devices would not send out BPDUs, so the BPDU Guard has no reason to engage (and if it does anyway, we will see evidence in the logs I have requested), hence removing the BPDU Guard and PortFast is unlikely to have any positive impact; configuring the PortFast on these two ports, on the other hand, may improve things significantly.

Best regards,
Peter

[Julio E. Moisa]

Thanks Peter, apologies i didnt see that suggestion adding spanning-tree portfast trunk , we will wait for the logs. I have seen this command under switchports usually connected to servers who support 802.1q but it makes sense for layer 3 devices like the router.