On 30 November 2015 at 12:34, john doe <kill...@zoho.com> wrote: Hey,
> Looking at MX104 vs ASR 9001 as a potential solution. > > Requirements are fairly straightforward - 1GE to collect customers and 10GE > going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier > NAT. For either of these NAT is bit awkward, as it's going to have to go via separate service card anyhow. Unless you could live with 1:1 NAT, but I believe CarrierNAT implies NAPT. If all traffic is NAPTed traffic, you might want to go with ASR1k instead. > Customer wants a box that will give them most room to grown in terms of > scale/features. And we can't go full modular since rack space is big pain for > these guys. Price is also an issue (as usual) > > I heard good stuff about Juniper SP gear, while not so complimentary things > of ASR. But that was when platform was introduced and they had all sorts of > IOS-XR adventures. > > Would love to hear some input from here as vendor claims are conflicting > (nothing new here I guess) For ASR9001 and MX104 I would definitely choose MX104. Both boxes have serious problems, but MX maybe less so. Largest problem MX has is that it's decoupling route HW insertion and readvertisement in SW+HW, so in scaled BGP environment you're going to do some blackholing during convergence. This may be minor inconvenience or major headeache. HW in MX104 is simpler, as it's fabricless, which I think is very good thing as long as you can get away with it, distributed architecture is just harmful. I think Trio is better story than ASR9k engine story, it's still same microcode and fundamentally same design from oldest MPC1 to newest MPC, unlike ASR9k which is making jump to entirely new engine, and even Trio to EZChip, I think Trio wins. JunOS and IOS-XR are both terrible in their own way. I have more faith in JunOS today than in IOS-XR. JunOS is very conservative, run-to-completion single threaded RPD (much same design as IOS XE), which in theory requires very very good code quality to pull it off, and in JunOS the code quality issues related to run-to-completion flat model manifests as 'RPD slips', where you might lose your IGP because commit took too long. IOS-XR is architecturally more modern, but they likely made some architectural design flaws, as the platform seems to have quite large amount of state errors. Perhaps Barney was wrong, perhaps newer isn't always better. I think most innovation is to be made in control-plane software. Everything today is basically awfully fragile hacks. > Anyone with experience on ISSU on these platforms? Yes. Don't. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp