Talk:Network switch

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Types of switches[edit]

Article has been reorganized so presumable this is all taken care of ~Kvng (talk) 16:12, 3 April 2020 (UTC)[reply]

The following discussion 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.

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

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

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 68.99.186.1 (talk) 00:13, 27 October 2014 (UTC) BTW, previous comment was by me "Switchguy" — Preceding unsigned comment added by Switchguy (talk • contribs) 00:16, 27 October 2014 (UTC)[reply]

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

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

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 (talk • contribs) 05:58, 28 October 2014 (UTC)[reply]

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

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 (talk • contribs) 03:29, 3 November 2014 (UTC)[reply]

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)[reply]
Dsimic - please go ahead and make any edits you deem necessary. — Preceding unsigned comment added by Switchguy (talk • contribs) 19:02, 3 November 2014 (UTC)[reply]
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)[reply]

TL;DR[edit]

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)[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.

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 70.231.129.165 (talk) 15:11, 27 October 2015 (UTC)[reply]

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

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 70.231.128.66 (talk) 16:29, 1 November 2015 (UTC)[reply]

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

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

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

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

I'm ready to do this merge but it appears to be a pretty big job. LAN switching is not well referenced so maybe a lot of that material will not make the cut in a merge. Though I would feel obliged to review it all. I'm going to start by refamiliarizing myself with the contents of the target sections in Network switch. ~Kvng (talk) 20:15, 26 October 2017 (UTC)[reply]

From my understanding, although the topic LAN switching could be the part of Network switch, it would be easier for the audience to read the condensed subject. There might be two options - 1) leave as it is - two separate topics and reference each other 2) Merge LAN switching to Network switch, but identify the coverage and difference between two topics - LAN and WAN switching. Goodtiming8871 (talk) 22:23, 4 January 2018 (UTC)[reply]

I'm now prepared to merge the material in Network switch#Layer-specific functionality with what's in LAN switching and Multilayer switch. My inclination is to convert Network switch#Layer-specific functionality to a summary that points to Multilayer switch. LAN switching would redirect to Network switch. I'm sure this is not the world's best organization but I believe it is a clear improvement to covering the same material three different places. We can do further improvements afterwards. ~Kvng (talk) 13:21, 27 April 2018 (UTC)[reply]
@Kvng: That sounds like a good revised plan. I agree that 2 articles rather than the existing 3 is appropriate, with the LAN switching page becoming a redirect to Network switch. It looks like a manageable job. Klbrain (talk) 11:28, 17 July 2018 (UTC)[reply]
I have done a rough merge of LAN switching into Multilayer switch. There is some unnecessary repetition. I will try to comb that out. ~Kvng (talk) 15:40, 27 October 2018 (UTC)[reply]

LAN switching has now been mostly absorbed. Network_switch#Layer-specific_functionality still overlaps with Multilayer switch. My proposal from above is to merge that content in to Multilayer switch. I have put up a split banner to see if there is a consensus to proceed with that. ~Kvng (talk) 18:16, 1 May 2020 (UTC)[reply]

 Done Layer-1 content went to Ethernet hub. Layer-2 content remained and the section is renamed Bridging. The remainder went to Multilayer switch. ~Kvng (talk) 14:49, 17 August 2020 (UTC)[reply]

External links modified (February 2018)[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on Network switch. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:37, 16 February 2018 (UTC)[reply]

[1] is a corrupt file and, from the looks of the metadata, likely an unreliable source. I have replaced it. ~Kvng (talk) 22:53, 2 April 2020 (UTC)[reply]

Citation needed for 'packet switching'[edit]

Following is the first sentence in the article:

A network switch (also called switching hub, bridging hub, and, by the IEEE, MAC bridge) is networking hardware that connects devices on a computer network by using packet switching to receive and forward data to the destination device.

I believe that the use of packet switching needs a citation. This seems to contradict the idea that the switch operates at the datalink level (2-level) and that operation at the network level (3-level) (packet switching) glorifies the switch to router status, which does not apply to all switches. 174.29.69.108 (talk) 19:48, 1 August 2022 (UTC)[reply]

Please use the New section button to add a new thread, don't add to to some random section. I've created a section header for you. I don't understand your problem. Network switches using packet switching? Layer-3 switches effectively being hardware-based routers? Packet switching applies to any kind of packet-based forwarding, in contrast to circuit-based switching. The concept of switching packets predates the concepts of distinct network layering by at least a decade. --Zac67 (talk) 20:54, 1 August 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Network_switch&oldid=1194333850"