Talk:Network switch

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking / Hardware (Rated C-class, High-importance)
WikiProject icon 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.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Top-importance).
Taskforce icon
This article is supported by Computer hardware task force (marked as Mid-importance).
edit·history·watch·refresh Stock post message.svg To-do list for Network switch:

There are no active tasks for this page
    • Remove repetition
    • Merge content to Multilayer switch
    • Improve organization
    • Add historical information

    De-facto meaning[edit]

    While WP drowns in technical details, the current article doesn't describe what's the difference between a switch, a hub and a bridge. The devices are different de facto, my CompTIA Network+ book (ISBN 978-0-7897-3796-0) claims that switches are smart hubs that redirect a traffic session only to the intended host. A bridge is, according to the book, more limited: it decides whether to block or let through data traffic from one network to another.

    I think the intro and Function section are confused about the function. Functionally a switch is used as a junction connecting computers in a network, while a bridge is used to connect (usually only) two networks. Rursus dixit. (mbork3!) 16:12, 7 August 2011 (UTC)

    Clarifying myself: those things are mentioned, but not initially where they should be, and mostly drowning in techspeach ("operating at OSI 2 layer") obscuring the essence of the usage. The text needs shuffling, so that the article starts with the function and the usage, then the jargon can escalate step-by-step to make us nerds drool. Rursus dixit. (mbork3!) 16:21, 7 August 2011 (UTC)
    I agree that there is too much jargon in the lead. I do not, however, see any technical issues. The idea of a bridge as a two-port device dates back to when Ethernet networks were built with coax or hubs. Now that these are gone, we have to update our terminology. The 802.1Q standard defines layer 2 switch behavior and "bridge" is the terminology used throughout. --Kvng (talk) 16:19, 11 August 2011 (UTC)
    I agree that terminology has to be updated, but jargon sometimes evolves into common technical meaning different to the technical standards. Can a non-blocking packet switch be fairly described as a bridge, or even a switching hub? "Switching hub" is as obsolete as the original thin-net bridges -- and both terms belong in a history section instead of the intro. "Bridge" is still used to describe point-to-point wireless devices, which could be a useful comparison since they don't switch packets they just send them through to the other end of the link. A laymans description of the Layer 2 concept should still be in the intro because thats the core of its definition. Maybe intro could say: "Switches send data between devices physically connected to them, with basic ones being unaware of the data's final destination or internet address". Webwat (talk) 03:34, 13 October 2013 (UTC)
    I think we'd all need to take a look on how these devices do their job – simply looking at what they do quickly blurs the distinction between repeaters, bridges and routers. What is commonly called "switch" is per definition (IEEE 802.3) a multiport bridge. What does a bridge do? A bridge takes a decision based on the destination's MAC address. A simple two-port device just decides whether it forwards a given frame or not. A multiport bridge makes this decision for each port it's got, essentially deciding where to forward it to.
    In this line of thought, a repeater (hub) does not take any decision, and a router's decision is based on layer 3 information (commonly the IP address). Zac67 (talk) 10:16, 13 October 2013 (UTC)

    Types of switches[edit]

    Hello, Switchguy and Agentjulian! Regarding the addition to the Network switch § Types of switches section, we should discuss here so it doesn't unnecessarily turn into WP:EDITWARRING. I've compared the content of the blog entry with what this article already contains, and everything is pretty much already covered – managed, unmanaged, PoE, L2, L3, etc. Please have a look at the article as a whole, and I'm sure you'll agree that some radical changes (and the note) are not required. — Dsimic (talk | contribs) 21:57, 26 October 2014 (UTC)

    Agreed – dumping an external link doesn't improve the article. Looks rather like link spam even though the linked source is at least partially unbiased. Zac67 (talk) 22:25, 26 October 2014 (UTC)

    I fully agree we should discuss this here. And "Zac67", this is EXACTLY about improving the content which is not 100% as it stands now, and the reason I added the link is it is more accurate and current. The body of the document, which most people read, needs to be reliable and up-to-date - links at end is not so important as that is not what most people would review. We don't need the link in the body of the article if the article is correct, but as it stands it is old. Here's the issues (reflected nowhere in the wikipedia entry especially not in this section):

    1) Under Smart Switches, comments shown here shows "they provide a web interface (and usually no CLI access) and allow configuration of basic settings, such as VLANs, port-bandwidth and duplex". This info is at least a few years old as evidenced by HP, Cisco, Netgear, D-Link, Huawei, or pretty much anyone else's portfolio. Even the link there is from 2007 - a lot has changed since then by all the vendors I mentioned above. You can even find Stackable Switches in the Smart Switch category today. A better description is provided in the blog, the core message being that they have evolved to support a whole lot more - in all areas including Management, Security, QoS, Scalability, etc. All the vendors I mentioned above support ACLs, CLI, SNMP/RMON, 802.1x, and a whole lot more. Pull up one of their datasheets and this becomes very clear. The message is that, while they have these things, it does not scale as large, provide the same levels of configuration knobs and levers, is simpler, more cost-effective than Managed Switches

    2) Unmanaged Switches - people need to know what is possible with this category as well. Nowhere in the article does it say that it is now possible to get things like "cable diagnostics, prioritization of traffic using default QoS settings, Energy savings capabilities using EEE (Energy Efficient Ethernet) and even PoE (Power Over Ethernet).". Again, datasheets from any of these vendors show this to be the case

    3) Here's the description of Managed Switch in the article - "these have a full set of management features, including CLI, SNMP agent, and web interface. They may have additional features to manipulate configurations, such as the ability to display, modify, backup and restore configurations". There are many Smart Switch on the market today can do this, so should not be used as a differentiator for Managed. Can use instead "The scalability, levels of security, capacity, feature sets to optimize uptime, user and application control, goes far beyond what Smart Switches have to offer, where the emphasis is around ease-of-use and value."

    4) This is a section about "Types of switches", so this is the place where the rest of the article needs to be pulled together. A person can go out and buy for example a "Managed Switch with 24 ports of Gigabit with 4 ports of 10-Gigabit uplinks with POE", or they will buy a "48-port 10/100 Smart switch without POE", or an "8 port Unmanaged switch". The idea is that people need to be aware that, at the end of the day, this is what I can buy, use, or deploy. Right now, we talk about all these different features/functions (layers, features, places in the network, etc) in an abstract way and I'm not sure everyone is clear on what is a real deliverable. Maybe a missed opportunity? Or maybe a clear area to improve.

    5) I only focused on this one section. Another comment for improvement elsewhere int he document: - What makes it a layer 3 switch is not only that it operates at L3 (a router does that too), but that it does its forwarding in silicon at wire speed - a router does it in CPU which makes it's performance of a different scale and of particular value in the campus. This should be mentioned in the article. — Preceding unsigned comment added by (talk) 00:13, 27 October 2014 (UTC) BTW, previous comment was by me "Switchguy" — Preceding unsigned comment added by Switchguy (talkcontribs) 00:16, 27 October 2014 (UTC)

    Please check WP:NOT since you seem to be new to WP (welcome by the way!). Your input is appreciated but updates and changes need to be incorporated in the text that people read, using reliable sources where appropriate. The link style was bad as it was done and didn't improve the text at all, rather refer to somewhere else. Your objections are (mainly) valid but we need to improve the text here and not build a link list to refer elsewhere. Please be aware that this article tries to cover the general topics and not mirror the very latest advances in the industry nor focus on a certain manufacturer's philosophy. If we're able to compile a to-do list with outdated or incomplete info we'll surely all benefit. Zac67 (talk) 11:18, 27 October 2014 (UTC)

    Switchguy - some more - Port options available(how many ports), better content on POE(major selection criteria),Stacking? — Preceding unsigned comment added by Agentjulian (talkcontribs) 21:20, 27 October 2014 (UTC)

    The common goal is to improve this article and that should be clear from my comments. There is no intention to push any agenda here - all my comments are relevant to just about every vendor in the market. We can remove all references to all vendors or any vendor's products. The problem is that 7 year old information is as good as a lifetime in the Networking industry. The goal from the get-go was to freshen up the content, which means either the section has to be rewritten or link to something which is accurate. So consensus is rewrite the section. We can rewrite this section here (in this "talk" section) and then update the article after, rather than going back and forth rejecting each other's edits in the main article. The dialog needs to be more constructive and fact-based rather than comments like "dumping", "spam", "partially unbiased", "objections (mainly) valid" - I can provide "reliable sources" for every comment I made. If you want, I will post URLs for the different vendor's products. To move this exercise forward and, If you guys want, I can take a first shot at it and then the community can edit before posting it live. Probably won't have time until the weekend at least. — Preceding unsigned comment added by Switchguy (talkcontribs) 05:58, 28 October 2014 (UTC)

    Sounds good to me, please go ahead as you've described it. — Dsimic (talk | contribs) 16:05, 28 October 2014 (UTC)

    Content proposal[edit]

    My first pass - comments/edits welcome:

    The most basic switch you can buy is an Unmanaged Switch. Devices (PCs, Printers, Wireless Access Points, Servers, IP phones, Storage, Surveillance cameras, other Switches, and many others) can be connected to these switches and it will provide connectivity between all of these devices. This connectivity is very basic however. Unmanaged switches are not manageable (except for a few corner case options in the market) - i.e. you cannot connect to the switch from a PC or some external device and change its configuration and operation. The most advanced Unmanaged switches in the market have a pre-set QoS (Quality of Service) mapping table where packets that are received on the switch with L2 QoS (802.1p) or L3 QoS (DSCP, TOS, or IP Precedence) are prioritized and treated differently based on this table. This allows the network administrator to set priorities on the endpoints or applications and have the switches in the network automatically enforce that priority. That way, voice traffic is not degraded when there is an unusual burst of data traffic in the network. It is important to note that you have no flexibility with Unmanaged switches. Endpoints must be set to match the mapping table in the switch or you will not get the desired effects. You also do not have the visibility into things which are good for troubleshooting like a way to tell how many packets have been treated as high priority versus low, or a means to change any settings on the switch. The more advanced Unmanaged Switches also come with EEE (IEEE 802.3az) for Energy Efficiency and also a few with POE (power over Ethernet). Unmanaged switches are the most cost-effective in the market and you can generally find them in port configurations ranging from 4 ports to 24 ports and in 10/100, Gigabit Ethernet, and 10 Gigabit Ethernet options. They come in desktop and rack mount configuration options. They work well in environments which are very simple (plug and play) such as anywhere you need a few extra ports with minimal control - conference rooms, at home, in a lab, very small office, etc.

    Smart Switches (also called Smart Managed or Lightly Managed Switches) is the next tier up from Unmanaged Switches. These switches add much more flexibility to the network. They are configurable and offer much more capabilities. They allow you to segment your user population into workgroups which are isolated from each other using VLANs. They add capabilities to secure the network, preventing unauthorized users from connecting to the network (using IEEE 802.1x). Additionally, newer Smart Switches allow you to disallow certain users from accessing certain applications while others can access the same applications using ACLs (Access Control Lists).

    Smart switches allow you to configure QoS according to your network or application needs. The switches can either trust the settings which have been set by the endpoints, or re-mark these per network policy requirements. These switches are a better fit for Voice and Video environments than the Unmanaged switches. They offer a simple, easy-to-use Web management interface as a standard feature. You can also find some Smart switches supporting management via CLI and/or SNMP/RMON as well. You can find Smart switches in the market in port configurations generally ranging from 5 ports to 48 ports and in 10/100, Gigabit Ethernet, and 10 Gigabit Ethernet options. Switches can be purchased with/without Power over Ethernet (POE). They can also be purchased with copper or fiber ports on them. There are even a few supporting Stacking. Smart Switches come in desktop and rack mount configuration options. The most optimal deployment scenarios for Smart switches is 1) as the infrastructure for small, simple networks, 2) where cost is a key consideration, or 3) at the edge of a larger network where a Managed switch is used in core.

    Managed Switches (also called Enterprise Managed) are the next tier up from Smart Switches. Here, the focus is on platforms which can enable any application, scale to very large networks, maximal uptime, together with the Security, QoS, and Management options to make all of this possible.

    Managed Switches can flexibly be deployed in the Network Centre (or Core), Aggregation layer, or Access layer. If the core of a network goes down, the whole network is affected. Therefore, Managed switches offer many capabilities to ensure the network remains up. This includes elements of protecting the switch CPU (with control plane policing), protecting the layer 2 domain (with items such as Spanning Tree Root and BPDU Guard), Denial of Service (DoS) Attack prevention, and Layer 3 First Hop Security with capabilities such as VRRP, HSRP, and GLBP.

    Managed switches scale far beyond Smart Switches. They have larger tables (for MAC addresses, VLANs, Link Aggregation Groups, IP routes or interfaces, Multicast groups, etc), ACLs, more hardware queues, etc. All capabilities are deeper with more knobs and levers to enable, control, and troubleshoot them. Some of the Management options include a full CLI, HTTP/S Web Interface, SNMP/RMON, and discovery through LLDP, CDP, and Bonjour. It may also include Netflow, SFlow, IPFIX, and other Performance Management protocols.

    Then there is Security. Managed switches offer First Hop Security (ARP Inspection, IP Source Guard, DHCP Snooping) and their IPv6 equivalents. They offer Policing and shaping of traffic. They also offer the capacity to drop traffic by L2, L3, L4 address or TCP/UDP port, physical port, and a lot more. The Management traffic is also secured with things like SSH, SCP, HTTPS, SNMPv3, and external authentication via Radius/TACACS.

    For better application control, there is more options for unicast and multicast traffic. For Multicast, there is IGMP Querier (for IPv4), MLD Querier (for IPv6) and Proxy functions added to the Snooping capabilities. For unicast, more queues, flexible assignment of traffic to queues, Accounting, and much more. The discovery of voice endpoints and traffic coupled with the QoS mechanisms built into the switches, make them the best option for IP voice deployments. They may also include dynamic unicast or multicast protocols such as OSPF, BGP, RIP, EIGRP, PIM and others.

    While you can find a few stackable Smart switches in the market, Stacking (link to Stacking) tends to be the domain of Managed Switches. The reason for this is that, since a stack of switches tend to be a large concentration of ports and users, the scalability, security, availability, and instrumentation offered by Managed Switches is essential for successful deployment and operation of the stack.

    Managed switches can also come in a Modular platform configuration. Modular switches tend to consist of a chassis which houses blades or cards delivering different interfaces/port options, application modules, power supplies, cooling fans. The idea being that you add new modules into the chassis as you grow or as the technology changes.

    You can find fixed Managed switches in the market in port configurations generally ranging from 5 ports to 48 ports and in 10/100, Gigabit Ethernet, 10 Gigabit Ethernet, and 40/100 Gigabit options. They come in desktop and rack-mount configuration options. Switches can be purchased with/without Power over Ethernet (POE). They can also be purchased with copper or fiber ports on them. With Modular switches, you purchase a chassis with several open slots. You then also have to purchase interface modules housing your physical interfaces (copper or fiber), modules for applications (like Firewall, Intrusion Detection, VPN, Wireless, or Performance Analysis), Supervisor modules (brains of the switch), power supplies, and cooling fans. — Preceding unsigned comment added by Switchguy (talkcontribs) 03:29, 3 November 2014 (UTC)

    Comments on the proposal[edit]

    • Switchguy, thank you for putting it together. Would all this be supposed to go into the Network switch § Types of switches section? Speaking right off the bat, it would require some work to meet the style required by Wikipedia; please don't get me wrong, but did you have a chance to have a look at the Wikipedia's Manual of Style? For example, the second person ("you", "your") isn't supposed to be used as it sounds like suggesting what's only to be described; please see MOS:YOU for more details. — Dsimic (talk | contribs) 08:23, 3 November 2014 (UTC)
    Dsimic - please go ahead and make any edits you deem necessary. — Preceding unsigned comment added by Switchguy (talkcontribs) 19:02, 3 November 2014 (UTC)
    There's quite some work required, I'll see to do that in the next three or four days. — Dsimic (talk | contribs) 00:19, 4 November 2014 (UTC)


    Can someone summarize what's going on here? I've marked Network switch § Types of switches with {{Prose}}. I hope that's what we're trying to address. I don't see any evidence of a potential edit war so please be bold and put proposed changes directly into the article. ~KvnG 00:21, 8 November 2014 (UTC)

    Lead cleanup[edit]

    Problems I have identified in the lead:-

    1. It fails to summarise key aspects of what a "switch" is or does.
    2. It contains too much technical information.
    3. The lead is messy. For instance, it contains three or four different names for the switch.
    4. Some of the content in the overview could be moved to the lead section to help summarise the subject.

    Things I have done to correct this:

    • Moved some of the technical content to the overview section, under a new subsection called Technical Details.

    Things I recommend to be done:

    1. Complete rewrite of the lead and to incorporate some of the content from the overview section.
    2. Remove the many different names for the switch in the lead and maybe create a new (sub)section that explains the different naming.
    3. The lead should give a general overview of the topic and avoid too much technical information. A little bit of technical information can be OK if it explained correctly, or can be understood by a broad audience.
    4. Move the content outlining the difference between a switch and a hub to a new subsection.

    --Hrbm14 (talk) 01:51, 5 February 2015 (UTC)

    Hello! Well, the lead section clearly says that "a network switch [...] is a computer networking device that connects devices together on a computer network, by using a form of packet switching to forward data to the destination device" – please don't get me wrong, but how could that be made more understandable to Joe Averages? If we wanted even simpler words, we could only say that it's a device with multiple square holes one plugs some cables into, and all that just to be able to login into Facebook. :) The article is technical, that's what it is. — Dsimic (talk | contribs) 23:02, 10 February 2015 (UTC)
    Firstly, I would like to thank you for your feedback. I understand that this topic has to be inherently technical. My concerns was that the lead did not give a complete summary of the topic and, therefore, the technical content did not flow properly.
    I have included a draft copy of a lead that might be better. Please feel free to make amendments as you see fit. The following things were changed:-
    1) Removed "a form of". It is cleaner to write, "... Switches use packet switching" rather than "Switches use a form of packet switching". The words, "a form of" are, in my opinion, redundant.
    2) Cleaned up the explanation relating to the "hub verses switch".
    3) Other clean ups.
    The revised lead is here. I posted it here to get feedback first.
    A network switch (officially MAC bridge[1]) is a computer networking device that receives, processes and forwards data to destination device(s) using packet switching. Unlike network hubs, switches only send the received data to the device that requests it.[2] Multilayer (or layer-3) switches are those switches which have the capability of routing the packets based on IP addresses.[3]
    Ethernet Switches (sometimes also known as a switching hubs, bridging hubs or a MAC bridges) that operate at the data link layer of the OSI model process and forward Ethernet frames based on the source and destination MAC address stored within the header of the frame. The first Ethernet switch was introduced by Kalpana in 1990.[4]. Switches also exist for various other types of networks including; Fibre Channel, Asynchronous Transfer Mode and InfiniBand.
    Thanks, --Hrbm14 (talk) 01:51, 11 February 2015 (UTC)
    You're welcome, and thank you for your contributions in the first place. Speaking of your proposal, unfortunately some of the details were lost in the process; for example, technically speaking, receiving device doesn't request or ask for anything to be forwarded to it, it's more about either the sending device initiating the forwarding of packets, or forwarding them due to the switch configuration. Also, we shouldn't limit the description to Ethernet switches, no matter how common they are. Went ahead and incorporated some of your changes into the lead section, together with some other improvements – please check it out. — Dsimic (talk | contribs) 06:55, 11 February 2015 (UTC)


    1. ^ IEEE 802.1D
    2. ^ "Hubs Versus Switches — Understand the Tradeoffs" (PDF). 2002. Retrieved 2013-12-10. 
    3. ^ Thayumanavan Sridhar (September 1998). "Layer 2 and Layer 3 Switch Evolution". The Internet Protocol Journal. Cisco Systems. Retrieved 2014-08-05. 
    4. ^ Robert J. Kohlhepp (2000-10-02). "The 10 Most Important Products of the Decade". Network Computing. Retrieved 2008-02-25. 

    Internal Operation Clarification[edit]

    Hello. In the Network Design section, the statement

    Each device connected to a switch port can transfer data to any of the other ones at a time, and the transmissions will not interfere

    is vague. Apprecitate the non technical attempt to address the internal operations without reaching into techno speak. However, me (Joe Average) still does not understand exactly how data transfers between ports on the internal switch ethernet bus, but still detect and arbitrate collision. For example, the connection between NIC and switch port is a dedicated ethernet and no collision should ever happen. But, if the bus within the switch is active, then collision will happen and block (right?). Thanks! — Preceding unsigned comment added by (talk) 15:11, 27 October 2015 (UTC)

    In a fully switched segment no collisions can occur if all devices support full duplex operation – a switched segment is not a bus in that respect. A non-blocking switch (standard since late 1990s) supports passing data into and out of all ports simultaneously without interference. --Zac67 (talk) 17:47, 27 October 2015 (UTC)

    Okay, so then I guess that the definition of "network segment", aka "collision domain" within the switch is unclear (to me, sorry). Would the following conceptual definition add correct details, or be misleading?

    There are n ethernet buses / network segments / collision domains within the switch, where n is an unsigned integer not 0. Assuming full-duplex, two communicating ports connect to the same ethernet bus / network segment / collision domain. When multiple ports attempt silmutaneous communication with the same destination port, collision detection arbitrates the bus.

    Or, would the second port attempting to communuicate with the same destination port wait until the destination port is idle, then establish a new collision domain, or possibly reuse the old one?

    I assume that this would be a typical situation for the destination port being an uplink port (maybe a 10 gigabyte ethernet, and the source ports (all gigabyte ethernet) being connected to single interface hosts. — Preceding unsigned comment added by (talk) 16:29, 1 November 2015 (UTC)

    A switch/bridge always separates collision domains, ie. each port with a half-duplex connection relying on CSMA/CD. It does so by buffering any incoming frame and forwarding it as soon as the destination port is idle.
    In contrast, repeater hubs can't buffer anything, so they must repeat incoming data immediately to the other ports – any collision happening anywhere must disrupt data transfer, so a collision domain always spans across a repeater/hub.
    Full-duplex switched links consist of two independent media (technically each a collision domain), each with a single transmitter and a single receiver, so no collision can ever occur. --Zac67 (talk) 17:01, 1 November 2015 (UTC)
    Packets flying around in the internal bus of a non-blocking switch between ports do not interfere with each other because to bus has sufficient bandwidth to handle incoming packets from all ports simultaneously. Packets can interfere with each other on the egress ports; If two packets from different ingress ports are destined to the same egress ports, one of them is going to go first and the other will be held in switch buffer memory and will be delayed. ~Kvng (talk) 11:39, 6 November 2015 (UTC)

    Merge from LAN switching[edit]

    This content could be used to improve the Layer-specific functionality section here. I do not see a good reason for there to be a separate article on this sub-topic. ~Kvng (talk) 15:39, 31 December 2016 (UTC)

    Support – see no reason for a separate article; devices and functionality aren't easily separated. --Zac67 (talk) 17:37, 31 December 2016 (UTC)

    I support moving the article aswell. Many people read the article because they do not know the difference betweeen LAN and WAN switch, or level 2 and level 3 switch... That is why the are reading the article. =Carl Stenquist