DMVPN – Part 2, BGP with dyanmic neighbors

Oh man… BGP Dynamic Neighbors. This is a freaking cool way of setting up BGP on a device like a Hub router where you’re expecting numerous BGP neighbors. Before dynamic neighbors, I remember configuring my hub router with peer-groups and having an insane amount of syntax since we had ~30-40 spokes. No more my friends, in this post we’ll not only look at how to configure iBGP for DMVPN routing, but also using dynamic neighbors to dramatically reduce the amount of configuration on the hub.

Before I jump into the config, you might wonder “why use BGP for DMVPN routing?” Simple answer my friend, it’s awesome. So, since most moderately sized organizations have BGP running anyway (think about your MPLS, unless you’re super cool and have a full on VPLS… you’re peering with your MPLS provider, and more than likely using BGP) using BGP for DMVPN allows a relatively seamless integration of the DMVPN cloud into your organization. I used to preach about “consistent BGP information”, because that model sincerely does allow you to build more stable and scalable networks. Also, per Cisco, distance vector routing protocols just play nicer with DMVPN’s hub and spoke model. SO enough with the sales pitch, let’s get into it. Here’s our topology:

We’ll configure the spokes first, since there’s nothing too exciting happening there. *This post assumes you already have DMVPN up and running, see DMVPN Part 1 for that*

Spoke1
…
conf t
!
router bgp 65000
 neighbor 172.16.10.1 remote-as 65000
 neighbor 172.16.10.1 send-community
 network 172.17.10.10 mask 255.255.255.255

 That’s it… rinse and repeat on Spokes 2 and 3 (just change your network statement). Now here’s the magic, configuring the Hub. Dynamic neighbors aside, there’s one key feature we’re really concerned with on the Hub… route-reflector-client. Specifically telling the hub that all DMVPN peers are RR clients. Why? Well young padawans, what’s the rule about iBGP? BGP expects that internal peerings are configured in a full mesh, and to prevent routing loops, it will not advertised iBGP learned prefixes to other iBGP peers… think of this like BGP’s split horizon. Well, that’s not going to work for us at all, so we’re effectively going to turn it off by telling the hub our DMVPN peers are RR clients. Also note the bgp listen syntax… we’ll talk about that bit next.

Hub
…
conf t
!
router bgp 65000
 neighbor DMVPN peer-group
 neighbor DMVPN remote-as 65000
 neighbor DMVPN route-reflector-client
 bgp listen range 172.16.10.0/24 peer-group DMVPN
 network 172.17.1.1 mask 255.255.255.255

That’s it! Calling “bgp listen range x.x.x.x/x peer-group abcd” is the entire configuration of dynamic neighbors. Now the default behavior allows for 100 dynamic peers, but this can be increased to 5000 with “bgp listen limit 5000”. Check out the bgp summary table on the hub, so informative:

HUB#show ip bgp summary | b ^Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
*172.16.10.10   4        65000      30      30       11    0    0 00:22:24        1
*172.16.10.20   4        65000      29      34       11    0    0 00:22:22        1
*172.16.10.30   4        65000      29      34       11    0    0 00:22:24        1
* Dynamically created based on a listen range command
Dynamically created neighbors: 3, Subnet ranges: 1

BGP peergroup DMVPN listen range group members:
  172.16.10.0/24

Total dynamically created neighbors: 3/(5000 max), Subnet ranges: 1

So you can see “Total dynamically created neighbors: 3/(5000 max)” I did bump up the maximum allowed dynamic neighbors to 5000. Also note the “*” next to our neighbors indicating that they were learned dynamically. Alright, the last thing we should look at is a couple pings showing spoke to spoke communication, our routing tables (since iBGP does not update next hop information), and our dmvpn neighbor table after said pings. We’ll test between Spoke 2 and Spoke 3.

SPOKE2#ping 172.17.30.30
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.30.30, timeout is 2 seconds:
!!!!!
!
SPOKE2#show ip route bgp | b ^Gateway
Gateway of last resort is not set

      172.17.0.0/32 is subnetted, 4 subnets
B        172.17.1.1 [200/0] via 172.16.10.1, 00:28:58
B        172.17.10.10 [200/0] via 172.16.10.10, 00:28:58
B        172.17.30.30 [200/0] via 172.16.10.30, 00:28:58
!

SPOKE2#show dmvpn | b ^ # Ent
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1 1.1.1.1             172.16.10.1    UP 00:38:05     S
     1 1.1.1.10           172.16.10.10    UP 00:28:34     D
     1 1.1.1.30           172.16.10.30    UP 00:00:05     D

Well that’s all there is too it! See the linked video for a walk through of this post, and a quick blurb on design considerations.