MPLS TE - Affinity
I’ll use the following topology:
The basic idea about MPLS TE affinity is to add an attribute to a link and be able to include or exclude this link during path calculation. The concept is also known as link coloring.
Affinity is configured on links using the mpls traffic-eng attribute-flags <0x0-0xFFFFFFFF> interface command. The values is expressed in a 32-bit hexadecimal number. By default a link has the number 0 (or 0x0).
To match attributes we set affinity and a mask under our MPLS TE tunnel using the command tunnel mpls traffic-eng affinity <0x0-0xFFFFFFFF> mask <0x0-0xFFFFFFFF> interface command.
The mask works just like a regular subnet mask, meaning if a bit is set, we’re matching whatever value of the attribute-flag. The default value for an MPLS TE tunnel is 0x0 mask 0xFFFF. This means that the least significant 16 bits of attribute-flags must be zeros.
With the above topology we have a path with an attribute of 2 and one with an attribute of 4. The first and last hop over these paths have an attribute of 0 (the default).
This gives us these values in binary:
So if we wanted to avoid the 0x2 path, we’d need the following:
The reason why we’re ending up with matching 0x0 mask 0x1011, is that we do not want to match the number 2 (0010). So the second least significant bit (0100) must be 0 in order to match the R2-R5-R6-R4 path. And because the second most significant bit (0100) is 1 and we must include the links of R1 and R7 we must NOT care about this bit, which is why the mask is 0 for this bit position.
Therefore the configuration of R1 could look like this:
interface Tunnel17 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 188.8.131.52 tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng affinity 0x0 mask 0xB tunnel mpls traffic-eng path-option 1 dynamic
We can verify this using the command sh mpls traffic-eng tunnels:
R1#sh mpls traffic-eng tunnels tunnel 17 | sec Path_Info: RSVP Path Info: My Address: 10.1.2.1 Explicit Route: 10.1.2.2 10.2.5.5 10.5.6.6 10.4.6.4 10.4.7.7 184.108.40.206 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 40 (TE) Explicit Route: 10.1.2.2 10.2.3.3 10.3.4.4 10.4.7.7 220.127.116.11 R1#
This output is very nice since it lets us know both the path it is using (RSVP Path Info) and the path it could have used without cSPF (Shortest Unconstrained Path Info). It is easy to see that the path used is our “4” path (R2-R5-R6-R4) which is what we wanted.
Dealing with MPLS TE affinity can be complicated. Changing the attribute-flag (color) of a link, can cause MPLS TE tunnels to go down. If we were to change the link between R4 and R7 to 0x1, the tunnel on R1 should go down. Let’s try it out:
R1#sh mpls traffic-eng topology 18.104.22.168 | in Intf_Add|flags: frag_id: 0, Intf Address: 10.4.6.4, Nbr Intf Address: 10.4.6.6 TE metric: 10, IGP metric: 10, attribute flags: 0x4 frag_id: 0, Intf Address: 10.3.4.4, Nbr Intf Address: 10.3.4.3 TE metric: 10, IGP metric: 10, attribute flags: 0x2 frag_id: 0, Intf Address: 10.4.7.4, Nbr Intf Address: 10.4.7.7 TE metric: 10, IGP metric: 10, attribute flags: 0x1 R1#
First I changed the link to R7 on R4 to 0x1 as we can see in our TED (Traffic Engineering Database). Let’s look at how our tunnel is doing:
R1#sh mpls traffic-eng tunnels tunnel 17 Name: R1_t17 (Tunnel17) Destination: 22.214.171.124 Status: Admin: up Oper: down Path: not valid Signalling: Down path option 1, type dynamic Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xB Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 0  bw-based auto-bw: disabled Shortest Unconstrained Path Info: Path Weight: 40 (TE) Explicit Route: 10.1.2.2 10.2.3.3 10.3.4.4 10.4.7.7 126.96.36.199 History: Tunnel: Time since created: 1 days, 12 hours, 53 minutes Time since path change: 3 minutes, 33 seconds Number of LSP IDs (Tun_Instances) used: 422 Prior LSP: [ID: 411] ID: path option 1  Removal Trigger: path verification failed Last Error: CTRL:: No path to destination, 0070.0700.7007.00 (affinity) R1#
Signalling is Down and at the bottom we see why. Last Error: CTRL:: No path to destination, 0070.0700.7007.00 (affinity). This is because we can no longer find a path that satisfies our affinity constraint. We are not matching 0x1 with our mask. We are looking for a 0x0 which we can’t find no matter which way we go.
We can ask the router to look for the path like this:
R1#sh mpls traffic-eng topology path destination 188.8.131.52 affinity 0x0 mask 0xB Query Parameters: Destination: 184.108.40.206 Bandwidth: 0 Priorities: 0 (setup), 0 (hold) Affinity: 0x0 (value), 0xB (mask) Query Results: % No matching path to destination, 220.127.116.11 R1#
If we were to change the mask to 1010 (binary), we might get a path:
R1#sh mpls traffic-eng topology path destination 18.104.22.168 affinity 0x0 mask 0xA Query Parameters: Destination: 22.214.171.124 Bandwidth: 0 Priorities: 0 (setup), 0 (hold) Affinity: 0x0 (value), 0xA (mask) Query Results: Min Bandwidth Along Path: 750000 (kbps) Max Bandwidth Along Path: 750000 (kbps) Hop 0: 10.1.2.1 : affinity 0x00000000, bandwidth 750000 (kbps) Hop 1: 10.2.5.2 : affinity 0x00000004, bandwidth 750000 (kbps) Hop 2: 10.5.6.5 : affinity 0x00000004, bandwidth 750000 (kbps) Hop 3: 10.4.6.6 : affinity 0x00000004, bandwidth 750000 (kbps) Hop 4: 10.4.7.4 : affinity 0x00000001, bandwidth 750000 (kbps) Hop 5: 126.96.36.199 R1#
Sure enough, now we’re matching the complete path.
That’s all for now. I hope you’ve enjoyed this post.