Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

See also:

http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/mpls-configuring-traffic-engineering-for-lsps.html

On Wed, Sep 14, 2016 at 09:20:17AM +0200, Dragan Jovicic wrote:
> So you want BGP to resolve routes using only inet.3 table which contains
> RSVP routes, and not inet.0.
> 
> https://www.juniper.net/documentation/en_US/junos15.1/topics/example/vpns-layer-3-route-resolution-route-reflector.html
> 
> 
> Dragan
> 
> On Wed, Sep 14, 2016 at 1:26 AM, Rob Foehl  wrote:
> 
> > On Tue, 13 Sep 2016, Chuck Anderson wrote:
> >
> > I guess I don't understand what you are trying to accomplish then.
> >> Ttaffic engineering specific routes is exactly what RSVP is used for.
> >> The MPLS path should be torn down if there is no available
> >> RSVP-capable route.  Did you try just not configuring RSVP on the
> >> interfaces that can't support MPLS?
> >>
> >
> > The LSP is torn down; the BGP session carrying a bunch of routes for which
> > that LSP is the only viable forwarding path survives.  (RSVP is only
> > configured where it ought to be, no "interfaces all" or anything like that.)
> >
> > The goal is for the BGP-learned routes to disappear along with the LSP --
> > preferably by just tearing the session down with it, but otherwise
> > invalidating the next-hops would suffice.
> >
> > I have another idea in my back pocket if this isn't workable, but that
> > involves turning a bunch of P routers into full BGP RRs...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[kworm83]

If you make your LSP with a strict path where it will not use the other IGP 
path then you can use a forwarding table export policy to force the LSP as a 
strict next next hop:

policy-statement name-of-policy {
   term term-1 {
   from ;
   then {
   install-nexthop strict lsp YOUR-LSP-NAME;
   accept;
   }
   }
}


If the LSP fails the BGP route will disappear.  I have tested this in the lab 
but not at full table scale.

Kevin


> On Sep 13, 2016, at 6:26 PM, Rob Foehl  wrote:
> 
> On Tue, 13 Sep 2016, Chuck Anderson wrote:
> 
>> I guess I don't understand what you are trying to accomplish then.
>> Ttaffic engineering specific routes is exactly what RSVP is used for.
>> The MPLS path should be torn down if there is no available
>> RSVP-capable route.  Did you try just not configuring RSVP on the
>> interfaces that can't support MPLS?
> 
> The LSP is torn down; the BGP session carrying a bunch of routes for which 
> that LSP is the only viable forwarding path survives.  (RSVP is only 
> configured where it ought to be, no "interfaces all" or anything like that.)
> 
> The goal is for the BGP-learned routes to disappear along with the LSP -- 
> preferably by just tearing the session down with it, but otherwise 
> invalidating the next-hops would suffice.
> 
> I have another idea in my back pocket if this isn't workable, but that 
> involves turning a bunch of P routers into full BGP RRs...
> 
> -Rob
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

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

Re: [j-nsp] Fate sharing between BGP and RSVP

[Dragan Jovicic]

So you want BGP to resolve routes using only inet.3 table which contains
RSVP routes, and not inet.0.

https://www.juniper.net/documentation/en_US/junos15.1/topics/example/vpns-layer-3-route-resolution-route-reflector.html


Dragan

On Wed, Sep 14, 2016 at 1:26 AM, Rob Foehl  wrote:

> On Tue, 13 Sep 2016, Chuck Anderson wrote:
>
> I guess I don't understand what you are trying to accomplish then.
>> Ttaffic engineering specific routes is exactly what RSVP is used for.
>> The MPLS path should be torn down if there is no available
>> RSVP-capable route.  Did you try just not configuring RSVP on the
>> interfaces that can't support MPLS?
>>
>
> The LSP is torn down; the BGP session carrying a bunch of routes for which
> that LSP is the only viable forwarding path survives.  (RSVP is only
> configured where it ought to be, no "interfaces all" or anything like that.)
>
> The goal is for the BGP-learned routes to disappear along with the LSP --
> preferably by just tearing the session down with it, but otherwise
> invalidating the next-hops would suffice.
>
> I have another idea in my back pocket if this isn't workable, but that
> involves turning a bunch of P routers into full BGP RRs...
>
> -Rob
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[Rob Foehl]

On Tue, 13 Sep 2016, Chuck Anderson wrote:


I guess I don't understand what you are trying to accomplish then.
Ttaffic engineering specific routes is exactly what RSVP is used for.
The MPLS path should be torn down if there is no available
RSVP-capable route.  Did you try just not configuring RSVP on the
interfaces that can't support MPLS?


The LSP is torn down; the BGP session carrying a bunch of routes for which 
that LSP is the only viable forwarding path survives.  (RSVP is only 
configured where it ought to be, no "interfaces all" or anything like 
that.)


The goal is for the BGP-learned routes to disappear along with the LSP -- 
preferably by just tearing the session down with it, but otherwise 
invalidating the next-hops would suffice.


I have another idea in my back pocket if this isn't workable, but that 
involves turning a bunch of P routers into full BGP RRs...


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

Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

On Tue, Sep 13, 2016 at 06:38:10PM -0400, Rob Foehl wrote:
> On Tue, 13 Sep 2016, Chuck Anderson wrote:
> 
> >Could you just use a strict MPLS path with an ERO?
> 
> Hmm, doesn't look like it...  I just tried configuring an explicit
> path LSP to nowhere on a lab box, and it didn't install anything
> into the routing table without the LSP up.  Either way, a strict
> path would probably cause more trouble than it'd be worth.

I guess I don't understand what you are trying to accomplish then.
Ttaffic engineering specific routes is exactly what RSVP is used for.
The MPLS path should be torn down if there is no available
RSVP-capable route.  Did you try just not configuring RSVP on the
interfaces that can't support MPLS?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[Rob Foehl]

On Tue, 13 Sep 2016, Chuck Anderson wrote:


Could you just use a strict MPLS path with an ERO?


Hmm, doesn't look like it...  I just tried configuring an explicit path 
LSP to nowhere on a lab box, and it didn't install anything into the 
routing table without the LSP up.  Either way, a strict path would 
probably cause more trouble than it'd be worth.


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

Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

On Tue, Sep 13, 2016 at 05:42:37PM -0400, Rob Foehl wrote:
> Assuming a typical IBGP session built between loopbacks, is there
> any relatively clean way to tie that session state to RSVP-signaled
> LSPs between the same pair of routers?
> 
> I'm trying to work around a case where the IGP knows about another
> path between the two that doesn't carry any MPLS traffic, thus
> keeping the BGP session alive without a valid forwarding path for
> any of the received routes in the event of a failure along the
> MPLS-enabled path.

Could you just use a strict MPLS path with an ERO?

http://www.juniper.net/documentation/en_US/junos14.2/topics/example/mpls-lsp-explicit-path-configuring.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Fate sharing between BGP and RSVP

[Rob Foehl]

Assuming a typical IBGP session built between loopbacks, is there any 
relatively clean way to tie that session state to RSVP-signaled LSPs 
between the same pair of routers?


I'm trying to work around a case where the IGP knows about another path 
between the two that doesn't carry any MPLS traffic, thus keeping the BGP 
session alive without a valid forwarding path for any of the received 
routes in the event of a failure along the MPLS-enabled path.


Thanks!

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