Category Archives: Service Provider - Page 2

ISIS csnp-interval

The CSNP on multiaccess networks

The CSNP (Complete Sequence Number PDU) on multi-access networks is being sent out on behalf of the DIS (Designated Intermediate System), which acts as the pseudonode representing the multi-access network. Its being used as ISIS’s way of making sure everybody on the multi-access network is up to date. If thats not the case, the node which is missing some routing information can use PSNP (Partial Sequence Number PDU)’s to request the missing information from the DIS.

The csnp-interval is simply the timer that controls how often the DIS sends out this CSNP. The default on IOS (and XR) is every 10 seconds.

Its important to know that a separate timer is kept for both level–1 and level–2 DIS.

For this example i will be using the topology listed in figure 1:

Topology

Take note of the fact that i have manually set the Mac address on the routers to make it more obvious which router is the DIS from the point of view of debugs.

Since everybody has the same priority (default 64), the highest SNPA (SubNet Point of Attachment), which translates to the Mac address, will be used as the tiebreaker. Highest one wins. In our case this will be R3.

The output below highlights this fact:

R1#sh isis nei

System Id      Type Interface   IP Address      State Holdtime Circuit Id
R2             L2   Fa1/0       100.100.100.2   UP    28       R3.01
R3             L2   Fa1/0       100.100.100.3   UP    7        R3.01

Now to prove the CSNP timer, lets look at what our debugs are telling us:

R1#
*Jun 24 16:58:10.267: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 16:58:10.267: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 16:58:10.267: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 16:58:10.267: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 16:58:10.267: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 16:58:10.267: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2
R1#
*Jun 24 16:58:19.467: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 16:58:19.471: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 16:58:19.471: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 16:58:19.471: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 16:58:19.471: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 16:58:19.475: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2
R1#
*Jun 24 16:58:27.639: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 16:58:27.643: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 16:58:27.643: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 16:58:27.643: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 16:58:27.643: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 16:58:27.643: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2

Roughly every 10 seconds R1 receives a L2 frame containing the CSNP from R3 (0000.0000.0003). So at least the theory is spot on. Now lets modify the timer to see if it kicks in:

R3(config)#
 R3(config)#int f1/0
 R3(config-if)#isis csnp-interval 20

So now on R1, we should see the CSNP arrive every 20 seconds instead:

R1#
*Jun 24 16:59:32.883: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 16:59:32.883: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 16:59:32.883: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 16:59:32.883: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 16:59:32.887: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 16:59:32.887: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2
R1#
*Jun 24 16:59:49.679: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 16:59:49.679: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 16:59:49.679: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 16:59:49.679: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 16:59:49.679: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 16:59:49.679: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2
R1#
*Jun 24 17:00:07.479: ISIS-Snp: Rec L2 CSNP from 0000.0000.0003 (FastEthernet1/0)
*Jun 24 17:00:07.483: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF
*Jun 24 17:00:07.483: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 6
*Jun 24 17:00:07.483: ISIS-SNP: Same entry 0000.0000.0002.00-00, seq 4
*Jun 24 17:00:07.483: ISIS-SNP: Same entry 0000.0000.0003.00-00, seq 3
*Jun 24 17:00:07.487: ISIS-SNP: Same entry 0000.0000.0003.01-00, seq 2

And lo and behold, its working!

Conclusion

With this command you have the ability to modify how often a DIS sends out the required CSNP (Complete Sequence Number PDU). Unless you have a certain requirement that requires you to change this timer, its default of 10 seconds should be able to scale to very large multi-access networks.

I hope the explanation of this timer has been useful to you.

isis retransmit-interval Vs. isis retransmit-throttle-interval

In this short post i want to try and shed some light on a couple of ISIS timers that had me confused at first. I think i got them down now, but please let me know if i have misunderstood them.

The timers in question is “isis retransmit-interval <seconds>” and “isis retransmit-throttle-interval <mseconds>“.

Both of these commands are only relevant on point-to-point links as no concept of a DIS is present here.

Lets start out with the simple topology of two routers in figure 1.

Figure 1

Figure 1

When R1 has some LSPs to send to R2 it sends them with a default interval of 33 ms (which is the “isis lsp-interval“).

This is shown in figure 2.

Figure 2

Figure 2

R1 expects an acknowledgement within the “isis retransmission-interval“, which is 5 seconds by default. The retransmission-interval specifies the interval between retransmissions of the same LSP.

In our example the 5 seconds pass and so R1 must retransmit the LSP’s to R2. R1 is now in its retransmission-window.

Now here’s where the second timer comes into play. Instead of sending the LSP’s which needs to be retransmitted with a 33ms delay between each of them, the “retransmit-throttle-interval” goes into effect and increase the time between the LSP’s from 33ms to 100ms.

This is shown in figure 3.

Figure 3

Figure 3

All of this is done in order to help R2 from staying over burdened. If the same LSP is not acknowledged within 5 seconds, the same LSP is retransmitted again per the retransmission-interval timer.

Configuration wise, it is very simple to configure. On IOS:

Current configuration : 179 bytes
!
interface FastEthernet1/0
ip address 10.1.2.1 255.255.255.0
ip router isis 1
speed auto
duplex auto
isis retransmit-throttle-interval 100
isis retransmit-interval 10
end

And on IOS-XR:

RP/0/0/CPU0:XR1(config-isis-if)#show config
Thu Jun 13 22:49:41.657 UTC
Building configuration...
!! IOS XR Configuration 3.9.1
router isis 1
interface POS0/6/0/0
retransmit-interval 10
retransmit-throttle-interval 100
address-family ipv4 unicast
!
!
!
end

I hope that helped clear up some confusion on these two timers. And again, if i have misunderstood anything, please let me know. Thanks!

References:
Cisco Documentation: http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_isis/command/irs-a1.html#wp1754145253

The complete IS-IS Routing Protocol: Amazon.co.uk

Another Lab lies ahead, round one.

This morning I booked my first go with the CCIE Service Provider lab exam. The battle is in mid November, so I have some time to study.

That also means that alot of forthcomming blog posts will be about CCIE SP material.
I will try and blog about all the tricky features comming my way and provide plenty of examples.

At the moment im very excited and at the same time very humble to have a go at the SP lab exam. When I saw my # the first time around, I never thought I would be going for a 2nd one.

Let the hard work begin.

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!

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/

Recertified & Plan

I have recertified by doing the SP written exam.

Took me a while, but now its done.

My plan is to hit the labs, starting with Narbik’s SP workbook, working my way through that one. That should keep me occupied for quite a while.

After that I plan on going to a SP bootcamp at some point in 2013. Which one and where im not sure of yet. It all depends on availability.

Finally, I will be doing the INE workbook.

An issue however, is rack availability. The Service Provider stuff includes IOS-XR which require a minimum of a 12000 series router, which doesnt come cheap.
Rack rental is also an option and at least INE now has open slots after adding some more racks.

I can do alot of Narbik’s labs on the hardware i have in my rack already, so there is no pressure in making a decision just yet.

Anyways, im off to it!

Class Based Tunnel Selection

In this post i would like to demonstrate the Class-Based Tunnel Selection feature.

In class-based tunnel selection, we will select an MPLS TE tunnel based on the incomming Precedence bit in the data.

For example, IP Prec 5 goes to TE Tunnel 1, whereas IP Prec 3 goes to TE Tunnel 2.

This sort of thing would be very useful for the SP if SLA’s are offered based on the incomming data. Think of voice for example. IP Prec 5 marked traffic would be voice and as it enters the SP network it automatically gets sent down the appropriate tunnel.

For the example, i will be using the topology shown in Figure 1.
The entire L2 VPN has been setup already so we will just focus on the TE Tunnels.

Topology for CB Tunnel Selection

Figure 1 outlines a typical SP network, with a customer using its L3 VPN service.

The end result is that we want to differentiate the tunnel selection based on what traffic enters PE-1 from CE-1 going to CE-2.

I will be using 3 IP Prec values:

0 = Best Effort
3 = High priority Data
5 = Voice

We will need their decimal values when we issue ICMP Pings from CE-1 to CE-2, so here they are:

0 = 0 = 0
3 = 011 000 00 = 96
5 = 101 000 00 = 160

I will be using 3 Tunnels originating from PE-1 terminating at PE-2.
These tunnels will be used to carry traffic with the 3 different IP Precedence values.

Tunnel 1 will go from PE-1 to P1 to PE-2.
Tunnel 2 will go from PE-1 to P2 to P3 to PE-2.
Tunnel 3 will go from PE-1 to P4 to PE-2.

Note that Tunnel 1 will carry IP Prec 0, but also all the other unassigned values (1, 2, 4, 6 and 7).

This tunnel layout can be seen in Figure 2

Topology with tunnels

On top of that i will be using Tunnel100 to be the “master” of the other three.
This tunnel will control which Tunnel member will be used for the forwarding.

Remember that TE tunnels are unidirectional. That means that the traffic engineering we are doing
here is only from PE-1 to PE-2, not from PE-2 to PE-1.

In the real world you would ofcourse do it both ways.

Lets take a look at the tunnel definitions on PE-1:

interface Tunnel1
ip unnumbered Loopback0
tunnel destination 7.7.7.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name TUNNEL1-PATH
tunnel mpls traffic-eng exp 0
end

interface Tunnel2
ip unnumbered Loopback0
tunnel destination 7.7.7.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name TUNNEL2-PATH
tunnel mpls traffic-eng exp 3
end

interface Tunnel3
ip unnumbered Loopback0
tunnel destination 7.7.7.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name TUNNEL3-PATH
tunnel mpls traffic-eng exp 5
end

And then the “main” tunnel:

interface Tunnel100
ip unnumbered Loopback0
tunnel destination 7.7.7.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member Tunnel1
tunnel mpls traffic-eng exp-bundle member Tunnel2
tunnel mpls traffic-eng exp-bundle member Tunnel3

We can issue the command: “show mpls traffic-eng exp” to verify our tunnel setup on PE-1:

PE-1#sh mpls traffic-eng exp

Destination: 7.7.7.7

Master: Tunnel100 Status: up

Members Status Conf Exp Actual Exp

Tunnel1 up (Active) 0 0 1 2 4 6 7
Tunnel2 up (Active) 3 3
Tunnel3 up (Active) 5 5

Everything looks as we expected. Tunnel 1 handles every but Prec 3 and 5.
Tunnel 2 handles Prec 3 and Tunnel 3 handles Prec 5.
We can verify on CE-1 and CE-2 that we are seeing the routes we expect through the L3 VPN.

on CE-1:

CE-1#sh ip route | beg Gate
Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
R 192.168.78.0/24 [120/10] via 192.168.12.2, 00:00:13, FastEthernet0/0
8.0.0.0/32 is subnetted, 1 subnets
R 8.8.8.8 [120/10] via 192.168.12.2, 00:00:13, FastEthernet0/0

and on CE-2:

CE-2#sh ip route | beg Gate
Gateway of last resort is not set

R 192.168.12.0/24 [120/10] via 192.168.78.7, 00:00:07, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/10] via 192.168.78.7, 00:00:07, FastEthernet0/0
C 192.168.78.0/24 is directly connected, FastEthernet0/0
8.0.0.0/32 is subnetted, 1 subnets
C 8.8.8.8 is directly connected, Loopback0

We can verify that our data forwarding works, by enabling “debug mpls pack” on P1, P2 and P4.

When we ping from CE-1 to CE-2 (using loopbacks), with the value 0, we expect to see traffic going through P1:

On CE-1:

CE-1#ping 8.8.8.8 so loo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, 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 = 56/65/76 ms

At the same time on P1:

*Sep 30 09:20:34.355: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.355: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.427: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.427: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.511: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data
*Sep 30 09:20:34.511: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 0 253} - ipv4 data
*Sep 30 09:20:34.575: MPLS turbo: Fa1/0: rx: Len 122 Stack {310 0 254} {709 0 254} - ipv4 data

If we then perform the same ping from CE-1, but with the IP Prec value of 3 (96 decimal), we expect the traffic to be on P2 instead:

on CE-1:

CE-1#ping
Protocol [ip]:
Target IP address: 8.8.8.8
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
Type of service [0]: 96
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 8.8.8.8, 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 = 52/64/84 ms

And sure enough, on P2:

*Sep 30 09:23:22.879: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:22.879: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:22.959: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:22.959: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:23.023: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data
*Sep 30 09:23:23.023: MPLS turbo: Fa1/1: tx: Len 122 Stack {510 3 253} {709 3 254} - ipv4 data
*Sep 30 09:23:23.087: MPLS turbo: Fa1/0: rx: Len 122 Stack {410 3 254} {709 3 254} - ipv4 data

Finally, lets verify with IP Prec 5 (160 decimal), we want to see the traffic hit P4:

on P4:

P4#Sep 30 09:25:10.959: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data
*Sep 30 09:25:10.991: MPLS turbo: Fa1/0: rx: Len 122 Stack {610 5 254} {709 5 254} - ipv4 data
*Sep 30 09:25:10.991: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 5 253} - ipv4 data
*Sep 30 09:25:11.023: MPLS turbo: Fa1/1: rx: Len 122 Stack {604 5 254} {209 5 254} - ipv4 data
*Sep 30 09:25:11.023: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data
*Sep 30 09:25:11.055: MPLS turbo: Fa1/0: rx: Len 122 Stack {610 5 254} {709 5 254} - ipv4 data
*Sep 30 09:25:11.055: MPLS turbo: Fa1/1: tx: Len 118 Stack {709 5 253} - ipv4 data
*Sep 30 09:25:11.083: MPLS turbo: Fa1/1: rx: Len 122 Stack {604 5 254} {209 5 254} - ipv4 data
*Sep 30 09:25:11.083: MPLS turbo: Fa1/0: tx: Len 118 Stack {209 5 253} - ipv4 data

Excellent! – So depending on how the traffic is marked comming from our customer, we will use different TE tunnels to forward the data through our SP core.

Thats all i had for now. Take care!