TE Tunnel using Link Affinity
Last updated
Last updated
Load mpls.te.base.config.with.ospf.cfg or mpls.te.base.config.with.ospf.and.affinity.cfg
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
One router at a time, we set the link-affinity on the links themselves. Shown below is only CSR1:
On IOS-XR we can create affinity-maps and then assign colors to links:
Create the TE tunnels:
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.
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:
