Lesson Contents
The first DMVPN lesson explained the basics and I explained how to configure a basic DMVPN phase 2 network. I also created an example for BGP on DMVPN phase 1 networks.
In this lesson we’ll take a look how we can use BGP on DMVPN phase 2 networks. Here is the topology we will use:
One hub router and two spoke routers, each has a loopback interface which we will advertise in BGP.
Configuration
Tunnel interfaces
Let’s start with the tunnel on the hub router:
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
Hub(config-if)#end
Here are the spoke routers:
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 mode gre multipoint
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 mode gre multipoint
Let’s make sure the spokes have registered with the hub:
Hub#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override
C - CTS Capable
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.2 172.16.123.2 UP 00:09:48 D
1 192.168.123.3 172.16.123.3 UP 00:09:56 D
And that we can ping our spoke routers:
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 = 5/7/11 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 = 6/7/10 ms
Everything is working, time for BGP.
eBGP
We will start with external BGP. This will work but it has one disadvantage:
Spoke routers have to learn each others networks if we want direct spoke-to-spoke communication. This means we can’t use the same AS on all spoke routers since they would not accept prefixes that have the same AS number in the AS path.
We will need a different AS number for each spoke router, this means we can’t use dynamic neighbors so we’ll have to configure them manually.
Here’s what it looks like:
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
Let’s see what we find in 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:01:00
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 172.16.123.3, 00:01:00
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:01:04
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 172.16.123.3, 00:00:34
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:01:08
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [20/0] via 172.16.123.2, 00:01:08
We can find all prefixes in the routing tables. External BGP also preserves the next hop addresses which is a good thing for us. Let’s try a trace from spoke1 to spoke2:
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.123.3 7 msec 11 msec *
No problem, we can get from spoke1 to spoke2 directly.
Configurations
Want to take a look for yourself? Here you will find the eBGP configuration of each device.
Hub
hostname Hub
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 65001
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 172.16.123.2 remote-as 65002
neighbor 172.16.123.3 remote-as 65003
!
end
Spoke1
hostname Spoke1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 65002
bgp log-neighbor-changes
network 2.2.2.2 mask 255.255.255.255
neighbor 172.16.123.1 remote-as 65001
!
end
Spoke2
hostname Spoke2
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.3 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 65003
bgp log-neighbor-changes
network 3.3.3.3 mask 255.255.255.255
neighbor 172.16.123.1 remote-as 65001
!
end
iBGP
Let’s try something else now, we’ll go for internal BGP. The advantage of iBGP is that we can use dynamic peers. We need to make sure that prefixes from one spoke router will be advertised to another spoke router. To accomplish this, we’ll configure the hub router as a route reflector:
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.
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
Rene
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.
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 insta
... Continue reading in our forumGreat 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 ?