Services · Topic 3 of 5
Layer 3 VPNs: Intra-AS, Extranet and Internet Access
Configure intra-AS MPLS L3VPN with VRFs, route distinguishers, route targets and VPNv4, then share services with an extranet and Internet access.
- 7 min
- Includes a diagram
- A VRF is a separate routing table, and the P routers have no VRFs.
- The RD makes prefixes unique. The RT controls import and export.
- PEs exchange customer routes in the VPNv4 address family.
What it is
An MPLS Layer 3 VPN gives each customer a private routed network over the provider's shared core.
Each customer has a virtual routing table on the PE, called a VRF. The provider routes customer traffic, and it keeps different customers apart, even when they use the same private addresses. The core P routers know nothing about customer routes.
How it works
Customer routes are kept apart by VRFs, made unique by route distinguishers, and shared by route targets.
The building blocks
| Item | Purpose |
|---|---|
| VRF | A separate routing table on the PE for one customer |
| Route distinguisher (RD) | A 64 bit value added to the prefix, so overlapping customer prefixes stay unique in BGP |
| Route target (RT) | An extended community that says which VRFs import or export the route |
| MP-BGP VPNv4 | The BGP address family that carries RD plus prefix between PEs |
The RD makes a VPNv4 prefix unique, and it does not control who receives the route. The route targets do that. A VRF exports routes with its export RT, and it imports any route that carries one of its import RTs.
Forwarding
A packet crossing the core has two labels. The outer label is the transport label, built by LDP or segment routing, and it gets the packet to the egress PE. The inner label is the VPN label, advertised by the egress PE in BGP, and it picks the correct VRF.
The P routers swap only the outer label. They never see the customer address.
Configuration on IOS XR
RP/0/RP0/CPU0:PE1(config)# vrf RED
RP/0/RP0/CPU0:PE1(config-vrf)# address-family ipv4 unicast
RP/0/RP0/CPU0:PE1(config-vrf-af)# import route-target
RP/0/RP0/CPU0:PE1(config-vrf-af-import-rt)# 65000:100
RP/0/RP0/CPU0:PE1(config-vrf-af-import-rt)# exit
RP/0/RP0/CPU0:PE1(config-vrf-af)# export route-target
RP/0/RP0/CPU0:PE1(config-vrf-af-export-rt)# 65000:100
RP/0/RP0/CPU0:PE1(config-vrf-af-export-rt)# exit
RP/0/RP0/CPU0:PE1(config)# interface GigabitEthernet0/0/0/1
RP/0/RP0/CPU0:PE1(config-if)# vrf RED
RP/0/RP0/CPU0:PE1(config-if)# ipv4 address 10.1.1.1 255.255.255.252
RP/0/RP0/CPU0:PE1(config)# router bgp 65000
RP/0/RP0/CPU0:PE1(config-bgp)# address-family vpnv4 unicast
RP/0/RP0/CPU0:PE1(config-bgp-af)# exit
RP/0/RP0/CPU0:PE1(config-bgp)# neighbor 2.2.2.2
RP/0/RP0/CPU0:PE1(config-bgp-nbr)# remote-as 65000
RP/0/RP0/CPU0:PE1(config-bgp-nbr)# update-source Loopback0
RP/0/RP0/CPU0:PE1(config-bgp-nbr)# address-family vpnv4 unicast
RP/0/RP0/CPU0:PE1(config-bgp-nbr-af)# exit
RP/0/RP0/CPU0:PE1(config-bgp-nbr)# exit
RP/0/RP0/CPU0:PE1(config-bgp)# vrf RED
RP/0/RP0/CPU0:PE1(config-bgp-vrf)# rd 65000:100
RP/0/RP0/CPU0:PE1(config-bgp-vrf)# address-family ipv4 unicast
RP/0/RP0/CPU0:PE1(config-bgp-vrf-af)# redistribute connected
The CE neighbour is then added under the VRF, with a route policy for XR eBGP. On IOS XE the VRF is defined and then attached to the interface:
PE1(config)# vrf definition RED
PE1(config-vrf)# rd 65000:100
PE1(config-vrf)# address-family ipv4
PE1(config-vrf-af)# route-target both 65000:100
PE1(config)# interface GigabitEthernet0/0/1
PE1(config-if)# vrf forwarding RED
PE1(config-if)# ip address 10.1.1.1 255.255.255.252
PE1(config)# router bgp 65000
PE1(config-router)# neighbor 2.2.2.2 remote-as 65000
PE1(config-router)# neighbor 2.2.2.2 update-source Loopback0
PE1(config-router)# address-family vpnv4
PE1(config-router-af)# neighbor 2.2.2.2 activate
PE1(config-router-af)# neighbor 2.2.2.2 send-community extended
PE1(config-router)# address-family ipv4 vrf RED
PE1(config-router-af)# neighbor 10.1.1.2 remote-as 65001
PE1(config-router-af)# neighbor 10.1.1.2 activate
RP/0/RP0/CPU0:PE1# show bgp vpnv4 unicast summary
RP/0/RP0/CPU0:PE1# show route vrf RED
PE1# show ip route vrf RED
If two customer sites use the same AS number, the AS path loop check drops the route. The PE can use as-override, or the CE can accept it with allowas-in.
Shared services: extranet
An extranet lets VRFs of different customers, or of one customer, share some routes. It is built with route targets only.
Create a shared services VRF with its own RT. Customer VRFs import that RT to reach the servers, and the shared VRF imports each customer RT so the servers can reply. The customers do not import each other's RTs, so they cannot reach each other.
Shared services: Internet access
A customer VRF has no route to the Internet unless you give it one. There are a few ways to do it.
- Default route to the global table: a static default route in the VRF that points to a next hop in the global routing table. On IOS XE this uses the
globalkeyword, for exampleip route vrf RED 0.0.0.0 0.0.0.0 203.0.113.1 global. - Internet VRF: a VRF that holds the Internet routes, with route targets that customer VRFs import.
- Route leaking between a VRF and the global table: done with import and export policy, and the method depends on the platform and release.
The return path also needs a route from the global table into the VRF. Many providers use NAT at the Internet edge, so that private customer addresses are translated.
What to remember for the exam
Seven facts cover most questions on this topic.
- A VRF is a separate routing table, and the P routers have no VRFs.
- The RD makes prefixes unique. The RT controls import and export.
- PEs exchange customer routes in the VPNv4 address family.
- Packets carry a transport label on the outside and a VPN label on the inside.
- XR eBGP to a CE needs a route policy, and XE needs
activateunder the VRF address family. - An extranet uses a shared VRF and route target imports and exports.
- Internet access needs a route from the VRF to the global table, and a return route.
If a route is in the VPNv4 table but not in the VRF, check that the import route target matches the export on the far PE.
Common mistakes
These four mistakes appear often.
Thinking the RD controls route sharing. Only route targets decide which VRFs import a route.
Losing extended communities on the VPNv4 session. IOS XE normally adds send-community extended when the VPNv4 neighbour is activated, but if it is removed or missing, the route targets are not sent and the routes are not imported.
Using the same AS number at both sites. The route is dropped by loop prevention unless you use as-override or allowas-in.
Importing customer RTs into each other's VRFs for shared services. That joins the customers instead of just giving them the shared servers.
Leaking Internet routes into a customer VRF can expose customer addresses. Plan filtering and NAT before you do it.
Check yourself
Work through these three questions.
What is the job of the route distinguisher?
It makes overlapping customer prefixes unique in BGP, but it does not decide who imports them.
How do customers reach a shared server VRF without reaching each other?
Each customer VRF imports the shared RT, and only the shared VRF imports the customer RTs.
Which two labels does a VPN packet carry in the core?
The outer transport label and the inner VPN label.
Topic 3 of 5 in Services
Test yourself on Services
The full Cisco CCNP 350-501 SPCOR question bank has 738 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.