Hi, Do you think MX80 can match the price of MLX-4? I seriously doubt.
Regards, Samit David Kotlerewsky 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
