[j-nsp] Decoding DDOS messages

[Saku Ytti]

Hey Jason,

> Questions about the ddos-protection "features".  We're on a qfx5100-48 running 16.1.  I know that folks on the list aren't always big fans of ddos-protection; I'm just trying to understand what is triggering it so I can make decisions about tuning/disabling/ignoring it.

I am a big fan, it's great feature everyone should be running and
tuning correctly. Unfortunately even non-broken lo0 filter is
extremely uncommon, even MX book has fundamentally broken example, as
is CYMRU example. And ddos-protection may be even more complicated.

I'm not very familiar how it works on QFX5k, I'm more aware of MX
behaviour, where it's really great.

> We are not a service provider; we're an end site running a flat L2 network (LAN) with the QFX as our L3 core for IRB and routing to our ISP.  Since the QFX is seeing all the BUM traffic I'm curious if ddos-protection is being triggered as a result of seeing all the L2 packets.

Your L2 should be in its virtual-switch/vpls (doesn't imply VPLS)
instance with forwarding-plane filter policing BUM. But unrelatd to
subject.

> IPMCAST-miss (lots of this one!)

Probably punts for programming flow, and subsequent will be HW
switched. You may want to have ACL to drop all MCAST traffic at edge.
This should be 0 if you don't actually run multicast.

> ARP

Self-explanatory? You shouldn't want to see this exceeded, ideally you
should police this on IFD level, but I'm not sure if QFX5k can, MX
can.

> TTL

TTL exceeded message. Normal to hit this policer in uloops.

> Redirect

IP redirect, you probably want to disable them at network edge. This
should be 0.

> L3MTU-fail

Egress MTU was too small for packet. It is punted for potentially ICMP
message generation. Depending on config expected or unexpected.

> RESOLVE

Traffic hitting connected DADDR which is not in ARP cache, we need to
punt it for ARP resolution. Normal to see as there is constant
background traffic to every DADDR.

> L3NHOP

Unsure.

> So is that all ARP?  ARP that the switch needs to answer for?  Similar for the other packet types: are these thresholds for packets that the switch is processing (sent to the RE), or just for any traffic that is seen on any interface?  If it's just an issue of too much stuff going to the RE I can firewall it off so long as I know it's spurious.

It's ARP packets verbatim (see RESOLVE which is non ARP packet
triggering ARP resolution). Originally when ddos-protection was
implemented resolve was not implemented, and RESOLVE packet was what
ever classifier it hit, so if you sent BGP packets to unarpable DADDR
it was eating BGP policer PPS, so you could easily get targets core
iBGP down, and there was nothing they could do to stop you.

> Sorry if I'm not asking the right questions... I'm just trying to figure out if these errors are actually problems that I need to track down, or if the default reporting is just too noisy.
>
> Thanks,
>
> Jason
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti