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