Ah, good point, but... the MX80 will support RE redundancy via a Virtual Chassis technology with another MX80, so not only RE redundancy, bu chassis redundancy as well, which ios not something you can get with a single MLX.
On Fri, May 7, 2010 at 2:51 PM, David Ball <[email protected]> wrote: > ...except that the MX80 won't have redundant REs (mgmnt modules) > or switch fabrics like the MLX does. > > D > > > On 7 May 2010 14:38, David Kotlerewsky <[email protected]> wrote: > > I'd say wait for MX80 to come out, and then compare the two. The MX80 > will > > have a much more attractive price point than the MX240. Then you can have > a > > decent comparison between say an MLX-4 and an MX80. > > > > Sincerely, > > > > David Kotlerewsky > > Sr. Systems Engineer > > InterVision Systems Technologies, Inc. > > www.intervision.com > > > > On Fri, May 7, 2010 at 12:56 PM, Debbie Fligor <[email protected]> > wrote: > >> > >> On May 7, 2010, at 6:21, Scott T. Cameron wrote: > >> > >> > > >> > 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. > >> > > >> > >> > >> Our backbone (core and distribution layers) are MLX routers (I'm at the > >> Urbana campus). Our regional network that connects the three campuses > are > >> also MLX routers. I would not suggest you assume fewer bugs than you've > seen > >> in the ServerIrons. > >> > >> We see much fewer headaches with their L2 devices typically than with > >> their L3 devices, but we've moved to HP over the years for > price/performance > >> for most of our L2 access ports. Our experience with BGP and OSPF is > that > >> those protocols are pretty solid. ACLs are buggy, at least if you use > them > >> on a ve instead of a physical port, and PIM/MSDP is one of those things > you > >> keep your fingers crossed about with every single software upgrade, > hoping > >> that they fix more things than they break and that they will move > forward in > >> being fully standards compliant. mBGP (for multicast) is hit and miss, > at > >> least on our MPLS based regional network. Some of that is config > choices we > >> made, some is their (apparent) lack of QA for anything multicast. > >> > >> they are fast hardware switching, and they reboot fast though and > they're > >> usually pretty good about fixing problems once you finally nail down > what > >> the problem is. I'll echo what someone else said, if your needs are > simple, > >> they'll probably work fine. I can't honestly recommend them if you run > PIM > >> or MSDP however, that has been (and still is) a nightmare to keep > working > >> correctly. > >> > >> I can't compare to the Juniper MX, we've not got any of those. > >> > >> ----- > >> -debbie > >> Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il > >> email: [email protected] <http://www.uiuc.edu/ph/www/fligor> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
