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 0
Of 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 18.104.22.168 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 22.214.171.124 area 0 mpls traffic-eng ! interface tunnel-te1 ipv4 unnumbered Loopback0 autoroute announce ! destination 126.96.36.199 path-option 10 dynamic
Before we start verification let me quickly show the topology i’m using. Router-ids will be used as follows:
XR1 188.8.131.52 XR2 184.108.40.206 XR3 220.127.116.11 R1 18.104.22.168 R2 22.214.171.124 R3 126.96.36.199 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 188.8.131.52 YES TFTP up up R3#show ip route 184.108.40.206 Routing entry for 220.127.116.11/32 Known via "ospf 1", distance 110, metric 3, type intra area Last update from 18.104.22.168 on Tunnel0, 00:15:54 ago Routing Descriptor Blocks: * 22.214.171.124, from 126.96.36.199, 00:15:54 ago, via Tunnel0 Route metric is 3, traffic share count is 1
Check out the show ip route. The route for 188.8.131.52 is pointing to its self. Normally this would not work, but with MPLS-TE its perfectly fine. See below:
R3#ping 184.108.40.206 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 59/82/162 ms R3#traceroute 18.104.22.168 Type escape sequence to abort. Tracing the route to 22.214.171.124 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: 126.96.36.199 InLabel : - OutLabel : GigabitEthernet4, 24016 Next Hop : 10.3.12.12 RSVP Signalling Info: Src 188.8.131.52, Dst 184.108.40.206, 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 220.127.116.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 18.104.22.168 index 15 next-address 22.214.171.124 index 20 next-address 126.96.36.199 index 25 next-address 188.8.131.52
Yep, 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 (184.108.40.206). 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 dynamic
On 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 220.127.116.11 Type escape sequence to abort. Tracing the route to 18.104.22.168 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 msec
It 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 22.214.171.124 index 15 next-address strict ipv4 unicast 126.96.36.199 index 20 next-address strict ipv4 unicast 188.8.131.52 index 25 next-address strict ipv4 unicast 184.108.40.206 index 30 next-address strict ipv4 unicast 220.127.116.11 ! interface tunnel-te1 ipv4 unnumbered Loopback0 autoroute announce ! destination 18.104.22.168 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 22.214.171.124 Sat Sep 14 18:25:46.177 UTC Type escape sequence to abort. Tracing the route to 126.96.36.199 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.