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

[Saku Ytti]

On 1 February 2016 at 22:37, Ross Halliday
<ross.halliday at wtccommunications.ca> wrote:

Hey,

> If I am understanding what you guys are saying correctly, this would cause everything to get punted to the CPU until a new hardware shortcut is created, and in the meantime - since our entire channel lineup is in there - this would hammer the DoS protection mechanism?

Yes, if ingress interface does not match, they will be punted.

> Can the rate at which the joins are sent out be slowed? I can live with a bit of a delay on the channels coming back to life, but not with the entire slot getting blackholed...

What do you mean 'entire slot being blackholed', do you mean losing
unrelated control-plane stuff, like BGP/ARP etc? If yes, just limit
the mcast resolve to something reasonable 100pps should be plenty,
provided we're not competing with actual attack traffic.

I would start with ddos-protection fixes and see if it behaves better
with more restricted punting. Further research might involve figuring
out if both MX boxes have multicast state with source towards the
local EX port, and clients subscribed. So that no convergence is
needed.


It wasn't obvious to me what kind of negative impact you observe when
the EX-EX link goes down. How are you now stopping loop in the EX
network? You have direct physical link between them, then you have
l2circuit as well? But it looks like you're not carrying BPDU over the
l2circuit? So if you rely on STP, I'm not entirely sure how the L2
redundancy works, which port is normally being blocked? The actual
physical link between switches or the link via l2circuit, since  my
first guess would be that there would be L2 loop in the topology and
nothing to stop it, so I'm not sure I understand why it works at all.

-- 
  ++ytti