cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1704
Views
0
Helpful
2
Replies

Fabricpath traffic blackhole when MAC ages out on leaf switch

silemire
Level 1
Level 1

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.

fp_blackhole.png

2 Replies 2

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

Getting Started

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: