02-22-2023 05:27 PM - edited 02-22-2023 05:33 PM
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
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
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
Solved! Go to Solution.
02-23-2023 03:10 PM
I bumped the NX-OSv version down to 9.3.5. Everything seems to be working now with spanning tree enabled
02-23-2023 01:12 AM
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
02-23-2023 03:19 PM
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
02-26-2023 10:22 PM
Initially, your configuration was not matching the pictures, that's why I said that is confusing. I see you corrected it afterwards.
02-27-2023 05:45 PM
That is simply not true. It was edited before any responses were provided.
That is when you responded.
that is when I edited it.
02-27-2023 05:51 PM
Not only are you providing advice that is not relevant, you are trying to make an excuse for it that blames me.
02-24-2023 06:10 PM
- 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.
02-26-2023 10:50 PM
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
02-27-2023 06:00 PM - edited 02-27-2023 06:02 PM
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.
02-23-2023 03:10 PM
I bumped the NX-OSv version down to 9.3.5. Everything seems to be working now with spanning tree enabled
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: