[j-nsp] BGP/MPLS Question MX Platform
Dean B
jnprlist at gmail.com
Wed Aug 3 12:36:43 EDT 2016
Hey Saku thanks for clarifying...it makes sense now. So for your option
"c" I would just set the ISIS metric to have a higher cost on the expensive
A-C link so that it would not normally be used right? I have sample lab
logical system config here: http://pastebin.com/uzHtzWrw
I'm assuming I need to add an additional LSP to each node that has a higher
priority and then use that LSP for the l2circuit traffic. What else would
I need to get the option "c" with blackhole of other traffic during
low-cost path failure?
Thanks again for all the help.
On Wed, Aug 3, 2016 at 11:01 AM, Saku Ytti <saku at ytti.fi> wrote:
> On 3 August 2016 at 18:49, Dean B <jnprlist at gmail.com> wrote:
>
> Hey,
>
> > Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but
> what
> > is the SPT you are referring to and what JunOS config elements does it
>
> Shortest Path Tree (result of SPF algorithm). Essentially I'm talking
> how you'll configure your IGP, will the expensive link be chosen as
> result of IGP configuration or not.
>
> > Speaking of QoS, might another way to solve this (assuming I could mark
> > traffic eligible to discard) be to use use QoS on both sides of the
> > high-cost link and just discard that marked traffic? Then I could just
> let
> > the existing ISIS/LDP stuff do it's thing.
>
> Devices really don't support exactly this behaviour, not these days.
> But if the link is say 1Gbps and you know you won't have more than
> 600Mbps of L2VPN. Then if you give L2VPN class/queue >=60% guarantee,
> and rest for other traffic, then you'll never drop the L2VPN. Of
> course you could do 98% L2VPN, 1% signalling and 1% all other traffic.
> Bandwidth will be 'loaned' from class which is not using its
> guarantee, so it'll work just fine.
>
> --
> ++ytti
>
More information about the juniper-nsp
mailing list