How does Routing and Switching Work?: The Life of a Packet

Note   Note
This tutorial is only theory based and aims to demystify the functions of a router and a switch and help to shine some light on how your data is routed through a network.


In this tutorial I am going to be explaining the basic principles of routing and switching in a network as well as the functions of MAC addresses and IP addresses in the network as there are often misunderstood in how they are actually used. Please understand that I will be making little to no reference to security and application separation techniques such as the use of TCP/UDP (Transmission Control Protocol/User Datagram Protocol). Additionally I will also be explaining what a router and switch actually does as these two devices can also be misunderstood (Thanks to the ISP router/switch combo devices that they hand out).

What is a Switch?

A switch is a multi-port device that designed to interconnect end user devices or other switches into the network. Without them we would all be stuck in our modem days where only one computer could connect to the internet at any one time. To better expand on this, the image below shows an physical example of some switches.

prod_large_photo0900aecd80327c05.jpg

Source: http://www.cisco.com/c/en/us/produc....img.jpg/prod_large_photo0900aecd80327c05.jpg

As you can see, they have an extremely high port density for connecting large amounts of end devices. Right, what else does a switch do? Well they can switch traffic from one port to another and do it very efficiently. This is done by using the MAC addresses that are placed on packets as they are sent on the network. Upon receipt of a packet/frame it will check the source MAC addresses (The MAC address of the device who sent the frame.) and map it to the port that it was received on. This way, if a frame was destined to go to that device later it can be switched straight out of that port without bothering any other device on the network. This leads me on to how it handles the destination MAC address attached to the frame. After mapping the source MAC address it will then look at the destination MAC address to find out which port to send this frame out to. To do this it will then compare the destination MAC address to what is listed in the MAC address table that states what devices are mapped to which ports. If a match is made it will switch the frame out that destination port and not bother anyone other device. If it doesn't know the destination MAC address it will flood the packet/frame out all ports on the switch other than one that it received it on. This way, the frame is still sent to its destination device on the local network and when/if reply traffic is made it can then map the MAC address to the port and the next time another frame/packet is sent it can be directly switched to the relevant destination. This is known as the learning phase of a switch, where the longer it runs and the more traffic sent through it, the more efficient it becomes as the flooding of frames is reduced. This in turn saves up bandwidth (The amount of data that can be sent on a port at any one particular point in time). If the concepts are still fuzzy don't worry I will be completing a practical demonstration later that will better show the position a switch has in the network.

When drawing network diagrams, it is often inefficient to use pictures of the actual device it self therefore we typically use a logical representation of it. This can be seen below:

cisco-switch-icon.png

Source: http://www.takistmr.com/wp-content/uploads/2011/07/cisco-switch-icon.png

With this in mind, when you see this logo in a network topology just remember that it is a switch.

What is a Router?

Routers are fairly advanced yet dumb devices (A bit of an oxy moron I know but it will make sense later!). Their main purpose is to route traffic from one network to another through the use of IP addresses ONLY. You see, with a switch all the devices reside in the same network as in they all have the same subnet and they are all in the same broadcast domain (Another technical term: The domain at which a broadcast can go before it is stopped). This is much like your internal home network where everything belongs in the 192.168.1.0/24 network. With a router it is a device that takes traffic going from one network and routes it to another. A common example of this happening is you accessing the internet. Your router at home is simply taking your internet requests and routing them to your ISP (Internet Service Provider) who then routes it off to the internet. If you look at a traceroute output you will notice that each "hop" shown is a different network is actually the route that your packets are taking through various networks before it reaches its destination. These are all routers routing your traffic.

How does it work? The concept is rather similar to what a switch does with its MAC address table in finding what port to switch the traffic. A router has a table that is known as the routing table. This is a table that dictates what networks a router knows how to reach and where it should send traffic should a match occur. You see, if a router does not know how to reach a network, lets say for example, google... If a router does not know how to reach Google then it will drop your traffic and your device will most likely receive requests time out. So what does a router know by default then? Quite simply, a router only knows networks that it is directly connected to and nothing more (This is where the dumb part of routers come into play). In order for routers to converge with each other in routing traffic to each network they need to add entries to the routing table that tell them what the destination network is and who to send it to/what interface to send it out of (Another technical term: This is known as a route in the routing table.). To add routes to the routing table it can be completed in two possible ways. One way is where you manually input the route and manually tell the router where to send the traffic (This is known as a Static Route). The other option which is more common is that you use a routing protocol that allows routers to communicate with each other and dynamically tell each other about what networks they know in their routing table. The principle is as follows. If you tell me about a network then I will use you as the next "hop/router" in my routing table. An example of this in action can be seen at the bottom of this tutorial - https://www.sysnative.com/forums/ne...-use-rip-listener-routing-for-a-computer.html. Essentially, our client device choose to send traffic to a router because it was the one who told us that it knew how to reach that network.

To better put it into picture here is an image of a physical router:

prod_large_photo0900aecd8016fb47.jpg

Source: http://www.cisco.com/en/US/prod/routers/ps5854/ps6018/prod_large_photo0900aecd8016fb47.jpg

As with the switch, we do not represent routers in a network diagram through their physical chassis but rather use an icon. An example can be seen below:

Cisco-Router-Commands-images.jpg

Source: http://blog.tecnologialibre.net/wp-content/uploads/2012/04/Cisco-Router-Commands-images.jpg

As you can see, routers are circle and switches are square. If there is one thing that you take away from this it should at least be that one is circle and the other is square!

The Life of a Packet

Now you have a somewhat fuzzy idea of what a switch and router does I am now going to show a practical example so you can better understand the life of a packet as it reaches its destination. In order to explain this here is the following example with it containing 2 switches and 2 routers. Having seen the icons you should know which is which. In this example, we have 3 networks that have been noted by having each network have different colours.

topology.PNG


In this example I am going to be simply sending 1 ping message from PC-A over to SERVER-B.

The first step in initiating the communication is for PC-A to figure out if SERVER-B is on the local network or if it is on a remote network. This is done by examining the subnet mask of the IP address configured with the destination IP address. Why would it want to know this? Well it needs to determine if it can send an ARP request for MAC address of the server directly so SW1 can switch the traffic straight to the destination, or if it needs to ARP request for the MAC address of the default gateway (R1) so SW1 can switch the traffic over to the router and have it route to the relevant destination.

Right so lets look at it:

PC-A's IP address: 192.168.1.10

Destination IP address: 172.16.1.70

As we can see, 172.xxx.xxx.xxx is different than 192.168.1.xxx therefore PC-A will need to send this ping request over to R1 for it to be routed to its destination.

Remember, switches only look at MAC addresses therefore PC-A will send this ping message with a source MAC address of its own and a destination MAC address of R1. It will then proceed to add a source IP address of its own and a destination IP address of SERVER-B. A good thing to remember is that IP addresses are for end to end connectivity and MAC addresses are used for the local network. With this in mind PC-A will need to look at its ARP cache to find out what the MAC address of R1 is.

PC-A%20ARP.png


As you can see, R1 conveniently has the MAC address of 00:00:11:11:11:11. Since I am a nice person I have manually configured all the MAC addresses involved so you can see how it changes as the packet is routed across the network over to the server.

As the ping request is sent it reaches SW1. From here the switch then maps the source MAC address of PC-A on its port and then looks at the MAC address table for the destination MAC address which in this case is going over to R1. We can see the MAC address table of SW1 below:

SW1-MAC-TABLE.png


As you can see, PC-A is connected on port FastEthernet1/0 on SW1 and R1 is connected on port FastEthernet1/1. Based on the MAC addresses added/encapsulated on the frame, the ping request has now been switched over to R1.

Fortunately, I have made packet captures across each link in the path of the packet and from as of now in our path you can see that out ping request is the same structure as when it left.

capture-pca-r1.png


Our ping request has now reached R1... you may be thinking.. all that and its only just reached the default gateway. Well yeah but remember I have broken it down and this process happens in milliseconds. When the frame enters R1 it first looks at the destination MAC address since that is at the top and sees the destination MAC address is destined to it. From this point, R1 believes that this packet is destined to itself however after looking at the MAC address it sees the destination IP address. This destination IP address isn't one owned by R1 and therefore R1 knows that this is a packet to be routed.

The next step in the process is for R1 to find out how to reach the IP address of 172.16.1.70. For this process it will look at its routing table for the answer. A copy of R1's routing table can be seen below:

R1-Route-Table.png


If you look closely you should be able to see that there is an entry saying that to get to the 172.16.1.0/24 network you need to send the packets over to 10.1.1.2 (R2). Right so we know we need to send it over to R2 but the question is... what interface does R2 belong on? From this R1 then re-looks at the routing table and sees that the 10.1.1.0/24 network that has R2 on it is located off of FastEthernet0/1. (Technical Term: The process of looking up the routing table multiple times is called a recursive route lookup).

Now that a path has been chosen to send this packet there are some final adjustments that need to be made before it is sent on over to R2. R1 will now rip off the source and destination MAC addresses and change them accordingly so that when R2 receives the packet it will continue to process it. If R1 just sent the packet as it was it would get rejected by R2 since the destination MAC address does not match the MAC address of R2. To find out the MAC address of R2, R1 will complete an ARP request and look at its ARP cache for the information. This can be seen below:

R1-ARP-TABLE.png


Note   Note
As a side note you will find that R1 knows the MAC address of PC-A and R2. This is because it is directly connected to both of those networks hence the ARP table containing entries from disparate networks. If you look at the ARP cache on your host machine you will find that you will only see entries for your local network since that is all you are connected to.


With this new information found the new MAC addresses imposed on the original packet is now the following:

Source MAC Address: 00:00:11:11:11:11

Destination MAC Address: 00:00:22:22:22:22

Source IP Address: 192.168.1.10

Destination IP Address: 172.16.1.70

Notice how the IP addresses stay the same... Remember, IP addresses stay the same to ensure end to end connectivity. MAC Addresses change upon change of a network (This happens when a router routes the packet).

To backup this we can see our ping packet as it is sent across the link between R1 and R2.

capture-r1-r2.png


The packet has now just reached R2 (We're almost there!). The first step for R2 is to check whether this frame is destined for it by checking the destination MAC address. It matches one configured on R2 therefore R2 continues to process the packet and sees the destination IP address. R2 then sees that this packet isn't destined for it but needs to be routed (Since R2 doesn't own the destination IP address). With it now knowing it has to route the traffic it then looks at its routing traffic to find out how to reach the destination IP address. R2's routing table can be seen below:

R2-Route-Table.png


Upon checking R2 sees that it is directly connected to the network out of its FastEthernet0/0 interface. With this in mind it doesn't even have to perform a recursive lookup since it knows which interface to send the packet to. Now that the network has been found R2 will now arp for the MAC address of SERVER-B since that is the final destination in the path. This way, SW2 can appropriately switch the traffic over to it.

With this in mind, the new MAC addresses added are now the following:

Source MAC Address: 00:00:22:22:22:22

Destination MAC Address: 00:00:BB:BB:BB:BB

This can be confirmed by viewing the ARP cache of R2 and the packet capture running between R2 and the server.

R2-ARP-TABLE.png


capture-r2-serverb.png


Once the frame is sent it then enters SW2 who looks at its MAC Address table to find out what port the server resides at. From looking at the table we can see that the server is off of port FastEthernet1/1 therefore the frame is finally switched and reaches it destination.

SW2-MAC-TABLE.png


When SERVER-B receives the frame it will look at the destination MAC address to determine if it is destined for it. It is. It then continues to process the packet and checks the destination IP address to see if it is still destined for it. It is. It then finally opens up the payload and sees that this was a ping request. All this time the routers and switches had no idea what was in the packet. Since the server matches the destination it got the message. Now it generates a reply message for this and then performs the exact same steps. Check ARP cache, send over to R2, R2 check routing table, check ARP cache, send to R1, R1 check routing table, check ARP cache, send to PC-A. And the switches are in the middle making the frame move. That is it and what is there to show for it? One reply to one ping message shown on PC-A!

PC-A%20PING.png


This has been the basic principles of routing and switching in network communication all using IP and Ethernet protocols. Should you want more in depth tutorials on this I can make them. If you have any queries let me know and I'll do my best to answer them. Please find attached a ZIP folder containing all the captures made in this example.

Hope This Helps,
Josh
 

Attachments

Last edited:
Since the person who posted this has not been back, for whatever reason, since Dec. 2015, don't count on the images being reposted 5 years after the article was written.
 
It seems that the images were hosted on a Google Drive account, so unfortunately we won't be able to restore them.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top