cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
809
Views
0
Helpful
9
Replies

NX-OSv 9.3.10 and 9.3.11 vPC STP blocking

sp2720401
Level 1
Level 1

I found that spanning tree is blocking vlans on NX-OSv versions 9.3.10 and 9.3.11 on the vPC peer link for every vlan except vlan 1.

My configurations work on physical switches running both versions. 

vpc domain 2
peer-switch
role priority 100
system-mac 00:23:04:b1:b1:b1
system-priority 3000
peer-keepalive destination 10.0.0.2 source 10.0.0.1 vrf VPC_KEEPALIVE
peer-gateway

9.3.10 spanning.PNG

In version 9.3.10 you can see the system mac for the root bridge is what is set in the vpc domain configuration and it is not blocking for vlan 1 but it is blocking for vlan 201. The bridge id for vlan 201 is actually not the system mac set in the vpc domain configuration.

vpc domain 2
peer-switch
role priority 100
system-mac 00:23:04:a1:a1:a1
system-priority 3000
peer-keepalive destination 10.0.0.2 source 10.0.0.1 vrf VPC_KEEPALIVE
peer-gateway

Capture 9.3.11.PNG

In 9.3.11 it seems that the system mac portion has been fixed and the bridge ID is the same as the root id which is what has been configured for the vPC domain. But for all vlans other than vlan 1 the peer link is in the blocking state for spanning tree.

To get around this I disabled STP for the vlans I am working with. This might cause other problems down the road for lab setup but i just wanted to point out that there is some kind of bug in versions 9.3.10 and 9.3.11. 

This is a sample of the architecture I am working with. LEAF A1/A2 use vpc system mac 00:23:04:a1:a1:a1 and LEAF B1/B2 use system mac 00:23:04:b1:b1:b1

sample architecture.PNG



 

 

 

1 Accepted Solution

Accepted Solutions

sp2720401
Level 1
Level 1

I bumped the NX-OSv version down to 9.3.5. Everything seems to be working now with spanning tree enabled

sp2720401_0-1677193543792.png

sp2720401_1-1677193826410.png

 

 

View solution in original post

9 Replies 9

Sergiu.Daniluk
VIP Alumni
VIP Alumni

Hi @sp2720401 

It is not clear from the above details what is the configuration you have in your setup, but here are some guidelines:

- vpc system mac must be identical on the vpc peer switches part of the same vpc domain

- vpc domain id must be unique in the layer 2 domain

 

Take care,

Sergiu

You didn't look at the diagram then. Everything is clear. 

LEAF A1/A2 use system mac 00:23:04:a1:a1:a1
LEAF B1/B2 use system mac 00:23:04:b1:b1:b1

Initially, your configuration was not matching the pictures, that's why I said that is confusing. I see you corrected it afterwards.

That is simply not true. It was edited before any responses were provided. 

sp2720401_1-1677548625318.png

That is when you responded.

sp2720401_2-1677548668567.png

that is when I edited it. 

Not only are you providing advice that is not relevant, you are trying to make an excuse for it that blames me. 

- vpc domain id must be unique in the layer 2 domain

This is another thing you missed. The system mac is generated from the domain id. I manually set the system mac on the vpc peers. so domain id is irrelevant in this regard. 

But that is a moot point seeing as downgrading the version fixed the issue and none of my peer links or peer keepalive links share the same layer 2 domain. 

You are correct. vPC domain ID generates the vpc system mac, so by manually configuring the vpc system mac, you can*** use the same vpc domain ID.

***Note: I strongly discourage this, simply because the software is not and will never be bug free. You never know when you can get a partial network meltdown because of a unexpected bug with `vpc system mac` command. In the end, nothing stops you to manually configure the vpc system mac and at the same time configure unique vpc domain id. But hey, it's your network, play as you wish.

 

Coming back to the problem you experienced, if we look at the screenshots you shared, which are again incomplete because are only taken from one peer from each vpc domain, you could see that the bridge id of Leaf-B1 is not the system mac. Meaning the problem is not with the "vpc system mac" command, but with the "peer-switch" command. When peer switch is enabled, the vpc peer will use the vpc system mac as it's bridge id. You could see the correct and expected output on leaf-A1.  A "show vpc" would have been useful as well to see who is primary and who is secondary.

Anyway, I think if you would have shutdown and then no shut the vpc domain on the problematic leaf, then problem could have been resolved. Or maybe it's an order of operation type of issue.

 

Take care,

Sergiu

 

Stop while you are behind... quit digging deeper. The first post said this was already working on real switches. 102 real switches to be exact. 

LEAF A1 is not connectd to LEAF B1.
LEAF A1 is not connected to LEAF B2. 

LEAF-A1 is connected to LEAF A2
LEAF-B1 is connected to LEAF B2 

Which is completely apparent in the diagram. I didn't post this to ask for help with my configuration. I posted it because I found something that wasn't working properly with NX-OSv. 

sp2720401
Level 1
Level 1

I bumped the NX-OSv version down to 9.3.5. Everything seems to be working now with spanning tree enabled

sp2720401_0-1677193543792.png

sp2720401_1-1677193826410.png

 

 

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: