Procurve STP Priorities

[Jaredo]

Hello quick question. I plan on using STP to setup redundacy between our access and core layer. Our core layer will consist of 2 Procurve 2848s, which with a link to a access switch.

Core switch A, will have priority 0, while core switch B would have the next lowest priority.

I know with cisco the priorities have to be set in mutiples of 4096. Is there any such things with procurves? IE make Core switch A 0, and Core switch B 10 or similar.

Thanks

[Jaredo]

Here is a basic diagram of the proposal.

[RicN]

Procurve does the very same thing, i.e. setting the priorities in multiples of 4096, it is just a slightly hidden.

prio 0 = 0*4096 = 0
prio 1 = 1*4096 = 4096
prio 2 = 2*4096 = 8192

and so on.

So to your question, if you set the Core Switch B to priority 10, that would be 10*4096 = a very high priority = low probability to get elected root switch.

Use 0, 1 or 2 for the most preferred Procurve ones and set Cisco devices in the "true" form (4096, 8192..) for which switches you wish to be candidates for root bridge.

[Jaredo]

Great thanks.

[RicN]

You are welcome! Glad to be of any help!

And please assign points to posts that you find helpful. :)

[André Beck]

BTW,

there's no reason *not* to set both core switches to bridge priority 0. I usually do this after designating the box with the lower MAC as the intended more "rooty" one. This way, there cannot be a lower bidder in the topology. Especially helpful with some old DEC bridges at the periphery - some of them defaulted to 128 and cannot be set to values larger than 255 for the bridge priority.

BTW^2, the IEEE standard describing the split of the classic 16bit bridge priority into 12bit VID and 4bit remaining user configurable bridge priority for VLAN-unique bridge priority values is 802.1t. Everyone has to deal with it today.

HTH,
Andre.

[RicN]

>there's no reason *not* to set both core
>switches to bridge priority 0. I usually do
>this after designating the box with the
>lower MAC as the intended more "rooty" one.

How do you designate one of the core switches if you use prio 0 for both? Do you mean by physical placement?

>Especially helpful with some old DEC
>bridges at the periphery - some of them
>defaulted to 128 and cannot be set to
>values larger than 255 for the bridge
>priority.

Was the 128 and 255 "real" values, that is one of the values from 0-65535? The 128 as the default and 255 as maximum "feels" like is should be internaly multiplied with something, for example 256.


>the IEEE standard describing the split of
>the classic 16bit bridge priority into
>12bit VID and 4bit remaining user
>configurable bridge priority for VLAN-
>unique bridge priority values is 802.1t.

Is that used for MSTP or some other Spanning Tree method?

[Jaredo]

"How do you designate one of the core switches if you use prio 0 for both? Do you mean by physical placement?"

When switches are set the same priority, the switch with the lower MAC is choosen first.

So like he said, when you physically place the core switches, use the one with the lower MAC as the "primary" (Even though they have the same priority).

[André Beck]

Re,

> How do you designate one of the core
> switches if you use prio 0 for both? Do you
> mean by physical placement?

Yep, exactly. Jaredo brought it to the point: select the box with the lower MAC prior to any naming, tagging and physical placement so it can become the intended root. Often this isn't even necessary, as both switches will be identical to a high degree - it's not really relevant which one wins. In case of L3 and VRRP/HSRP on the switches the actual root should also become the VRRP/HSRP master, though, so it's good to stay in control. If there's ever a replacement, things may need a priority fix anyway.

> Was the 128 and 255 "real" values, that is
> one of the values from 0-65535?

Indeed it was. The number went into the least significant byte of the bridge priority word, the most significant byte was always zero.

> The 128 as the default and 255 as maximum
> "feels" like is should be internaly
> multiplied with something, for example 256.

No doubt - but I've seen those devices win against a switch using 4096+VID after 802.1t hit the streets, so it was really the worst case. Remember we are talking about devices from the first half of the 90s. IIRC the PEswitch900 had this issue, while newer DECswitch900 had 16bit bridge priorities in the later firmwares. Those were devices with a single port to FDDI (dual ring or tree) and six 10Base ports (the most stable and feature complete bridges between FDDI and Ethernet I've ever seen) - just to give you a feeling of how far back all this dates. Beeing as stable as they were, they used to still be around in the early 00s though.

> Is that used for MSTP or some other
> Spanning Tree method?

I've never groked why exactly that hack was necessary. When 802.1t was finally inlined into 802.1D-2004 (previously it was an amendment to 802.1D-1998) they added a note (9.2.5 NOTE 2) that essentially reads

---
This change was made in order to allow implementations of Multiple Spanning Trees (IEEE Std 802.1Q) to
make use of the 12-bit system ID extension as a means of generating a distinct Bridge Identifier per VLAN, rather than
forcing such implementations to allocate up to 4094 MAC addresses for use as Bridge Identifiers.
---

The note references 802.1Q which introduced VLANs but in fact never managed to standardize anything but Single Spanning Tree, it does however not mention MSTP at all. I assume it was something that seemed appropriate at the time, allowing different vendors to outfit their proprietary PVST solutions with per-VLAN bridge identifiers without wasting MAC addresses. MSTP doesn't need this given its small number of actually running spanning trees, but MSTP wasn't seen to be ready soon at the time (some consider the situation to not have changed significantly since then ;)

Andre.