MPLS Traffic Engineering (TE) attribute flags and tunnel affinity allow you to set attributes on interfaces and configure tunnels to either include or exclude specific links based on those attributes. This is also known as link coloring.
Like TE metric or explicit path options, you can use this to decide what path your tunnels should use.
What are attributes? That’s entirely up to you. There are no predefined attributes. The link type (for example, Fiber, DSL, Satellite) could be attributes. Whether a link is encrypted or not, connected to another country. You name it. You can use whatever you think is useful.
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.
Attribute Flag
Let’s look at an example:

Above, we have an MPLS TE network with links with different attributes:
- Fiber links
- DSL link
- Satellite link
- Encrypted link
- Link to another country
We could use attribute flags like this:
Link type | Binary | Hexadecimal |
Fiber | 0000 0001 | 0x1 |
Satellite | 0000 0010 | 0x2 |
DSL | 0000 0100 | 0x4 |
Link to another country | 0000 1000 | 0x8 |
Encrypted link | 0001 0000 | 0x10 |
I made up these values myself. I decided that for this network, a Fiber link should have its least significant bit set to 1. For a DSL link, it should be the third least significant bit, etc. You can use hexadecimal values from 0x00000000 up to 0xFFFFFFFF.
I’m only using five attributes in this example, so I’m only showing the eight least significant bits. The attribute flag is 32 bits, so the first 24 bits are all zeroes.
A link could have multiple attributes. For example, let’s say a link has these three attributes:
- Fiber (0000 0001)
- Encrypted (0001 0000)
- Connects to another country (0000 1000)
We set the corresponding bits to 1:
Link type | Binary | Hexadecimal |
Fiber + encrypted link + link to another country | 0001 1001 | 0x19 |
Affinity and Mask
Deciding on attribute flags is one part of the story. On our tunnel interfaces, we have to configure two items:
- Affinity
- Mask
These two items determine whether we include or exclude specific links for our tunnel interface.
With affinity, we set the attribute flag value we want to check, and with the mask, we tell the router what bits we care about or don’t care about. This is similar to how a subnet mask works:
Bit | Function |
0 | Don’t care about this attribute flag bit. |
1 | The attribute flag bit must match. |
- 1 = the attribute bit must match.
- 0 = we don’t
Don’t worry about this too much for now. In the configuration section, I’ll explain four examples of how we use affinity and different masks.
Configuration
Let’s dive into the configuration. This is the topology I’ll use:

We have a small MPLS TE network. Routers PE1, P1, P2, and PE2 run MPLS TE. PE1 is the headend router for four TE tunnels that terminate at PE2. We are going to use these tunnels to test affinity. You can also see that I added attribute flags to each link. These correspond to the examples I showed previously.
- Configurations
- CE1
- CE2
- P1
- P2
- PE1
- PE2
Want to take a look for yourself? Here you will find the startup configuration of each device.
I’m using IOSv Version 15.9(3)M4 on all routers.
By default, all interfaces have the attribute flags all set to zero:
PE1#show mpls traffic-eng topology | include Intf | flags
frag_id 0, Intf Address:192.168.24.2
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.23.2
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.25.2
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.23.3
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.35.3
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.24.4
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.45.4
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.35.5
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.45.5
TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:192.168.25.5
TE metric:10, IGP metric:10, attribute flags:0x0
Tunnels use the following default affinity and mask:
PE1#show mpls traffic-eng tunnels Tunnel 1 | include Affinity
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
The default affinity is 0x0 with a mask of 0xFFFF. Let me show all 32 bits:
Affinity | 00000000 00000000 00000000 00000000 |
Mask | 00000000 00000000 11111111 11111111 |
What does this mean?
- The first 16 bits of the mask are set to zeroes, so we don’t care about these.
- The last 16 bits of the mask are set to ones, so we care about these.
The last 16 affinity bits are set to zeroes, so we can use links where the last 16 attribute flag bits are set to zero. Because the attribute flag of a link is set to all zeroes by default, we can use all links.
Be careful when configuring attribute flags in a production network. With this default affinity setting, some links may become excluded for your tunnels.
Link Attributes
Let’s start with the configuration of the link attributes. I’ll use the examples I showed you before:
Link type | Binary | Hexadecimal |
Fiber | 0000 0001 | 0x1 |
Satellite | 0000 0010 | 0x2 |
DSL | 0000 0100 | 0x4 |
Fiber + encrypted link + link to another country | 0001 1001 | 0x19 |
Let’s configure all interfaces on the routers:
PE1
PE1(config)#interface GigabitEthernet 0/1
PE1(config-if)#mpls traffic-eng attribute-flags 0x19
PE1(config)#interface GigabitEthernet 0/2
PE1(config-if)#mpls traffic-eng attribute-flags 0x1
PE1(config)#interface GigabitEthernet 0/3
PE1(config-if)#mpls traffic-eng attribute-flags 0x4
P1
P1(config)#interface GigabitEthernet 0/0
P1(config-if)#mpls traffic-eng attribute-flags 0x19
P1(config)#interface GigabitEthernet 0/1
P1(config-if)#mpls traffic-eng attribute-flags 0x1
P2
P2(config)#interface GigabitEthernet 0/0
P2(config-if)#mpls traffic-eng attribute-flags 0x1
P2(config)#interface GigabitEthernet 0/1
P2(config-if)#mpls traffic-eng attribute-flags 0x2
PE2
PE2(config)#interface GigabitEthernet 0/1
PE2(config-if)#mpls traffic-eng attribute-flags 0x1
PE2(config)#interface GigabitEthernet 0/2
PE2(config-if)#mpls traffic-eng attribute-flags 0x2
PE2(config)#interface GigabitEthernet 0/3
PE2(config-if)#mpls traffic-eng attribute-flags 0x4
That’s all there is to it.
Affinity and Mask
Now we can configure affinity and a mask for our tunnel interfaces. I’ll give you four examples.
Example 1
Let’s say that our tunnel should only use plain DSL links. No other attributes are allowed. The attribute flag we use for a DSL link looks like this:
Link type | Binary | Hexadecimal |
DSL | 0000 0100 | 0x4 |
We can use our affinity and mask like this:
Type | Binary | Hexadecimal |
Affinity | 0000 0100 | 0x4 |
Mask | 1111 1111 | 0xFFFFFFFF |
We set our affinity to the same value as the attribute flag for a DSL link. We set the mask to all ones, which means that all affinity bits have to match. Let’s configure this:
PE1(config)#interface Tunnel 1
PE1(config-if)#tunnel mpls traffic-eng affinity 0x4 mask 0xFFFFFFFF
Verification
Let’s figure out whether this works. Let’s check the tunnel:
PE1#show mpls traffic-eng Tunnels tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 5.5.5.5
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 10)
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x4/0xFFFFFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet0/3, implicit-null
RSVP Signalling Info:
Src 2.2.2.2, Dst 5.5.5.5, Tun_Id 1, Tun_Instance 107
RSVP Path Info:
My Address: 192.168.25.2
Explicit Route: 192.168.25.5 5.5.5.5
Record Route: NONE
Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
Shortest Unconstrained Path Info:
Path Weight: 10 (TE)
Explicit Route: 192.168.25.2 192.168.25.5 5.5.5.5
In the output above, we see our configured affinity and mask. The explicit route we use is the direct DSL link from PE1 to PE2. To find out whether affinity works, we’ll shut the DSL link:
PE1(config)#interface GigabitEthernet 0/3
PE1(config-if)#shutdown
Let’s check the tunnel:
PE1#show mpls traffic-eng tunnels Tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 5.5.5.5
Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 1, type dynamic
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x4/0xFFFFFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 192.168.24.2 192.168.24.4 192.168.45.4 192.168.45.5
5.5.5.5
History:
Tunnel:
Time since created: 1 days, 47 minutes
Time since path change: 2 hours, 3 minutes
Number of LSP IDs (Tun_Instances) used: 469
Prior LSP:
ID: path option 1 [215]
Removal Trigger: path error
Last Error: PCALC:: No path to destination, 0005.0005.0005.00
As expected, the tunnel is now down because no DSL links remain.
Let’s reactivate the interface before we continue:
PE1(config)#interface GigabitEthernet 0/3
PE1(config-if)#no shutdown
Example 2
Let’s try something else. Let’s configure a tunnel where we only permit fiber links. We shouldn’t use satellite or DSL links. We don’t care about any other attributes.
Link type | Binary | Hexadecimal |
Fiber | 0000 0001 | 0x1 |
Satellite | 0000 0010 | 0x2 |
DSL | 0000 0100 | 0x4 |
Here is the affinity and mask we can use:
Type | Binary | Hexadecimal |
Affinity | 0000 0001 | 0x1 |
Mask | 0000 0111 | 0x7 |
Let me explain this:
- The affinity has it’s last bit set to 1 because this matches the fiber attribute flag bit.
- The mask is set to 111 because we care about the last three bits:
- The second least significant bit indicates a satellite link, so we care that this bit is a 0.
- The third least significant bit indicates a DSL link, so we care that this bit is a 0.
- The least significant bit indicates a fiber link, so we care that this bit is a 1.
We don’t care about any of the other attribute flag bits. Let’s configure this:
- Unit 1: Introduction
- Unit 2: LDP (Label Distribution Protocol)
- Unit 3: MPLS VPN
- VRFs (Virtual Routing and Forwarding)
- MPLS L3 VPN Explained
- MPLS L3 VPN Configuration
- MPLS L3 VPN BGP Allow AS in
- MPLS L3 VPN BGP AS Override
- MPLS L3 VPN PE-CE RIP
- MPLS L3 VPN PE-CE EIGRP
- MPLS L3 VPN PE-CE OSPF
- MPLS L3 VPN PE-CE OSPF Default Route
- MPLS L3 VPN PE-CE OSPF Global Default Route
- MPLS L3 VPN PE-CE OSPF Sham Link
- VRF Lite Route Leaking
- MPLS VPN Extranet Route Leaking
- MPLS VPN VRF Export Map
- MPLS VPN VRF Import Map
- MPLS over FlexVPN
- Unit 4: MPLS L2 Encapsulation
- Unit 5: IPv6 MPLS
- Unit 6: MPLS Traffic Engineering (TE)
- Introduction to MPLS Traffic Engineering (TE)
- MPLS Traffic Engineering (TE) IS-IS Configuration
- MPLS Traffic Engineering (TE) OSPF Configuration
- MPLS TE RSVP-TE
- MPLS TE Static Routes
- MPLS TE Policy Based Routing (PBR)
- MPLS TE Autoroute Announce
- MPLS TE Autoroute Destination
- MPLS TE Autoroute Metric
- MPLS TE Unequal Cost Load Balancing
- MPLS TE Load Balancing between IGP and TE
- MPLS TE Forwarding Adjacency
- MPLS TE Path Options Explicit
- MPLS TE Class-Based Tunnel Selection (CBTS)
- MPLS TE Metric
- MPLS TE Setup and Hold Priority
- MPLS TE Attribute Flag and Affinity
- MPLS TE Reoptimization
- MPLS TE Fast Reroute (FRR)
- MPLS TE Fast Reroute Path Link Protection
- MPLS TE Fast Reroute Path Node Protection
- MPLS TE FRR RSVP Hello Support
- MPLS TE DiffServ Aware (DS-TE) Traditional
- MPLS TE Diffserv-Aware (DS-TE) IETF Mode
- MPLS VPN over MPLS TE Tunnels
- MPLS TE Per VRF TE tunnel