[j-nsp] QFX 5100 uRPF

[Brian Rak]

On 3/8/2017 1:48 PM, Hugo Slabbert wrote:
>
> On Wed 2017-Mar-08 12:38:52 -0500, Brian Rak <brak at gameservers.com> 
> 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.
>