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 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
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
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] 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 checking hardware and version numbers, or for pieces of config hierarchy that might not be present on any given box either way. ...returns substantially different XML b/w ELS and non-ELS IIRC. Thanks, Phil. Just realizing I'd never followed up on this... That RPC does return completely different XML, and was easy enough to wedge into a commit script to detect ELS vs. non-ELS, but we hit a snag with VCs in that the backup RE fails to execute the RPC and thus blows up during a commit sync. This should still work fine over netconf for off-box differentiation, of course. We wound up falling back to platform detection, with explicit pattern matching for the models we've tested the script on. There's a small benefit there, in that the script will refuse to run on a new box where nobody's tested it before, but that's still a maintenance trade-off. -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
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
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
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 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
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) - 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. On 9/13/2016 11:10 PM, Saku Ytti wrote: 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 absolutely nothing. I wish I had good news for you. From my notes when labbing this many many years ago: Flow is: packet > ingress int FW > SCU > ingress forw FW > DCU > egress forw FW > egress int FW This means: - you cannot match on SCU/DCU at all in ingress iface - you can do SCU matches in ingress forwarding fw filter, but not DCU - you can do SCU and DSU matches in egress forwarding filter and egress iface filter - 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 These limitations are certainly from IP2 days, I can't imagine Trio HW imposing these limits. If you have leverage to JNPR, I'm confident it would be possible to consider DCU/SCU in ingress interface filter. ___ 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
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 > policer. [...] > So, is there any other way to apply this only on the concerned customer > interfaces, or are we going to have to maintain a large > forwarding-options filter with entries like 'term 1 from > destination-class dcu-local; interface x; then ...' and 'term 2 from > destination-class dcu-local; interface y' ...' You can group customer interfaces using interface-set, e.g. set firewall interface-set customer-local ge-0/0/0.0 set firewall interface-set customer-local ge-0/0/1.0 and then use that interface set together with DCU in pfe filter, term cust-local from destination-class dcu-local interface-set customer-local Not as nice as having DCU in ingress filter, but still much better than one term per interface. ___ 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
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 > absolutely nothing. I wish I had good news for you. From my notes when labbing this many many years ago: Flow is: packet > ingress int FW > SCU > ingress forw FW > DCU > egress forw FW > egress int FW This means: - you cannot match on SCU/DCU at all in ingress iface - you can do SCU matches in ingress forwarding fw filter, but not DCU - you can do SCU and DSU matches in egress forwarding filter and egress iface filter - 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 These limitations are certainly from IP2 days, I can't imagine Trio HW imposing these limits. If you have leverage to JNPR, I'm confident it would be possible to consider DCU/SCU in ingress interface filter. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 routing-options ->
forwarding-table -> export to assign a destination class to the prefixes
that we want, and finally setup a simple firewall filter to deal with it
all.
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 absolutely nothing.
Applying it globally isn't the most desirable solution in my opinion
(but it does work). It would appear ras had actually ran into this
before once -
https://puck.nether.net/pipermail/juniper-nsp/2008-October/011812.html
So, is there any other way to apply this only on the concerned customer
interfaces, or are we going to have to maintain a large
forwarding-options filter with entries like 'term 1 from
destination-class dcu-local; interface x; then ...' and 'term 2 from
destination-class dcu-local; interface y' ...'
Inputs welcome, thank you!
Filter config:
firewall filter filter-dcu-local {
term block-dcul-access {
from {
destination-class dcu-local;
}
then {
count dcu-local-drops;
discard;
}
}
term accept-the-rest {
then accept;
}
}
Policy config:
policy-options policy-statement community-to-class
term dcu-local {
to community dcu-local;
then {
destination-class dcu-local;
accept;
}
}
Interface config:
unit 0 {
family inet {
accounting {
destination-class-usage;
}
address 10.10.10.5/30;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
