[j-nsp] MX punting packets to RE - why?

[Ross Halliday]

Hey again,

> No, something like this:
> edit system ddos-protection protocols resolve mcast-v4
> set bandwidth 100
> set burst 100
> set flow-level-bandwidth logical-interface 20
> set flow-level-detection subscriber off
> set flow-level-detection logical-interface on
> 
> So we allow on aggregate 100pps of mcast-v4 resolve, but only 20pps
> per IFL. So even if one IFL is misbehaving, another IFL's mcast-v4
> resolve works fine.
> 
> There are only 4k policers available in HW for ddos-protection, which
> makes me turn off subscriber detection, as it's easy for attacker to
> generate 'new subscriber' (like in BGP change SADDR => new subscriber)
> and congest those 4k policer slots.
> I make logical-interface on (instead of 'automatic', which means they
> are added dynamically if aggregate policer if out-of-contract, but
> with 'on' they are always there, this guarantees well-behaving IFL
> does not suffer or the duration software detects this and adds the IFL
> policers)
> 
> This is just random recommendation. And funny thing is, you'd need to
> make similar thing to _all_ protools available for 'ddos-protection',
> there are quite many of them, like maybe 100, so you'll get several
> thousand new lines of config just for this.
> I wish there was way to set default explicit values, but there isn't.

Oh dear, that sounds like quite the chore. I don't understand your reasoning behind lowering the parameters so far from the defaults, though. 3000 pps/5000 packet burst is how the box ships. Or am I to read between the lines re: "random recommendation"? lol

Maybe this is something I should talk with JTAC about at this point. I don't want to slam the RE but I don't want to have such a massive cutout, either.

> Hmm, then the redundancy really should have worked, unless you're
> doing some IGMP Snooping or something in the switches (on by default)
> which might require convergence on multicast states on the L2 too.
> If you're rocking RSTP  or MST, and it's correctly configured (all
> non-l2-core ports _MUST_ be portfast, because MST will not unblock
> downstream ports, until there is explicit permission from all upstream
> ports, and if you don't have portfast on in 1 port which is not
> speaking MST, then this port will block whole MST convergence, as
> you're waiting for explicit permission from that port, which will
> never come).

Oh, the redundancy definitely works, don't get me wrong. For some reason the MX is deciding it has to resolve packets instead of just sending whatever comes in with that VLAN tag into an l2circuit.

> Yeah multicast is tricky subject

That's the understatement of the year!

> I dislike
> multicast, I believe there are probably lot of yet unknown DoS vectors
> in it, and I would never run internet multicast. But for well
> controlled internal applications, it may sometimes be least bad
> solution.

Internet multicast, as we have things now, would be an absolute nightmare. But as far as unknown DoS vectors and other quirkiness, I compare it to IPv6 a few years ago. Everybody basically does it half-assed because nobody uses it. The only applications we have for multicast are TV service delivery and some timing protocols here and there.

> But getting help on the setup probably is huge chore, just getting
> external person to understand the network takes time.

Yes, that's for sure. Thank you very much for all of your feedback and effort into trying to understand what's going on here. I'm going to see if our CSE is subscribed to this list and ask him to take a peek.

Thanks again.

Ross