MPLS VPN Per VRF Label feature

In this post i would like to explain the usage of the “MPLS VPN Per VRF Label” feature.

By default, in each VRF, prefixes are assigned a VPN label, used to identify the route within the VRF itself.
This label is the only label that is being looked at by the receiving PE router.

In theory, you only need a single label to identify the VRF for the destination prefix, and then you can do an IP lookup to further process the packet.
This is what the “MPLS VPN Per VRF Label” does.

Im going to be using the simple topology below to illustrate the functionality:

In this topology, R2 receives 2 prefixes from R1 through RIP.

1.0.0.0/32 is subnetted, 1 subnets
R        1.1.1.1 [120/1] via 192.168.12.1, 00:00:24, FastEthernet1/0
11.0.0.0/32 is subnetted, 1 subnets
R        11.11.11.11 [120/1] via 192.168.12.1, 00:00:24, FastEthernet1/0

Since we are redistributing RIP into BGP, we can see these two routes in the BGP table:

Route Distinguisher: 100:100 (default for vrf VPN_A)
*> 1.1.1.1/32       192.168.12.1             1         32768 ?
*>i4.4.4.4/32       3.3.3.3                  1    100      0 ?
*> 11.11.11.11/32   192.168.12.1             1         32768 ?
*> 192.168.12.0     0.0.0.0                  0         32768 ?
*>i192.168.34.0     3.3.3.3                  0    100      0 ?

And we can check which labels R2 allocates for each of the prefixes:

R2#sh bgp vpnv4 unicast all labels
Network          Next Hop      In label/Out label
Route Distinguisher: 100:100 (VPN_A)
1.1.1.1/32       192.168.12.1    20/nolabel
4.4.4.4/32       3.3.3.3         nolabel/16
11.11.11.11/32   192.168.12.1    21/nolabel
192.168.12.0     0.0.0.0         22/nolabel(VPN_A)
192.168.34.0     3.3.3.3         nolabel/17

For prefix 1.1.1.1/32 a VPN label of 20 has been assigned and for 11.11.11.11/32, label 21 is used.

Lets check the settings for the VRF VPN_A:

R2#sh ip vrf detai
VRF VPN_A (VRF Id = 1); default RD 100:100; default VPNID <not set>
Interfaces:
Fa1/0
VRF Table ID = 1
Export VPN route-target communities
RT:100:100
Import VPN route-target communities
RT:100:100
No import route-map
No export route-map
VRF label distribution protocol: not configured
VRF label allocation mode: per-prefix

We can see that the label allocation mode is “per-prefix” which is what we expect and have verified by looking at the labels assigned by BGP.

The final verification of this can be see on R3:

R3#sh bgp vpnv4 unicast all la
Network          Next Hop      In label/Out label
Route Distinguisher: 100:100 (VPN_A)
1.1.1.1/32       2.2.2.2         nolabel/20
4.4.4.4/32       192.168.34.4    16/nolabel
11.11.11.11/32   2.2.2.2         nolabel/21
192.168.12.0     2.2.2.2         nolabel/22
192.168.34.0     0.0.0.0         17/nolabel(VPN_A)

We can see that the “Out label” for 1.1.1.1/32 is in fact 20 and for 11.11.11.11/32 21. Everything we expect.

Now lets change the setting on R2 to be “Per VRF”:

R2(config)#mpls label mode ALL-vrfs protocol all-afs per-vrf

Verification of the VRF setting:

R2#sh ip vrf detai
VRF VPN_A (VRF Id = 1); default RD 100:100; default VPNID <not set>
Interfaces:
Fa1/0
VRF Table ID = 1
Export VPN route-target communities
RT:100:100
Import VPN route-target communities
RT:100:100
No import route-map
No export route-map
VRF label distribution protocol: not configured
VRF label allocation mode: per-vrf (Label 18)

And verify the BGP label allocation:

R2#sh bgp vpnv4 unicast all labels
Network          Next Hop      In label/Out label
Route Distinguisher: 100:100 (VPN_A)
1.1.1.1/32       192.168.12.1    IPv4 VRF Aggr:18/nolabel
4.4.4.4/32       3.3.3.3         nolabel/16
11.11.11.11/32   192.168.12.1    IPv4 VRF Aggr:18/nolabel
192.168.12.0     0.0.0.0         IPv4 VRF Aggr:18/nolabel(VPN_A)
192.168.34.0     3.3.3.3         nolabel/17

What we can see now, is that the prefixes are being treated as an aggregate with a label of 18 for both prefixes.
Finally, if i look at the changes on R3, we can see that label 18 is indeed being used for all the routes from R2 (and hence R1):

R3#sh bgp vpnv4 unicast all la
Network          Next Hop      In label/Out label
Route Distinguisher: 100:100 (VPN_A)
1.1.1.1/32       2.2.2.2         nolabel/18
4.4.4.4/32       192.168.34.4    16/nolabel
11.11.11.11/32   2.2.2.2         nolabel/18
192.168.12.0     2.2.2.2         nolabel/18
192.168.34.0     0.0.0.0         17/nolabel(VPN_A)

Thats all i had for now. Hope you enjoyed it. Take care!

Going to DKNOG

I just ordered my ticket for DKNOG, which will be happening on March 21st in Copenhagen.

Catch me there if you can!

www.dknog.dk

Becomming Zen’ish?

Wow. The other day, someone posted a link to [zenhabits.net]. and I was hooked right away.

The entire idea around being “Zen’ish” really appeals to me on a fundamental level. I like the idea behind it, i like what it entails, i like the discipline and i like the calmness.

Do i want to give everything up and join a monastery? – No, definitely not. That is what is so great about this site. It contains tips on how to incorporate the Zen into every day things.

I certainly recommend you take a detour over onto that site and spend just 20 minutes of your time reading through some of the posts. I think you will thank me later.

Cisco to sell Linksys to Belkin.

Yesterday it was announced that Belkin intends to purchase the Linksys division of Cisco’s hands.

I for one, am very happy to see this happen.

I think that for Cisco to be really great, it needs to focus on its core competencies, which does not include home networking equipment.

The downside of this deal, is probably how much, or rather how little, Belkin is willing to pay for the Linksys brand. Cisco will probably end up loosing quite alot of what they paid for it in the first place (which was $500 Million back in 2003).

I believe Mr. Chambers is beginning to reverse on the previous notion that in order for Cisco to evolve it needs to diversify. I seem to recall that previously (when Flip cameras was around) 30 new market adjacencies just that year was the goal.

Working for a VAR, this is also good news, as it was always awkward having people believe that Linksys actually had much to do with “real” Cisco gear.

All in all, positive news as far as im concerned!

Source

Time to put the beans to rest

Yesterday brought with it another Java security breach. It is security breach that doesnt yet have a fix for it (0-day), so short of disabling Java on your computer, you are out of luck.

Im continually amazed that we keep running this piece of software, but I guess I shouldnt be, given people’s track record of running insecure software (think older Internet Explorer browsers on windows).

My dilemma as a Danish citizen is the fact that we are forced to run Java applications from a certain vendor in order to access pretty much anything from our online banking, to our communication with the government. Ofcourse, the vendor in question doesnt seem to think there’s an issue at all.

I disagree. After countless Java security breaches its time we stop using Java alltogether.

Looking forward

“All that matters, is where you are going” is a favorite quote of mine.

With that an update as well as a plan to move forward.

I have now finished Narbik’s Volume 2 Service Provider workbook. It took a little while longer than I had planned. This is mainly because i took some time off during the holidays (well, studied less at least :) ).

Just today, I finished working on a plan of attack for the next phase of my studies. My goal is to take 3 days at a time, planning 3 days ahead and then plan again. Hopefully this will prevent me from being overwhelmed with tasks and ending up doing none of them.

There are basically 3 areas to my study, 1) Reading, 2) Labs, 3) Videos. With my “3 day”‘s approach, i try to mix things up, so i don’t get into a rut with any one thing.

Currently im reading Deploying IPv6 Networks as well as going through INE videos on Inter-AS MPLS and Carrier-Supporting-Carrier (CsC). All interesting stuff.

Lab wise, next up is Narbik’s Volume 3 labs. I figure somewhere around 4-6 weeks to go through them. The labs contain complex scenarios such as CsC, so each one will take alot longer than Vol 1 and 2 labs.

Thats all for now folks!

I wish everyone a happy new year!

 

Done with volume 1 labs.

I have now finished the Narbik Volume 1 labs.

It took about 2,5 weeks to do. Im planning on spending a bit more time on the Volume 2 labs. Maybe about 3-4 weeks. I want to make sure i got all the foundational stuff down before advancing to some more complex labs.

Nothing new on the hardware vs. rack rental front just yet. Im still debating on what to do.

On the reading front, im reading Deploying IPv6 networks. I still have some gaps in my IPv6 knowledge which i want to close. Hopefully reading this book will do that for me.

At the same time, im going through the INE videos again, hammering in the concepts required.

Just a quick morning update before work.

Take care!

Frame-Relay PVC bundle

In this short piece i would like to show how Frame-Relay PVC bundles work.

A PVC bundle is exactly what the name says. Its a bundle of PVC’s, with each PVC handling a certain Precedence, MPLS EXP or DSCP.

A requirement for the PVC bundle is that all IP Precedence or DSCP values will be handled by one of the PVC’s, so you need to set the “default” PVC unless
you map them all manually. The PVC bundle will not come up unless you do this.

If a certain individual VC fails, traffic is by default allowed to “bump” to another VC.

If individual protection is enabled, what this means if that the protected VC goes down, the entire PVC bundle goes down.

If group protection is enabled for some of the VC’s, all of the links in the group needs to go down in order for the entire PVC bundle to go down.
Only 1 group can be used for a PVC bundle.

In my example below, i will be using R1 and R4 for generating and receiving traffic.

R2 and R3 is where the magic happens and the PVC bundle is defined.

The topology is as such:

Frame-Relay PVC bundle topology

 

For this example, i have defined 3 PVC’s on the Frame-Relay switch. For R2, these DLCI’s are 203, 213 and 223. For R3 these corresponds to 302, 312 and 322.

I am running EIGRP AS 100 on all the routers to provide connectivity.

Lets see how we define our PVC bundle on R2:

interface Serial2/0
 ip address 10.2.3.2 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay vc-bundle MAIN
  pvc 203 VC-A
   precedence 7
  pvc 213 VC-B
   precedence 5
  pvc 223 VC-C
   precedence other
 frame-relay map ip 10.2.3.3 vc-bundle MAIN broadcast
end

Here we define a PVC bundle called MAIN. This is an abitrary name that will be referenced later to use the PVC bundle.
Within the bundle we define each of our DLCI’s as well as give each one of them another abitrary name.

In our example we have chosen to use precedence values. Either IP Prec, MPLS EXP or DSCP can be used, but only one of them.
This means that we must have all values between 0 to 7 mapped out in some way.

I have selected to use VC-A (DLCI 203) for precedence 7 and VC-B (DLCI 213) for precedence 5 and everything else maps to VC-C (DLCI 223).

Finally i make the L2->L3 mapping using the frame-relay map command and using the name for the PVC bundle that was defined earlier.

The same sort of configuration is happening on R3:

interface Serial2/0
 ip address 10.2.3.3 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay vc-bundle MAIN
  pvc 302 VC-A
   precedence 7
  pvc 312 VC-B
   precedence 5
  pvc 322 VC-C
   precedence other
 frame-relay map ip 10.2.3.2 vc-bundle MAIN broadcast
end

We can verify our PVC bundle using the “show frame-relay vc-bundle” command:

R2#sh frame vc

MAIN on Serial2/0 - Status: UP  Match-type: PRECEDENCE

Name    DLCI  Config.         Active          Bumping     PG/ CIR   Status
              level           level           to/ accept  PV  kbps

VC-A    203   7               7               6/Yes       -   -     up
VC-B    213   5               5               4/Yes       -   -     up
*VC-C   223   0-4,6           0-4,6           -/Yes       -   -     up

Packets sent out on vc-bundle MAIN : 75

In this output we can see that we have 3 VC’s in the PVC bundle, what Precedence value they are each carrying and how the “bump” strategy will work in case the VC goes down.
The * marks the default VC.
We also see that all the VC’s are up.

Now lets try and generate some traffic on R1 to R4 and run a packet capture on traffic sent out by R2 to verify if the mappings are working correctly.

First off is traffic marked with Precedence 7. This traffic should use VC-A (DLCI 203).

First, lets work out which decimal values to use in our ping tests:

IP Prec 7:
111 00000 = 224

IP Prec 5:
101 00000 = 160

On R1, lets make an extended ping:

R1#ping
Protocol [ip]:
Target IP address: 10.3.4.4
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 224
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/88/124 ms

And the packet capture:

Precedence 7 Capture

From this we can see that the DLCI being used is as expected DLCI 203 (VC-A).

Lets try out IP Precedence 5:

R1#ping
Protocol [ip]:
Target IP address: 10.3.4.4
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 160
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/79/88 ms

And the capture:

Precedence 5 Capture

Excellent, DLCI 213 (VC-B), is used.

Finally, lets make a generic ping to test the final VC in the PVC bundle:

R1#ping 10.3.4.4

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

The capture for default traffic:

Default Traffic

And finally we see the default PVC (VC-C) being used to handle everything else.

And with that i will close out.

Some IOS-XR Training

Just wanted to let you know of a good place to go for some IOS-XR training.

Head on over to FryGuy’s place:

http://www.fryguy.net/2012/11/06/ios-xr-cisco-videos-and-training/

Another great motivational video

Just wanted to share another great motivational video