On 3/8/2017 1:48 PM, Hugo Slabbert wrote:
On Wed 2017-Mar-08 12:38:52 -0500, Brian Rak <[email protected]>
wrote:
Is anyone successfully using rpf-check on QFX5100's?
I'm getting some really weird behavior.. If I enable uRPF, then
disable it again, the device still appears to continue to enforce it.
(Spoofed packets continue to be blocked). I have to restart the
device in order to fully remove RPF.
Also, whenever I enable rpf-check, a whole bunch of legitimate
traffic starts getting dropped. My guess is that this is related to
the device having redundant uplinks, and an ECMP default route. I
can't really confirm this though, since RPF troubleshooting seems
non-existent.
Mixing redundant / asymmetric paths and uRPF needs to be done
carefully. Are you doing strict or loose RPF? What legitimate
traffic is being dropped (e.g. specific types/classes of traffic or
seemingly random)? Do you have an exception filter defined to
log/catch/exclude certain traffic? E.g. on SRX used as CPE we needed
to define an exception filter so that DHCP discover packets don't get
dropped.
I've attempted RPF in both loose and strict modes. As far as I can
tell, they worked in exactly the same way. The traffic getting dropped
is seemingly random, I'll be able to SSH in from one IP, but randomly
not from another.
QFX5100 doesn't appear to support fail-filter, when I enable it, I see
this in the configs:
rpf-check {
##
## Warning: statement ignored: unsupported platform
(qfx5100-48s-6q)
##
fail-filter rpf-special;
mode loose;
}
Dropping DHCP would be a pretty big deal here, so maybe we can't use RPF
after all.
My hope was to enable RPF on the customer-facing vlans, and leave it
disabled on the uplinks. I was thinking that would result in the ECMP
default route being less of an issue.
The documentation is confusing here, it states:
> QFX switches, OCX switches, and EX3200 and EX4200 switches do not
perform unicast RPF filtering on equal-cost multipath (ECMP) traffic.
Which I'd interpret to mean that uRPF is not applied to traffic
destined to an ECMP route. That's contradicted a few lines later,
> Using unicast RPF to filter ECMP traffic on these switches can result
in the switch discarding packets that you want to forward because the
unicast RPF filter does not examine the entire ECMP address block.
Is attempting to use RPF here a mistake? I'd really prefer not to
have to implement per-port ACLs. We're on 16.1 currently, I'll
probably try upgrading once JTAC fixes my account.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
