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

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

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

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

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

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

Re: [j-nsp] Commit script portability between ELS and non-ELS platforms

On Wed, 8 Jun 2016, Phil Mayers wrote: On 07/06/16 21:51, Rob Foehl wrote: Does anyone have any clever methods for probing Enhanced Layer 2 Software support from a commit script on QFX/EX in order to generate changes appropriate to the platform? Specifically looking for something beyond

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

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

[j-nsp] Fate sharing between BGP and RSVP

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

Re: [j-nsp] DCU matching in firewall filter

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

Re: [j-nsp] DCU matching in firewall filter

Hi Saku, Many thanks for your reply. 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)

Re: [j-nsp] DCU matching in firewall filter

On Tue, Sep 13, 2016 at 08:35:26PM +0900, Paul S. wrote: > Hi j-nsp, > > I'm trying to use DCU to filter access to specific prefixes selectively > on Juniper MX. i.e: Customer on interface ge-0/0/0 cannot send traffic > to prefixes tagged by some BGP community, or perhaps it'll be sent to a >

Re: [j-nsp] DCU matching in firewall filter

On 13 September 2016 at 14:35, Paul S. wrote: Hey Paul, > Issue is, the filter only works when it's applied to the > 'forwarding-options' level of hierarchy, not the interface itself. i.e: If I > apply it to 'unit 0 family inet filter input filter-dcu-local,' ...it does >

[j-nsp] DCU matching in firewall filter

Hi j-nsp, I'm trying to use DCU to filter access to specific prefixes selectively on Juniper MX. i.e: Customer on interface ge-0/0/0 cannot send traffic to prefixes tagged by some BGP community, or perhaps it'll be sent to a policer. So we first match routes into a community, then use a