My experience with both lines(I've used MX480/960 & MLX-16/32) has thus far 
been pretty good.  I personally prefer JunOS, but that's as much a familiarity 
issue(worked in a couple Juniper-laden ISPs for several years) as anything.  
The IOS is a pretty easy ramp-up for anyone with significant Cisco experience.  
It seems that the entire Foundry line has improved since Brocade bought them 
out; I used to feel similar to you when it came to their support, but these 
days I haven't had any problems getting questions answered/RMAs processed.  
Other things they've done - like moving to unified images instead of having to 
upgrade multiple binaries - make me think the Foundry/Brocade line is on the 
right track.  Having said that, the Juniper MX series is a good platform & has 
a lot going for it.  I'd agree with earlier assessments about price, Junipers 
have always been pricy.

What kind of failover are you considering?  Are you talking about failover 
between redundant routers or internal failover(between mgmt modules, etc.)?

(Full disclosure: I work for a Brocade subsidiary.)


Jonathan Brashear
Strategic Business Systems, Inc.
13800 Coppermine Road, Suite 400 | Herndon, VA 20171
Work: 214-887-7719 x 101-7719 | Cell: 214.850.5986 
Please visit our web site at www.sbsplanet.com

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Scott T. Cameron
Sent: Friday, May 07, 2010 6:22 AM
To: [email protected]
Subject: Re: [f-nsp] NetIron MLX-4 vs Juniper MX240

(forgot to copy back the list)


Thanks, this is really helpful.  I do appreciate the cost difference.  We do 
have some "credits", so to speak, due to our early adoption of the SRX series.

Some of the routing engine tasks done on the SRX series are really, really 
slow. I have my SRX series taking a full route table from my upstream providers 
today on BGP.  This process can take about 5 minutes to complete.  Obviously, 
this is insane.

How fast are the Juniper MX series at taking / injecting routes?  How is the 
failover convergence?

For the CLI, I'm not sure that I like JunOS better than the IOS clone.  My 
former career was entirely Cisco, so the IOS clone is like an old, familiar 
friend for me. I have more or less gotten over the learning curve with JunOS, 
though.  And I do like it is a familiar FreeBSD system underneath, even 
allowing you to go in to a shell.

There's a site I found, which I suspect is likely to be a bit of a Cisco 
talking point, but interesting nonetheless: 

http://bradreese.com/cisco-vs-competitor.htm

Some of their "studies" show that the MX-series routers have some trouble 
during failover.  I am taking it with a grain of salt, just curious of anyone 
has had those experiences.

On the MLX side of things.  With a rather large Foundry switching environment, 
I and my team are very comfortable on that platform.  The switches just work, 
and the strangest problem I have seen interop problems with a Cisco -- and I 
blame Cisco for that.  We have had some struggles using the Foundry ServerIron 
due to a few bugs here and there.  I do, however, expect that a full layer3 
stack is significantly less complicated of code than what the ServerIron is 
able to do, so should have less bugs.

They are marketing the dual management modules as ISSU-capable.  There is a 
cost difference, but it's not even 25% for our config.  

Last but not least, support.  Both vendors have terrible technical support when 
you have a bug, in my experience.  I loathe having to open a case.  Is it 
different for support on the router series?

Thanks for all the wisdom, much appreciated.

On Fri, May 7, 2010 at 12:46 AM, David Ball <[email protected]> wrote:


         I eval'd the XMR-4 for a couple of months (same as an MLX, really),
        and for the most part was quite happy with it.  Amazingly fast boot,
        seemed stable to me, and I actually recommended it to management for a
        portion of our network.  Politics took us in a different direction
        though, we stuck with Juniper (we have a T-series core, and now some
        MX480s/240s).
         Off the top of my head, these were a few of the 'shortcomings' I
        found with the MLX-4 which, for us, wouldn't have necessarily been
        showstoppers, as workarounds were surely available.  They may or may
        not apply to you at all:
        
        -can't gather per-VLAN input/output stats via SNMP on a dot1q port
        (displays total port stats only), although the account team committed
        to providing a fix if we bought x number of them)
        -there were some QinQ intricacies that I had a hard time wrapping my
        head around, but eventually made it work
        -couldn't hold a global routing table inside a VRF/L3VPN due to the
        TCAM memory partitioning Brocade uses (we house the internet in a VRF
        on our Juniper network).
        -unable to do dot1q *and* MPLS on the same physical port (fixed in
        release 5.0.0 apparently)
        -code upgrades are a little clumsy, with multiple image upgrades
        required, and no In-Service Software Upgrade as far as I know.
        
         I never touched IPv6 on it, so can't help you there.  But, I was
        running OSPFv2, BGP (no full tables during my eval), MPLS (LDP &
        RSVP-TE w/FRR) and interop'ing with some Junipers, and built VLLs,
        VPLSs, and VRFs which all worked between the platforms.
        
         I've heard the odd report of frequent hardware failures on the
        XMR/MLX line, but can't say how recent said reports are and I didn't
        hear them first hand.
         I still really like the MLX/XMR boxes, and would love to get my
        hands on one of the new CERs, but alas, it may not be in the cards.  I
        think the MLX is a decent box (we ended up buying an MLX-4 which still
        sits in our lab) and you simply can't beat the price (they were less
        than 1/2 the price of similarly spec'd Juniper, Cisco and
        Alcatel-Lucent boxes).
        
         That said, the MX240 is a great box too, if not a little
        weird.....only 2 slots for line cards if you have redundant REs.  Tons
        of horse power, best CLI IMO, and generally speaking it just 'works'.
        If it weren't for the extraordinarily high price, I'd say it was a
        near perfect box.
        
         Anyhow, not sure it helped, but good luck.
        
        David
        




        On 6 May 2010 19:59, Scott T. Cameron <[email protected]> wrote:
        > I'm in the market for a new edge router.  It must be capable of 
performing
        > BGP on IPv4 and IPv6, OSPF and scale to 10GbE uplinks.
        > The two products in mind are:
        > Foundry NetIron MLX-4
        > vs
        > Juniper MX240
        > There will be no more than 10 BGP sessions in the configuration.
        > I have had a bad experience from having early adopted the Juniper 
SRX-series
        > firewall, so I'm not sure if I can trust their product lines.
        > We already have a large install base of Foundry FESX648s and SX800s 
in the
        > core.
        > Anyone have experience with either?  With both?  Or any other useful
        > guidance?
        > Thanks.
        
        > _______________________________________________
        > foundry-nsp mailing list
        > [email protected]
        > http://puck.nether.net/mailman/listinfo/foundry-nsp
        >
        





The information contained in this transmission may contain privileged and 
confidential information. 
It is intended only for the use of the person(s) named above. If you are not 
the intended  
recipient, you are hereby notified that any review, dissemination, distribution 
or  
duplication of this communication is strictly prohibited. If you are not the 
intended recipient, 
please contact the sender by reply email and destroy all copies of the original 
message. 
To reply to our email administrator directly, please send an email to 
[email protected].

_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp

Reply via email to