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 <[email protected]> On Behalf Of [email protected] Sent: Tuesday, September 1, 2020 10:01 PM To: [email protected] 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 [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
