ICND2 200-105

ICND2 200-105

Troubleshooting EIGRP Routing Tables

Now we have to remember the other aspect of the network command. I want you to think that the network command enables the routing protocol for interfaces, but another thing will help you build that understanding better. By including that interface in the process, you are making it part of the autonomous system. Even if you do not expect a neighborship, you are making it part of the autonomous system. And so, what if you did not make a network part of the autonomous system because you did not include it with the network command? Well then, other routers are not going to know how to reach it because it's not part of the autonomous system. So we need to validate and on HQ, we look at the commands that are on it. This is a tricky one.

EIGRP Example Deployment

HQ#show ip protocols
...
Routing Protocol is "eigrp 100"
...
  Routing for Networks:
    192.168.1.0
    10.0.0.0
...

I see a problem here. It says HQ, Routing for Networks 192.168.1.0 and 10.0.0.0. Is that accurate? Let's look at HQ. We're missing something and in the same time we're routing for a network that we shouldn't be.

What does that even mean when we have a network command like the 10 network on HQ? Is that doing anything? No. Why? Because there are no local interfaces in the 10 network and I do not want you to think that we'd have to include networks that are not local to us. That's a bad thought process because it's not a filter and it's not saying what you're permitted to allow advertisements to flow, or saying here's what I'm going to be talking to you about. It's about, here are my local interfaces and the network spaces that are on those. Once one router injects advertisements into the process, they'll flow freely through the autonomous system, through routers that do not have that specific network as a network statement. So you have to have a really good understanding of that network command. Don't do extra either. So, what is our failure? One failure was adding a network command that we didn't need to. It's not going to break things, but there is something breaking this topology and what is it?

We need another network command. We need a network command to enable EIGRP on the interface that is part of the 172.16.1.0/24 network.

So what would the network command be? And don't give us a wildcard mask. Execute the network command without a wildcard mask. What would it be? I want you thinking. I'm going to type it up. I'm going to write it up. I'm going to break out no path. What would it be?

Well let's start off with a hint for everybody. It starts with network.

But I want the value. I want that dot and decimal value.

All right. So what is that dot and decimal value? Hopefully, you had a chance to formulate it yourself, but it would be, first of all, a class B address, so I only care about the first two octets of 172.16 and then, I can zero out the rest. So 172.16.0.0.

And oh by the way, do you see how the tenant work, does zero out the second, third, and fourth octets? We don't know what was typed, but we know how the routers going to take it without a wildcard mask. Any 10 IP address in a network command is going to be taken that way without a wildcard mask. So this is a great discussion we're having here.

Here is something interesting to think about - is it possible for access control list to potentially block routing advertisements?

And the answer is yes, but they have to be applied in a different way, so I don't want you to think that I'm looking at the ip access-group command. If you're looking at the ip access-group command as applied on an interface, that's an ACL applied as a packet filter. So what will cause an ACL to filter routes? Well it's when it's referenced as a distribute list. Now we have not used a distribute list. We have not talked about this. But if you were in a real world environment, and you looked under the EIGRP process and the running config, you do a show running-config | section eigrp, you see distribute list. What is that? It's a filter that can be configured inbound and outbound, and the permitted networks within the ACL that are tied to the distribute list will say what can come in and out. A denied network would say, I don't want to hear about this if it's inbound, or I will not speak about it if it's outbound. So there's a lot of control that we can do. An EIGRP is one of the easier routing protocols with regards to routing protocol filtering. OSPF on the other hand, is really tricky. I mean I don't want to have to do filtering inside OSPF because I always have to look up a white paper to make sure that I'm doing it properly.

HQ#show ip protocols
...
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
...

Here's a behavior of EIGRP that has changed. For those of you who are familiar with EIGRP behavior in the past, when I say the past, that's not too long ago for EIGRP, it would automatically summarize whenever advertisements crossed network boundaries and we can see that example here.

EIGRP Auto Summarization

We have 172.16.2.0 and that's advertised of the interface on router C over towards router B. Automatic summarization occurs and router B learns about 172.16.0.0. Notice on the other side on router A? We also have 172.16.1.0, but because of the older behavior of automatic summarization, router A, when it advertises it to router B, summarizes that to the major class for network boundary as well, 172.16.0.0. And as a result, router B learns about 172.16.0.0 through two different directions. This is known as a discontiguous network. But what part of it is the discontiguous network? Let's be clear on which part of it, it is. Is it the 10 network that's discontiguous here or is it the 172.16 network that's discontiguous?

By keeping track of the third octet, we can narrow it down, the 172.16 is over the left, the .2 is on the right and now it won't have the conundrum anymore. This is a really big deal. Now let's say you want to get ready for the test.

Тhis used to be a major issue for EIGRP. Why? Because by default, as I said, we did this automatic summarization, but now with the newer operating systems of 15.0 and higher, EIGRP does not behave this way by default. It ensures that we do not perform automatic summarization now. Does anybody know what command is on by default now for EIGRP, which wasn't on by default before - no auto-summary.

So let's get down to being highly reductive and highly preparatory for the exam. Should this ever come up? What you need to do is you need to think, I'm troubleshooting a routing problem for EIGRP. Do I have a neighborship? Yes. Do I have the right information at my table? Maybe not, okay. Look to your network commands first, right. Got to make sure your network commands are there after neighborships are formed. And if that network command, if all the network commands look right, then come here and you do a show ip protocols output.

HQ#sh ip protocols
...
Routing Protocol is "eigrp 100"
...
  Automatic Summarization: disabled
...

You need to make sure that automatic summarization was disabled. You'd look at the running config. You could also see if auto-summary was there as well. You see that as a big, big warning sign. Not saying that that's necessarily the case because if it's not a discontiguous network, it wouldn't break it, but if it was a discontiguous network, boy, you got a problem on your hands and that's a thing to figure out. What do I do? Нo auto-summary. Remove that really old archaic operation. Operation in fact makes EIGRP behave classfully.