DMVPN Phase 2 BGP Routing

Lessons Discussion
1

This topic is to discuss the following lesson:

https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-2-bgp-routing/

2

Nice article, Rene!

I am sure you are gonna create another article about ā€œā€œdirtyā€ tricks like AS override, allow AS in or remove private AS.ā€ since CCIE is all about details and details and more details.

Ā 

Thanks.

3

Hi Harvinder,

I did, you can take a look here:

https://networklessons.com/mpls/mpls-layer-3-vpn-bgp-allow-as-in/

https://networklessons.com/mpls/mpls-layer-3-vpn-bgp-override/

https://networklessons.com/bgp/bgp-remove-private-as/

Enjoy :slight_smile:

Rene

4

Am I correct in noting that for iBGP Route-Reflector in a DMVPN env the next hop attribute changes to the spokes but in a normal non dmvpn route reflector env the next hop attribute DOES NOT change.

5

Michael,
In both environments, the iBGP route-reflector should not change the next hop attribute, and the reason in both cases is the same. By having the RR change the next hop, the RR would necessarily be putting itself in the data plane. In most cases, it is preferable to have the RR act only in the control plane so the most efficient path can be taken.

The tricky part about BGP in a DMVPN environment is accounting for knowledge of the next hops by all BGP clients. As you know, in BGP, if an advertised route has an inaccessible next hop, BGP will not install the route in the RIB. The example in this Network Lesson was pretty simple since all spokes and the hub had outside addresses all in the same subnet. This will almost never be the case, which means you will likely need to advertise these next hops via an IGP via the DMVPN tunnel. This will allow each BGP client to know how to reach the advertised next hop.

1 Like
6

Great article

quick question concerning the ebgp configuration, i can see that in the routing table the next hop is not passing through the hub. however i can see that the AS path still mention the hub ā€¦even if the next hop is not the hub.
is it the normal behavior ?

7

Hello Fethi,

That is correct yes. eBGP doesnā€™t change the next hop address.

Rene

8

HI Rene,

If you wanted to use eBGP with different ASā€™s on the Spokes couldnā€™t you just advertise a default route from the Hub to the Spokes with ā€˜default-originateā€™ instead of advertising every prefix from every spoke (say there were hundreds of spokes)? I wouldnā€™t of thought this would be considered a ā€˜dirty trickā€™.

1 Like
9

Hello George

This is a viable solution as well. Of course if you have tens or hundreds of prefixes, the default route would be preferable. If you have the ability, lab it up and let us know your results!

I hope this has been helpful!

Laz

10

It actually does work, this is how we use it at work :slight_smile:

1 Like
11

I thought the next hop addresses are the tunnel addresses, not the NBMA addresses?

Spoke2#show ip route bgp

  1.0.0.0/32 is subnetted, 1 subnets
 B        1.1.1.1 [200/0] via 172.16.123.1, 00:00:13
  2.0.0.0/32 is subnetted, 1 subnets
 B        2.2.2.2 [200/0] via 172.16.123.2, 00:00:13

Then the router uses NHRP to ā€œresolveā€ the tunnel addresses to NBMA addresses.

And for Georgeā€™s default route solution, wouldnā€™t a default route force the data plane traffic via the Hub, rather than spoke to spoke direct communication?

12

Hi Chris,

The next hop addresses are indeed the tunnel addresses, which are then resolved with NHRP.

If you use DMVPN phase 3, all you need is that default route on your spokes. The hub uses NHRP redirects to spokes. The spokes will then do an NHRP resolution for each others address, and youā€™ll have direct spoke-to-spoke traffic.

Rene

13

Hello Rene,
In DMVPN Phase 2, why are Spokes not forming neighborship with each other in RIP, EIGRP and OSPF (all the tunnel interfaces are in the same broadcast domain and Areas are the same)? On the other hand, why can Spokes form eBGP neighborship with each other? Thanks in advance.

14

Hello Azm

In DMVPN Phase 2, the hub router has a multipoint GRE tunnel interface, and the spokes have point-to-point GRE tunnel interfaces. This means that on the spokes, each tunnel interface is point-to-point, meaning it is designed to connect to only one other interface. The spokes are configured to establish a point-to-point GRE tunnel with the hub.

So by default, spokes can only ā€œseeā€ the hub and not each other. They are not aware of each otherā€™s existence directly, and thus canā€™t form neighbor relationships or communicate directly with each other.

Now DMVPN Phase 2 uses NHRP to allow spokes to learn about each other and establish direct tunnels between themselves, bypassing the hub. However, the process to establish these direct tunnels involves the hub and NHRP. It is not automatic and requires the spokes to request the necessary information from the hub.

Note that routing protocols such as OSPF and EIGRP rely on the broadcast and multicast capabilities of the underlying network to form adjacencies. Since the spokes donā€™t directly see each other and require the hub and NHRP to intervene to ā€œsimulateā€ a direct connection, this arrangement does not support the automatic discovery of neighbors using broadcast/multicast. Thus these routing protocols cannot see each other.

Just a note, RIP does not create neighbor adjacencies.

Now why does BGP allow for the creation of neighbors? Well, this is because, unlike OSPF and EIGRP, BGP uses TCP connections to the specific network address of the neighbor to create its adjacencies. DMVPN phase 2 supports such direct communication implicitly, so there is no restriction there. This applies for both eBGP and iBGPā€¦

I hope this has been helpful!

Laz