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

[aaron1 at gvtc.com]

Correction on one of those statements....I think the affinity mask default
of 0xffff actually means 0x0000ffff

Which seems to make sense in my observations, that I could set the link
attributes to anything in the top 4 hex characters and it didn't affect the
tunnel.... but if I change so much as one bit of the bottom 4 hex
characters, the tunnel would go the other way.

Now all I need to know is the place to apply these link attributes to be
effective... it seems that it's the outgoing interface of any router in the
tunnel path.  Not the incoming interface.  That's what my tests have shown,
I just haven't read it in any document yet.

-Aaron

-----Original Message-----
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of
aaron1 at gvtc.com
Sent: Tuesday, September 1, 2020 10:01 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] mpls-te - affinity and link attributes to influence path
selection

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

 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/