Get Unlimited Access to our 786 Cisco Lessons Now Get $1 Trial
You are here: Home » Cisco » CCIE Routing & Switching

DMVPN Phase 1 BGP Routing

In the first DMVPN lesson I explained some of its basics and in the second lesson I explained how to create a basic DMVPN phase 1 configuration. We also did a configuration for each of the IGPs:

This time, we’ll take a look at BGP. Here’s the topology we will use:

DMVPN Example Topology with hub, two spokes and loopback interfaces.

Configuration







Tunnel Interfaces

Here’s a basic DMVPN phase 1 configuration:

Hub(config)#interface Tunnel0
Hub(config-if)#ip address 172.16.123.1 255.255.255.0
Hub(config-if)#ip nhrp authentication DMVPN
Hub(config-if)#ip nhrp map multicast dynamic
Hub(config-if)#ip nhrp network-id 1
Hub(config-if)#tunnel source GigabitEthernet0/1
Hub(config-if)#tunnel mode gre multipoint
Spoke1(config)#interface Tunnel0
Spoke1(config-if)#ip address 172.16.123.2 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke1(config-if)#ip nhrp map multicast 192.168.123.1
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp nhs 172.16.123.1
Spoke1(config-if)#tunnel source GigabitEthernet0/1
Spoke1(config-if)#tunnel destination 192.168.123.1
Spoke2(config)#interface Tunnel0
Spoke2(config-if)#ip address 172.16.123.3 255.255.255.0
Spoke2(config-if)#ip nhrp authentication DMVPN
Spoke2(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke2(config-if)#ip nhrp map multicast 192.168.123.1
Spoke2(config-if)#ip nhrp network-id 1
Spoke2(config-if)#ip nhrp nhs 172.16.123.1
Spoke2(config-if)#tunnel source GigabitEthernet0/1
Spoke2(config-if)#tunnel destination 192.168.123.1

Let’s verify if the tunnels are working:

Hub#show dmvpn | begin 192.168.123.
     1 192.168.123.2      172.16.123.2    UP 00:22:37     D
     1 192.168.123.3      172.16.123.3    UP 00:00:32     D

And do a quick ping:

Hub#ping 172.16.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/8 ms
Hub#ping 172.16.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/9 ms

Everything seems to be working, time to configure BGP.

eBGP with different AS on the spokes

There are a number of variations we can choose from:

  • eBGP with a different AS number on each spoke.
  • eBGP with the same AS number on each spoke.
  • iBGP

We’ll take a look at all the different options, we’ll start with eBGP with a different AS number on all spokes:

Hub(config)#router bgp 65001
Hub(config-router)#neighbor 172.16.123.2 remote-as 65002
Hub(config-router)#neighbor 172.16.123.3 remote-as 65003
Hub(config-router)#network 1.1.1.1 mask 255.255.255.255
Spoke1(config)#router bgp 65002
Spoke1(config-router)#neighbor 172.16.123.1 remote-as 65001
Spoke1(config-router)#network 2.2.2.2 mask 255.255.255.255
Spoke2(config)#router bgp 65003
Spoke2(config-router)#neighbor 172.16.123.1 remote-as 65001
Spoke2(config-router)#network 3.3.3.3 mask 255.255.255.255

Above we have a different AS number for each router, also we advertised the loopback interfaces in BGP. Let’s see if our hub router has two neighbors:

Hub#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.123.2    4        65002      47      48        4    0    0 00:38:49        1
172.16.123.3    4        65003      46      47        4    0    0 00:38:05        1

This is looking good, we have two neighbors. Let’s take a look at the routing tables:

Hub#show ip route bgp 

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 172.16.123.2, 00:37:59
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.123.3, 00:37:59
Spoke1#show ip route bgp

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [20/0] via 172.16.123.1, 00:38:16
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.123.3, 00:37:46
Spoke2#show ip route bgp 

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

All routers have learned the different networks. Let’s see if spoke1 can reach spoke2:

Spoke1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/10 ms

Great, no issues there. All traffic goes through the hub so there’s no need for our spoke routers to see specific networks.

Let’s configure the hub so that it will only advertise a default route to our spokes. I’ll use a route-map for this:

Hub(config)#ip route 0.0.0.0 0.0.0.0 null0

Hub(config)#ip prefix-list DEFAULT_ROUTE permit 0.0.0.0/0

Hub(config)#route-map SPOKE_ROUTERS permit 10
Hub(config-route-map)#match ip address prefix-list DEFAULT_ROUTE

Hub(config)#router bgp 65001
Hub(config-router)#network 0.0.0.0 mask 0.0.0.0
Hub(config-router)#neighbor 172.16.123.2 route-map SPOKE_ROUTERS out
Hub(config-router)#neighbor 172.16.123.3 route-map SPOKE_ROUTERS out

Hub#clear ip bgp *

Our hub router should still have all networks, the spoke routers should only have a default route. Let’s take a look:

Hub#show ip route bgp 

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 172.16.123.2, 00:00:52
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.123.3, 00:00:52
Spoke1#show ip route bgp

B*    0.0.0.0/0 [20/0] via 172.16.123.1, 00:00:44
Spoke2#show ip route bgp

B*    0.0.0.0/0 [20/0] via 172.16.123.1, 00:00:48

That’s looking good. Let’s verifiy connectivity:

Spoke1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms

It’s still working, excellent!

eBGP with same AS on the spokes

Another thing we can try with eBGP is to use the same AS number on all spoke routers. The advantage of this solution is that we don’t have to filter any networks, the spoke routers will not accept any networks where they see their own AS number in the AS path. Let’s clean up first:

Hub(config)#router bgp 65001
Hub(config-router)#no neighbor 172.16.123.2
Hub(config-router)#no neighbor 172.16.123.3
Spoke1(config)#no router bgp 65002
Spoke2(config)#no router bgp 65003

Now we’ll configure the spoke routers to use AS 65023:

Hub(config)#router bgp 65001
Hub(config-router)#neighbor 172.16.123.2 remote-as 65023 
Hub(config-router)#neighbor 172.16.123.3 remote-as 65023
Spoke1(config)#router bgp 65023
Spoke1(config-router)#neighbor 172.16.123.1 remote-as 65001
Spoke1(config-router)#network 2.2.2.2 mask 255.255.255.255
Spoke2(config)#router bgp 65023 
Spoke2(config-router)#neighbor 172.16.123.1 remote-as 65001
Spoke2(config-router)#network 3.3.3.3 mask 255.255.255.255

Our hub router is still advertising a default route but we don’t need the route-map anymore. Let’s take a closer look:

Hub#show ip route bgp 

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 172.16.123.2, 00:00:56
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.123.3, 00:00:20

The hub still has the networks from the spoke routers in its routing table. Let’s see what it is advertising to the spoke routers:

Hub#show ip bgp neighbors 172.16.123.2 advertised-routes 
BGP table version is 9, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  0.0.0.0          0.0.0.0                  0         32768 i
 *>  1.1.1.1/32       0.0.0.0                  0         32768 i
 *>  2.2.2.2/32       172.16.123.2             0             0 65023 i
 *>  3.3.3.3/32       172.16.123.3             0             0 65023 i
Hub#show ip bgp neighbors 172.16.123.3 advertised-routes 
BGP table version is 9, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  0.0.0.0          0.0.0.0                  0         32768 i
 *>  1.1.1.1/32       0.0.0.0                  0         32768 i
 *>  2.2.2.2/32       172.16.123.2             0             0 65023 i
 *>  3.3.3.3/32       172.16.123.3             0             0 65023 i

Above you can see that the hub advertises 3.3.3.3/32 to spoke1 and 2.2.2.2/32 to spoke2. What did they install?

Spoke1#show ip route bgp

B*    0.0.0.0/0 [20/0] via 172.16.123.1, 00:04:05
      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [20/0] via 172.16.123.1, 00:04:05
Spoke2#show ip route bgp 

B*    0.0.0.0/0 [20/0] via 172.16.123.1, 00:02:19
      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [20/0] via 172.16.123.1, 00:02:19

Spoke1 doesn’t accept 3.3.3.3/32 since it has AS 65023 in the AS path. The same thing applies to spoke2, it doesn’t like 2.2.2.2/32 since AS 65023 is in the AS path. The default route is installed and we can see 1.1.1.1/32. It would be best to get rid of the network 1.1.1.1 mask 255.255.255.255 command on the hub, we don’t need this entry.

Let’s see if the spokes can still reach each other:

Spoke1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/9 ms

Spoke1 can still reach spoke2. No problems here!

iBGP with dynamic peers

The two previous examples with eBGP work very well. Both examples had one “issue” though, we manually configured our neighbors. It works but it defeats the purpose of having dynamic DMVPN spoke routers.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 786 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

Give Membership a try - it's just $1 ►

1507 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,

Forum Replies

  1. Very nice article, Really good work .

    Could we use dynamic neighbors in case of EBGP? Hub AS (65001) and spokes (65002) , also I will not use default route and will use allow in to accept routes.

    sorry I know it is multiple questions :slight_smile:

  2. Yes, you can absolutely use dynamic neighbors on BGP for this. In fact, this would be the preferred method, especially if you have a lot of spokes. By using the BGP option of “listen range” you can specify entire network ranges where you will allow a BGP neighborship to form. By using the listen range option, you can create DMVPN templates for the spokes and hub(s), so it is very easy to deploy new devices.

    I don’t quite understanding what you are asking in the second part of your question. What DMVPN phase are you in? If you are in Phase 1, there is no re

    ... Continue reading in our forum

  3. Thanks Andrew P for your fast reply , please check below image .

    http://i67.tinypic.com/21ot54.jpg

    I appreciate your feedback.am i right for not using default route ? especially that i will use (Local preference for out traffic , AS path prepending for in traffic)

  4. Depending on your traffic complexity, one suggestion might be to have R1 and R2 learn their routes via BGP (or a default route), and simply use a floating static default route with a high administrative distance (obviously higher than 20) on R1 and R2 towards the Hub. This way, if your BGP relationships should fail with the preferred local loop connection, the floating route will be inserted and traffic will route via the DMVPN.

    I don’t know all the details about your network, so this simplistic approach might not work in your situation, but from what I seeing

    ... Continue reading in our forum

55 more replies! Ask a question or join the discussion by visiting our Community Forum