[j-nsp] Decoding DDOS messages

[Tom Beecher]

This is the most recent Juniper document I had bookmarked for the QFX.

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protocols-edit-ddos-qfx-series.html

I agree with Saku that the ddos-policer is a good tool to use, but as he
said it requires turning for your specific environment to be at its most
useful. I don't want to discount the opinions of those who dislike it, but
many complaints about it seem to boil down to "the defaults didn't work, I
didn't tune it, therefore I hate it".

On Wed, Mar 18, 2020 at 10:42 AM Saku Ytti <saku at ytti.fi> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>