eBGP DMVPN next hop

[sarahanand]

Hi,

I have read from several sources ranging from blog posts to the foundation learning guide for CCDP that when using Phase 1 DMVPN with eBGP it is required to set the next-hop-self argument on the eBGP neighbors.

The supposed reason is that because eBGP will not change the next-hop if it is advertising the routes to a neighbor in the same subnet. Here is an excerpt from the latest CCDP book for further clarity:

If you decide to use BGP as the routing protocol in your DMVPN, you should consider using eBGP to accommodate a simplified design and simplified overall provisioning. iBGP does not announce prefixes that are received through iBGP to other iBGP peers and will require configuring the DMVPN hub router as a route reflector. When using eBGP, you need to configure the next-hop-self option because eBGP does not change next-hop attributes when peers are in the same subnet.

If you examine this closely in the context of DMVPN, when you configure eBGP peering relationships between IP addresses on the tunnel interfaces, the spoke announces prefixes with the next-hop IP address of the tunnel interface. When prefixes come to the hub router, this router announces prefixes to the other spokes and does not change the next-hop attribute. The result of this situation is that spokes will not have reachability to the networks behind other spokes because the next-hop IPs of these spokes are not available.

However, in personal testing I have found that this fact is not true. Upon setting up a DMVPN topology where BGP is the overlay protocol and attempting pings between spoke networks, the pings succeed. This is because the exit interface is matched as the Tunnel interface for DMVPN which contains a static destination of the DMVPN Hub. The Hub receives the packet and routes it according to its own Routing table. This happens in reverse for return traffic.

So the question is, for Phase 1 why do the book and other sources state it is mandatory to set the next-hop to self for eBGP peerings over DMVPN, when it seems to work without it.

Thank you.

[Peter Paluch · Accepted solution]

Hi Sarah,

You are spot-on with your explanation that if the spoke routers are configured with point-to-point tunnels (as is common with Phase1 DMVPN), then for every next-hop falling into the IP range of the tunnel interface, the destination is already known and set with the tunnel destination command which happens to be the hub router. Therefore, regardless whether the spoke networks are learned with the IP next hop pointing directly to the spoke router with that network, or with the IP next hop pointing to the tunnel IP address of the hub router, the traffic will always be delivered to the hub router by natural means, and there will be no reachability problems in this network.

I can, however, think of two possible scenarios where the next-hop-self might truly be required, although I wouldn't call those two reasons the typical ways of deploying DMVPN.

Scenario 1: Because the tunnel interfaces on spokes are configured as point-to-point tunnels in Phase1, you can have them configured as IP Unnumbered interfaces, sharing the IP address from some other interface, presumably a Loopback that is configured with a /32 netmask. This could be advantageous if, for example, you wanted to have a router represented with a single IP address (the one on the Loopback) for management purposes and also wanted to have your routing tables neat and tidy - the next hop addresses would be matching the Loopback addresses of individual spokes. In this case, however, the spokes would no longer have a directly connected network on their Tunnel interface; rather, they would need to be configured with a static /32 route toward the hub tunnel IP address manually. Quite obviously, the hub would now need to be configured with next-hop-self for all spoke neighbors, otherwise the next hops it would advertise would be considered unreachable.

Scenario 2: What we call Phase1 in DMVPN is essentially defined as "spokes dynamically registering to the hub, without direct spoke-to-spoke communication". This can be accomplished in two essential ways: Either you use point-to-point tunnels on spokes, preventing them from ever building a tunnel to another spoke, or you configure spokes with multipoint tunnels but make sure that the next hop always points to the hub. The final effect is the same but the means are different. Having multipoint tunnels on spokes allows you to centrally migrate between Phase1 and Phase2 just by changing the configuration on the hub (adding or removing the next-hop-self) while with static tunnels, you would need to reconfigure all spokes. Obviously, with the approach of all spokes configured with multipoint tunnels, using the next-hop-self is essential to have the network operate in Phase1 mode.

To sum up, with static point-to-point tunnels on spokes configured with IP address range covering all tunnel endpoints in the DMVPN, I see no reason to use the next-hop-self. However, with multipoint tunnels on spokes, Phase1 operation must be enforced by the use of next-hop-self on the hub.

Would this explain things a bit? Please feel welcome to ask further!

Best regards,
Peter

[sarahanand]

Thanks Peter.

It's nice to know my initial conclusion was correct. Also, your examples with the IP unnumbered and the multipoint tunnel makes total sense.