Revision as of 21:27, 30 November 2011

This article describes how to do basic troubleshooting of virtual Port Channel(vPC) problems on a Cisco Nexus 7000 NX-OS device.

Troubleshooting vPC on Nexus 7000 is covered in detail in Cisco-Live presentation. Sections of this presentation covers,
both platform independent, and platform specific step by step troubleshooting for vPC, among other things. Access to
this presentation is available FREE. Follow the below instructions to access the presentation

Initial Troubleshooting Checklist

Begin troubleshooting vPC issues by checking the following issues first:

Checklist

Check off

Verify that all vPC interfaces in a vPC domain are configured in the same virtual device context (VDC).

Verify that you have a separate vPC peer-link and peer-keepalive link infrastructure for each VDC deployed.

Is the vPC keepalive link mapped to a separate vrf? If not, it will be mapped to the management vrf by default. In this case, do you have a management switch connect to the management ports on both vPC peer devices?

Verify that the vPC peer-link is configured on a N7K-M132XP-12. It is recommended to have at least two N7K-M132XP-12 for redundancy.

Verify that both the source and destination IP addresses used for the peer-keepalive messages are reachable from the VRF associated with the vPC peer-keepalive link.

Verify that the peer-keepalive link is up or the vPC peer-link will not come up.

Verify that the vPC peer-link is configured as a Layer 2 Port Channel trunk which only allows vPC VLANs.

Verify that the vPC number that you assigned to the port channel that connects to the downstream device from the vPC peer device is identical on both vPC peer devices.

If you manually configured the system priority, verify that you assigned the same priority value on both vPC peer devices.

Check the show vpc consistency-parameters command to verify that both vPC peer devices have identical type-1 parameters.

Verify that the primary vPC is the primary STP root and the secondary vPC is the secondary STP root.

Verifying vPCs Using the CLI

To verify vPCs using the CLI, follow these steps:

1. Use the show running-config vpc command to verify the vPC configuration.

2. Use the show vpc command to check the status of vPC.

3. Use the show vpc peer-keepalive command to check the status of the vPC peer-keepalive link.

4. Use the show vpc consistency-parameters command to verify that both the vPC peers have the identical type-1 parameters.

5. Use the show port-channel summary command toverify the members in the port channel are mapped to the vPC.

6. Use the show cfs status commands to verify that distribution over Ethernet is enabled.

7. If you enable STP, use the show spanning-tree command on both sides of the vPC peer link to verify that the following STP parameters are identical:

BPDU Filter

BPDU Guard

Cost

Link type

Priority

VLANs (PVRST+)

Received Type 1 Configuration Element Mismatch

You may have a problem where you cannot bring up a vPC link because of a type 1 configuration element mismatch.

Symptom

Possible Cause

Solution

Received a type 1 configuration element mismatch.

The vPC peer ports or membership ports do not have identical configurations.

Use the show vpc consistency-parameters interface command to determine where the configuration mismatch occurs.

Example: show vpc consistency-parameters Command Output

This example shows how to display the vPC consistency parameters on a port channel:

vPC in Blocking State

BPDU only sends on a single link of a port-channel. If BA dispute is detected, the entire vPC will be in the blocking state.

Do not enable BA on vPC.

VLANs on a vPC moved to suspend state

VLANs on a vPC may move to the suspend state.

Symptom

Possible Cause

Solution

VLANs on a vPC moved to suspend state.

VLANs allowed on the vPC have not been allowed on the vPC peer=link.

All VLANs allowed on a vPC must also be allowed on the vPC peer-link. Also, it is recommended that only vPC VLANs are allowed on the vPC peer-link.

Hosts with an HSRP Gateway Cannot Access Beyond Their VLAN

When HSRP is enabled on both vPC peer devices on a VLAN and hosts on that VLAN set the HSRP as their gateway, they may not able to reach anything outside their own VLAN.

Symptom

Possible Cause

Solution

Hosts with an HSRP gateway cannot access beyond their VLAN.

If the host gateway mac-address is mapped to the physical MAC address of any one of the vPC peer-devices, packets may get dropped due to the loop prevention mechanism in vPC.

Map the host gateway's mac-address to the HSRP MAC address and not the physical MAC address of any one of the vPC peer-devices. Peer-gateway can be a workaround for this scenario. Please read the configuration guide for peer-gateway for further information before implementing it.

Traffic Disrupted when the Primary vPC Device Goes Down

Traffic may remain disrupted when the N7K-M132XP-12 module on the primary vpc device goes down.

Symptom

Possible Cause

Solution

Traffic disrupted when the primary vPC device goes down.

All core facing interfaces and vPC peer-links are configured on a single N7K-M132XP-12 module.

Enable object tracking. With object tracking enabled, all vPC on the primary will shut down. The vPC secondary will take over as the operational primary and all the vPC on the secondary will stay up. As a result, traffic will still be flowing thru the secondary which became operational primary.