 |
From Learn Cisco Network Administration in a Month of Lunches by Ben Piper
This article discusses Cisco routers and switches. |
What do routers and switches actually do?
Why do devices have both a MAC and IP addresses?
Save 37% on Learn Cisco Network Administration in a Month of Lunches. Just enter code fccpiper into the discount code box at checkout at manning.com.
These seemingly simple questions don’t have a straightforward answer. I’ve seen a lot of attempts to answer these questions in a few sentences, and all such attempts invariably cause more confusion than they clear up.
The truth is that routers and switches were born out of necessity rather than practicality. In principle, neither device is particularly elegant or clever, although Cisco has done some clever things to make them perform better. Like most technologies, routers and switches came about because of questionable decisions that were made decades ago. This means we have to try and figure out how to hide IP address on Mac these days to keep secure.
These questionable decisions that were made have completely transformed the technological industry and without the likes of routers and switches, access to the internet and its providers could have been significantly affected. They act as the gateway to the internet, and every router and IP address is different and unique. You can even decide to click here if you wanted to know how to access your router admin interface should you suffer from any problems. It’s hard to believe that inventions like this had to be created and edited before being able to continue its journey.
Later technology is usually built on earlier technology. For instance, e-books borrow concepts such as “pages” and “bookmarks” from traditional printed books. Imagine explaining the “page” concept to someone who is used to reading scrolls but has never seen a traditional printed book. How would you do it? Before you can explain what a “page” is, you have to explain why pages exist in the first place.
Similarly, before I can explain what a router or a switch is, I have to briefly explain what problems each was designed to solve. Once you understand that, everything else will fall into place more easily, and you’ll be administering your own Cisco network in no time. If you want to find out more about Cisco networks, or if you’re about to take your CCNA exam, you may want to look into ccna exam topics for additional help.
MAC addresses
A long time ago, some folks decided that all network devices would uniquely identify each other using something called a media access control (MAC) address. A MAC address is 48 bits long and is represented as a string of hexadecimal numbers, like this: 0800.2700.EC26. You’ve probably seen a few of these.
Here’s the interesting part: the manufacturer of each network device assigns it a unique MAC address at the time of manufacture. The rationale behind this is to make it possible to simply plug a device into a network and have it communicate with other devices without having to manually configure anything. That sounds noble, but there is a rub: because the manufacturer assigns the MAC address, it has no relationship to where the device will physically end up. In that sense, it’s not really an address because it can’t help you locate the device.
Try it now
Open a Windows command shell and type “ipconfig /all”. Your computer’s MAC address is listed next to “Physical Address”. If you have multiple network interface cards (NICs) you will see multiple MAC addresses.
A MAC address works like a person’s full name. It’s assigned at birth and makes it easy to identify someone, get their attention in a crowd of people, and even send them a message by calling out their name. If we’re in a large crowd of people, and you need to communicate a message to me but have no idea where I am, you could get on a bullhorn and yell, “Benjamin Piper, where are you?” If I’m in that crowd, I’ll receive your message.
Network devices communicate with each other in a similar fashion, but instead of using full names, they use MAC addresses. Suppose that my computer has a MAC address of 0800.2700.EC26, and it needs to print to a network printer named Monoprint with the MAC address 0020.3500.CE26. My computer and the printer have a physical connection to a device called a switch as illustrated in Figure 1. Specifically, my computer and the printer are physically connected to individual Ethernet ports on the Network Switch. Note that unlike a wireless access point, connections to a switch are always physical connections. In this sense, a switch is like a gathering place for network devices. Just like you and I might gather together with others in a crowded outdoor marketplace, network devices gather together on a switch. This collection of connected devices is called a local area network (LAN).
Figure 1. Computer and two printers connected to a switch
But here’s the problem: My computer doesn’t know where Monoprint is, or if it’s even a part of the LAN – the “crowd” of devices connecting to the switch. MAC addresses, like full names, make for good identifiers, but they’re lousy at telling you exactly where a device is. Because of this, my computer has to get on its “bullhorn” and call out to Monoprint using its MAC address.
Above and beyond
Each device manufacturer has an organizationally unique identifier (OUI) which is a string of six hexadecimal numbers. The OUI makes up the leftmost part of every MAC address the manufacturer assigns. You can think of the OUI as a person’s surname. Even though it’s assigned “at birth,” devices from the same manufacturer share the same OUI. The rest of the MAC address is assigned sequentially. This is how manufacturers ensure each device’s MAC address is unique.
The Ethernet frame: a big envelope
My computer creates an Ethernet frame containing its own MAC address as the source, and the printer’s MAC address as the destination. Think of the Ethernet frame as the big envelope in Figure 2 with a return address and a destination address.
Figure 2. An Ethernet frame contains a source and destination MAC address.
My computer places the data it wants to send – in this case, a print job – inside the “big envelope” and sends it to the switch. The switch receives the frame and looks at the destination printer’s MAC address. Initially, the switch has no idea which port the printer is connected to, so it sends the frame to every other device plugged into the switch in order to get it to the one device that needs it – the printer. This is called flooding.
Figure 3. Ethernet frame flooding. In step 1, my computer sends an Ethernet frame addressed to Monoprint’s MAC address (0020.3500.ce26). In step 2, the switch floods this frame to all other connected devices.
When everybody talks, nobody listens
Flooding has an effect similar to that of blasting a bullhorn into a large crowd. Everyone hears you, but for that moment, people in the crowd cannot hear each other. You effectively stop their communication, at least momentarily. Even after you stop bellowing into your bullhorn, it takes a bit of time for the people in the crowd to process your message and realize that they were not the intended recipient. The same thing happens when a switch floods or sends a message to all devices. Those devices won’t be able to “hear” any other devices until the flood is over. And even then, they must process the message to determine whether they need to do anything with it. This phenomenon is called an interrupt.
Although a few flooded frames and interrupts here and there might seem negligible, consider what would happen in a crowd of, say, 1,000 people who each have a bullhorn. Just as you’re ready to get on your bullhorn and send a message to me, someone right next to you gets on his bullhorn and yells out to someone else. After your ears stop ringing, you raise your bullhorn again, only to be once again interrupted by someone else. Eventually, you might get enough of a break to get your message out. But that’s the problem. You’re competing with others for the use of a shared medium – the air. This “one-to-many” communication method makes it difficult to relay a message to a specific person in a timely manner. And the larger the crowd, the worse the problem becomes.
On a LAN with a few devices, flooding is not a problem. On a LAN with hundreds or thousands of devices, it is. But that’s raises another problem. A network that can’t connect thousands of devices is virtually useless.
Broadcast domains
Suppose you add another switch named Switch2 to the network topology and connect a database server to it, as shown in Figure 4. When my computer sends a frame to the server’s MAC address, Switch1 will flood (and interrupt) every device connected to its ports – including Switch2! Switch2 in turn floods the frame to every other device. In this case, the database server is the only other device connected to Switch2.
Figure 4. Second switch extending the broadcast domain. In step 1, my computer sends a frame addressed to the database server’s MAC address (00db.dbdb.5010). In step 2, Switch1 floods this frame to all of its connected devices. Finally, in step 3, Switch2 floods the frame to the database server.
All of these devices that receive the frame are members of the same broadcast domain. A broadcast domain isn’t a thing or a directly configurable setting, but rather an emergent property of a network. To better understand this, consider the following analogy.
When you stand alone in the middle of a street, you are not a crowd. But as a few people gather around you, you become part of a small crowd. As more people gather around you, you become part of a larger crowd. You don’t change, but you become part of a crowd by virtue of how many others gather around you. Similarly, a device becomes part of a broadcast domain by virtue of which devices it receives flooded frames from.
Closing the floodgates: the MAC address table
Flooding is an inevitable side-effect of using MAC addresses. Fortunately, switches use a neat little trick to mitigate unnecessary flooding. Whenever a switch receives a frame, it looks at the source MAC address and the switch port it came in on. It uses this information to build a MAC address table.
Above and beyond
Cisco sometimes refers to the MAC address table as a content addressable memory (CAM) table, but they’re the same thing.
When Switch1 receives a frame from my computer, it takes note of the source MAC address – 0800.2700.ec26 – as well as the switch port the frame came in on – FastEthernet0/1. It adds this information to its MAC address table as shown in Table 1.
Table 1. Switch1’s MAC address table
| Device | MAC address | Switch port |
| Ben’s computer | 0800.2700.ec26 | FastEthernet0/1 |
Now suppose the database server sends a frame addressed to my computer’s MAC address. The frame reaches Switch2 which in turn forwards it on to Switch1. But this time, instead of blindly flooding the frame to all other devices, Switch1 checks its MAC address table.
It sees that the destination MAC address – 0800.2700.ec26 – is on FastEthernet0/1, so it sends that frame only out of that specific port. This works similarly to an old telephone switchboard, which is where the term switch comes from.
Figure 5. How the MAC address table mitigates flooding. In step 1, the database server sends a frame to my computer’s MAC address (0800.2700.ec26). In step 2, Switch2 floods the frame to Switch1. In step 3, Switch1 consults its MAC address table and finds a corresponding entry for the destination MAC. In step 4, Switch1 sends the frame only to my computer instead of flooding it to all devices.
Breaking up the broadcast domain
As the size of the broadcast domain grows, communication becomes more difficult. Consequently, a broadcast domain containing hundreds of devices performs poorly. But modern organizations require network connectivity among thousands of devices. And just haven’t connectivity isn’t good enough. The network still has to be fast and reliable.
The solution is to limit the size of the broadcast domain. This means breaking it into multiple, small broadcast domains that, somehow, can still communicate with each other.
Going back to our example, the simplest way to split the broadcast domain is to remove the Ethernet cable connecting Switch1 and Switch2, as shown in Figure 6. Note that the switches are not connected in any way. That’s the easy part. Here’s the hard part: My computer and the database server reside on two separate broadcast domains. There is no way my computer and the server can communicate. What do you do? You can’t just plug the switches back together because that would re-create the original, single broadcast domain.
Figure 6. Two broadcast domains
Joining broadcast domains
In order to join two broadcast domains together without encountering that nasty flooding problem, two things must happen:
First, since both broadcast domains are physically disconnected, you need a special device to physically connect them in such a way that flooded frames cannot cross the broadcast domain boundary. Since frames contain source and destination MAC addresses, this device will effectively “hide” the MAC addresses in one broadcast domain from the MAC addresses in the other.
Second, since MAC addresses in one broadcast domain will be hidden from another, we need a different scheme to address devices across multiple broadcast domains. This new addressing scheme, unlike MAC addresses, must not only be able to uniquely identify devices across broadcast domains, it must also provide some clues as to which broadcast domain each device resides in.
Let’s start with the latter.
Addressing devices across broadcast domains
The addressing scheme has to meet some requirements: First, the addresses have to be unique across broadcast domains. A device in one broadcast domain can’t have the same address as another device. Second, the address has to tell us all by itself which broadcast domain it is a part of. The address should not only be able to uniquely identify a device, but also tell other devices which broadcast domain it resides in. This is to avoid that ugly flooding problem. Third, the addresses cannot be “assigned at birth” like MAC addresses. They have to be configurable by you, the network administrator.
Fortunately, you don’t have to look very far. Such an addressing scheme already exists, and you’re already using it.
If you want to learn more about the book, check it out on liveBook here and see this slide deck.