IPv4 default gateway issues
How important is our default gateway? It’s very important. If you don’t have the correct information regarding the default gateway, you’re not going anywhere. You’re staying inside your local network, inside your subnet. You’ll never ever be able to reach destinations outside of your own subnet.
We always think about the default gateway from the perspective of a client. But our router, if it doesn’t have information pointing itself to a next hop IP address for all traffic that it doesn’t have specific information for, then those destinations are unreachable. We just discussed that static route and more specifically that static default route.
So here we see, our static default route configured on branch 0.0.0.0/0 next hop IP of 192.168.1.2. We can see it’s the gateway of last resort here, gateway of last resort. So if this branch router doesn’t have anything specific in its routing table for 172, it will use this default route. This could be misleading for you, I’m worried at this point. There’s a command in global configuration mode that you might’ve seen, you might’ve used, and it didn’t work like you thought it was. It’s the command ip default-gateway.
The command ip default-gateway issued on a router does not do anything when the router is a router. If you were to turn off routing then it would take effect. So be very cautious about thinking that, that ip default-gateway command issued on our router is going to do anything for you. Again you have to turn off routing with the no ip routing command which you don’t usually do unless you’re making the router a host because maybe it’s running services for you, okay. So be careful about that. This is showing us the quote default gateway as installed by the ip route command and not the default-gateway command.
Let’s focus on PC1 now in regards to the default gateway. If you’ve never used the route print command in Windows, essentially this is what it’s doing for you. It’s showing you the PC’s routing table. Now I’m going to use routing table loosely here. It’s not the routing table we have on our router, but it’s a listing of entries on that particular PC that’s going to point the PC to where it should send the packet. So remember when we discussed earlier in our CCNA studies that we are going to determine whether the destination we’re trying to communicate with is either local or remote. And we compare our IP address and subnet mask and that network portion. We determine from that calculation to the IP address of that destination if that IP is in the same network, traffic stays local. If not, we have to send it to our default gateway.
C:Windowssystem32>route printIPv4 Route Table===========================================================================Active Routes:Network Destination Netmask Gateway Interface Metric0.0.0.0 0.0.0.0 10.2.10.1 10.1.10.100 11
And the output of this route print is showing us that if we need to send our traffic to the default gateway, so 0.0.0.0, 0.0.0.0 any destination outside of our local network, send it to this particular IP address. Now, do you see anything wrong here? Let’s put on our troubleshooting hats. Do you see anything wrong? And if you do, make a mental note of it because I see something wrong here.
On our client PC1 that gateway, that IP address for the default gateway appears to be wrong to me. Yeah, I’m going to assume a 24-bit mask and even if I assume a 16-bit mask, I still have a problem. The default gateway must be in your subnet. There’s no way around that. The default gateway must be in your subnet, so this isn’t going to work. This would be an indication that if the client was statically configured that we type out of it, or if the DHCP server had been configured with the wrong default-router command. Well we want to adjust that, should be the IP address of the router in the subnet and it should be 10.1.10.1 based on the topology.
In both those examples we just provided, the scope of the issue would be completely different. If we type out our default gateway more than likely, only one PC would be affected by that if we were statically configuring IP addresses because we probably wouldn’t have typed, wouldn’t in all the machines. But if it was DHCP that was handing out that default gateway information, then all of the clients in that subnet would’ve been affected. So a big difference in scope here in regards to, whether we were statically configuring it or whether it was being handed out by a DHCP server.
IPv4 name resolution issues
We’re Cisco folks, right? So we’re not usually the people who set up the domain name system, or DNS servers or the WINS servers. So does that mean we don’t have to care about it? No, well our job is quite simple. For name resolution so that your folks can get to your .coms, your .edus, your .cas, whatever that might be, they have to be pointed to a DNS server that is working. And there might also be an essential name resolution that is internal to your organization as well. And when our server folks want to distribute a new WINS server or a DNS server, we have to make sure that we have properly updated those parameters on the DHCP servers, that are typically the ones burdened with disseminating the name resolution servers down to your clients.
Indeed, usually we will not be the ones responsible for those DNS servers, and Cisco makes a good note of it right here. We are modifying the host file on the PC to prove that DNS is working. So here you can see how to modify the host file, which is a text file and we will add this entry here 172.16.1.100; the name of server.
C:WindowsSystem32driversetchosts
172.16.1.100 Server
So now that we’re set up here, with the name of the server going back to that specific IP address, let’s go ahead and do a ping and let’s see the result we get.
So we ping server instead of the IP address that you were using earlier and we can see the result here.
We received a successful response of 172.16.1.100, meaning we had name resolution from that host file. Now what do we really rely on that host file in the real world? Here is the only time I update my hosts file is when I’m working with some proprietary program that’s internal to my organization, that needs to be pointed to a backend server for that application. And I’ll read the README for it and it says, “Update your host file with this information”, that’s when I do it. So this is not a scalable solution. This is not the sort of thing that a Cisco network engineer would want to get into. This is, you’re in the weeds if you’re trying to fix problems by updating a host file. So what do we want to take away from this? This is really what we want take away. If you can ping that hostname, and DNS servers are being utilized for name resolution, what does that tell us? Well a successful ping tells us many different things here.
First and foremost, you can see that, that name has to be converted to an IP address which it has been here. That means name resolution is successful. We’ve received successful replies now, so we have connectivity at layer 3 as well. Do we have connectivity at layer 2? Yeah because it was successful so we were able to successfully create our frames as well. And then they were able to be converted to bits and cross the physical wire. So by being able to ping the hostname we take it a step further and are able to verify that name resolution is working as well. So we can hit more layers of the OSI model instead of just layer 3, 2, and 1 like we do if we’re pinging an IP address.
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
