cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
785
Views
10
Helpful
3
Replies

VPC Load Balancing / Redundancy

mkashifashraf
Level 1
Level 1

Dears,

 

We've VPCs configured in ACI with L3Outs/L2Outs on and facing issue that some type of traffic after single link failure in VPC has dropped. like ping/trace is working but SSH or HTTP is not working and after to fix the passive issue all kind of traffic is fine.

 

It seems that redundancy by default on VPC is based on type of traffic, how we can fix this issue to get proper load balancing / redundancy on VPCs.

 

Thanks

3 Replies 3

Check this point from cisco "red text"
Should I enable vPC auto-recovery?

It is a good practice to enable auto-recovery in your vPC environment.

There is a slight chance that the vPC auto-recovery feature might create a dual-active scenario. For example, if you first lost the peer-link and then you lost the peer-keepalive, you will have dual-active scenario.

In this situation, each vPC member port continues to advertise the same Link Aggregation Control Protocol ID that it did before the dual-active failure.

A vPC topology intrinsically protects from loops in case of dual-active scenarios. In a worst case scenario, there are duplicate frames. Despite this, as a loop-prevention mechanism, each switch forwards Bridge Protocol Data Units (BPDUs) with the same BPDU Bridge ID as prior to the vPC dual-active failure.

While not intuitive, it is still possible and desirable to continue to forward traffic from the access layer to the aggregation layer without drops for current traffic flows, provided that the Address Resolution Protocol (ARP) tables are already populated on both Cisco Nexus 7000 Series peers for all needed hosts.

If new MAC addresses need to be learned by the ARP table, issues might arise. The issues arise because the ARP response from the server might be hashed to one Cisco Nexus 7000 Series device and not to the other, which makes it impossible for the traffic to flow correctly.

Suppose, however, that before the failure in the situation just described, traffic was equally distributed to both Cisco Nexus 7000 Series devices by a correct PortChannel and by an Equal Cost Multipath (ECMP) configuration. In this case, server-to-server and client-to-server traffic continues with the caveat that single-attached hosts connected directly to the Cisco Nexus 7000 Series will not be able to communicate (for the lack of the peer link). Also, new MAC addresses learned on one Cisco Nexus 7000 Series cannot be learned on the peer, because this would cause the return traffic that arrives on the peer Cisco Nexus 7000 Series device to flood.

check this command.
Nexus(config-vpc-domain)#
ip arp synchronize

Sergiu.Daniluk
VIP Alumni
VIP Alumni

Hi @mkashifashraf 

First, just wanted to say that VPC does not differentiate the traffic based on ip protocol number. Based on your short description, to me it sounds either a bug related to contracts, or some sort of misconfig. Anyway, a deeper tshoot should be performed.

Since the investigation in a forum post can be quite tedious for such scenarios (it involves narrowing down the problem to impacted direction of the traffic, packet captures, config checks, contract programming checks etc), I would recommend you open a case with TAC and perform a live tshoot.

 

Stay safe,

Sergiu

Save 25% on Day-2 Operations Add-On License