Do the IOS version on your 6500 support bidge assurance?
Bridge 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.
As mentioned in "Portfast (Edge Port)" section, the CLI has been enhanced to support bridge assurance:
•NX-OS—spanning-tree port type {edge [trunk], network, normal}
•IOS—spanning-tree portfast {edge [trunk], network, normal}
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.
More info:
HTH
