This article is a part of a series on Packet Traveling — everything that happens in order to get a packet from here to there. Use the navigation boxes to view the rest of the articles.
In the last article, we looked at everything that happens for two hosts to communicate directly with one another. In this article, we will add a common network device: a switch. We will take a look at what happens for communication from Host to Host through a Switch.
This article will be the practical application of everything that was discussed when we looked at a Switch as a key player in packet traveling. It might be worth reviewing that section before proceeding.
We will start by looking at the individual switch functions, and then take a look at an animation which shows their collaborative operation.
Being a Layer 2 device, a Switch will make all its decisions based upon information found in the L2 Header. Specifically, a Switch will use the Source MAC address and Destination MAC address to make its forwarding decisions.
One of the goals of the Switch is to create a MAC Address Table, mapping each of its switchports to the MAC address of the connected devices.
The MAC address table starts out empty, and every time a Switch receives anything, it takes a look at the Source MAC address field of the incoming frame. It uses the Source MAC and the switchport the frame was received on to build an entry in the MAC Address Table.
Sooner or later, as each connected device inevitably sends something, the Switch will have a fully populated MAC Address Table. This table can then be used to smartly forward frames to their intended destination.
However, despite the learning process above, it is unavoidable that a Switch will at some point receive a frame destined to a MAC address of which the Switch does not know the location.
In such cases, the Switch's only option is to simply duplicate the frame and send it out all ports. This action is known as Flooding.
Flooding assures that if the intended device exists and if it is connected to the switch, it will definitely receive the frame.
Of course, so will every other device connected to that particular Switch. And though not ideal, this is perfectly normal. The NIC of each connected device will receive the frame and take a look at the Destination MAC address field. If they are not the intended recipient, they will simply silently drop the frame.
If they are the intended device, however, then the Switch can rest satisfied knowing it was able to deliver the frame successfully.
Moreover, when the intended device receives the frame, a response will be generated, which when sent to the Switch will allow the switch to learn and create a MAC Address Table mapping that unknown device to its switchport.
Ideally, of course, the Switch will have an entry in its MAC Address Table for every Destination MAC it comes across.
When this happens, the Switch happily forwards the frame out the appropriate switchport.
There are three methods by which a Switch can forward frames. They are briefly described below.
Store and Forward – The Switch copies the entire frame (header + data) into a memory buffer and inspects the frame for errors before forwarding it along. This method is the slowest, but allows for the best error detection and additional features like prioritizing certain types of traffic for faster processing.
Cut-Through – The Switch stores nothing, and inspects only the bare minimum required to read the Destination MAC address and forward the frame. This method is the quickest, but provides no error detection or potential for additional features.
Fragment Free – This method is a blend of the prior two. The Switch inspects only the first portion of the frame (64 bytes) before forwarding the frame along. If a transmission error occurred, it is typically noticed within the first 64 bytes. As such, this method provides "good enough" error detection, while gaining the speed and efficiency of avoiding storing the entire frame in its memory before forwarding it.
It is worth pointing out that these three methods were at one point very significant when Switch technologies were newer and switching induced noticeable latency. In modern days, with line-speed switching, the difference in speed between these three is negligible, and most switches operate in Store and Forward mode.
And finally, the last function of the switch is filtering. Mainly, this function states that a Switch will never forward a frame back out the same port which received the frame.
Most commonly, this happens when a Switch needs to flood a frame — the frame will get duplicated and sent out every switchport except the switchport which received the frame.
Rarely, a host will send a frame with a destination MAC address of itself. This is usually a host experiencing some sort of error condition or being malicious. Either way, when this happens, the Switch simply discards the frame.
Now that we've looked at each of the individual functions of a Switch, we can look at them in action. The animation below includes a Switch going through all four functions as it processes traffic.
Ordinarily, the hosts in the animation below would need to perform an ARP resolution, but for the sake of focusing on the Switch's operation, we will omit ARP and proceed as if all the hosts already knew each other's IP and MAC addresses.
Host A has "something" to send to Host B. The contents of the "something" is entirely irrelevant, so long as its understood that the frame has a L2 header which includes a Source and Destination MAC address.
Initially, the MAC Address Table of the Switch is empty. Remember, it only gets populated when a frame is received.
When Host A sends the frame to the switch, it includes a Source MAC address of aaaa.aaaa.aaaa. This prompts the Switch to learn a MAC Address Table entry mapping Port 1 to MAC Address aaaa.aaaa.aaaa.
Then, when deciding how to forward the frame, the Switch realizes there is no entry for bbbb.bbbb.bbbb. This leaves the Switch only one option: duplicate and flood the frame out all ports. Notice the frame was duplicated out all ports, except Port 1 (the port it came in on) – this is an example of the Switch performing its filtering function.
This frame will then be received by Host C and Host B. Host C, when inspecting the L2 header will realize the frame is not intended for them and will simply discard it. Conversely, when Host B receives the frame and realizes they indeed are the intended recipient, they will accept the frame and generate a response.
When the response arrives on the Switch, another MAC Address Table mapping can be learned: Port 2 contains the MAC address bbbb.bbbb.bbbb.
Then the Switch looks up the Destination MAC address (aaaa.aaaa.aaaa) and realizes this address exists out Port 1. The Switch can then simply forward the frame, since it knows the location of the Destination MAC address.
The animation above illustrate the four switch functions on a single switch. To see how the process scales to multiple switches, check out this article.
There is often some confusion about a switch in regards to a Broadcast and a Switch's flooding behavior. The confusion is understandable, because the end result is the same, but it is also important to understand the distinction.
A Broadcast frame is a frame which is addressed to everyone on the local network. This is done using the same Ethernet header we've been discussing, except the Destination MAC address field is populated with a special address: ffff.ffff.ffff. The "all F's" address is specially reserved for the purpose of broadcasting.
By definition, if the Switch ever encounters a packet with a destination MAC of ffff.ffff.ffff, it will always flood the frame (after learning the Source MAC, of course).
Another way of looking at it, is since the address ffff.ffff.ffff is reserved, the switch is unable to learn a MAC Address Table mapping for it. As such, any frame destined to this MAC address will always be flooded.
In summary, a Broadcast is a frame addressed to everyone on the local network (ffff.ffff.ffff), and Flooding is an action a switch can take. A broadcast frame, by definition, will always be flooded by a switch. But a switch will never broadcast a frame (since broadcasting is not a function of a switch).
This article intentionally omits the Address Resolution Protocol (ARP) in order to focus purely on the actions of a Switch. ARP is a function of the client, and will never be performed by the switch itself. It is assumed that the clients in the animation above already know each other's MAC address. To learn more about ARP, check out this video.
To some extent i was interested to know more about what will happen when the switch receive a frame address to a new host that is not in the mac address table?
Hi Baraka, it would first attempt to Learn the source MAC address of the received frame, then if it doesn't yet have an entry for the Destination MAC address, it would Flood the flame out all ports (except the one it came in on). Pretty much the same sequence of events as the animation above when the switch first receives the frame from Host A, and the MAC Address Table is empty.
I am confused now. You brought up the example of Host A sending data to Host B. The switch does not know Host B MAC address. So the switch duplicate the Frame and Broadcast it out. Everyone other hosts drops except for Host B. Host B sends the FRAM back to the switch. Switch populate its MAC Address Table.
When does Host B receive the data? From your statement, Host B sends a response to the Switch with the Destination to Host A. Switch sends data to Host A.
How does the switch send data when Host A is sending to Host B after getting the response from Host B from an empty MAC Address Table?
> When does Host B receive the data?
The frame is the data. When Host A sends the frame, it is not sending it to the switch, it is just sending it. Host A does not know whether it is connected to a switch, or directly connected to Host B.
> How does the switch send data when Host A is sending to Host B after getting the response from Host B from an empty MAC Address Table?
The switch is not sending data, it is merely forwarding data initially sent by Host A or Host B. It is simply using its MAC address table to forward the data smartly. This is in contrast to a hub, which would simply duplicate each incoming frame and flood it out all ports, every single time. The switch only needs to do the flooding action initially — once it learns which MAC addresses exist at which ports, it simply forwards.
Thanks Ed. After I posted my commented, I continued to watch the YouTube Video that you made. That video made me think clearly.
When Host A does not know the MAC address, it sends an ARP saying "what is the MAC address to this IP". After the response from Host B…"Hi, I'm that IP and this is my MAC"…get back to Host A. Host A update its ARP table. Now Host A can build the frame of Source MAC and Destination MAC and send the data off.
Without the complete L2 header, data can never be sent within a network or another network. That's my interpretation. Data can never travel when L2 is not completed.
Hi Hoang, absolutely. L2's job is to deliver a packet from one NIC to the next NIC. Without the ability to create a full L2 header, data can never traverse between two nodes. Glad it all makes sense now!
I also wanted to know the process when Host A does not have the Destination MAC because it rebooted. However, the switch does have the Destination of where Host A wants to send.
For example, Host A sends data to Host B. Host A looks at its ARP table, discovers that it doesn't have Host B. Host A sends a Broadcast. How does the Switch handle the Broadcast when the switch does have Host B MAC?
Just for more confusion on my side, what does the switch do when it doesn't have Host B MAC as well? Does the switch duplicate the FRAM from Host A and FLOOD?
If the switch in between has been switched off and on??? Then what will happen to the packets forwarded from HOST A ???
> For example, Host A sends data to Host B. Host A looks at its ARP table, discovers that it doesn't have Host B. Host A sends a Broadcast. How does the Switch handle the Broadcast when the switch does have Host B MAC?
The ARP Request that Host A sent will be a Broadcast frame, which means the destination MAC address field of the L2 header is FFFF.FFFF.FFFF. Whether the switch has Host B's MAC address or not, it will always process a broadcast frame the same way — by flooding the ARP Request to every host on the network.
Remember, the switch does not know that the packet is an ARP Request or regular data. It only looks up to the L2 header to make it's forwarding decision.
Thank you so much. I swear that you made the subject matter in this series so friendly to understand that even a cave man will learn.
Thank you again Ed. Please write more topics when you have time of anything IT.
Thanks for the series.I wish to know how the packet flow between two switches with one host (192.168.1.1/24) in one switch and another host(192.168.1.5/24)in another switch.
Can you please explain this for me.
Hi Chandra, I finished the article that describes the process with multiple switches. Check it out here: Communication through Multiple Switches.
Thank you for this, Ed. I teach networking here at the University and as much as I hate to admit it, you do a better job than I do. So…..one would think I would learn how to teach it better, but I am going to send them to your site instead! ;-D Then they get it two ways instead of one…..much better. Thank you again.
Hi Steve, thanks for the kind words! I'm glad you enjoyed the article! I hope they continue to help you and your students!
Thanks for the wonderful article along with video, Let us know do you have the examples like this for DHCP & PPPOE protocols.
i want to receive frame from port C of a switch.when port A sends the frame to port B on the same switch.HOW??????????????
Hi Phani, you're looking for what is known as SPAN sessions.
Could you kindly elaborate on this statement?
Hi Joelle. A Broadcast, by definition, is simply a frame with a destination address of ffff.ffff.ffff. A Switch's reaction to a broadcast frame is flooding. One is a type of frame, the other is an action the switch will take.
Great article. I was wondering how does the host or any device in the same network know the location of the switch? The destination ip address and MAC address is either of the router or an another host (given, its in the same network).
The host does not know the location of the switch, nor does it need to. The host does not know whether there is one switch or ten switches, or zero switches. The host simply creates the datagram, creates the L3 frame, creates the appropriate L2 frame, then puts it on the wire. Everything that happens after that is entirely out of the host's hands.
A switch can learn the MAC address mapping of the devices connected from any frame, not just ARP frames. When HostA sends anything, the switch will learn the MAC address and associated port for HostA. When HostB sends anything, the switch will learn the mapping for HostB.
An ARP Frame is only a broadcast because the destination MAC address is set to ffff.ffff.ffff. ARP can be sent unicast, as is the case in ARP Responses.
Flooding is a switch action (not a type of frame). It is the action a switch takes when it does not know exactly which port to deliver a frame to.
Separate the functions of each device. They are independent from one another.
A host will issue an ARP Request if it needs to map an IP address to a MAC address. This frame typically has a destination MAC address of ffff.ffff.ffff and is therefore a broadcast frame.
A switch will learn the source MAC address of any frame it receives on any port.
Each function is independent of the other. A switch does not flood because the frame is an ARP, a switch floods because the frame is destined to ffff.ffff.ffff.
I read this this article and was impressed with the level of detail. I took a few of your classes at the Rack! Awesome 🙂 Thanks for this.
Hi Swetha! Good to hear from you again! Glad you enjoyed the articles and hope everything is well!
1) What happens if host 1 sends data to host2 and someone had unplug host2 and plug it to an another port ?
1. When a host is disconnected, the switch will purge all known MAC addresses with that port. When the host is reconnected elsewhere, the standard learning function will populate the MAC address table for the host's new port.
2. Typically, when a host's IP address changes, it will issue a Gratuitous ARP. This will update all the relative ARP caches on the network and all the relative MAC address tables on the switch.
3. Lastly, if the MAC addresses were changed, whatever next frame is sent by either host from their new MAC addresses would cause the MAC address table to update, and the switch to "re-learn" where those MAC addresses exist.
Hope this helps. If it doesn't, it might be because your question is too specific… in which case I would recommend asking at the Network Engineering Stack Exchange or Sub Reddit.
Thanks for your answer and the time you spend writing it.
Hi! Great article and animations!
One thing puzzles me: Since Host A needs to know MAC address of Host B before sending actual data, an ARP request and response will take place, during which the switch will learn and store the MAC addresses of Host A and Host B. So, how can it be that in your example when Host A sends the actual data, the switch doesn't already know the MAC addresses of Host A and Host B?
For the sake of limiting this article to the functions of a switch, I omitted the process of Host A and Host B discovering each other's MAC address.
Otherwise, you are correct. If they did not know each other's MAC address, they would have to discover it using ARP, and the switch would have learned their MAC addresses from the packets in the ARP conversation.
OK, I understand now. I've read 2 books about networking and your tutorial was the only thing that made everything was so simple and clear. You are very gifted at what you're doing and your animations are superb. I'm looking forward to a tutorial about VPN. Thank you very much!
In data link layer we have frame for comminication that have a two field for MACs.We have client A with source mac aaaa.aaaa.aaaa destined to client B with bbbb.bbbb.bbbb MAC add in a cleared mac table switch.when aaaa.aaaa.aaaa received to switch and not known bbbb.bbbb.bbbb is where ,then wants to flood a frame to all port (except the port that received) for learnnig bbbb.bbbb.bbbb.
my question is which destination mac address is in destination mac address field in the frame? switch floods the frame with bbbb.bbbb.bbbb dest mac add field or with ffff.ffff.ffff ?
When the switch chooses to flood the frame, it does not change the destination MAC address. So in the case of the flood action above, the SRC MAC will be aaaa.aaaa.aaaa and the DST MAC will (still) be bbbb.bbbb.bbbb.
Remember, a switch does not broadcast — broadcasting is not an action of the switch. A switch only Forwards, Floods, Filters, or Learns.
A Broadcast is a frame created by the client which the client wishes to be delivered to everyone on the network. Just like a Unicast frame is a frame created by the client which the client wishes to be delivered to just one other recipient.
The Client creates Broadcasts or Unicast frames. The Switch chooses to flood or forward the Unicast frame, and (by rule) the Switch chooses to always flood the Broadcasts frames.
In case the Mac and IP address of host C is known, will it still flood the frame to the port where host C is connected?
The frame is only looking at the L2 header, and if the L2 header is ffff.ffff.ffff then the switch will Flood the frame.
Even if the switch knows the location of the MAC address being ARP'ed for, the switch will never look into the ARP Payload. It will only look at the L2 header. See this section for more details on the L2 header vs the ARP payload.
Thanks for the clarification Ed.
Very good Informations here in this page highly appreciated.
But i have some Beginner question.
Something that is not clear to me yet is , How the Source computer A knows the Mac address of the Destination computer B ?
We know Computer A and B never communicated before ?
Could someone help with this ?
Hi Joe. Good question. In reality, Host A would not know the MAC address of Host B. But for the sake of focusing on the switch operations, I omitted including ARP in this illustration. If you want to understand the full process, check out the last article in this series which provides a video that explains every step, to include Host A's ARP Request.
Yes i have gone through the Video and other Another part of this series which explains thew ARP request By Host A.
Thank you again for the article , it's really helping me out. And i hope to see more Detailed and deep articles on Networking Just like this again.
Since in point to point connections we do not use arp request ,how does host A find out the routers interface mac address ,host Bs mac address etc ? thank you again.
Point to Point media, such as Serial links, can only have two parties on the "network" — one on each end of the cable.
Multiaccess media, such as Ethernet, can have unlimited parties on the network. But for that to be possible, there has to be a device facilitating communication among the different devices on the network — like a switch.
In your picture, Host A is connected to a switch, which means Host A is using multi-access media, which means it would indeed use ARP to resolve the Router's MAC address.
Had there been no switch, and had Host A been connected directly to the Router with a Serial link, THEN there would be no ARP, because anything Host A put on the wire would appear on the other side (although typically you do not see hosts using Serial cables these days).
I see.I get it now.
hi sir, I have a question suppose packet is sent from the host A which is in Lan 1 to host B which is in Lan 10, packet travels via intermediate node or switch or router … while travelling a packet from LAN 1 to LAN 10 packets can be lost/ discarded due to various reasons at that moment how re-transmission of packet is done ???
Good question. Within L2 and L3, there is no consideration for lost packets or re-transmissions. That doesn't come into play until L4, and even then only if the protocol in use is TCP. Then, TCP will handle keeping track of which packets have arrived, and which packets need to be re-transmitted.
TCP might one day be the topic of a future article, but is outside the scope if this particular series.