VRF Route Target

MPLS VPN implementation requires VRF and also exporting and importing routes for that VRF. I mentioned on my previous posts about VRF that the VRF name is locally significant and even the RD number. What counts is what you import and export. Importing and exporting route targets use the same syntax as the RD and it is ASN:NN as shown by the example below.

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

By definition the routes that you "export" are only the routes you advertise on the vrf address family in BGP. The routes that you import are the cummulative routes with the same label that were exported from the other routers participating in the MPLS VPN. Remember that you don't export what you have learned through importation. Check the diagram below and the scenario we need to accomplish in this lab.


Scenario Conditions:

1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS should not see each other.
2. RR should only see the all the routes but will not be seen by the routers.

I have setup everything and configured MPLS as well. I have configured the clients on the RR on both ipv4 and vpnv4 address-families. The command "show ip bgp vpnv4 all sum" on the RR should show that its learning prefixes from the clients.

RR#sh ip bgp vpnv4 all sum
BGP router identifier 123.123.123.4, local AS number 123
BGP table version is 13, main routing table version 13
12 network entries using 1644 bytes of memory
12 path entries using 816 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
3 BGP extended community entries using 72 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 3028 total bytes of memory
BGP activity 12/0 prefixes, 12/0 paths, scan interval 15 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
123.123.123.1   4   123      52      57       13    0    0 00:40:41        2
123.123.123.2   4   123      53      61       13    0    0 00:41:26        2
123.123.123.3   4   123      43      44       13    0    0 00:36:44        2

We can clearly see that its learning prefixes in the vpnv4 but will not put those routes in the routing table until it has been imported in one of the VRF's. In our case, I have configured vrf ALL-VRF in RR and imported all the route-targets 123:1, 123:2 and 123:4. In a VRF you can export and import as many route-targets as needed. Lets see if RR can see the routes now

RR

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

RR#sh ip route vrf ALL-VRF

Routing Table: ALL-VRF
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:46:26
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 00:46:26
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:46:26
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:46:26
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 00:46:26
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:46:28
 123.0.0.0/32 is subnetted, 1 subnets
C       123.123.123.14 is directly connected, Loopback40

Ok, we have meet the first condition. RR is now able to see the routes exported by the RR clients. They won't see the route advertised in RR because the clients are not even importing that route. Full reachability in MPLS VPN requires that one router's exported route-target should be imported by another and vice-versa, otherwise you can only see the route but you won't be able to reach it. The networks should be in the corresponding VRF routing table of the routers.

To illustrate this point, let's configure the second scenario. Below are the VRF configurations on the 3 clients.

APAC#

!
ip vrf APAC
rd 123:1
route-target export 123:1
route-target import 123:3

AMERICAS#

!
ip vrf AMERICAS
rd 123:2
route-target export 123:2
route-target import 123:2

EMEA#
!
ip vrf EMEA
rd 123:3
route-target export 123:3
route-target export 123:2
route-target import 123:1
route-target import 123:2

APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA. EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip reachability between the two. By the way the route-target ID doesn't necessarily match with the RD. Normally for networks that should see each other in MPLS VPN both the export and import route target ID's are the same. It will get rid of any unnecessary confusion created by using different RT ID's. Take into consideration AMERICAS and EMEA routers. As you can see on the config above, AMERICAS is importing and exporting 123:2. One command can generate the both export and import and that is "route-target both 123:2". EMEA is importing and exporting also 123:2 which means they will reach each other. Let's test if we have accomplished the condition, we will show the routing table in APAC and AMERICAS and let's ping the networks in EMEA. The ping should be sourced on the loopback interfaces where we configured the VRF's.

APAC#sh ip route vrf APAC

Routing Table: APAC
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 01:04:51
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 01:04:51
 11.0.0.0/32 is subnetted, 1 subnets
C       11.11.11.11 is directly connected, Loopback10

APAC#ping vrf APAC 3.3.3.3 source lo0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, 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 = 248/346/436 ms


AMERICAS#sh ip route vrf AMERICAS

Routing Table: AMERICAS
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:56:20
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:56:20
 22.0.0.0/32 is subnetted, 1 subnets
C       22.22.22.22 is directly connected, Loopback10

AMERICAS#ping vrf AMERICAS 3.3.3.3 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/593/1020 ms


EMEA#sh ip route vrf EMEA

Routing Table: EMEA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:00:00
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 01:07:06
 33.0.0.0/32 is subnetted, 1 subnets
C       33.33.33.33 is directly connected, Loopback10
 3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 01:07:06
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:00:03

It will take a while to get used to VRF Route-target if you are just learning it but this should be pretty easy. Remember, you can't reach a network that you have imported unless it exported your network. In MPLS VRF, entries in your VRF routing table doesn't assure reachability, the router in the destination network should also have your network in its VRF routing table. Ok, we are done! :)

VRF and VRF-lite

I remembered that several months ago, I had an implementation regarding VRF-lite. In my previous posts VRF Basics and MPLS VPN VRF Select I haven't actually mentioned about VRF-lite. What exactly is this and how does this differ with VRF used in MPLS VPN?

First, ask the question, what is required to run VRF in the MPLS VPN implementation? Of course VRF, MP-BGP and MPLS should be running on the Provider's routers. It would need BGP VPNv4 neighborship to make MPLS VPN run.

VRF-lite is normally VRF without MPLS. This is Cisco's way, of what is so called virtualization. This can be useful of course if the enterprise has networks of overlapping IP addresses or some segments they don't want to be reached by other segments. Its kinda like VLAN in the sense that its in WAN. In this sense, VRF-lite configuration doesn't need the route-target part. For every VRF is a separate routing table. Routing VRF-lite can be done by static or dynamic under its vrf instance. I think I'll create a lab for this to show how it can be configured using IGP's. By the way, these days, I wonder why I am posting more on MPLS than any other topic? Does it mean I want to pursue CCIE SP than gettting the R&S? Good day! :)

MPLS VPN VRF Source Selection

It's been a while since I did some labs. Recently I received a comment from someone in the VRF Basics entry regarding importing the loopbacks from the CE routers to a VRF for management purposes. I'm in the middle of my BGP review but I'm curious anyway. I created a lab and tried a way and it seems I found a way how to. The feature is called VRF source selection, in which you can have multiple VRF's in an interface and VRF mapping is based on the source ip address. As we all know, CE routers usually don't have VRF's configured on them and usually for MPLS VPN setup one customer is assigned to one VRF. For MPLS Basics check my previous entry.

The diagram below shows 2 PE's and 3 CE's. I have preconfigured the PE's with BGP peering on both ipv4 and vpnv4 address-families and the necessary IP configuration with the CE's having a default route toward the directly connected PE. VPNv4 address-family on BGP by the way, is used for MPLS VPN. Configured MPLS on the link between PE1 and PE2.

Scenario:

We have 2 Customers, Customer1 and Customer2. The branch offices needs to connect to the other branches in PE2(I have created Loopback addresses for these). They need to have their own VRF's configured. Customer1 and Customer2 should have loopback0 ip addresses configured on the CE's for the NOC to use as management ip to access from their hopping server which is in ISP NOC router. VRF named "Management" should be used on the CE's. Customer's LAN networks are represented as Loopback10. The RD's of the Customers should be Customer1 - 1234:1, Customer2 - 1234:2 and Management - 1234:100. Click the image below for a bigger view.



The scenario requires 2 VRF's from every Customer CE. The Command "ip vrf forwarding" only uses one VRF per interface. We only have 1 interface and this command is not a feasible solution. We need to use VRF source selection in order to use multiple VRF's in an interface.

Provided that we already created the VRF's, first we would need to map a source IP address to a VRF. The PE will know which VRF a packet will be through the source IP.

PE1(config)#vrf selection source 1.1.1.1 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 2.2.2.2 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 11.11.11.11 255.255.255.255 vrf Customer1 
PE1(config)#vrf selection source 22.22.22.22 255.255.255.255 vrf Customer2  

PE2(config)#vrf selection source 3.3.3.3 255.255.255.255 vrf Management

After that, we would need to configure the interfaces in the PE's to use source selection. As mentioned, a while ago, "ip vrf forwarding" command is used if there is only one VRF used so in this scenario there is no need for the command.

PE1(config)#interface Serial1/1 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer1 
PE1(config-if)#ip vrf receive Management

PE1(config)#interface Serial1/2 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer2 
PE1(config-if)#ip vrf receive Management

PE2(config)#interface Se1/3
PE2(config)#ip vrf select source
PE2(config)#ip vrf receive Management

The commands mean that on the corresponding interfaces the VRF are activated based on the "vrf selection source" commands. It's the equivalent of "ip Vrf forwarding" command but in the sense that its for multiple vrfs.

Well now the question is, how will the VRF's know which subnets will come from what interface. Simple, through routing.:) In our case since we are not configuring dynamic routing, we will configure static vrf routes.

PE1(config)#ip route vrf Customer1 11.11.11.11 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Customer2 22.22.22.22 255.255.255.255 192.168.20.2 
PE1(config)#ip route vrf Management 1.1.1.1 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Management 2.2.2.2 255.255.255.255 192.168.20.2  

PE2(config)#ip route vrf Management 3.3.3.3 255.255.255.255 192.168.30.3

It's obvious that the "vrf " keyword there points to what VRF this route belongs to.:) MPLS VPN requires that the routes be learned by Multiprotocol BGP. Since these are static routes we need to redistribute them into BGP on the ipv4 VRF address-family. Output pasted below from the running config.

PE1
! 
address-family ipv4
neighbor 10.10.10.2 activate 
no auto-summary 
no synchronization
exit-address-family 
! 
address-family vpnv4
neighbor 10.10.10.2 activate 
neighbor 10.10.10.2 send-community extended 
exit-address-family 
!
address-family ipv4 vrf Management 
redistribute static metric 1 
no auto-summary  no synchronization 
exit-address-family 
!
address-family ipv4 vrf Customer2
redistribute static metric 1
 no auto-summary 
no synchronization 
exit-address-family 
!
 address-family ipv4 vrf Customer1 
redistribute static metric 1  no auto-summary  no synchronization  exit-address-family

PE2
!
 address-family ipv4 vrf Management
redistribute static metric 1
no auto-summary
no synchronization
exit-address-family

If you notice, we didn't redistribute it on the "ipv4" global address-family but instead we did it on their corresponding VRF address-families. We learned that VRF's are like separate routing tables in a single router, and that exactly is the reason why we advertise this in different address-families.

We are not done yet, remember we have 2 loopback's in PE2 representing the other sites of Customer1 and Customer2. Lets configure those.

PE2
!
interface Loopback1
 ip vrf forwarding Customer1
 ip address 111.111.111.111 255.255.255.255
!
interface Loopback2
 ip vrf forwarding Customer2
 ip address 222.222.222.222 255.255.255.255

Now let's advertise this in BGP.
!
 address-family ipv4 vrf Customer2
 no auto-summary
 no synchronization
 network 222.222.222.222 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf Customer1
 no auto-summary
 no synchronization
 network 111.111.111.111 mask 255.255.255.255
 exit-address-family

Ok, now lets check BGP peering on the VPNv4 address family. The "show ip bgp vpnv4 all summary" command will display the summary of the prefixes learned through all the VRF's.

PE1#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4  1234      93     106       15    0    0 01:14:47        3

PE2#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4  1234     106      93       20    0    0 01:14:56        4

Let's check the VRF routing tables on R1.

PE1#sh ip route vrf Customer1 | beg Gateway
Gateway of last resort is not set

C    192.168.10.0/24 is directly connected, Serial1/1
     111.0.0.0/32 is subnetted, 1 subnets
B       111.111.111.111 [200/0] via 10.10.10.2, 00:23:02
     11.0.0.0/32 is subnetted, 1 subnets
S       11.11.11.11 [1/0] via 192.168.10.1
PE1#sh ip route vrf Customer2 | beg Gateway
Gateway of last resort is not set

     222.222.222.0/32 is subnetted, 1 subnets
B       222.222.222.222 [200/0] via 10.10.10.2, 00:24:04
     22.0.0.0/32 is subnetted, 1 subnets
S       22.22.22.22 [1/0] via 192.168.20.2
C    192.168.20.0/24 is directly connected, Serial1/2
PE1#sh ip route vrf Management | beg Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
S       1.1.1.1 [1/0] via 192.168.10.1
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 192.168.20.2
     3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/1] via 10.10.10.2, 01:02:10
C    192.168.10.0/24 is directly connected, Serial1/1
C    192.168.20.0/24 is directly connected, Serial1/2

We can see the routes that should be there. Now let's test the Customer1 VRF first if we achieved our objective. It should be able to reach the network 111.111.111.111/32 in PE2.

Customer1#ping 111.111.111.111 source 11.11.11.11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/168/192 ms

Cool its working! We need to specify the source ip so that it will be in the correct VRF. Network 111.111.111.111/32 is in vrf Customer1, if we don't use a source ip, by default it will use the exit interface's ip address as the source and will not be using any vrf since we don't have a source selection mapping for that. Instead it will use the "global routing table" which doesn't have entries for 111.111.111.111/32. Let's see what happens.

Customer1#ping 111.111.111.111

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

As expected! Let's do a test for Customer2.

Customer2#ping 222.222.222.222 source 22.22.22.22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 222.222.222.222, timeout is 2 seconds:
Packet sent with a source address of 22.22.22.22
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/173/192 ms

And for our final objective, the Loopback0 should be reachable through vrf "Management" from ISP NOC router. By the way, since we are only using one VRF for this, it was not necessary to use source selection. It's only for example sake!:) Now for the testing.

ISPNOC#ping 1.1.1.1 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 172/216/264 ms
ISPNOC#ping 2.2.2.2 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/231/292 ms

Success!!! Whew, I don't like long blog entries but sure this will be helpful for myself in case I forget this feature. More on route-target import and export next time. Cheers!

VRF Basics

When we hear about VRF, its almost synonymous to MPLS VPN. Virtual Routing and Forwarding is commonly used by Service Providers to provide services within an MPLS cloud with multiple customers. The most interesting feature of this is that, VRF allows creation of multiple routing tables within a single router. This means that overlapping use of IP addresses from different customers is possible. Some enterprises use VRF to seggrate their services like VOIP, wireless, geographical location and other varieties. Through the network setup below, we will see how to configure VRF and check if its really possible for duplicate ip addresses. We have 3 customers in the figure connected to a Provider Edge router. We will name the VRF's Blue, Red and Yellow. Click image for a bigger view.


Now let's configure RD's on the PE router.

Router(config)#host PE 
PE(config)#ip vrf blue 
PE(config-vrf)#rd 1:1 
PE(config-vrf)#ip vrf red 
PE(config-vrf)#rd 2:2 
PE(config-vrf)#ip vrf yellow 
PE(config-vrf)#rd 3:3

Basically the "rd" command is in the format ASN:nn or IP-address:nn. The VRF names and rd values are actually locally significant which means that it doesn't matter what name you create. What really matters is the "route target" value because this is what you will import or export. More about this on the next blog entry.

Now we have created VRF's, lets configure interfaces and apply the VRF's to the interfaces.

PE(config)#int fa0/0.2
PE(config-subif)#encapsulation dot1q 2
PE(config-subif)#ip vrf forwarding blue
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.3
PE(config-subif)#encapsulation dot1q 3
PE(config-subif)#ip vrf forwarding red
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.4
PE(config-subif)#encapsulation dot1q 4
PE(config-subif)#ip vrf forwarding yellow
PE(config-subif)#ip address 1.1.1.1 255.255.255.252

If you notice above all interfaces have the same ip address which is 1.1.1.1. Normally without VRF, the router will give a warning message that overlapping ip addresses are not allowed. The command "ip vrf forwarding " will add the vrf to a specific interface.

Let's configure the other routers Blue, Red and Yellow with 1.1.1.2/30 on their FastEthernet0/0 interfaces. Lets ping 1.1.1.1 from the routers.

Blue#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/80 ms

Red#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/156 ms

Yellow#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/60/136 ms

It's good! We have ip reachability to PE from the CE routers. Now, from PE point of view, how will PE know which one to ping if we use 1.1.1.2 since all Blue, Red and Yellow routers use the same ip? This can be accomplished using the "ping vrf " command. See below.

PE#ping vrf blue 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/68 ms
PE#ping vrf red 1.1.1.2 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/88 ms
PE#ping vrf yellow 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/31/68 ms

Now, we have proven that duplicate IP addresses is possible using VRF. Be reminded that VRF's are usually and by standard configured on PE routers. CE routers normally don't make use of VRF's but there are always exceptions. Next entries will focus on importing Route Targets and using IGP's and BGP on a MPLS VPN setup. Cheers.

MPLS Basics

One of the great advancements to enhance WAN services is MPLS. Originally, it was created to address the problems on ATM networks and thanks to Cisco and IETF, it has evolved to what it is today.

MPLS (Multiprotocol Label Switching) is a protocol that uses labels for packet switching. MPLS is agnostic of Layer 1 or Layer 2 protocols and can be used on any type of links. It inserts a 32-bit label in between the Layer 2 and Layer 3 headers which dubbed it as a Layer 2.5 protocol. These labels number range is 0-1,048,575. Labels 0-15 for reserved purposes therefore the usuable range is 16-1,048,575. The defaul range in Cisco routers is from 16 - 100,000 which is good enough for big enterprises.

MPLS requires a running IGP routing protocol with a full routing table. CEF must also be enable because FIB (Forwarding Information Base) and adjancency tables are needed to build the LFIB (Label Forwarding Information Base). FIB is responsible for maintaning the next hops for the routes in the routing table while adjacency table is for the Layer 2 rewrite so that repetitive ARP requests will be avoided.

The process of how MPLS works starts by the routing protocol building the IP routing table. After that, based on the routing table the MPLS enabled router will now build its own mapping between destination ip to a label. Thirdly, using LDP (Label Distribution Protocol) the LSR's (Label Switch Routers or simply MPLS-enabled routers) in an MPLS networks share their assigned labels. Lastly, the LSR's build the LIB (Label Information Base), LFIB, and FIB based on the labels they received.

How to Configure MPLS in a Cisco Router

We have below a simple diagram of the network that will be used for this example. We will focus on the basics of configuration, some show commands and some "what if" scenarios.

Diagram:

Dynamips Configuration

autostart = true
ghostios = true
sparsemem = true
# MPLS Basics

[localhost]

[[7200]]
image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.bin
npe = npe-400
ram = 160

[[ROUTER R1]]
Se1/0 = R2 Se1/0
Se1/1 = R3 Se1/0

[[ROUTER R2]]
Se1/1 = R3 Se1/1

[[ROUTER R3]]

Basic Configurations

Start dynamips and apply the basic configuration below needed for this example. Just copy and paste everything below and it should be good.

R1
!
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
no shut
!
interface Serial1/1
ip address 192.168.13.1 255.255.255.0
no shut

!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0

R2
!
interface Serial1/0
ip address 192.168.12.2 255.255.255.0
no shut
!
interface Serial1/1
ip address 192.168.23.2 255.255.255.0
no shut
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0

R3
!
interface Serial1/0
ip address 192.168.13.3 255.255.255.0
no shut
!
interface Serial1/1
ip address 192.168.23.3 255.255.255.0
no shut
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0

Enabling MPLS

Once you have done this the OSPF adjacencies should be up and running. Now what we need to do is apply the necessary MPLS command to enable MPLS on network.

R1(config)#int se1/0
R1(config-if)#mpls ip
R1(config-if)#int se1/1
R1(config-if)#mpls ip

R2(config)#int se1/0
R2(config-if)#mpls ip
R2(config-if)#int se1/1
R2(config-if)#mpls ip

R3(config)#int se1/0
R3(config-if)#mpls ip
R3(config-if)#int se1/1
R3(config-if)#mpls ip

Once you have applied the single command "mpls ip" on the both sides of the link, an LDP adjacency will be formed and will display a log shown below:

*Feb 21 04:15:51.811: %SYS-5-CONFIG_I: Configured from console by console
*Feb 21 04:15:52.135: %LDP-5-NBRCHG: LDP Neighbor 192.168.13.1:0 (2) is UP

This means that MPLS is enabled on both sides and the neighbors are exchanging label information. The LFIB, FIB and LIB are created after the neighborships are formed.

Verifying MPLS Interfaces

Inorder to get which interfaces are mpls enabled the command "show mpls interfaces" is used. Operational state is "Yes" if the command "mpls ip" is enabled on the interface.

R3#sh mpls interfaces
Interface              IP            Tunnel   Operational
Serial1/0              Yes (ldp)     No       Yes
Serial1/1              Yes (ldp)     No       Yes

Verifying LDP Neighbors

To know the LDP neighbors use "show mpls ldp neighbors". This will show the neighbors ID which is based on the highest ip address of the mpls enable interface., the LDP neighborship uptime, which interface it was discovered and the ip addresses of the MPLS enabled interfaces. Like OSPF, LDP's election of the ID is first chosen the highest ip address of the loopback interfaces and then the physical interfaces.

R3#sh mpls ldp neigh
Peer LDP Ident: 192.168.23.2:0; Local LDP Ident 192.168.23.3:0
TCP connection: 192.168.23.2.646 - 192.168.23.3.46832
State: Oper; Msgs sent/rcvd: 18/18; Downstream
Up time: 00:10:59
LDP discovery sources:
Serial1/1, Src IP addr: 192.168.23.2
Addresses bound to peer LDP Ident:
192.168.12.2    192.168.23.2
Peer LDP Ident: 192.168.13.1:0; Local LDP Ident 192.168.23.3:0
TCP connection: 192.168.13.1.646 - 192.168.23.3.26398
State: Oper; Msgs sent/rcvd: 6/6; Downstream
Up time: 00:00:39
LDP discovery sources:
Serial1/0, Src IP addr: 192.168.13.1
Addresses bound to peer LDP Ident:
192.168.12.1    192.168.13.1

Let's configure loopbacks for R1, R2 and R3. Using 1.1.1.1, 2.2.2.2 and 3.3.3.3 respectively and lets see what happends to the Peer LDP Ident.

R1#config t
R1(config)#int lo0
R1(config-if)#ip address 1.1.1.1 255.255.255.255

R2#config t
R2(config)#int lo0
R2(config-if)#ip address 2.2.2.2 255.255.255.255

R3#config t
R3(config)#int lo0
R3(config-if)#ip address 3.3.3.3 255.255.255.255

After configuring, lets first clear the ospf process on the routers. Use the "clear ip ospf process" and "clear mpls ldp neigbor" in enable mode. For some reason in Dynamips, there are no changes to the LDP ident and the OSPF router id, so its advisable to remove the OSPF process first and disabling first MPLS on the interfaces then renabling OSPF and MPLS. Now lets see what happens to the LDP Ident.

R1#sh mpls ldp neigh
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 192.168.13.1:0
TCP connection: 2.2.2.2.646 - 192.168.13.1.17752
State: Oper; Msgs sent/rcvd: 15/15; Downstream
Up time: 00:05:24
LDP discovery sources:
Serial1/0, Src IP addr: 192.168.12.2
Addresses bound to peer LDP Ident:
192.168.12.2    192.168.23.2    2.2.2.2
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 192.168.13.1:0
TCP connection: 3.3.3.3.646 - 192.168.13.1.19721
State: Oper; Msgs sent/rcvd: 14/14; Downstream
Up time: 00:05:22
LDP discovery sources:
Serial1/1, Src IP addr: 192.168.13.3
Addresses bound to peer LDP Ident:
192.168.13.3    192.168.23.3    3.3.3.3

It's now taking the loopback ip address as the Local Ident which proves that MPLS LDP chooses the ID like how OSPF does. You can manually force the LDP id by the command "mpls ldp router-id loopback0 force" so it will take the ip address of the interfaces as its ID. In this example we us the loopback0 with is already the default ID.

MPLS Labels

Let's take a look on how MPLS labels destination IP addresses. I mentioned at the beginning that MPLS creates a label for certain destination ip addresses in the routing table. When the labels are done, it propagates the information to its neighbors so they will know what label they should put on the packet for the sending router. An analogy in the real world, we can compare this to snail mail processing. The address on the letter is the IP address and the Zip code is the Label. The central post office knows where to send the letter, by just looking at the zip code. They don't need to read the whole address. Once the letter has been sent to the local post office, its the time they read the whole address. The local post office is like the PE (Provider Edge) routers. This will be discussed in the next post.

To show the MPLS labels and how their neighbors identify the route with their own labels use the "show mpls ldp bindings" command.

R1#sh mpls ldp binding
tib entry: 1.1.1.1/32, rev 4
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: 19
remote binding: tsr: 3.3.3.3:0, tag: 20
tib entry: 2.2.2.2/32, rev 8
local binding:  tag: 19
remote binding: tsr: 2.2.2.2:0, tag: imp-null
remote binding: tsr: 3.3.3.3:0, tag: 21
tib entry: 3.3.3.3/32, rev 10
local binding:  tag: 20
remote binding: tsr: 2.2.2.2:0, tag: 21
remote binding: tsr: 3.3.3.3:0, tag: imp-null
tib entry: 192.168.12.0/24, rev 2
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: imp-null
remote binding: tsr: 3.3.3.3:0, tag: 19
tib entry: 192.168.13.0/24, rev 6
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: 20
remote binding: tsr: 3.3.3.3:0, tag: imp-null
tib entry: 192.168.23.0/24, rev 12
local binding:  tag: 21
remote binding: tsr: 2.2.2.2:0, tag: imp-null
remote binding: tsr: 3.3.3.3:0, tag: imp-null

Check out the first entry mark in red. The TIB is also equivalent to LIB. Tag Information Base was its old name when Label Switching was then called Tag Switching. 1.1.1.1 is the ip address entry. Local binding means what tag the router will put for the packet to destination 1.1.1.1 based on the LIB it generated. In this case we see it as imp-null meaning it will not put because this is a locally originated. Remote Binding means, the label the LDP neighbor router assigned to this subnet. TSR (Tag Switching Router) 2.2.2.2 which is router R2 assigns a label of 19 as identifier to this subnet and 3.3.3.3 which is router R3 assigns label 20 to this.

Let's take a look at the 2nd entry. For 2.2.2.2, R1 has a tag of 19 to identify this subnet but R2 has imp-null because this originates from R2. Routes originated locally to the router are never label. R3 identifies this as label 21.

MPLS LFIB

MPLS enabled routers don't label the packets before sending based on their LIB but based on the LIB's of their neighbors learned through LDP. They label it this way so that when the packet reaches their neighbor, the neighbor knows exactly this label is for and how to forward it because this label information is from the router itself. Take a look at the example below. I'll shut the link from R1 to R3 so the pacdkets destined for R3 will pass through R2. Lets also compare the LFIB before and after the shutting of links.

Before shut

After Shut



Observe the prefix 3.3.3.3, when R1 and R3 where directly connected before I shut down the link, the Outgoing tag or VC is Pop tag. This means that if R1 receives a packet destined for R3, it "pops" or removes the label and doesn't swap any label because in the LIB of R3, 3.3.3.3 has an implicit-null. After the link has been shut down, the Outgoing tag or VC now is 21. This literally means that R1 must swap a label of 21 to packets destined for 3.3.3.3. R2 in its LIB has 21 for 3.3.3.3. R2 to R3, should never be labeled because 3.3.3.3 originates from R3. Let's check the traceroute below for more proof.

R1#traceroute 3.3.3.3

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 192.168.12.2 [MPLS: Label 21 Exp 0] 88 msec 56 msec 60 msec
2 192.168.23.3 140 msec 76 msec *

The first hop is from R1 to R2. You can see clearly that it labeled 21. The 2nd hop did not display any labels.

Verifying and Configuring Label Range

A simple command to verify the label assignment range is "show mpls label range". The range of labels can also be set to your liking by using "mpls label range minrange maxrange" command.

R1#show mpls label range
Downstream Generic label region: Min/Max label: 16/100000
R1(config)#mpls label ?
protocol  Set platform default label distribution protocol
range     Label range

R1(config)#mpls label range ?
<16-1048575>  Minimum label value

R1(config)#mpls label range 100 500000 static 50 70
% Label range changes will take effect at the next reload.

In the example above, we set the range to 100 minimum and 500000 for the maximum. I saved the config and restarted the router. The changes reflect right away when R1 fully restarted. It's local bindings now start from 100.

R1#sh mpls ldp bind
tib entry: 1.1.1.1/32, rev 4
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: 19
tib entry: 2.2.2.2/32, rev 6
local binding:  tag: 100
remote binding: tsr: 2.2.2.2:0, tag: imp-null
tib entry: 3.3.3.3/32, rev 8
local binding:  tag: 101
remote binding: tsr: 2.2.2.2:0, tag: 21
tib entry: 192.168.12.0/24, rev 2
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: imp-null
tib entry: 192.168.23.0/24, rev 10
local binding:  tag: 102
remote binding: tsr: 2.2.2.2:0, tag: imp-null

MPLS Static Bindings

Using the range we configured about for the static bindings, lets configure 3.3.3.3 and statically assign a label of 65.

R1#sh mpls ldp binding
tib entry: 1.1.1.1/32, rev 4
local binding:  tag: imp-null
remote binding: tsr: 2.2.2.2:0, tag: 19
tib entry: 2.2.2.2/32, rev 6
local binding:  tag: 100
remote binding: tsr: 2.2.2.2:0, tag: imp-null
tib entry: 3.3.3.3/32, rev 12
local binding:  tag: 65
------truncated---------------

So that concludes the MPLS Basics. Cheers!