Fabricpath traffic blackhole when MAC ages out on leaf switch
Here's my network setup:
2x Nexus 7710 at the spine with HSRP (routing at the spine layer)
2x Nexus 6001 running VPC+ (leaf layer 2 only)
Fabricpath between the 6K and 7K
Traffic to a vPC connected host on the N6K is load-balanced 50/50 between both Nexus 6K's (i'm running multiple flows for the purpose of this test).
If a MAC address entry in the CAM of the N6K ages out (or is cleared manually) while the same MAC address is still in the ARP cache and CAM of the N7K, 50% of my traffic is blackholed. All the traffic going to N6K-1 is being dropped: I can see the traffic entering the switch from the FabricPath port but it's not leaving out any ports towards the vPC. The situation persists until the vPC connected host generates some traffic to refresh the MAC address entry on the N6K. (for my test, the host is basically silent and only answers to ARPs).
Since the N7K has learned the MAC address, from a FabricPath perspective is this considered unknown unicast traffic or regular unicast traffic? If it's considered unicast traffic from a FabricPath perspective, is it normal that one of the two VPC+ peer drops the traffic if it does not have a CAM entry for that MAC address?
If I also clear the MAC adress entry from both N7K then my traffic starts working again. I guess in this case traffic is now being forwarded using the multidestination tree so both N6K's know they should forward this traffic.
I had exactly the same problem and your post helped me a lot. Thanks!
Have you find a solution (by design or config) for this issue?
From my understanding, even if design/config make completly disapear automatic mac flushing (limit BPDU TCN by using Edgeport function, respect timer hierarchy (CAM > ARP)), manual clearing of MAC tables always introduce traffic black holing. Right?
Also, I'm not totally agree with the bug description from the cisco bugtoolkit website (CSCud25862).
In our scenario, I think the frame received by the N5K/N6K is not a unknown unicast fabricpath frame (because the ingress fabricpath switch know both source and destination MAC address), but a unicast fabricpath frame. So I think the problem is that the egress fabricpath switch not flood the received unicast fabricpath frame on VPC CE interfaces (that it should normaly do because locally MAC address is not known).
Is the solution is to prohibit manual clearing of MAC address on Nexus 5000?
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.