ICND2 200-105

ICND2 200-105

Identification of Current and Desired Path

As we began our discussion here, I asked you what do you have to think about for end-to-end connectivity. Of course we have to think about the devices. That led us down one thought process and we could align that with the other thought process that I brought up which is good layer 3. At this point, we might have an issue, where we can't get traffic from one place to the other. We see we have good physical up/up interfaces, no duplex mismatches then we move on to layer 3. And if we move on to layer 3, we're going to be looking at the routing table.

So, I'd like you to take this time to analyze this routing table.

Troubleshooting Routing Tables

Will PC1 be able to connect to the server? Yes or no? We typed in on PC1 ping 172.16.1.100. Will we have connectivity? Alright, we can't see or hear your answers. But I'm hoping you said no. No, PC1 would not be able to connect to the server. We're looking at the routing table of our branch router right now. Do you see an entry in the routing table for the branch router for the 172.16 network that the server belongs to? I see some 10 entries as well as some 192 entries, nothing related to 172 at all. So PC1 would execute a ping here over to 172.16.1.100 and the branch router would have to respond back to the PC, wouldn't it? And what type of response would it send back to the PC?

It would send U, the letter U, which is that code that we try to prepare you for destination unreachable. So we've got to solve this. This is the layer 3 issue and the solution is going to be getting the branch router educated of that subnet that is in our routing domain, in our autonomous system, but not present in the routing tables of every router.

So we just mentioned the word "educate our router". How do we educate our router?

Well we have a few types of routes, we get those that happen because we have an up/up interface with the IP address those are directly connected. Very, very important. And we also get local host routes, which is something that is in the newer operating systems. If you are working with older IOSs like 12.4, you tend to not see local host routes. But we get these now inside of the Cisco IOS. They clutter our routing table little bit, doesn't make it easier to read, but it points to the router's own IP addresses, okay. Then we have a static routing plugged in for this one router. Put the IP route command in global configuration mode saying, I'm going to point you to this not directly connected subnet that you don't know about and I'm going to indicate the next hop IP address of that. We then have dynamic routing, which is going to handle the bulk of all routing challenges for us that's your Open Shortest Path First, or OSPF, your Enhanced Interior Gateway Routing Protocol, or EIGRP, your Border Gateway Protocol or even Routing Information Protocol, or RIP. But there are a lot of routes that may be present inside of our own autonomous system and there are far more outside of our autonomous system. How do we account for a large number of networks, without necessarily trying to jam them in all uniquely inside of the routing table?

Well in that case, I would make you configure them all statically just to keep you busy all the time. How would I accomplish reaching all of those different destination networks without having to make unique entries is where we get to your default route. Let's create a static default route that's pointing our traffic off to a particular location if I don't have a better entry in my routing table. But I also want to advertise that static default route if I'm using something type of routing protocol inside my autonomous system. So I would inject that into the routing protocol I'm using whether its EIGRP or OSPF and allow all the other routers to know. So if those routers need to forward the traffic on, they know who to send it to along the path and then eventually it leaves my organization.

This is a big deal. We want you to know this one. We don't want you to just know the default static route, we want you to know the dynamic default routes. How do we do it for OSPF, do you remember? You might've seen it in your earlier CCNA journey. It's a command, it's an awesome command that works beautifully and I mean beautifully. We go to that router that has the default static route, then we advertise that, how do we do that?

That would be in router OSPF configuration mode and I would type in default information originate. EIGRP is a little harder and we haven't discussed that but it's done with one of the three ways. We can execute a network command of all zeros if we have a static route that's kind of sporadically, that won't work all the time. You can use the default network command that's really tricky to work with. I'm not going to say why, but it's really tricky and then there's a really tried and true way. What's the tried and true way of advertising a dynamic route for the default route inside of EIGRP? That would be using redistribution. We're not going to pull any punches, redistribution basically says, I'm going to extract the information from this other source and that source being static routing and I'm going to put it into EIGRP as a dynamic route. Then that works beautifully.