I am seeing strange behavior from a 3850 stack running EIGRP to a couple of 4507's. Let me start out by saying that over the past couple of weeks, we have replaced 5 stacks using the same configuration template, code version, etc. with no issues. Before we execute the change to install these switches, we always run failover testing to prove routing. Last night, on the 6th switch stack, failover testing did not succeed. Maybe you can help me figure out why.
Here is what happened. I have a loopback configured on the stack. We connect the stack to each of the 4507's at the distribution layer and bring up an eigrp adjacency. I start a continuous ping from another site to the loopback. Then we pull the first link and the ping continues successfully. Plug it back in, bring up the adjacency. Then we pull the second uplink and the ping begins failing (TTL Lost in transit). The route at the source of the ping was lost so it was using the default route which led to nowhere. When I check the route against the table on the 4507's the subnet is not in the table but the adjacency is up.
I have attached a topology drawing of the relevant devices (as I see it). Again, we never experienced this issue with the 5 previous stacks which are all connected to the 4507's the same way.
So you have equal cost paths on the 4507 to the loopback. You pull the first link and the ping continues because it still has one route. You reconnect the link and an adjacency is formed but no routes are passed from the 3850 to the 4500 and then when you pull the second link the only remaining routes is lost on the 4507 ?
When you plug the first link back in -
1) what do you see in the EIGRP topology tables on the 4507
2) You may need to run debugging on EIGRP to see what is happening from the 4500 and 3850 end
My logs show an entry that reads "Dec 19 15:19:26.811: EIGRP: Handle deallocation failure ". Has anyone ever seen this? Looks like info is scarce.
See this thread. The Cisco person answering is an expert on EIGRP so it may just be a bug as he says -
Did you try debugging and looking at the topology tables when reconnecting the first link ?
That error message is always an indication of a bug. It's just not certain the side effect of hitting it.
Sent from Cisco Technical Support iPad App