MPLS TE Affinity Attribute

This topic is to discuss the following lesson:

Hi Rene,

Thank you so much for your post. Your SP topics are really well explained, and are helping me study for my SP core exam here coming up.

Understanding these attributes has been such a pain for me because of the way people explain it. You explained it extremely well and I think I get it. I wanted to confirm with you if I understood it correctly.

Below I came up with my own table of TE attributes, along with requirements. Can you tell me if I got the requirements correct or not?

0x2 = high speed links - 0000 0010
0x4 = low speed links - 0000 0100
0x10 = low latency links - 0001 0000
0x12 = high latency links - 0001 0010
0x8 = commercial ISP links - 0000 1000
0x13 = starlink satellite links - 0001 0011

Only use high speed links, as well as low latency links.

  • tunnel mpls traffic-eng affinity 0x12 mask 0x12

Exclude commerical ISP links.

  • tunnel mpls traffic-eng affinity 0x0 mask 0x8

Use low latency links, and low speed links, exclude everything else.

  • tunnel mpls traffic-eng affinity 0x14 mask 0xff

Use starlink sattelite links, and high latency links. Don’t care about the rest.

  • tunnel mpls traffic-eng affinity 0x25 mask 0xff

Hello Victor

Notice the following phrase in the lesson:

An attribute flag is 32-bit, meaning you can use this to define 32 separate properties on a link. It’s written in hexadecimal and, by default, all set to zeroes.

You must remember that this 32-bit value is actually a flag. Flag means that it indicates a boolean function, either 1 or 0. So you can actually think of the attribute flag as a series of 32 bit flags. Take a look at this NetworkLessons note on best practices for choosing your attribute flags.

Now in your case, you have overlapping flags because you are using multiple bits for certain link types. So you can’t successfully exclude or include specific traffic unless you follow the best practice in the note, and make the flags unique.

Take a look and try to readjust your flags before attempting the affinity and mask values again.

I hope this has been helpful!

Laz

Hi René i have this topology created showed below , R37 is the (HEADEND) and R39 is my (TAILEND)
i have seted the atribute flags to 0x1 to upper path , 0x81 middle path and 0x80 lower path, my doubt is why if i set from R37 : show mpls traffic engineering topology path destination 3.3.3.3 affinity 0x80 mask 0x84 the command traffic displayed goes from R37 to R39 ?

Why this happens?


greetings!

Hello Dante

The CLI output that you shared seems to be at odds with the given affinity and mask you’ve configured. Given the affinity and mask values, the path via R42 is the expected path that should be selected, but your output shows it taking the path via R39.

What do you see in the output of the show mpls traffic-eng Tunnels command? What do you see in the Explicit Route as shown under the RSVP Path Info and the Shortest Unconstrained Path Info? Take a look at the lesson in the verification sections to see how those outputs tell us about how the tunnel is formed, and see if you can determine the path of the tunnel from that output.

Also, you may want to issue other related commands of the show mpls traffic-eng topology series that will show additional information. You can find these options and what they do at the following Cisco command line reference:

Let us know if these tools have further helped you to investigate and determine the reason behind the unexpected behavior.

I hope this has been helpful!

Laz