On Thu, 11 Dec 2025 at 09:21, Gert Doering <[email protected]> wrote:
> Can you share some reading material on this? > > (We've been on the "receiving end" on this a few times, like traceroutes > showing "munich -> frankfurt" latency jumps of +100ms due to LSPs going > trans-atlantic being involved - and understanding better options might > be useful in convincing transit ISPs to do better ;-) ) Not aware of reading material. But what you can do, is on every full view router configure anycasted secondary loopback. Then on the LSR/P core has a static default with next-hop to this address. Then when P device will try to send TTL expire, it of course won't find the route in IGP, therefore it'll follow static default to IGP closest full mesh router. Which will then have route to the destination, and will impose proper label and return it to a backbone. If we assume the same pop has P and PE device, we're talking about microseconds inflation in RTT, far too small to observe, due to the pre-emptive kernels on both ends of the ping. Of course this doesn't work for VPN traffic. But you can make it work on INET-IN-VPN. And if I were to build a greenfield design, my INET would be in VRF and the global table would be just for signalling and management. Here we'd have to route on the PE devices global table to the INET-IN-VPN for the next lookup, which is possible. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
