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 <[email protected]> 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 > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp > _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
