VPN Technologies

• Explain the MPLS VPN architecture, RDs, RTs, and virtual routing tables
• Describe end-to-end routing update flow
• Describe VPN label propagation between PE routers and the MPLS
VPN end-to-end forwarding mechanism
VPN services can be offered based on two major models:
• Overlay model, in which the service provider provides virtual point-to-
point links between customer sites
• Peer-to-peer model, in which the service provider participates in the
customer routing
 VPNs
Overlay VPN Peer-to-Peer VPN

Layer 2 VPN Layer 3 VPN

ACLs
GRE (Shared router)
X.25
DMVPN Split routing
(dedicated router)
Frame Relay IPsec
GET VPN
L2TPv3
ATM MPLS VPN
SSL VPN
• Overlay VPN:
- Well-known and easy to implement
- Service provider does not participate in customer routing.
- Customer network and service provider network are
well isolated.
• Peer-to-peer VPN:
- Guarantees optimum routing between customer sites
- Easier to provision an additional VPN
- Only sites provisioned, not links between them
 Provider Edge (PE) Devices
Customer Site A Customer Site C

Provider (P)
Core Devices
CE Router CE Router

PE Router PE Router

Customer Site B Customer Site D

P Router

CE Router CE Router

• CE routers route traffic to PE routers.

• Each customer has its own isolated routing table instance on PE router.
• P routers do not have customer route information.
• Label switching is enabled in service provider core.
An MPLS VPN combines the best features of an overlay VPN
and a peer-to-peer VPN:
• PE routers participate in customer routing, guaranteeing optimum
routing between sites and easy provisioning.
• PE routers carry a separate set of routes for each customer (similar to
the dedicated PE router approach).
• Customers can use overlapping addresses.

Access
Aggregation
IP Edge
Core

MPLS
MPLS
VPN
 Customer A Customer A
Site 1 Site 2
CE1-A CE2-A
CE Router CE Router

P1
PE1 PE2
MPLS VPN Service
Provider Edge Provider Network Provider Edge
Router Router
P2
Customer B Customer B
Site 1 Site 2

CE1-B CE2-B
CE Router CE Router
Customer A Customer A Customer A Customer A
Site 1 IPv4 Routes IPv4 Routes Site 2
Global Routing Global Routing
Table Table

CE
CE
Virtual Routing Virtual Routing
Table (Customer A) Table (Customer A)
P
Physical or Physical or
Logical Logical
Virtual Routing Table Virtual Routing Table
Interface (Customer B) (Customer B)
Interface
P
Customer B Provider Edge Router Provider Edge Router Customer B
Site 1 (PE) (PE) Site 2

Customer B Customer B
CE IPv4 Routes IPv4 Routes CE

A PE router in an MPLS VPN uses virtual routing tables to implement

the functionality of customer-dedicated PE routers.
Customer A Site 1
Global Routing
Table
CE1-A Routes

CE1-A Virtual Routing Table

(Customer A)
Static, RIPv2, OSPF,
EIGRP, BGP from CE1-A
AND CE1-B Virtual Routing Table
(Customer B)

CE1-B
PE Router
CE1-B Routes

Customer B Site 1 Physical or

Logical
Interfaces
• Run a single routing protocol that will carry all customer routes between
PE routers. Use MPLS labels to exchange packets between PE routers.
• P routers do not carry customer routes; the solution is scalable.
• The number of customer routes can be very large. BGP4 is the only
routing protocol that can scale to a very large number of routes.
• BGP is used to exchange customer routes directly between PE routers.
• Extend the customer addresses to make them unique.
• In the MPLS VPN backbone, the PE router needs to implement
processes that enable overlapping address spaces in connected
customer networks.
• The 64-bit route distinguisher is prepended to an IPv4 address to make
it globally unique.
• The resulting address is a VPNv4 address.
• VPNv4 addresses are exchanged between PE routers via BGP4.

Route Distinguisher IPv4 Address VPNv4

(8 Bytes) (4 Bytes) Address

AS Number VPN Identifier

RD Formats
IP Address VPN Identifier
 96-bit VPNv4 Prefix
RD: 1:100:172.16.10.0/24
Customer A RD: 1:101:172.16.10.0/24 Customer A
Site 1 VPNv4 Prefix Site 2
Global Global
Routing Table Routing Table
CE1-A
CE2-A
IPv4 Prefix VRF for VRF for
172.16.10.0/24 Customer A P Customer A
RD = 1:100 RD = 1:100

IPv4 Prefix
172.16.10.0/24 VRF for P VRF for
Customer B Customer B
CE1-B CE2-B
RD = 1:101 RD = 1:101

PE Router PE Router
MPLS VPN
Customer B Service Customer B
Site 1 Provider Site 2
AS1
 Customer A Customer A
Site 1 CE2-A Site 2
CE1-A
CE Router
CE Router
Step 4: The receiving PE routers strip the RD from
Step 2: The PE router prepends a 64-bit the VPNv4 prefix, resulting in an IPv4 prefix. RD is
RD to the IPv4 routing update, resulting used to match the proper VRF routing table.
in a globally unique 96-bit VPNv4 prefix.
Step 3: The VPNv4 prefix is propagated via
an MP-IBGP session
P1 to other PE routers.
PE1 PE2
Provider Edge Provider Edge
Router Router
P2
Customer B Step 5: The IPv4 prefix is forwarded to other Customer B
Site 1 CE routers within an IPv4 routing update. Site 2

CE1-B CE2-B
CE Router CE Router
Step 1: The CE router sends an IPv4
routing update to the PE router.
• The RD cannot identify participation in more than one VPN.
• RTs were introduced in the MPLS VPN architecture to support complex
VPN topologies.
• RTs are additional attributes attached to VPNv4 BGP routes to indicate
VPN membership.
• Extended BGP communities are used to encode these attributes.
• Export RTs:
- Identifying VPN membership
- Appended to the customer route when it is converted into a VPNv4 route
• Import RTs:
- Associated with each virtual routing table
- Select routes to be inserted into the virtual routing table
 1:100:172.16.10.0/24
RT 1:100 NH 10.10.10.101 (PE1) VPN Label: V1
1:101:192.168.10.0/24
RT 1:101 NH 10.10.10.101 (PE1) VPN Label: V2

Customer A 3 Customer A
Site 1 Site 2
MP-BGP MP-BGP
4
VRF Customer A VRF Customer A
1 CE1-A RD = 1:100 RD = 1:100 CE2-A
Export RT = 1:100 Export RT = 1:100
IPv4 Prefix IPv4 Prefix
172.16.10.0/24 Import RT = 1:100 Import RT = 1:100 172.16.10.0/24
P1 5
2
VRF Customer B VRF Customer B
IPv4 Prefix RD = 1:101 IPv4 Prefix
RD = 1:101
192.168.10.0/24 192.168.10.0/24
Export RT = 1:101 P2 Export RT = 1:101
1 CE1-B Import RT = 1:101 Import RT = 1:101 CE2-B

PE Router (PE1) PE Router (PE2)

MPLS VPN
Customer B Service Customer B
Site 1 Provider Site 2
MPLS VPN Routing
• CE routers must run standard IP routing software.
• PE routers must support MPLS VPN services and IP routing.
• P routers must not participate in customer VPN routing.
 • Exchange VPN routes with CE routers via per-VPN routing protocols
• Exchange core routes with P routers and PE routers via core IGP
• Exchange VPNv4 routes with other PE routers via MP-IBGP sessions

MPLS VPN Backbone

MP BGP

CE Router PE Router P Router PE Router CE Router

VPN Routing VPN Routing

Core IGP Core IGP

CE Router CE Router
• P routers do not participate in MPLS VPN
• The CE routers run standard IP routing software and routing and do not carry VPN routes.
exchange routing updates with the PE router.
• P routers run backbone IGP with the PE routers
• The PE router appears as another router in the C-network. and exchange information about global
subnetworks (core links and loopbacks).
• The P routers are hidden from the customer.
PE routers contain a number of routing tables:
• The global routing table contains core routes (filled with core IGP).
• The VRF tables contain routes for sites of identical routing requirements
from local (IPv4 VPN) and remote (VPNv4 via MP-BGP) CE routers.

MPLS VPN Backbone

VPN Routing MP BGP VPN Routing

CE Router PE Router P Router PE Router CE Router

Core IGP Core IGP

CE Router CE Router
 PE routers receive IPv4 routing
updates from CE routers and install
them in the appropriate VRF table.

MPLS VPN Backbone

CE Router CE Router

IPv4 Update MP-BGP Update

PE Router P Router PE Router

PE routers export VPN routes from VRF

CE Router tables into MP-BGP and propagate them as CE Router
VPNv4 routes to other PE routers. The
export RT attribute is matched.
An MP-BGP update contains these elements:
• VPNv4 address
• Extended communities (for example, route targets)
• Route from customer VRF is distributed
• Label used for VPN packet forwarding
to CE sites.
• Any other BGP attribute (for example, AS path, local
preference, MED, standard community)

MPLS VPN Backbone

CE Router CE Router

IPv4 Update MP-BGP Update IPv4 Update

PE Router P Router PE Router

CE Router • The receiving PE router imports the incoming CE Router

VPNv4 routes into the appropriate VRF based
on route targets attached to the routes. Import
route target attribute is matched.
Approach 1: The PE routers will label the VPN packets with an LDP label
for the egress PE router, and forward the labeled packets across the MPLS
backbone.
Results:
• The P routers perform the label switching, and the packet reaches the egress
PE router.
• Because the egress PE router does not know which VRF to use for packet
switching, the packet is dropped.

MPLS VPN Backbone

CE Router IP L1 IP L2 IP L3 CE Router

IP Ingress PE P Router P Router

?
Egress PE
Router Router

CE Router CE Router
Approach 2: The PE routers will label the VPN packets with a label stack,
using the LDP label for the egress PE router as the top label, and the VPN
label assigned by the egress PE router as the second label in the stack.
Results:
• The P routers perform label switching using the top label, and the packet
reaches the egress PE router. The top label is removed.
• The egress PE router performs a lookup on the VPN label and forwards the
packet toward the CE router.

MPLS VPN Backbone

CE Router IP V L1 IP V L2 IP V L3 CE Router

Ingress PE P Router P Router Egress PE

IP IP
Router Router

CE Router CE Router
• PHP on the LDP label can be performed on the last P router.
• The egress PE router performs label lookup only on the
VPN label, resulting in faster and simpler label lookup.
• IP lookup is performed only once—in the ingress PE router.

MPLS VPN Backbone

CE Router IP V L1 IP V L2 IP V CE Router

Ingress PE P Router P Router Egress PE

IP
Router Router

CE Router CE Router
Question: How will the ingress PE router get the second label in the label
stack from the egress PE router?
Answer: Labels are propagated in MP-BGP VPNv4 routing updates.
Step 3: A label stack is Step 1: A VPN label is assigned
built in the VRF table. to every VPN route.

MPLS VPN Backbone

CE Router 38 26 38 CE Router

LSP Forwarding

Ingress PE P Router P Router Egress PE

Router Router

CE Router CE Router

Step 2: The VPN label is advertised to all

other PE routers (participating in the
VPN) in an MP-BGP update.
• The VPN label must be assigned by the BGP next hop.
• The BGP next hop should not be changed in the MP-IBGP update
propagation.
• The PE router must be the BGP next hop.
- Use the next-hop-self command on the PE router.
• The label must be reoriginated if the next hop is changed.
- A new label is assigned every time that the MP-BGP update crosses the AS
boundary where the next hop is changed.
• The VPN label of the BGP route is understood by only the egress PE router.
• An end-to-end LSP tunnel is required between the ingress and egress PE routers.
• BGP next-hop addresses must be IGP routes.
- LDP labels will be assigned to addresses in the global routing table.
- LDP labels are not assigned to BGP routes (BGP routes receive VPN labels).
• BGP next hops announced in IGP must not be summarized in the core network.
- Summarization breaks the LSP tunnel.
P router is faced with a VPN label
that it does not understand.
P router performs PHP. MPLS VPN Backbone

?
CE Router IP V L1 3 IP V CE Router
4

Ingress PE P Router P Router Egress PE

IP 2 IP
Router 1 Router

PHP is requested through LDP. P router summarizes PE loopback.

CE Router 5 CE Router
Aggregation point
• The most scalable method of exchanging customer routes across a
provider network is the use of an MP-BGP between PE routers.
- RDs transform non-unique 32-bit addresses into 96-bit unique addresses.
- RTs are used to identify VPN membership in overlapping topologies.
• In MPLS VPNs:
- CE routers run standard routing protocols to the PE routers.
- PE routers provide the VPN routing and services via MP-BGP.
- P routers do not participate in VPN routing, and only provide core IGP
backbone routing to the PE routers.
• PE routers forward packets across the MPLS VPN backbone using label
stacking.
MPLS Layer 3 VPNs
• Customers connect to service provider via IP
• Service provider uses MPLS to forward packets between edge routers
• Service provider enables any-to-any connectivity between sites
belonging to the same VPN
• Service provider uses virtual routers to isolate customer routing
information
• Customers can use any addressing inside their VPN

IP IP
Site 1 Site 3
IP
+
MPLS

Site 2 IP IP Site 4

VPNA
• A VRF is the routing and forwarding instance for a set of sites with
identical connectivity requirements.
• Data structures associated with a VRF are as follows:
- IP routing table
- Cisco Express Forwarding table
- Set of rules and routing protocol parameters (routing protocol contexts)
- List of interfaces that use the VRF
• Other information associated with a VRF is as follows:
- Route distinguisher
- Set of import and export route targets
 10.1.1.0/24 • There are two backbones with
overlapping addresses.
RIP
VPN A
CE-A MPLS VPN
RIP Backbone
PE Router
VPN B CE-B Address Conflict

10.1.1.0/24 • RIP is running in both VPNs.

• RIP in VPN A has to be different from

RIP in VPN B.
• Cisco IOS Software supports only
one RIP process per router.
Routing context = routing protocol run in one VRF
• Supported by VPN-aware routing protocols: External BGP (EBGP),
EIGRP, OSPF, RIPv2, IS-IS, static routes
• Implemented as several instances of a single routing process
(EIGRP, EBGP, RIPv2, IS-IS) or as several routing processes (OSPF)
• Independent per-instance router variables for each instance
• Contains routes that should be available to a particular set of sites
• Analogous to standard Cisco IOS Software routing table; supports same
set of mechanisms
• VPN interfaces (physical interface, subinterfaces, logical interfaces)
assigned to VRFs:
- Many interfaces per VRF
- Each interface assignable to only one VRF
 PE Router
VRF-A Routing Table BGP Routing
Process

Backbone
VRF-B Routing Table Multiprotocol
BGP

Instance for VRF-A

CE-BGP-A
Instance for VRF-B

CE-BGP-B

• Two VPNs are attached to the same PE router.

• Each VPN is represented by a VRF.
 PE Router
VRF-A Routing Table BGP Routing
Process

Backbone
VRF-B Routing Table Multiprotocol
BGP

Instance for VRF-A

CE-BGP-A
Instance for VRF-B

CE-BGP-B

• BGP-speaking CE routers announce their prefixes to the PE router via BGP.

• The instance of the BGP process associated with the VRF of the PE-CE interface collects
the routes and inserts them into the VRF routing table.
 PE Router
VRF-A Routing Table BGP Routing
Process

Backbone
VRF-B Routing Table Multiprotocol
BGP

Instance for VRF-A

CE-BGP-A
Instance for VRF-B

CE-BGP-B

• The route distinguishers are prepended during the route export to the BGP routes from the
VRF instance of the BGP process to convert them into VPNv4 prefixes. Route targets are
attached to these prefixes.
• VPNv4 prefixes are propagated to other PE routers.
 PE Router
VRF-A Routing Table BGP Routing
Process

Backbone
VRF-B Routing Table Multiprotocol
BGP

Instance for VRF-A

CE-BGP-A
Instance for VRF-B

CE-BGP-B

• VPNv4 prefixes are received from other PE routers.

• The VPNv4 prefixes are inserted into the proper VRF routing tables based
on their route targets and the import route targets configured in VRFs.
• The route distinguisher is removed during this process.
 PE Router
VRF-A Routing Table BGP Routing
Process

Backbone
VRF-B Routing Table Multiprotocol
BGP

Instance for VRF-A

CE-BGP-A
Instance for VRF-B

CE-BGP-B

• Routes are received from backbone MP-BGP and imported into a VRF.
• IPv4 routes are forwarded to EBGP CE neighbors attached to
that VRF.
 PE Router
VRF-A Routing Table BGP Routing
RD: 1:100 Imp. RT: 1:100 Process
172.16.10.0/24
Backbone
VRF-B Routing Table Multiprotocol
BGP

1:100 172.16.10.0/24
172.16.10.0/24 RT: 1:100
Instance for VRF-A
172.16.10.0/24
CE-BGP-A
Instance for VRF-B

CE-BGP-B
 PE Router
RIP Routing Process
VRF-A Routing Table BGP Routing
Instance for VRF-A Process

CE-RIP-A Backbone
Instance for VRF-B VRF-B Routing Table Multiprotocol
BGP
CE-RIP-B

Instance for VRF-A

Instance for VRF-B

• RIP-speaking CE routers announce their prefixes to the PE router via RIP.

• The instance of the RIP process associated with the VRF of the PE-CE interface
collects the routes and inserts them into the VRF routing table.
 PE Router
RIP Routing Process
VRF-A Routing Table BGP Routing
Instance for VRF-A Process

CE-RIP-A Backbone
Instance for VRF-B VRF-B Routing Table Multiprotocol
BGP
CE-RIP-B

Instance for VRF-A

Instance for VRF-B

• The RIP routes entered in the VRF routing table are redistributed into BGP
for further propagation into the MPLS VPN backbone.
• Redistribution between RIP and BGP has to be configured for proper
MPLS VPN operation.
 PE Router
RIP Routing Process
VRF-A Routing Table BGP Routing
Instance for VRF-A Process

CE-RIP-A Backbone
Instance for VRF-B VRF-B Routing Table Multiprotocol
BGP
CE-RIP-B

Instance for VRF-A

Instance for VRF-B

• The RIP routes entered in the VRF routing table are redistributed into BGP
for further propagation into the MPLS VPN backbone.
• Redistribution between RIP and BGP has to be configured for proper
MPLS VPN operation.
 PE Router
RIP Routing Process
VRF-A Routing Table BGP Routing
Instance for VRF-A Process

CE-RIP-A Backbone
Instance for VRF-B VRF-B Routing Table Multiprotocol
BGP
CE-RIP-B

Instance for VRF-A

Instance for VRF-B

• Routes redistributed from BGP into a VRF instance of RIP are sent to RIP-speaking CE
routers.
 PE Router
RIP Routing Process
172.16.10.0/24 VRF-A Routing Table BGP Routing
Instance for VRF-A RD: 1:100 Imp. RT: 1:100 Process
172.16.10.0/24 172.16.10.0/24
CE-RIP-A Backbone
Instance for VRF-B VRF-B Routing Table Multiprotocol
BGP
CE-RIP-B
1:100 172.16.10.0/24
RT: 1:100
Instance for VRF-A
172.16.10.0/24

Instance for VRF-B

Create a VRF table. Router(config)# ip vrf vrf-name

Assign an RD to the VRF. Router(config-vrf)# rd route-distinguisher

Router(config-vrf)# route-target export RT

Specify export and import route
targets. Router(config-vrf)# route-target import RT

Configure a VPN ID (optional). Router(config-vrf)# vpn id oui:vpn-index

Assign interfaces to VRFs. Router(config-if)# ip vrf forwarding vrf-name

 Router(config)#
Cisco IOS and ip vrf vrf-name
IOS XE

• This command creates a new VRF or enters configuration of an

existing VRF.
• VRF names are case-sensitive.
• VRF names have only local significance.
 • This command assigns a route distinguisher to a VRF.
• A VRF is not operational unless you configure an RD.
• You can use the ASN:nn or A.B.C.D:nn format for RD.
• Each VRF in a PE router must have a unique RD.

Cisco IOS and IOS XE configuration

RD is configured under VRF configuration area

Router(config)#ip vrf vrf-name

Router(config-vrf)#rd route-distinguisher
Router(config-vrf)#
route-target export RT
• Specifies an RT to be attached to every route exported from this
VRF to Multiprotocol Border Gateway Protocol
• Allows specification of many export RTs—all to be attached to
every exported route
Router(config-vrf)#
route-target import RT
• Specifies an RT to be used as an import filter. (Only routes
matching the RT are imported into the VRF.)
• Allows specification of many import RTs. (Any route where at least
one RT attached to the route matches any import RT is imported
into the VRF.)
Because of implementation issues, in Cisco IOS Release 12.4(T) and earlier, at least
one export route target must also be an import route target of the same VRF.
• A VPN identifier (VPN ID) allows you to identify VPNs by an ID number.
- Not used to control distribution of routing information
- Not used to associate IP addresses with VPN IDs in routing updates
- Is stored on the VRF structure for a VPN
• Has the following elements:
- OUI (three-octet hexadecimal number)
- A VPN index (four-octet hexadecimal number identifying the VPN within the
company)
• Configure all PE routers that belong to the same VPN with the same
VPN ID.
• Make the VPN ID unique to the service provider network.
Router(config)#
ip vrf vrf-name
• Creates a VRF routing table and a Cisco Express Forwarding table
and enters VRF configuration mode

Router(config-vrf)#
vpn id oui:vpn-index
• Assigns the VPN ID to the VRF
 Router(config-if)#
Cisco IOS and IOS ip vrf forwarding vrf-name
XE

• This command associates an interface with the specified VRF.

• The existing IP address is removed from the interface when the interface
is put into the VRF—the IP address must be reconfigured.
• Cisco Express Forwarding switching must be enabled on the interface.
 MPLS VPN Backbone
CE-A1 AS 64500 CE-A2
IOS
and IOS XE

CE-B1 CE-B2

PE-X PE-Y

ip vrf Customer_A
rd 6111:11
route-target both 64500:11
!
ip vrf Customer_B
rd 6111:12
route-target both 64500:12
!
interface GigabitEthernet1/0/0
ip vrf forwarding Customer_A
ip address 10.1.0.1 255.255.255.252
!
interface GigabitEthernet1/1/0
ip vrf forwarding Customer_B
ip address 10.2.0.1 255.255.255.252
 MP-BGP

PE P P PE
MPLS Backbone

• Layer 3 MPLS VPNs are implemented using MP-BGP to exchange VPN

routing information.
• MP-BGP is BGP version 4 with extensions to support other protocols
and applications:
- Layer 3 MPLS VPNs
- Virtual Private LAN Services (VPLS) using BGP autodiscovery
 MP-BGP

BGP BGP

PE P P PE
MPLS Backbone

• MP-BGP must be configured on edge routers only.

• Support for MPLS VPNs must be enabled.
• Steps required:
- Add address family vpnv4
- Activate neighbor in address family vpnv4
• Optional configuration settings
• The BGP process in an MPLS VPN-enabled router performs three
separate tasks:
- Global BGP routes (Internet routing) are exchanged as in a traditional BGP
setup.
- VPNv4 prefixes are exchanged through MP-BGP.
- VPN routes are exchanged with CE routers through per-VRF External Border
Gateway Protocol sessions or through route redistribution.
• Address families (routing protocol contexts) are used to configure these
three tasks in the same BGP process.
 Router(config)#
router bgp as-number
• Selects global BGP routing process

Router(config-router)#
address-family vpnv4

• Selects configuration of VPNv4 prefix exchanges under MP-BGP

sessions

Router(config-router)#
address-family ipv4 vrf vrf-name

• Selects configuration of per-VRF PE-CE EBGP parameters

• MP-BGP neighbors are configured under the BGP routing process:
- These neighbors need to be activated for each global address family that they
support.
- Per-address-family parameters can be configured for these neighbors.
• VRF-specific BGP neighbors are configured under corresponding
address families.
 Router(config)#
router bgp as-number
neighbor ip-address remote-as as-number
neighbor ip-address update-source interface-type
interface-number

• All MP-BGP neighbors have to be configured under the global BGP

routing configuration.
• MP-IBGP sessions have to run between loopback interfaces.

Router(config-router)#
address-family vpnv4

• This command starts configuration of MP-BGP routing for VPNv4 route

exchange.
• The parameters that apply only to MP-BGP exchange of VPNv4 routes
between already configured IBGP neighbors are configured under this
address family.
Router(config-router-af)#
neighbor ip-address activate
• The BGP neighbor defined under BGP router configuration has to
be activated for VPNv4 route exchange.

Router(config-router-af)#
neighbor ip-address next-hop-self
• The next-hop-self keyword can be configured on the MP-IBGP
session for MPLS VPN configuration if EBGP is being run with a
CE neighbor.
Router(config-router-af)#
neighbor ip-address send-community [standard | extended
| both]

• This command with the extended option is enabled by default by Cisco

IOS Software after the BGP neighbor has been activated for VPNv4
route exchange.
• The command can be used to enable propagation of standard BGP
communities attached to VPNv4 prefixes.
• Usage guidelines:
– Extended BGP communities attached to VPNv4 prefixes have to be
exchanged between MP-BGP neighbors for proper MPLS VPN
operation.
– To propagate standard BGP communities between MP-BGP
neighbors, use the both option.
Router(config-router)#
no bgp default ipv4-unicast

• Cisco IOS and IOS XE Software only

• The exchange of IPv4 routes between BGP neighbors is enabled by
default. Every configured neighbor will also receive IPv4 routes.
• This command disables the default exchange of IPv4 routes. Neighbors
that need to receive IPv4 routes have to be activated for IPv4 route
exchange.
• Use this command when the same router carries Internet and VPNv4
routes and you do not want to propagate Internet routes to some PE
neighbors.
• Neighbor 172.16.32.14 receives only Internet routes.
• Neighbor 172.16.32.15 receives only VPNv4 routes.
• Neighbor 172.16.32.27 receives Internet and VPNv4 routes.

router bgp 65173

no bgp default ipv4-unicast
neighbor 172.16.32.14 remote-as 65173
neighbor 172.16.32.15 remote-as 65173
neighbor 172.16.32.27 remote-as 65173
! Activate IPv4 route exchange

address-family ipv4
neighbor 172.16.32.14 activate
neighbor 172.16.32.27 activate
! Step#2 – VPNv4 route exchange
address-family vpnv4
neighbor 172.16.32.15 activate
neighbor 172.16.32.27 activate
 MPLS VPN Backbone
CE-X1 CE-Y1
AS 64500

CE-X2 PE-Site-X PE-Site-Y CE-Y2

CE-X3 IOS XR IOS and IOS XE CE-Y3

interface loopback 0 interface loopback 0

ipv4 address 172.16.1.2 255.255.255.255 ip address 172.16.1.1 255.255.255.255
! !
router bgp 64500 router bgp 64500
address-family vpnv4 unicast neighbor 172.16.1.2 remote-as 64500
! neighbor 172.16.1.2 update-source loopback 0
neighbor 172.16.1.1 !
remote-as 64500 address-family vpnv4
update-source Loopback0 neighbor 172.16.1.2 activate
address-family vpnv4 unicast neighbor 172.16.1.2 next-hop-self
next-hop-self neighbor 172.16.1.2 send-community both
MPLS Layer 3 VPNs
• PE-CE routing protocols are configured for individual VRFs.
• Cisco IOS and IOS XE Software
- Per-VRF routing protocols can be configured in two ways:
• Per-VRF parameters are specified in routing contexts, which are selected
with the address-family command.
• A separate OSPF process is started for each VRF.
 Router(config)#
router bgp as-number
Cisco IOS address-family ipv4 vrf vrf-name
and IOS XE ... Non-BGP redistribution ...

• Select the per-VRF BGP context with the address-family command.

• Configure CE External Border Gateway Protocol neighbors in VRF contexts,
not in global BGP configuration.
• All non-BGP per-VRF routes have to be redistributed into a per-VRF BGP
context to be propagated by MP-BGP to other PE routers.
Router(config)#
ip route vrf vrf-name prefix mask [next-hop-address]
[interface interface-number]
• This command configures per-VRF static routes.
• The route is entered in the VRF table.
• You must specify a next-hop IP address if you are not using a
point-to-point interface.

Sample router configuration:

ip route vrf Customer_ABC 10.0.0.0 255.0.0.0 10.250.0.2

!
router bgp 65173
address-family ipv4 vrf Customer_ABC
redistribute static
 MPLS VPN Backbone
AS 64500
CE-A1 CE-A2
Cisco IOS and Cisco IOS
IOS XE XR

CE-B1 CE-B2

PE-X PE-Y

ip route vrf Customer_A 10.0.1.0 255.255.255.0 192.168.0.2

!
router bgp 64500
address-family ipv4 vrf Customer_A
redistribute static
no auto-summary
Cisco IOS and IOS XE
• Displays the whole VPNv4 table
show ip bgp vpnv4 all
• Displays only BGP parameters associated with the specified VRF
show ip bgp vpnv4 vrf vrf -name

• Displays only BGP parameters associated with the specified RD

show ip bgp vpnv4 rd rd
 Cisco IOS and IOS XE
• Displays per-VRF Cisco Express Forwarding table
show ip cef vrf vrf-name
• Displays details of an individual Cisco Express Forwarding entry,
including label stack
show ip cef vrf vrf-name
ip-prefix detail

• Displays labels allocated by an MPLS VPN for routes in the

specified VRF
show mpls forwarding vrf vrf-
name
• Performs PE-CE Telnet through specified VRF
telnet vrf vrf-name ip-address

• Performs ping based on VRF routing table

ping vrf vrf-name ip-address

• Checks MPLS LSP connectivity

ping mpls ipv4 destination-address

• Performs VRF-based traceroute

trace vrf vrf-name ip-address

• Discovers MPLS LSP routes

trace mpls ipv4 destination-address

• These commands are the same in Cisco IOS , IOS XE, and IOS XR
Software.
• Configure an OSPF PE-CE routing session
• Configure a BGP PE-CE routing session
• Describe how to troubleshoot MPLS VPNs
REFERENCE TOPIC

OSPF as the PE-CE Routing Protocol

 OSPF Area 0 (Backbone Area) • OSPF divides a network into areas,
all of them linked through the
backbone (Area 0).
• Areas could correspond to
Area Border Router Area Border Router
individual sites from an MPLS VPN
perspective.

Area 1 Area 2 Area 3

• From the customer perspective, an

MPLS VPN-based network has a
BGP backbone with IGP running at BGP Backbone
customer sites.
• Redistribution between IGP and
BGP is performed to propagate
PE Router PE Router
customer routes across the MPLS
VPN backbone.
CE Router
Site IGP Site IGP Site IGP
 2. An OSPF route is redistributed into BGP.

BGP Backbone 3. The MP-BGP route is propagated to

other PE routers.

4. The MP-BGP route is

redistributed into OSPF.
PE Router PE Router
5. The OSPF route is
propagated as an
external route into
other sites.

Area 1 Area 2 Area 3

1. A local subnetwork is announced to the PE router as
type 1 or type 2 LSA.
• The OSPF route type is not preserved when the OSPF route is
redistributed into BGP.
• All OSPF routes from a site are inserted as external (type 5 LSA) routes
into other sites.
• The result is that OSPF route summarization and stub areas are hard to
implement.
Conclusion: MPLS VPNs must extend the classic OSPF-BGP routing
model.
• OSPF Area 0 might extend into individual sites.
• The MPLS VPN backbone has to become a superbackbone for OSPF.
BGP Backbone

PE Router PE Router

Area 0 Area 2 Area 0 Area 3

• OSPF between sites will not use normal OSPF-BGP redistribution.
• OSPF continuity must be provided across the MPLS VPN backbone:
- Internal OSPF routes should remain internal OSPF routes.
- External routes should remain external routes.
- OSPF metrics should be preserved.
• CE routers run standard OSPF software.
 2. The PE router propagates the route into the
superbackbone. Route summarization can be
OSPF Superbackbone performed on the area boundary.

3. The route from the superbackbone

is inserted into other areas as an
interarea route.

ABR ABR
4. The interarea route
is propagated into
other areas.

Area 0 Area 2 Area 0 Area 3

1. A local subnetwork is announced to the PE

router as type 1 or type 2 LSA.

• Extended BGP communities are used to propagate OSPF route types across the
BGP backbone.
• OSPF cost is copied into the MED attribute.
 BGP
10.0.0.0/8
Backbone OSPF RT = 1:1:0
Internal OSPF routes MED = 768

• The OSPF route type is copied into the PE PE

10.0.0.0/8
extended BGP community on redistribution 10.0.0.0/8
LSA type 3
LSA Type 1
into BGP. OSPF cost 768
OSPF Cost 768

• The egress PE router performs interarea Area 1 Area 2

transformation. BGP
10.0.0.0/8
Backbone OSPF RT = 1:5:1
External OSPF routes MED = 768

• Routes are propagated in the same PE PE

way as internal OSPF routes across 10.0.0.0/8
10.0.0.0/8
LSA Type 5
LSA Type 5
the superbackbone. Non-OSPF E2 Metric 20
E2 Metric 20
Route Area 1 Area 2
• The external metric and route type
are preserved. BGP
10.0.0.0/8
Backbone MED = 3
Routes from other routing protocols
• Routes from the MP-BGP backbone that did not PE PE
10.0.0.0/8
originate in OSPF are still subject to standard 10.0.0.0/8 LSA Type 5
redistribution behavior when inserted into OSPF. Hop Count 3 E2 Metric 20

RIP Area 2
Follow these steps to configure OSPF as the PE-CE routing
protocol:
• Configure a per-VRF copy of OSPF.
• Configure redistribution of MP-BGP into OSPF.
• Configure redistribution of OSPF into MP-BGP.
router(config)#
router ospf process-id vrf vrf-name
... Standard OSPF parameters ...
• This command starts the per-VRF OSPF routing process.
router(config-router)#
redistribute bgp as-number subnets
• This command redistributes MP-BGP routes into OSPF. The
subnets keyword is mandatory for proper operation.
router(config)#
router bgp as-number
address-family ipv4 vrf vrf-name
redistribute ospf process-id [match [internal]
[external-1] [external-2]]
• OSPF-BGP route redistribution is configured with the redistribute
command under the proper address-family command.
 2. The OSPF route is received by a PE router,
redistributed into MP-BGP, and propagated
across the MPLS VPN backbone.
BGP Backbone
3. The route from the superbackbone
is inserted as the interarea route.

PE Router PE Router PE Router

5. The other PE router
would redistribute the
route back into BGP.

4. The OSPF route

is propagated
across the area.

Area 1 Area 2
1. The local subnetwork is announced to the PE router.
• A down bit has been introduced in the options field of the OSPF LSA header.
• PE routers set the down bit when redistributing routes from MP-BGP into OSPF.
• PE routers never redistribute OSPF routes with the down bit set into MP-BGP.
2. An OSPF route is received by a PE router, redistributed into
MP-BGP, and propagated across the MPLS VPN backbone.
BGP Backbone
3. The route from the superbackbone is inserted
as the interarea route.

PE Router PE Router PE Router

Down The route is never redistributed
back into the MP-BGP backbone.

4. The OSPF route is propagated

with the down bit set.

Area 1 Area 2
1. The local subnetwork is announced without the down bit.
2. The OSPF route is propagated with the down 3. Because of administrative distances,
bit set. an OSPF route is preferred over an
MP-IBGP route. Packet flow across
the network is not optimal.
BGP Backbone

PE Router PE Router PE Router

Down

Another OSPF or
Area 1 Area 2 Non-OSPF Site
1. The OSPF route is received by a PE router
and redistributed into MP-BGP and OSPF.
1. The OSPF route is propagated with the down 2. The OSPF route is ignored because
bit set. the down bit is set.

BGP Backbone

PE Router PE Router PE Router

Down

Another OSPF or
Area 1 Area 2 Non-OSPF Site
Packet flow across the network is optimal.
Troubleshooting MPLS VPNs
Perform basic MPLS troubleshooting:
• Is Cisco Express Forwarding enabled?
• Are labels for IGP routes generated and propagated?
• Are large labeled packets propagated across the MPLS backbone
(maximum transmission unit issues)?
2. Are routes redistributed into MP-BGP 5. Are VPNv4 routes inserted into
with the proper extended communities? VRFs on other PE routers?

P-Network 6. Are VPNv4 routes redistributed

from BGP into the PE-CE routing
protocol?
CE-Spoke P CE-Spoke
7. Are IPv4 routes propagated
to other CE routers?
PE-1 PE-2

3. Are VPNv4 routes propagated

CE-Spoke to other PE routers? CE-Spoke
1. Are CE routes received
by a PE router? 4. Is the BGP route selection
process working correctly?
 show route vrf
show bgp vpnv4 vrf vrf-name ip-prefix show bgp ip-prefix
debug bgp show vrf detail

P-Network

CE-Spoke P CE-Spoke
show route

PE-1 PE-2

show bgp vpnv4 unicast ip-prefix

CE-Spoke CE-Spoke
show route vrf vrf-name
show bgp vpnv4 unicast vrf vrf-name ip-prefix
 Is there an end-to-end LSP
tunnel between the PE routers?
Is the Cisco Express
Forwarding entry correct on
the ingress PE router?
P-Network

CE-Spoke P CE-Spoke
Is Cisco Express Forwarding
enabled on the ingress PE
router interface?
PE-1 PE-2

CE-Spoke CE-Spoke
Is the LFIB entry on the
egress PE router correct?
 show cef vrf vrf-name ip-prefix/length detail

P-Network

CE-Spoke P CE-Spoke
show cef interface

PE-1 PE-2

CE-Spoke CE-Spoke
• Check for summarization issues. The BGP next hop should be
reachable as a host route.
• Quick check—If TTL propagation is disabled, the trace from PE-2 to
PE-1 should contain only one hop.
• If needed, check LFIB values hop by hop.
• Check for MTU issues on the path. MPLS VPN requires a larger label
header than pure MPLS.

P-Network

CE-Spoke P CE-Spoke

PE-1 PE-2

CE-Spoke CE-Spoke
 show cef vrf vrf-name ip-prefix/length detail
show mpls forwarding vrf vrf-name value detail

P-Network

CE-Spoke P CE-Spoke

PE-1 PE-2

CE-Spoke CE-Spoke
Cisco IOS and IOS XE
show ip ospf database Control Plane
show ip bgp
show ip eigrp topology Routing Protocol

show ip route IP Routing Table (RIB)

show mpls ldp bindings Label Exchange Protocol

(LFIB)

Data Plane
show ip cef
show ip cef vrf
IP Forwarding Table (FIB)

show mpls forwarding-table Label Forwarding Table

show mpls forwarding-table vrf (LFIB)