It’s been a while since I’ve written a new post, the last month or so has been very busy at work. I am also studying for the CCIE SP written exam, I don’t actually plan to take the lab exam at this time but I want to make sure my CCIE RS is renewed before everything changes in February. I am really excited for the new DevNet certifications and want to focus on those without having to worry about my CCIE expiring. Perhaps ill circle back around to SP and finish that up at some point, but for now the current goal is to just pass the written. This post doesn’t really have anything to do with programming or automation, but I felt like posting something. So I thought something short relevant to the content I am studying would work.
MPLS-TE has plenty of options to explore, however I wanted to take a look at explicit path options specifically. Something I found interesting about it is the ability it gives you to literally specify the exact label switch path you want to take from one PE to another PE, simply by making a list of the router IDs you wish to pass through. First of all lets look at some of the basic configuration needed to get MPLS TE working:
IOS XE:
mpls traffic-eng tunnels
!
interface GigabitEthernet2
mpls traffic-eng tunnels
ip rsvp bandwidth
!
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0Of course, you need and IGP and LDP set up throughout your core as well. In the above configuration you turn on mpls traffic-eng tunnels on globally. On every interface that you want to run MPLS-TE, you need to specify that you want to run mpls traffic-eng tunnels as well as ip rsvp bandwidth. You can specify an actual bandwidth that you want to be reservable by tunnels here, but just leaving it at the above command is enough to get things running. By default, this command will allow 75% of the physical interfaces bandwidth to be reserved. And finally, you need to enable your IGP to carry MPLS-TE information throughout your network. I am using OSPF above but you can of course use IS-IS. Tell your IGP which area (or level) you want to run MPLS-TE in and which address you want to use for the router-id. You need to configure all routers within the MPLS-TE path in your core with this configuration. Now, on the Source PE from which you want to use MPLS-TE to send traffic FROM you need to set up a tunnel:
R3
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 11.11.11.11
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
You need to use ip unnumbered with a /32 loopback IP address and tunnel destination of the PE you are wanting to reach. The “tunnel mpls traffic-eng autoroute announce” command is technically optional, however your routing table must have a route toward the desired PE pointing through the tunnel. You can do this with a static route pointing the destination PE to the tunnel interface, or simply use the command above to let the router take care of it. You will also need to specify the path-option. Here im basically telling the router to just get to the destination PE however you can, which is basically the IGPs decision with this particular command. Heres the equivalent configuration for XR:
IOS XR:
mpls traffic-eng
interface GigabitEthernet0/0/0/0
!
rsvp
interface GigabitEthernet0/0/0/0
bandwidth
!
router ospf 1
mpls traffic-eng router-id 11.11.11.11
area 0
mpls traffic-eng
!
interface tunnel-te1
ipv4 unnumbered Loopback0
autoroute announce
!
destination 3.3.3.3
path-option 10 dynamicBefore we start verification let me quickly show the topology i’m using. Router-ids will be used as follows:
XR1 11.11.11.11
XR2 12.12.12.12
XR3 13.13.13.13
R1 1.1.1.1
R2 2.2.2.2
R3 3.3.3.3
Between nodes a format of 10.first router.second router.router will be used. So between XR1 and R2 for example 10.2.11.11 on XR1 and 10.2.11.2 on R2. Most important thing to keep in mind is that the last octet identifies the router, this will make it easy to identify the path when looking at a traceroute. I'll be setting up a tunnel between XR1 and R3.
You can verify wether your tunnel is working or not by the interface status. You want to see both the Status and Protocl as “up” as well as the route to your destination PE pointing to the tunnel:
R3#show ip int br
Interface IP-Address OK? Method Status Protocol
Tunnel0 3.3.3.3 YES TFTP up up
R3#show ip route 11.11.11.11
Routing entry for 11.11.11.11/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 11.11.11.11 on Tunnel0, 00:15:54 ago
Routing Descriptor Blocks:
* 11.11.11.11, from 11.11.11.11, 00:15:54 ago, via Tunnel0
Route metric is 3, traffic share count is 1Check out the show ip route. The route for 11.11.11.11 is pointing to its self. Normally this would not work, but with MPLS-TE its perfectly fine. See below:
R3#ping 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 59/82/162 ms
R3#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
1 10.3.12.12 [MPLS: Label 24016 Exp 0] 90 msec 65 msec 78 msec
2 10.11.12.11 79 msec * 73 msec
R3# show mpls traffic-eng tunnels
P2P TUNNELS/LSPs:
Name: R3_t0 (Tunnel0) Destination: 11.11.11.11
InLabel : -
OutLabel : GigabitEthernet4, 24016
Next Hop : 10.3.12.12
RSVP Signalling Info:
Src 3.3.3.3, Dst 11.11.11.11, Tun_Id 0, Tun_Instance 16
RSVP Path Info:
My Address: 10.3.12.3
Explicit Route: 10.3.12.12 10.11.12.12 10.11.12.11 11.11.11.11 I have truncated some of the output above to show the important parts. First of all, you can see it works via ping. You can see in the trace route it goes to XR2 then its destination XR1. With show mpls traffic-eng tunnels, we can see that R3 understands it needs to push a label of 24016 on the packet and send it out Gi4 connected to XR2. So lets look at what XR2 does:
RP/0/0/CPU0:XR2#show mpls forwarding
Sat Sep 14 17:12:20.580 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24016 Pop TE: 0 Gi0/0/0/0 10.11.12.11 1371390 When a packet with label 24016 comes in it pops the label and sends the traffic out gi0/0/0/0 to XR1. Since XR1 is the final destination, XR2 knows to pop the top label. In this case, we are pinging XR1s loopback so a raw IP packet is sent at this point. Had the packet been destined to a CE connected to XR1, there would have been a VPNv4 label for XR1 to act accordingly on. Interestingly enough, XR2 is also aware of the MPLS-TE tunnels even though we did not configure and actual tunnel interface on it. All routers between your source and destination must successfully participate in the MPLE-TE topology as mentioned above with the configuration example.
MPLS-TE tunnels are unidrectional. Meaning the tunnel I just set up on R3 to XR1 is specifically and only a tunnel from R3 to XR1. XR1 will not necessarily use the same path back to R3 as R3 made to get to XR1. If you want to ensure the back and forth path is the same you would simply create a similar tunnel on XR1 destined to R3. Since we are using dynamic path-option so far, the path will be symmetrical since its just IGP making the decision at this point. In the next part, we will see how the paths are not necessarily going to be symmetrical.
Now the more interesting part. Lets say from R3 to XR1 we want to use this path: R3->XR2->XR3->R2->R1. Its not an efficient path and you probably aren’t going to have traffic loop around in production, but this shows what you can do pretty well. Heres the configuration for dictating the path:
IOS XE
ip explicit-path name toXR1 enable
index 10 next-address 12.12.12.12
index 15 next-address 13.13.13.13
index 20 next-address 2.2.2.2
index 25 next-address 11.11.11.11Yep, its as simple making a list of which routers (by router-id) that you want to pass through. You can set this up using sequence numbers (index). As always its a good idea to leave some room between statements to make it easier to insert something in the middle later. You can also make a list of routers you do NOT want to pass through instead. Instead of “next-address” you would use “exclude-address”. So I could tell R3 to take any path to XR1, as long as it doesn’t include R2 (2.2.2.2). You need to apply this explicit-path to the tunnel interface like this:
IOS XE
R3
interface Tunnel0
tunnel mpls traffic-eng path-option 10 explicit name toXR1
tunnel mpls traffic-eng path-option 15 dynamicOn the tunnel interface, you can also have a sequence of path-options. Here, our explicit path to XR1 has preference of 10, meaning it should be used as long as R3 can verify that path works. If that path doesn’t work, then R3 is allowed to dynamically figure out its own path due to the dynamic path-option with a preference of 15. Lower preference number is more preferred. So heres what happens now that we have added this explicit path:
R3#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
1 10.3.12.12 [MPLS: Label 24016 Exp 0] 96 msec 87 msec 91 msec
2 10.12.13.13 [MPLS: Label 24018 Exp 0] 95 msec 82 msec 99 msec
3 10.2.13.2 [MPLS: Label 31 Exp 0] 95 msec 91 msec 91 msec
4 10.2.11.11 88 msec * 118 msecIt does exactly what we told it to do. You can identify the router by the last octet of the IP in each hop. .12->.13->.2->.11 or XR2->XR3->R2->XR1. Heres an example of similar configuration for XR:
IOS XR
XR1
explicit-path name tor3
index 10 next-address strict ipv4 unicast 1.1.1.1
index 15 next-address strict ipv4 unicast 12.12.12.12
index 20 next-address strict ipv4 unicast 2.2.2.2
index 25 next-address strict ipv4 unicast 13.13.13.13
index 30 next-address strict ipv4 unicast 3.3.3.3
!
interface tunnel-te1
ipv4 unnumbered Loopback0
autoroute announce
!
destination 3.3.3.3
path-option 5 dynamic
path-option 10 explicit name tor3
Here I have XR1 building a tunnel to R3 with the path XR->R1->XR2->R2->XR3->R3. Heres the traceroute:
RP/0/0/CPU0:XR1#traceroute 3.3.3.3
Sat Sep 14 18:25:46.177 UTC
Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 10.1.11.1 [MPLS: Label 33 Exp 0] 159 msec 89 msec 79 msec
2 10.1.12.12 [MPLS: Label 24015 Exp 0] 69 msec 59 msec 69 msec
3 10.2.12.2 [MPLS: Label 31 Exp 0] 79 msec 199 msec 179 msec
4 10.2.13.13 [MPLS: Label 24017 Exp 0] 99 msec 59 msec 69 msec
5 10.3.13.3 69 msec * 49 msec It followed the path just as we described in the explicit-path.
Of course theres a lot more to MPLS-TE as a whole, but I found the explicit path options particularly interesting. So I picked this feature out to write a post about. Hopefully you have found it interesting as well.
