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:
path
hexadecimal
binary
R1-R2
0x0
0000
R2-R3-R4
0x2
0010
R2-R5-R6-R4
0x4
0100
R4-R7
0x0
0000
So if we wanted to avoid the 0x2 path, we’d need the following:
affinity (bin)
mask (bin)
affinity (hex)
mask (hex)
0000
1011
0x0
0xB
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 7.7.7.7
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 7.7.7.7
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
7.7.7.7
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 4.4.4.4 | 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: 7.7.7.7
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 [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
7.7.7.7
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 [422]
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 7.7.7.7 affinity 0x0 mask 0xB
Query Parameters:
Destination: 7.7.7.7
Bandwidth: 0
Priorities: 0 (setup), 0 (hold)
Affinity: 0x0 (value), 0xB (mask)
Query Results:
% No matching path to destination, 7.7.7.7
R1#
If we were to change the mask to 1010 (binary), we might get a path:
R1#sh mpls traffic-eng topology path destination 7.7.7.7 affinity 0x0 mask 0xA
Query Parameters:
Destination: 7.7.7.7
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: 7.7.7.7
R1#
Sure enough, now we’re matching the complete path.
That’s all for now. I hope you’ve enjoyed this post.
