[f-nsp] NetIron MLX-4 vs Juniper MX240

[David Ball]

  A couple come to mind (though I haven't looked at the 5.0 code at all):

-ability to obtain per-VLAN interface stats on a given dot1q port via SNMP
-logical routers (which spawn unique routing daemons)
-ability to house a global routing table inside a VRF
-some QinQ strangeness which *may* have been resolved by now
-hitless control plane switchover when MPLS is in use
-advanced VLAN tag manipulation (pop, swap, push) before sending to a
VLL/VPLS (might be fixed?)
-no RSVP refresh reduction

  I still really like the MLX/XMR......just tripped over a few of
those things....

David



On 7 May 2010 10:44, Samit <janasamit at wlink.com.np> wrote:
> Hi,
>
> Could you little bit elaborate more about the "advanced feature" which
> is lacking in MLX but available in MX?
>
> Thanks,
>
> Regards,
> Samit
>
>
> Richard A Steenbergen wrote:
>> On Fri, May 07, 2010 at 07:21:35AM -0400, Scott T. Cameron wrote:
>>> 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.
>>
>> Heh yes SRX is painfully slow. I have an SRX210 in my basement for my
>> home connectivity and it takes a good 30 seconds to commit even a basic
>> config. We run MX's with 10k+ line configurations, a heavy dose of
>> commit scripts, and on-commit RE sync, and it only takes around 10
>> seconds at maximum (on RE-2000).
>>
>>> How fast are the Juniper MX series at taking / injecting routes?  How is the
>>> failover convergence?
>>
>> The juniper-nsp list is probably a better place for a detailed
>> discussion on this. Generally speaking Foundry is very "lightweight", so
>> it tends to perform quite well on CPU intensive tasks like this, but at
>> the expense of features and functionality. Feature-wise there is
>> absolutely no comparison, Foundry gets stomped hands down, but like I
>> said if you run a simple network and don't need advanced features
>> Foundry can become interesting based on price and the ability to
>> reliably deliver line-rate traffic (something that can't be said for
>> 6500/7600 :P).
>>
>>> 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.
>>
>> Once you go JUNOS you can't go back. There are things we do with policy
>> statements and commit scripts that are worth their weight in gold, that
>> couldn't be duplicated under IOS let alone under Foundry if their lives
>> depended on it. But the learning curve is steep, and for people who are
>> more comfortable with IOS-like CLI Foundry can provide an acceptable
>> solution. For my needs (running a complex network) we found Foundry L3
>> to be completely unworkable, and had to pull them. But we turned around
>> and sold our MLX's to a customer who had far simpler needs and they've
>> been quite happy. It entirely depends on your network and your needs.
>>
>>> 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.
>>
>> Cisco paid those guys a lot of money to write absolutely absurd bullshit
>> about the competition they are most afraid of, and MX certainly has them
>> running scared. There have been plenty of discussions on j-nsp about
>> exactly which parts are complete and total fabrications, you might want
>> to check the archives from "Miercom".
>>
>>> 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?
>>
>> Not that Juniper support is perfect (you'll find me ranting about it
>> quite a bit on j-nsp :P), but MX is handled by a completely different
>> support group from SRX/J-series (which is very enterprise support
>> focused, i.e. far more resources devoted to answering "RTFM" questions
>> :P).
>>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>