This topic is to discuss the following lesson:
Hopé you are doing great!
Can you please Add Trouble Shooting Steps for EIGRP Neighbors Over DMVPN?
Thanks In Advance!
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!
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.
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!