MPLS

Table of Contents
MPLS ................................................................................................................................................................... 4
Course Description ......................................................................................................................................... 4
Course Highlights ........................................................................................................................................... 4
Requirements .................................................................................................................................................. 4
Course Schedule ............................................................................................................................................. 4
Introduction to MPLS............................................................................................................................................ 4
Why do we need MPLS? ................................................................................................................................... 5
Tunnel between PE routers.......................................................................................................................... 6
What is MPLS? ................................................................................................................................................ 11
iBGP configuration ..................................................................................................................................... 11
MPLS Configuration.................................................................................................................................... 11
Verification ................................................................................................................................................. 12
Conclusion ..................................................................................................................................................... 16
MPLS Labels and Devices ............................................................................................................................... 17
MPLS Label Format .................................................................................................................................... 17
MPLS Devices and Operations ................................................................................................................... 18
Conclusion ..................................................................................................................................................... 20
MPLS LDP (Label Distribution Protocol) ............................................................................................................. 20
Configuration.................................................................................................................................................. 24
OSPF Configuration .................................................................................................................................... 24
LDP Configuration ...................................................................................................................................... 24
Verification ..................................................................................................................................................... 25
LDP Neighbor Adjacency ............................................................................................................................ 25
LDP Control Plane....................................................................................................................................... 26
LDP Data Plane ........................................................................................................................................... 28
Conclusion ...................................................................................................................................................... 29
MPLS LDP Label Filtering Example...................................................................................................................... 29
VRF Lite Configuration on Cisco IOS ................................................................................................................... 32
MPLS Layer 3 VPN Explained .............................................................................................................................. 38
VRF (Virtual Routing and Forwarding)............................................................................................................ 39
MP-BGP (Multi Protocol BGP) ........................................................................................................................ 40
RD (Route Distinguisher) ............................................................................................................................ 41
RT (Route Target) ....................................................................................................................................... 42
Transport and VPN Label ................................................................................................................................ 44
Conclusion ...................................................................................................................................................... 45
Page 1 of 177
MPLS Layer 3 VPN Configuration........................................................................................................................ 45
Configuration.................................................................................................................................................. 46
IGP and LDP ................................................................................................................................................ 46
VRF on the PE routers ................................................................................................................................ 48
IBGP Configuration on PE1 and PE2 ........................................................................................................... 49
EBGP on PE and CE ..................................................................................................................................... 51
Verification ..................................................................................................................................................... 53
Wireshark Captures ........................................................................................................................................ 56
Conclusion ...................................................................................................................................................... 57
MPLS Layer 3 VPN BGP Allow-AS-In ................................................................................................................... 60
Conclusion ...................................................................................................................................................... 69
MPLS Layer 3 VPN BGP AS Override ................................................................................................................... 69
Conclusion ...................................................................................................................................................... 78
MPLS Layer 3 VPN PE-CE RIP .............................................................................................................................. 78
Configuration.................................................................................................................................................. 78
IGP and LDP ................................................................................................................................................ 78
VRFs on the PE Routers .............................................................................................................................. 79
IBGP between PE1 and PE2 ........................................................................................................................ 80
RIP between PE and CE routers.................................................................................................................. 80
Verification ..................................................................................................................................................... 83
Conclusion ...................................................................................................................................................... 83
MPLS Layer 3 VPN PE-CE EIGRP .......................................................................................................................... 86
Configuration.................................................................................................................................................. 87
IGP and LDP ................................................................................................................................................ 87
EIGRP between PE and CE routers ............................................................................................................. 89
Verification ..................................................................................................................................................... 91
Conclusion ...................................................................................................................................................... 93
MPLS Layer 3 VPN PE-CE OSPF ........................................................................................................................... 96
Configuration.................................................................................................................................................. 97
IGP and LDP ................................................................................................................................................ 97
OSPF between PE and CE Routers .............................................................................................................. 99
Verification ................................................................................................................................................... 100
Page 2 of 177
Conclusion .................................................................................................................................................... 104
MPLS Layer 3 VPN PE-CE OSPF Sham Link ........................................................................................................ 107
Configuration................................................................................................................................................ 110
Backdoor Link ........................................................................................................................................... 110
OSPF Sham Link ........................................................................................................................................ 111
Verification ................................................................................................................................................... 112
Conclusion ................................................................................................................................................... 116
VRF Lite Route Leaking ................................................................................................................................ 116
Configuration.............................................................................................................................................. 117
Static Routes ............................................................................................................................................ 118
MP-BGP .................................................................................................................................................... 121
Conclusion ................................................................................................................................................... 124
MPLS VPN Extranet Route Leaking............................................................................................................ 124
Configuration.............................................................................................................................................. 126
Conclusion .................................................................................................................................................... 135
MPLS VPN VRF Export Map .............................................................................................................................. 136
Configuration................................................................................................................................................ 137
Empty Export Map ................................................................................................................................... 140
Export Map with Prefix-list....................................................................................................................... 140
Export Map Additive ................................................................................................................................ 141
Export Map as Filter ................................................................................................................................. 141
Conclusion .................................................................................................................................................... 146
MPLS VPN VRF Import Map .............................................................................................................................. 146
Configuration................................................................................................................................................ 148
Conclusion .................................................................................................................................................... 154
Any Transport Over MPLS (AToM) ............................................................................................................ 154
Configuration.............................................................................................................................................. 155
Verification ................................................................................................................................................. 156
IPv6 over MPLS 6PE/6VPE .......................................................................................................................... 159
Configuration.............................................................................................................................................. 159
6PE............................................................................................................................................................ 163
Verification ............................................................................................................................................... 164
6VPE ......................................................................................................................................................... 169
Verification ............................................................................................................................................... 171
Conclusion .................................................................................................................................................... 177
Page 3 of 177
MPLS
Course Description
MPLS (Multi Protocol Label Switching) is a mechanism that switches traffic based on labels instead of routing
traffic. It’s typically seen in service provider networks and can transport pretty much everything…IP, IPv6,
Ethernet, frame-relay, PPP. MPLS VPN is a popular technique to build VPNs for customers over the MPLS
provider network.
Course Highlights
In this course you will learn:
 Why we use MPLS.

 What MPLS is and how it works.
 What labels are and how they are used for forwarding.
 How to configure different MPLS VPN L3 PE-CE scenarios.
 How to tunnel protocols like Ethernet or frame-relay over the MPLS VPN network.
 And many other topics…
Requirements
 Good understanding of IGPs like RIP, OSPF and EIGRP.
 Good understanding of tunneling techniques like GRE.
 Good understanding of BGP.
Course Schedule
 Unit 1: Introduction
 Unit 2: LDP (Label Distribution Protocol)
 Unit 3: MPLS VPN
 Unit 4: MPLS L2 Encapsulation
 Unit 5: IPv6 MPLS
Introduction to MPLS
To understand MPLS there are two questions we need to answer:
 What is MPLS?
 Why do we need MPLS?
I’m going to start this lesson with an explanation of why we need it and how MPLS solves some of the issues of
other protocols, this will help you to understand why we use MPLS. In the second part of this lesson you will
learn what MPLS is and how it actually works.
Page 4 of 177
When you want to learn MPLS, you need to be very familiar with the following topics before you continue:
 IGPs (like OSPF and EIGRP)

 Tunneling (GRE)
 CEF (Cisco Express Forwarding)
 BGP (Border Gateway Protocol)
Having said that, let’s get started!
Why do we need MPLS?

Take a look at the following picture:
Above we have an example of an ISP with two customers called “A” and “B”. The ISP only offers Internet
connectivity and no other services. Each customer uses the ISP to have connectivity between their sites.
To accomplish our goal, the ISP is running eBGP between the CE (Customer Edge) and PE (Provider Edge) to
exchange prefixes. This means all internal (P) routers of the ISP have to run iBGP or they don’t know where to
forward their packets to.
A full internet routing table currently has > 500.000 prefixes and with 8 ISP routers running iBGP, we need 28
iBGP peerings. We can reduce this number by using route reflectors or a confederation. All routers have to do
lookups in the routing table for any possible destination.
Now here’s something to think about…when our goal is to have connectivity between two customer sites, why
should all internal P routers know about this? The only routers that need to know how to reach the customer
sites are the PE routers of the provider. Why not build a tunnel between the PE routers? Take a look at the
picture below:
Page 5 of 177
In the picture above I added two GRE tunnels:
 The two PE routers at the top will use a GRE tunnel for the customer A sites.
 The two PE routers at the bottom will use a GRE tunnel for the customer B sites.
With a solution like this, we can have a BGP free core! There’s only two places where we need BGP:
 eBGP between the PE and CE router.

 iBGP between two PE routers.
Let’s take a closer look at the solution I described above.
Tunnel between PE routers
Let’s take a look at the example above in action. I will use the following topology for this:
Page 6 of 177
The topology above is a smaller version of the topology I showed you before. This is the ISP with only one
customer. We’ll use a GRE tunnel between PE1 and PE2 so that we don’t need iBGP on the P router. Let me
walk you through the entire configuration…
OSPF Configuration
First we will configure OSPF on all ISP routes so that PE1 and PE2 are able to reach each other. I’ve added
some loopback interfaces on the ISP routers that will be advertised as well:
PE1(config)#router ospf 1
PE1(config-router)#network 192.168.23.0 0.0.0.255 area 0
P(config)#router ospf 1
P(config-router)#network 192.168.23.0 0.0.0.255 area 0
That takes care of all internal routing for the ISP.
eBGP Configuration
Let’s continue by configuring eBGP between the CE and PE routers. We will advertise a loopback on each CE
router:
CE1(config)#router bgp 10
CE1(config-router)#neighbor 192.168.12.2 remote-as 1234
CE1(config-router)#network 1.1.1.1 mask 255.255.255.255
PE1(config)#router bgp 1234
PE1(config-router)#neighbor 192.168.12.1 remote-as 10
That takes care of eBGP.
GRE Tunnel Configuration
Now we can configure the GRE tunnel between PE1 and PE2. I will use their loopback interfaces as the source
and destination. We will use the 192.168.24.0 /24 subnet on the tunnel interfaces:
PE1(config)#interface tunnel 0
PE1(config-if)#tunnel source 2.2.2.2
PE1(config-if)#tunnel destination 4.4.4.4
PE1(config-if)#ip address 192.168.24.2 255.255.255.0
PE2(config)#interface tunnel 0
PE2(config-if)#tunnel source 4.4.4.4
PE2(config-if)#tunnel destination 2.2.2.2
Page 7 of 177
Now we have a working GRE tunnel.
iBGP Configuration
With the GRE tunnel up and running, we can configure iBGP between the two PE routers:

PE1(config-router)#neighbor 192.168.24.4 next-hop-self
Our PE routers will establish an iBGP peering using the IP addresses on the GRE tunnel.
I also could have established iBGP between the loopback interfaces of PE1 and PE2 instead of the IP addresses of the
tunnel interfaces. The advantage is that BGP traffic between PE1 and PE2 wouldn’t be encapsulated by GRE. The
downside however is that you will need to configure a route-map that changes the next hop IP address of all prefixes
learned through BGP to the IP addresses of the tunnel interfaces.
Our configuration is now complete. Let’s find out if it works shall we?
Verification
I’ll do a trace from CE1 to CE2:
CE1#traceroute 5.5.5.5 source loopback 0

Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 0 msec 0 msec
2 192.168.24.4 0 msec 0 msec 4 msec
3 192.168.45.5 0 msec 0 msec *
Great, it’s working! The ISP has a BGP-free core. Here’s what an IP packet from CE1 to CE2 looks like to the
P router:
The outer IP header has source address 2.2.2.2 and destination address 4.4.4.4, the P router knows how to route
these since it learned these addresses through OSPF.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname CE1
!
Page 8 of 177
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
router bgp 10
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 remote-as 1234
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router bgp 20
network 5.5.5.5 mask 255.255.255.255
!
control-plane
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
ip address 192.168.24.2 255.255.255.0
tunnel source 2.2.2.2
Page 9 of 177
tunnel destination 4.4.4.4
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 1234
neighbor 192.168.24.4 next-hop-self
!
end
hostname PE2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface Tunnel0
ip address 192.168.24.4 255.255.255.0
tunnel source 4.4.4.4
tunnel destination 2.2.2.2
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 1234
!
end
Great! Now you might be thinking…so what? Where’s MPLS?
For now, keep in mind that tunneling is used to create a BGP free core. Hold this thought while you read the
next section of this lesson where we finally start talking about MPLS!
Page 10 of 177
What is MPLS?
In the previous example I used a GRE tunnel but I could have used any tunneling mechanism. Besides GRE,
there’s IP-in-IP, Q-in-Q and…
MPLS (Multi Protocol Label Switching).
What does multi protocol label switching mean?
 Multi protocol: besides IP you can tunnel pretty much anything…IP, IPv6, Ethernet, PPP, frame-relay, etc.
 Label switching: forwarding is done based on labels, not by looking up the destination in the routing table.
MPLS can do anything that any of the other tunneling protocols support and it can do a lot more than that.
Let’s start with something simple, let’s replace the GRE tunnel from the previous example with MPLS so I can
explain how MPLS uses labels.
First let’s get rid of the GRE tunnel and the BGP peering between PE1 and PE2:
PE1 & PE2

(config)#no interface tunnel 0
PE1(config-router)#no neighbor 192.168.24.4 remote-as 1234
PE2(config-router)#no neighbor 192.168.24.2 remote-as 1234
Now we can start with the MPLS configuration.
iBGP configuration
Once again I will configure iBGP between PE1 and PE2 but this time I will use their loopback interfaces. You
will see why in a minute:

PE1(config-router)#neighbor 4.4.4.4 update-source loopback 0
That takes care of iBGP.
MPLS Configuration
This is the exciting part, let’s enable MPLS. We’ll do this on all interfaces that connect PE1, PE2 and the P
router:
PE1(config)#interface GigabitEthernet 0/2

PE1(config-if)#mpls ip
Page 11 of 177
P(config)#interface GigabitEthernet 0/1
P(config-if)#mpls ip
P(config)#interface GigabitEthernet 0/2
That’s pretty simple…only one command to activate MPLS on our interfaces. In the next lesson I will explain
what exactly happens when you use this command, for now I want to focus on the labels.
Verification
Let’s try a quick ping between CE1 and CE2:
CE1#ping 5.5.5.5 source loopback 0

Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Great, it works. Why does it work? Keep in mind there is no iBGP on the P router:
P#show ip cef 5.5.5.5

0.0.0.0/0
no route
Normally this traffic should be dropped since this router has no idea how it can reach 5.5.5.5. However, since
we enabled MPLS we are now using labels for our forwarding decisions. Let me explain how that works.
Let’s start with PE1:
PE1#show ip route 5.5.5.5

Routing entry for 5.5.5.5/32
Known via "bgp 1234", distance 200, metric 0
Tag 5, type internal
Last update from 4.4.4.4 00:20:16 ago
Routing Descriptor Blocks:
* 4.4.4.4, from 4.4.4.4, 00:20:16 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 5
MPLS label: none
To reach 5.5.5.5, we have to use 4.4.4.4 as the next hop. Instead of checking the routing table, let’s take a look
at the MPLS forwarding table:
PE1#show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 17 4.4.4.4/32 0 Gi0/2 192.168.23.3
17 Pop Label 192.168.34.0/24 0 Gi0/2 192.168.23.3
18 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.23.3
Page 12 of 177
Above you can see the labels that this router uses to reach certain prefixes. In the next lesson we’ll discuss how
these labels are generated. To reach 4.4.4.4, this router will add label 17 to the IP packet and forwards it on
GigabitEthernet 0/2 (towards the P router). A quicker method to see what labels are used for different prefixes
is by checking the CEF table:
PE1#show ip cef 5.5.5.5

5.5.5.5/32
nexthop 192.168.23.3 GigabitEthernet0/2 label 17
Here’s a capture of the IP packet that PE1 sends to the P router:
You can see that the MPLS header has been added in between the Ethernet and IP header. This is why they call
MPLS a layer 2.5 protocol.
So what happens when the P router receives this IP packet? It’s using MPLS for forwarding decisions so let’s
take a look at its labels:
P#show mpls forwarding-table

16 Pop Label 2.2.2.2/32 152492 Gi0/1 192.168.23.2
17 Pop Label 4.4.4.4/32 153234 Gi0/2 192.168.34.4
When the P router receives something that is tagged with label 17, then it has to be forwarded to 4.4.4.4. It’s
outgoing label says “pop label” which means to remove the label.
PE2 will receive a regular IP packet (without label) with destination 5.5.5.5 and it will forward it using the
routing table towards CE2.
Page 13 of 177
When CE2 receives the packet, it will create an ICMP echo reply which will end up at PE2. Here’s what PE2
will do with it:

Tag 1, type internal
* 2.2.2.2, from 2.2.2.2, 00:31:34 ago
AS Hops 1
Route tag 1
MPLS label: none
PE2 knows that it has to use next hop 2.2.2.2 to reach 1.1.1.1. Let’s check what label we will use to reach
2.2.2.2:

16 16 2.2.2.2/32 0 Gi0/2 192.168.34.3
17 Pop Label 192.168.23.0/24 0 Gi0/2 192.168.34.3
18 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.34.3
PE2 will add label 16 to the IP packet and will forward it out the GigabitEthernet 0/2 interface towards the P
router. Looking at the CEF table is a quicker method to find the label for a destination prefix:
PE2#show ip cef 1.1.1.1

1.1.1.1/32
nexthop 192.168.34.3 GigabitEthernet0/2 label 16
The PE2 router will forward it to the P router. Let’s check what it will do with this packet:

16 Pop Label 2.2.2.2/32 154767 Gi0/1 192.168.23.2
17 Pop Label 4.4.4.4/32 155528 Gi0/2 192.168.34.4
Router P sees that anything with label 16 should be forwarded on the GigabitEthernet 0/1 interface. It will
remove the label and forwards it to PE1.
PE1 can then forward the IP packet (without label) using its routing table to CE1.
That’s how we use MPLS to tunnel traffic between PE routers, creating a BGP free core.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
Page 14 of 177
!
ip address 192.168.12.1 255.255.255.0
!
router bgp 10
network 1.1.1.1 mask 255.255.255.255
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router bgp 20
network 5.5.5.5 mask 255.255.255.255
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
mpls ip
Page 15 of 177
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 1234
neighbor 4.4.4.4 update-source Loopback0
!
end
hostname PE2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 1234
!
end
Conclusion
I hope this lesson has been useful to get a basic understanding of why we use MPLS and how it uses labels as a
tunneling mechanism to create a BGP free core. There’s a lot more to this story. In other lessons you will learn:
 How MPLS routers generate/exchange labels using LDP.

 How to build MPLS VPNs
 How to tunnel Ethernet or frame-relay over your MPLS network.
 And more…
Page 16 of 177
MPLS Labels and Devices
In my introduction to MPLS I explained why we use MPLS and explained some of the basics of how we use
labels for forwarding decisions. In this lesson, we’ll take a closer look at the MPLS labels, the devices that we
use and how IP packets travel through the MPLS network.
MPLS Label Format

The MPLS header has been standardized, you can find it in RFC 3032. The header is pretty simple, here’s what
it looks like:
Here’s what the different fields are used for:
 Label value: the name says it all, this is where you will find the value of the label.
 EXP: these are the three experimental bits. These are used for QoS, normally the IP precedence value of
the IP packet will be copied here.
 S: this is the “bottom of stack” bit. With MPLS it’s possible to add more than one label, you’ll see why
in some of the MPLS VPN lessons. When this bit is set to one, it’s the last MPLS header. When it’s set
to zero then there is one or more MPLS headers left.
 TTL: just like in the IP header, this is the time to live field. You you can use this for traces in the MPLS
network. Each hop decrements the TTL by one.
The MPLS header is added in between the L2 and L3 header:
That’s why we call it a “layer 2.5” protocol. Here’s an example of what it looks like in wireshark:
Page 17 of 177
Above you have an example of the MPLS header in between the Ethernet and IP header. You can also see the
different fields, this header uses label value 16. We don’t use QoS and since there is only one MPLS header, the
bottom of label stack bit has been set.
Where did the label value come from? MPLS uses a protocol called LDP (Label Distribution Protocol) for
this. You will learn about it in the next lesson.
MPLS Devices and Operations

Now you know what the MPLS labels look like, let’s talk about a bit about the different devices you will
encounter in a MPLS network. Here’s an overview:
Page 18 of 177
Above you will find three different routers:
 CE (Customer Edge): this device is the last device in the customer’s network, it could be a L2 or L3
device. In my picture I used a router but for example, it could be a switch. This device does not use
MPLS.
 PE (Provider Edge): this device is owned by the ISP and sits at the edge of the ISP’s network. It has an
important role…it receives packets or frames from the customer and will then add a MPLS label to it
and forwards towards the core. Another common name for this device is LER (Label Edge Router).
 P (Provider): this device connects to PE routers and other P routers. It has a simple job, it switches
packets based on their labels or removes the labels. Another common name for this device is the LSR
(Label Switch Router) or transit router.
There are three actions we can perform with labels:[teaser]
 Label push: when we add a label to a packet, we call it a label push.

 Label swap: replacing a label with another value is called a label swap.
 Label pop: removing the label is called a label pop.
Let’s look at an example of how labels are pushed, swapped and popped in a MPLS network:
Let me add some more detail to the picture above:
1. The CE1 router is owned by the customer and connected to the ISP’s PE1 router. This device doesn’t
have a clue what MPLS is and sends an IP packet that should end up at CE2 (another site of the
customer).
Page 19 of 177
2. The PE1 router receives the IP packet from the CE1 router, it will push a label on it and forwards it
further into the core of the ISP network.
3. P1 receives the labeled packet from PE1, swaps the label and forwards it to P2. Labels are only locally
significant, we’ll talk more about this in the next lesson.
4. P2 receives the labeled packet from P1, swaps the label and forwards it to P3.
5. P3 receives the labeled packet and will pop the label, forwarding the IP packet to PE2. This is called
penultimate hop popping and is performed to save PE2 the trouble of looking at the MPLS label.
6. PE2 receives the IP packet and forwards it to the CE2 router.
7. The CE2 router receives the IP packet and the customer is happy.
The label swapping that the P routers perform is similar to how a frame-relay switch behaves. A frame with a
DLCI number comes in on one interface and is switched to another interface with a different DLCI number.
Conclusion
You have now seen what the MPLS header looks like, the different devices and their role in the MPLS network.
You have also seen an example of how labels are pushed, swapped and popped. In the next lesson we will take
a close look at LDP (Label Distribution Protocol) where you will learn where the different label values come
from.
MPLS LDP (Label Distribution Protocol)

LDP is a protocol that automatically generates and exchanges labels between routers. Each router will locally
generate labels for its prefixes and will then advertise the label values to its neighbors.
It’s a standard, based on Cisco’s proprietary TDP (Tag Distribution Protocol). It’s pretty much the same story as
802.1Q/ISL or PaGP/LACP. Cisco created a protocol and a standard was created later. Nowadays almost
everyone uses LDP instead of TDP.
Like many other protocols, LDP first establishes a neighbor adjacency before it exchanges label information.
It works a bit different than most protocols though…
First we send UDP multicast hello packets to discover other neighbors. Once two routers decide to become
neighbors, they build the neighbor adjacency using a TCP connection. This connection is then used for the
exchange of label information. Normally a loopback interface is used for the neighbor adjacency. Here’s an
example:
Page 20 of 177
The two routers above will send multicast hello packets on their FastEthernet interfaces. Within this hello
packet, they will advertise a transport IP address. This IP address is then used to establish the TCP connection
between the two routers. Here’s what the hello packet looks like in wireshark:
In the capture above you can see a couple of interesting things:
 The hello packets are sent to multicast address 224.0.0.2 using source/destination UDP port 646.
 Each router has a unique ID called the LSR (Label Switch Router) ID. This is similar to how most protocols select
an ID, by default it will select the highest IP address on a loopback interface. If you don’t have any loopback
interfaces then we will use the highest IP address on a physical interface.
 At the bottom you find the transport address. This is what we use to build the actual TCP connection. Like the
LSR ID, the router selected the IP address on the loopback interface as the transport address.
Make sure that the IP address that LDP has selected for the transport address is advertised in your routing protocol.
Otherwise your routers will be able to hear each others hello packets but they can’t form a neighbor adjacency since the
transport address(es) are unreachable.
This is different compared to how routing protocols like OSPF or EIGRP form neighbor adjacencies. For
example, when you run OSPF then your routers will form neighbor adjacencies on all interfaces that run OSPF:
Page 21 of 177
LDP will only form a single neighbor adjacency, no matter how many interfaces you have in between your
routers:
LDP is a bit similar to BGP when you use the loopback interfaces for the neighbor adjacency. When we use
BGP we have to use the update-source command to select the source, LDP does it automatically.
So once our LDP routers have become neighbors, how do we exchange label information? To explain this, let’s
do a quick review of how normal routing uses the RIB and FIB. If you have no idea what these two are then I
recommend you to read my CEF tutorial first before you continue.
With normal routing, we use routing protocols like EIGRP, OSPF or BGP to learn prefixes from other routers.
These are all stored in the RIB (Routing Information Base), this is your routing table.
The information in the RIB is used to build the FIB (Forwarding Information Base) which is what we use for
actual forwarding of IP packet. These tables are all used for IP packets but for MPLS we use something else:
Page 22 of 177
When we use LDP, we locally generate a label for each prefix that we can find in the RIB. This information is
then added to the LIB (Label Information Base).
The information in the LIB is used to build the LFIB (Label Forwarding Information Base). When the router
has to forward a packet with a MPLS label on it, it will use the LFIB for forwarding decisions.[teaser]
The LIB is similar to the RIB but it’s used to store labels for prefixes. The LFIB is similar to the FIB, it’s used
for actual forwarding of MPLS packets.
Two routers that have formed a LDP neighbor adjacency will exchange the label information in their LIBs to
tell each other what label values to use for different prefixes.
All routers running LDP will now know what label values to use when they switch a MPLS packet to their
neighbor.
Now you have an idea what LDP is about, let’s take a look at it in action. I will also show you the different
tables that I just described.
Page 23 of 177
Configuration
I will use the following three routers to demonstrate LDP:
Each router has a loopback interface that we will use for the LDP neighbor adjacency. LDP will select the IP
addresses on the loopback interfaces as the LSR IDs and the transport addresses. We also need the information
in the RIB to build the LIB so I’ll configure OSPF to advertise all prefixes.
OSPF Configuration
Let’s advertise all interfaces:
R1(config)#router ospf 1
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
That’s all we need.
LDP Configuration
There are two ways to configure LDP:
 On the interface level with the mpls ip command.

 Globally under the OSPF process with the mpls ldp autoconfig command.
It doesn’t matter much which one you pick, by default LDP will create a label for each prefix. I’ll enable it on
the interfaces this time:
R1(config)#interface FastEthernet 0/0

R1(config-if)#mpls ip
After a few seconds you will see a message on the consoles telling you that the neighbor is up:
Page 24 of 177
R1#
%LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
That’s all you have to do to enable LDP. Let’s verify our work!
Verification
The messages on the console(s) revealed to us that we have a neighbor adjacency but it still might be useful to
check some things yourself.
LDP Neighbor Adjacency
First let’s check if LDP is enabled on the interface:
R1#show mpls interfaces

Interface IP Tunnel BGP Static Operational
FastEthernet0/0 Yes (ldp) No No No Yes
The show mpls interfaces command is a quick way to see if LDP is enabled or not. It tells us what interfaces
are enabled and if they are operational or not. The next thing to check is if we have LDP neighbors or not:
R2#show mpls ldp neighbor

Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
TCP connection: 1.1.1.1.646 - 2.2.2.2.36200
State: Oper; Msgs sent/rcvd: 8/7; Downstream
Up time: 00:00:32
LDP discovery sources:
FastEthernet0/0, Src IP addr: 192.168.12.1
Addresses bound to peer LDP Ident:
192.168.12.1 1.1.1.1
TCP connection: 3.3.3.3.13500 - 2.2.2.2.646
Up time: 00:00:12
192.168.23.3 3.3.3.3
Akove you see the output of R2. Here’s what you see:
 R2 and R3 have become neighbors:

o R2 uses 2.2.2.2 as its LSR ID, R3 uses 3.3.3.3 as the LSR ID.
o R2 and R3 have formed a TCP connection using 2.2.2.2 and 3.3.3.3 as the transport addresses.
o Discovery (hello packets) was done using the FastEthernet0/1 interface.
 R1 and R2 have become neighbors:
Page 25 of 177
o R2 uses 2.2.2.2 as its LSR ID, R1 uses 1.1.1.1 as the LSR ID.
o R1 and R2 have formed a TCP connection using 2.2.2.2 and 1.1.1.1 as the transport addresses.
o Discovery (hello packets) was done using the FastEthernet0/0 interface.
Now we have confirmed that we have LDP neighbors, let’s look at the labels.
LDP Control Plane
When you use LDP, all routers will start assigning labels with label value 16. This might be a bit annoying if
you are new to MPLS as some routers will use the same label value. To make it easier to read the different
tables I will configure each router to use different label values. Here’s how to do this:
R1(config)#mpls label range 100 199

When you use this command you will have to reload the routers, clearing the neighbor adjacency is not enough.
Let’s take a look at some labels. Since the LIB is built with information from the RIB, we will start with the
routing table. Here’s R1:
R1#show ip route
1.0.0.0/32 is subnetted, 1 subnets

C 1.1.1.1 is directly connected, Loopback0
O 2.2.2.2 [110/2] via 192.168.12.2, 00:36:02, FastEthernet0/0
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, FastEthernet0/0
L 192.168.12.1/32 is directly connected, FastEthernet0/0
O 192.168.23.0/24 [110/2] via 192.168.12.2, 00:36:02, FastEthernet0/0
Above you can see the prefixes in the routing table. Here’s what the LIB looks like:
R1#show mpls ldp bindings

lib entry: 1.1.1.1/32, rev 4
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 200
lib entry: 2.2.2.2/32, rev 6
local binding: label: 100
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 3.3.3.3/32, rev 10
lib entry: 192.168.12.0/24, rev 2
lib entry: 192.168.23.0/24, rev 8
Above you can see the LIB of R1. Let’s walk through some of the things we see here:
Page 26 of 177
 The first entry is for 1.1.1.1/32, the loopback interface of R1. This router doesn’t generate a label value for this
entry since it’s directly connected. You can see however that R2 has advertised to R1 that it uses label value 200
for this prefix.
 The second entry is for 2.2.2.2/32. R1 has chosen label value 100 for this entry, we can also see that R2 doesn’t
use a label for this prefix. This makes sense since it’s directly connected for R2.
 The third entry for 3.3.3.3/32 has a local label value of 102. R2 is using label value 201 for this entry.
 The fourth entry is 192.168.12.0/24. We don’t use a label for this entry since it’s directly connected. R2 also
doesn’t use a label value since it’s directly connected there as well.
 The fifth entry is for 192.168.23.0/24, R1 uses label value 101 for this one.
Now let’s take a look at the LFIB, that’s what we will actually use when we forward MPLS packets:
R1#show mpls forwarding-table

100 Pop Label 2.2.2.2/32 0 Fa0/0 192.168.12.2
101 Pop Label 192.168.23.0/24 0 Fa0/0 192.168.12.2
102 201 3.3.3.3/32 0 Fa0/0 192.168.12.2
The LFIB is much smaller, keep in mind that this is similar to the CEF table that we use for IP forwarding.
There is no entry for 1.1.1.1 /32 or 192.168.12.0 /24 here since we don’t have a label for these prefixes. When
we want to reach 3.3.3.3 /32 then we will add label value 201 to the MPLS header before we send it to R2.
When R1 receives something for 2.2.2.2/32 or 192.168.23.0/24 then we will “pop the label” before we forward
it to R2. This is called penultimate hop popping. I’ll explain this in more detail in another post, it’s done to save
R2 some time by already removing the MPLS header.
Let me also show you the RIB, LIB and LFIB of R2 and R3:
R2#show ip route

lib entry: 1.1.1.1/32, rev 8
lib entry: 2.2.2.2/32, rev 6
lib entry: 3.3.3.3/32, rev 10
Page 27 of 177
lib entry: 192.168.12.0/24, rev 2
lib entry: 192.168.23.0/24, rev 4
200 Pop Label 1.1.1.1/32 0 Fa0/0 192.168.12.1
201 Pop Label 3.3.3.3/32 126 Fa0/1 192.168.23.3
And here’s R3:
R3#show ip route

O 192.168.12.0/24 [110/2] via 192.168.23.2, 00:45:50, FastEthernet0/0
lib entry: 1.1.1.1/32, rev 10
lib entry: 2.2.2.2/32, rev 8
lib entry: 3.3.3.3/32, rev 6
lib entry: 192.168.12.0/24, rev 12
lib entry: 192.168.23.0/24, rev 2
300 Pop Label 2.2.2.2/32 0 Fa0/0 192.168.23.2
301 200 1.1.1.1/32 0 Fa0/0 192.168.23.2
302 Pop Label 192.168.12.0/24 0 Fa0/0 192.168.23.2
LDP Data Plane
All these tables allow us to check the control plane but what about the data plane? We can use a quick
traceroute to see if we are using label switching:
R1#traceroute 3.3.3.3 source 1.1.1.1
Page 28 of 177
1 192.168.12.2 [MPLS: Label 201 Exp 0] 0 msec 0 msec 4 msec
2 192.168.23.3 0 msec 0 msec *
When you use traceroute on your MPLS devices then you can see the labels that we use. The path that we use
here is called the LSP (Label Switched Path).
Conclusion
You have now learned how LDP uses multicast to send hello packets to discover other LDP routers. You have
seen how we establish a neighbor adjacency using a TCP connection and the transport addresses in the hello
packet.
We also discussed the different tables that we use for IP and MPLS forwarding. Last but not least, you have
seen some of the labels in action. I can recommend you to boot up some routers yourself, enable LDP and then
take a look at it yourself.
MPLS LDP Label Filtering Example

Once you enable MPLS on the interfaces between the routers and LDP neighbor adjacencies have been formed,
a label will be advertised for each network. With LDP however we can configure filters to decide what
networks should get a label and which ones shouldn’t be tagged. I’ll use the following topology to demonstrate
this:
Above we have 3 routers and each router has 2 loopback interfaces so that we have plenty of networks to play
with. Before we enable MPLS we’ll configure OSPF so that all networks are advertised:
R1,R2,R3:
(config)#router ospf 1
(config-router)#network 0.0.0.0 255.255.255.255 area 0
We’ll do this the easy way and activate OSPF on all interfaces. Now let’s enable MPLS on the FastEthernet
interfaces:
R1(config)#interface fastEthernet 0/0

R2(config-if)#exit
Page 29 of 177
Let’s check if we have LDP neighbors:
R2#show mpls ldp neighbor | include Peer

So far so good, now let’s take a look at the LDP labels that have been generated:

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.12.2
17 17 33.33.33.33/32 0 Fa0/0 192.168.12.2
18 18 3.3.3.3/32 0 Fa0/0 192.168.12.2
19 Pop tag 22.22.22.22/32 0 Fa0/0 192.168.12.2
20 Pop tag 192.168.23.0/24 0 Fa0/0 192.168.12.2
16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.12.1
17 Pop tag 33.33.33.33/32 0 Fa0/1 192.168.23.3
18 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.23.3
19 Pop tag 11.11.11.11/32 0 Fa0/0 192.168.12.1
16 Pop tag 192.168.12.0/24 0 Fa0/0 192.168.23.2
17 16 1.1.1.1/32 0 Fa0/0 192.168.23.2
18 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.23.2
19 Pop tag 22.22.22.22/32 0 Fa0/0 192.168.23.2
20 19 11.11.11.11/32 0 Fa0/0 192.168.23.2
For all networks a label has been generated by LDP. Now let’s configure filtering so that we only generate
labels for the loopback 0 interfaces. This is how you do it:
[teaser]
R1(config)#access-list 1 permit 1.1.1.1 0.0.0.0

R1(config)#no mpls ldp advertise-labels
R1(config)#mpls ldp advertise-labels for 1
First use no mpls ldp advertise-labels to disable the advertisement of all labels. Secondly use the mpls ldp
advertise-labels for command and refer to an access-list or prefix-list to choose what networks should have a
label.
Be careful, if you forget to use the no mpls ldp advertise-labels command you will discover that LDP is STILL advertising
a label for each network…
Page 30 of 177
Let’s verify our work:

16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.12.2
17 Untagged 33.33.33.33/32 0 Fa0/0 192.168.12.2
18 Untagged 3.3.3.3/32 0 Fa0/0 192.168.12.2
19 Untagged 22.22.22.22/32 0 Fa0/0 192.168.12.2
20 Untagged 192.168.23.0/24 0 Fa0/0 192.168.12.2
16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.12.1
17 Untagged 33.33.33.33/32 0 Fa0/1 192.168.23.3
18 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.23.3
19 Untagged 11.11.11.11/32 0 Fa0/0 192.168.12.1
16 Untagged 192.168.12.0/24 0 Fa0/0 192.168.23.2
17 Untagged 1.1.1.1/32 0 Fa0/0 192.168.23.2
18 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.23.2
19 Untagged 22.22.22.22/32 0 Fa0/0 192.168.23.2
20 Untagged 11.11.11.11/32 0 Fa0/0 192.168.23.2
Above you can see that only network 1.1.1.1/32, 2.2.2.2/32 and 3.3.3.3/32 now have a label when advertised to
a LDP neighbor.
hostname R1
!
ip cef
!
no mpls ldp advertise-labels
mpls ldp advertise-labels for 1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
access-list 1 permit 1.1.1.1
!
end
hostname R2
!
ip cef
!
Page 31 of 177
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
ip address 22.22.22.22 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
mpls ip
!
ip address 192.168.23.2 255.255.255.0
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
!
end
hostname R3
!
ip cef
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
!
end
VRF Lite Configuration on Cisco IOS

In this lesson you will learn about VRFs (Virtual Routing and Forwarding). By default a router uses a single
global routing table that contains all the directly connected networks and prefixes that it learned through static
or dynamic routing protocols.
VRFs are like VLANs for routers, instead of using a single global routing table we can use multiple virtual
routing tables. Each interface of the router is assigned to a different VRF.
Page 32 of 177
VRFs are commonly used for MPLS deployments, when we use VRFs without MPLS then we call it VRF lite.
That’s what we will focus on in this lesson. Let’s take a look at an example topology:
In the topology above we have one ISP router and two customers called “Red” and “Blue”. Each customer has
two sites and those are connected to the ISP router. The ISP router has only one global routing table so if we
connect everything like the topology above, this is what the routing table will look like:
ISP#show ip route connected

The ISP router has a single global routing table that has all 4 directly connected networks. Let’s use VRFs to
change this, I want to create a seperate routing table for customer “Blue” and “Red”. First we have to create
these VRFs:
ISP(config)#ip vrf Red

ISP(config-vrf)#exit
ISP(config)#ip vrf Blue
ISP(config-vrf)#exit
Globally we create the VRFs, one for each customer. Our next step is to add the interfaces of the ISP router to
the correct VRF. Here’s how:
ISP(config)#interface FastEthernet 0/0

ISP(config-if)#ip vrf forwarding Blue
% Interface FastEthernet0/0 IP address 192.168.1.254 removed due to enabling VRF Blue
ISP(config-if)#ip address 192.168.1.254 255.255.255.0
On the interface level we use the ip vrf forwarding command to assign the interface to the correct VRF. Once
you do this , you’ll have to add the IP address again. Let’s configure the remaining interfaces:

ISP(config-if)#ip vrf forwarding Red

ISP(config-if)#ip vrf forwarding Blue
Page 33 of 177
ISP(config-if)#ip vrf forwarding Red
All interfaces are now configured. There’s a useful command you can use to see all the VRFs and their
interfaces:
ISP#show ip vrf
Name Default RD Interfaces
Blue Fa0/0
Fa2/0
Red Fa1/0
Fa3/0
Our VRFs are configured, let’s take a look at the global routing table of the ISP router:
ISP#show ip route connected
The global routing table has no entries, this is because all interfaces were added to a VRF. Let’s check the VRF
routing tables:
ISP#show ip route vrf Blue connected

ISP#show ip route vrf Red connected
We use the show ip route command but you’ll need to specify which VRF you want to look at. As you can see,
each VRF has its own routing table with the interfaces that we configured earlier.
If you want to do something on the router like sending a ping then you’ll have to specify which VRF you want
to use. By default it will use the global routing table. Here’s an example how to send a ping:[teaser]
ISP#ping vrf Blue 192.168.1.1

!!!!!
That’s easy enough, just don’t forget to specify the correct VRF. The same thing applies to routing (protocols).
For example if you want to configure a static route you’ll have to specify the correct VRF. Take a look at the
example below:
Page 34 of 177
Router Blue1 has a loopback interface with IP address 1.1.1.1 /32. Let’s create a static route on the ISP router so
that we can reach it:
ISP(config)#ip route vrf Blue 1.1.1.1 255.255.255.255 192.168.1.1
We use the same ip route command but I specified to what VRF the static route belongs. Let’s see if this works:
ISP#ping vrf Blue 1.1.1.1

!!!!!
Easy enough, the ping works. What about routing protocols? We can use OSPF, EIGRP, BGP…no problem at
all. Let’s look at an example for OSPF:
Customer “Blue” and “Red” both want to use OSPF to advertise their networks. Since we use VRFs, everything
is seperated. Let’s start with the OSPF configuration for customer Blue:
Blue1(config)#router ospf 1
Blue1(config-router)#network 192.168.1.0 0.0.0.255 area 0
Blue2(config)#router ospf 1
Page 35 of 177
The OSPF configuration for the customer routers is pretty straight-forward. On the ISP router, we’ll have to
specify what VRF we want to use:
ISP(config)#router ospf 1 vrf Blue

ISP(config-router)#network 192.168.1.0 0.0.0.255 area 0
We configure OSPF process 1 and specify the VRF that we want to use, that’s all there is to it. Let’s do the
same for customer Red:
Red1(config)#router ospf 1
Red1(config-router)#network 192.168.2.0 0.0.0.255 area 0
Red2(config)#router ospf 1
ISP(config)#router ospf 2 vrf Red
The configuration is similar, I had to use another process ID on the ISP router since the first one is used for
customer Blue. Here’s what the VRF routing tables on the ISP router look like now:
ISP#show ip route vrf Blue ospf
Routing Table: Blue

ISP#show ip route vrf Red ospf
Routing Table: Red

Two seperate routing tables with the prefixes from each VRF, this is looking good.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
Page 36 of 177
network 192.168.1.0 0.0.0.255 area 0
!
end
hostname Blue2
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.3.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.3.0 0.0.0.255 area 0
!
end
hostname ISP
!
ip cef
!
ip vrf Blue
!
ip vrf Red
!
ip vrf forwarding Blue
ip address 192.168.1.254 255.255.255.0
!
ip vrf forwarding Red
ip address 192.168.2.254 255.255.255.0
!
interface FastEtherne2/0
ip vrf forwarding Blue
ip address 192.168.3.254 255.255.255.0
!
ip vrf forwarding Red
ip address 192.168.4.254 255.255.255.0
!
router ospf 1 vrf Blue
network 192.168.1.0 0.0.0.255 area 0
network 192.168.3.0 0.0.0.255 area 0
!
router ospf 2 vrf Red
network 192.168.2.0 0.0.0.255 area 0
network 192.168.4.0 0.0.0.255 area 0
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 37 of 177
ip address 192.168.2.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.2.0 0.0.0.255 area 0
!
end
hostname Red2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.4.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.4.0 0.0.0.255 area 0
!
end
This is what VRF lite is about, it has one downside though…it’s not a scalable solution. In our example we only used a
single ISP router but what if we want to use VRFs and multiple ISP routers? That’s something we’ll discuss in the EVN
(Easy Virtual Network) lesson.
MPLS Layer 3 VPN Explained

In previous lessons I explained the basics of MPLS:
 Introduction to MPLS
 MPLS Labels and Devices
 MPLS LDP
 VRF
In this lesson we will look at MPLS L3 VPNs and we will build upon the things you learned in previous
lessons. By now you should know what MPLS is about. What about the L3 VPN part? Here’s what it is about:
 Layer 3: the service provider will participate in routing with the customer. The customer will run OSPF,
EIGRP, BGP or any other routing protocol with the service provider, these routes can be shared with other sites
of the customer.
 VPN: routing information from one customer is completely separated from other customers and tunneled over
the service provider MPLS network.
Let’s look at an example:
Page 38 of 177
Above we have two customers connected to a service provider network. Customer A and B each have two sites
and you can see that they are using the same IP ranges.
Customer A might use OSPF between their sites and customer B could use EIGRP between their sites.
Everything from these customers is completely separated by the service provider.
In this lesson you will learn everything that is required to build a MPLS L3 VPN network. Let’s get started!
VRF (Virtual Routing and Forwarding)

Let’s start with VRFs. This is the first step in separating traffic from different customers. Instead of using a
single global routing table, we use multiple routing tables. Each customer of the service provider will use a
different VRF. Let’s take a closer look:
Above we have our PE1 router with the two customer sites. Each customer will use a different VRF so the
overlapping address space is no problem. Now you might be wondering, why don’t we use VRFs everywhere
instead of MPLS? We could but there’s one downside to using VRFs. Take a look at the following picture:
Page 39 of 177
The problem with VRFs is that you have to create them everywhere. When our goal is to have connectivity
between CE1 and CE3 then we will have to add a VRF on the PE1, P and PE2 router. Also, all the service
provider routes will have to participate with routing. For example, when customer A wants to run OSPF
between their two sites then it means that we have to configure OSPF on the PE1, P and PE2 router of the
service provider for their VRF.
When customer B wants to run EIGRP between their sites, we have to participate…we’ll have to configure
EIGRP on all service provider routers for the VRF of customer B.
This is not a scalable solution so it’s not going to happen. Instead, we will configure the VRFs only on the PE
routers. The core of the service provider network (P router) will only do switching based on labels.
To share information about VRFs between PE routers, we will use BGP.
MP-BGP (Multi Protocol BGP)

We will use BGP between the PE routers so that they can share information from the VRFs. Here’s how it
works:
 One of the CE routers advertises something to the PE router, this can be done through OSPF, EIGRP, BGP or any
other routing protocol (static routing is also possible).
 The PE router uses a VRF for the customer so it will store everything it learns in the routing table of the
customer’s VRF.
 The PE router will then redistribute everything in BGP.
 The PE router will advertise to to the other PE router through iBGP.
There’s a couple of problems though. First of all, our two customers are using overlapping address space. Let’s
say that our PE1 router is advertising 192.168.1.0 /24 from customer A to the PE2 router on the other side.
Here’s what happens:
Page 40 of 177
The PE2 router will learn 192.168.1.0 /24 from the PE1 router but it has no clue to what customer it will belong.
There is no way to differentiate if something belongs to customer A or B.
What we need is something to make all prefixes that we learn unique.
RD (Route Distinguisher)
To fix this issue, we will use a RD (Route Distinguisher). We will add something to the prefix of the customer
so that it will become unique:
The RD is a 8 byte (64 bit) field. You can use any value you want but typically we use the ASN:NN format
where ASN is the service provider’s AS number and NN is a number we pick that identifies the site of the
customer.
The RD and the prefix combined is what we call a VPNv4 route. We now have a method to differentiate
between the different prefixes of our customers. Here’s an example:
Page 41 of 177
Let’s say that we use RD 123:10 for customer A and RD 123:20 for customer B. By adding these values, we
have unique VPNv4 routes.
How do we advertise these VPNv4 routes? That’s what we need MP-BGP for.
MP-BGP supports IPv4 unicast/multicast, IPv6 unicast/multicast and it has support for VPNv4 routes. To
exchange VPNv4 routes, MP-BGP uses a new NLRI (Network Layer Reachability Information) format that
has the following attributes:
 RD (Route Distinguisher)
 IPv4 prefix
 Next Hop
 VPN Label
This is how PE routers exchange VPNv4 routes with each other. This NRL also has an attribute called the VPN
label, we’ll get back to this one later in this lesson.
RT (Route Target)
When a PE router learns these VPNv4 routes, what will it do with it? Take a look at the picture below:
Page 42 of 177
Our PE2 router has learned the two VPNv4 routes, one for each customer. You might think that the PE2 router
will automatically export each VPNv4 route in the correct customer VRF but that’s not going to happen.[teaser]
We use something called a RT (Route Target) to decide in which VRF we import and export VPNv4 routes.
The RT is a 8 byte value that uses the same format as the RD (ASN:NN). It’s advertised between PE routers by
using a BGP extended community value. For each VRF that we configure, we tell it what RTs we want to
import and export. Here’s an example:
Let me explain the picture above:
 Both PE routers are configured to use a VRF called “CustA”for customer A.

 When PE1 receives a prefix from CE1, it will add RD 123:10 to it to create a unique VPNv4 route.
 PE1 is configured to add RT 123:1 to all VPNv4 routes for VRF CustA.
 PE1 will advertise the VPNv4 route to PE2.
 PE2 is configured to export all VPNv4 routes that use RT 123:1 into VRF CustA.
 When PE2 receives the VPNv4 route, it will redistribute it into the VRF so that CE3 will learn the prefix.
The end result will be that CE3 will learn prefix 192.168.1.0 /24 that was advertised by CE1.
Since the RD and RT use the same format, many students confuse these two. Normally we use the same value for these
two but to emphasize that the RD and RT are two different things, I used 123:10 for the RD and 123:1 for the RT.
Now let me show you the picture with our two customers again:
Page 43 of 177
In the picture above you can see that the PE routers are importing and exporting everything from customer A
with RT value 123:1. This allows CE1 and CE3 to learn everything from each other. We do the same thing for
customer B but we use RT 123:2 for VRF CustB.
CE2 and CE4 will be able to learn everything from each other.
The RT gives us a lot of control over our VPNv4 routes. Do you want to give customer B access to the
networks behind CE3 of customer A? Just import and export some RTs and it’s done.
Do you want to build a hub and spoke topology for a third customer? No problem, we can do this by importing
and exporting some RTs. The service provider can also use this to offer “shared services” like Internet access.
Transport and VPN Label

Everything that we just discussed about the VRFs, MP-BGP, RD and RT occurs on the control plane. On the
data plane, we still have a problem. Let me give you an example:
In the picture above I have added a couple of extra P routers so that we have a nice example of how the routers
in the service provider network forward traffic. In the example, the CE1 router from the customer is sending an
IP packet with source address 192.168.1.1 and destination 192.168.2.2 to the PE1 router.
The PE1 router will add a transport label to the IP packet and our MPLS packet will be label switched all the
way to P3 which pops the label (penultimiate hop popping) so that PE2 receives the IP packet.
In the header of this IP packet, there’s nothing that will help PE2 decide where to forward it to.
To fix this problem, we will add a second label to the IP packet called the VPN label. Besides the RT, the PE1
router will also advertise a VPN label to the PE2 router. Take a look at the example below:
Page 44 of 177
Here’s what happens:
 The CE1 router sends an IP packet to the PE1 router.

 The PE1 router will first add a VPN label to the IP packet, in this example we’ll pick number 21.
 The PE1 router also adds a transport label to it and it will be forwarded to the P1 router.
 The packet makes it to the P3 router, which pops the transport label.
 PE2 sees VPN label 21 and knows that this belongs to the RT of the VRF that connects to CE3. It pops the label
and forwards the IP packet to CE3.
Conclusion
You have now seen all components that are used in MPLS VPNs. With all the pieces together, it’s quite a
complex story. In other lessons, I will show you the configuration of everything that I explained above and we
will take a look at the different PE-CE scenarios where we use OSPF, EIGRP, BGP, etc between the customer
and provider edge.
MPLS Layer 3 VPN Configuration

In this lesson we’ll take a look how to configure a MPLS Layer 3 VPN PE-CE scenario. Here’s the topology I
will use:
Page 45 of 177
Above we have five routers where AS 234 is the service provider. There’s one customer with two sites, AS 1
and AS 5. Our customer wants to exchange 1.1.1.1 /32 and 5.5.5.5 /32 between its sites using BGP. To achieve
this, we’ll have to do a couple of things:
 Configure IGP and LDP within the service provider network.

 Configure VRFs on the PE routers.
 Configure IBGP between the PE routers.
 Configure BGP between the PE and CE routers.
There are a lot of difference pieces in the MPLS puzzle to make this work. Instead of configuring everything at
once and praying that it will work, we’ll build this network step-by-step. At each step, I’ll show you how to
verify that it’s working before we continue with the next step.
Having said that, let’s get started!
Configuration
IGP and LDP
First we will configure the service provider network. On the PE1, P and PE2 routers we will create a loopback
interface that will be advertised in OSPF. LDP will then uses the addresses as the transport address for the TCP
connection. Let’s add those interfaces and enable OSPF:
PE1(config)#interface loopback 0
P(config)#interface loopback 0
P(config-if)#ip address 3.3.3.3 255.255.255.255
Page 46 of 177
Now we will configure OSPF to advertise all interfaces in the service provider network:
And let’s enable LDP on all internal interfaces:
PE1(config)#interface FastEthernet 0/1

P(config)#interface FastEthernet 0/0
P(config)#interface FastEthernet 0/1

That takes care of that. Let’s see if MPLS is enabled:
PE1#show mpls interfaces

P#show mpls interfaces
PE2#show mpls interfaces
That’s looking good to me. Do we have any LDP neighbors?
P#show mpls ldp neighbor

TCP connection: 2.2.2.2.646 - 3.3.3.3.55065
Up time: 00:02:39
192.168.12.2 192.168.23.2 2.2.2.2
TCP connection: 4.4.4.4.52817 - 3.3.3.3.646
Up time: 00:02:02
192.168.34.4 192.168.45.4 4.4.4.4
Page 47 of 177
Our P router in the middle has two neighbors so we know that LDP is working. Just to be sure, let’s check if we
have connectivity between PE1 and PE2:
PE1#ping 4.4.4.4 source loopback 0

!!!!!
A quick ping tells us that it’s working. Are we switching based on labels though? Let’s do a trace to find out:
PE1#traceroute 4.4.4.4 source loopback 0

2 192.168.34.4 0 msec 0 msec *
Above you can see that we are using a label for the packet from PE1 to PE2. The P router is popping the label
(penultimate hop popping) so PE1 receives a normal IP packet. So far, this is looking good.
VRF on the PE routers
Since we want our customer routes separated from the service provider’s routes, we’ll have to create some
VRFs. Here’s how it’s done:
PE1(config)#ip vrf CUSTOMER
First I will create a VRF called CUSTOMER. The next step will be configuring a RD (Route Distinguisher):
PE1(config-vrf)#rd ?
ASN:nn or IP-address:nn VPN Route Distinguisher
The RD is to make sure that all prefixes are unique. The customer prefix + RD together are a VPNv4 route. I’ll
pick something simple:
PE1(config-vrf)#rd 1:1
Our RD will be 1:1. The next item to configure is the RT (Route Target). This defines where we will import and
export our VPNv4 routes. I want to make sure that all routes from CE1 and CE2 will be exchanged:
PE1(config-vrf)#route-target both 1:1
I will use RT value 1:1 and use parameter both. This means that all routes of this VRF will be imported and
exported.
I used the same value (1:1) for the RD and RT, keep in mind that these are two different things…don’t mix them up!
Here’s what the VRF now looks like:
PE1#show run | begin vrf

Page 48 of 177
ip vrf CUSTOMER
rd 1:1
route-target export 1:1
route-target import 1:1
After creating the VRF globally, we have to assign the interface that is facing the customer to the VRF:

PE1(config-if)#ip vrf forwarding CUSTOMER
% Interface FastEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF
CUSTOMER
Once you add an interface to a VRF, Cisco IOS will remove its IP address. Let’s add it again:
The VRF configuration of PE1 is now complete. We’ll configure the exact same thing on PE2:

PE2(config-vrf)#route-target export 1:1
PE2(config-vrf)#route-target import 1:1

The VRFs are now configured. If you want to reach the CE1 or CE2 routers then you’ll have to use the VRFs
from now on:
PE1#ping vrf CUSTOMER 192.168.12.1

!!!!!
!!!!!
Great our VRFs are operational!
IBGP Configuration on PE1 and PE2
PE1 and PE2 will have to exchange VPNv4 routes through IBGP. When you configure iBGP, your routers will
only exchange IPv4 unicast routes by default. Since we need the PE routers to exchange VPNv4 routes, we’ll
have to activate an additional address-family:[teaser]

PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor 4.4.4.4 activate
Page 49 of 177
In the configuration above I’m sourcing the iBGP updates from the loopback interface. We also enabled the
VPNv4 address-family, this will allow the router to exchange those VPNv4 routes. When you activate the
VPNv4 address-family, the router will do one more thing for you:
PE1#show run | section bgp

router bgp 234
!
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
exit-address-family
Above you can see that the router automatically added the send-community extended command. This
command is required and should never be removed since we use a community to advertise the route-target.
The configuration of PE1 is complete, let’s configure the same thing on PE2:

The iBGP configuration of the PE routers is now complete. There’s one more thing we could do…
Right now our routers will be able to exchange IPv4 unicast prefixes and VPNv4 routes. In our example
however, the PE routers will only be used to exchange VPNv4 routes so we can disable the address-family for
IPv4 unicast. Here’s how you can do this:

PE1(config-router)#address-family ipv4
PE1(config-router-af)#no neighbor 4.4.4.4 activate
PE2(config-router-af)#no neighbor 2.2.2.2 activate
This will disable the IPv4 unicast address-family. Let me show you the complete BGP configuration one more
time:
PE1#show run | section bgp

router bgp 234
!
address-family ipv4
no neighbor 4.4.4.4 activate
exit-address-family
!
Page 50 of 177
exit-address-family
With this BGP configuration, we will use IPv4 to establish the neighbor adjacency but we won’t exchange IPv4
prefixes. The only thing we will exchange are VPNv4 routes.
Before we continue we should check if IBGP is working or not. You’ll need to use some different commands
however, here’s why:
PE1#show ip bgp summary
The show ip bgp summary command won’t work since it is used to check IPv4 unicast prefixes. Here’s the
command you need to use:
PE1#show bgp vpnv4 unicast all summary

BGP router identifier 2.2.2.2, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

4.4.4.4 4 234 7 7 1 0 0 00:03:03 0

2.2.2.2 4 234 8 8 1 0 0 00:04:00 0
You need to use the show bgp vpnv4 command to look at anything that is related to the VPNv4 address-family.
Above you can see that PE1 and PE2 have become neighbors, nothing has been exchanged yet since we don’t
have any VPNv4 routes right now.
EBGP on PE and CE
The last piece of the puzzle is exchanging routes between the PE and CE routers. In this example, we’ll use
EBGP. Let’s start with the CE routers:
CE1(config)#interface loopback 0
CE1(config-if)#ip address 1.1.1.1 255.255.255.255
And we’ll do something similar on CE2:
The configuration of the CE routers is straight forward, this is plain and simple eBGP. Let’s configure the PE
routers:
Page 51 of 177
The interface that connects to the CE1 router is assigned to the VRF. This means we’ll have to create an
address-family in BGP for this VRF:

PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#neighbor 192.168.12.1 remote-as 1
Let’s find out if we have established a BPG neighbor adjacency with the CE1 router:
PE1#show bgp vpnv4 unicast vrf CUSTOMER summary

1 network entries using 160 bytes of memory
1 path entries using 56 bytes of memory
2/1 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 536 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

192.168.12.1 4 1 13 12 2 0 0 00:07:31 1
Great, we have become neighbors and we received one prefix. Let’s take a closer look to see what we have
learned:
PE1#show bgp vpnv4 unicast vrf CUSTOMER

BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-
Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 1.1.1.1/32 192.168.12.1 0 0 1 i
Above you can see that we have learned prefix 1.1.1.1 /32 and we will use RD 1:1. These two values together
are our VPNv4 route.
Let’s configure PE2 to become neighbors with CE2:

PE2(config-router-af)#neighbor 192.168.45.5 remote-as 5
Let’s see if they have become neighbors:
PE2#show bgp vpnv4 unicast vrf CUSTOMER summary

2 network entries using 320 bytes of memory
2 path entries using 112 bytes of memory
Page 52 of 177
3/2 BGP path/bestpath attribute entries using 408 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 912 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

192.168.45.5 4 5 5 5 4 0 0 00:00:31 1
Great, PE2 and CE2 are now neighbors. Did we learn anything?

Filter

*>i1.1.1.1/32 2.2.2.2 0 100 0 1 i
*> 5.5.5.5/32 192.168.45.5 0 0 5 i
Interesting…above you see two prefixes. The first entry was learned through iBGP from the PE1 router. Take a
close look at the next hop address which is 2.2.2.2.
Normally when you use iBGP between two routers, the next hop address does not change automatically. That’s
why we use BGP next hop self sometimes to fix reachability issues. For VPNv4 routes however the next hop
address is changed automatically because the loopback address of the other PE router will be the endpoint of the
tunnel.
Everything is now in place, the only thing left to do is to verify our work.
Verification
I already showed you how to verify some of the things that we configured but there is still a couple of things to
check. We need to make sure that there is connectivity between the CE routers and I will also show you how to
check the transport and VPN labels that are used by the routers.
First we will check if our CE routers have learned anything through BGP:
CE1#show ip bgp
Filter

*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 5.5.5.5/32 192.168.12.2 0 234 5 i
CE2#show ip bgp
Page 53 of 177
Filter

*> 1.1.1.1/32 192.168.45.4 0 234 1 i
*> 5.5.5.5/32 0.0.0.0 0 32768 i
CE1 and CE2 have learned about each others networks. Let’s try a quick ping, just to check if things are
working or note:

!!!!!
Great, our ping is working! A trace is more interesting to look at however, it will show the transport and VPN
label that we use:

1 192.168.12.2 0 msec 0 msec 4 msec
2 192.168.23.3 [MPLS: Labels 17/19 Exp 0] 0 msec 0 msec 4 msec
4 192.168.45.5 0 msec 0 msec *
Above you can see how the packet travels from CE1 to CE2:
 The CE1 router sends a normal IP packet to the PE1 router.

 The PE1 router will add two labels to it:
o First it will add the VPN label (19) which PE2 can use to determine to which VRF this packet will belong.
o The second label is the transport label (17) that is used to get this packet through the core of the service
provider network.
 The P router will receive the packet, looks at the transport label, pops it and forwards the packet to the PE2
router.
 The PE2 router will look at the VPN label and decides that this is for VRF CUSTOMER. It will remove the label and
forwards the IP packet to the CE2 router.
Let’s take a closer look at the labels that we use. Here’s how you can find the VPN label that the PE1 router will
use for 5.5.5.5 /32:
PE1#show bgp vpnv4 unicast all 5.5.5.5

BGP routing table entry for 1:1:5.5.5.5/32, version 4
Paths: (1 available, best #1, table CUSTOMER)
Advertised to update-groups:
3
5
4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
Page 54 of 177
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/19
The output above is interesting to look at. PE1 tells us that it has learned about 5.5.5.5 /32 in VRF
CUSTOMER. The next hop address is 4.4.4.4 and the VPN label will be 19.
The funny thing though is that the next hop is unreachable in the VRF because it’s in the global routing table:
PE1#show ip route vrf CUSTOMER 4.4.4.4

Routing Table: CUSTOMER
% Network not in table
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 192.168.23.3 on FastEthernet0/1, 02:05:53 ago
* 192.168.23.3, from 4.4.4.4, 02:05:53 ago, via FastEthernet0/1
This is an exception for VPNv4, based on the transport label the router knows to use the global routing table to
figure out where 4.4.4.4/32 is. Here’s a good way to see both labels and the logic of the PE1 router how it will
reach the next hop:
PE1#show ip cef vrf CUSTOMER 5.5.5.5

5.5.5.5/32
nexthop 192.168.23.3 FastEthernet0/1 label 17 19
Our PE1 router knows that in order to reach 5.5.5.5, it has to use 192.168.23.3 as the next hop (P router). In
order to get there, we will use transport label value 17. This packet will be forwarded to the P router which
checks its own forwarding table to figure out what to do with it:

16 Pop Label 2.2.2.2/32 21359 Fa0/0 192.168.23.2
17 Pop Label 4.4.4.4/32 21432 Fa0/1 192.168.34.4
When the P router receives something with label 17, it will pop the label and forwards it to 4.4.4.4 (PE2 router).
Once PE2 receives it, it will check its forwarding table and finds this:

16 16 2.2.2.2/32 0 Fa0/0 192.168.34.3
17 Pop Label 3.3.3.3/32 0 Fa0/0 192.168.34.3
18 Pop Label 192.168.23.0/24 0 Fa0/0 192.168.34.3
19 No Label 5.5.5.5/32[V] 2498 Fa0/1 192.168.45.5
Anything that PE2 receives with label value 19 should have all its labels removed. This makes sense since CE2
doesn’t use MPLS, it uses regular IP forwarding. You can also see that 5.5.5.5 /32 is a VPN route. Once PE2
has removed all the labels, it forwards the IP packet to CE2 and that’s it.
Page 55 of 177
Wireshark Captures
I figured it might be interesting to show you some wireshark captures of the things we discussed above. The
first example is a BGP update where PE2 advertises the VPNv4 route for 5.5.5.5 /32 to PE1:
Above you can see quite some interesting items:
 In the extended communities you can find the route-target value 1:1
 In the NLRI information we find:
o The VPNv4 address-family.
o The next hop address 4.4.4.4.
o The VPN label value 19.
o The VPNv4 route:
 RD 1:1
 Prefix 5.5.5.5 /32
The second capture will show you what the packet from 1.1.1.1 to 5.5.5.5 looks like when we receive it on the P
router:
Page 56 of 177
Above you see the ICMP request from CE1 to CE2, the first label is the transport label (17) and the second label
is the VPN label which has the bottom of label stack bit set.
If you want to take a look for yourself, here are the links:
BGP VPNv4 route update
MPLS VPN transport and VPN label
Conclusion
That’s the end of this MPLS layer 3 VPN PE-CE configuration, if you understood everything and are able to
configure this on your own then any of the other PE-CE scenarios will be no problem for you. In the next
lessons I will show you how to configure PE-CE with OSPF and EIGRP.
Want to take a look for yourself? Here are the final configurations of all devices.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router bgp 1
network 1.1.1.1 mask 255.255.255.255
!
Page 57 of 177
end
hostname PE1
!
ip cef
!
ip vrf CUSTOMER
rd 1:1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip vrf forwarding CUSTOMER
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
address-family ipv4 vrf CUSTOMER
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
Page 58 of 177
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
Page 59 of 177
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 5
network 5.5.5.5 mask 255.255.255.255
!
end
MPLS Layer 3 VPN BGP Allow-AS-In

External BGP uses a simple loop prevention mechanism: when you see your own AS number in the AS path,
we don’t accept the prefix. There are some scenarios where this might be an issue. Take a look at the following
topology:
Page 60 of 177
Above we have a MPLS VPN network where the customer is using the same AS number (12) on both sites.
CE1 and CE2 will be unable to learn each others prefixes since they are using the same AS number.
Let’s see if this is true, here are the configurations of all routers if you want to test this yourself:
Here you will find the startup configurations of each device.

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
Page 61 of 177
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
Page 62 of 177
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Each CE router has a loopback interface that was advertised in BGP (1.1.1.1/32 and 5.5.5.5/32). The first thing
to check is to see if the PE routers have learned the prefixes from our CE routers:
PE1#show ip bgp vpnv4 all
Page 63 of 177
*> 1.1.1.1/32 192.168.12.1 0 0 12 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i

*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
*> 5.5.5.5/32 192.168.45.5 0 0 12 i
Above you can see that both PE routers have a VPN route for these prefixes. Did they advertise these prefixes
to our CE routers?
PE1#show ip bgp vpnv4 all neighbors 192.168.12.1 advertised-routes

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
RPKI validation codes: V valid, I invalid, N Not found

*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i
Total number of prefixes 1


*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
No issues there, our PE routers are advertising these prefixes to the CE routers. Let’s see what we find in the
BGP tables of the CE routers:
CE1#show ip bgp

*> 1.1.1.1/32 0.0.0.0 0 32768 i
CE2#show ip bgp

*> 5.5.5.5/32 0.0.0.0 0 32768 i
The CE routers only have their own prefixes in their BGP tables. Why did they refuse the updates from the PE
routers? Time for a debug:
CE1#debug ip bgp all updates

Page 64 of 177
BGP updates debugging is on for all address families
Let’s reset the BGP neighbor adjacency:
CE1#clear ip bgp *
Here’s what you will see on the CE1 router:
CE1# BGP(0): 192.168.12.2 rcv UPDATE about 5.5.5.5/32 -- DENIED due to: AS-PATH contains
our own AS;
As expected, the CE1 router denies the update since it sees its own AS number in the AS path. If we don’t want
to change our AS numbers then there’s two ways to deal with this:
 Use Allow-AS in to overrule the loop prevention mechanism of external BGP.

 Use AS override to change the AS number on the PE routers.
This lesson is about allow-AS in so that’s what we will do this time:
CE1(config-router)#neighbor 192.168.12.2 allowas-in
CE1 is now configured to allow prefixes with its own AS number from the PE1 router. If you left the debug
enabled then you will see this:
CE1#
BGP(0): Revise route installing 1 of 1 routes for 5.5.5.5/32 -> 192.168.12.2(global) to
main IP table
That should take care of our problem. Let’s see if the prefix has been installed:
CE1#show ip route 5.5.5.5

Tag 234, type external
* 192.168.12.2, from 192.168.12.2, 00:01:13 ago
AS Hops 2
Route tag 234
MPLS label: none
There we go, it’s in the routing table. Don’t forget to configure the same change on CE2:
CE2(config-router)#neighbor 192.168.45.4 allowas-in
CE2 should now accept 1.1.1.1/32:

Page 65 of 177
Tag 234, type external
* 192.168.45.4, from 192.168.45.4, 00:00:45 ago
AS Hops 2
Route tag 234
MPLS label: none
That’s looking good. One final check left, let’s see if there is connectivity between 1.1.1.1 and 5.5.5.5:

!!!!!
Excellent it’s working.
Want to take a look at the complete configurations yourself?

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 allowas-in
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 66 of 177
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
Page 67 of 177
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
Page 68 of 177
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
neighbor 192.168.45.4 allowas-in
!
end
Conclusion
The allow-AS command is a simple trick to overrule the loop prevention mechanism of external BGP. In this
example it’s safe to disable it since CE1 and CE2 are stub routers, they only have one exit path through the PE
routers. This solution allowed us to solve the problem on the CE routers. We can also fix it by making a change
on the PE routers, I’ll show you how to do this in the AS override lesson.
When your customer sites are multihomed or have a backdoor link between them then you have to be careful as
this solution can introduce loops. The BGP SoO (Site of Origin) communitry attribute is then used as a loop
prevention mechanism. This is something we will cover in another lesson.
MPLS Layer 3 VPN BGP AS Override

BGP has a simple loop prevention mechanism for external BGP. When you see your own AS number in the AS
path, we do not accept the prefix. This mechanism is fine for Internet routing but there are some other scenarios
where this might be an issue. Take a look at the following topology:
Page 69 of 177
Above we have a small MPLS VPN network with two customer sites. The customer is using the same AS
number (12) for both sites. When CE1 or CE2 receive an update from each other they will not accept it since
their own AS number will be in the AS path.
Let’s find out if this is true. Here are the configurations of all routers:

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
Page 70 of 177
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
Page 71 of 177
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Let’s find out what is going on. First we’ll check if the PE routers have a VPN route for the prefixes from the
CE routers:
Page 72 of 177
*> 1.1.1.1/32 192.168.12.1 0 0 12 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i

*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
*> 5.5.5.5/32 192.168.45.5 0 0 12 i
The PE routers have an entry for the loopback interfaces of the CE routers. Are they advertising these to the CE
routers?


*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i


*>i 1.1.1.1/32 2.2.2.2 0 100 0 12 i
The PE routers are advertising these to the CE routers. Let’s check the CE routers:
CE1#show ip bgp

*> 1.1.1.1/32 0.0.0.0 0 32768 i
CE2#show ip bgp

*> 5.5.5.5/32 0.0.0.0 0 32768 i
There’s nothing there…they only have the prefix on their own loopback interface in the BGP table. Let’s enable
a debug on CE1 to figure out why it’s not accepting anything from PE1:
CE1#debug ip bgp all updates

Page 73 of 177
BGP updates debugging is on for all address families
Let’s reset the neighbor adjacency:
CE1#clear ip bgp *
Here’s what you will see:
CE1#
BGP(0): 192.168.12.2 rcv UPDATE about 5.5.5.5/32 -- DENIED due to: AS-PATH contains our
own AS;
No surprises here…CE1 is denying the update since it sees its own AS number in the AS path. If we want to
keep the same AS number on CE1 and CE2 then there are two possible solutions for this issue:
 Allow-AS in: this can be configured on the CE routers which tells them to accept prefixes with their
own AS number in the AS path.
 AS override: this can be configured on the PE routers, the AS number will be replaced with the AS
number from the service provider.
This lesson is about AS override so that’s what we will do. Let’s configure the PE routers:

PE1(config-router-af)#neighbor 192.168.12.1 as-override
PE2(config-router-af)#neighbor 192.168.45.5 as-override
To speed things up, let’s clear the BGP neighbor adjacencies on the PE routers:
PE1 & PE2#clear ip bgp *
Let’s take another look at the CE routers:
CE1#show ip bgp 5.5.5.5

BGP routing table entry for 5.5.5.5/32, version 7
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
234 234
192.168.12.2 from 192.168.12.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
CE2#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 7
Not advertised to any peer
Refresh Epoch 1
234 234
192.168.45.4 from 192.168.45.4 (4.4.4.4)
Origin IGP, localpref 100, valid, external, best
Page 74 of 177
The CE routers have now learned each others prefixes. If you take a closer look, you can see that AS number 12
has been replaced with AS number 234.
One final check, let’s see if there is connectivity between 1.1.1.1 and 5.5.5.5:

!!!!!
Excellent this is working! Want to take a look at these configurations yourself?

hostname CE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 12
network 1.1.1.1 mask 255.255.255.255
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
Page 75 of 177
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
neighbor 192.168.12.1 as-override
exit-address-family
!
end
hostname P
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
Page 76 of 177
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
neighbor 192.168.45.5 as-override
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router bgp 12
network 5.5.5.5 mask 255.255.255.255
!
end
Page 77 of 177
Conclusion
AS override is a simple technique to change the AS number of updates that you advertise to your external BGP
neighbors. Another solution is allow AS in but this is configured on the CE routers. Since we are “overruling”
the external BGP loop prevention mechanism you have to make sure that you have a loop-free topology.
In this scenario there are no issues since the CE routers are stubs, they only have one exit path. When your
customer sites are multihomed or have a backdoor link then you need to use the BGP SoO (Site of Origin)
community to ensure you have a loop free topology. This is something we’ll cover in another lesson.
MPLS Layer 3 VPN PE-CE RIP

In my previous lessons I explained the basics of MPLS L3 VPNs and I explained in detail how to configure it.
This time, we are going to configure MPLS VPN PE-CE with RIP as the routing protocol between the customer
and service provider.
RIP is a simple routing protocol and easy to implement with MPLS VPN. Here’s the topology we will use:
This is the same topology that I used in my previous examples. Let’s see what the configuration is like…
Configuration
IGP and LDP
We will start with the configuration of the service provider network, we’ll have to configure an IGP (OSPF) and
LDP on the PE1, P and PE2 router. Let’s add some loopbacks that are required for LDP:
Page 78 of 177
Now we can configure OSPF:
PE1(config-router)#mpls ldp autoconfig
P(config-router)#mpls ldp autoconfig
This time I used the mpls ldp autoconfig command to automatically enable LDP for all OSPF enabled
interfaces. Let’s do a quick check to see if LDP is enabled:
P#show mpls ldp neighbor | include Peer

Our P router in the middle has two neighbors so this is looking good. Just in case, let’s verify if there is
connectivity between PE1 and PE2:

2 192.168.34.4 0 msec 0 msec *
PE1 and PE2 are able to reach each other and you can see we are using label switching.
VRFs on the PE Routers
Our next step in the configuration is to configure the VRFs. I will use a VRF called “CUSTOMER”, the route
distinguisher and route-target will be 1:1.
PE1 & PE2

(config)#ip vrf CUSTOMER
(config-vrf)#rd 1:1
(config-vrf)#route-target both 1:1
Don’t forget to add the interfaces facing the customer routers into the VRF:
Page 79 of 177
Let’s check if the PE routers are able to ping the CE routers from the VRF:

!!!!!
!!!!!
So far so good…
IBGP between PE1 and PE2
Our two PE routers require iBGP to exchange the VPNv4 routes. Let’s configure this:

Before we continue we should check if our routers have formed an IBGP neighbor adjacency:


4.4.4.4 4 234 5 6 1 0 0 00:01:03 0
Great, the BGP session has been established.
RIP between PE and CE routers
The only thing left to do is to configure RIP between the PE and CE routers. Let’s start with the CE routers:
Page 80 of 177
CE1(config)#router rip
CE1(config-router)#version 2
CE1(config-router)#no auto-summary
CE1(config-router)#network 192.168.12.0
CE2(config)#router rip
CE2(config-router)#version 2
The CE routers use regular RIP, nothing special here. Now we will configure the PE routers:
PE1(config)#router rip
PE1(config-router-af)#version 2
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#network 192.168.12.0
Since the customer is in the VRF, we have to configure RIP not for the global routing table but for this
particular VRF. This is done with the address-family, the rest of the configuration is the same. Let’s do the same
on PE2:
PE2(config-router-af)#version 2
The PE routers should learn something from the CE routers. Let’s see if this is true:
PE1#show ip route vrf CUSTOMER rip

R 1.1.1.1 [120/1] via 192.168.12.1, 00:00:18, FastEthernet0/0
PE2#show ip route vrf CUSTOMER rip

The PE routers have learned the networks from the CE routers. Now there’s only one thing left to
do…somehow we need to get this RIP information into BGP so that we can advertise it to the other PE router.
This is done with redistribution:

PE1(config-router-af)#redistribute rip
PE2(config-router-af)#redistribute rip
All networks learned through RIP should now be VPNv4 routes, let’s verify this:
Page 81 of 177
Filter

*> 1.1.1.1/32 192.168.12.1 1 32768 ?
*>i5.5.5.5/32 4.4.4.4 1 100 0 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*>i192.168.45.0 4.4.4.4 0 100 0 ?
Filter

*>i1.1.1.1/32 2.2.2.2 1 100 0 ?
*> 5.5.5.5/32 192.168.45.5 1 32768 ?
*>i192.168.12.0 2.2.2.2 0 100 0 ?
*> 192.168.45.0 0.0.0.0 0 32768 ?
Our PE routers have learned about each others redistributed RIP routes. Also, take a close look at the metric
value of 1. BGP uses its MED to carry the original metric of RIP (hop count 1). This allows us to transparently
advertise the metric between two customer sites.
Last but not least, we’ll have to redistribute these VPNv4 routes back into RIP so that the CE routers can learn
the networks. Here’s how to do this:
PE1(config-router-af)#redistribute bgp 234 metric ?
<0-16> Default metric
transparent Transparently redistribute metric
When we redistribute something into RIP, we have to use a seed metric. You can choose if you want to set a
metric yourself or if you want to use the transparent option. If you choose this then the router will use the value
in the BGP MED as the metric. Let’s try this:
PE1(config-router-af)#redistribute bgp 234 metric transparent
Don’t forget PE2:
PE2(config-router-af)#redistribute bgp 234 metric transparent
Our configuration is now finished.
Page 82 of 177
Verification
Let’s check if everything is working. First we’ll check if CE1 and CE2 have learned anything:
CE1#show ip route

R 192.168.45.0/24 [120/1] via 192.168.12.2, 00:00:25, FastEthernet0/0
CE2#show ip route

R 192.168.12.0/24 [120/1] via 192.168.45.4, 00:00:03, FastEthernet0/0
You can see the networks in the routing tables. Note the hop counts, the 1.1.1.1 /32 network had a hop count of
1 in the routing table of PE2 so it is advertised with a hop count of 2 to the CE2 router. Let’s try if it actually
works:

!!!!!
Pinging from CE1 to CE2 is no problem. Let’s look at a trace:

1 192.168.12.2 0 msec 0 msec 4 msec
4 192.168.45.5 0 msec 0 msec *
Above you can see that transport label (17) and VPN label (19) that were used in the service provider network.
Conclusion
RIP as the PE-CE routing protocol is pretty straight forward. The only new item in this configuration is that we
had to redistribute between RIP and BGP and the option of transparently setting the seed metric.
Want to take a look for yourself? Here you will find the final configurations of all routers.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
Page 83 of 177
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
router rip
version 2
network 1.0.0.0
network 192.168.12.0
no auto-summary
!
end
hostname PE1
!!
ip cef
!
ip vrf CUSTOMER
rd 1:1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router rip
!
redistribute bgp 234 metric transparent
network 192.168.12.0
no auto-summary
version 2
exit-address-family
!
router bgp 234
!
exit-address-family
!
Page 84 of 177
redistribute rip
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0/0
no ip address
shutdown
!
interface Serial0/1/0
no ip address
shutdown
!
Page 85 of 177
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router rip
!
redistribute bgp 234 metric transparent
network 192.168.45.0
no auto-summary
version 2
exit-address-family
!
router bgp 234
!
exit-address-family
!
redistribute rip
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router rip
version 2
network 5.0.0.0
network 192.168.45.0
no auto-summary
!
end
MPLS Layer 3 VPN PE-CE EIGRP

In this lesson we’ll take a look how we can use EIGRP as the PE-CE routing protocol for MPLS L3 VPN. If
you already have seen my lesson for PE-CE RIP then you can skip to the “EIGRP between PE and CE routers”
section as the configuration of the service provider network is exactly the same.
Here’s the topology we will use:
Page 86 of 177
Above we have 5 routers. CE and CE2 belong to the customer who wants to run EIGRP between their sites. The
service provider has two PE routers and one P router in the middle.
Configuration
IGP and LDP
Let’s prepare the service provider routers. We need an IGP (OSPF) and LDP on the PE1, PE2 and P router.
Now we can configure OSPF:
Page 87 of 177
This takes care of IGP and LDP. Make sure you have LDP neighbors before we continue:


2 192.168.34.4 0 msec 0 msec *
The PE routers are able to reach each others loopback interfaces and we are using label switching.
PE1 & PE2

(config-vrf)#rd 1:1


!!!!!
!!!!!
So far so good…
Page 88 of 177



4.4.4.4 4 234 5 6 1 0 0 00:01:03 0
EIGRP between PE and CE routers
Here’s where things will be different. We will use EIGRP between the PE and CE routers. Let’s start with the
CE routers:
CE1(config)#router eigrp 1
CE1(config-router)#network 1.1.1.1 0.0.0.0
The EIGRP configuration above is pretty straight forward. On both routers, I used AS number 1. At the end of
this lesson I’ll show you what happens if you pick a different AS number for two sites.
Let’s configure the PE routers:[teaser]
PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf CUSTOMER autonomous-system 1
Page 89 of 177
When you configure the PE router, you can pick any AS number for the “global” EIGRP process. When you
configure the address-family, that’s where you specify the AS number for the VRF. If you forget this, EIGRP
will not run since the router has no idea what AS number to pick for the VRF.
Let’s check if the PE routers have learned anything from the CE routers:
PE1#show ip route vrf CUSTOMER eigrp

D 1.1.1.1 [90/156160] via 192.168.12.1, 00:01:33, FastEthernet0/0
PE2#show ip route vrf CUSTOMER eigrp

Great, it’s in the routing table for the customer’s VRF. Let’s redistribute these into BGP:

PE1(config-router-af)#redistribute eigrp 1
Let’s make sure these routes have become VPNv4 routes:

Filter

*> 1.1.1.1/32 192.168.12.1 156160 32768 ?
*>i5.5.5.5/32 4.4.4.4 156160 100 0 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*>i192.168.45.0 4.4.4.4 0 100 0 ?
Filter

*>i1.1.1.1/32 2.2.2.2 156160 100 0 ?
*> 5.5.5.5/32 192.168.45.5 156160 32768 ?
*>i192.168.12.0 2.2.2.2 0 100 0 ?
Page 90 of 177
*> 192.168.45.0 0.0.0.0 0 32768 ?
Excellent, above we have our VPNv4 routes. Take a close look at the MED value of 156160. This is the EIGRP
metric that has been copied to BGP’s MED attribute.
The last thing to do is redistributing these VPNv4 routes back into EIGRP:
PE1(config-router-af)#redistribute bgp 234 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
EIGRP doesn’t have an option to transparently redistribute the metric from BGP into EIGRP, we still have to
use a seed metric. The cool thing however is that the router will ignore whatever metric you specify here. It will
use the metric from the BGP MED attribute:
PE1(config-router-af)#redistribute bgp 234 metric 1 1 1 1 1
Let’s do the same on PE2:
This completes our configuration.
Verification
I already showed you how to verify some of the things during the configuration but now we will test end-to-end
reachability. First we will check the routing tables of CE1 and CE2:
CE1#show ip route eigrp

D 192.168.45.0/24 [90/30720] via 192.168.12.2, 00:03:50, FastEthernet0/0
CE2#show ip route eigrp

D 192.168.12.0/24 [90/30720] via 192.168.45.4, 00:04:08, FastEthernet0/0
This is looking good. Both CE routers have learned each others loopback interfaces. In the EIGRP topology
table you can see what metric they learned from the PE routers:
CE1#show ip eigrp topology 5.5.5.5/32

EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 5.5.5.5/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720
Descriptor Blocks:
192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0
Composite metric is (158720/156160), route is Internal
Page 91 of 177
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 5200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 5.5.5.5
Above you can see the advertised distance (156160) which we also found in the BGP MED attribute. Let’s do a
quick ping, see if we can reach the other side:

!!!!!
No problems there. Let’s do a trace so you can see the transport and VPN labels:

1 192.168.12.2 0 msec 0 msec 4 msec
4 192.168.45.5 0 msec 0 msec *
Here you can see the transport label (17) and the VPN label (19). Everything is working as it should, there’s one
last thing that I would like to show you. What happens when we use a different AS number between one of the
PE-CE routers? Let’s try this on PE2 and CE2, I’ll use AS 2 there:
PE2(config-router)#no address-family ipv4 vrf CUSTOMER


CE2(config)#no router eigrp 1
The configuration is exactly the same but we changed the EIGRP AS number on PE2 and CE2. Take a look at
the routing tables now:
CE1#show ip route eigrp | incl 5.5.5.5

Page 92 of 177
D EX 5.5.5.5 [170/2560002816] via 192.168.12.2, 00:02:13, FastEthernet0/0
CE2#show ip route eigrp | incl 1.1.1.1
D EX 1.1.1.1 [170/2560002816] via 192.168.45.4, 00:02:44, FastEthernet0/0
There’s two things that have changed now:
 We have EIGRP external routes, this makes sense since we are using two different AS numbers.
 The metric is the actual seed metric that I used, the router no longer uses the information in the BGP MED
attribute.
This doesn’t affect connectivity in our example but it might be a problem if you use a backup link. For example,
let’s say our customer is using the MPLS link as their primary connection but they also have a GRE tunnel over
the Internet between CE1 / CE2 where they use EIGRP. In our first example, with the internal EIGRP routes
(AD 90) and low metric we have a good chance the routers will prefer the MPLS link over the backup GRE
tunnel.
With the different AS numbers, we now have EIGRP external routes (AD 170) and a large (seed) metric. You
have to make sure that the MPLS link will still be preferred over the GRE backup tunnel…
Conclusion
Running EIGRP as the PE-CE routing protocol isn’t much different than RIP, the main difference
is understanding that the seed metric is ignored when you redistribute back into EIGRP but that you do have to
specify something. You have also seen how using different EIGRP AS numbers affects the routing tables.
Want to take a look for yourself? Here you will find the configuration of each router.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 1.1.1.1 0.0.0.0
network 192.168.12.0
!
end
hostname PE1
!
ip cef
!
ip vrf CUSTOMER
rd 1:1
Page 93 of 177
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
!
address-family ipv4 vrf CUSTOMER autonomous-system 1
redistribute bgp 234 metric 1 1 1 1 1
network 192.168.12.0
exit-address-family
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
exit-address-family
!
redistribute eigrp 1
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
!
router ospf 1
Page 94 of 177
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
!
address-family ipv4 vrf CUSTOMER autonomous-system 1
redistribute bgp 234 metric 1 1 1 1 1
network 192.168.45.0
exit-address-family
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
exit-address-family
!
redistribute eigrp 1
exit-address-family
!
end
hostname CE2
Page 95 of 177
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 5.5.5.5 0.0.0.0
network 192.168.45.0
!
end
MPLS Layer 3 VPN PE-CE OSPF

This lesson explains how to use OSPF as the PE-CE routing protocol for MPLS L3 VPN. The configuration is
very similar to PE-CE RIP or PE-CE EIGRP but OSPF has some extra options as a link-state routing protocol.
The first part is about configuring LDP, VRFs and iBGP between the PE routers. This is the same as my
previous lessons so you might want to skip to the PE-CE OSPF section.
Here’s the topology we will use:
Above we have 5 routers. CE and CE2 belong to the customer who wants to run OSPF between their sites. The
service provider has two PE routers and one P router in the middle.
Page 96 of 177
Configuration
IGP and LDP
Let’s prepare the service provider routers. We need an IGP (OSPF) and LDP on the PE1, PE2 and P router.
Now we can configure OSPF for routing in the service provider network:
This takes care of IGP and LDP. Make sure you have LDP neighbors before we continue:


2 192.168.34.4 0 msec 0 msec *
The PE routers are able to reach each others loopback interfaces and we are using label switching.
PE1 & PE2

Page 97 of 177
(config-vrf)#rd 1:1


!!!!!
!!!!!
So far so good…



4.4.4.4 4 234 5 6 1 0 0 00:01:03 0
Page 98 of 177
OSPF between PE and CE Routers
Now we can work on OSPF between the PE and CE routers. Let’s start with CE1 and CE2 first:
CE1(config)#router ospf 1
CE1(config-router)#network 192.168.12.0 0.0.0.255 area 0
Each CE router has a loopback which is advertised in OSPF. Now we can configure OSPF on the PE routers for
the customer VRF:
PE1(config)#router ospf 2 vrf CUSTOMER

Unlike RIP or EIGRP, we don’t use an address-family but a different process for a VRF. Let’s see if we have
learned anything:
PE1#show ip route vrf CUSTOMER ospf

PE2#show ip route vrf CUSTOMER ospf

Great, our PE routers learned the loopback interfaces from the CE routers. Let’s redistribute this into BGP:
PE1 & PE2

(config)#router bgp 234
(config-router)#address-family ipv4 vrf CUSTOMER
(config-router-af)#redistribute ospf 2
If everything went ok, we should now have some VPNv4 routes:

Filter

Page 99 of 177
*> 1.1.1.1/32 192.168.12.1 2 32768 ?
*>i5.5.5.5/32 4.4.4.4 2 100 0 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*>i192.168.45.0 4.4.4.4 0 100 0 ?
Filter

*>i1.1.1.1/32 2.2.2.2 2 100 0 ?
*> 5.5.5.5/32 192.168.45.5 2 32768 ?
*>i192.168.12.0 2.2.2.2 0 100 0 ?
*> 192.168.45.0 0.0.0.0 0 32768 ?
Exellent, we have VPNv4 routes. You can also see that the metric from OSPF (cost 2) has been saved in the
BGP MED attribute. Now let’s redistribute these VPNv4 routes back into OSPF:
PE1 & PE2

(config)#router ospf 2
(config-router)#redistribute bgp 234 subnets
Our configuration is now complete.
Verification
First we’ll check if we have connectivity between our CE routers. Did they learn anything?
CE1#show ip route ospf

O IA 5.5.5.5 [110/3] via 192.168.12.2, 00:02:19, FastEthernet0/0
O IA 192.168.45.0/24 [110/2] via 192.168.12.2, 00:02:19, FastEthernet0/0

O IA 1.1.1.1 [110/3] via 192.168.45.4, 00:02:43, FastEthernet0/0
O IA 192.168.12.0/24 [110/2] via 192.168.45.4, 00:02:43, FastEthernet0/0
Our CE routers have learned each others networks. There’s something interesting in the output
above…normally when we redistribute something into OSPF then our prefixes show up as O E2 or E1, now we
seem to have O IA prefixes. I’ll explain why in a bit, first let’s see if we have connectivity:

!!!!!
Our two CE routers are able to reach each other, let’s try a trace as well:
Page 100 of 177

1 192.168.12.2 0 msec 0 msec 4 msec
4 192.168.45.5 0 msec 0 msec *
Everything seems to be working, the CE routers are able to reach each other and above you can see the transport
label (17) and VPN label (16).
There’s a couple of things left I’d like to explain however, let’s think about the prefixes that we have seen on
the CE routers.
Our CE routers advertise routes to the PE routers who redistribute it into BGP so they become VPNv4 routes.
These VPNv4 routes are exchanged from one PE router to another. Once a PE router receives a VPNv4 route
and redistributes it into OSPF, how does it know what LSA type to use and to what area the prefix belongs?
Also, how is it possible that redistributed routes show up as inter-area routes?
OSPF works a bit different when we use it as the PE-CE routing protocol, I’ll give you the short version here
but if you want to know all details you can check RFC 4577.
Both of our customer sites are using OSPF area 0, normally it’s impossible to have two backbone areas unless
you connect them to each other with a virtual link. When we use MPLS L3 VPN, the service provider network
is seen by OSPF as the superbackbone:[teaser]
This allows us to use area 0 on multiple sites without using virtual links, the superbackbone connects everything
together. If you look on the CE routers you can see that they see the PE routers as ABR routers:
Page 101 of 177
CE1#show ip ospf database | begin Summary
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum

5.5.5.5 192.168.12.2 1208 0x80000001 0x00C26C
192.168.45.0 192.168.12.2 1208 0x80000001 0x00FCB0
CE2#show ip ospf database | begin Summary
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum

1.1.1.1 192.168.45.4 1223 0x80000001 0x008794
192.168.12.0 192.168.45.4 1223 0x80000001 0x007536
Above you can see that 192.168.12.2 (PE1) and 192.168.45.4 (PE2) are seen as ABR routers by the CE routers.
The other question we still have to answer is how do the PE routers know to which area a prefix belongs and
which LSA type to use when we redistribute a VPNv4 route back into OSPF for the customer?
Our PE routers need something to tell other PE routers which area and LSA type to use. We use two additional
BGP extended communities for this:
 OSPF Domain Identifier: the domain ID is used to identify from what OSPF instance the route was redistributed.
 OSPF Route Type: the route type is used to identify what LSA we should use:
o Area number: the number of the area or 0 when it’s an external route.
o Route Type: intra-area, inter-area, external, NSSA route.
Here’s how you can see the OSPF domain identifier:
PE1#show ip ospf 2
Routing Process "ospf 2" with ID 192.168.12.2
Domain ID type 0x0005, value 0.0.0.2
Start time: 6d05h, Time elapsed: 17:07:02.960
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 1587)
Connected to MPLS VPN Superbackbone, VRF CUSTOMER
PE2#show ip ospf 2
Routing Process "ospf 2" with ID 192.168.45.4
Domain ID type 0x0005, value 0.0.0.2
Start time: 6d22h, Time elapsed: 00:00:20.812
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 1587)
Connected to MPLS VPN Superbackbone, VRF CUSTOMER
Above you can see the OSPF process for the customer VRF. The domain ID type is 0x0005 which is a default
value on Cisco devices. The value is 0.0.0.2 because Cisco IOS uses the OSPF process ID for this.
Now let’s take a look at the VPNv4 routes that our PE routers have created:
PE1#show bgp vpnv4 unicast all 1.1.1.1/32

Page 102 of 177
1
Local
192.168.12.1 from 0.0.0.0 (3.3.3.3)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:192.168.12.2:0
mpls labels in/out 16/nolabel
PE2#show bgp vpnv4 unicast all 5.5.5.5/32
1
Local
192.168.45.5 from 0.0.0.0 (192.168.34.4)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:192.168.45.4:0
mpls labels in/out 16/nolabel
Above you can see the OSPF domain ID which is exactly the same on both routers since I used the same OSPF
process ID (2). The route type can be read like this:
 Area: 0.0.0.0
 LSA Type: 2
 Options: 0
Don’t confuse the RT (route target) with the OSPF RT (route type). They use the same two letters which makes it easy to
confuse the two…
When the PE router redistributes a VPNv4 route into OSPF, it will check the domain ID and route type.
When the domain ID is the same then a LSA type 1, 2 or 3 will be redistributed as a LSA type 3. LSA type 5 or
7 will always remain the same.
If the domain ID is different then LSA type 1, 2 or 3 will always be redistributed as external prefixes. Let’see if
this is true…I can easily test this by changing the OSPF process ID on one of the PE routers since this will
change the domain ID:
PE2(config)#no router ospf 2

PE2(config-router)#redistribute bgp 234 subnets

PE2(config-router-af)#redistribute ospf 22
By changing the OSPF process ID, we have a different domain ID on PE2. Here’s the result:
CE1#show ip route ospf | include O E2

O E2 5.5.5.5 [110/2] via 192.168.12.2, 00:01:22, FastEthernet0/0
Page 103 of 177

O E2 192.168.45.0/24 [110/1] via 192.168.12.2, 00:01:22, FastEthernet0/0
CE2#show ip route ospf | include O E2
O E2 1.1.1.1 [110/2] via 192.168.45.4, 00:02:11, FastEthernet0/0
O E2 192.168.12.0/24 [110/1] via 192.168.45.4, 00:02:11, FastEthernet0/0
Instead of O IA entries you now see O E2 entries. You can see that the domain ID has changed below:
PE1#show bgp vpnv4 unicast all 5.5.5.5/32 | include DOMAIN

PE2#show bgp vpnv4 unicast all 1.1.1.1/32 | include DOMAIN
That’s it for now, that concludes our basis MPLS VPN L3 PE-CE OSPF configuration.
Conclusion
In this lesson you have seen how to configure OSPF as the PE-CE routing protocol over a MPLS L3 VPN
network and how it deals with different LSA types. There is more to explain however…for example, if we have
a backup link between the customer sites where we use OSPF then we might run into issues.
If we configure OSPF area 0 on the backup link then our CE routers will always prefer these intra-area prefixes
over the inter-area prefixes that our MPLS VPN network offers. There is a solution for this which is called the
OSPF sham link.
Another issue with this scenario is loop prevention. Theoretically, OSPF routes could be redistributed from
OSPF into BGP and back into OSPF. This is something I’ll also demonstrate in another lesson.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
!
ip vrf CUSTOMER
rd 1:1
Page 104 of 177

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
!
router ospf 2 vrf CUSTOMER
redistribute bgp 234 subnets
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
!
Page 105 of 177
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.45.4 255.255.255.0
duplex auto
speed auto
!
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
Page 106 of 177
ip address 192.168.45.5 255.255.255.0
duplex auto
speed auto
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
MPLS Layer 3 VPN PE-CE OSPF Sham Link

OSPF Sham Links are required when you try to use a backdoor link between two CE routers in an MPLS VPN
PE CE scenario where you use OSPF as the PE-CE routing protocol. This is best explained with an example,
take a look at the following topology:
Above we have an MPLS VPN topology where we use OSPF as the PE-CE routing protocol. CE1 and CE2
each have a loopback interface that is advertised in OSPF area 0. Right now, the MPLS backbone is the only
way for the CE routers to reach each other.
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
Page 107 of 177

ip address 192.168.12.1 255.255.255.0
!
no ip address
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
no ip address
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
Page 108 of 177
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
Page 109 of 177
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
Let’s take a look at the routing tables of our CE routers:

O IA 5.5.5.5 [110/3] via 192.168.12.2, 00:09:22, GigabitEthernet0/1
O IA 192.168.45.0/24 [110/2] via 192.168.12.2, 00:09:22, GigabitEthernet0/1

The CE routers see each other’s loopback interfaces as an inter-area route through the OSPF “super
backbone”. Let’s try a traceroute just to be sure that our CE routers can reach each other:
CE1#traceroute 5.5.5.5 source 1.1.1.1

1 192.168.12.2 5 msec 7 msec 5 msec
4 192.168.45.5 9 msec 10 msec *
Configuration
Backdoor Link
Time to mess things up. Let’s add a backdoor link between CE1 and CE2. This could be a backup link that you
want to use in case the MPLS VPN provider has issues:
Page 110 of 177

Let’s enable OSPF on this interface and advertise it in area 0:
The total cost through the MPLS VPN network is 4. Let’s increase the metric for our backdoor link to 100:
CE1 & CE2

(config)#interface GigabitEthernet 0/2
(config-if)#ip ospf cost 100
Let’s see which interface our CE routers now want to use:

O 5.5.5.5 [110/101] via 192.168.15.5, 00:00:22, GigabitEthernet0/2
O 192.168.45.0/24 [110/101] via 192.168.15.5, 00:00:22, GigabitEthernet0/2

O 1.1.1.1 [110/101] via 192.168.15.1, 00:00:27, GigabitEthernet0/2
O 192.168.12.0/24 [110/101] via 192.168.15.1, 00:00:27, GigabitEthernet0/2
Despite the higher cost, CE1 and CE2 prefer the backdoor link. This is because OSPF always prefers intra-
area routes over inter-area routes.

1 192.168.15.5 7 msec 4 msec *
OSPF Sham Link
The only way to fix this is to advertise the routes that are learned through the MPLS VPN network as intra-area
routes. We can do this with the OSPF sham link. The sham link is a logical link, similar to a virtual link. It
allows you to create a point-to-point connection between the two PE routers. The PE routers are then able to
flood LSAs across the MPLS VPN backbone. You don’t have to configure anything on the CE routers.
The sham link is established between two IP addresses that have to be in the VRF of the customer. To achieve
this, we will create a new loopback interface on each PE router which is advertised in BGP:
Page 111 of 177
 PE1: 22.22.22.22/32
 PE2: 44.44.44.44/32
Let’s start with PE1:
Let’s advertise this IP address in BGP:[teaser]

PE1(config-router-af)#network 22.22.22.22 mask 255.255.255.255
Now we can configure the sham link. You have to configure a source and destination address, the cost is
optional:

PE1(config-router)#area 0 sham-link 22.22.22.22 44.44.44.44 cost 10
Let’s do the same thing on PE2:

PE2(config-router-af)#network 44.44.44.44 mask 255.255.255.255

PE2(config-router)#area 0 sham-link 44.44.44.44 22.22.22.22 cost 10
That’s all we have to configure.
Verification
After a few seconds, you will see that a new OSPF neighbor adjacency is established between the PE routers:
PE1#
%OSPF-5-ADJCHG: Process 2, Nbr 192.168.45.4 on OSPF_SL0 from LOADING to FULL, Loading
Done
PE2#
%OSPF-5-ADJCHG: Process 2, Nbr 192.168.12.2 on OSPF_SL0 from LOADING to FULL, Loading
Done
There is also a show command we can use to take a closer look at the sham link:
PE1#show ip ospf sham-links

Sham Link OSPF_SL0 to address 44.44.44.44 is up
Area 0 source address 22.22.22.22
Run as demand circuit
Page 112 of 177

DoNotAge LSA allowed. Cost of using 10 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:07
Adjacency State FULL (Hello suppressed)
Index 1/2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
So, how does this affect CE1 and CE2? Let’s take a look:

Last update from 192.168.12.2 on GigabitEthernet0/1, 00:01:59 ago
* 192.168.12.2, from 5.5.5.5, 00:01:59 ago, via GigabitEthernet0/1
As you can see above, the CE routers now prefer the MPLS VPN backbone and the type has changed from
inter-area to intra-area. Since the cost (4) through the MPLS network is lower, this link is now prefered over the
backbone link. Just to be sure, let’s try one more traceroute:

1 192.168.12.2 9 msec 13 msec 5 msec
4 192.168.45.5 9 msec 10 msec *
That’s looking good! That’s all there is to it.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip address 192.168.15.1 255.255.255.0
ip ospf cost 100
!
Page 113 of 177
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.15.0 0.0.0.255 area 0
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
ip address 192.168.15.5 255.255.255.0
ip ospf cost 100
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.15.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
Page 114 of 177
ip address 22.22.22.22 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
area 0 sham-link 22.22.22.22 44.44.44.44
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
network 22.22.22.22 mask 255.255.255.255
redistribute ospf 2
exit-address-family
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface Loopback1
ip address 44.44.44.44 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
Page 115 of 177
ip address 192.168.34.4 255.255.255.0
!
area 0 sham-link 44.44.44.44 22.22.22.22
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
network 44.44.44.44 mask 255.255.255.255
redistribute ospf 2
exit-address-family
!
end
Conclusion
You have now learned why we need OSPF sham links and how to configure them:
 OSPF prefers intra-area routes over inter-area routes so if you have a backdoor link in the same area,
this link will always be preferred.
 A sham link is a logical point-to-point connection between two PE routers. It allows LSAs to be flooded
over the MPLS VPN backbone.
 The sham link requires IP addresses that are in the VRF of the customer. It’s best to create two new
loopback interfaces for this and advertise them in BGP so the PE routers learn about each others
loopbacks.
 The sham link is configured with the area X sham-link command where you specify a source and
destination IP address. The cost is optional but might be required to ensure the total cost through the
MPLS backbone is lower than the total cost through the backdoor link.
If you want to know more, you can find more details in RFC 4577.
VRF Lite Route Leaking

Page 116 of 177
VRF Lite allows us to use multiple routing tables on a router, creating a separation similar to VLANs on
switches. Each interface on the router can be assigned to a different VRF. However, what if you have some
shared services or routes that should be shared between multiple VRFs?
It is possible to “leak” routes from one VRF into another. There are two options to achieve this:
 Static Routes
 MP-BGP
In this lesson, I’ll show you how to configure both options.
Configuration
This is the topology I will use:
We have an ISP router that is connected to two customers. For each customer, we use a different VRF:
 VRF “RED” for Red1

 VRF “BLUE” for Blue1
hostname ISP
!
ip vrf BLUE
!
ip vrf RED
!
ip cef
!
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
end
Page 117 of 177

hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
end
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
end
With the configuration above, we only have connectivity within a VRF. What if we want connectivity between
VRF RED and BLUE?
Static Routes
Let’s start with the static routes option. According to this Cisco document, static routes directly between VRFs
are not supported. What does work, is routing traffic from a VRF to the global routing table and then to the
destination VRF. One advantage of using static routes is that you can configure exactly which routes should be
reachable without the hassle of configuring MP-BGP.
I’ll show you how to get connectivity between 1.1.1.1/32 in VRF RED and 3.3.3.3/32 in VRF BLUE.
Configuration
First, let’s create a default route on the Red1 and Blue1 routers so that they send all unknown traffic towards the
ISP router:
Red1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

Blue1(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2
In each VRF, we add a static route for the destination in the other VRF that we want to reach. This static route
is pointed to the global routing table:
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3 global

ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1 global
Page 118 of 177

Let me explain what you see above:
 In VRF RED, we have a static route to destination 3.3.3.3/32 that uses next hop IP address 192.168.23.3 in the
global routing table.
 In VRF BLUE, we have a static route for destination 1.1.1.1/32 that uses next hop IP address 192.168.12.1 in the
global routing table.
These two static routes will route traffic from the VRFs to the global routing table. These next hop addresses,
however, are not in the global routing table but in the VRFs.
We need to add two static routes in the global routing table of the ISP router so that it knows how to reach the
next hop addresses:
ISP(config)#ip route 192.168.12.1 255.255.255.255 GigabitEthernet 0/1

ISP(config)#ip route 192.168.23.3 255.255.255.255 GigabitEthernet 0/2
That completes our configuration.
Verification
Let’s look at the routing tables of our ISP router. Here’s the routing table of VRF RED:
ISP#show ip route vrf RED static

S 3.3.3.3 [1/0] via 192.168.23.3
Above we see the static route for 3.3.3.3/32 that points to 192.168.23.3. It doesn’t show it, but this static route
points to the global routing table. Here is the route for 1.1.1.1/32 in routing table VRF BLUE:
ISP#show ip route vrf BLUE static

S 1.1.1.1 [1/0] via 192.168.12.1
Here is the global routing table:
ISP#show ip route static

S 192.168.12.1 is directly connected, GigabitEthernet0/1
S 192.168.23.3 is directly connected, GigabitEthernet0/2
Above, we see the entries for the next hop addresses in the global routing table.
The ISP router is now able to route from one VRF into the global routing table and into another VRF. Let’s try
a quick ping:
Red1#ping 3.3.3.3 source 1.1.1.1

Page 119 of 177

!!!!!
Mission accomplished.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.23.2
!
end
hostname ISP
!
ip vrf BLUE
!
ip vrf RED
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
ip route 192.168.12.1 255.255.255.255 GigabitEthernet0/1
ip route 192.168.23.3 255.255.255.255 GigabitEthernet0/2
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1 global
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3 global
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
Page 120 of 177

!
ip route 0.0.0.0 0.0.0.0 192.168.12.2
!
end
MP-BGP
Let’s see how we can get connectivity between the VRFs by using MP-BGP. This is pretty much the same as
MPLS VPN PE CE but without MPLS. We will use MP-BGP to redistribute routes from one VRF into another.
To demonstrate this, I will redistribute static routes that I create on the ISP router into MP-BGP. Of course, you
can also use a routing protocol like OSPF or EIGRP between the ISP and customer routers.
Configuration
Let’s create a default route on the customer routers that point to the ISP:[teaser]
Red1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

Blue1(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2
On the ISP router, I have to do two things under the VRF configuration:
 We need an RD (Route Distinguisher) for each VRF.

 We need an RT (Route Target) and export/import our routes.
This is what we’ll do:
 VRF RED will use RD 1:1 and VRF BLUE uses RD 3:3
 Routes from VRF RED will be exported using RT 1:1
 Routes from VRF BLUE will be exported using RT 3:3
Let’s start with the configuration for VRF RED:
ISP(config)#ip vrf RED

ISP(config-vrf)#rd 1:1
ISP(config-vrf)#route-target export 1:1
ISP(config-vrf)#route-target import 3:3
VRF RED exports its routes with RT 1:1 and imports routes with RT 3:3. Here’s VRF BLUE:
ISP(config)#ip vrf BLUE

ISP(config-vrf)#rd 3:3
ISP(config-vrf)#route-target export 3:3
ISP(config-vrf)#route-target import 1:1
Now we can worry about getting the routes into each other’s VRF. For each VRF, I will create a static route that
points to the loopback 0 interface of the other VRF:
ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1

ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
Page 121 of 177

Now we can redistribute these into MP-BGP. Let’s start a new BGP process. It doesn’t matter what AS number
you use since we won’t have any neighbors. Since I don’t have any IP addresses in my global routing table,
BGP will complain about being unable to pick a router ID so I’ll configure one manually:
ISP(config)#router bgp 2
ISP(config-router)#bgp router-id 2.2.2.2
Under the address-family of each VRF, we have to redistribute two things:
 Static route: this is the static route we just configured for each VRF, it points to the loopback 0 interface of the
other customer router.
 Directly connected route: required because the next hop IP address for the static route is on this network.
ISP(config-router)#address-family ipv4 vrf RED

ISP(config-router-af)#redistribute static
ISP(config-router-af)#redistribute connected
ISP(config-router)#address-family ipv4 vrf BLUE
ISP(config-router-af)#redistribute static
ISP(config-router-af)#redistribute connected
Our static and directly connected routes are now in MP-BGP and will be exported/imported according to the
route-targets we configured.
Verification
Let’s take a look at the VPN routes of each VRF:
ISP#show bgp vpnv4 unicast vrf RED

Route Distinguisher: 1:1 (default for vrf RED)
*> 1.1.1.1/32 192.168.12.1 0 32768 ?
*> 3.3.3.3/32 192.168.23.3 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.23.0 0.0.0.0 0 32768 ?
VRF RED has learned the 3.3.3.3/32 and 192.168.23.0/24 prefixes. Here’s VRF BLUE:
ISP#show bgp vpnv4 unicast vrf BLUE

Route Distinguisher: 3:3 (default for vrf BLUE)
*> 1.1.1.1/32 192.168.12.1 0 32768 ?
*> 3.3.3.3/32 192.168.23.3 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.23.0 0.0.0.0 0 32768 ?
VRF BLUE has the 1.1.1.1/32 and 192.168.12.0/24 prefixes. We can also see these in the routing table of each
VRF:
ISP#show ip route vrf RED bgp

B 3.3.3.3 [20/0] via 192.168.23.3 (BLUE), 00:06:41
Page 122 of 177
B 192.168.23.0/24 is directly connected, 00:08:20, GigabitEthernet0/2
ISP#show ip route vrf BLUE bgp

B 1.1.1.1 [20/0] via 192.168.12.1 (RED), 00:07:23
B 192.168.12.0/24 is directly connected, 00:09:00, GigabitEthernet0/1
Let’s see if we have connectivity between VRF RED and BLUE:
Red1#ping 3.3.3.3 source 1.1.1.1

!!!!!
Excellent, this is working.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.23.2
!
end
hostname ISP
!
ip vrf BLUE
rd 3:3
!
ip vrf RED
rd 1:1
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
Page 123 of 177
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
bgp router-id 2.2.2.2
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-family
!
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2
!
end
Conclusion
You have now learned how to leak routes from one VRF into another:
 How to use static routes to route from a VRF into the global routing table and into another VRF.
 How to use MP-BGP to exchange routes from one VRF into another.
MPLS VPN Extranet Route Leaking

MPLS supports intranet and extranet VPNs:
 MPLS Intranet VPN: this is a VPN where we connect the headquarters, remote sites, branch offices,
etc. from a single company.
 MPLS Extranet VPN: this is a VPN where we extend connectivity from a company to other
parties like customers, suppliers, or partners.
Let me show you a quick example to explain this:

Page 124 of 177
In the topology above, we have a simple MPLS VPN PE-CE topology from a provider that has two customers:
 Customer Red
 Customer Blue
Each customer has two sites. On our PE routers, we use the following configuration for our VRFs:
PE1#show run | begin ip vrf

ip vrf BLUE
rd 2:2
!
ip vrf RED
rd 1:1
PE2#show run | begin ip vrf
ip vrf BLUE
rd 2:2
!
ip vrf RED
rd 1:1
Here’s what you see above:
 VRF RED uses route-target 1:1 to import and export its routes.
 VRF BLUE uses route-target 2:2 to import and export its routes.
With the configuration above, both customers are only able to communicate with their own sites. It’s impossible
to send traffic from RED to BLUE or vice versa. This is what we call an MPLS intranet VPN.
Does this mean it’s impossible for customers RED and BLUE to communicate with each other at all?
Page 125 of 177

This is no problem at all…the only thing we have to do is leak some routes from one VRF to another. This
allows the different sites to learn about each others’ routes and they will be able to communicate with each
other. This is called an MPLS VPN Extranet (Route Leaking).
Configuration
Let’s see how this works. To demonstrate this, I will use the topology I just showed you and we will leak some
routes between customer site RED-CE1 and BLUE-CE2. Here it is:
This is a basic MPLS VPN PE CE setup with two VRFs. We use OSPF as the PE-CE routing protocol.
hostname BLUE-CE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 126 of 177

ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
end
hostname BLUE-CE2
!
ip cef
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 192.168.57.7 255.255.255.0
!
router ospf 1
network 7.7.7.7 0.0.0.0 area 0
network 192.168.57.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
mpls ip
!
ip address 192.168.45.4 255.255.255.0
mpls ip
!
router ospf 345
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf BLUE
rd 2:2
!
ip vrf RED
rd 1:1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
Page 127 of 177
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
router ospf 1 vrf RED
network 192.168.13.0 0.0.0.255 area 0
!
router ospf 2 vrf BLUE
network 192.168.23.0 0.0.0.255 area 0
!
router ospf 345
network 3.3.3.3 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 345
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
redistribute ospf 1
exit-address-family
!
end
hostname PE2
!
ip vrf BLUE
rd 2:2
!
ip vrf RED
Page 128 of 177
rd 1:1
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
mpls ip
!
ip address 192.168.56.5 255.255.255.0
!
ip address 192.168.57.5 255.255.255.0
!
network 192.168.56.0 0.0.0.255 area 0
!
network 192.168.57.0 0.0.0.255 area 0
!
router ospf 345
network 5.5.5.5 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 345
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
redistribute ospf 1
exit-address-family
!
end
hostname RED-CE1
!
ip cef
Page 129 of 177
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.13.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.13.0 0.0.0.255 area 0
!
end
hostname RED-CE2
!
ip cef
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 192.168.56.6 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 192.168.56.0 0.0.0.255 area 0
!
end
Right now, we have an intranet VPN so each customer only sees their own routes. Here are customer RED’s
routes:
RED-CE1#show ip route ospf


And here we have customer BLUE’s routes:
BLUE-CE1#show ip route ospf


Page 130 of 177

If I want to let RED-CE1 and BLUE-CE2 talk with each other, I’ll have to export and import some routes. I’ll
use a new route-target (1:2) for this. Let’s do this step-by-step…first, let’s export the routes from VRF RED on
PE1:[teaser]
PE1(config)#ip vrf RED

The next thing I have to do is import route-target 1:2 on PE2 in VRF BLUE:
PE2(config)#ip vrf BLUE

Let’s see how this influences BLUE-CE2:

O E2 1.1.1.1 [110/2] via 192.168.57.5, 00:00:34, GigabitEthernet0/1
O E2 192.168.13.0/24 [110/1] via 192.168.57.5, 00:00:34, GigabitEthernet0/1
As you can see above, BLUE-CE2 has learned the routes from RED-CE1. This router is now able to send traffic
to RED-CE1 but there will be no return traffic until RED-CE1 learns about the routes from BLUE-CE2. Let’s
fix this, I’ll export the routes from VRF BLUE on PE2 with route-target 2:1 and will import these on PE1:
PE2(config)#ip vrf BLUE

PE1(config)#ip vrf RED
RED-CE1 will now learn the routes that originated in BLUE-CE2:

O E2 7.7.7.7 [110/2] via 192.168.13.3, 00:00:20, GigabitEthernet0/1
O E2 192.168.57.0/24 [110/1] via 192.168.13.3, 00:00:20, GigabitEthernet0/1
Let’s do a quick test:
RED-CE1#ping 7.7.7.7 source 1.1.1.1

!!!!!
Excellent, this is working. By leaking these routes between two VRFs, we created an MPLS VPN extranet.
Page 131 of 177

hostname BLUE-CE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
end
hostname BLUE-CE2
!
ip cef
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 192.168.57.7 255.255.255.0
!
router ospf 1
network 7.7.7.7 0.0.0.0 area 0
network 192.168.57.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.34.4 255.255.255.0
mpls ip
!
ip address 192.168.45.4 255.255.255.0
mpls ip
!
router ospf 345
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf BLUE
rd 2:2
Page 132 of 177
!
ip vrf RED
rd 1:1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
ip address 192.168.13.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
network 192.168.13.0 0.0.0.255 area 0
!
network 192.168.23.0 0.0.0.255 area 0
!
router ospf 345
network 3.3.3.3 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 345
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
redistribute ospf 1
exit-address-family
!
end
Page 133 of 177
hostname PE2
!
ip vrf BLUE
rd 2:2
!
ip vrf RED
rd 1:1
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
mpls ip
!
ip address 192.168.56.5 255.255.255.0
!
ip address 192.168.57.5 255.255.255.0
!
network 192.168.56.0 0.0.0.255 area 0
!
network 192.168.57.0 0.0.0.255 area 0
!
router ospf 345
network 5.5.5.5 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
router bgp 345
!
address-family ipv4
exit-address-family
!
exit-address-family
!
Page 134 of 177
redistribute ospf 2
exit-address-family
!
redistribute ospf 1
exit-address-family
!
end
hostname RED-CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 192.168.13.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.13.0 0.0.0.255 area 0
!
end
hostname RED-CE2
!
ip cef
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 192.168.56.6 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 192.168.56.0 0.0.0.255 area 0
!
end
One thing to keep in mind is that right now, all routes are exchanged between RED-CE1 and BLUE-CE2. If you want to
prevent this, you need to use export maps.
Conclusion
you now learned that MPLS VPN Extranet route leaking means we “leak” routes from one VRF into another
and how to configure this.
Page 135 of 177

MPLS VPN VRF Export Map
When you use the route-target export command for a VRF, it adds the same route-target to all VPN routes.
With an export map, you can use the power of a route-map to decide which VPN routes should get exported and
what route-targets to use.
Let’s look at an example. Consider the following topology:
We have a simple MPLS VPN PE CE topology with a single customer that has two sites. Each site has a router
with two loopback interfaces. Take a look at the VRF configuration of PE1 and PE2:
PE1#show running-config | begin ip vrf

ip vrf CUSTOMER
rd 1:1
ip vrf CUSTOMER
rd 1:1
VPN routes on PE1 are exported with RT 1:1 and PE2 exports its VPN routes with RT 2:2.
With the route-target export command, all VPN routes are exported. There is no way to filter anything. This
means that CE1 and CE2 will learn about each other’s routes that they advertise:
Page 136 of 177


We can see the RT that was added. For example, here’s PE1:
PE1#show ip bgp vpnv4 all 1.1.1.1/32 | include Extended

What if I want to filter some of these VPN routes? Or use a different route-target for some of them? That’s what
we have export maps for…
Configuration
I will use the topology from above to demonstrate the export map. If you want to follow along, you can use my
configurations:
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 11.11.11.11 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
Page 137 of 177

hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
ip address 55.55.55.55 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 55.55.55.55 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 138 of 177

ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
Page 139 of 177
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
Empty Export Map
Let’s start with a simple example. I will create a new route-map that permits everything and sets the route-target
to 3:3:
PE1(config)#route-map EXPORT_MAP permit 10

PE1(config-route-map)#set extcommunity rt 3:3
You activate it under the VRF configuration with the export map command:

PE1(config-vrf)#export map EXPORT_MAP
Let’s look at the result:

As you can see above, it overwrites the RT that is set with the route-target export command. All routes now
have an RT of 3:3.
Export Map with Prefix-list
The output we just saw might not be what we are looking for. Let’s try something else. What if we only want to
set the RT to 3:3 for the 1.1.1.1/32 prefix from CE1?
We can do this with an access-list or prefix-list. I’ll use a prefix-list:
Page 140 of 177

PE1(config)#ip prefix-list CE1_L0 permit 1.1.1.1/32
PE1(config-route-map)#match ip address prefix-list CE1_L0
Here’s what the VPN routes now look like on PE1:

This is looking better. 1.1.1.1/32 has the RT of 3:3 and all other VPN routes still have RT 1:1 that was set with
the route-target export command.
Because of the new RT, CE2 no longer has 1.1.1.1/32:

% Network not in table
If we want CE2 to have this route, we’ll have to import the new RT on PE2:

Now it’s back:

Known via "ospf 1", distance 110, metric 3, type inter area
Export Map Additive
In the previous two examples, the export map has overwritten our RT. It’s also possible to add an additional RT.
You only have to add the additive parameter in your route-map:[teaser]

PE1(config-route-map)#set extcommunity rt 3:3 additive
The VPN route now has two RTs:

Extended Community: RT:1:1 RT:3:3 OSPF DOMAIN ID:0x0005:0x000000020200
Export Map as Filter
What if we want to filter certain VPN routes? Because of the route-target export command, all VPN routes get a
default RT. Let’s get rid of this command so that we can control everything with an export map:
Page 141 of 177

PE1(config-vrf)#no route-target export 1:1
Let’s see how this influences our VPN routes:

Extended Community: OSPF DOMAIN ID:0x0005:0x000000020200
Because of the export map that only matches 1.1.1.1/32, only this route has an RT. The other two routes don’t
have an RT anymore.
Let’s try something else…let’s say we have the following requirements:
 1.1.1.1/32 needs RT 3:3

 11.11.11.11/32 should not receive an RT.
 All other routes should get RT 1:1.
With our export map, it’s easy to configure this. Let’s add a prefix-list that matches 11.11.11.11/32:
Now I add two additional entries in the export map:
PE1(config)#route-map EXPORT_MAP deny 20


PE1(config-route-map)#set extcommunity rt 1:1
Entry 20 denies everything that matches prefix-list CE1_L1 and has no set parameter. Entry 30 sets the RT to
1:1 for everything else.
Here’s the end result:

1.1.1.1/32 has an RT of 3:3. Let’s check 11.11.11.11/32:

This prefix now doesn’t have any RT. All other routes will have a default RT of 1:1

Since I configured PE2 to import RT 1:1 and RT 3:3, we will see the following prefixes on CE2:
Page 142 of 177

That’s all there is to it.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 11.11.11.11 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
ip address 55.55.55.55 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 55.55.55.55 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
Page 143 of 177

!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
export map EXPORT_MAP
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
Page 144 of 177
!
ip prefix-list CE1_L0 seq 5 permit 1.1.1.1/32
!
!
route-map EXPORT_MAP permit 10
match ip address prefix-list CE1_L0
set extcommunity rt 3:3 additive
!
route-map EXPORT_MAP deny 20
!
route-map EXPORT_MAP permit 30
set extcommunity rt 1:1
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
Page 145 of 177
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
Conclusion
You have now learned how to use export maps to selectively decide which prefixes should get a certain RT and
how export maps work together with the route-target export command.
MPLS VPN VRF Import Map

With the route-target command for VRFs, the RT (Route Target) is added for all VPN routes. If you don’t want
this, you can select which routes you want to import or export using a route-map. In the MPLS VPN VRF
export map lesson, I explained how the export map works. This time we’ll take a look at the import map.
Let’s take a look at the following topology:
This is a standard MPLS VPN PE CE topology with a customer that uses OSPF on two sites. Each CE router
has two loopback interfaces. Here is the VRF configuration from PE1 and PE2:
Page 146 of 177

ip vrf CUSTOMER
rd 1:1
ip vrf CUSTOMER
rd 1:1
VPN routes on PE1 are exported with RT 1:1 and PE2 exports its VPN routes with RT 2:2.
With the route-target export command, all VPN routes are exported. There is no way to filter anything. This
means that CE1 and CE2 will learn about each other’s routes that they advertise:


Let’s take a closer look at PE2, and see which VPN routes it has received from PE1:

These VPN routes are installed in the VRF of our customer:
PE2#show ip route vrf CUSTOMER bgp

B 1.1.1.1 [200/2] via 2.2.2.2, 00:02:39
B 11.11.11.11 [200/2] via 2.2.2.2, 00:00:26
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:00:26
If you want to restrict the routes that PE2 installs in the VRF then you could use an export-map on PE1.
However, what if I want to control this from PE2?
That’s when the import map becomes useful…
Page 147 of 177

Configuration
I’ll use the topology that I just showed you.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 11.11.11.11 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
ip address 55.55.55.55 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 55.55.55.55 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
Page 148 of 177
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname PE2
!
Page 149 of 177
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
Let’s configure PE2 so that CE2 only learns 1.1.1.1/32. The other two routes should be filtered.
I can do this with a prefix-list and a route-map:
PE2(config)#route-map IMPORT_MAP permit 10

The route-map has a single permit and only matches 1.1.1.1/32. Let’s activate it:

Page 150 of 177
PE2(config-vrf)#import map IMPORT_MAP
Let’s see how this influences PE2:

The VPN routes are still there…nothing changes. However, what does change is the routing table for our
VRF:[teaser]
PE2#show ip route vrf CUSTOMER bgp
Routing Table: CUSTOMER

B 1.1.1.1 [200/2] via 2.2.2.2, 00:04:41
We now only find 1.1.1.1/32 here, the other two routes are gone, excellent!
The route-map I just used is pretty simple… it only checks for our prefix-list. What if there are two VPN routes
for prefix 1.1.1.1/32?
In that case, it’s best to include a match for the route-target as well. This allows you to specify exactly which
VPN route you want to import. PE1 uses RT 1:1 so let’s filter on that with a community-list:
PE2(config)#ip extcommunity-list standard CUSTOMER permit rt 1:1
And add it to the route-map:
PE2(config)#route-map IMPORT_MAP permit 10

PE2(config-route-map)#match extcommunity CUSTOMER
We now have a specific match for RT 1:1 and the 1.1.1.1/32 route. That’s all there is to it.
hostname CE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
Page 151 of 177
network 1.1.1.1 0.0.0.0 area 0
network 11.11.11.11 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
ip address 55.55.55.55 255.255.255.255
!
ip address 192.168.45.5 255.255.255.0
!
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
network 55.55.55.55 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 0
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
mpls ip
!
ip address 192.168.34.3 255.255.255.0
mpls ip
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip vrf CUSTOMER
rd 1:1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
Page 152 of 177
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
network 192.168.12.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
end
hostname PE2
!
ip vrf CUSTOMER
rd 1:1
import map IMPORT_MAP
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 192.168.45.4 255.255.255.0
!
ip address 192.168.34.4 255.255.255.0
!
Page 153 of 177
network 192.168.45.0 0.0.0.255 area 0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
redistribute ospf 2
exit-address-family
!
ip extcommunity-list standard CUSTOMER permit rt 1:1
!
!
route-map IMPORT_MAP permit 10
match extcommunity CUSTOMER
!
end
Conclusion
You have now learned how to use VRF import maps to select which VPN routes you want to import into a
certain VRF. You can use a route-map to filter on the route-target and prefix that you want to import. The
import map doesn’t influence the VPN routes on the PE router, but it does define which routes are imported into
the VRF.
Any Transport Over MPLS (AToM)

Any Transport over MPLS (AToM) will transport layer 2 frames over a MPLS (Multiprotocol Label Switching)
network. This will allow service providers to connect layer 2 networks of customers transparently by using their
MPLS backbone. AToM can transport the following:
 ATM AAL5
 ATM Cell Relay
Page 154 of 177
 Ethernet
 Frame Relay
 PPP
 HDLC
I will give you an example how to configure AToM to transport Ethernet over the MPLS backbone, we will use
the following topology to do this:
Above you see a small MPLS backbone that consists of the PE1, P and PE2 router. This ISP only has one
customer that has a HQ and Branch. The customer wants to have the HQ and Branch router to be in the same
layer 2 segment.
Configuration
First we will enable OSPF to advertise the loopback interfaces, these will be used as the router ID for MPLS
LDP:
Now we will enable MPLS LDP on the interfaces connecting the PE1, P and PE2 routers:
PE1(config)#interface fastEthernet 0/1

P(config)#interface fastEthernet 0/0
P(config)#interface fastEthernet 0/1

Page 155 of 177
Just to be sure let’s verify that we have LDP neighbors:

That seems to be the case! Now we can configure AToM so that the HQ and Branch router are able to reach
each other:
[teaser]

PE1(config-if)#xconnect 3.3.3.3 13 encapsulation mpls
PE2(config-if)#xconnect 1.1.1.1 13 encapsulation mpls
We need to use the xconnect command between PE1 and PE2. The VC ID (13) has to be the same on both
routers.
Verification
First we will check our LDP peers:
PE1#show mpls ldp neighbor 3.3.3.3

TCP connection: 3.3.3.3.64567 - 1.1.1.1.646
Up time: 00:05:19
Targeted Hello 1.1.1.1 -> 3.3.3.3, active, passive
192.168.23.3 3.3.3.3
PE2#show mpls ldp neighbor 1.1.1.1
TCP connection: 1.1.1.1.646 - 3.3.3.3.64567
Up time: 00:05:38
Targeted Hello 3.3.3.3 -> 1.1.1.1, active, passive
192.168.12.1 1.1.1.1
PE1 and PE2 are LDP neighbors, now we’ll verify that they are transporting our Ethernet traffic:
PE1#show mpls l2transport binding

Destination Address: 3.3.3.3, VC ID: 13
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Page 156 of 177
CV Type: LSPV [2]
PE2#show mpls l2transport binding
Destination Address: 1.1.1.1, VC ID: 13
Local Label: 19
CV Type: LSPV [2]
Remote Label: 19
CV Type: LSPV [2]
A label has been assigned to this virtual circuit, you can see it says “Ethernet”. There’s another useful command
that lets us check the AToM configuration:
PE1#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status

------------- -------------------------- --------------- ---------- ----------
Fa0/0 Ethernet 3.3.3.3 13 UP
PE2#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status

------------- -------------------------- --------------- ---------- ----------
Fa0/1 Ethernet 1.1.1.1 13 UP
Above you have a nice overview with the interfaces, transport type, virtual circuit ID and the status. Everything
is looking good to let’s give it a test drive:
HQ#ping 172.16.1.2

!!!!!
Our ping is successful, we can verify the number of packets that have been sent as following:
PE1#show mpls l2transport vc detail

Local interface: Fa0/0 up, line protocol up, Ethernet up
Destination address: 3.3.3.3, VC ID: 13, VC status: up
Next hop: 192.168.12.2
Output interface: Fa0/1, imposed label stack {17 19}
Create time: 00:09:46, last status change time: 00:09:41
Signaling protocol: LDP, peer 3.3.3.3:0 up
MPLS VC labels: local 19, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 84, send 83
byte totals: receive 9445, send 9045
packet drops: receive 0, seq error 0, send 0
Page 157 of 177
That’s how you configure AToM to transport Ethernet.
hostname Branch
!
ip cef
!
ip address 172.16.1.2 255.255.255.0
!
no ip address
!
end
hostname HQ
!
ip cef
!
ip address 172.16.1.1 255.255.255.0
!
login
transport input all
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 192.168.12.2 255.255.255.0
mpls ip
!
ip address 192.168.23.2 255.255.255.0
mpls ip
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
network 2.2.2.2 0.0.0.0 area 0
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
no ip address
xconnect 3.3.3.3 13 encapsulation mpls
!
Page 158 of 177
ip address 192.168.12.1 255.255.255.0
mpls ip
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
IPv6 over MPLS 6PE/6VPE

6PE and 6VPE allow us to run IPv6 over an IPv4-only MPLS core where we use dual stack PE routers.
On the PE routers, we use MP-BGP to exchange IPv6 prefixes and the LSP (Label Switched Path) is based on
IPv4. This allows service providers to offer IPv6 to their customers without making major changes to the core
of their MPLS network.
To achieve this, a small modification to MP-BGP was needed. The LSP between the PE routers is based on
IPv4 so the next hop addresses are IPv4 addresses. When a PE router advertises an IPv6 prefix through MP-
BGP to another PE router, it embeds the IPv4 address in the IPv6 next hop address so that a PE router knows
which IPv4 address (and thus which label) to use to get to the other PE router.
 6PE uses the global IPv6 routing table on the PE routers.

 6VPE uses VRFs on the PE routers (MPLS VPN).
In this lesson, I’ll show you how to configure 6PE and 6VPE.
Configuration
Here is the topology we will use:
Page 159 of 177

Above, we have a service provider in AS234 with two PE routers and one P router, the MPLS core is based on
IPv4. The SP has a customer that is ready to use IPv6. On each CE router, there is a loopback with an IPv6
address. Between the PE-CE routers, we are going to use MP-BGP to advertise those IPv6 prefixes so that we
have connectivity between CE1 and CE2.
hostname CE1
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
Page 160 of 177

ip address 10.255.1.147 255.255.0.0
!
ipv6 address 2001:DB8:0:45::5/64
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
end
hostname PE2
!
ip cef
!
interface Loopback0
Page 161 of 177

ip address 4.4.4.4 255.255.255.255
!
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
end
With the configuration above, I have an LSP between PE1 and PE2. These two PE routers are MP-BGP
neighbors:


4.4.4.4 4 234 65 65 1 0 0 00:55:23 0

2.2.2.2 4 234 66 66 1 0 0 00:55:59 0
We can see the transport labels that are used between PE1 (2.2.2.2) and PE2 (4.4.4.4):

16 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.23.3
17 Pop Label 192.168.34.0/24 0 Gi0/2 192.168.23.3
18 17 4.4.4.4/32 0 Gi0/2 192.168.23.3
16 Pop Label 2.2.2.2/32 8361 Gi0/1 192.168.23.2
17 Pop Label 4.4.4.4/32 8415 Gi0/2 192.168.34.4
16 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.34.3
17 16 2.2.2.2/32 0 Gi0/2 192.168.34.3
18 Pop Label 192.168.23.0/24 0 Gi0/2 192.168.34.3
Now let’s see if we can get IPv6 traffic over this network.
Page 162 of 177

6PE
Let’s start with 6PE, this is where we use the global IPV6 routing table on the PE routers.
PE Routers
Let’s start with PE1. There are a couple of things I need to do:
 Configure the CE1 router as a neighbor.

 Activate the CE1 router under the IPv6 address-family.
 Activate the PE2 router under the IPv6 address-family.
 Send labels for IPv6 prefixes to the PE2 router.
Let’s configure all of this:
PE1(config)#ipv6 unicast-routing

PE1(config-router)#neighbor 2001:DB8:0:12::1 remote-as 1
PE1(config-router-af)#neighbor 2001:DB8:0:12::1 activate
PE1(config-router-af)#neighbor 4.4.4.4 send-label
On the PE2 router, we do the exact same thing:

PE2(config-router)#neighbor 2001:DB8:0:45::5 remote-as 5
PE2(config-router-af)#neighbor 2.2.2.2 send-label
This completes the configuration of the PE routers.
CE Routers
The configuration of the CE routers is pretty straightforward. We configure MP-BGP for IPv6 and advertise the
IPv6 prefix on the loopback interface. Let’s start with CE1:
CE1(config)#ipv6 unicast-routing
CE1(config-router)#bgp router-id 1.1.1.1
CE1(config-router)#neighbor 2001:DB8:0:12::2 remote-as 234
CE1(config-router)#address-family ipv6
CE1(config-router-af)#neighbor 2001:DB8:0:12::2 activate
CE1(config-router-af)#network 2001:DB8:1:1::1/128
The configuration of CE2 is the same as CE1:

Page 163 of 177
That completes our configuration.
Verification
Let’s verify our work. Let’s start with the PE routers to see if MP-BGP has exchanged any prefixes:
PE1#show bgp ipv6 unicast


*> 2001:DB8:1:1::1/128
2001:DB8:0:12::1
0 0 1 i
*>i 2001:DB8:5:5::5/128
::FFFF:4.4.4.4 0 100 0 5 i
We see two entries on the PE router. The 2001:DB8:1:1::1/128 prefix we learned from CE1 and the
2001:DB8:5:5::5/128 prefix we learned from PE2. Take a good look at the next hop address for that second
prefix, it has IPv4 address 4.4.4.4 embedded in it.
4.4.4.4 is the IPv4 address on the loopback of the PE2 router which is used for our LSP. This is how the PE1
router is able to figure out what LSP to use if it wants to reach 2001:DB8:5:5::5/128.
Let’s take a closer look at this prefix:
PE1#show bgp ipv6 unicast 2001:DB8:5:5::5/128

BGP routing table entry for 2001:DB8:5:5::5/128, version 6
3
Refresh Epoch 1
5
::FFFF:4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
Above, we see the next hop again but also the VPN label (19) that is used to reach this prefix. You can also use
the show bgp ipv6 unicast labels command to see the labels that are used:
PE1#show bgp ipv6 unicast labels

Page 164 of 177
Network Next Hop In label/Out label
2001:DB8:1:1::1/128
2001:DB8:0:12::1
19/nolabel
2001:DB8:5:5::5/128
::FFFF:4.4.4.4 nolabel/19
With 6PE, prefixes are installed in the global IPv6 routing table. Let’s take a look:
PE1#show ipv6 route bgp

IPv6 Routing Table - default - 5 entries
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FEEA:B8E3, GigabitEthernet0/1
B 2001:DB8:5:5::5/128 [200/0]
via 4.4.4.4%default, indirectly connected
Above, we see the two prefixes in the global IPv6 routing table. Let’s take a look at the PE2 router:
PE2#show bgp ipv6 unicast


*>i 2001:DB8:1:1::1/128
::FFFF:2.2.2.2 0 100 0 1 i
*> 2001:DB8:5:5::5/128
2001:DB8:0:45::5
0 0 5 i
PE2 uses ::FFFF:2:2:2:2 as the next hop address for 2001:DB8:1:1::1/128. That’s the IPv4 address on the
loopback interface of the PE1 router, that is used for the LSP.
Let’s take a closer look at the 2001:DB8:1:1::1/128 prefix:
PE2#show bgp ipv6 unicast 2001:DB8:1:1::1/128

BGP routing table entry for 2001:DB8:1:1::1/128, version 3
3
Refresh Epoch 1
1
::FFFF:2.2.2.2 (metric 3) from 2.2.2.2 (2.2.2.2)
Above, we see the VPN label (19) that is used.
PE2#show bgp ipv6 unicast labels

2001:DB8:1:1::1/128
Page 165 of 177
2001:DB8:5:5::5/128
2001:DB8:0:45::5
19/nolabel
Let’s check the global routing table:
PE2#show ipv6 route bgp

IPv6 Routing Table - default - 5 entries
B 2001:DB8:1:1::1/128 [200/0]
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FEC3:25CB, GigabitEthernet0/1
The PE routers look good, everything we need is there. Let’s take a look at the CE routers:
CE1#show ipv6 route bgp
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE44:53EA, GigabitEthernet0/1
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE4C:A56C, GigabitEthernet0/1
Each CE router has a BGP route. Let’s see if we can ping from one loopback interface to another:
CE1#ping 2001:DB8:5:5::5 source 2001:DB8:1:1::1

Sending 5, 100-byte ICMP Echos to 2001:DB8:5:5::5, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:1:1::1
!!!!!
Our ping is successful, if we want to see the labels then we can use a traceroute:
CE1#traceroute
Protocol [ip]: ipv6
Target IPv6 address: 2001:DB8:5:5::5
Source address: 2001:DB8:1:1::1
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]: 1
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [0]:
Tracing the route to 2001:DB8:5:5::5
1 2001:DB8:0:12::2 7 msec
2 ::FFFF:192.168.23.3 [MPLS: Labels 17/19 Exp 0] 12 msec
3 2001:DB8:0:45::4 [MPLS: Label 19 Exp 0] 9 msec
4 2001:DB8:0:45::5 8 msec
Page 166 of 177

This is looking good. We see the VPN label (19) and the transport label (17) in this output.
hostname CE1
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ip address 10.255.1.146 255.255.0.0
!
ipv6 address 2001:DB8:0:12::1/64
ipv6 enable
!
router bgp 1
neighbor 2001:DB8:0:12::2 remote-as 234
!
address-family ipv4
no neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
ipv6 address 2001:DB8:0:45::5/64
!
router bgp 5
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:5:5::5/128
Page 167 of 177
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
address-family ipv6
neighbor 4.4.4.4 send-label
Page 168 of 177

exit-address-family
!
end
hostname PE2
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
address-family ipv6
neighbor 2.2.2.2 send-label
exit-address-family
!
end
6VPE
Now let’s try the 6VPE configuration. I’ll use the same startup configuration I showed in the beginning of this
lesson.
PE Routers
6VPE uses VRFs so that’s the first thing I am going to configure. We’ll create a VRF called “CUSTOMER”
and use RD 1:1:
PE1(config)#vrf definition CUSTOMER

Page 169 of 177
PE1(config-vrf)#address-family ipv6
PE1(config-vrf-af)#route-target both 1:1

PE1(config-if)#vrf forwarding CUSTOMER
PE1(config-if)#ipv6 address 2001:DB8:0:12::2/64
Make sure IPv6 unicast routing is enabled before you configure MP-BGP:
Now we can configure MP-BGP. I need to enable the VPNv6 address family and activate the PE2 router. We
also need to configure the CE router as a neighbor under the VRF:

PE1(config-router-af)#neighbor 4.4.4.4 send-community extended

PE1(config-router-af)#neighbor 2001:DB8:0:12::1 remote-as 1
Unlike the 6PE configuration, we don’t need to add the “send-label” command since this is already the default
for the VPN address-families. Let’s configure the same on the PE2 router:
PE2(config)#vrf definition CUSTOMER

PE2(config-vrf)#address-family ipv6
PE2(config-vrf-af)#route-target both 1:1

PE2(config-if)#vrf forwarding CUSTOMER
PE2(config-if)#ipv6 address 2001:DB8:0:45::4/64
PE2(config-router-af)#neighbor 2.2.2.2 send-community extended

PE2(config-router-af)#neighbor 2001:DB8:0:45::5 remote-as 5
This completes the configuration of the PE routers.
CE Routers
The CE routers use the same configuration as for 6PE. We need to enable IPv6 unicast routing, enable MP-
BGP, become neighbors with the PE router, and advertise the prefix on the loopback:
Page 170 of 177

We do the same thing on the CE2 router:
That’s all we need.
Verification
Let’s verify our work. Let’s start with the VRFs:
PE1#show vrf ipv6 CUSTOMER

Name Default RD Protocols Interfaces
CUSTOMER 1:1 ipv6 Gi0/1
PE2#show vrf ipv6 CUSTOMER
Name Default RD Protocols Interfaces
CUSTOMER 1:1 ipv6 Gi0/1
We can see that the VRFs support IPv6 and that the GigabitEthernet 0/1 interfaces use our VRF CUSTOMER.
Let’s see if the PE routers have anything in the BGP table for the VRF:


*> 2001:DB8:1:1::1/128
2001:DB8:0:12::1
0 0 1 i
*>i 2001:DB8:5:5::5/128
::FFFF:4.4.4.4 0 100 0 5 i
Page 171 of 177

The output above is similar to what we have seen with the 6PE configuration. The difference is that we now see
the RD that is included with the prefix. The PE1 router uses 4.4.4.4 as the next hop to reach
2001:DB8:5:5::5/128.
Here’s the output of PE2:


*>i 2001:DB8:1:1::1/128
::FFFF:2.2.2.2 0 100 0 1 i
*> 2001:DB8:5:5::5/128
2001:DB8:0:45::5
0 0 5 i
PE2 uses 2.2.2.2 as the next hop to reach 2001:DB8:1:1::1/128.
Let’s take a closer look at those prefixes, see what labels we find:
PE1#show bgp vpnv6 unicast vrf CUSTOMER 2001:DB8:5:5::5/128

BGP routing table entry for [1:1]2001:DB8:5:5::5/128, version 9
2
Refresh Epoch 1
5
::FFFF:4.4.4.4 (metric 3) (via default) from 4.4.4.4 (4.4.4.4)
PE1 uses VPN label 19 for 2001:DB8:5:5::5/128. Here’s PE2:
PE2#show bgp vpnv6 unicast vrf CUSTOMER 2001:DB8:1:1::1/128

BGP routing table entry for [1:1]2001:DB8:1:1::1/128, version 8
2
Refresh Epoch 1
1
::FFFF:2.2.2.2 (metric 3) (via default) from 2.2.2.2 (2.2.2.2)
PE2 uses VPN label 19 to reach 2001:DB8:1:1::1/128. You can also use the show bgp vpnv6 unicast all labels
command to get a quick overview:
Page 172 of 177
PE1#show bgp vpnv6 unicast all labels
Route Distinguisher: 1:1 (CUSTOMER)
2001:DB8:1:1::1/128
2001:DB8:0:12::1
19/nolabel
2001:DB8:5:5::5/128
PE2#show bgp vpnv6 unicast all labels
Route Distinguisher: 1:1 (CUSTOMER)
2001:DB8:1:1::1/128
2001:DB8:5:5::5/128
2001:DB8:0:45::5
19/nolabel
Let’s take a look at the routing tables for the CUSTOMER VRF to see if the prefixes got installed:
PE1#show ipv6 route vrf CUSTOMER bgp
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE75:5CA5, GigabitEthernet0/1
B 2001:DB8:5:5::5/128 [200/0]
PE2#show ipv6 route vrf CUSTOMER bgp
B 2001:DB8:1:1::1/128 [200/0]
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE7A:CAE2, GigabitEthernet0/1
The PE routing tables are filled with the IPv6 prefixes. Let’s check the CE routers:
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE77:CDEB, GigabitEthernet0/1
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE7F:A9E, GigabitEthernet0/1
The CE routers have learned each other’s prefix. Let’s try a quick ping:
CE1#ping 2001:DB8:5:5::5 source 2001:DB8:1:1::1

Sending 5, 100-byte ICMP Echos to 2001:DB8:5:5::5, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:1:1::1
!!!!!
That’s looking good. Here’s a Wireshark capture of an ICMP request from CE1 to CE2:
Page 173 of 177

IPv6 over MPLS 6VPE
We can also see the labels with a traceroute:
CE1#traceroute
Protocol [ip]: ipv6
Target IPv6 address: 2001:DB8:5:5::5
Source address: 2001:DB8:1:1::1
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]: 1
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [0]:
Tracing the route to 2001:DB8:5:5::5
1 2001:DB8:0:12::2 6 msec
2 ::FFFF:192.168.23.3 [MPLS: Labels 17/19 Exp 0] 11 msec
3 2001:DB8:0:45::4 [MPLS: Label 19 Exp 0] 7 msec
4 2001:DB8:0:45::5 12 msec
This is looking good, we see VPN label 19 and transport label 17.
hostname CE1
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ip address 10.255.1.152 255.255.0.0
!
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
!
address-family ipv4
Page 174 of 177
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
ipv6 address 2001:DB8:0:45::5/64
!
router bgp 5
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:5:5::5/128
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
vrf definition CUSTOMER
rd 1:1
!
Page 175 of 177
address-family ipv6
exit-address-family
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
vrf forwarding CUSTOMER
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
hostname PE2
!
vrf definition CUSTOMER
rd 1:1
!
address-family ipv6
exit-address-family
!
ip cef
ipv6 cef
Page 176 of 177

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
vrf forwarding CUSTOMER
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
exit-address-family
!
exit-address-family
!
end
Conclusion
You have now learned how you can run IPv6 over an IPv4-only MPLS core with 6PE and 6VPE:
 The core of the MPLS network is IPv4-only.

 The PE routers are dual stack.
 6PE uses the global IPv6 routing table.
 6VPE uses VRFs.
 How to configure both 6PE and 6VPE.
 How to verify 6PE and 6VPE.
Page 177 of 177

MPLS

Uploaded by

Copyright:

Available Formats

MPLS

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MPLS

Uploaded by

Copyright:

Available Formats

Table of Contents

 Why we use MPLS.

 IGPs (like OSPF and EIGRP)

Having said that, let’s get started!

Why do we need MPLS?

 eBGP between the PE and CE router.

Let’s take a closer look at the solution I described above.

Tunnel between PE routers

That takes care of all internal routing for the ISP.

That takes care of eBGP.

GRE Tunnel Configuration

PE1(config)#router bgp 1234

I’ll do a trace from CE1 to CE2:

CE1#traceroute 5.5.5.5 source loopback 0

Great! Now you might be thinking…so what? Where’s MPLS?

MPLS (Multi Protocol Label Switching).

What does multi protocol label switching mean?

PE1 & PE2

Now we can start with the MPLS configuration.

PE1(config)#router bgp 1234

That takes care of iBGP.

PE1(config)#interface GigabitEthernet 0/2

Let’s try a quick ping between CE1 and CE2:

CE1#ping 5.5.5.5 source loopback 0

P#show ip cef 5.5.5.5

Let’s start with PE1:

PE1#show ip route 5.5.5.5

PE1#show mpls forwarding-table

PE1#show ip cef 5.5.5.5

Here’s a capture of the IP packet that PE1 sends to the P router:

P#show mpls forwarding-table

PE2#show ip route 1.1.1.1

PE2#show mpls forwarding-table

PE2#show ip cef 1.1.1.1

P#show mpls forwarding-table

 How MPLS routers generate/exchange labels using LDP.

MPLS Label Format

Here’s what the different fields are used for:

The MPLS header is added in between the L2 and L3 header:

MPLS Devices and Operations

There are three actions we can perform with labels:[teaser]

 Label push: when we add a label to a packet, we call it a label push.

Let me add some more detail to the picture above:

MPLS LDP (Label Distribution Protocol)

In the capture above you can see a couple of interesting things:

Let’s advertise all interfaces:

That’s all we need.

There are two ways to configure LDP:

 On the interface level with the mpls ip command.

R1(config)#interface FastEthernet 0/0

LDP Neighbor Adjacency

First let’s check if LDP is enabled on the interface:

R1#show mpls interfaces

R2#show mpls ldp neighbor

 R2 and R3 have become neighbors:

LDP Control Plane

R1(config)#mpls label range 100 199

1.0.0.0/32 is subnetted, 1 subnets

R1#show mpls ldp bindings