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

[Saku Ytti]

On 3 February 2016 at 19:09, Ross Halliday
<ross.halliday at wtccommunications.ca> wrote:

> 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

Lot of the DDoS-protection limits are 20kpps by default, which is more
than the NPU will even punt to the PFE CPU, so there will be
additional policer anyhow limiting more strictly. The defaults are
unfortunately not sane.
Only reason you'd need to punt multicast, is to fix your ingress
interface in the HW, so really 1 packet per group will do, anything
extra is just additional useless work for CPU.

> 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.

Absolutely, always good idea to engage vendor support.

> 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.

Reason is, the ingress interface of mcast stream changed, so the
multicast tree was incorrect.

> 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.

I did quite few multicast setup for companies running CCTV, where CCTV
by default sends to multicast (But can be changed to send unicast). In
each of these configurations the CCTV only had single host join
(recorder). So multicast was just useless complexity with no
advantages, so I guess my failure as I was consistently unable to to
convince them to reconfigure the CCTV's for unicast.

-- 
  ++ytti