[j-nsp] MX104 capabilities question

Ross Halliday ross.halliday at wtccommunications.ca
Tue Jun 7 17:00:48 EDT 2016

Hi Saku,

> I don't see how this makes it any less of a box, in my mind this makes
> it superior box. You lost single PFE/linecard, which happens to be
> only linecard you have.
> In my mind fabricless single-linecard design is desirable, as it
> reduces delay and costs significantly. Not only can you omit fabric
> chip, but you can get >2x the ports on faceplate, as no capacity is
> wasted on fabric side.

This is a good point but kind of tangential to what I was getting at. Before we were really familiar with the MX104, we went on sales and marketing material that talked about "the little" MXes and "MXes with multiple slots". It's very misleading. Even JUNOS MX documentation talks about FPCs being separate in control and forwarding plane operations, when in reality there's only AFEB0 and that's the whole box. No isolation, and "slot diversity" is basically only a little bit better than adjacent ports... Again, contrary to what the popular advice about "multi-slot MX routers" is. The MX104 is not really a multi-slot router in the traditional sense, it just takes more MICs.
> Regarding PR1031696, years ago I had bunch of 3rd party SFPs which
> would crash MX PFE. I practically begged JTAC to fix it. The issue was
> caused by SFP being sluggish to answer to I2C polling, and the code
> which was expecting an answer crashed when it couldn't receive I2C
> answer fast enough. I tried to explain to them, it's only matter of
> time before original SFP develops I2C error, at which point you'll see
> this from customer buying 1st party optics. JTAC was unconvinced, told
> me to re-open if I see it on 1st party.
> I used many channels to complain, but no avail. To me this was
> absolutely appalling and short-sighted behaviour.

Yes, and then it crashes every single SFP... brilliant design backed with brilliant support... give me a break!

> But all platforms can have all kind of problems, and if you would have
> multiple linecards, sure, in this case you'd only crash one of them.
> But just having multiple linecards won't help that much, you can still
> crash all linecards due to RE problem, so you're still going to need
> second router for proper redundancy, at which point it becomes
> immaterial if you have this 'linecard redundancy' or not.

All kinds of problems happen, yes the only "real" safeguard is to put every customer on their own PE. You might remember a previous conversation we had regarding the DDoS Protection mechanism. This thing is a major thorn in my side. Thanks to this "faster" design, when one of these filters kicks in, any traffic matching that class on the ENTIRE box is blackholed. I don't think this is appropriate behaviour: In my experience, it actually *creates* a DoS situation on these boxes.

These routers have their place, they're definitely a Swiss Army Knife type of machine, it's just that the handle is really small...

Oh - and something I forgot to mention in my original email: The MX104 doesn't support ISSU like the "real" MX routers do. ISSU isn't an option until somewhere in the 14.x train, I think, and JTAC's recommended stable release is still in the 13.x train. Kind of ticked about that one.


More information about the juniper-nsp mailing list