If you’re going to troubleshoot a network, then you need to understand the basic functionality of an Ethernet switch. In this video, you’ll learn the fundamentals of Ethernet switching, the address resolution protocol, power over Ethernet, and more.
The role of a switch is to forward traffic based on the destination MAC address inside of an ethernet frame. This means the switch needs to keep an ongoing and active list of all of the devices it happens to know about based on the MAC address of those devices. The switch builds this list by looking at inbound traffic and examining the source MAC address and tying that source Mac address to a specific physical interface.
And for switches that are configured with spanning tree protocol, or STP, they’re also responsible for ensuring that a loop does not occur on the switch network. The process of sending traffic through a switch network is the same for every ethernet frame. Let’s take this scenario where Sam, and you can see the Mac address for Sam’s device, is sending information to the SGC server, and you can see the SGC server’s Mac addresses 1000:5555:5555.
We have a switch in the middle, and all of our devices are plugged into the switch, including Sam and the SGC server. Inside of the switch is a MAC address table. It lists all the MAC addresses and the interfaces were those addresses are connected. When Sam sends traffic to the switch with the destination MAC address of 1000:5555:5555, the switch looks up that address in its table, and if one matches one of the entries inside of that table, it identifies the output interface for that traffic and sends it down that interface to the server that has that MAC address.
If you have multiple switches it’s exactly the same process, except it occurs twice once on the first switch and once on the second. You can see this is the same configuration where Sam is communicating to the SGC server, but there is a switch A on one side of the network and a switch B on the other. Switch A has a MAC address table specific to the devices plugged in to switch, and switch B has a completely different, and unique, MAC address table. Sam is going to send traffic again to the SGC server.
It knows that it’s sending this traffic to MAC address 1000:5555:5555. As that traffic hits switch A, switch A refers to its own MAC address table and knows that that particular MAC address is located on an interface that is a gigabit 0/2 interface, and so it sends that traffic out that interface to the next switch. On that switch, the same lookup process occurs where switch B will examine the destination MAC address, determine that MAC address is associated with the interface fast ethernet 0/5, and sends that traffic down that interface to the destination device.
You can see that building that MAC address table is extremely important. If we didn’t have the MAC address table, the switch would not know where to send that traffic. In order to build that table, the switch is going to examine all incoming traffic and make a note of the source MAC address. It will then associate that source MAC address to a specific interface on the switch. So let’s take a scenario where we’ve just powered up a switch, it has nothing in the MAC address table, and we’re going to send information from Sam’s computer to the SGC server.
Sam’s going to send that traffic to the switch, the switch is going to examine the source MAC address, and in the case of Sam’s device, that’s 1000:1111:1111. It will then put that MAC address into the MAC address table, and it will identify the interface where that information was received, in this case, interface F0/1. That information is then sent on to the SGC server, and then when the SGC server responds to that communication, it has a different source MAC address. And the process is repeated, except in this case, the switch identifies that MAC address is coming from fast ethernet 0/5.
In that previous example, we were sending information to the SGC server, but the SGC server’s MAC address was not yet in the switch. If the switch does not have an entry for that MAC address in the table, then it will send that information to everyone on the network. For example, we’ll take Sam sending this information to the SGC server. You can see in this case, the MAC address table has nothing inside of it at the moment. The MAC address table will be updated with the source Mac address because Sam did send that information to the switch, and it did associate that with fast ethernet 0/1, but we’re sending this information to a destination MAC address that’s not currently listed in the switch’s table.
In that case, it’s going to now send that traffic to everybody on the network and effectively flood that traffic to all of the other interfaces on that switch. If you’re familiar with the operation of a hub, then you’ll notice that this is very similar to the way a hub works normally. But this traffic being sent to every device ensures that at least the destination will receive this particular frame. And in this example, you can see that the SGC server did indeed receive that time frame, and when the SGC server responds back to Sam with a response, the source MAC address will be identified by the switch, that information will be added to the MAC address table, and the switch will no longer need to flood the traffic across all interfaces if communication is occurring between Sam and the SGC server again.
On an IPv4 network, devices are able to obtain the MAC address of a remote device using the ARP protocol. ARP stands address resolution protocol. ARP will query the network for a specific IP address, and that IP address will respond back with its MAC address. Your local computer keeps a cache of all of the MAC addresses that it currently knows. If you wanted to look at the ARP address table on your local machine, you can use the command arp-a. Let’s run the arp-a command on my machine. You can see that I have a number of local devices on the 10.1.10 network. You can see them all listed here.
There’s also some other devices on my local network, including some APIPA addresses and some multicast addresses. Let’s say that I want to communicate to a switch that I have on my network. That switch’s IP address is 10.1.10.210, and you can see in my ARP address table, I don’t currently have that address in the list. So I’m going to perform a ping, and I’m on a ping 10.1.10.210, and I’ll get some responses back from that particular device. If I now look at my ARP address table with an arp-a, you will see that I have a new entry for 10.1.10.210, and you’ll see that I have a MAC address associated with that IP address.
When I performed that ping, the first thing that occurred was an ARP request made to the network to try to find that particular device, and I received an ARP response, which then allowed me to send traffic to that device directly. I captured the ARP communication using Wireshark, which is a packet analyzer, and you can download and install Wireshark on your own machine to see not only ARPs, but all of the network traffic on your system. The first frame that I’m sending is from my device, and it’s sending it out as a broadcast, and the ARP itself is requesting the MAC address for who has 10.1.10.210.
You can see the details of the ARP that are located further down in the detail. You can see the sender mac address, which is my Apple computer. You can see my local IP address, which is 10.1.10..249. You can see the target MAC address. Right now we don’t know what the MAC address is of the target so it’s all zeros, and you can see that I’m requesting the MAC address for the device that has the IP address of 10.1.10..210. We very quickly get a response from this device, which happens to be a Cisco switch, and the response from the MAC address is from the Cisco Mac address with the sender’s IP address, which is 10.1.10.210.
And the target is the response back to my Apple computer and my local IP address. You can see in the response that it filled in the sender MAC address. So instead of being all zeros, I see this long MAC address associated with this IP. And if you remember the IP address and MAC address in my local ARP cache, it matches both of those that were received by this ARP response. That ARP process is what we use an IP version 4 to be able to identify a MAC address, but we don’t have broadcasts in IPv6.
There’s also a different process for IPv6 to identify the MAC addresses of devices on your local network. In IPv6, we use in NDP, which is Neighbor Discovery Protocol, using multicast, specifically with ICMPv6. This replaces the ARP function that we would commonly see in IP version 4 with this Neighbor MAC Discovery. This can also be used in conjunction with SLAAC, which is Stateless Address Autoconfiguration, which allows the system to automatically configure itself with an IP address without using a DHCP server.
Neighbor Discovery Protocol is also used to identify any duplicate addresses using DAD, or duplicate address detection. If you wanted to see the conversation that takes place in IPv6, instead of using ARP, we send a neighbor solicitation, or NS, on a multicast address, and that is the IPv6 multicast that’s used for this neighbor solicitation frame. The response is sent back from the other side with a neighbor advertisement, or NA, and that NA includes the mac address of that local device. Although the protocols and the method is slightly different, you can see that the process is very similar to the one that occurs in IPv4.
Not only are we sending data over ethernet networks, we can also send power over those networks at the same time using power over ethernet, or POE. This allows us to connect devices such as access points, voice over IP phones, and other devices by simply plugging in an ethernet connection. You don’t have to then plug in a separate power connection for that device. That power is coming from either the switch or another device that’s connected into the network. If it’s coming from the switch, we call that an endspan, or if it’s coming from an injector like the one you see here, which sits in the middle of an existing ethernet connection, we refer to that as a midspan.
If your ethernet network is a 10 or 100 megabit per second connection, then you have some extra wires inside of that cable that you could use for power. We refer to that as mode B power over ethernet, where you’re sending power on the spare pairs. But if you’re using gigabit connections, you’re using all of those wires for your gigabit ethernet data. And in those cases, we’re using mode a where we’re sending power and data over the same wire. You’ll find there are a number of different power over ethernet standards, and these standards are being added to and changed all the time.
Two very common standards are the IEEE 802.3af from 2003. We refer to that as the original POE standard, which provides 15.4 watts of direct current power with a maximum current of 350 milliamps. An update to that standard is what we call POE+. This was updated with 802.3at in 2009. This also has been incorporated into the existing 802.3 ethernet standard. This provides a bit more power on the ethernet network, 25.5 watts of DC power, with a maximum current of 600 milliamps.
There are other power over ethernet standards, and these are being updated all the time so make sure you check with the ethernet standards from IEEE to know exactly what options may be available for you.