juniper mx80 vs cisco asr 1000

George Bonser gbonser at seven.com
Wed Jan 25 12:57:59 CST 2012


> 
> Sorry I can't let a line like that slide.
> 
> I used to use ServerIron's in my last job, and while generally
> wonderful they had two big issues that also occur on other Foundry kit
> like the MLX.
> 
> 1. Multiple firmware files that must be upgraded in sync. While getting
> more common (I've seen kit from Extreme, Cisco, and Juniper that have
> done this to some extent), some of these boxes require on the order of
> four firmware files which must be upgraded in lock-step

They're a little better here these days.  So IF the monitor and boot images change you might need to upgrade those but those don't change on every rev.  I think Cisco sometimes requires updates of things like that, too, from time to time.  Another thing is due to the nature of the beast.  The MLX/XMR is FPGA hardware.  In other words, the hardware itself can be reconfigured with a firmware update.  Most other gear doesn't have programmable hardware.  So in a release two things might have to change.  In addition to a software update, there might also be an associated hardware change that requires an FPGA code update in addition to the OS.  This is actually a good thing from my perspective in that it allows improvements in the hardware without having to get a new rev of blade.  In the "old days" you had to manually update each FPGA image for each blade, that is now a combined file.  There's one FPGA file for all blades.  These are not always required for updates.  The OS is also a combined image so that is just one file.  So to recap:

For some updates you will simply need to update one file:  the combined OS image 

If there is a hardware change, you might need to update the FPGA images. That is a second file but doesn't happen with every release.  In fact, you might not even need it of they DO release a new one because the change might be for the addition of FPGA images or changes to an image for blade you don't even have. But again, it is one combined file for all blades.

If there is a boot rom / monitor change you might need to update those files but that doesn't happen with every release.  If you update the application (OS) image and do a "reload-check" command, it will tell you if you need to update anything else.  Often you don't.

I just went from 5.1 to 5.2 on a couple of MLX units (two more are being upgraded soon and updating some from 5.2b to 5.2c soon) and it was fairly painless.  I think what people don't "get" is that the hardware on the things is reprogrammable and that sometimes requires an additional set of files that has nothing to do with the OS running on the system, it is a hardware upgrade in addition to a software upgrade.  Once people realize that, it takes some of the sting out of it. 

Point is they have combined these images now.  You don't need to load the management module OS, line card OS, management module FPGA and line card FPGA files separately anymore.  You just update one combined OS image.  The FPGA image is updated only if required and again, that is also now one combined file for all modules.  So most updates will be one or sometimes two files with the boot and monitor images updated only infrequently.


> 2. Backspace doesn't work. Seriously (ok Ctrl-h works, and you can
> patch your terminal emulator for it, but it's the only hardware I've
> used in the last 15 years like that)

I've noticed that though I think that is only on the hardware console port.  Most of the work I do is via the management port.  If I'm on the console serial port, then I am working manually and just deal with the ^H thing.  I don't think that issue by itself is enough to prevent me from buying a piece of gear.  The applications where we use the MLX units is pretty straightforward and their price/performance is great for that application.  But I'm not married to any vendor and if there is a better tool for a particular job, I'll use it.  Each vendor seems to have their "sweet spot" for various applications.



More information about the NANOG mailing list