Talk:VLAN

This is the talk page for discussing improvements to the VLAN article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 365 days

Computing: Networking / Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).
	This article is supported by WikiProject Software (assessed as Low-importance).

On 28 April 2022, it was proposed that this article be moved from Virtual LAN to VLAN. The result of the discussion was moved.

Switches Have No Collision Domain?

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)[reply]

No collision domain, but do have broadcast domain. 64.39.108.99 (talk) 01:00, 22 February 2008 (UTC)[reply]

They do have collision domains, one on each port. Pgallert (talk) 16:25, 29 April 2008 (UTC)[reply]

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Unwieldy sentence

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Is ISL supported by CISCO?

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)[reply]

This is probably best discussed at Cisco Inter-Switch Link which says it is deprecated, in agreement with the summary in Virtual LAN § Cisco Inter-Switch Link. ~Kvng (talk) 17:01, 26 December 2021 (UTC)[reply]

"physical object recreated in software"

@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)[reply]

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)[reply]

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)[reply]

SPB and VLANs

I removed the following from the end of the History section.

In 2012, the IEEE approved IEEE 802.1aq (shortest path bridging) to standardize load-balancing and shortest path forwarding of (multicast and unicast) traffic allowing larger networks with shortest path routes between devices. In 802.1aq Shortest Path Bridging Design and Evolution: The Architect's Perspective David Allan and Nigel Bragg stated that shortest path bridging is one of the most significant enhancements in Ethernet's history.^[1]

Zac67 reverted noting that, "SPB is another protocol for handling VLANs." And that's true, at least according to material in Virtual LAN § Shortest Path Bridging. 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)[reply]

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)[reply]

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)[reply]

References

^ Allan, David; Bragg, Nigel (2012). 802.1aq Shortest Path Bridging Design and Evolution: The Architects' Perspective. New York: Wiley. ISBN 978-1-118-14866-2.

Requested move 28 April 2022

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)[reply]

Virtual LAN → VLAN – 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)[reply]

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)[reply]

That's fine for me. PhotographyEdits (talk) 12:54, 28 April 2022 (UTC)[reply]

Support Per nom. ᴢxᴄᴠʙɴᴍ (ᴛ) 16:34, 28 April 2022 (UTC)[reply]
Support --Zac67 (talk) 04:55, 29 April 2022 (UTC)[reply]
Comment LAN is located at local area network, and if were were to be consistent with that article, this one could be called virtual local area network -- 65.92.246.142 (talk) 04:36, 29 April 2022 (UTC)[reply]

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)[reply]

Support per nom.--Ortizesp (talk) 16:36, 29 April 2022 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

[1] Allan, David; Bragg, Nigel (2012). 802.1aq Shortest Path Bridging Design and Evolution: The Architects' Perspective. New York: Wiley. ISBN 978-1-118-14866-2.

[1]