Can't find what you need?


• Ask the Community
• Create a Case
Reset Search
 

 

Article

After a Port Channel Redundancy Group member VDX boots from its default config and receives its running-config from the principal switch, a Layer2 bridging loop will occur.

« Go Back

Information

 
TitleAfter a Port Channel Redundancy Group member VDX boots from its default config and receives its running-config from the principal switch, a Layer2 bridging loop will occur.
Symptoms
After a Port Channel Redundancy Group member VDX boots from its default config and receives its running-config from the principal switch, a Layer2 bridging loop will occur.
Environment
  • VDX6740, VDX6740T
  • NOS 6.0.2b, 7.0.1a, 7.0.1b, 7.1.0
Cause
This issue can be considered a failure to apply PRG behavior to the port channel interfaces of a VDX that booted from its default config and received its config from the VCS principal.
Resolution
This issue is registered as DEFECT000633740. It is fixed in versions NOS 7.1.0a, 7.2.0, and later versions.

NOS 7.2.0 contains multiple fixes relating to Port Channel Redundancy Group functionality: DEFECT000633740, DEFECT000636021, DEFECT000634220, and DEFECT000634222. Publicized details on each are available in the NOS 7.2.0 release notes. There are no plans to port these fixes to additional earlier releases. Any customer considering using PRG should be running NOS 7.2.0 or later.

In software without the fix for DEFECT000633740, after the DEFECT000633740 issue has occurred, it is possible to recover by entering the config of the affected port-channel-redundancy-group, applying "no activate", and then applying "activate". Executing "no activate" then "activate" under the PRG config forces re-application of PRG behavior to port channels that had failed to apply PRG behavior when receiving their config from the VCS principal.

A reliable method of preventing this issue from happening in all circumstances does not exist. When "vcs replace" is planned it may be possible to avoid the issue by leaving non-ISL interfaces disconnected before running "vcs replace", applying "no activate" and "activate" to the PRG after "vcs replace" is complete, and then connecting non-ISL interfaces as a final step. There is no method of preventing the DEFECT000633740 issue from happening in unplanned situations such as a VDX losing power, losing its config, and receiving its config from the VCS principal. When PRG is configured, upgrading to NOS 7.2.0 or later is higher priority than attempting preventative measures.
Additional notes
DEFECT000633740 was originally discovered in an environment where a PRG member VDX running 7.0.1a was cold rebooted, Dcmd database corruption was detected during boot, the VDX started with its default config, and then the VDX received its config from the principal. At the time LAGs and PRGs were being used and vLAGs were not being used. The issue was found to be 100% reproducible by temporarily severing a PRG member VDX's connections, executing "copy default-config startup-config" on the isolated VDX, and then restoring connections while it boots. This method imitated the loss of config due to sudden loss of power. The issue was registered as DEFECT000633740 and fixed in NOS 7.1.0a and 7.2.0.

Later, DEFECT000633740 bridging loops were reported in an environment running NOS 6.0.2b and using PRG where "vcs replace" had been executed. As such it is safe to assume that if PRG is configured in a VCS running any version without the fix for DEFECT000633740, the environment will experience bridging loops after executing "vcs replace". Again, due to PRG issues DEFECT000633740, DEFECT000636021, DEFECT000634220, and DEFECT000634222, any environment with PRG configured should be running NOS 7.2.0 or later.

Further information on situations where port channel redundancy groups should be used can be found in When would I use port-channel redundancy groups?

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255