Talk:Spanning Tree Protocol
This is the talk page for discussing improvements to the Spanning Tree Protocol article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 365 days |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
The contents of the Bridge protocol data unit page were merged into Spanning Tree Protocol on 2024-03-16. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
Explicit definition of "Segments"
editI think it might be useful to add a description of what "segments" on an ethernet network are. Nowadays, I think of things in terms of fully switched networks - whereas a network "segment" is a shared medium (thin ethernet over coax; twisted pair on an old hub) with many nodes and bridges on it. If you do not have a good understanding of this concept it's hard to grok the point of Designated ports.
Hmm, do dumb switches forward spanning-tree frames? If so, I guess a dumb switch would be considered a segment in this context.
If a bit about dumb switches is added, it would be prudent to add a note of caution. I've definitely seen cases where a dumb switch, or perhaps an intelligent switch that had STP disabled, has caused a broadcast storm when dually linked to a LAN running STP. User:Danpritts —Preceding undated comment added 19:50, 8 May 2013 (UTC)
- I have added links to network segment. I have also replaced occurrences of LAN segment with network segment. ~Kvng (talk) 02:05, 25 November 2023 (UTC)
RSTP as it's own
editI am reading a paper and didn't know what RSTP was, so I fed it into wikipedia search. Luckily, there is only 1 "RSTP" acronym so far as the "RSTP" page points here as well. RSTP had a 100% hit while Rapid Spanning Tree Protocol came in 2nd at 2.9%. I found my answer right there in the search results and immediately knew "oh, that's what RSTP" stands for. If it was hidden away in the Spanning Tree Protocol page... I don't think I would have found it as easily! ("Spanning Tree" has a 1.1% search result). I vote to keep the separate page and not merge, it is good to be categorized in "Network protocols" though. --BrianWiese 19:28, 20 March 2006 (UTC)
I also think this should be merged with STP
- remark by User:Jishnua
- please sign your comment, makes discussion easier ;-)
- In the current state, the articles could be merged... However, i had the idea to extend the RSTP en MSTP articles some day (or hoping someone else would do it). RSTP and MSTP are compatible and extensions of STP indeed, some parts of the text on protocol operations would be the same, or refer to the other article; however, an more extended description of the RSTP en MSTP protocol operation and properties would make de STP article lengthy, and maybe it IS usefull to have some "stand alone" description of the protocols. --LimoWreck 00:48, 14 December 2005 (UTC)
I agree!
Sergio
Yes, Do it!!
Yeah, I had no idea what is was...please add it, it fits well. Harry Cavallero
Merge Them
Most people will be looking for information on Spanning Tree, without realizing that in most network RSTP is the default version of spanning tree that is used. Both MSTP and RSPT should be merged into this article as the concept are very similar, and are evolutions on the basic STP protocol. By merging them together the reader will have the benefit of not only understanding the RSTP protocol, but the foundation of the protocol, and all related issues to do with it.
Sal Veya
Don't merge them - the mian article can explian the progression and the individual articles can provide more detail. Everyone is capable of clicking on the other pages. 195.195.0.77 14:27, 19 October 2006 (UTC)
The RSTP page IMHO is so short and mostly people will be looking for STP so I think they should be merged and if someday the RSTP section becomes so huge that it deserves individual article, people will call for that --krampo 14:00, 3 November 2006 (UTC)
Don't merge them, please. Like another user above, I came here looking for RSTP specifically, & I wasn't even sure of its expansion. I think it deserves a page of its own. --Arungoodboy 05:42, 5 December 2006 (UTC)
- Rapid Spanning Tree Protocol redirects to this article. ~Kvng (talk) 02:07, 25 November 2023 (UTC)
Algorhymes rock!
editPlease add more specifications like this. Very nice. =) STP was designed to monitor and control the Layer2 Network, it has different variations like RSTP,MSTP and PVST+.
yes for my career prospectus, please add RSTP, MSTP
yet another vote - merge the 3.
Problems in Article
editIn the opening paragraph of the article there is a sentence that doesn't make sense to me. However, I don't know enough about the topic to really correct it, so I'm hoping that by noting it here, somebody else can make the fix. The part I'm confused by is:
First, there would be a broadcast storm caused by broadcast packets looping. Second, the traditional source-based location system used by switches to operate correctly. The result of this would be to cripple the network.
The middle sentence is incomplete; it seems to be missing something. It's just a dangling subject, without an action. Anyone want to clue me in? If someone can give me the technical info I'll rewrite it, but I don't understand STP well enough to know what's being meant here. --Kadin2048 21:37, 1 November 2006 (UTC)
- The reference to broadcast storms in the article is arguably incorrect. The LAN is flooded as a result of bridge loops, but a "broadcast storm" is defined by IETF and Cisco as network flooding as a result of an incorrect broadcast packet. So mentioning it here suggests that the problem is more restrictive than it is, i.e., if you avoid broadcasting you won't have the problem. But that's not the case - the flooding occurs whether you have broadcasting or not. The incorrectness of the mac-address-table will also occur, but since that's a problem internal to the bridges and not likely to be understandable to a lay reader without considerable explanation, I think the introduction should restrict itself to flooding as the big problem with bridge loops. Ngriffeth (talk) 15:29, 11 April 2008 (UTC)
- At some point the article was changed to ues broadcast radiation terminology. ~Kvng (talk) 02:10, 25 November 2023 (UTC)
The Poem
editIs it just me, or do the links mess up the poem? I know wikifying stuff is the way, it just seems so out of place in the poem. Nichlas 15:13, 16 January 2007 (UTC)
Merge
editSince all of the articles discuss a form of the STP algorithm, they should be merged under one twiki page.
User: ftmkx
- Rapid Spanning Tree Protocol was merged. We still have a separate Multiple Spanning Tree Protocol article. ~Kvng (talk) 02:15, 25 November 2023 (UTC)
PortFast
editThere is no mention of Cisco's PortFast STP optimization in this article or elsewhere on Wikipedia. My understanding is that when enabled, PortFast puts a port into forwarding mode immediately after link is established. This gives end stations immediate connectivity at the expense of the possibility of a brief storm if the connection results in a loop. I believe the PortFast option was incorporated into the RSTP enhancement but I need someone to verify this before editing the article. Meanwhile, I've removed recent edit claiming that Blocking is the initial state for STP. While the statement is true for the original 802.1D, it needs some qualification given the above. --Kvng (talk) 13:31, 25 August 2008 (UTC)
- Still no discussion of portfast here or elsewhere on Wikipedia. ~Kvng (talk) 02:16, 25 November 2023 (UTC)
Merge from Bridge protocol data unit
edit- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- The result of this discussion was merge due to lack of discussion. OrdinaryGiraffe (talk) 23:22, 16 March 2024 (UTC)
Spanning Tree Protocol § Bridge protocol data units already appears to be more comprehensive than Bridge protocol data unit so the latter is likely not necessary. Anything not already covered here can be merged and Bridge protocol data unit turned into a redirect. ~Kvng (talk) 14:30, 20 August 2023 (UTC)