EIGRP Neighbor flapping between Core's on VLAN 48

[Adam Coombs]

Hello I am looking for help with this problem i am having.  6513 vlan48 connects to 3750-e switch

I can ping each side of that vlan ip address successfully

traceroute the ip address find

I can ping each side using the source ping option

ping ip 10.200.0.13 source vlan 48 works fine

I have check each port to look for any inputs errors, crc,frame,overrun,ignored etc... all are zero

The intefaces are not passive  

This the logging information from the 6513 switch

Sep 17 14:45:05: EIGRP: Packet from ourselves ignored

Sep 17 14:45:10: EIGRP: Packet from ourselves ignored

Sep 17 14:45:16: EIGRP: Packet from ourselves ignored

Sep 17 14:45:19: EIGRP: Packet from ourselves ignored

Sep 17 14:45:25: EIGRP: Packet from ourselves ignored

Sep 17 14:45:28: EIGRP: Packet from ourselves ignored

Sep 17 14:45:32: EIGRP: Packet from ourselves ignored

Sep 17 14:45:38: EIGRP: Packet from ourselves ignored

Sep 17 14:45:43: EIGRP: Packet from ourselves ignored

Sep 17 14:45:47: EIGRP: Packet from ourselves ignored

Sep 17 14:45:50: EIGRP: Packet from ourselves ignored

Sep 17 14:45:56: EIGRP: Packet from ourselves ignored

Sep 17 14:46:01: EIGRP: Packet from ourselves ignored

Sep 17 14:46:04: EIGRP: Packet from ourselves ignored

Sep 17 14:46:10: EIGRP: Packet from ourselves ignored

Sep 17 14:46:13: EIGRP: Packet from ourselves ignored

Sep 17 14:46:18: EIGRP: Packet from ourselves ignored

Sep 17 14:46:23: EIGRP: Retransmission retry limit exceeded

Sep 17 14:46:23: EIGRP: Holdtime expired

Sep 17 14:46:23.237 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 10.200.0.13 (Vlan48) is down: retry limit exceeded

Sep 17 14:46:23: EIGRP: Neighbor 10.200.0.13 went down on Vlan48

Sep 17 14:46:24: EIGRP: Packet from ourselves ignored

Sep 17 14:46:27: EIGRP: New peer 10.200.0.13

Sep 17 14:46:27.397 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 10.200.0.13 (Vlan48) is up: new adjacency

show ip eigrp interfaces

IP-EIGRP interfaces for process 500

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Vl48               1        0/0         0       0/1           50          63

6513 has a loopback address

3750e does not have a loopback address

I am sure there is more i need to give but I cant think of anything right now please i will provide

[rfalconer.sffcu · Accepted solution]

Packet from ourselves ignored is probably coming from your loopback address. Do you need the no passive-interface Loopback0 in there for some reason?

[Adam Coombs]

Well the loopback0 that helps with routing and and testing from what i know about it.

[rfalconer.sffcu · Accepted solution]

What is your loopback0 specifically doing? Loopbacks are typically used for routing and management but I'm curious if your loopback is actually doing these things.

[Adam Coombs]

Well from what i know and see about the loopback setting are for routing and management.  Robert how can i test this to make sure the loopback is working correctly besides ping the loopback interface from any switch?

Thank you for your help as well Robert

[rfalconer.sffcu]

If the loopback is created, it should be doing what is needed. As John said, it shouldn't matter to make that passive since passive just stops eigrp hellos. The loopback interfaces don't need to be included in eigrp neighbor relationships. Even if you make it passive, it won't stop other things from working.

John also asked about loops. How many connections are there between the 3 switches?  Have you looked at sh cdp neighbor to see where you have connections between the switches?

Also, have you done any debugs on eigrp?

[Adam Coombs]

well loopbacks are include into many lists

there is two connections per device

so there are two connections from 6513 to other 6513,  two connections from 3750e to 6513 (flapping), two connections from 3750e to 6513.  all Connections are Fiber

I have do the show cdp neighbors details and summary command to verify those connections are connected

I have not done debugs on eigrp because last network guy did it still trying to find them and plus trying to get the

maintenance window to do this, looking like the window will have to be next week

I would like to see the debugs myself as well

I am going to change the loopback to passive in the maintenance

[dslice]

Any chance you have a duplicated IP address so your unicast is broken? I think the loopback interface stuff is a rabbit trail. It appears you have multicast in both directions (because of entries in neighbor tables) but unicast only working in one direction. Since the Q count is 0 on the 3750, he is receiving acks successfully, bit the retry limit exceeded with a Q count value means the 6500 isn't getting acks.

Have you tried pinging with full packet sizes in case of mtu problem?

Sent from Cisco Technical Support iPad App

[John Blakley]

Donald,

I labbed this up and was able to get the same result:

interface Loopback1

ip address 1.1.1.2 255.255.255.255

end

R2(config-router)#network 1.1.1.0 0.0.0.255

R2(config-router)#

*Mar  1 00:24:04.643: EIGRP: Packet from ourselves ignored

*Mar  1 00:24:09.315: EIGRP: Packet from ourselves ignored

*Mar  1 00:24:14.215: EIGRP: Packet from ourselves ignored

Debug those packets:

*Mar  1 00:30:04.671: EIGRP: Sending HELLO on Loopback1

*Mar  1 00:30:04.675:   AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

*Mar  1 00:30:04.683: EIGRP: Received HELLO on Loopback1 nbr 1.1.1.2

Notice that I have a /24 mask for a /32 host. If I specify the /32, the error goes away. So, the loopback could be an issue without an address conflict.

HTH,
John

*** Please rate all useful posts ***

[dslice]

My point was not that the packet from ourselves message is not related to the retry limit exceeded, which is the real problem

[Adam Coombs]

well Donald how would you test to see if the unicast is broken ?

I have ping to the 3750e to 6513 and back with mtu size 1500 repeat 1000 also used source vlan 48 all are successfully no drop packets.

Well how would you fixed retry limit exceeded problem ?

[shajakhan85]

Hi,

Configure no auto-summary on 3750 switch and also check the any multicast packet blocks on the link......

[dslice]

Is the mtu the same on both ends?  Is the problem continually happening?  Is there anything between the two routers/switches or are there other devices between them that could be creating an issue?  Check the arp entries to make sure that the mac address is what is expected (looking for a duplicate).

Another thing to try is to do the extended ping with a range of sizes and payloads rather than a fixed size.

[Adam Coombs]

Donald
I have ping both sides with different mtu size and repeat it like 100, 1000, 10000
MTU size i have try is 64, 1000, 1100, 1500.

There is nothing between these devices

We would it matter if arp entery to a mac address is being used by more than one device?

[dslice]

Maybe I don't understand your question, but if the MAC address mapping in the ARP table is incorrect, then unicast will be delivered to the wrong device.  Pings would work (the wrong guy would be answering) but EIGRP wouldn't function.

[Adam Coombs]

Well Donald, I am litte confused myself by (

Check the arp entries to make sure that the mac address is what is expected (looking for a duplicate). 
Question

can you show me a example of this please

Thank you