Pass Cisco CCNA 200-301 Exam in First Attempt Guaranteed!

All Cisco CCNA 200-301 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the 200-301 Cisco Certified Network Associate (CCNA) practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

The life of a Packet

1. Introduction

In this section, we're going to examine the life of a packet. So you'll learn about how a packet makes its way all the way from the source to the destination and everything that happens on our hosts, our switches, and our routers to make that happen. So we'll start off by discussing a couple of the protocols that help the source figure out the way to get to the destination; that's DNS, the domain name system, and ARP, the address resolution protocol. After we've covered those, you'll have all the information you need to understand how IP networking works. And we're going to walk through an example of the end-to-end life of a packet all the way from the source to the destination and everything that works together to allow that to happen. This section is really the culmination of everything else—all the other lectures that we've covered up to this point. So it's a big section. By the time we're done, you should be really confident that you understand the fundamentals of IP networking.

2. DNS The Domain Name System

In this lecture, you'll learn about the domain name system, DNS. So we're back to the OSI stack here again. And when a sender composes, the packet starts off with layer seven. The application layer puts that information there. That then gets encapsulated with the presentation-layer information and the session-layer information. And then, when we get down to layer four, we start getting interested as network engineers. The transport layer, the packet, will get encapsulated with the layer 4 header, which includes information like, "Is it TCP or UDP?" and the port number, for example, port 84, HTTP web traffic. Then we encapsulate that with the layer-3 header, which is the IP header.

And on that layer, the sender has to provide the source and destination IP addresses. Now, with some applications, it will actually put the IP address directly in there, but quite often it will use an FQDN, a fully qualified domain name, such as www.cisco.com. And that FQDN has to be resolved to an IP address that we can put into the packet. So that's where DNS comes in. The domain name system resolves that fully qualified domain name, such as www.cisco.com, to an IP address. Enterprises will typically have an internal DNS server or a cluster of internal DNS servers that will resolve the IP addresses of their internal hosts. For example, if I were working for an enterprise called Flatbox.com, we would have our own internal DNS server, which would be responsible for resolving all hosts that were in the Flatbox.com domain. However, that internal DNS server can't know about everything on the entire Internet.

It can't have the entire database there. So for anything external, it's going to need to forward those requests on to an external public DNS server. DNS requests are sent using UDP port 53, which can fail over to TCP on port 53, but normally it's going to use UDP. So let's take a look at how DNS works in the lab. To do that, I'm going to open up a command prompt here. So this is on my Windows hostile entry cmd, and I'll do an Ipconfig all. And you can see on the interface I'm using for the lab that my IP address is one 7223 110, which is 24. And my default gateway router is at 107 223-1254. My DNS server is at one seven-two dot 23 dot four dot one. And the DNS domain that I'm apart of is Flatbox, a dot lab. So let's take a look at the DNS server next. I'm using a Windows server as my DNS server. So let's have a look in Server Manager.

I can click on Tools and then open upDNS, and you can see that the server here is the authority for the domain flatboxa lab.And if I click on that, you'll see that I've already set up address records for some hosts in there. So the hostengineeringa is at 172,234,610 bis at 611, Linuxa is at 172,234; etc. And all these hosts are in the flagboxa.lab domain. If this DNS server received a request for an FQDN that was in a different domain, it would need to forward that out to public DNS to configure that. If I right-click on the server up in the top left corner here and then go to Properties and Forwarders, I don't actually have any configured here, but I would just edit this and put in the IP address of a public DNS server in here.Okay, so that's the DNS setup. If I come back to my local host now and I do an NS lookup for the host of Linuxa, you will see that it will take a second, and then my DNS server is 172 23 4 1, the one I just showed you, and it's resolved Linuxa flatbox a lab to 172 23 4 2. And if I ping Linuxa, then the ping works just fine because it was able to resolve it. So I'll be able to ping that host either by its FQDN, its host name, or by its IP address. OK, so that's how DNS works in a Windows environment. Once they look at DNS on our Cisco routers next.

3. DNS on Cisco Routers

The commands to configure a router to be a DNS client The reason you would do this is if you want the router itself to be able to resolve FQDNs. So for example, if you want to ping Linuxa from the router, you would need to set up a DNS client. Now you don't need to set the router up as a DNS client for DNS traffic to pass through it. This is only if you need the router itself to be able to resolve sqdns to host names so often. We won't do that often when we're working on a router; we're always going to be working with IP addresses.

But if you did want it to be able to resolve host names, the commands to enter are IP domain lookup to allow it to look up a DNS server, IP name server, and then the IP address of your DNS server, IP domainname, and then the primary domain name. And if you want it to also look up additional DNS suffixes, an IP domain list, and then those additional suffixes, Okay, so that's how you configure it to be a DNS client. If you wanted a router to be your DNS server, then to configure that, you would enter those same commands. plus IP DNS Server is a command that configures it as a DNS server. And then you would need to enter address records for everything that you want it to be able to resolve. The command for that is "IP host," and then the host name and then the IP address of that host. Now, you will not usually want a Cisco router to be a DNS server.

Usually you would use an external Windows, Unix, or Linux server to do that, but it is capable of doing it. Okay, those were the commands. Let's configure that in the lab. Next, I'll have a look at the lab typology. First. You can see I've got three routers: R1, R2, and R three. One has got IP address 1010 one. R two is 1010 two. It's also got an interface of 1010, 22, and our three is at 1010, 21. I'm going to configure R3 as the DNS server, and I'm going to configure entries for all three routers there so it will be able to resolve them. And then we'll configure one as the DNS client. Okay, so I've got a window open for both routers. Let's configure the DNS server first, which was our third. I'll do a show IP interface brief just to check the IP addresses right there. Yeah, 1010-21, that's going to be our DNS server. So the commands I'll enter first are IP domainlook up to enable it to use DNS. And I forgot to go to Global Configuration. So configure first to get to Global Configuration, and then IP domain lookup should work. Next up is the IP nameserver to configure where the DNS server is going to be, which is at 1010-21.

Then I'll configure the domain name. So the IP domain name And for this lab, I'll use FlatBox Lab. Only this is a different lab than the one I showed you with Windows because I'm doing it on my Cisco router now. And then the command to make this the DNS server is "ipdns server." So those are my basic DNS commands. Next up, I need to enter addresses for the hosts that I want to resolve. So the command for that is "IP host." The first one is R 1, which is at 1010 1. Then next will be R 2. I'll use command history for this. So I'll hit the up arrow to get that previous command back. And I'm going to edit this using the cursor keys to make it opaque. R2, is it 1010, then the up arrow again? The next host is R three, and that is 1010 21. So let's say you do your hosting. I'll also enter these as FQDNs to show you how to do that. So IP host R one dot flatbox dot lab is at 1010 one, and then R two is at 1010 two.

So I just use the up arrow again there. And I'll edit this and make that R two-dot flatbox dot lab and the correct IP address. And in the last one, Iphostr threeflatbox lab is at 1010, 21. So that's all the configuration that I need for my DNS server. Next up, let's configure R1 to be a DNS client. So I'll go in here, I'll go to global configuration, and then IP domain lookup to allow it to use a DNS server. Then configure the IP name server to be where the DNS server is. That's on our three, which is at 1010, 21. And then the DNS suffix, I'll say IP domain list flatbox lab. Now, if I use end to drop back down to the enable prompt, let's see if I can resolve host names now on R one.So I will try pinging R3 by its host name. And I can see it's resolving it at the domain server at 1010 21.It then resolved that, and I can see that the success rate was five out of five. So that looks all good. Let's also try pinging R two. So this will also be resolved by the DNS server at 1010, dot 1, and it resolved that to 1010, dot 2, and I was able to ping that too. So that's how you configure DNS on your Cisco routers. Next up, we'll have a look at art in the next lecture.

4. ARP Address Resolution Protocol

In this lecture, you'll learn about ARP, the address resolution protocol. As usual, we'll start off by looking at how this fits into the OSI stack. So we've got a sender on the left. It's going to send some traffic to the receiver, and the right header will compose the packet, starting off with the layer seven information. That's the application layer. It will then encapsulate that with layersix, the presentation layer header that will be encapsulated in the session layer header. Then, at layer 4, there is the Transport Layer Header, which will include information such as whether it's TCP or UDP and a report number. That will then get encapsulated in the layer 3 IP header, which includes the source and destination IP addresses. That will then be encapsulated in the Layer 2 Data Link header, which includes the resource and destination Mac addresses, and that will then get put on the physical wire. So, as you saw in the last lecture, the sender can either send directly to an IP address or it can send to an FQDN. If it sends to that fully qualified domainname, then that will need to be resolved into the IP address using DNS. So we'll find the destination IP address.

Then, when the packet gets down to layer 2, the sender also needs to know the destination and Mac address. So when it composes a packet, it needs to know both the destination IP address and Mac address as well. Now, the IP address is a logical address that is controlled by administrators, so it makes sense that we can have that referenced in the application either directly as the destination IP address or as the FQDN, which can be resolved by DNS. But the Mac address, on the other hand, is not a logical address. We just have that great, big, flat global address space. So it's not really possible either for the user to enter the destination Mac address himself or for it to be configured in the application. So because of that, we need to ensure that it can be automatically derived. We need a protocol that's going to be able to figure out what the Mac address is automatically. And that's what ARP is.

The address resolution protocol ARP maps the destination IP address to the destination Mac address. So in the example here, we've got a sender on the left at 172 23 4 1, with Mac Addresses 1, 2, and 3, and it's going to send some traffic to the receiver on the right with IP Address 172 23 4 2 and Mac Address 2, 3, and 4. And in our example, the sender already knows that it wants to send traffic to IP address 172 23 four two. So it can compose the packet as far as the layer-3 IP header, but it doesn't know the receiver's Mac address yet, so it's going to use ARP to find that out. So it will send out an Art request, which is a layer to broadcast the app request, saying, "Hey, I'm looking for 172, 234, 2." What's your Mac address? That will come from the sender's Mac address of "1 2 3," and it goes to a destination Mac address of "F f." That is the layer to broadcast from. Obviously, the sender has to send it everywhere because it doesn't know what the intended destination's Mac address is yet. That will come into play at the switch.

The switch will see that it is broadcast traffic, so it will flood it out to all parts. It will hit everything plugged into that switch, including, in our example, the receiver on the right, which will process that request. It will see that it's looking for 172-2342, which is its own IP address. So it will respond to the art request. It will send an Art reply back saying "I'm 172, 234, 2," and "here's my Mac address," which comes from its source mac of 2 3 4, and the destination mac address is the original sender's unicast mac address of 1 2 3." The receiver knows exactly where to send it back because the original Mac address of 1 2 3 was in the ARC request. The switch will then send that Art reply just out of port one down to the original sender because that was unique as traffic and it's for a known Mac address that's already in its Mac address table. Okay, so that is how art works. When both hosts are on the same IP subnet, art replies are saved in the host's art cache so that it doesn't need to send an art request every time it wants to communicate with somebody else to view the art cache. We can do that on Windows with the ARPA command.

On a Linux host, we use the ARP command. You can also see the commands there on the slide to flush the cache if you need to. We wouldn't normally do that, but if we were troubleshooting it or if you were using cash and it somehow got corrupted, that's how we would clear it. So let's have a quick look at that in the lab. So I'm here on a Windows host. Let's take a look at the IP address. It's 172, 234, 1, For this example, I've got a Linux host at 172 23 four two.So let's ping that to generate some traffic. Okay, so in the host here, I'm going to ping 172, 234, and 2. So it knows what the destination iPad addresses are, but it doesn't know what the matching destination Mac addresses are yet. So it's going to do an art request to find out. That happens in the background. You don't see it happening here. If I now do an Art A, I should see an entry for 172 23 4 2, which is the Linux host, and I can see what its Mac address is. If I jump onto that Linux host and I do an ARPin there, then I'll see an entry for 172 23 four two.Because I had some traffic between those two hosts, it got an entry in the staff cache for that host's IP address and its Mac address as well. Okay, so that's how it works when both hosts are in the same subnet. In the next lecture, we'll see how art works when traffic has to go through.

Cisco CCNA 200-301 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass 200-301 Cisco Certified Network Associate (CCNA) certification exam dumps & practice test questions and answers are to help students.