- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Procurve STP Priorities
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-27-2009 08:52 AM
тАО01-27-2009 08:52 AM
Procurve STP Priorities
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-27-2009 08:53 AM
тАО01-27-2009 08:53 AM
Re: Procurve STP Priorities
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-27-2009 01:57 PM
тАО01-27-2009 01:57 PM
Re: Procurve STP Priorities
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-27-2009 01:59 PM
тАО01-27-2009 01:59 PM
Re: Procurve STP Priorities
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-27-2009 02:03 PM
тАО01-27-2009 02:03 PM
Re: Procurve STP Priorities
You are welcome! Glad to be of any help!
And please assign points to posts that you find helpful. :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 03:46 PM
тАО02-11-2009 03:46 PM
Re: Procurve STP Priorities
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 11:51 PM
тАО02-11-2009 11:51 PM
Re: Procurve STP Priorities
>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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-12-2009 06:03 AM
тАО02-12-2009 06:03 AM
Re: Procurve STP Priorities
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-12-2009 11:51 AM
тАО02-12-2009 11:51 AM
Re: Procurve STP Priorities
> 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.