Routers vs Switches – Pt. 1
Yesterday I was browsing Reddit and came about this post where someone was asking about the differences between a router and a switch.
I wasn’t very happy with the answers being given, mostly because they weren’t really going deep enough as to how routers and switches function on completely different levels. I also feel like it’s good to talk about how devices talk to each other in general, so we’ll go into some good depth here.
I’ll also be using the word “computer” in my explanations, but keep in mind I’m referring to any networked device, whether it’s a computer, cell phone, media player, IP phone, etc…
In the simplest terms, routers connect networks together and switches connect devices together. The way they work and talk to each other is very different.
Let’s assume we have a very simple network.
We have two computers connected together with a switch. There’s no internet, no servers, no services. In order for one computer to talk to another on a network, they need to know two different addresses of the computer they’re trying to talk to.
The first is the physical address, also known as the MAC address. This is a 48-bit HEX digit, which looks like AF:01:EB:92:DC:83. Every networking device made has its own unique MAC address.
If you wanted to start a factory that made network cards, you would need to go to the IEEE Registration Authority where they would give you a range of MAC addresses to assign to the network cards you make.
We’ll talk about MAC address more in a little bit.
The second type of address is a link address or IP address (we’ll just be talking about IPv4 in this post). This is a 32 bit number that looks like 188.8.131.52.
A computer is assigned an IP address either automatically through APIPA (Automatic Private IP Addressing), by requesting an IP address from a DHCP server, or manually using a static IP. Unlike MAC addresses, the IP address can change depending on what network it is connected to.
If we were to boot up Computer A and it was not configured to use a static IP, the first thing it would try to do would be to find a DHCP server and request an IP address. A DHCP server assigns IP addresses to devices on the network from a pool of addresses. So if the DHCP server has a range of IPs to give out from 192.168.1.100 – 192.168.1.254, when a computer requests an IP address from the DHCP server, it may say, “Ok computer, you can have IP address 192.168.1.120 for 8 days.” After the 8 days are up, the computer makes another request to the DHCP server. The DHCP server will typically lease out the same IP address it gave before. Your home routers is probably configured to be a DHCP server.
Ok, so how does a new computer on the network even figure out where the DHCP server is if it doesn’t know anything about the network? It does this by sending out a broadcast request to the IP address 255.255.255.255. The broadcast request is sent to all the devices on the network. If there is a DHCP server on the network, it get’s that request and says, “Ooh! I can give you an IP address, Mr. Computer!!”
In our example, the only device that will hear the broadcast message is Computer B, and it’s not even paying attention to DHCP server requests because it’s not a DHCP server.
So in our example, if we don’t have a DHCP server, how are we supposed to get an IP address?
In the event that a computer sends out a broadcast DHCP request and doesn’t hear anything back, it will take matters into its own hands and go with plan B. It will randomly assign itself an IP address between 169.254.0.1 and 169.254.255.254. This way if there are several computers networked together and there is no DHCP server, they can still talk to each other. Using APIPA is usually a last resort because it limited to small local networks with no internet connection. It also creates more broadcast traffic because while the computer is using an APIPA assigned address, it’s still making broadcast requests for a DHCP server every 5 minutes in the hope that the DHCP server just went out to lunch and will be back soon.
So let’s say we don’t have a DHCP server and we don’t want to rely on APIPA for giving our computers IP addresses. What do we do? We can assign each computer a static IP address. This means we’re manually imputing the IP address we want that device to use.
In Windows, this is done in the local area connection properties window.
In our example network, since we don’t have a DHCP server, and we don’t want to use APIPA, we’ll assign Computer A an IP address of 192.168.1.10 and we’ll assign Computer B an IP address of 192.168.1.20.
Perfect! Now these computers can talk to each other. But wait. What was the deal with the MAC addresses?
Switches don’t really know what IP addresses are. But they do know what MAC addresses are! When your computer sends information to another computer, it says “I’m sending this information to the MAC address AA:BB:CC:DD:EE:FF and the IP address 192.168.1.20.” The switch gets this information and says, “I dunno what this IP address is, but I know that there’s a computer connected to my second port with the MAC address of AA:BB:CC:DD:EE:FF. I’ll send this information over there and hope they know what to do with it.”
Wait. How does the switch know there’s a computer on its second port that has AA:BB:CC:DD:EE:FF as its MAC address? And how does Computer A even know to send the information to AA:BB:CC:DD:EE:FF in the first place?
Let’s say Computer A and Computer B are both brand new computers on a brand new network with static IPs. Computer A wants to talk to Computer B. We know Computer B’s IP address is 192.168.1.20 (because we’re the ones who set that up!). If we were to ping that IP address from Computer A, it still needs to know what the MAC address is for Computer B so it can let the switch know what port to send that information through. We can’t ping yet because we don’t know what the MAC address is.
To figure out what Computer B’s MAC address is, Computer A will send an ARP (Address Resolution Protocol) request to the 192.168.1.20 with the destination MAC address of FF:FF:FF:FF:FF:FF. This is a broadcast address. The switch then gets the message from Computer A that says:
Hi! I’m Computer A. My IP address is 192.168.1.10. My MAC address is 11:22:33:44:55:66. I’d like to find out what the MAC address is for the computer on 192.168.1.20. Here’s an ARP request and I’m sending it to FF:FF:FF:FF:FF:FF.
The switch gets this message and says:
Oh… ok, well I’m not exactly sure about some of the stuff you’re talking about, but I do know a thing or two about MAC addresses. So you say you are 11:22:33:44:55:66, right? Let me make a note of that. You’re on port 1. Got it. And you want to send something to FF:FF:FF:FF:FF:FF? Well, ok. That means I’ll send that out to all my ports (except yours).
So that message goes through all the ports on the switch. Since Computer B gets the message, it sees the destination IP address and says:
Ooh that’s for me!! What is it? Oh, an ARP request? I was hoping it was something cool. So it’s from 192.168.1.10 and the MAC address is 11:22:33:44:55:66? Ok, well I’ll respond back.
I’m writing to inform you that I received your message and I appreciate the information about yourself that you’ve provided. I’ll be keeping a note of it. Per your request, my MAC address is AA:BB:CC:DD:EE:FF.
I’m looking forward to our future correspondence.
The switch gets the message and says:
Who are you? Oh you’re AA:BB:CC:DD:EE:FF? Let me just write that down. Ok, so you want to send something to 11:22:33:44:55:66? Oh! I know him, he’s on port 1! I was just talking to him, he’s a swell guy. Let me just send this over to him.
Computer A gets the message and now knows what Computer B’s MAC address is. The switch also knows what Computer A and B’s MAC addresses are and knows what ports they’re connected to. Now anytime Computer A or Computer B want to talk to each other, the switch knows exactly where to send information because everyone is on the same page.