Here's hoping someone been through this already and would like to share their experience with me. In preparing for an upcoming upgrade of our serverswitches (N7K and N55K), I've run into a wellknown issue with ISSU and Bridge Assurance, where ISSU is not supported when, among other, BA is enabled.
My topology is quite simple (see attatched jpg). A pair of N7K's as distributionlayer switches running in vPC mode with BA between them. The N55K's are dualhomed across the two N7K's through vPC, but each N55K operate indvidually, that is vPC is not running between them. The jpg shows a simplified topology, but I have several N55K's attached.
During the deployment of this network, we enabled BA downstream towards the N55K. In hindsight, maybe I could have excluded this option, but currently it's in operation and is also hindering me in doing ISSU on my N55K's. Now, the easy solution would be to simply revert to normal span-type mode and since the N55K is running LaCP upstream towards the N7K's, we've managed to stay clear of STP's shortcomings, so I believe I'm good even without BA.
Unfortunately, I don't have sufficient equipment at my disposal to set up a lab and test the impact of disabling BA between the N7Ks and N55Ks in a running enviroment. And since our server/application enviroment is somewhat fragile (that's putting it mildly), I'm trying to come up with an educated guess as to what impact to expect, if I concurrently (or as close as a manual intervention can get) re-configure the two ends of the channel to use span-type normal. I would expect the upstream port on the N55K (channel-port) to temporarily be suspended and having to go through the usual rstp cycle on both ends before coming operational again.
So I'm hoping someone out there can shed some light on the above scenario.
Solved! Go to Solution.
Just gone through your reply, I have similar kind of situation. But we have each peered Nexus 5596 is connected to other Nexus 5548's in VPC's etherchannel.
Also the 5596 connected in peered way to peered 6500 aswell.
Changing of port type as you suggest will cause VPC to go down temporarily.....how long will it be and what mechanism will behind it.
Is there a way to avoid ..
The outage will last couple seconds and no way to avoid it. You can minimized it by entering the commands simultaneously but you will still get couple seconds of outage (vPC synchronization).
Thanks Jerry for replying back.
Since we have VPC peering of Nexus switches, and what if we make changes to right leg of following image first. Will that impact the left leg as well ?
All the downlink/uplink ports would need to be changed from spanning tree port type network to "normal".
we are cautious in taking downtime for as dependency of services may break clusters/key exchanges aswell.
Yes, it will affect the left side. If you use the command show vpc consistency-parameters interface po X to verify the port-channel, you will see that port type is a type-1 parameter:
switch# show vpc consistancy-parameters interface po 1
Note: **** Global type-1 parameters will be displayed for peer-link *****
Type 1 : vPC will be suspended in case of mismatch
Name Type Local Value Peer Value
------------- ---- ---------------------- -----------------------
STP Mode 1 Rapid-PVST Rapid-PVST
STP Port Type, Edge 1 Normal, Disabled, Normal, Disabled,
Why it will effect the left side, due to STP or Peering ?
Yes with that command it evident that Type 1 parameters will go in suspension. But for how long....
Due to vPC consistancy parameter mismatch:
If you are in type-1 mismatches, the link will be down until the type-1 mismatches are resolved.