[j-nsp] MX80 vs MX240

[Richard A Steenbergen]

On Tue, Oct 19, 2010 at 01:50:59PM -0400, Tim Donahue wrote:
> Hi all,
> 
> We are working on a new colo deployment and we are trying to choose
> between the MX80 and the MX240.  With our current budget the MX240 is
> definitely a stretch over the MX80.  On paper, the MX80 has more than
> enough horsepower to meet our needs for the foreseeable future, however
> I was wondering if anyone has any comments on their experience with it
> in production.  We are looking at the MX80-AC chassis with the 20x1Gb
> SFP MIC card with a mixture of SX and copper SFPs.
> 
> Our immediate needs:
> 
> - IPv4 and IPv6
> - BGP (3-4 full tables, 1-2 partial tables)
> - OSPF
> - Sampled netflow
> - SNMP monitoring
> 
> Has anyone had problems running the MX80 in their network, with the
> features above or with other commonly used features?  Other than access
> to the MS-DPC blade and the expandability for the larger MX systems, are
> there any significant benefits to using a MX240 over the MX80?

As far as the chassis goes, the biggest downside to MX80 is probably 
going to be the fixed config single RE. This isn't just an issue because 
of the obvious lack of redundancy, but it's going to make your sw 
upgrade process a lot more painful too.

Currently the best way to do a JUNOS upgrade (assuming ISSU doesn't 
work, which might actually be a safe bet, since it hasn't worked 
succesfully for me since 9.4) is to pre-stage the new code on your 
backup RE, then do a switchover to it. The process takes about 1-2 
minutes to do the switchover and reboot the cards with new code, and 
you're pretty much guaranteed that it's going to work correctly (since 
you can verify that the backup RE is correctly booted and functional 
before you do the switchover). You can also take the opportunity to 
pre-stage any config changes you want to make at the same time, to avoid 
the extra impact of making those config changes later.

With only a single RE, you'll be reduced to "jinstall and pray". If 
anything goes wrong in the config validation or code installation 
process, you may very well find yourself with a dead box that just never 
comes back. I've personally run across about a dozen conditions/bugs 
that would have caused this over the last few years, so I'd HIGHLY 
recommend you never do a code upgrade without working OOB and console 
access. This also extends the total time from 1-2 minutes to more like 
15 minutes, since you now have to jinstall, reboot, run the install 
image, newfs and copy the new code, reboot again, and then finally boot 
the cards.

The MX80 RE is also a bit slower than the RE-2000 that currently ships 
with modular MX, and will be significantly slower than the new Core 2 
RE's that they're planning to ship in the nearish future. An interesting 
factoid is that the MX80 actually uses a dual core PowerPC cpu, but only 
one core is supported in sw currently. The same will be true of the dual 
and quad core Core 2 RE's, JUNOS is still extremely lacking on support 
for SMP, so you probably won't see the sw support for it any time soon.

As far as the actual PFE goes, MX80 is basically just a single Trio PFE 
splayed open so that you can do 80Gbps of switching thanks to the lack 
of fabric interconnections with other PFEs. The Trio cards are far more 
featureful, not to mention cheaper, and are a far better long term 
investment. Of course in the short term they're far buggier, but I 
probably wouldn't recommend you go out and buy an MX240 + Old DPC on 
that basis alone. 

In your situation, and especially with a relatively simple 
configuration, I'd recommend buying the MX80 and running nothing earlier 
than 10.2R3, with the associated caveats about making sure you have 
working OOB, and try to take it easy on the box for a little bit until 
all the bugs are worked out. When they add virtual chassis support at 
some point in the future, maybe you'll be able to recover your RE 
redundancy that way. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)