Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

DMVPN is a well-known solution for hub&spoke connectivity. Sometimes a need might arise to bring some notion of multi-tenancy to DMVPN network. Although it’s possible to assign a DMVPN tunnel per VRF, such an approach is not particularly scalable from operational perspective or management. MPLS is much more suitable in this case since it has necessary capabilities as well as proven reputation from Enterprise and Service Provider world.

GRE is capable of encapsulating multiple types of payload, including MPLS labels, so there is no challenge for data plane. The control plane, however, might be a bit trickier. Both LDP and RSVP require neighbor relationships established prior to any data exchange. Scalability is achieved by using multicast messages to find peer routers and exchange some protocol-related parameters. Using unicast neighbourship in DMVPN for LDP/RSVP would at least hinder the scalability of the solution so we will not look further into such a scenario. Multicast, however, poses a different set of challenges as spokes can exchange multicast messages only with hub thus rendering spoke-to-spoke MPLS communication impossible.

There is a third solution that is both scalable enough and capable of disseminating useful data between spokes – BGP labeled unicast. There are a few configuration options that allow spokes become PEs (e.g. option 1 – VPN labeled packet sent directly to spoke, DMVPN Phase 2; option 2 – hub involved into VRF forwarding and DMVPN Phase 3 redirection); however, it might be worth having flexibility to put PE role on a router behind a spoke or a hub, thus making them P-routers.

It’s time to build a lab and make our way up to the solution. Here is the topology we are going to look at during 2547oDMVPN discussion:

Router roles are listed below:

  • R1, R5, R7 (and R6 later) – MPLS PE;
  • R3 – ISP for DMVPN;
  • R2 – DMVPN hub;
  • R4, R6 – DMVPN spokes.

Routing protocols:

  • R1-R2, R4-R5, R6-R7 – OSPF, local office IGP;
  • R3 – ISP OSPF, connectivity for DMVPN routers;
  • R1, R5, R7 (R6) – MP-BGP VPNv4 AF;
  • R2, R4, R6 – MP-BGP IPv4 AF;

Loopback0 serves the purpose of unique router identification, e.g. OSPF RID. Loopback1 is used as BGP LU source (exact reason is discussed later). Loopback2 emulates client networks in VRFs.

Now that we’ve dealt with an overview of the topology, let’s create some initial configuration, starting from PEs:

R1(config)#vrf definition A
R1(config-vrf)#rd 1:1
R1(config-vrf)#address-family ipv4
R1(config-vrf-af)#route-target export 1:1
R1(config-vrf-af)#route-target import 1:1
R1(config-if)#interface Loopback0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#interface Loopback2
R1(config-if)#vrf forwarding A
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#interface FastEthernet0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#mpls ldp router-id Loopback0
R1(config)#router ospf 1
R1(config-router)#mpls ldp autoconfig
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 0.0.0.0 255.255.255.255 area 0
R1(config)#router bgp 1
R1(config-router)#template peer-policy L3VPN
R1(config-router-ptmp)#send-community both
R1(config-router-ptmp)#exit-peer-policy
R1(config-router)#template peer-session SESSION
R1(config-router-stmp)#remote-as 1
R1(config-router-stmp)#update-source Loopback0
R1(config-router-stmp)#exit-peer-session
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router)#no bgp default ipv4-unicast
R1(config-router)#neighbor 5.5.5.5 inherit peer-session SESSION
R1(config-router)#neighbor 7.7.7.7 inherit peer-session SESSION
R1(config-router)#address-family vpnv4
R1(config-router-af)#neighbor 5.5.5.5 activate
R1(config-router-af)#neighbor 5.5.5.5 send-community extended
R1(config-router-af)#neighbor 5.5.5.5 inherit peer-policy L3VPN
R1(config-router-af)#neighbor 7.7.7.7 activate
R1(config-router-af)#neighbor 7.7.7.7 send-community extended
R1(config-router-af)#neighbor 7.7.7.7 inherit peer-policy L3VPN
R1(config-router-af)#exit-address-family
R1(config-router)#address-family ipv4 vrf A
R1(config-router-af)#redistribute connected
R1(config-router-af)#exit-address-family
R5(config)#vrf definition A
R5(config-vrf)# rd 1:1
R5(config-vrf)# address-family ipv4
R5(config-vrf-af)#  route-target export 1:1
R5(config-vrf-af)#  route-target import 1:1
R5(config-vrf-af)# exit-address-family
R5(config-vrf)#interface Loopback0
R5(config-if)# ip address 5.5.5.5 255.255.255.255
R5(config-if)#interface Loopback2
R5(config-if)# vrf forwarding A
R5(config-if)# ip address 5.5.5.5 255.255.255.255
R5(config-if)#interface FastEthernet0/0
R5(config-if)# ip address 192.168.45.5 255.255.255.0
R5(config-if)#mpls ldp router-id Loopback0
R5(config)#router ospf 1
R5(config-router)# mpls ldp autoconfig
R5(config-router)# router-id 5.5.5.5
R5(config-router)# network 0.0.0.0 255.255.255.255 area 0
R5(config-router)#router bgp 1
R5(config-router)# template peer-policy L3VPN
R5(config-router-ptmp)#  send-community both
R5(config-router-ptmp)# exit-peer-policy
R5(config-router)# template peer-session SESSION
R5(config-router-stmp)#  remote-as 1
R5(config-router-stmp)#  update-source Loopback0
R5(config-router-stmp)# exit-peer-session
R5(config-router)# bgp router-id 5.5.5.5
R5(config-router)# no bgp default ipv4-unicast
R5(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R5(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION
R5(config-router)# address-family vpnv4
R5(config-router-af)#  neighbor 1.1.1.1 activate
R5(config-router-af)#  neighbor 1.1.1.1 send-community extended
R5(config-router-af)#  neighbor 1.1.1.1 inherit peer-policy L3VPN
R5(config-router-af)#  neighbor 7.7.7.7 activate
R5(config-router-af)#  neighbor 7.7.7.7 send-community extended
R5(config-router-af)#  neighbor 7.7.7.7 inherit peer-policy L3VPN
R5(config-router-af)# exit-address-family
R5(config-router)# address-family ipv4 vrf A
R5(config-router-af)#  redistribute connected R5(config-router-af)# exit-address-family
R7(config)#vrf definition A
R7(config-vrf)# rd 1:1
R7(config-vrf)# address-family ipv4
R7(config-vrf-af)#  route-target export 1:1
R7(config-vrf-af)#  route-target import 1:1
R7(config-vrf-af)# exit-address-family
R7(config-vrf)#interface Loopback0
R7(config-if)# ip address 7.7.7.7 255.255.255.255
R7(config-if)#interface Loopback2
R7(config-if)# vrf forwarding A
R7(config-if)# ip address 7.7.7.7 255.255.255.255
R7(config-if)#interface FastEthernet0/0
R7(config-if)# ip address 192.168.67.7 255.255.255.0
R7(config-if)#mpls ldp router-id Loopback0
R7(config)#router ospf 1
R7(config-router)# mpls ldp autoconfig
R7(config-router)# router-id 7.7.7.7
R7(config-router)# network 0.0.0.0 255.255.255.255 area 0
R7(config-router)#router bgp 1
R7(config-router)# template peer-policy L3VPN
R7(config-router-ptmp)#  send-community both
R7(config-router-ptmp)# exit-peer-policy
R7(config-router)# template peer-session SESSION
R7(config-router-stmp)#  remote-as 1
R7(config-router-stmp)#  update-source Loopback0
R7(config-router-stmp)# exit-peer-session
R7(config-router)# bgp router-id 7.7.7.7
R7(config-router)# bgp log-neighbor-changes
R7(config-router)# no bgp default ipv4-unicast
R7(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R7(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION
R7(config-router)# address-family ipv4
R7(config-router-af)# exit-address-family
R7(config-router)# address-family vpnv4
R7(config-router-af)#  neighbor 1.1.1.1 activate
R7(config-router-af)#  neighbor 1.1.1.1 send-community extended
R7(config-router-af)#  neighbor 1.1.1.1 inherit peer-policy L3VPN
R7(config-router-af)#  neighbor 5.5.5.5 activate
R7(config-router-af)#  neighbor 5.5.5.5 send-community extended
R7(config-router-af)#  neighbor 5.5.5.5 inherit peer-policy L3VPN
R7(config-router-af)# exit-address-family
R7(config-router)# address-family ipv4 vrf A
R7(config-router-af)#  redistribute connected R7(config-router-af)# exit-address-family

The next step would be connecting DMVPN routers to the corresponding local segments:

R2(config)#interface Loopback0
R2(config-if)# ip address 2.2.2.2 255.255.255.255
R2(config-if)#interface FastEthernet0/0
R2(config-if)# ip address 192.168.12.2 255.255.255.0
R2(config-if)#mpls ldp router-id Loopback0
R2(config)#router ospf 1
R2(config-router)# mpls ldp autoconfig
R2(config-router)# router-id 2.2.2.2
R2(config-router)# redistribute bgp 1 subnets
R2(config-router)# passive-interface default
R2(config-router)# no passive-interface FastEthernet0/0
R2(config-router)# no passive-interface Loopback0
R2(config-router)# network 0.0.0.0 255.255.255.255 area 0
R4(config)#interface Loopback0
R4(config-if)# ip address 4.4.4.4 255.255.255.255
R4(config-if)#interface FastEthernet0/0
R4(config-if)# ip address 192.168.45.4 255.255.255.0
R4(config-if)#mpls ldp router-id Loopback0
R4(config)#router ospf 1
R4(config-router)# mpls ldp autoconfig
R4(config-router)# router-id 4.4.4.4
R4(config-router)# redistribute bgp 1 subnets
R4(config-router)# passive-interface default
R4(config-router)# no passive-interface FastEthernet0/0
R4(config-router)# no passive-interface Loopback0
R4(config-router)# network 0.0.0.0 255.255.255.255 area 0
R6(config)#interface Loopback0
R6(config-if)# ip address 6.6.6.6 255.255.255.255
R6(config-if)#interface FastEthernet0/0
R6(config-if)# ip address 192.168.67.6 255.255.255.0
R6(config-if)#mpls ldp router-id Loopback0
R6(config)#router ospf 1
R6(config-router)# mpls ldp autoconfig
R6(config-router)# redistribute bgp 1 subnets
R6(config-router)# passive-interface default
R6(config-router)# no passive-interface FastEthernet0/0
R6(config-router)# no passive-interface Loopback0
R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Now to the last piece of preparation for BGP LU discussion – DMVPN configuration. Front-door VRF approach is used in this example to keep RIB clean.

R3(config)#interface Loopback0
R3(config-if)# ip address 3.3.3.3 255.255.255.255
R3(config-if)#interface FastEthernet0/1
R3(config-if)# ip address 192.168.34.3 255.255.255.0
R3(config-if)#interface FastEthernet1/0
R3(config-if)# ip address 192.168.23.3 255.255.255.0
R3(config-if)#interface FastEthernet1/1
R3(config-if)# ip address 192.168.36.3 255.255.255.0
R3(config-if)#router ospf 1
R3(config-router)# router-id 3.3.3.3
R3(config-router)# network 0.0.0.0 255.255.255.255 area 0
R2(config)#vrf definition FVRF
R2(config-vrf)# rd 1:1
R2(config-vrf)# address-family ipv4
R2(config-vrf-af)# exit-address-family
R2(config-vrf)#interface Tunnel0
R2(config-if)# ip address 192.168.0.2 255.255.255.0
R2(config-if)# no ip redirects
R2(config-if)# ip nhrp map multicast dynamic
R2(config-if)# ip nhrp network-id 1
R2(config-if)# ip nhrp redirect
R2(config-if)# tunnel source FastEthernet1/0
R2(config-if)# tunnel mode gre multipoint
R2(config-if)# tunnel vrf FVRF
R2(config-if)#interface FastEthernet1/0
R2(config-if)# vrf forwarding FVRF
R2(config-if)# ip address 192.168.23.2 255.255.255.0
R2(config-if)#router ospf 2 vrf FVRF
R2(config-router)# router-id 192.168.23.2
R2(config-router)# network 0.0.0.0 255.255.255.255 area 0
R4(config)#vrf definition FVRF
R4(config-vrf)# rd 1:1
R4(config-vrf)# address-family ipv4
R4(config-vrf-af)# exit-address-family
R4(config-vrf)#interface Tunnel0
R4(config-if)# ip address 192.168.0.4 255.255.255.0
R4(config-if)# no ip redirects
R4(config-if)# ip nhrp network-id 1
R4(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicast
R4(config-if)# ip nhrp shortcut
R4(config-if)# tunnel source FastEthernet0/1
R4(config-if)# tunnel mode gre multipoint
R4(config-if)# tunnel vrf FVRF
R4(config-if)#interface FastEthernet0/1
R4(config-if)# vrf forwarding FVRF
R4(config-if)# ip address 192.168.34.4 255.255.255.0
R4(config-if)#router ospf 2 vrf FVRF
R4(config-router)# router-id 192.168.34.4
R4(config-router)# network 0.0.0.0 255.255.255.255 area 0
R6(config)#vrf definition FVRF
R6(config-vrf)# rd 1:1
R6(config-vrf)# address-family ipv4
R6(config-vrf-af)# exit-address-family
R6(config-vrf)#interface Tunnel0
R6(config-if)# ip address 192.168.0.6 255.255.255.0
R6(config-if)# no ip redirects
R6(config-if)# ip nhrp network-id 1
R6(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicast
R6(config-if)# ip nhrp shortcut
R6(config-if)# tunnel source FastEthernet1/1
R6(config-if)# tunnel mode gre multipoint
R6(config-if)# tunnel vrf FVRF
R6(config-if)#interface FastEthernet1/1
R6(config-if)# vrf forwarding FVRF
R6(config-if)# ip address 192.168.36.6 255.255.255.0
R6(config-if)#router ospf 2 vrf FVRF
R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Now it’s time to discuss some business. In order to make L3VPN work end-to-end, LSP has to be in place. As we’ve discussed above, neither LDP nor RSVP are suited for the task so we are going to use MP-BGP that should carry out the following:

  • distribute IP prefixes of loopbacks on PEs;
  • distribute corresponding labels.

Seems to be easy enough. Let’s take a look at MPLS-enabled interfaces on R2:

R2#sho mpls interfaces 
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        Yes (ldp)     No       No  No     Yes  

Note there is no Tunnel0 interface listed. We aim at enabling just MPLS forwarding without starting LDP, so “mpls ip” command does not satisfy our requirements. There is a little less known command the does exactly what we need:

R2(config)#interface Tunnel0
R2(config-if)#mpls bgp forwarding
R2#sho mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        Yes (ldp)     No       No  No     Yes        
Tunnel0                No            No       Yes No     Yes  

After replicating the same command on spokes, we can get down to BGP configuration. For this discussion we would use iBGP between hub and spokes; hub would act as a route-reflector as well as listen for inbound BGP connections:

R2(config)#router bgp 1
R2(config-router)# bgp router-id 2.2.2.2
R2(config-router)# bgp listen range 192.168.0.0/24 peer-group DMVPN
R2(config-router)# no bgp default ipv4-unicast
R2(config-router)# neighbor DMVPN peer-group
R2(config-router)# neighbor DMVPN remote-as 1
R2(config-router)# neighbor DMVPN update-source Tunnel0
R2(config-router)# address-family ipv4
R2(config-router-af)#  network 1.1.1.1 mask 255.255.255.255
R2(config-router-af)#  neighbor DMVPN activate
R2(config-router-af)#  neighbor DMVPN route-reflector-client
R2(config-router-af)#  neighbor DMVPN send-label
R4(config)#router bgp 1
R4(config-router)# bgp router-id 4.4.4.4
R4(config-router)# no bgp default ipv4-unicast
R4(config-router)# neighbor 192.168.0.2 remote-as 1
R4(config-router)# neighbor 192.168.0.2 update-source Tunnel0
R4(config-router)# address-family ipv4
R4(config-router-af)#  network 5.5.5.5 mask 255.255.255.255
R4(config-router-af)#  neighbor 192.168.0.2 activate
R4(config-router-af)#  neighbor 192.168.0.2 send-label
R6(config)#router bgp 1
R6(config-router)# bgp router-id 6.6.6.6
R6(config-router)# no bgp default ipv4-unicast
R6(config-router)# neighbor 192.168.0.2 remote-as 1
R6(config-router)# neighbor 192.168.0.2 update-source Tunnel0
R6(config-router)# address-family ipv4
R6(config-router-af)#  network 7.7.7.7 mask 255.255.255.255
R6(config-router-af)#  neighbor 192.168.0.2 activate
R6(config-router-af)#  neighbor 192.168.0.2 send-label

Let’s check whether this configuration works on IP level:

R5#ping 1.1.1.1 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/64 ms

However, is it enough to have end-to-end connectivity for VRF?

R5#ping vrf A 1.1.1.1 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5
.....
Success rate is 0 percent (0/5)

Unfortunately, there is a little bit more to it. The reason for this particular failure is the absence of a functional LSP:

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5
Sending 5, 100-byte MPLS Echos to 1.1.1.1/32,      timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,   'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
BBBBB Success rate is 0 percent (0/5)

Specifically, the failure point is again R4:

R4#sho mpls forwarding-table 1.1.1.1 32
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
19         No Label   1.1.1.1/32       1125          Tu0        192.168.0.2

Is it really though? Shouldn’t R2 have sent R4 the prefix with a label?

R4#sho ip bgp labels 
   Network          Next Hop      In label/Out label
   1.1.1.1/32       192.168.12.1    nolabel/nolabel
   2.2.2.2/32       192.168.0.2       nolabel/imp-null    <output omitted>

Here is an important observation. 1.1.1.1/32 is sent unlabeled while 2.2.2.2/32 is perfectly fine. Also note an “inconsistent” next-hop for 1.1.1.1/32 – it’s R1 address instead of one of R2. R2 imported a prefix while preserving the original next-hop from the RIB. Since the R2-R4 session is iBGP, nexthop is kept as is. 2.2.2.2/32, on the other hand, has R2 as a next-hop. This subtle difference is a key for R2 behaviour: BGP assigns a label to a prefix only if BGP speaker is a next-hop itself for that prefix.

Given some thought, it makes sense though: R2 has to assign its own label to an update if it is within LSP. If next-hop is not R2, however, injecting a label cannot be guaranteed to be valid as a packet may pass along another way, not including R2.

In this case we would like to assign labels to prefixes coming from route import to BGP but there should be no change to reflected packets:

R2(config)#router bgp 1
R2(config-router)#address-family ipv4
R2(config-router-af)#neighbor PEER next-hop-self ?    all  Enable next-hop-self for both eBGP and iBGP received paths   <cr>
R2(config-router-af)#neighbor PEER next-hop-self

The defaults are tricky here. The command we’ve issued makes R2 change next-hop for local  and eBGP prefixes but not for iBGP ones; the keyword “all” would allow such a change for iBGP prefixes too.

Does it solve the issue?

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5
<output omitted>
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/72 ms
R5#
R5#ping vrf A 1.1.1.1 so lo 0              Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/108 ms
R5#
R5#ping mpls ipv4 7.7.7.7/32 source 5.5.5.5
<output omitted>
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 ms
R5#
R5#ping vrf A 7.7.7.7 so lo 2              Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/79/104 ms
R5#
R5#traceroute 7.7.7.7 so lo 0 Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
1    192.168.45.4 [MPLS: Label 22 Exp 0] 88 msec 80 msec 80 msec
2    192.168.0.6 [MPLS: Label 16 Exp 0] 52 msec 64 msec 52 msec
3    192.168.67.7 40 msec 64 msec 64 msec

We’ve achieved L3VPN across DMVPN cloud. However, if you followed the configuration on your own so far, you might have noticed a warning that IOS issued when we configured BGP LU:

R4(config-router-af)#neighbor 192.168.0.2 send-label
%BGP: For distributing MPLS labels to IBGP peers, the update source should be set to a loopback interface

Quite an interesting message we’ve got in a log. Although it seems alerting, the communication between PEs still works. What’s the issue here then? Consider the topology below:

For the sake of this example, R1 establishes BGP session from its f0/0 interface to R3 loopback, mimicking our DMVPN deployment. Although control plane would work perfectly fine, the data plane, specifically LSP, would be broken and the reason for that is PHP, penultimate hop popping. R1 source interface would reside in connected subnet for R2, so the latter would announce implicit-null for the subnet towards R3. Then the following events should occur:

  • R3 prepends VPN label (some value, e.g. 16) to a packet;
  • R3 prepends transport label (implicit-null) to the packet;
  • R3 forwards the MPLS frame towards R2 with VPN label being on top of the stack.

There are two possible outcomes for R2: it might have no idea what to do with the frame (no VPN label match in LFIB) or it would steer the frame in a wrong direction (accidental match between VPN label and LFIB). Either way, R1 has no chance of receiving the frame thus rendering LSP broken. Note that explicit-null would not remedy the situation as it is not used for forwarding.

What does it have to do with our case anyway? The issue above is related to PEs being incorrectly configured. However, if we introduced PE role to either of DMVPN routers, we would face the same challenge since BGP is not configured on a loopback as a source interface. One might suggest migrating BGP configuration entirely to loopbacks; however, it would bring LSPs down since there would be nobody left to announce labels for the loopbacks themselves – usually it’s LDP/RSVP job. There is an easier approach though: use loopbacks only for VPNv4 AF sessions as well as announcing them via BGP LU. Let’s check it out:

R6(config)#vrf definition A
R6(config-vrf)# rd 2:2
R6(config-vrf)# address-family ipv4
R6(config-vrf-af)#  route-target export 1:1
R6(config-vrf-af)#  route-target import 1:1
R6(config-vrf-af)# exit-address-family
R6(config-vrf)#interface Loopback1
R6(config-if)# ip address 100.0.0.6 255.255.255.255
R6(config-if)#interface Loopback2
R6(config-if)# vrf forwarding A
R6(config-if)# ip address 6.6.6.6 255.255.255.255
R6(config-if)#router bgp 1
R6(config-router)# template peer-policy L3VPN
R6(config-router-ptmp)#  send-community both
R6(config-router-ptmp)# exit-peer-policy
R6(config-router)# template peer-session SESSION
R6(config-router-stmp)#  remote-as 1
R6(config-router-stmp)#  update-source Loopback1
R6(config-router-stmp)# exit-peer-session
R6(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R6(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION
R6(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION
R6(config-router)# address-family ipv4
R6(config-router-af)#  network 100.0.0.6 mask 255.255.255.255
R6(config-router-af)# exit-address-family
R6(config-router)# address-family vpnv4
R6(config-router-af)#  neighbor 1.1.1.1 activate
R6(config-router-af)#  neighbor 1.1.1.1 send-community extended
R6(config-router-af)#  neighbor 1.1.1.1 inherit peer-policy L3VPN
R6(config-router-af)#  neighbor 5.5.5.5 activate
R6(config-router-af)#  neighbor 5.5.5.5 send-community extended
R6(config-router-af)#  neighbor 5.5.5.5 inherit peer-policy L3VPN
R6(config-router-af)#  neighbor 7.7.7.7 activate
R6(config-router-af)#  neighbor 7.7.7.7 send-community extended
R6(config-router-af)#  neighbor 7.7.7.7 inherit peer-policy L3VPN
R6(config-router-af)# exit-address-family
R6(config-router)# address-family ipv4 vrf A
R6(config-router-af)#  redistribute connected R6(config-router-af)# exit-address-family

Now R6 is a part of L3VPN overlay, it’s time to see if reachability is in place:

R6#tclsh                                                      
R6(tcl)#foreach x {1.1.1.1 5.5.5.5 7.7.7.7} {ping vrf A $x so lo 2} Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/84 ms Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/44 ms Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms

Now the connectivity is established as expected. In my opinion, the caveats of such a configuration are the following:

  1. mere existence of BGP IPv4 labeled unicast;
  2. BGP label assignment only in case the speaker is next-hop for the prefix;
  3. PHP being able to break LSP.

In this article we’ve discussed MPLS L3VPN over DMVPN (2547oDMVPN) leveraging iBGP LU to distribute MPLS labels for the underlay. An important distinction from the documented solutions is the ability to put PEs behind the spokes or hubs while maintaining direct spoke-to-spoke communication within DMVPN. As for eBGP configuration, I would leave it as an exercise for a curious reader.

Initial version of this article can be found in the Iaroslav blog.

Add comment


Security code
Refresh

Found a typo? Please select it and press Ctrl + Enter.