[j-nsp] debug messages - kernel: rt->rt_proto and fpc0 Next-hop resolution requests throttled

[John Kristoff]

Hello friends,

Curiosity may have killed the cat, but I'm not a cat so here goes.

Evaluating some debug logs on an EX-9208 I've seen two flavors of log
messages that I'd be interested in learning more about.  One set looks
like the following:

  /kernel: rt->rt_proto ipv4 plen 32
  /kernel: rt->rt_proto vpls plen 80
  /kernel: rt->rt_proto ipv6 plen 128

The other like this:

  fpc0 Next-hop resolution requests from interface 498 throttled

>From the text I think I have an idea what they sort of information they
are conveying, but I'd like to hear definitively a bit more.  Under
what conditions and for what reason they are being generated?  Yes,
these are from enabling debug message, which generally you wouldn't do,
but would otherwise ignore these if you saw them.  I opened a low
priority case and apparently not much is documented about them and I
didn't want to push the JTAC to expend a lot of effort on this.  Hoping
someone here might have this obscure knowledge.

John
___
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]

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] DCU matching in firewall filter

[Dragan Jovicic]

DCU on FT is executed on ingress PFE after routing decision. This means you
can attach it to inet family regardless of egress encapsulation (MPLS).
Junos 14.X did not allow me to configure interface-groups and FT egress
filter.
But interface sets seem to be good enough for this.

Dragan

On Tue, Sep 13, 2016 at 6:40 PM, Saku Ytti  wrote:

> On 13 September 2016 at 19:24, Paul S.  wrote:
>
> Hey Paul.
>
> > Could you expand a bit more about potential limitations that I might run
> > into in the future with this forwarding-options based setup?
> >
> > Mostly concerned about these two:
> >
> >   - egress iface filter requires that egress is IP tagged (trinity
> > allows mpls)
> >   - if egress forw FW filter is used, interface filter groups cannot
> be
> > used
> >
> > The router that this is being deployed on will likely be a part of a mpls
> > backbone at a later date.
>
> You're probably running Trio/Trinity platform, so egress IP filter
> should work even if egress is MPLS tagged, this wasn't true
> historically. The latter means, you cannot use this feature:
> http://www.juniper.net/documentation/en_US/junos16.1/
> topics/example/firewall-filter-option-received-on-
> interface-group-example.html
>
> I'm not sure if that limitation has been since lifted.
>
> --
>   ++ytti
> ___
> 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