Talk:VLAN

message: I don't think the following statement is correct: 
Section: Protocols and design
:" When Ethernet switches made this a non-issue (because they have no collision domain) ... " 
Switches do have a collision domain. Right?
-Manavkataria 14:40, 30 August 2007 (UTC)
replies: text: No collision domain, but do have broadcast domain. 64.39.108.99 (talk) 01:00, 22 February 2008 (UTC)

text: They do have collision domains, one on each port. Pgallert (talk) 16:25, 29 April 2008 (UTC)
replies: text: if the links are all full duplex (which most if not all switches support) then there are no collision domains. 02:17, 30 April 2008 (UTC)
replies: text: Yes, there are. As Pgallert said, there's one per port. If two hosts simultaneously send a packet to a third there is a collision at the port servicing this third host. 94.196.36.230 (talk) 23:02, 3 December 2009 (UTC)
replies: text: No, post on 30 April 2008 is correct. If two hosts simultaneously send a packet to a third, there is no collision, the packets are queued up.  That is the fundamental difference between switches and hubs.13.13.16.2 (talk) 22:16, 22 May 2012 (UTC)
replies: text: This is not the difference between switches and hubs. Hubs are dumb devices, in that there is no logic behind the way it forward L2 franes; its basically just an electrical device.  It receives a frame on one port and floods the frame out all other ports.  Hubs are not capable of full duplex line speeds, meaning it cannot send and receive at the same time.  The Carrier sense multiple access with collision detection algorithim was designed to detect collisions and proceed in the event of a collision.  Switches do have collision domains, they just are far less likely to occur because of full duplex line speeds and the basic logic by which switches operate.  They perform a lookup against a MAC address table, and only forward the frame out the link for which it has a MAC address entry.  If no entry exists, it floods the frame the same way a hub would.  MAC entries are added when the switch receives a frame with a source MAC it doesn't have an entry for. Getting back to collision domains though, they can't, or shouldn't occur when only 1 device is connected per port, but can occur over links with more than one host attached (like between switches) and even this is only possible if the link is functioning at half-duplex for some reason instead of full-duplex.  ...nubs ;-) 68.32.133.168 (talk) 06:22, 8 November 2016 (UTC)
replies: text:  You might want to read up on how a switch works. The essential difference is that a repeater cannot buffer anything while a switch can buffer (so many) frames and queue them on the outbound ports. With a switch and all ports in half-duplex, there's a collision domain on each port, ie. if there is a collision while the switch tries to send, the switch will retry the packet and not the initial sender as with a hub. --Zac67 (talk) 07:38, 8 November 2016 (UTC)
thread_title:  Switches Have No Collision Domain? 

message: This sentence needs editing: "Both ISL and IEEE 802.1Q tagging perform explicit tagging as the frame is tagged with VLAN information explicitly." - Dougher (talk) 05:39, 23 July 2008 (UTC)
replies: text: So does this one: "By definition, switches may not bridge IP traffic between VLANs as it would violate the integrity of the VLAN broadcast domain." What is meant by the word "it"? If "it" means "doing so" then that's what it ought to say. 94.196.36.230 (talk) 23:07, 3 December 2009 (UTC)
replies: text: The first sentence you could possibly replace "tagging" with "protocols" and replace "VLAN information..." with "VLAN ID's", ending the sentence there; They have already mentioned that frames are explicitly tagged earlier.
The second sentence I don't have a problem with as I think its more an issue of preference or style than clarity or grammatical acuity;  'It' refers to 'bridging IP traffic'. 68.32.133.168 (talk) 06:40, 8 November 2016 (UTC)

text: I have made some improvements to the first sentence. I no longer find the second in the article. ~Kvng (talk) 17:01, 26 December 2021 (UTC)
thread_title:  Unwieldy sentence 

message: In the article a sentence saying that ISL is no longer supported by cisco has a line through it. Could somebody check to see if it is true, and either remove the sentence entirely or remove that formatting based on whether or not it is?173.95.137.49 (talk) 20:40, 4 August 2009 (UTC)
replies: text: This is probably best discussed at Cisco Inter-Switch Link which says it is deprecated, in agreement with the summary in . ~Kvng (talk) 17:01, 26 December 2021 (UTC)
thread_title:  Is ISL supported by CISCO? 

message: @FT2: While I appreciate your recent edits, the "software" part is problematic. It suggests that VLANs are realized in software which isn't the case. Any objections changing that to something in the line of "(additional) logic"? --Zac67 (talk) 16:53, 30 April 2017 (UTC)
replies: text: I think there's room for improvement in those contributions. Please make some WP:BOLD changes and we'll see how it looks. ~Kvng (talk) 13:49, 3 May 2017 (UTC)
replies: text: Thanks for the feedback – I went ahead and made a few other fixes and updates on the way. --Zac67 (talk) 18:19, 4 May 2017 (UTC)
thread_title:  "physical object recreated in software" 

message: I removed the following from the end of the History section. 
 reverted noting that, "SPB is another protocol for handling VLANs." And that's true, at least according to material in . I've looked more closely and found that the relationship of SPB to VLANs is that SPB supports the pre-existing IEEE 802.1ad and IEEE 802.1ah-2008 improvements to original IEEE 802.1Q VLANs. SPB did not introduce these concepts. I have again removed the WP:PEACOCKY SBP paragraph and added information about IEEE 802.1ad and IEEE 802.1ah-2008 to the History section. ~Kvng (talk) 14:35, 10 September 2018 (UTC)
replies: text: SPB is something I definitely have to dive deeper into, but even though its VLAN handling is compatible to 802.1ad and 802.1ah it is not the same and more flexible. The link-state based 'routing' approach is definitely a giant leap in L2 technology, comparable to the invention of the Ethernet switch. Shame though that adoption of SPB is still slow... Anyway, thanks for handling this in an excellent way. ;-) --Zac67 (talk) 14:58, 10 September 2018 (UTC)
replies: text: As you look into this you may notice that there were a lot of SPB mentions and links added to network articles around the time SPB was published. This was overdone in some instances and this appears to me to be one of these. ~Kvng (talk) 15:45, 10 September 2018 (UTC)
thread_title:  SPB and VLANs 

message: :The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion. 
The result of the move request was: moved. (non-admin closure) NW1223<Howl at me•My hunts> 15:05, 5 May 2022 (UTC)
replies: text: Virtual LAN →  – VLAN is the WP:COMMONNAME by far, see Google Ngram. Per MOS:ACROTITLE, "Acronyms should be used in a page name if the subject is known primarily by its abbreviation and that abbreviation is primarily associated with the subject". There is no other notable subject named VLAN. PhotographyEdits (talk) 09:35, 28 April 2022 (UTC)

text: No objection, but the mover must commit to handling all the post move clean-up.  See WP:POSTMOVE/ Constant314 (talk) 12:51, 28 April 2022 (UTC)
replies: text: That's fine for me. PhotographyEdits (talk) 12:54, 28 April 2022 (UTC)

text: Re this one could be called virtual local area network – there's a disambiguation page Lan which Vlan doesn't need. --Zac67 (talk) 04:55, 29 April 2022 (UTC)
thread_title:  Requested move 28 April 2022