[c-nsp] mpls-te - affinity and link attributes to influence path selection

[aaron1 at gvtc.com]

speaking of only 1 unidirectional te-tunnel from headend r20 to tailend r22 

 

like this.... r20---to--->r22

 

physical network looks like this...

 

r20-----r21-----r22

|                           |

|                           |

r24-----r25-----r23

 

i'm observing in my lab, under normal and default settings, a te-tunnel from
headend r20 to tailend r22 flows via midpoint r21 and i'm pretty sure this
is because I used path-option dynamic and the IGP metric/TE Metric ends up
dictating best path. (you can correct me if there's more to it than that
please)

 

but if i need to *avoid* r21, and I want to use affinity and link attributes
to do so, i understand that the default tunnel interface on headend r20 uses
affinity 0x0 and affinity mask 0xffff (which i think actually means affinity
mask 0xffff0000)

 

and so here's my question please....

 

looking simply at what link attribute setting on r21 would cause the
te-tunnel to not use r21 as a midpoint but instead setup via the southbound
long path via midpoints r24, r25, r23, i tried the following on r21....

 

r20-----(attribute 0x1)r21-----r22

 

...reoptimize te-tunnel on headend r20, and that didn't work, no change,
still flows via r21

 

...but when i tried this...

 

r20-----r21(attribute 0x1)-----r22

 

...then i reoptimize te-tunnel on headend r20, and it works!  i see the
tunnel setup via long path via midpoints r24, r25, r23

 

so am i to understand that link attributes are effective on the outbound
direction only ?

 

seems to not work

-----te-tunnel setup direction----->>>

r20-----(attribute 0x1)r21-----r22

 

seems to work

-----te-tunnel setup direction----->>>

r20-----r21(attribute 0x1)-----r22

 

 

Aaron

aaron1 at gvtc.com