cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4055
Views
23
Helpful
2
Replies

EIGRP vPC Problem

Matt Glosson
Level 1
Level 1

I have a situation with two Nexus 7K switches that have a vPC link between them. That vPC link carries lots of VLANs. One of the VLANs that it carries has had three routers (3825, 2921, 2821) on doing various WAN-related functions. This has worked fine for years. I added a new ISR4431 router to the mix, put it in the same VLAN, and it flaps on its EIGRP neighbor relationship with one of the 7Ks. I found this article that explained why (we're diagram 2)... seems it is related to the loop-prevention hardware built into the Nexus. The article refers to OSPF but since EIGRP also forms neighbor relationships via multicast, I assume it is affected in the same way. The "debug eigrp packet <acl>" when run on the 4431 confirms that it's seeing duplicate packets:

Mar  1 17:11:57.516:   AS 100, Flags 0x1:(INIT), Seq 76881/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1, last received seq 76881, out of sequence, this seq 76881

Here is what the neighbor relationship looks like on the 4431:

EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.10.70.252 Gi0/0/1 14 00:00:14 1 5000 1 76887
4 10.10.10.252 Gi0/0/1 14 00:05:41 3 100 0 48273
3 10.10.10.250 Gi0/0/1 12 00:05:41 1 100 0 49038
1 10.10.10.251 Gi0/0/1 13 00:05:41 3 100 0 68409
0 10.10.70.253 Gi0/0/1 10 00:05:41 1 100 0 45342

There are no error messages on the other 3 routers. My question is why does this work on those but it's causing problems with the ISR4431? Any thoughts?

2 Replies 2

brocknathan
Level 4
Level 4

This is old but, wanted to comment for anyone that might stumble on this. I believe this is due to EIGRP TTL of 2 not being implemented the same accross platforms and code. Sometimes it's TTL of 1. New versions of nexus code fix this vpc routing issue.

Hi Nathan,

You are spot on.

To provide a little context: With vPC and IGP adjacencies over vPC to the vPC peers, the problems start if you implement the peer-gateway feature (which is typically done and recommended). With the peer-gateway, each vPC member switch adopts the MAC address of its peer, and starts listening to it, including performing routing if the packet received in a frame for this MAC address is not addressed to the particular vPC member switch that received it. Now, if a vPC member switch receives a packet that, by the destination IP address, belongs to its vPC peer, it will try to route it (remember - it cannot just switch it since the destination MAC address is considered to be local due to peer-gateway) - but if that packet's TTL was 1, it will obviously be dropped.

Now, older IOS versions, typically the ones you would see on ISR G1 routers (x800 series) and before, used the TTL=2 for their EIGRP packets. This way, the EIGRP over vPC "just" worked with the older IOSes. However, newer IOS versions changed the behavior and went to TTL=1, and that's where the problems start.

Starting with NX-OS 7.3, vPC domain configuration supports the layer3 peer-router command. If this command is configured, packets received by one vPC member and routed across the peer-link to the vPC peer will have their TTL unchanged. This will allow the IGP adjacencies over vPC to start working.

Best regards,
Peter

Review Cisco Networking for a $25 gift card