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

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: DMVPN Phase 1 RIP Routing DMVPN Phase 1 EIGRP Routing DMVPN Phase 1 OSPF Routing This time, we'll take a


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 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

501 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. Rene,

    When would we choose to use Phase 1, 2, or 3, and why? I understand the differences between the three, but do we gain any benefit from implementing one or the other that is noticeable to end users?

    It seems to me that perhaps allowing spoke routers to talk to each other may decrease latency in the real world, as they would not have to hop through the hub router, but other than that I’m not sure.

    Thanks,

    Patrick

  2. Hi Patrick,

    The different versions are like an evolution of DMVPN. We don’t really use phase 1 anymore unless you have a really good reason why you want to force all traffic through the hub (security perhaps?). Otherwise, it’s more effective to allow spoke-to-spoke traffic.

    Both phase 2 and 3 allow spoke-to-spoke traffic, the advantage of phase 3 is that we use the “shortcuts” so you don’t need specific entries anymore in the routing tables of the spoke routers. I can’t think of any advantages right now that phase 2 has over phase 3 so if you implement this, yo

    ... Continue reading in our forum

  3. Hello Heng

    This is a very good question. Looking at the process in more detail, when using Phase 3.

    Initially, (and that is the key word) all spoke to spoke packets are switched across the hub. In order for a spoke to learn about the true NBMA IP address of another spoke, the NHRP redirect message is used.

    So when a hub receives an IP packet inbound on its interface and switches it out of the same interface, it sends a special NHRP redirect message to the source indicating that this is a suboptimal path. It should look for a better way using NHRP resolution.

    ... Continue reading in our forum

  4. Hello Lagapides
    Thank you so much for your time. I got it now .
    Sovandara

  5. Thanks Laz - I’ve only ever known ethernet in my time as a network engineer so to imagine that something else can exist in it’s place at layer 2 is a strange concept for me! :open_mouth:

    I’ve since heard that home power line network can actually be used to shuttle ethernet frames around too… absolute madness! :wink:

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