[j-nsp] Going Juniper

Saku Ytti saku at ytti.fi
Tue Apr 17 19:02:57 EDT 2018


Hey Ross,

> The low-end MXes can do a lot of things, but that doesn't mean you SHOULD necessarily do them. Anything CPU-heavy is a good example. Convergence time on three full feeds takes about 10-15 minutes in my experience, say in the case a major upstream drops. This isn't a big deal for everyone and for my employer certainly not enough to justify a bigger box on its own. One of the platform's strengths is also its weakness, in that the MX104 is essentially fabricless. Each of the "PIC" slots is a carved out chunk of a single forwarding engine. This is why they're limited to the 2-XFP MICs for 10 GbE options, unlike bigger MXes that take MICs with a much greater port density and support more than 4 SFP+es. This is also why you have things that will affect the entire chassis at once, such as one of my favourite optics bug (plug in an SFP too slowly and all SFPs reset) and the DDoS Protection feature (blackholes an entire class of traffic on ALL ports). They are not suitable for core use for th

DDoS protection out-of-the-box is for all practical purposes not
configured at all, which is unfortunate as that is what most people
run. When configured correctly Trio has best CoPP I know of in the
market, certainly better than Cisco or Arista have.

DDoS protection has many levels 1. aggregate 2. per-npu 3.
per-physical-interface 4. per-logical-interface 5. per-subscriber
(session).

5. is dubious, as it's easy to congest the policer counts (Attacker
changes SPORT). But 3-4 should protect you from issue you describe. If
you limit each IFL or IFD, then single IFL or IFD won't congest whole
NPU, and having for example BGP down in the IFL which is violating the
BGP policer is entirely acceptable.

-- 
  ++ytti


More information about the juniper-nsp mailing list