10-23-2013 06:23 AM - edited 03-07-2019 04:11 PM
Here's my network setup:
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.
10-23-2013 09:08 AM
07-15-2015 11:42 AM
Hello silemire,
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?
Regards,
Florent
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: