DMVPN

[gauravpundir231]

Hi All,

Confused on below point regarding DMVPN.

1. once spokes identified the public & tunnel IP of each other via HUB. How they communicate with each other after that. How they find path to reach each other.

2. Difference in phase 2 & 3 in terms of Next HOP & routing information.

Reading this article but not able to visualize things.

Phase 3

Though DMVPN Phase 2 deployment provided direct spoke-to-spoke tunnels, one of the limitations is maintaining full routing tables on the spokes. Each route for remote spoke networks needs to be a specific route with the next hop pointing to the remote spoke’s tunnel address. This prevents the hub from being able to send down a summarized route to the spokes for a more concise routing table.

Phase 2

In DMVPN, the hub uses its Tunnel0 interface to reach the networks behind the spokes. Split horizon will prevent the hub from advertising those networks to remote spokes. Thus, in order for DMVPN to work in Phase 2 with EIGRP, split horizon must be disabled on the tunnel interface using the no ip split-horizon eigrp [asn] command.

[paul driver]

Hello

---

@gauravpundir231 wrote:

Hi All,

Confused on below point regarding DMVPN.

1. once spokes identified the public & tunnel IP of each other via HUB. How they communicate with each other after that. How they find path to reach each other.

Its all to do with the NHRP server (NHS) –client (NHC),
The NHC registers with the NHS server its public address(nbma) to tunnel ip address via its nhrp mapping of the NHS, this server stores the information of any NHC - Now any NHC client wishing to speak to another NHC will have the NHC peering address it wants and can dynamically initiate a tunnel between each ohter.

2. Difference in phase 2 & 3 in terms of Next HOP & routing information.

As I understand this - The difference is due to the behavior with eigrp routing protocol ,
Phase two you have to specify the no next-hop-self-command so the nexthop of the spoke peer route via eigrp would be that of the other spoke and not the NHS hub

In Phase 3 you don’t have to use this command but instead you specify both IP NHRP redirect on the hub and IP NHRP shortcut on the client

With this, When NHC wants to reach a route on another NHC it will initially query the NHS which will redirect it towards the other NHC -  however after this initial redirection NHRP itself will now have a cached redirection of the correct nexthop thus another any other request for this route will be redirected automatically without querying the NHS hub or eigrp.

[gauravpundir231]

Thanks Paul.

Phase 2 and phase are clear .

Still confused on dynamic communication between spokes.How 1 spoke will communicate with another if he has public & tunnel IP as this public IP will not be in its routing table