This topic is to discuss the following lesson:
Hello Rene!
Hopé you are doing great!
Can you please Add Trouble Shooting Steps for EIGRP Neighbors Over DMVPN?
Thanks In Advance!
Miguel Jimenez.
Hi Miguel,
The “general” EIGRP troubleshooting lessons can also be applied to DMVPN, the only thing you need to keep in mind are the differences with the DMVPN phases.
Have you seen my EIGRP examples for the different phases?
ÂHere’s what you need to keep in mind:
- When using phase 1, all traffic goes through the hub so the next hop address doesn't matter. Just make sure that the spoke routers have a (summary) route. If you don't use summarization then you need to disable split horizon on the hub so the spoke routers can learn each other's networks.
- When using phase 2, there is direct spoke-to-spoke traffic so spoke routers a) need to know each others networks and b) the next hop has to be correct. This means you have to disable split horizon and disable ip next hop self on the hub.
- When using phase 3, the spoke routers require "something" in the routing table to reach each other. It doesn't matter what the next hop is since NHRP will overwrite it. If you don't use summarization then you should disable split horizon on the hub.
Hope this helps!
Rene
Rene,
Am I correct in saying that you can use the neighbor command with sub-interfaces and have some of those sub-interfaces using the neighbor command with the others establishing a neighborship via normal means (i.e. dynamically discover neighbors)?
From an article I read from Kevin Wallace, (where three routers were connected via a switch and using physical interfaces), R1 and R2 initially established a dynamic neighborship, but then when R3 was introduced and a static neighbor was configured between R2 and R3, it broke the dynamic neighborship between R1 and R2.
Thanks in advance.
Hello Andy
Yes, it is possible to use the neighbor command with sub-interfaces. Each sub-interface is considered a separate entity when it comes to configuring EIGRP neighbors. Each sub-interface, just like the physical interfaces, can be configured to either automatically achieve neighbor relationship with an EIGRP neighbor, or achieve it manually via explicitly configuring the IP of the neighbor.
Now in the example that you state, the situation is different. Here you have three routers connected to the same subnet. When you configure a static neighbor adjacency between R2 and R3, then R2 and R3 cease to attempt to make any neighbor adjacencies dynamically. Any hello packets sent by R1 are ignored. Whenever the neighbor command is implemented on an interface, that interface cannot dynamically create EIGRP neighbor relationships, and this is why the adjacency between R1 and R2 is broken.
Now this example uses only the physical interfaces, so no sub-interfaces are involved. But even if they were, the EIGRP configuration on each subinterface is independent and would not affect the operation of OTHER subinterfaces, even if they are on the same physical interface.
I hope this has been helpful!
Laz
Hello Liz Sir!
I have turned on , debug EIGRP packets on my router, but it doesn’t show me anything please see the attached although my second router which I named it R2, it has ping reply with R-1 but the debug command doesn’t show me anything!
Thanks in advance for the hep in this regard.
Regards.
Ajmal
Hello Ajmal
Depending on what you want to examine, you should choose your debug commands accordingly. First of all, make sure that you have terminal monitor configured so that all debug output will appear on the command line. You can do this by simply issuing the following command:
R2#terminal monitor
Next, the debug ip packet command will monitor packets that are processed by the router’s routing engine, and not those processed by fast switching. If the router is fast switching, or using CEF, no output will appear. If you want to see packets routed using CEF, then use the following command:
R2#debug ip cef
Remember that all of these commands will output information for each and every packet that is being routed, so don’t use these on a production network. If you must, then use access lists that will match the traffic you are interested in and debug only those. You can see how to do this in the following Cisco documentation:
Now if you want to debug only EIGRP packets, then you will have to choose your debug commands accordingly. A useful list of commands for troubleshooting EIGRP can be found at this Cisco documentation.
I hope this has been helpful!
Laz
1 Like
Thank you Sir.
Regards,
Ajmal.
1 Like
In this lessons you mentioned an ACL blocking EIGRP. What if I can’t change the ACL. How can I circumvent the ACL to get EIGRP to establish?
Hello Marc
The access-list in this lesson blocks multicast traffic. For this particular case, a solution would be to configure static EIGRP neighbors. By doing so, EIGRP will only use unicast to communicate between EIGRP neighbors, and so you wouldn’t have to change the ACL. Configuring a static EIGRP neighbor is discussed in detail in the following lesson:
I hope this has been helpful!
Laz