MPLS Intro Series – Introduction to VPNv4

In the previous article, we took a look at building a simple label switched path (LSP) through an MPLS network. This article takes the configuration a step further and leverages multiple labels to connect and isolate VRFs over an MPLS core. This is known as MPLS VPNv4. My goal is to introduce a method to bring together VRF segmentation concepts and provide a framework for a scalable deployment.

Before we get started, I am going to rename the routers once again based on their target function. An LER in a VPNv4 configuration is known as a PE node. An LSR router is known as a P node. I am also introducing CE (customer edge) nodes into the topology.

Desired End State

In this example, we will allow CE_Site_1 to communicate with CE_Site_2. Likewise, we want CE_Site_3 to communicate with CE_Site_4.

Terms

  • P Router – provider router, is considered transit in a label switched path, the term is often used interchangeably with LSR
  • PE Router – provider edge router and sits on the provider side of the provider/customer interconnection. Has most of the intelligence and configuration for an LSP and allows a scale-out architecture. The term PE is more common but may be used interchangeably with LER
  • CE Router – customer edge router, is the router that sits on the customer side of the provider/customer interconnection
  • LDP – Label Distribution Protocol – Establishes adjacencies and exchanges label mapping information between MPLS nodes
  • PHP – Penultimate Hop Popping, removing (pop operation) an MPLS label at the next to last hop

Note: PE and CE functions may be consolidated into a single router in deployments where an entity deploys their own MPLS network for segmentation. An example would be an enterprise that uses VRFs in each building and leverages an MPLS core. In that case, a node serving as a PE/CE router may service each building.

The configuration of P1 through P4 was completed in MPLS Intro Series – Understanding a Simple LSP. For this exercise, we require no additional configuration for the LSP across the core. We will also assume that all CE routers are properly configured with an appropriate IP address and default route pointing toward their respective PE nodes. Our focus will be on the configuration and function of the PE routers.

PE1 Configuration

//create a vrf for RED (CE_Site_1 <> CE_Site_2)
vrf definition RED
 rd 100:200
 route-target export 1000:2000
 route-target import 1000:2000
 !
 address-family ipv4
 exit-address-family
!
//create a vrf for BLUE (CE_Site_3 <> CE_Site_4)
vrf definition BLUE
 rd 110:210
 route-target export 1100:2100
 route-target import 1100:2100
 !
 address-family ipv4
 exit-address-family
!
//assign the customer interfaces to their respective VRFs
interface GigabitEthernet4
 description to CE_Site1
 vrf forwarding RED
 ip address 10.1.1.1 255.255.255.0
!
interface GigabitEthernet5
 description to CE_Site3
 vrf forwarding BLUE
 ip address 10.3.3.1 255.255.255.0
!
//configure MP-BGP for VPNv4
router bgp 1
 no bgp default ipv4-unicast
 neighbor 20.20.20.20 remote-as 1
 neighbor 20.20.20.20 update-source Loopback0
 !
 address-family vpnv4
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 send-community both
 exit-address-family
 !
 address-family ipv4 vrf BLUE
  redistribute connected
 exit-address-family
 !
 address-family ipv4 vrf RED
  redistribute connected
 exit-address-family

PE2 Configuration

//create a vrf for RED (CE_Site_1 <> CE_Site_2)
vrf definition RED
 rd 100:200
 route-target export 1000:2000
 route-target import 1000:2000
 !
 address-family ipv4
 exit-address-family
!
//create a vrf for BLUE (CE_Site_3 <> CE_Site_4)
vrf definition BLUE
 rd 110:210
 route-target export 1100:2100
 route-target import 1100:2100
 !
 address-family ipv4
 exit-address-family
!
//assign the customer interfaces to their respective VRFs
interface GigabitEthernet4
 description to CE_Site2
 vrf forwarding RED
 ip address 20.2.2.1 255.255.255.0
!
interface GigabitEthernet5
 description to CE_Site4
 vrf forwarding BLUE
 ip address 20.4.4.1 255.255.255.0
!
//configure MP-BGP for VPNv4
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.10 remote-as 1
 neighbor 10.10.10.10 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community both
 exit-address-family
 !
 address-family ipv4 vrf BLUE
  redistribute connected
 exit-address-family
 !
 address-family ipv4 vrf RED
  redistribute connected
 exit-address-family

Before we jump straight into testing on the CE routers, we should step through a few things. One of the requirements for VPNv4 is that all of the LSR addresses are reachable as a /32 in the IGP. This LSR address is advertised via LDP and is the highest loopback IP address on each router.

The PE node introducing a packet into the MPLS network will impose two labels. The bottom label will ultimately be used to determine VRF membership. This label will typically remain consistent as it traverses the MPLS network. The top label is for transit and is used for delivering the packet from one PE node to the other PE node over the P nodes in the network core. This label typically changes as part of the label swapping operation as it traverses the MPLS network. The top label is popped (removed) by the last P node. This removal is known as penultimate hop popping. In VPNv4, penultimate hop popping leaves the bottom label exposed so the PE node can determine VRF membership.

The VPNv4 configuration does a couple of things for the network operation. First, it advertises the BGP next hop as the LSR address. This LSR address is used in the LDP process for identification. Next, it includes RD and RT values in the BGP advertisements. This allows BGP to create unique entries for overlapping addresses and provide a type of tagging for importing and exporting routes into a VRF.

So let’s do a step by step configuration validation from the perspective of the PE nodes.

Validation at PE1

PE1#show bgp vpnv4 unicast all
BGP table version is 45, local router ID is 10.10.10.10
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,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:200 (default for vrf RED)
 *>   10.1.1.0/24      0.0.0.0                  0         32768 ?
 *>i  20.2.2.0/24      20.20.20.20              0    100      0 ?
Route Distinguisher: 110:210 (default for vrf BLUE)
 *>   10.3.3.0/24      0.0.0.0                  0         32768 ?
 *>i  20.4.4.0/24      20.20.20.20              0    100      0 ?
!
//it is also possible to see the RT values (used for import and export into local vrf)
PE1#show bgp vpnv4  unicast vrf BLUE 20.4.4.0/24
BGP routing table entry for 110:210:20.4.4.0/24, version 43
Paths: (1 available, best #1, table BLUE)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    20.20.20.20 (metric 4) (via default) from 20.20.20.20 (20.20.20.20)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1100:2100
      mpls labels in/out nolabel/2008
      rx pathid: 0, tx pathid: 0x0

//validating next hop reachability in the global vrf
PE1#ping 20.20.20.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/67/229 ms

Validation at PE2

PE2#show bgp vpnv4 unicast all
BGP table version is 24, local router ID is 20.20.20.20
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,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:200 (default for vrf RED)
 *>i  10.1.1.0/24      10.10.10.10              0    100      0 ?
 *>   20.2.2.0/24      0.0.0.0                  0         32768 ?
Route Distinguisher: 110:210 (default for vrf BLUE)
 *>i  10.3.3.0/24      10.10.10.10              0    100      0 ?
 *>   20.4.4.0/24      0.0.0.0                  0         32768 ?

//validating next hop reachability in the global vrf
PE2#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/22/46 ms

At this point, we should have the desired configuration. The objective was for CE_Site_1 (10.1.1.2) to be reachable only from CE_Site_2 (20.2.2.2). Likewise, CE_Site_3 (10.3.3.2) should only be accessible from CE_Site_4 (20.4.4.2). Let’s test the VRF functionality from the PE nodes first. Then confirm directly from the CE nodes.

Testing from PE1

//Testing the RED VRF to CE_Site_1
PE1#ping vrf RED 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/21/42 ms

//Testing the RED VRF to BLUE VRF on PE2
PE1#ping vrf RED 20.2.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/5/8 ms

//Testing the BLUE VRF to CE_Site_3
PE1#ping vrf BLUE 10.3.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/8/16 ms

//Testing the BLUE VRF to BLUE VRF on PE2
PE1#ping vrf BLUE 20.4.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/9/18 ms

Testing from PE2

//Testing the RED VRF to CE_Site_2
PE2#ping vrf RED 20.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/14 ms

//Testing the RED VRF to BLUE VRF on PE1
PE2#ping vrf RED 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/33/49 ms

//Testing the BLUE VRF to CE_Site_4
PE2#ping vrf BLUE 20.4.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/7 ms

//Testing the BLUE VRF to BLUE VRF on PE1
PE2#ping vrf BLUE 10.3.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/6 ms

So far, everything looks good. From CE_Site_1 we should only be able to ping CE_Site_2.

Testing from CE_Site_1

CE_Site1#ping 20.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/50 ms
CE_Site1#ping 10.3.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
CE_Site1#ping 20.4.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

That is the desired behavior.

Testing from CE_Site_3

CE_Site3#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
CE_Site3#ping 20.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
CE_Site3#ping 20.4.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 31/46/67 ms

As we can see, the desired behavior has been achieved. The intent of this series is to provide an overview of the tools that are available in our networking toolbox. In the next article, we will do a packet walk through this topology and better understand how traffic traverses the network. This will help solidify the underlying concepts introduced here.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design and tagged . Bookmark the permalink.