www.flackbox.com
Open in
urlscan Pro
162.159.134.42
Public Scan
URL:
https://www.flackbox.com/cisco-the-life-of-a-packet
Submission: On October 28 via manual from US — Scanned from IT
Submission: On October 28 via manual from US — Scanned from IT
Form analysis 2 forms found in the DOM
https://forms.convertkit.com/landing_pages/282002/subscribe
<form id="ck_subscribe_form" class="ck_subscribe_form" action="https://forms.convertkit.com/landing_pages/282002/subscribe" data-remote="true">
<input type="hidden"
value="{"form_style":"full","embed_style":"inline","embed_trigger":"scroll_percentage","scroll_percentage":"70","delay_seconds":"10","display_position":"br","display_devices":"all","days_no_show":"15","converted_behavior":"show"}"
id="ck_form_options">
<input type="hidden" name="id" value="282002" id="landing_page_id">
<input type="hidden" name="ck_form_recaptcha" value="" id="ck_form_recaptcha">
<div class="ck_errorArea">
<div id="ck_error_msg" style="display:none">
<p>There was an error submitting your subscription. Please try again.</p>
</div>
</div>
<div class="ck_control_group ck_first_name_field_group">
<label class="ck_label" for="ck_firstNameField">First Name</label>
<input type="text" name="first_name" class="ck_first_name" id="ck_firstNameField">
</div>
<div class="ck_control_group ck_email_field_group">
<label class="ck_label" for="ck_emailField">Email Address</label>
<input type="email" name="email" class="ck_email_address" id="ck_emailField" required="">
</div>
<div class="ck_control_group ck_captcha2_h_field_group ck-captcha2-h" style="position: absolute !important;left: -999em !important;">
<label class="ck_label" for="ck_captcha2_h">We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.</label>
<input type="text" name="captcha2_h" class="ck-captcha2-h" id="ck_captcha2_h">
</div>
<button class="subscribe_button ck_subscribe_button btn fields" id="ck_subscribe_button"> DOWNLOAD! </button>
<span class="ck_guarantee">
<a class="ck_powered_by" href="https://kit.com/features/forms?utm_campaign=poweredby&utm_content=form&utm_medium=referral&utm_source=dynamic">Powered by Kit</a>
</span>
</form>GET https://www.flackbox.com
<form action="https://www.flackbox.com" id="searchform" method="get">
<div>
<input type="text" id="s" placeholder="Search" class="form-control" name="s" value="">
</div>
</form>Text Content
* * * Toggle navigation Building your Cloud and Data Center career * Free Lab Guides * CCNA Lab Guide * NetApp Lab Guide * Tutorials * Cisco CCNA Gold Bootcamp Course * NetApp ONTAP Complete Training Course * Cisco BGP Masterclass Course * Cisco Multicast Masterclass Course * Cisco CCNA Tutorials * NetApp Tutorials * SAN and NAS Storage Basics * Cloud Training Videos * Student Login * About * About Me * Testimonials * Resources Home » Tutorials » Cisco CCNA Tutorials » Cisco The Life of a Packet 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. FREE LAB GUIDE Download your complete 350 page Lab Guide covering everything on the latest CCNA exam here. Success! Now check your email to confirm your subscription. There was an error submitting your subscription. Please try again. First Name Email Address We use this field to detect spam bots. If you fill this in, you will be marked as a spammer. DOWNLOAD! Powered by Kit CISCO THE LIFE OF A PACKET VIDEO TUTORIAL JOHN SALMON I kept hearing how getting your CCNA would change your life. Well it’s true. I “Crushed” the CCNA exam and went from working as a mail courier to getting my first tech job as a network lab engineer working for Cisco. Neil’s courses were a critical factor in this. The way he structured the course and provided labs for each section really made it easier to absorb the information. I still go back and watch sections when I am setting up a new lab at work. Thank you so much for the awesome video courses. John Salmon Flackbox Cisco CCNA course student - click here to enroll 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 Libby’s passion for technology drives her to constantly learn and share her insights with others. When she’s not immersed in the world of tech, you’ll find her lost in a good book with a cup of coffee or out exploring nature on her next adventure—always curious, always inspired. * Cisco A Very Basic Introduction to Networking * Cisco Operating Systems Cisco CCNA Gold Bootcamp NetApp ONTAP Complete Course Download your FREE Lab Guide Download your FREE eBook Intro to SAN and NAS Storage Intro to Cloud Computing AlphaPrep Free Trial CATEGORIES * Career Advice * Cisco CCNA Tutorials * Cloud Training Videos * NetApp Tutorials * SAN and NAS Storage Basics Copyright 2024 flackbox.com | Privacy | Affiliates | Contact Me | Testimonials * * * * *