Cisco The Life of a Packet

In this Cisco CCNA tutorial, we’re going to walk through the life of a packet from the sender through to the receiver and how everything works together to make that possible. Scroll down for the video and also the text tutorial.

Cisco The Life of a Packet Video Tutorial

YouTube video

Arturo Ortiz

Arturo Ortiz Gonzalez

I was able to land my first job before finishing my college degree as a Network Consulting Engineer at Cisco after lots of hard work and following Neil’s courses and tips as a guide, I’m very thankful with Neil for proving great information and explaining complex topics in an easy and understandable manner.

Arturo Ortiz
In the example here, we've got Host A on the left, and it's going to send some HTTP traffic to our Web Server over on the right, which is www.flackbox.com. It's going to use the FQDN to send the traffic. So, it's also going to need to resolve that FQDN name to the IP address using DNS.

 

Also, it's a routed network. We've got different IP subnets there, and we've got a couple of routers in the middle of the topology. I've deliberately included multiple subnets, routers, and a DNS Server because I want it to mimic what you would see on a real-world network.

 

Cisco The Life of a Packet

 

OSI Reference Model - Encapsulation

 

Again, we're going to use the OSI stack model for this. We're going to be composing that web traffic and sending it to the Web Server from our source on the left. It will compose the packet starting off with the information at the Application Layer, which will be encapsulated in the Presentation Layer header, and then will be encapsulated in the Session Layer header.

 

OSI Reference Model - Encapsulation

 

We then get down to the really important information for networking, so Layer 4, the Transport Layer. This is web traffic, so it's going to be sent with TCP, and the destination port is going to be Port 80.

 

When the sender on the left is composing this web traffic, it needs to make the Layer 3 header next, where it needs to enter the destination IP address. It doesn't know the destination IP address because the user just opened up a browser and entered www.flackbox.com. The sender will need to resolve that to an IP address to complete this packet. It's going to use DNS for that.

 

The Life of a Packet

 

Host A at 10.10.10.10/24 wants to send a packet to the FQDN of www.flackbox.com, but it doesn't know the destination IP address. So it will hold onto that packet, and in the meantime, it will send the DNS request to its DNS Server at 10.10.100.10. The host already knows its IP address, its subnet mask, its default gateway, and its DNS Server.

 

The Life of a Packet

 

Host A will compare its IP address and subnet mask to the destination address of the DNS Server, and it sees that it's on a different IP subnet, so the DNS request will need to be sent via its default gateway. Host A will hold the DNS request and send a broadcast ARP request for its default gateway, which is at 10.10.10.1.

 

You can see that in the diagram here, Host A sends an ARP request. It comes from 10.10.10.10, it says it's looking for its default gateway 10.10.10.1, and it says, "Hey, what's your MAC address." So, that comes from a source MAC of 1111.2222.3333, and it goes to a destination MAC of the Layer 2 broadcast address of FFFF.FFFF.FFFF.

 

The Life of a Packet 1

 

The ARP request will be received by Switch 1 on the left. Switch 1 will add an entry in its MAC address table, mapping Host A's MAC address of 1111.2222.3333 to Port 1. Switch 1 will then flood broadcast traffic out all ports apart from the one that it was received on.

 

The Life of a Packet 2

 

That will go out of Port 2. The ARP request is still from 10.10.10.10, looking for 10.10.10.1, with a source MAC of 1111.2222.3333, a destination MAC of FFFFF.FFFF.FFFFF.

 

The Life of a Packet 3

 

That will hit Router A's interface of 10.10.10.1. Router A will process the ARP request and see that it is for itself. It will then send a unicast ARP reply back to Host A, and Router A will also add an entry for Host A, mapping IP address of 10.10.10.10 to the MAC address of 1111.2222.3333, and that will be added to its ARP cache. It will then send the ARP reply.

 

The Life of a Packet 4

 

 

Switch 1 will receive that, and it will add an entry in its MAC address table, mapping Router A's MAC address of 4444.5555.6666 to Port 2. Switch 1 will then send the ARP reply out only Port 1, which Host A is plugged into because the ARP reply is a unicast reply, and the switch already has Host A's MAC address in its MAC address table. It knows it's available out of Port 1.

 

The Life of a Packet 5

 

Okay, so there goes the ARP reply. It says, "I'm 10.10.10.1, and here's my MAC address." That came from Router A, the source MAC is 4444.5555.6666, and the destination MAC is 1111.2222.3333, on Host A.

 

The Life of a Packet 6

 

Host A will receive that, it will then add an entry for Router A, mapping Router A's IP address of 10.10.10.1 to the MAC address of 4444.5555.6666, it will add that to its ARP cache, and it will then use that whenever it needs to send traffic to another IP subnet. Host A will then send the DNS request for www.flackbox.com.

 

The Life of a Packet 7

 

That DNS request will say, "Tell me the IP address of www.flackbox.com, please?" It comes from a source MAC of 1111.2222.3333 on Host A. It goes to Host A's default gateway MAC address of 4444.5555.6666, the source IP is 10.10.10.10 on Host A, and the destination IP is its DNS Server at 10.10.100.10.

 

The Life of a Packet 8

 

That is unicast traffic, so Switch 1 will send the DNS request out only Port 2, which Router A is plugged into, and which the switch already has its MAC address table. So, the DNS request will come into Router A.

 

The Life of a Packet 9

 

It will receive the request and see that the destination IP address is 10.10.100.10, the DNS Server. Router A has an interface in that subnet, 10.10.100.0/24, so it knows that the destination should be available out of that port. It doesn't know the MAC address of 10.10.100.10 yet, so it will hold the DNS request packet and send an ARP request out of the 10.10.100.1 interface.

 

The Life of a Packet 10

 

There goes the ARP request. That's from 10.10.100.1 on the router, it's looking for 10.10.100.10, asking what its MAC address is. It comes from a source MAC of 8888.9999.AAAA, which is on that interface on the router. The destination MAC is always the same for an ARP request FFFF.FFFF.FFFF, the Layer 2 broadcast address.

 

The Life of a Packet 11

 

The ARP request will be received by Switch 3. Switch 3 will add an entry in its MAC address table, mapping Router A's MAC address 8888.9999.AAAA to Port 1. It will then flood the broadcast traffic out all ports apart from the one it was received on.

 

The Life of a Packet 12

 

That will go down to the DNS Server out Port 2 as well. Again, the ARP request looks the same as from 10.10.100.1, looking for 10.10.100.10, from a source MAC of 8888.9999.AAAA, destination MAC of FFFF.FFFF.FFFF.

 

The Life of a Packet 13

 

The ARP request hits the DNS Server's interface of 10.10.100.10. The DNS Server will process the ARP request and see that it's for itself. It will then send a unicast ARP reply back to Router A.

 

The DNS Server will add an entry for Router A, mapping IP address of 10.10.100.1 to MAC address 8888.9999.AAAA to its ARP cache. It will use that whenever it needs to send traffic to another IP subnet because 10.10.100.1 is its default gateway.

 

The Life of a Packet 14

 

So there goes the ARP reply from 10.10.100.10, saying, "Here's my MAC address of source MAC 3333.4444.5555," going back to the router with a destination MAC of 8888.9999.AAAA.

 

The Life of a Packet 15

 

Switch 3 will receive that, and it will add an entry in its MAC address table, mapping the DNS Server's MAC address of 3333.4444.5555 to Port 2. It will then send the ARP reply out only Port 1, which Router A is plugged into because that is a unicast reply, and it already has Router A in its MAC address table.

 

The Life of a Packet 16

 

So, there goes the ARP reply unchanged on its way to Router A.

 

The Life of a Packet 17

 

Router A will receive that. It will then add an entry for the DNS Server, mapping IP address of 10.10.100.10 to MAC address 3333.4444.5555 to its ARP cache. Router A will then send the DNS request it was holding from Host A to the DNS Server.

 

The Life of a Packet 18

 

Now, the source and destination MAC address of a packet are updated hop by hop, but the source and destination IP addresses always remain the same end to end unchanged from the original source to the final destination.

 

The source and destination MAC addresses in our example will be updated to come from Router A and go to the DNS Server for this DNS request. The source and destination IP addresses are still Host A 10.10.10.10, and the DNS Server is the destination at 10.10.100.10.

 

The Life of a Packet 19

 

So there goes the DNS request, DNS request's saying, "Tell me the IP address of www.flackbox.com." The source and destination MAC addresses are now changed to be 8888.9999.AAAA on Router A, going to 3333.4444.55555 on the DNS Server. The source IP is still 10.10.10.10 on Host A. The destination IP is still 10.10.100.10 on the DNS Server.

 

The Life of a Packet 20

 

Switch 3 will send out only Port 2, which is the DNS Server plugged into it, which Switch 3 already has in its MAC address table.

 

The Life of a Packet 21

 

The DNS request gets sent down to the DNS Server, the DNS Server will receive the DNS request packet and see that the destination is itself.

 

The Life of a Packet 22

 

OSI Reference Model – De-encapsulation

 

Looking at the OSI stack again. It comes in on the physical wire, and the receiver will then process the packet starting at the bottom of a stack working its way up. It sees that the destination MAC address is 3333.4444.5555, which is itself. So it will carry on processing the packet.

 

OSI Reference Model – De-encapsulation

It sees that the destination IP address in the Layer 3 header is 10.10.100.10, which again is itself, it will carry on processing the packet. Then in Layer 4, Transport header, it sees that it's UDP and it's at Port 53.

 

So, it knows that this is a DNS request because DNS uses UDP port 53. It will then pass the packet up to the rest of the stack. So look at the Session header, the Presentation header, and the Application header, and it will process that DNS requests.

 

OSI Reference Model – De-encapsulation 1

 

The Life of a Packet

 

The server will look in its DNS database and see an address record for www.flackbox.com at 10.10.12.10. That was configured in DNS. It will send the information back to Host A in a DNS response. It knows to send the response to 10.10.10.10 because that was the source IP address in the DNS request.

 

It knows to send it via Router A because Router A is its default gateway, and the destination is in another subnet. The DNS Server already has Router A's MAC address in its ARP cache, so it does not need to send an ARP request for this.

 

The Life of a Packet 23

 

So, the DNS reply says that "www.flackbox.com is at 10.10.12.10." The source MAC is 3333.4444.5555. The destination MAC is its default gateway at 8888.9999.AAAA. Source IP is the DNS Server at 10.10.100.10, and the destination IP is Host A at 10.10.10.10.

 

The Life of a Packet 24

 

Switch 3 will receive the DNS response, and it will send out only Port 1, which Router A is plugged into and which it already has in its MAC address table. So, it passes that onto Router A.

 

The Life of a Packet 25

 

Router A will receive the DNS response packet and see the destination IP address 10.10.10.10. It has an interface in the subnet of 10.10.10.0/24, so it knows that the destination should be available out of that port, and Router A has the MAC address for 10.10.10.10 in its ARP cache. So, again it doesn't need to send another ARP request.

 

The Life of a Packet 26

 

It will send the DNS reply out of that interface, again it is going from source IP 10.10.100.10, the DNS Server going to destination IP 10.10.10.10 Host A. So that doesn't change, but the source and destination MAC will be updated. Source MAC is 4444.5555.6666, and the destination MAC is 1111.2222.3333, which is the MAC address is on the left hand side of Router A.

 

The Life of a Packet 27

 

Switch 1 will receive the DNS response and send out only Port 1, which Host A is plugged into and which it already has in its MAC address table. So, it passes the DNS reply down to Host A.

 

The Life of a Packet 28

 

Host A now learns from that DNS response that www.flackbox.com is available at 10.10.12.10. It can now update the packet it was waiting to send to www.flackbox.com with that destination IP address.

 

Host A sees that the Web Server is not on its own subnet, so it knows that any packets it sends there must go via its default gateway. At this point, Host A has learned the IP address of the Web Server through DNS.

 

The Life of a Packet 29

 

OSI Reference Model - Encapsulation

 

Now, we're looking at the web packet that Host A was holding before being able to compose it as far as Layer 4, but it couldn't put the Layer 3 IP header on there because it didn't know the destination IP address yet.

 

OSI Reference Model - Encapsulation

 

It's just received that from the DNS Server, so it can carry on composing that packet and knows that the destination is 10.10.12.10, and it sees that it's on a different IP subnet, so it knows that the destination MAC address is its default gateway, which it already knows is at 4444.5555.6666. It will then put that web traffic onto the physical wire.

 

OSI Reference Model - Encapsulation 1

 

The Life of a Packet

 

So here's our HTTP Get Request, the source MAC is 1111.2222.3333. The destination MAC is the default gateway 4444.5555.6666. Source IP is its own IP address, 10.10.10.10, and destination IP is the Web Server at 10.10.12.10.

 

The Life of a Packet 30

 

That will hit Switch 1, which will send the packet to Router A, which it already has in its MAC address table. The packet will come into Router A.

 

The Life of a Packet31

 

It sees that the destination IP address is 10.10.12.10, and in our example, Router A does not have any interfaces in the 10.10.12.0/24 subnet. So, in that case, it's going to need a route to get there. The route can be either statically configured by an administrator or learned dynamically through a routing protocol, which also would be configured by the administrator.

 

The Life of a Packet 32

 

So for our example, let's say that the administrator has already configured a static route for 10.10.12.0/24, with the next hop address of 10.10.11.2, which is on the next hop router. Router A has an Ethernet interface in the 10.10.11.0 subnet.

 

It doesn't know of the MAC address for the next hop address of 10.10.11.2 yet, though. So, it will hold the HTTP packet from Host A, and it will send an ARP request out that interface in the 10.10.11.0 subnet looking for 10.10.11.2.

 

The Life of a Packet 33

 

So there goes the ARP request, it's from 10.10.11.1, saying it's looking for 10.10.11.2, "What's your MAC address?" It comes from a source MAC of 5555.6666.7777, going to the Layer 2 broadcast address of FFFF.FFFF.FFFF.

 

The Life of a Packet 34

 

The ARP request will hit Router B's interface at 10.10.11.2, and it will see that the ARP request is for itself. It will send a unicast ARP reply back to Router 1. While it's doing that, Router B will add an entry for Router A, mapping the IP address 10.10.11.1 to MAC address 5555.6666.7777 to its ARP cache.

 

The Life of a Packet 35

 

So the ARP reply goes back, it says "Hey, I'm 10.10.11.2, and here's my MAC address of 6666.7777.8888, going to the destination MAC of 5555.6666.7777."

 

The Life of a Packet 36

 

Router A will get the information, and it can know forward the HTTP packet it was holding to Router B. So, it's the original HTTP Get Requests from Host A. The source IP is always the same, so it's still 10.10.10.10 on Host A, going to the destination IP of 10.10.12.10 on the Web Server.

 

The source and destination MAC addresses will get updated for this hop. Therefore, the source MAC is 5555.6666.77777 and the destination MAC is 6666.7777.8888.

 

The Life of a Packet 37

Router B will receive the HTTP packet and see that the destination IP address is 10.10.12.10. Router B has an interface into the subnet of 10.10.12.0/24, so it knows the destination should be available out that port. But it doesn't know the MAC address of 10.10.12.10 yet, so it will hold the HTTP packet and send an ARP request out that 10.10.12.1 interface.

 

The Life of a Packet 38

 

So, there goes the ARP request. It's from 10.10.12.1 looking for 10.10.12.10, asking for the MAC address. It comes from a source MAC of 7777.8888.9999, going to the Layer 2 broadcast of FFFF.FFFF.FFFF.

 

The Life of a Packet 39

 

The ARP request will be received by Switch 2. Switch 2 will add an entry in its MAC address table mapping Router B's MAC address of 7777.8888.9999 to Port 1. Switch 2 will then flood the ARP request broadcast traffic out all ports apart from the one it was received on, so that will be sent out of Port 2.

 

The Life of a Packet 40

 

The ARP request will hit the Web Server's interface at 10.10.12.10. The Web Server will process the ARP request and see it is for itself. The Web Server will then send a unicast ARP reply back to Router B.

 

It will add an entry for Router B, mapping IP address of 10.10.12.1 to the MAC address of 77777.88888.9999 to its ARP cache. That's its default gateway, so it will use that whenever it needs to send traffic to another IP subnet.

 

The Life of a Packet 41

 

The ARP reply will go back, saying, "I'm 10.10.12.10. Here's my MAC address of 2222.3333.4444 going to the destination MAC of 7777.8888.9999."

 

The Life of a Packet 42

 

Switch 2 will get that and add an entry to its MAC address table, mapping the Web Server's MAC address of 2222.3333.4444 to Port 2. Switch 2 will then send the ARP reply out only Port 1, which Router B is plugged into, which it already has in its MAC address table. So, there goes the ARP reply unchanged from the Web Server.

 

The Life of a Packet 43

 

Router B will get that, and add an entry for the Web Server, mapping IP address 10.10.12.10 to MAC address 2222.3333.4444 to its ARP cache. And then, Router B will send the HTTP Request it was holding to the Web Server.

 

The Life of a Packet 44

 

Again, it's the original source IP on Host A, 10.10.10.10. The original destination IP in the Web Server of 10.10.12.10. The MAC addresses will get updated with the source MAC of 7777.8888.9999 and the destination MAC of 2222.3333.4444.

 

The Life of a Packet 45

 

Switch 2 will send that HTTP Request out only Port 2, which the Web Server is plugged into, and which the switch already has in its MAC address table. Finally, the HTTP Get Request will reach the Web Server.

 

The Life of a Packet 46

 

OSI Reference Model - De-encapsulation

 

So, it comes in on the physical wire. The Web Server will look at the Layer 2 header and see that the destination MAC address is 2222.3333.4444, which is itself, so it will carry on processing it. It will look at the Layer 3 IP header and see the destination IP address is 10.10.12.10, which again is itself. It will carry on processing it.

 

OSI Reference Model - De-encapsulation 3

 

It will look at the Layer 4, Transport header, see that it's TCP, Port 80. So, it knows it is web traffic. It will then carry on up through the Session, the Presentation, and the Application Layer, and the web traffic has now reached the Web Server.

 

OSI Reference Model - De-encapsulation 4

 

The Life of a Packet

 

The ARP and MAC address tables are already built, so any subsequent packets in either direction will flow without any need for ARP requests or switch flooding.

 

The Life of a Packet 47

 

So, let's say the second packet in the session goes from Host A, so it will send the HTTP Get Request. It comes from a source MAC of 1111.2222.3333, going to a destination MAC of its default gateway 4444.5555.6666.

 

The source IP is 10.10.10.10 and the destination IP is 10.10.12.10. It already has the destination MAC address in its ARP cache, so it can just immediately send the packet.

 

The Life of a Packet 48

 

That will get to Router A, which also already has everything in its ARP cache. So the HTTP Get Request is still from source IP 10.10.10.10, going to the Web Server at 10.10.12.10. The MAC addresses will be updated to be relevant for this hop which was a source MAC of 5555.6666.7777, a destination MAC of 6666.7777.8888.

 

The Life of a Packet 49

 

That will hit Router B, and again, it's got an interface in the subnet of 10.10.12.0, so it knows what interface to send out of. Source IP remains unchanged, 10.10.10.10, destination IP is still 10.10.12.10. The source MAC gets updated to 7777.8888.9999. The destination MAC gets updated to 2222.3333.4444, and we've got traffic going end to end.

 

The Life of a Packet 50

We covered the complete life of a packet from end to end, and you now have a really good knowledge of how IP networking works. Honestly, there's really not much more to it than that. What we're going to be covering in the following lectures are the different features and functions that are available on our routers and switches to support that and how to configure them.

 

Additional Resources

 

Tracing a Packet From Network Ingress to Egress, or "The Life of a Packet": https://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/13713-42.html

How does Routing and Switching Work?: The Life of a Packet: https://www.sysnative.com/forums/threads/how-does-routing-and-switching-work-the-life-of-a-packet.10431/

Packet flow in different Network: https://www.geeksforgeeks.org/packet-flow-in-different-network/

 

Want to practice Cisco CCNA technologies on your laptop? Download my complete 350-page Cisco CCNA Lab Guide for free.

 

Click Here to get my Cisco CCNA Gold Bootcamp, the highest rated CCNA course online with a 4.8 star rating from over 20,000 public reviews.

Libby Teofilo

Text by Libby Teofilo, Technical Writer at www.flackbox.com

With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.