Segment Routing with RSVP-Traffic Engineering Tunnels

In the previous post we discussed setting up SR.

SR is now running but its relying on IGP for the shortest path through the SP core. RSVP-TE is used to choose the best route and not necessarily the shortest path. We'll pretend that the connections between XR1 and XR2, XR3 and XR4 are 10 Gbps connections, the rest of the network is 40 Gbps. The goal is to build a TE tunnel that will take the path XR1 > XR5 > XR6 > XR2 > XR3 > XR7 > XR8 > XR4, which will effectively bypass the slower links. There will also be a backup path option that will be able to take the direct XR1 > XR2 > XR3 > XR4 path.

The first thing that needs to be done is enabling MPLS Traffic Engineering, RSVP and enabling OSPF to support MPLS TE for area 0.


XR1 - XR8
router ospf 1
 area 0
  mpls traffic-eng
 !
 mpls traffic-eng router-id Loopback0


XR1
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.115


XR2
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.126


XR3
rsvp
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.137


XR4
rsvp
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.148


XR5
rsvp
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.115
 !
 interface GigabitEthernet0/0/0/0.156


XR6
rsvp
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
!
mpls traffic-eng
 !
 interface GigabitEthernet0/0/0/0.126
 !
 interface GigabitEthernet0/0/0/0.156
 !
 interface GigabitEthernet0/0/0/0.167


XR7
rsvp
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.137
 !
 interface GigabitEthernet0/0/0/0.167
 !
 interface GigabitEthernet0/0/0/0.178


XR8
rsvp
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.148
 !
 interface GigabitEthernet0/0/0/0.178

Now that we have built the TE topology, we can build the unidirectional tunnel from XR1 to XR4 via the path we laid out from above, there should also be another path option that follows the IGP path. The TE tunnel should advertise the TE tunnel as an IGP route.

XR1
explicit-path name SR_TE
 index 1 next-address strict ipv4 unicast 192.0.2.25
 index 2 next-address strict ipv4 unicast 192.0.2.26
 index 3 next-address strict ipv4 unicast 192.0.2.22
 index 4 next-address strict ipv4 unicast 192.0.2.23
 index 5 next-address strict ipv4 unicast 192.0.2.27
 index 6 next-address strict ipv4 unicast 192.0.2.28
 index 7 next-address strict ipv4 unicast 192.0.2.24
!
interface tunnel-te1
 ipv4 unnumbered Loopback0
 autoroute announce
 !
 destination 192.0.2.24
 path-option 5 explicit name SR_TE segment-routing
 path-option 10 segment-routing

RP/0/0/CPU0:XR1#sh ip int br
tunnel-te1                     192.0.2.21      Up              Up       default 

We can see that the tunnel was signaled successfully, if it wasn't the tunnel wouldn't not become up/up.

RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels 1 
Thu May 10 22:34:29.600 UTC


Name: tunnel-te1  Destination: 192.0.2.24  Ifhandle:0x680 
  Signalled-Name: XR1_t1
  Status:
    Admin:    up Oper:   up   Path:  valid   Signalling: connected

    path option 5, (Segment-Routing) type explicit SR_TE (Basis for Setup)
      Protected-by PO index: none
    path option 10,  type segment-routing 
    G-PID: 0x0800 (derived from egress interface properties)
    Bandwidth Requested: 0 kbps  CT0
    Creation Time: Thu May 10 21:31:07 2018 (01:03:23 ago)
  Config Parameters:
    Bandwidth:        0 kbps (CT0) Priority:  7  7 Affinity: 0x0/0xffff
    Metric Type: TE (default)
    Path Selection:
      Tiebreaker: Min-fill (default)
      Protection: any (default)
    Hop-limit: disabled
    Cost-limit: disabled
    Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
    AutoRoute:  enabled  LockDown: disabled   Policy class: not set
    Forward class: 0 (default)
    Forwarding-Adjacency: disabled
    Loadshare:          0 equal loadshares
    Auto-bw: disabled
    Path Protection: Not Enabled
    BFD Fast Detection: Disabled
    Reoptimization after affinity failure: Enabled
    SRLG discovery: Disabled
  History:
    Tunnel has been up for: 01:03:22 (since Thu May 10 21:31:08 UTC 2018)
    Current LSP:
      Uptime: 00:52:10 (since Thu May 10 21:42:20 UTC 2018)
    Prior LSP:
      ID: 2 Path Option: 10
      Removal Trigger: reoptimization completed

  Segment-Routing Path Info (OSPF 1 area 0)
    Segment0[Node]: 192.0.2.25, Label: 16025
    Segment1[Node]: 192.0.2.26, Label: 16026
    Segment2[Node]: 192.0.2.22, Label: 16022
    Segment3[Node]: 192.0.2.23, Label: 16023
    Segment4[Node]: 192.0.2.27, Label: 16027
    Segment5[Node]: 192.0.2.28, Label: 16028
    Segment6[Node]: 192.0.2.24, Label: 16024
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

The MPLS TE tunnel output shows that SR is being used to build the tunnel, meaning that SR labels will be used and not RSVP-TE which would be labels starting at 24000 and above. The current path being leveraged is option 5, the explicit path, which is defined above. 

RP/0/0/CPU0:XR1#sh route 192.0.2.24
Thu May 10 22:35:40.545 UTC

Routing entry for 192.0.2.24/32
  Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
  Installed May 10 21:31:09.200 for 01:04:31
  Routing Descriptor Blocks
    192.0.2.24, from 192.0.2.24, via tunnel-te1
      Route metric is 4
  No advertising protos. 

Expanding the route to XR4's loopback, we see that the path now follows the TE1 path and is using a labeled SR path.

RP/0/0/CPU0:XR1#sh cef 192.0.2.24
Thu May 10 22:35:56.954 UTC
192.0.2.24/32, version 46, internal 0x1000001 0x1 (ptr 0xa12b3a74) [1], 0x0 (0xa127f584), 0xa20 (0xa150d320)
 Updated May 10 21:31:09.460
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 192.0.2.24/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0f164f0 0xa0f16154]
    next hop 192.0.2.24/32
    local adjacency
     local label 24007      labels imposed {ImplNull}

Looking at the CEF table we can see label 24007 was allocated as adjacency SID since the TE1 tunnel is a new tunnel and therefore a label needs to be allocated.

RP/0/0/CPU0:XR1#sh mpls forwarding labels 24007
Thu May 10 22:50:33.174 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------

24007  Pop         192.0.2.24/32      tt1          192.0.2.24      0   

We can prove that by looking at what label 24007 was applied to, in this case it is the TE tunnel.

Once the tunnel is up, re-optimization maybe needed to take the explicit path.

RP/0/0/CPU0:XR1#mpls traffic-eng reoptimize 1

Now that we have a TE tunnel up and running, the routing table shows that traffic towards XR4 will take the TE tunnel. Let's do a trace from XR1 to XR4 and see what happens.

RP/0/0/CPU0:XR1#traceroute 192.0.2.24 source 192.0.2.21 num
Thu May 10 22:36:40.701 UTC

Type escape sequence to abort.
Tracing the route to 192.0.2.24

 1  100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024 Exp 0] 139 msec  119 msec  109 msec 
 2  100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024 Exp 0] 119 msec  109 msec  149 msec 
 3  100.64.126.12 [MPLS: Labels 16023/16027/16028/16024 Exp 0] 119 msec  119 msec  119 msec 
 4  100.64.123.13 [MPLS: Labels 16027/16028/16024 Exp 0] 129 msec  109 msec  119 msec 
 5  100.64.137.17 [MPLS: Labels 16028/16024 Exp 0] 109 msec  119 msec  119 msec 
 6  100.64.178.18 [MPLS: Label 16024 Exp 0] 119 msec  129 msec  109 msec 
 7  100.64.148.14 109 msec  *  109 msec 

We can see that the TE tunnel is being taken with the 7 SR label stack. This stack is encoded as it hits the ingress PE.

R1#ping 192.0.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/86/90 ms

R1#traceroute 192.0.2.2 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.101.11 19 msec 7 msec 10 msec
  2 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024/24004 Exp 0] 131 msec 133 msec 126 msec
  3 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024/24004 Exp 0] 143 msec 134 msec 123 msec
  4 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024/24004 Exp 0] 143 msec 129 msec 124 msec
  5 100.64.123.13 [MPLS: Labels 16027/16028/16024/24004 Exp 0] 140 msec 133 msec 126 msec
  6 100.64.137.17 [MPLS: Labels 16028/16024/24004 Exp 0] 141 msec 138 msec 124 msec
  7 100.64.178.18 [MPLS: Labels 16024/24004 Exp 0] 135 msec 132 msec 128 msec
  8 100.64.148.14 [MPLS: Label 24004 Exp 0] 130 msec 133 msec 127 msec
  9 100.64.103.2 133 msec *  136 msec

We see that in the above ping worked, but that doesn't showcase the SR TE output. The traceroute showcases the SR TE stack. The screenshot shows that the entire stack is encoded as traffic enters the SP core.

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS Traffic Engineering - TE Attributes - Path Options

Software versions:

IOS XE 15.5

IOS XR 5.3

The topology for this demo:

In this post we will take a look at the "path option" feature, which essentially determines how the TE tunnel will calculate its path. We can be either really "lazy" or really involved in this process, lazy with using the dynamic option and letting RSVP go out and find the shortest path and pretty much use IGPs path and call it a day. We could also use the explicit path option which allows us to have more control over where the traffic goes. We haven't covered PE to P LSPs yet for things like H-VPLS TE support, what we'll focus on here is R3 to XR3 and XR3 to R3 LSP signalling. The dynamic path option is the easiest and has been used so far in all of our testing so no reason to really break that out here. Let's focus on the explicit path and start there.

There are several ways to "code" the path, the "ip explicit-path" is the primary way. This method allows us to be really specific or be rather general. General in the sense I can give the path certain IPs that must be in the path and the others I may not care about. Other times I could give per interface path IPs and be really specific. Using the "loose" keyword allow us to specify the node we want to go through, but not necessarily how we go through. The strict keyword pretty much says you have to go through it. 

Our demo will start with leveraging the loose option and just build a TE tunnel path from R3 to XR3. The path we will take is XR4 to XR1 to R1 to XR5 to XR6 to R2 to XR3, not exactly direct but we want to exercise our capabilities. 

R3

ip explicit-path name LOOSE_TO_XR3 enable

 next-address loose 192.168.1.14

 next-address loose 192.168.1.11

 next-address loose 192.168.1.1

 next-address loose 192.168.1.15

 next-address loose 192.168.1.16

 next-address loose 192.168.1.2

 next-address loose 192.168.1.13

interface Tunnel4

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit name LOOSE_TO_XR3

R3#show mpls traffic-eng tunnels tunnel 4

Name: R3_t4                               (Tunnel4) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit LOOSE_TO_XR3 (Basis for Setup, path weight 1)

RSVP Path Info:

      My Address: 10.14.3.3

      Explicit Route: 10.14.3.14 192.168.1.14 192.168.1.11* 192.168.1.1*

                      192.168.1.15* 192.168.1.16* 192.168.1.2* 192.168.1.13*

Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15

                    10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2

                    10.13.2.2 10.13.2.13 192.168.1.13

As you can see above, we have configured our explicit path to use the TE ID of the nodes in the path to XR3. The * you see next to each of the router IDs is the indication of a loose path. The explicit path noted below the RSVP path is the actual path that will be taken from R3 to XR3. 

Now let's take a look at an strict explicit path.

R3

ip explicit-path name STRICT_TO_XR3 enable

 next-address 192.168.1.4

 next-address 192.168.1.15

 next-address 192.168.1.1

 next-address 192.168.1.12

 next-address 192.168.1.13

interface Tunnel5

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng priority 4 4

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit name STRICT_TO_XR3

R3#show mpls traffic-eng tunnels tunnel 5

Name: R3_t5                               (Tunnel5) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit STRICT_TO_XR3 (Basis for Setup, path weight 5)

RSVP Path Info:

      My Address: 10.3.4.3

      Explicit Route: 10.3.4.4 10.15.4.4 10.15.4.15 10.1.15.15

                      10.1.15.1 10.1.12.1 10.1.12.12 10.12.13.12

                      10.12.13.13 192.168.1.13

Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15

                    10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2

                    10.13.2.2 10.13.2.13 192.168.1.13

As you can see, the RSVP path is configured to use R4 to XR5 to R1 to XR2 to XR3. I don't have a static route or other traffic to tunnel mapping mechanism in place for this TE tunnel, so this path is simply a different output to show you the difference. The Other explicit route is the route that falls under the "Shortest Unconstrained Path" in the network, basically, this is the LDP path in the network. The RSVP path is the one that will be followed.

The next option is the "identifier" where state which devices we want the TE tunnel to go through.

ip explicit-path identifier 1 enable

 next-address 192.168.1.4

 next-address 192.168.1.5

 next-address 192.168.1.6

 next-address 192.168.1.2

 next-address 192.168.1.16

 next-address 192.168.1.15

 next-address 192.168.1.14

 next-address 192.168.1.11

 next-address 192.168.1.1

 next-address 192.168.1.12

 next-address 192.168.1.13

interface Tunnel6

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit identifier 1

ip route 192.168.1.13 255.255.255.255 Tunnel6

R3#show mpls traffic-eng tunnels tunnel 6

Name: R3_t6                               (Tunnel6) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit 1 (Basis for Setup, path weight 11)

RSVP Path Info:

      My Address: 10.3.4.3

      Explicit Route: 10.3.4.4 10.4.5.4 10.4.5.5 10.5.6.5

                      10.5.6.6 10.2.6.6 10.2.6.2 10.16.2.2

                      10.16.2.16 10.15.16.16 10.15.16.15 10.14.15.15

                      10.14.15.14 10.11.14.14 10.11.14.11 10.1.11.11

                      10.1.11.1 10.1.12.1 10.1.12.12 10.12.13.12

                      10.12.13.13 192.168.1.13

This path hits every router in the MPLS core, intentionally configured to show you it could be done that way. I also configured a static route pointing towards XR3 to use Tunnel 6. 

R3# traceroute mpls traffic-eng tunnel 6

Type escape sequence to abort.

  0 10.3.4.3 MRU 1500 [Labels: 28 Exp: 0]

L 1 10.3.4.4 MRU 1500 [Labels: 42 Exp: 0] 10 ms

L 2 10.4.5.5 MRU 1500 [Labels: 36 Exp: 0] 3 ms

L 3 10.5.6.6 MRU 1500 [Labels: 26 Exp: 0] 5 ms

L 4 10.2.6.2 MRU 1500 [Labels: 24013 Exp: 0] 4 ms

L 5 10.16.2.16 MRU 1500 [Labels: 24014 Exp: 0] 10 ms

L 6 10.15.16.15 MRU 1500 [Labels: 24010 Exp: 0] 17 ms

L 7 10.14.15.14 MRU 1500 [Labels: 24026 Exp: 0] 15 ms

L 8 10.11.14.11 MRU 1500 [Labels: 40 Exp: 0] 18 ms

L 9 10.1.11.1 MRU 1500 [Labels: 24014 Exp: 0] 11 ms

L 10 10.1.12.12 MRU 1500 [Labels: implicit-null Exp: 0] 17 ms

! 11 10.12.13.13 17 ms

Let's do a little recursion to make sure we still know how to figure out where the TE label gets allocated and why.

R3#show ip route 192.168.1.13

Routing entry for 192.168.1.13/32

  Known via "static", distance 1, metric 0 (connected)

  Routing Descriptor Blocks:

  * directly connected, via Tunnel6

      Route metric is 0, traffic share count is 1

R3#sh ip cef 192.168.1.13 detail

192.168.1.13/32, epoch 2, flags [attached]

  local label info: global/30

  3 RR sources [non-eos indirection, heavily shared]

  attached to Tunnel6

R3#sh mpls forwarding-table labels 30 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

30         Pop Label  192.168.1.13/32  0             Tu6        point2point

        MAC/Encaps=18/22, MRU=1500, Label Stack{28}, via Gi1.34

        000C2924DCA2000C29062644810000228847 0001C000

        No output feature configured

We will first look at the RIB, we see that traffic to XR3s loopback will be sent out Tunnel 6, if we do a CEF lookup we can see that a local global label of 30 has been allocated to that prefix. We can use that now in the MPLS lookup and see that 30 is the local label, label 28 is the outgoing label and it points out Tunnel 6.

Let's checkout XR3 now, we can also configure path options on XR3. They are almost identical in XR so I'll only show you the TE tunnel to R3 I created to show some basic verification against.

XR3

explicit-path identifier 1

 index 1 next-address strict ipv4 unicast 192.168.1.2

 index 2 next-address strict ipv4 unicast 192.168.1.6

 index 3 next-address strict ipv4 unicast 192.168.1.5

 index 4 next-address strict ipv4 unicast 192.168.1.4

 index 5 next-address strict ipv4 unicast 192.168.1.3

interface tunnel-te2

 ipv4 unnumbered Loopback0

 destination 192.168.1.3

 affinity ignore

 path-option 1 explicit identifier 1

RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels 2

Sun Feb  5 03:18:33.883 UTC

Name: tunnel-te2  Destination: 192.168.1.3  Ifhandle:0x780

  Signalled-Name: XR3_t2

  Status:

    Admin:    up Oper:   up   Path:  valid   Signalling: connected

Node hop count: 5

  Hop0: 10.13.2.2

  Hop1: 10.2.6.2

  Hop2: 10.2.6.6

  Hop3: 10.5.6.6

  Hop4: 10.5.6.5

  Hop5: 10.4.5.5

  Hop6: 10.4.5.4

  Hop7: 10.3.4.4

  Hop8: 10.3.4.3

  Hop9: 192.168.1.3

We can see that the tunnel was successfully signalled and the path was built. Slightly different output from IOS but it still makes sense. I created a static route to point to R3 for verification purposes.

router static

 address-family ipv4 unicast

  192.168.1.3/32 tunnel-te2

RP/0/0/CPU0:XR3#sh cef 192.168.1.3 detail | in label

Sun Feb  5 03:20:18.416 UTC

     local label 24013      labels imposed {ImplNull}

RP/0/0/CPU0:XR3#show mpls traffic-eng forwarding p2p tunnel-id 2 detail

Sun Feb  5 03:21:07.423 UTC

P2P tunnels:

Tunnel ID:    2 LSP ID:    2 Destination:     192.168.1.3 Ctype:  7

  Source:    192.168.1.13 Ext Tun ID:    192.168.1.13

  Output: Gi0/0/0/0.132     Next Hop: 10.13.2.2       Output Label: 29

  Input:  -                 Prev Hop: None            Local Label:  24028

RP/0/0/CPU0:XR3#traceroute mpls traffic-eng tunnel-te 2 lsp active

Type escape sequence to abort.

  0 10.13.2.13 MRU 1500 [Labels: 29 Exp: 0]

L 1 10.13.2.2 MRU 1500 [Labels: 37 Exp: 0] 0 ms

L 2 10.2.6.6 MRU 1500 [Labels: 43 Exp: 0] 10 ms

L 3 10.5.6.5 MRU 1500 [Labels: 29 Exp: 0] 10 ms

L 4 10.4.5.4 MRU 1500 [Labels: implicit-null Exp: 0] 0 ms

! 5 10.3.4.3 10 ms

The routing table has R3s loopback pointed out Tunnel 2, the CEF output states that local label 24013 will be used. IOS XR has a separate but equally important traffic-eng forwarding table for us to leverage, we see that label 29 will be used for outbound forwarding. A MPLS trace proves that label 29 will be used as the transport label to R3.

As you can see, the path option is very handy in situations like this, being able to manipulate the forwarding is key in modern networks. 

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS Traffic Engineering - TE Attributes - Affinity and Attribute flags

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will look at the link "affinity" that can be used to selectively include or exclude link(s) from being in the transit path from the TE head end to the tail end. The idea of the link affinity or link color is to label an interface with a set of values that could be mapped to SLA or service level agreement. Blue could be bulk traffic, Green could be transactional data, Red could be low latency and Orange could be high bandwidth. The idea is to use the "affinity" or attribute flags at the interface level so RSVP would know if that link is or is not to be used for TE forwarding. 

For those familiar with the ACL or Access Control Lists, the idea with the "anding" values is to use bits in the "wildcard" mask to directly map to the prefix to determine the level of match. Where a "0" means "This matters" or "must match" and the "1" means "this doesn't matter" or "I don't care". TE uses the reverse in it's logic, "1" means to match and "0" means to disregard. So when the TE tunnel is configured, if no "affinity" values are configured at the tunnel level and "attribute flags" are configured at the interface level, the tunnel will fail to come up.

The Affinity colors on the individual links directly correlate to a specific attribute flag configured at the interface level, specifying an affinity match value is required in our topology to allow RSVP to signal an end to end path.

R1

interface GigabitEthernet1.111

 mpls traffic-eng attribute-flags 0x6

!

interface GigabitEthernet1.115

 mpls traffic-eng attribute-flags 0x1011

R3

interface GigabitEthernet1.34

 mpls traffic-eng attribute-flags 0x1011

!

interface GigabitEthernet1.143

 mpls traffic-eng attribute-flags 0x110

R4

interface GigabitEthernet1.34

 mpls traffic-eng attribute-flags 0x1011

!

interface GigabitEthernet1.154

 mpls traffic-eng attribute-flags 0x1111

XR1

mpls traffic-eng

 interface GigabitEthernet0/0/0/0.111

  attribute-flags 0x110

 !

 interface GigabitEthernet0/0/0/0.1114

  attribute-flags 0x101

XR4

mpls traffic-eng

 interface GigabitEthernet0/0/0/0.143

  attribute-flags 0x110

 !

 interface GigabitEthernet0/0/0/0.1114

  attribute-flags 0x101

 !

 interface GigabitEthernet0/0/0/0.1415

  attribute-flags 0x1111

XR5

mpls traffic-eng

 interface GigabitEthernet0/0/0/0.115

  attribute-flags 0x1011

 !

 interface GigabitEthernet0/0/0/0.154

  attribute-flags 0x1111

 !

 interface GigabitEthernet0/0/0/0.1415

  attribute-flags 0x1111

R3

interface Tunnel1

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.1

 tunnel mpls traffic-eng path-option 1 dynamic

The result:

TE-PCALC: 192.168.1.3_364->192.168.1.1_1 {7}: Path Request Info

  Flags:  METRIC_TE

  IP explicit-path: None (dynamic)

  bw 0, min_bw 0, metric: 0

  setup_pri 7, hold_pri 7

  affinity_bits 0x0, affinity_mask 0xFFFF

TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Area (ospf 1  area 0) Path Lookup begin

TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Get path: Failed to find a path to destination

TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Area (ospf 1  area 0) Path Lookup end: path not found

TE-PCALC-API: 192.168.1.3_364->192.168.1.1_1 {7}: P2P LSP Path Lookup result: failed

The problem is that no affinity values were set, and every path from R3 to R1 has some attribute flag value configured, so when the RSVP PATH message tries to begin, it immediately fails due to the lack of TE tunnel affinity configuration.

R3#sh mpls traffic-eng tunnels tunnel 1

Name: R3_t1                               (Tunnel1) Destination: 192.168.1.1

  Status:

    Admin: up         Oper: down   Path: not valid   Signalling: Down

The operational state, Path and Signaling are all down or not valid.

To fix this we need to configure R3s TE Tunnel 1 with an appropriate affinity value and mask combination that will allow an end to end match to be made, this can be a combination of yes to Green and no to Red along the same path. We'll take a look at how that works later. For now, a simple affinity value and mask config at the TE tunnel level will suffice. Once configured, we'll have to flap the tunnel interface to force an RSVP PATH message

interface Tunnel1

 tunnel mpls traffic-eng affinity 0x0001 mask 0x0001

TE-PCALC-API: 192.168.1.3_394->192.168.1.1_1 {7}: P2P LSP Path Lookup called

TE-PCALC: 192.168.1.3_394->192.168.1.1_1 {7}: Path Request Info

  Flags:  METRIC_TE

  IP explicit-path: None (dynamic)

  bw 0, min_bw 0, metric: 0

  setup_pri 7, hold_pri 7

  affinity_bits 0x1, affinity_mask 0x1

TE-PCALC-PATH: 192.168.1.3_394->192.168.1.1_1 {7}: Area (ospf 1  area 0) Path Lookup begin

TE-PCALC-PATH:Path from 192.168.1.3 -> 192.168.1.1:

  10.1.15.1->0.0.0.0 (admin_weight=3):

  10.1.15.15->0.0.0.0 (admin_weight=3):

  10.15.4.15->0.0.0.0 (admin_weight=2):

  10.15.4.4->0.0.0.0 (admin_weight=2):

  10.3.4.4->0.0.0.0 (admin_weight=1):

  10.3.4.3->0.0.0.0 (admin_weight=1):

  num_hops 7, accumulated_aw 3, min_bw 0

TE-PCALC-PATH: 192.168.1.3_394->192.168.1.1_1 {7}: Area (ospf 1  area 0) Path Lookup end: path found

TE-PCALC-API: 192.168.1.3_394->192.168.1.1_1 {7}: P2P LSP Path Lookup result: success

Calling ext path_addmodify arginfo: 0x7EFF4BF8B540, avg: 0, peak: N/A, burst: 0x3E8

   mtu: N/A, qos: N/A,hint: 0x1600018A, new: TRUE, sub_lsp: 0x7EFF4C446020

*Jan 24 22:53:14.446: %MPLS_TE-5-TUN: Tun1: installed LSP 1_394 (popt 1) for nil, got 1st feasible path opt

RSVP: session 192.168.1.1_1[192.168.1.3] (7): Received Resv message from 10.3.4.4 (on GigabitEthernet1.34)

RSVP: 192.168.1.3_394->192.168.1.1_1[Src] {7}: Successfully parsed Resv message from 10.3.4.4 (on GigabitEthernet1.34)

RSVP: 192.168.1.3_394->192.168.1.1_1[Src] {7}: reservation not found--new one

*Jan 24 22:53:14.564: %MPLS_TE-5-LSP: LSP 192.168.1.3 1_394: UP

RSVP-RESV: Admitting new reservation: 7EFF4BFFC110

RSVP-RESV: reservation (RSB 0x7EFF4BFFC110) was installed on GigabitEthernet1.34

*Jan 24 22:53:14.564: %MPLS_TE-5-TUN: Tun1: LSP path change 1_394 for nil, normal

*Jan 24 22:53:14.568: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

R3#sh mpls traffic-eng tunnels tunnel 1 | sec Affinity

    Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x1/0x1

RSVP

10.3.4.4 10.15.4.4 10.15.4.15 10.1.15.15

                      10.1.15.1 192.168.1.1

By setting an affinity value that is matchable at the interface level, the RSVP PATH messages make it all the way down to R1 and the RSVP RESV messages make it all the way back to R3.

R3#sh mpls traffic-eng tunnels tunnel 1

Name: R3_t1                               (Tunnel1) Destination: 192.168.1.1

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type dynamic (Basis for Setup, path weight 3)

R3#sh ip rsvp reservation detail filter session-type 7 tunnel-id 1 | b Label

  Label: 23 (outgoing)

We can see that label 23 was assigned via RSVP-TE.

R3#sh ip cef 192.168.1.1 detail

192.168.1.1/32, epoch 2, flags [attached]

  local label info: global/32

  3 RR sources [non-eos indirection, heavily shared]

  attached to Tunnel1

Local label 32 was assigned and we can use the MPLS forwarding table to see the detailed output for that.

R3#sh mpls forwarding-table labels 32 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

32         Pop Label  192.168.1.1/32   0             Tu1        point2point

        MAC/Encaps=18/22, MRU=1500, Label Stack{23}, via Gi1.34

        000C2924DCA2000C29062644810000228847 00017000

        No output feature configured

Label 23 is the label stack to get us to our next hop of R4.

R3#traceroute 192.168.1.1 source lo0 num

Type escape sequence to abort.

Tracing the route to 192.168.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 10.3.4.4 [MPLS: Label 23 Exp 0] 5 msec 3 msec 3 msec

  2 10.15.4.15 [MPLS: Label 24000 Exp 0] 20 msec 7 msec 8 msec

  3 10.1.15.1 7 msec *  8 msec

And the traceroute proves that we are taking the appropriate path. Let's test the end to end reachability from R8 to R13.

R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num

Type escape sequence to abort.

Tracing the route to 13.13.13.13

VRF info: (vrf in name/id, vrf out name/id)

  1 83.0.0.3 3 msec 1 msec 1 msec

  2 10.3.4.4 [MPLS: Labels 23/28 Exp 0] 8 msec 7 msec 7 msec

  3 10.15.4.15 [MPLS: Labels 24000/28 Exp 0] 28 msec 31 msec 31 msec

  4 131.0.0.1 [MPLS: Label 28 Exp 0] 17 msec 15 msec 15 msec

  5 131.0.0.13 20 msec *  11 msec

As you can see, we take the TE path.

We can also tell TSVP-TE via affinity bits to not use a path that has a certain color. For instance we could tell RSVP to avoid paths where the color Orange is applied.

interface Tunnel1

 tunnel mpls traffic-eng affinity 0x0 mask 0x8

R3#sh mpls traffic-eng tunnels tunnel 1

Name: R3_t1                               (Tunnel1) Destination: 192.168.1.1

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type dynamic (Basis for Setup, path weight 3)

R3#sh mpls traffic-eng tunnels tunnel 1 | b RSVP

  RSVP Signalling Info:

       Src 192.168.1.3, Dst 192.168.1.1, Tun_Id 1, Tun_Instance 396

    RSVP Path Info:

      My Address: 10.14.3.3

      Explicit Route: 10.14.3.14 10.11.14.14 10.11.14.11 10.1.11.11

                      10.1.11.1 192.168.1.1

You can see that the path changed to avoid any links where the color Orange was applied.

R3#sh ip cef 192.168.1.1 detail

192.168.1.1/32, epoch 2, flags [attached]

  local label info: global/32

  3 RR sources [non-eos indirection, heavily shared]

  attached to Tunnel1

R3#sh mpls forwarding-table labels 32 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

32         Pop Label  192.168.1.1/32   0             Tu1        point2point

        MAC/Encaps=18/22, MRU=1500, Label Stack{24001}, via Gi1.143

        000C29769933000C290626448100008F8847 05DC1000

        No output feature configured

You can see that a new label, 24001 has been issued with a next hop of XR4.

R3#traceroute 192.168.1.1 source lo0 num

Type escape sequence to abort.

Tracing the route to 192.168.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 10.14.3.14 [MPLS: Label 24001 Exp 0] 6 msec 5 msec 4 msec

  2 10.11.14.11 [MPLS: Label 24001 Exp 0] 6 msec 6 msec 6 msec

  3 10.1.11.1 8 msec *  10 msec

The test is to see what path we take in the network now that we are avoiding the Orange links.

R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num

Type escape sequence to abort.

Tracing the route to 13.13.13.13

VRF info: (vrf in name/id, vrf out name/id)

  1 83.0.0.3 3 msec 1 msec 1 msec

  2 10.14.3.14 [MPLS: Labels 24001/28 Exp 0] 7 msec 10 msec 7 msec

  3 10.11.14.11 [MPLS: Labels 24001/28 Exp 0] 27 msec 31 msec 65 msec

  4 131.0.0.1 [MPLS: Label 28 Exp 0] 11 msec 7 msec 7 msec

  5 131.0.0.13 7 msec *  9 msec

It is working as expected. 

There are several other matching variations we could test out. I will leave those for upcoming posts.

Thanks for stopping by!

Rob Riker, CCIE #50693