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