We have two 5548 switches connected to a pair of 6509 running in VSS mode. I am trying to understand the benefit of having bridge assurance on the uplink ports.
If we have the command spanning-tree port type network enabled we cannot do a non disruptive upgrade. If there is bridge assurance on the uplink it warns you of this. Yet if I do not run bridge assurance on the uplinks I can do a upgrade without any disruption.
Why in god would I enable bridge assurance on this VPC link if I cannot do a non disruptive upgrade?
Please help me understand
I have attached a diagram showing the connectivity in question
Do the IOS version on your 6500 support bidge assurance?
To ensure that the STP can be run on low-end devices, the IEEE standard specifies that "the memory requirements associated with each bridge port are independent of the number of bridges and LANs in the network". This rule precludes the creation of adjacencies between bridges, as there can be an arbitrary number of peers connected to a particular port. On a particular segment, only the designated port ends up sending periodic BPDUs. Other peers can (and in fact are likely to) remain silent and no information is collected about them. As a result, there is no consistency check that can be applied to them either. The typical dangerous bridging behavior that makes the phrase "STP identify where not to send frames" (described in "Differences Between Routing and Bridging" section) thus also indirectly stems from that rule.
Bridge assurance is a very simple feature that introduces a counterpart to portfast configuration. With bridge assurance, a port can be now be classified in two categories:
•Edge ports—ports connected to end stations (existing portfast)
•Network ports—ports connected point to point to another bridge
This is not really an additional configuration burden. In order to reach their full potential, RSTP and MST already required a network with point-to-point links between bridges, and a strict identification of the edge ports.
Bridge assurance forces a bridge to keep sending BPDUs on a network port, even if it is not a designated port. Conversely, a network port expects receiving periodic BPDUs, even if it is designated. If no BPDU is received, the port stays in (or reverts to) a discarding state. Bridge assurance introduce stability in the network by making bridging closer to routing: a bridge is no longer forwarding traffic by default. The network port behavior can also be compared to Loopguard without its plug-and-play aspect. The main weakness of Loopguard was that it was not started until it had received at least a BPDU and detected a peer. Bridge assurance does not suffer from this problem as the existence of the peer is identified by configuration.
Note that this simple consistency check can only be implemented on point-to-point links because a bridge, contrarily to a router, has no way of sending traffic to a subset of its neighbors on a shared segment.
The normal setting allows keeping the current existing spanning tree behavior and will be necessary on shared segments or port connected to a bridge that does not support bridge assurance.
The recommended setting for bridge assurance is to consider all ports as network ports by default, using the following global configuration command:
•NX-OS—spanning-tree port type network default
•IOS—spanning-tree portfast network default
This mode will force the network administrator to visit the configuration of each port and help reveal the most common configuration errors (like non- identified edge ports, or bridge assurance not enabled on a neighbor). But most of all, it is safer to have spanning tree block too many ports than not enough and introduce discarding as the default port state enhances the overall stability of the network.
I also found this in the design doc for Nexus switches
The Bridge Assurance feature should not be enabled on the vPC member ports. Bridge Assurance does not add much benefit in a PortChannel-based configuration, and it may intervene in certain vPC failure scenarios in which it is actually less disruptive not to error-disable any port. Also, if you want to take advantage of In Service Software Upgrade (ISSU) on the Cisco Nexus 5000 Series, you should not enable Bridge Assurance on any link except the peer link (referred to as the multichassis EtherChannel trunk [MCT] in the command-line interface [CLI]) on which it is automatically enabled