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 text tutorial.

The term “Cisco The Life of a Packet” refers to a concept used in Cisco networking to describe the journey of a data packet as it travels through a network. It is a fundamental concept in understanding how data is transmitted and delivered from one device to another in a Cisco network.

The life of a packet can be broken down into several stages:

Generation: The packet is generated by a source device, such as a computer or server, when data needs to be sent to a destination.
Encapsulation: The packet is encapsulated with various headers and trailers, including source and destination IP addresses, protocol information, and other necessary details.
Transmission: The packet is transmitted from the source device and travels through the network infrastructure, such as routers and switches.
Routing: Routers examine the destination IP address to determine the best path for the packet to reach its destination.
Switching: Switches forward the packet within a local network based on the destination MAC address.
Decapsulation: When the packet reaches its destination, the headers and trailers are removed, and the original data is extracted.
Delivery: The packet is delivered to the intended application or service on the destination device.

Understanding “The Life of a Packet” is crucial for network administrators and engineers as it helps them troubleshoot network issues, optimize network performance, and ensure the efficient delivery of data across the network. It is also a fundamental concept in networking certifications, such as Cisco’s CCNA and CCNP.

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.

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.

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.

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. cisco data packet.

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 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.

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.

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.

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.

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.

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.

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. cisco data packet.

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.

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.

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 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.

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 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. cisco data packet.

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.

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.

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

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.

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.

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. (cisco data packet)

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 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.

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.

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.

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.

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.

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.

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.

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. (cisco data packet)

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.

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.

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.

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.

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.

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.

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.

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.

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 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.(cisco data packet)

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.”

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.

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.

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 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. cisco data packet.

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 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.”

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. (cisco data packet)

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.

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. (cisco data packet)

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.

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.

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.

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.(cisco data packet).

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.

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.

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.

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.

so, in this tutorial you learnt about the journey of a cisco data packet.