Join Chris Bryant for an in-depth discussion in this video The network and frame map commands, part of CCNP Troubleshooting (300-135) Cert Prep.
- [Narrator] What in the world could go wrong with EIGRP? Well, just a couple of things, and I have a feeling we might see a couple pop up in this particular section of the course. But, frankly not as many as, say, OSPF because EIGRP is just not as complex to configure as OSPF in my humble opinion and I think you'll share that opinion if you don't already, once we go through some of these labs, you'll think, "hey, this is easier than troubleshooting OSPF." So, you know, you have fewer moving parts in a way, you have fewer commands, frankly, with EIGRP, so you have fewer things that can go wrong.
There's a little bit of a trade-off there, we're going to see live here in a few minutes but that's your teaser. Right now, I just want to remind you that most of your EIGRP troubleshooting frankly, it's going to deal with adjacencies. Both adjacencies that have never existed and still aren't existing, and those that you had but then suddenly stopped existing, and we'll see both in action not just using this NBMA network, but we'll add a network or two as we go along. But here, we're running over frame relay, same as we have in many of the labs, almost all of them, routers one, two, and three 22.214.171.124 /24 network and lets say you just get called in and someone says, well I got the CIGRP config running and I can't get one of my adjacencies up.
And, you come in, and you run the neighbor command, and by golly, that person is right because you look at those, and we know that 123 is router three and we see the up time which is always helpful, and you can see that that adjacency has been up for over 10 minutes. So no problems there, no flapping, anything like that and the adjacency to router two simply doesn't exist. Now that's a little more puzzling since we're in a hub and spoke network, I'm going to bring that up just a little bit.
We've got a hub and spoke network and your adjacency is fine between one and three, but not between one and two. So, where exactly does that point us to? Where should we start our troubleshooting? This is going to sound odd. I would actually start on router two, and I will tell you exactly why. I would use the OSI troubleshooting model here, and I'm even calling it the OSI troubleshooting model instead of the networking model. I would use that first off if I were called in on a case like this, because first off I want to make sure router two is even available.
You know, is it on, you know for all of us who have worked help desk over the years. That's like the first question you try to ask without being insulting. Is this thing on? So, can I connect to router two? Yeah, I can. And I can run a show config right there and everything looks fine, the router is definitely up. So no issues there. And let me bring that right back up. And what I'm going to do, hopefully, is go back to router one, and even though we're running EIGRP, and I would do this on a lab environment as well, I would do this.
Hmm. Now, you're thinking, well Chris, that's just lovely, but that's frame relay. Yes, it is frame relay and if frame relay at layer two is not working then you cannot possibly have any kind of adjacency at layer three. So we've got to make sure that routers one and two are talking to each other, if you will, over frame relay, and it looks pretty good. We've got a show frame PVC here. We see that two of them are active. Everything looks good here.
And everything looks pretty good right there, there's DLCI 122 and 123. Now, you could see different numbers in the field, of course, and I didn't put the DLCI numbers on the diagram for a reason. This is one reason that I do like to use the router number at the end of the DLCI if I possibly can, so I know by looking at these, I can look at 122 and say, okay, I know that's going from router one to router two, and I can look at this one and say, okay, it's going from router one to router three. That doesn't sound like much until you start getting labs with a dozen of these.
And if you're, if you don't have a numbering method then you can get a little confused on which ones are actually working, which ones aren't, and which one actually leads to a certain router. But here we know that 122 is leading to router two. Everything looks fine there. The last time the PVC status changed was 15 minutes, 33 seconds ago. So everything's looking pretty good. And a ping looks just as good. So I really don't have any problems here. Let's see, let's run show IP EIGRP neighbor again.
And then I'm going to go over to router two. Run the exact same command, I don't have any neighbors on router two. But do you see anything on the screen right now that would tell you what the problem is or do we have to run something else? Should we go ahead and start running debugs? You don't have to run any debugs because actually, the answer is right in front of you. The problem is that router one is running EIGRP process 100 and router two is running process 10, AS 10.
And that's where the problem comes in because the AS number has to match between potential, excuse me, EIGRP neighbors. Between potential OSPF neighbors, the number in the command router OSPF, the number that follows that doesn't matter because that's the locally significant only process number. So that's the whole problem, right there. Is that you're just zipping through the config, you left a zero off on router two, and everything went from there. So, let's go ahead and remove that.
Put that on there anyway, 126.96.36.199. And the adjacency's already come up. Now, you might be thinking, boy, that's not real complex. A lot of EIGRP problems aren't complex. They come down to the AS number and they come down to a network number or something else just being one little number off. Let's go over to router three, I'll show you exactly what I'm talking about. Let's run our command here.
And I didn't put it on the diagram so we're going to wing this a little bit. I've got router four in this network at the 188.8.131.52 /24 network, so let me ping router four over there first. There we go, it pinged successfully, and now I'm going to get an adjacency between routers three and four. I'll zip over to four.
And what do you think? What's going to happen? Of course, you're already laughing, because you think I didn't do that on purpose. (laughing) This time I did it on purpose. There may be other times on tape that the recorder was running and I messed up a network command but this is not one of those times, I actually did it on purpose. The problem is simply right here, a mis-entered network command. And the other reason I'm showing you this is just to remind you, always look for the simpler solution first when you're troubleshooting. Don't look for the complex or the super complex first, or something you read in a book the other night or just saw in a class.
I've done it before, too, especially early in my career. It just seems like we go for the more esoteric or complex solution when a lot of times, frankly, it really is just this simple. So, let's go back over to router three. We're going to take that one command off. Yeah, I can just do a control A there. I always want to put area zero on there on occasion but don't do that with EIGRP, of course, and there's our adjacency, just that fast.
We'll go ahead and verify. And we're good! So we've got our adjacencies up, a little basic troubleshooting here, a couple of extra tips to kind of warm us up. Before we look at a couple of values that don't necessarily have to match, but probably should, because if they don't, they're going to lead to trouble, and we're going to hit those on the very next video.
- Port security fundamentals
- EtherChannel negotiation protocols
- Advanced switching options
- NBMA configuration and troubleshooting
- Spotting and fixing authentication type mismatches
- K-values and passive interfaces
- Route redistribution
- NTP authentication
- Border Gateway Protocol (BGP)
- VPNs and VRF-lite