MPLS over FlexVPN

With MPLS over FlexVPN, we combine the advantages of FlexVPN and MPLS. FlexVPN allows us to create a secure hub and spoke network where direct spoke-to-spoke traffic is possible because of NHRP. By using VRFs and MPLS, we can have overlapping addresses in customer networks.

MPLS over FlexVPN is a good choice if you want to extend your MPLS network securely over the Internet.

We require the following components to run MPLS over FlexVPN:

• IKEv2 and IPSec: to create security associations and encrypt our traffic.
• NHRP: to make direct spoke-to-spoke traffic possible. A difference with DMVPN is that we only use NHRP for redirection. Spoke routers don’t register themselves with the hub router.
• MPLS: for label switching. We don’t use LDP. There are two main reasons not to use LDP:
  • • When we use LDP to distribute transport labels, it has to establish a neighbor adjacency with every LDP neighbor. There will be quite some overhead when you have many remote peers.
    • LDP keepalive will keep the spoke-to-spoke tunnels active, even if there is no traffic between the spoke routers.
• MPLS Forwarding Infrastructure (MFI): Manages the MPLS data structures we use for forwarding. Cisco replaced the Label Forwarding Information Base (LFIB) with the MFI on recent IOS and IOS XE images. NHRP is an application that calls MFI for label management.
• MP-BGP: Distributes overlay labels for the prefixes on different VRFs.

Let me give you a walkthrough of how these different components work together when we run MPLS over FlexVPN. Take a look at the following topology:

Here is our starting point:

• We use VRF “CUSTOMER” on the GigabitEthernet 0/1 interfaces of the spoke routers.
• We use MP-BGP to advertise labels for the networks in each VRF:
  • The spoke routers advertise the /24 network on their GigabitEthernet 0/1 interface.
  • The hub router advertises a 10.0.0.0/8 summary route so the spoke routers know how to reach each others networks.

Here’s how it works:

1. The spoke routers establish IKEv2 and IPSec security associations with the hub router.
2. The routers install an implicit null label for the tunnel interfaces. We use an implicit null label because the remote tunnel interface is always only one hop away.
3. MP-BGP exchanges labels for the prefixes in each VRF.
4. CE1 (10.1.1.101) sends an IP packet to CE2 (10.2.2.102).
5. Spoke1 receives the IP packet, adds the label that matches the summary route from the hub, encapsulates the IP packet with GRE, and forwards it through the tunnel interface to the hub router.
6. The hub router decrypts the IP packet and looks up the required label to reach 10.2.2.102.
7. The hub router adds the label that matches the 10.2.2.0/24 network, encapsulates the IP packet with GRE, and sends the packet to the spoke2 router.
8. The hub router also sends an NHRP redirect packet to the spoke1 router and adds the label that matches the 10.1.1.0/24 prefix where the IP packet originated from.
9. The spoke1 router receives and processes the NHRP redirect packet which triggers an NHRP resolution request.
10. The spoke1 router creates an NHRP mapping entry and associates it with VRF “CUSTOMER” for the 10.2.2.0/24 prefix.
11. The spoke1 router sends an NHRP resolution request to the hub router. The NHRP resolution request includes a request ID which we later need when we receive an NHRP resolution reply.
12. The hub router receives the NHRP resolution request, looks up the label for 10.2.2.0/24, and forwards the NHRP resolution request to the spoke2 router.
13. The spoke2 router receives the NHRP resolution request and creates a virtual-access interface.
14. The spoke2 router initiates an IKEv2 and IPSec SA with the spoke1 router.
15. NHRP installs the route for the spoke1 router’s virtual-access interface IP address.
16. The spoke2 router sends an NHRP resolution reply to the spoke1 router using the virtual-access interface.
17. The NHRP resolution reply from the spoke2 router includes:
    1. The label that the spoke1 router can use to send IP packets over the spoke-to-spoke tunnel. NHRP gets this label from the MPLS Forwarding Infrastructure (MFI).
    2. An implicit null label for the IP address of the spoke2 router’s virtual-access interface.
18. The spoke1 router receives the NHRP resolution reply on its virtual-access interface. The NHRP resolution reply includes the request ID that the spoke1 router added in the NHRP resolution request. This is how the spoke1 router knows to which VRF the NHRP resolution reply belongs.
19. The spoke1 router looks up the NHRP entry in the NHRP cache and inserts a route in the VRF routing table.
20. The spoke1 and spoke2 can now label switch packets directly using their virtual-access interfaces for the VRF.

Configuration

Let’s dive into the configuration. Most of the configurations are similar to what we did in the FlexVPN spoke-to-spoke pool and BGP lesson. Let’s use the topology I showed you before:

I will focus on the configuration parts that we haven’t seen before. I’m using IOSv Version 15.9(3)M2 on all routers.

hostname CE1
!
ip cef
!
interface GigabitEthernet0/0
 ip address 10.1.1.101 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
end

hostname CE2
!
ip cef
!
interface GigabitEthernet0/0
 ip address 10.2.2.102 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.2.2.2
!
end

hostname Hub1
!
interface Loopback0
 ip address 172.16.1.254 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.1.254 255.255.255.0
!
end

hostname Spoke1
!
interface Loopback0
 ip address 172.16.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
end

hostname Spoke2
!
interface Loopback0
 ip address 172.16.1.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.1.2 255.255.255.0
!
end

Hub1

Let’s start with the hub router.

IKEv2 Keyring

We need a keyring with an entry for our spoke routers:

Hub1(config)#crypto ikev2 keyring KEYRING
Hub1(config-ikev2-keyring)#peer SPOKE_ROUTERS
Hub1(config-ikev2-keyring-peer)#address 0.0.0.0 0.0.0.0
Hub1(config-ikev2-keyring-peer)#pre-shared-key local CISCO
Hub1(config-ikev2-keyring-peer)#pre-shared-key remote CISCO

IKEv2 Authorization Policy

In the IKEv2 authorization policy, we advertise our tunnel IP address through IKEv2:

Hub1(config)#aaa new-model

Hub1(config)#aaa authorization network FLEXVPN_LOCAL local 

Hub1(config)#crypto ikev2 authorization policy IKEV2_AUTHORIZATION 
Hub1(config-ikev2-author-policy)#route set interface

IKEv2 Profile

Let’s create an IKEv2 profile:

Hub1(config)#crypto ikev2 profile IKEV2_PROFILE
Hub1(config-ikev2-profile)#match identity remote fqdn domain FLEXVPN.LAB
Hub1(config-ikev2-profile)#identity local fqdn HUB.FLEXVPN.LAB
Hub1(config-ikev2-profile)#authentication remote pre-share
Hub1(config-ikev2-profile)#authentication local pre-share
Hub1(config-ikev2-profile)#keyring local KEYRING
Hub1(config-ikev2-profile)#aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION   
Hub1(config-ikev2-profile)#virtual-template 1

IPSec Profile

Let’s configure the IPSec profile:

Hub1(config-ikev2-profile)#crypto ipsec profile IPSEC_PROFILE
Hub1(ipsec-profile)#set ikev2-profile IKEV2_PROFILE

Dynamic VTI

The dynamic VTI interface on the hub is slightly different. We have to add the mpls nhrp command here which enables label switching without LDP:

Hub1(config)#interface Virtual-Template1 type tunnel
Hub1(config-if)#ip unnumbered Loopback0
Hub1(config-if)#ip nhrp network-id 1
Hub1(config-if)#ip nhrp redirect
Hub1(config-if)#mpls nhrp
Hub1(config-if)#tunnel protection ipsec profile IPSEC_PROFILE

VRF

Let’s create a VRF for our customer:

Hub1(config)#vrf definition CUSTOMER
Hub1(config-vrf)#rd 1:1
Hub1(config-vrf)#route-target export 1:1
Hub1(config-vrf)#route-target import 1:1
Hub1(config-vrf)#address-family ipv4

MP-BGP

We use MP-BGP to advertise our VPN routes. First, I’ll add a static route in the VRF:

Hub1(config)#ip route vrf CUSTOMER 10.0.0.0 255.0.0.0 Null0

Now we can configure MP-BGP.  I’ll create a peer group for my spoke routers so I don’t have to configure them one by one. We enable the VPNv4 address-family and advertise the static route in the VRF:

Hub1(config)#router bgp 1
Hub1(config-router)#bgp router-id 172.16.1.254
Hub1(config-router)#bgp listen range 172.16.1.0/24 peer-group FLEXVPN_SPOKES
Hub1(config-router)#neighbor FLEXVPN_SPOKES peer-group
Hub1(config-router)#neighbor FLEXVPN_SPOKES remote-as 1
Hub1(config-router)#neighbor FLEXVPN_SPOKES transport connection-mode passive
Hub1(config-router)#neighbor FLEXVPN_SPOKES update-source Loopback0

Hub1(config-router)#address-family vpnv4
Hub1(config-router-af)#neighbor FLEXVPN_SPOKES activate
Hub1(config-router-af)#neighbor FLEXVPN_SPOKES send-community both
Hub1(config-router-af)#exit-address-family

Hub1(config-router)#address-family ipv4 vrf CUSTOMER
Hub1(config-router-af)#network 10.0.0.0
Hub1(config-router-af)#exit-address-family

This completes the configuration of the hub router.

Spoke1

Let’s configure the spoke router.

IKEv2 Keyring

Let’s create the IKEv2 keyring where we specify the hub and spoke2 router:

Spoke1(config)#crypto ikev2 keyring KEYRING
Spoke1(config-ikev2-keyring)#peer HUB1
Spoke1(config-ikev2-keyring-peer)#address 192.168.1.254
Spoke1(config-ikev2-keyring-peer)#pre-shared-key local CISCO
Spoke1(config-ikev2-keyring-peer)#pre-shared-key remote CISCO

Spoke1(config-ikev2-keyring-peer)#peer SPOKE2
Spoke1(config-ikev2-keyring-peer)#address 192.168.1.2
Spoke1(config-ikev2-keyring-peer)#pre-shared-key local CISCO
Spoke1(config-ikev2-keyring-peer)#pre-shared-key remote CISCO

IKEv2 Authorization Policy

We create an IKEv2 authorization policy so we can advertise the tunnel IP address through IKEv2:

Spoke1(config)#aaa new-model

Spoke1(config)#aaa authorization network FLEXVPN_LOCAL local 

Spoke1(config)#crypto ikev2 authorization policy IKEV2_AUTHORIZATION 
Spoke1(config-ikev2-author-policy)#route set interface

IKEv2 Profile

We need an IKEv2 profile:

Spoke1(config)#crypto ikev2 profile IKEV2_PROFILE
Spoke1(config-ikev2-profile)#match identity remote fqdn HUB.FLEXVPN.LAB
Spoke1(config-ikev2-profile)#match identity remote fqdn SPOKE2.FLEXVPN.LAB
Spoke1(config-ikev2-profile)# dentity local fqdn SPOKE1.FLEXVPN.LAB
Spoke1(config-ikev2-profile)#authentication remote pre-share
Spoke1(config-ikev2-profile)#authentication local pre-share
Spoke1(config-ikev2-profile)#keyring local KEYRING
Spoke1(config-ikev2-profile)#aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION

IPSec Profile

We create the IPSec profile:

Spoke1(config)#crypto ipsec profile IPSEC_PROFILE
Spoke1(ipsec-profile)#set ikev2-profile IKEV2_PROFILE

Static VTI

Our static VTI requires the mpls nhrp command so that we can label switch on the tunnel interface which connects to the hub:

Spoke1(config)#interface Tunnel0
Spoke1(config-if)#ip unnumbered Loopback0
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp shortcut virtual-template 1
Spoke1(config-if)#mpls nhrp
Spoke1(config-if)#tunnel source GigabitEthernet0/0
Spoke1(config-if)#tunnel destination 192.168.1.254
Spoke1(config-if)#tunnel protection ipsec profile IPSEC_PROFILE

Dynamic VTI

The dynamic VTI also requires the mpls nhrp command so that we can label switch with other spoke routers:

Spoke1(config)#interface Virtual-Template1 type tunnel
Spoke1(config-if)#ip unnumbered Loopback0
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp shortcut virtual-template 1
Spoke1(config-if)#mpls nhrp
Spoke1(config-if)#tunnel source GigabitEthernet0/0
Spoke1(config-if)#tunnel protection ipsec profile IPSEC_PROFILE

VRF

We create the VRF “CUSTOMER” globally and enable the VRF on our GigabitEthernet0/1 interface: