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/
