[j-nsp] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 30 November 2015 at 12:34, john doe <killbop at 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