{"id":268,"date":"2014-07-24T22:17:50","date_gmt":"2014-07-24T22:17:50","guid":{"rendered":"https:\/\/learncisco.net\/index.php\/troubleshooting-neighbor-tables\/"},"modified":"2023-01-12T09:26:34","modified_gmt":"2023-01-12T02:26:34","slug":"troubleshooting-neighbor-tables","status":"publish","type":"page","link":"https:\/\/www.learncisco.net\/courses\/icnd-2\/implementing-an-eigrp-based-solution\/troubleshooting-neighbor-tables.html","title":{"rendered":"EIGRP Troubleshooting | EIGRP Neighbor Table"},"content":{"rendered":"
Folks, we have seen a flowchart for troubleshooting already in this curriculum and we will see one now for Enhanced Interior Gateway Routing Protocol, or EIGRP. The flowchart is not what is truly essential, but we are going to talk about some specifics that will really improve your success chances for troubleshooting. So we are going to walk you through these questions that you see here.<\/p>\n
<\/p>\n
Are interfaces operational? First question on our plate, how do we verify that? It really takes us back to the basics of our interfaces. Are they up-up, up-down, down-down, or administratively down-down? If our interface is operational, what will we be?<\/p>\n
<\/p>\n
We will be up-up. We need to be up-up and any dynamic routing protocol demands connectivity, which can only happen on an up-up interface.<\/span><\/p>\n What has to match for us to form neighbor adjacencies? This is important. We discussed it earlier. In this case will we successfully form a neighbor adjacency?<\/p>\n We’re looking at the output of the show ip protocols command, invaluable for validating some of the core configuration of any dynamic routing protocol. And we see that the routing protocol has autonomous system numbers of 1 and 2 depending on what device we’re on. So is that going to work?<\/p>\n When I’m looking at the output here, it says Routing Protocol is “eigrp 1”, Routing Protocol is “eigrp 2”. We’re running EIGRP on both Branches in HQ. We can confirm that, but the one and the two, what did those represent?<\/p>\n Branch#show ip protocols HQ#show ip protocols They’re the autonomous system numbers. They must match. We will not form an adjacency with a router that has a different autonomous system number. Now there are some other things that could be mismatched. We talked about the metric and what were the little flags, the little dip switches for turning on and off those metric components? They were the K values, right?<\/p>\n Yes, those K values have to match as well. So Branch has 1 0 1 0 0 configured for its key values, then HQ has to have those exact same values for the K values. If they don’t, they don’t form our neighbor adjacency either. Now something else too that we have to make sure of. Will we form a neighbor adjacency, if we are not on the same subnet?<\/p>\n No. And one last one, if you have authentication, then the authentication is configured differently between the devices, it’s not going to work either. So there is pretty much everything. We have an up-up interface, which we just talked about. Proper IP addressing. We really are covering the gamut of things that can affect EIGRP neighborship.<\/p>\n What is the command we use to enable EIGRP on interfaces?<\/p>\n It is the network<\/strong> <\/span>command.<\/p>\n So if we’re looking at the output of show ip eigrp interfaces, I expect to see a certain number of lines that would be associated with the number of interfaces I expect to be enabled for EIGRP. In this case, we’re only looking at Serial 0\/0 on both devices.<\/p>\n All right. Are those the correct interfaces according to our diagram that are enabled for EIGRP?<\/p>\n I in fact see a problem with this. I see a problem, but wait a minute. We’re seeing that they’ve paired it down to just looking at the serial interface. We usually don’t execute command this way. We usually just show the whole command, but if I’m troubleshooting neighborships, I want to make sure that my interface is captured with the network command. And it looks like that’s the case because it’s not going to show up as a line here unless it was captured with a network command that says, let’s include it in our autonomous system by enabling it as a local interface in the routing process for EIGRP.<\/p>\n Folks, will Branch form a neighbor adjacency with HQ based on the following output? Will a neighbor adjacency be formed between Branch and HQ?<\/p>\n No, not at all. If you didn’t see that, let me explain it. A passive interface is one that will not send or even listen to hellos. When we do not send and receive hellos and even one of those is not done, there’s no potential for neighborship out the interface. And so, if we have a passive-interface command pointing to an interface, they would go to another EIGRP-enabled router, there’s no hope for us. There’s no hope at all. So this in fact would be a configuration issue that we would need to solve and we solve it by just saying no passive interface Serial0\/0<\/strong><\/span>. We would remove that and we might almost immediately get a sys log message indicating that our neighborship was up and running.<\/p>\n","protected":false},"excerpt":{"rendered":"Folks, we have seen a flowchart for troubleshooting already in this curriculum and we will see one now for Enhanced Interior Gateway Routing Protocol, or EIGRP. The flowchart is not what is truly essential, but we are going to talk about some specifics that will really improve your success chances for troubleshooting. So we are … Read more<\/a>","protected":false},"author":5,"featured_media":0,"parent":140,"menu_order":180,"comment_status":"closed","ping_status":"closed","template":"cisco-page.php","meta":{"_acf_changed":false,"footnotes":""},"acf":[],"yoast_head":"\n\n
\nRouting Protocol is “eigrp 1”<\/p><\/blockquote>\n
\nRouting Protocol is “eigrp 2”<\/p><\/blockquote>\n\n
\n
\n