TE Tunnel using Link Affinity

Load mpls.te.base.config.with.ospf.cfg or mpls.te.base.config.with.ospf.and.affinity.cfg

#IOS-XE
config replace flash:mpls.te.base.config.with.ospf.cfg
! or
config replace flash:mpls.te.base.config.with.ospf.and.affinity.cfg

#IOS-XR
configure
load bootflash:mpls.te.base.config.with.ospf.cfg
! or
load bootflash:mpls.te.base.config.with.ospf.and.affinity.cfg
commit replace

Configure link affinities as show in the diagram above. If you use the config file mpls.te.base.config.with.ospf.and.affinity.cfg, the affinities will already be pre-configured.

Create the following TE tunnels:

  • CSR8 to CSR5 without using orange links

  • XRv11 to CSR8 using only red links

  • CSR4 to XRv12 not using blue or green

Answer

One router at a time, we set the link-affinity on the links themselves. Shown below is only CSR1:

#CSR1
int gi2.514
 mpls traffic-eng attribute-flags 0xa
int gi2.513
 mpls traffic-eng attribute-flags 0x2
int gi2.519
 mpls traffic-eng attribute-flags 0x2
int gi2.516
 mpls traffic-eng attribute-flags 0x4
int gi2.518
 mpls traffic-eng attribute-flags 0x4

On IOS-XR we can create affinity-maps and then assign colors to links:

#XRv11
mpls traffic-eng
 affinity-map RED 0x1
 affinity-map GREEN 0x2
 affinity-map BLUE 0x4
 affinity-map ORANGE 0x8
 interface GigabitEthernet0/0/0/0.551
  attribute-names RED BLUE
 interface Gi0/0/0/0.501
  attribute-names RED GREEN
 interface Gi0/0/0/0.512
  attribute-names BLUE ORANGE

Create the TE tunnels:

#CSR8 (to CSR5 not using orange)
int tunnel0
 tunnel mode mpls traffic-eng
 ip unn lo0
 tunnel dest 5.5.5.5
 tunnel mpls traffic-eng affinity 0x0 mask 0x8   ! convert 1000 to hex 
 tunnel mpls traffic-eng path-option 1 dynamic

#XRv11 (to CSR8 using only red)
int tunnel-te0
 ip unn lo0
 tunnel dest 8.8.8.8
 affinity 0x1 mask 0x1    ! convert 0001 to hex
 path-option 1 dynamic

#CSR4 (to XRv12 not using blue or green)
int tunnel0
 tunnel mode mpls traffic-eng
 ip unn lo0
 tunnel dest 12.12.12.12
 tunnel mpls traffic-eng affinity 0x0 mask 0x6   ! convert 0110 to hex
 tunnel mpls traffic-eng path-option 1 dynamic

Explanation

First we set link affinity on each interface individually. Each color is represented by a single bit. When set to one, that color is “turned on” or assigned to the link. When set to 0, the color is not assigned to the link.

To set multiple colors to a link we can simply add the values together. For example, for both red (0x1) and blue (0x4) we add them and assign the link 0x5. This is 0101 in binary.

We then create an affinity constraint on each tunnel. If we want the bit to not match (”use links that are not orange”) we set that bit to 0 and the mask for that bit to one.

Let’s look in detail at how we can configure an instruction for “use links that are not orange.” Orange is 0x8, so we make sure affinity is 0XXX in binary. This is because we just need bit 4 to be zero in order to not use orange link. We make the mask match the four bit, so the mask is 0x1000. The rest of the bits are zero, because we don’t care if they are set or not. The tunnel affinity in hex becomes: 0x0 mask 0x8. This means “we care about bit 4, and the value must be zero.”

If we want the bit to match, we set the mask to 1 for that bit position. For example, to match all RED links, we use 0x1 mask 0x1. The affinity in binary is 0001, which is RED’s value. The mask is 0001 because we only care about the first bit matching for RED links. (We care about the RED bit being on).

With the mask we can only do AND logic. For example, match RED (0x1) and match not BLUE (0x4): 0x1 mask 0x5. (The mask in binary is 0101 because we want to match the blue bit (4) as being 0, in addition to the first bit being 1 for RED).

We cannot do OR logic with a mask. You can’t say “match BLUE or RED” only “match BLUE and RED” / “match BLUE and not RED” / “match not BLUE and not RED” etc…

By default the tunnel affinity mask is 0xffff if you don’t specify it. The default affinity is 0x0 mask 0xffff if you don’t configure affinity at all. 0xffff means “match last 16 bits.” 0xffffffff would be “match all 32 bits.” This can potentially cause problems that might be hard to notice. If you color all your links and then don’t configure an affinity on the tunnel, CSPF may not find any path at all, because all links have some value in the last 16 bits and the tunnel is using 0x0/0xffff by default.

Verification

We can verify link affinity from any router in the area by inspecting the TED:

The link affinity is advertised inside the opaque area LSA for each interface:

We can verify the affinity required on each tunnel, and verify the path the tunnel calculated:

Last updated