<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div>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.</div></span></blockquote><div><br></div>This is my experience as well. Other than a couple buys involving (1) QoS + MPLS, (2) adding/removing VPLS's too quickly, and (3) the BGP AS path length problem we've not had any issues. Both of those bugs were already identified and resolved.. we just had to do a quick software upgrade. Since we're a research network, we use quite a few of the features.. and most of the newer features.<br><blockquote type="cite"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> <div><br></div></span></blockquote><blockquote type="cite"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div>There is a cost difference, but it's not even 25% for our config.  </div></span></blockquote><div><br></div>Really? I've not priced an MX device recently but to get a box with *-R cards used to be stupidly expensive. Then if you wanted to do advanced QoS it got completely insane.<br><blockquote type="cite"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div><br></div><div>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?</div></span></blockquote><div><br></div>We were early SRX adopters as well. Painful indeed. Hopefully you are not trying to manage the devices via NSM. :(</div><div><br></div><div>I've experienced pretty solid support from Brocade since the merger/buyout/whatever. Juniper's support at the SRX and J-Series level is pretty weak IMHO. Things like "we don't have IPv6 in the lab so can you mock this up for us?" is not what I want to hear from a router manufacturer. I'm sure the MX support engineers are better though.</div><div><br></div><div><br></div><div><br></div><div>I like that the MLX has a high density 10G card available (hoping the XMR gets one soon). I don't know if total throughput is a major concern for you, but an MLX 4000 with four 8x10G cards represents a significant amount of throughput in a very small form factor. And I **believe** the MLX has a roadmap to 100G, but be sure to check with your SE to be sure.</div><div><br></div><div>Next to last note: I've not seen specs on the MX recently but the MLX/XMR are very efficient with space and power. We were surprised how little the XMR with a couple 4x10G cards consumed. Certainly makes leasing space and power in someone else's facility easier!</div><div><br></div><div>A final note: We perform software upgrades once a year (during the summer) unless there's an emergency. Having a core router that can reload, take multiple full table BGP feeds, converge everything and be routing traffic 3 minutes after hitting enter at the "reload" command is really nice. We have so much confidence in the devices, we reload all of them at the exact same time.</div></body></html>