How a network switch works
Author |
Date |
Revision |
Samuel Knoppe | 4/11/2024 | 1.0 |
Related product (if any): |
N/A |
Description: | Explains the fundamentals of network switches, what they are used for, and how they work. |
Symptoms: |
N/A |
Cause: |
N/A |
Files Needed: |
N/A |
Steps to Correct: |
What is a network switch? A network switch is a device which connects network devices and allows users to perform intra-network data exchange data packets via frames. Switches can be both hardware and software, and operate at Layer 2, the data link layer, in the OSI Model.
The way a switch operates is that it distributes information to the one device a frame is destined for, including some other switch, a router, or a user's computer, rather than several other devices in the network at once.
The majority of switches use Ethernet as its main Layer 1 medium of choice, but some also use fiber optics, InfiniBand, and more.
How does a network switch work? Network switches can work in one of three ways in a network:
This diagram provides an overview of what these three types of network switches will look like in a network architecture. This follows a design philosophy in network engineering calling the 3 Layer Hierarchical Network Model. The 3-tier model shown provides a mixture of high redundancy for all three layers. Redundancy is the main key appeal of this model. Note that this model doesn't include just network switches, but routers as well. But the image showing the layers of switches follows this design philosophy of redundancy as well.
Why have this? In massive enterprise network environments, downtime is a no-go. You also need to have speed and reliability for your network. Where access switches provide network coverage, a distribution layer is optionally used to facilitate faster and redundant connections between other access switches. While the core provides a high-speed backbone for the network and connects to the Internet and other remote sites, and more.
Smaller businesses may not have or need a distribution layer, and may only have an access and core layer, or, for very small businesses, basically only have an access layer.
What happens when data comes into the switch? Okay, so I lied about the last section. This is the section where I actually explain how a switch works. Whenever a device is connected to a switch, the switch notes the device's MAC address, which is baked into the network device's NIC. The NIC attaches to a Layer 1 media like an ethernet cable, which connects it to a switch. The switch uses the MAC address of the device to identify which device's outbound packets are being send, and where to send inbound ones.
The MAC address identifies the physical device and does not change in a way an IP address might change.
When a packet enters the switch--packets actually mean frames, when we're talking about network switches--the switch reads the header, then matches the destination MAC address or addresses and sends the frame out of the appropriate ports that lead to destination devices.
But what if a network switch doesn't know where a destination MAC address is? What then? In that situation, it will send out a broadcast frame out of every one of its ports, except for the port it received the frame on that included the unknown destination MAC address. If the destination is near, the switch will record the port where the destination MAC is attached to into something called a forwarding information base (FIB) or MAC table, which includes a cache of all MAC address to port mappings. After it has been recorded, the switch will be able to simply forward traffic out of that port if it needs to reach that MAC address.
The danger of broadcast storms I want you to envision a scenario. You have a network with two access switches, and one core switch. All three are interconnected, so there is redundancy in play. One access switch receives a frame with an unknown MAC, so it floods that frame on all its ports except the one the frame came in on. The second access switch and the core switch also receive the broadcast frame, and perform the same procedure. The first access switch receives the broadcast again, and so does the second, and the core... dramatically increasing network activity until the switches shut off.
So... what happened? Why did the switches shut off? The reason is because of a broadcast storm (also called BUM frames). This is where broadcast frames are looped indefinitely between a redundant array of network switches, creating an excess of network activity, increasing CPU usage until the switches shut-off due to built-in protection parameters.
Another problem arises when a broadcast storm occurs, called MAC table instability. A MAC address can only be tied to one port, but during a storm, multiple copies of the same frame are coming in on multiple ports, creating inconsistency and even more BUM traffic to the other switches, exacerbating the problem even further.
There also a third problem created when a broadcast storm happens. End devices will receive multiple copies of the same frame. This can result in high CPU usage and may even crash end-user devices!
Spanning-tree protocol--a network's sword and shield against deadly loops So... now you understand fully just how catastrophic broadcast storms are. How the hell do you prevent them? Luckily most network switches have a protocol which is used to defend against loops in networks with redundant paths called Spanning Tree Protocol (STP). This protocol's entire job is to prevent these loops by strategically blocking certain ports on the network as to close off loops, but still allowing said port to be used as a redundant link if its counterpart goes down. So you get the benefits of redundancy without the fear of deadly loops. STP: No, you furry little fucker. These loops are mine! You cannot have them!
The specifics of how STP works and the election process it goes through is beyond the scope of this document, but just know it's the thing that's keeping your nice redundant layer 2 switch topology from completely nuking your entire network and creating a really bad day in the office.
Switches versus hubs In the olden days, hubs were the shit and switches weren't a thing at all. Hubs function simply like this; I receive traffic, I shit traffic out of all ports. I'm sure you can see the issue here. Hubs are very stupid and simply just spit out traffic. Back then, it worked fine since bandwidth needs were lower, but that ain't going to fly today at all. Doesn't help that most at the time capped out at, like, 10MB at the ports.
Another frequent problem of hubs, is that they ran at half duplex; meaning, they can only send or receive data. But not at the same time. If data is sent and received at the same time, data collisions occur, resulting in data loss and errors.
Network switches fix all these issues by first only sending traffic to ports of a specific device (once it has learned its MAC and port binding), and also by being able to run at full duplex on its port. Meaning it can send data back and forth at the same time, giving full access to the bandwidth of the connection to the switch.
Did you know? If a network switch's MAC table gets full, it will fail over to broadcast mode and start to broadcast the traffic to all ports in that VLAN, effectively turning it into a hub!
|
No Comments