- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- RSTP implementation - Do we really need to identif...
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
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
тАО09-30-2005 09:40 AM
тАО09-30-2005 09:40 AM
It talks about identifying non-edge ports and identifying which ports are edge ports so they immediately come online in forwarding mode. We've got hundreds of links between switches, many of which are not standardized for which ones uplink.
What is the simplest way to implement STP on a "flat"(?) network?
Could...it really be as simple as
"spanning-tree protocol-version rstp"
"spanning-tree"
?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-30-2005 10:24 AM
тАО09-30-2005 10:24 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Is there a way to easily identify a switch-to-switch link on HP 2600 series 8.53 firmware (other than "show mac" and looking for the port with the most ;-) )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2005 02:56 AM
тАО10-03-2005 02:56 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
No although we mostly set it to "Non-Edge" when it is indeed a Switch to Switch Link. Per 802.1W IEEE (RSTP) specification. When a port set to "Edge" receives a BPDU, it will loose it's "Edge Port" status.
So in a simple scenario where you only interconnect three Switches in a triangle with 802.1W enabled, leaving the defaults (Edge)will NOT result in a Layer 2 loop as the ports will "hear" the BPDUs on the inter switch link ports and therefore act as normal ports.
If wanted I can look up and send you the pages of interest from the IEEE 802.1W specs.
Regards, Ardon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2005 03:07 AM
тАО10-03-2005 03:07 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2005 03:43 AM
тАО10-03-2005 03:43 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
our links switch to switch are mostly gigabit (ports 25 or 26 on 2626 or 49 and 50 on 2650's) -- are you saying that it is possible for someone to create a loop and have that port lose its edge status and begin blocking?
I'd want the new link(which is 100mb) to be blocked
(99.9999% of our loops are users plugging in their network cable back to the wall jack which patches to wiring closet)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 02:19 AM
тАО10-04-2005 02:19 AM
SolutionLet me answer your latest posting step by step.
I reread your response -- you said when a port receives a BPDU, it loses its edge port status
our links switch to switch are mostly gigabit (ports 25 or 26 on 2626 or 49 and 50 on 2650's) -- are you saying that it is possible for someone to create a loop and have that port lose its edge status and begin blocking?
Ardon>Yes, and you should be glad as otherwise a Layer 2 loop WOULD occur. By looping two ports, the BPDU will get out and return to the Switch. This mechanism helps to identify loops and take them out by blocking a link.
I'd want the new link(which is 100mb) to be blocked
Ardon>I can not tell as I do not know the topology and configs you are using. Most of the time Blocking Links can be manipulated by setting STP Priority on the Switch and therfore the STP Root in the network.
(99.9999% of our loops are users plugging in their network cable back to the wall jack which patches to wiring closet
Regards, Ardon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 03:31 AM
тАО10-04-2005 03:31 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Secondary question to that is, if a port is blocked, can PCM+ Find ports that are blocked (aka looped) so that we can remove them from the network as we get around to it? (it wont cuase a disruption, but we still prefer to educate our users)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 09:27 AM
тАО10-04-2005 09:27 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Yes, the PCM network map shows STP blocked links as dashed lines.
You can also you a MIB browser to identify all STP blocked ports using the Bridge MIB (RFC 1493). Look for ports where the dot1dStpPortState is blocking(2).
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 09:29 AM
тАО10-04-2005 09:29 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 09:45 AM
тАО10-04-2005 09:45 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Sorry about your PCM problems :(
Regarding your other question. Yes, RSTP is smart enough to block a lower speed port.
There is a per-port "path-cost", where the lowest value is used to determine which ports are forwarding.
The following is the default path cost when using the auto option (recommended).
10 Mbps - 2,000,000
100 Mbps - 200,000
1Gbps - 20,000
Good luck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2005 09:53 AM
тАО10-04-2005 09:53 AM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Last question: the command spanning-tree point-to-point-mac force-false
How critical is it to identify the hubs? We have a great number of HP WL420's out there -- as well as just a few hubs, but most of our infrastructure is
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-05-2005 01:14 PM
тАО10-05-2005 01:14 PM
Re: RSTP implementation - Do we really need to identify non-edge ports?
Regarding the point-to-point-mac question:
It is not important to identify the hubs or the WL 420s, as long as you keep them as Edge Ports (the default).
It is recommended to set switch to switch links as "non-edge" to speed up RSTP convergence.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-06-2005 03:01 AM
тАО10-06-2005 03:01 AM