Mailing List Archive

I know of a few methods for steering traffic in MPLS-TE/RSVP-TE, I've done
this in IOS-XR, but not in Junos at this point... but i found this link that
might help in Junos... https://www.inetzero.com/in-control-with-rsvp/

One way is to change the te-metric on that P router that you don't want lsp
to pass through...but that might be too global as it would seem to affect
all TE LSP's passing through there.

set protocols isis interface ge-0/0/1 level 1 te-metric 100

clear lsp to re-signal

Make sure to do that on the opposite side te tunnel as you usually need to
setup one in each direction as a te tunnel is unidirectional... however, i
just learned of corouted-bidirectional, seems interesting

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/basic-lsp
-configurtion.html#id-configuring-corouted-bidirectional-lsps

again, this seems to be a nice and easy way to exclude a P router in cisco
ios-xr from the te head-end, i don't know of the junos equivelent for this

conf
explicit-path name not-r2
index 1 exclude-address ipv4 unicast 10.2.2.2
commit


-Aaron

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Sat, 6 Feb 2021, Robert Huey wrote:

> Have you looked into IGP Overload? I think it will do the trick without ever getting into TE constraints.

In this case, it's OSPF, so overload is just max metric. The path metric
already exceeds any other through the network under ordinary conditions,
which is why it's only a problem on occasion, and with bypass LSPs in
particular.

IGP metric isn't enough when "best path" is the same answer as "only
available path", and it looks like switch-away-lsps goes too far in the
opposite direction.

-Rob


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp