Hi,
> Saku Ytti
> Sent: Monday, November 30, 2015 11:28 AM
> 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.
I think this can be alleviated with BGP provider edge link protection(Cisco BGP
PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
However in Junos this is available only for VRFs.
> 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.
That's right Trio's LU is just better, it can cope with any combination of
features enabled with only small performance hit compared to A9k's NPU.
However if QX chip is used the whole LU performance advantage is jeopardized
(but at least the degradation is deterministic).
> 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.
Or you get random convergence times when adding links to bundle.
> 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.
>
Yes XR is more modern and as a consequence there are a lot of things/features
that makes your life easier that I miss in Junos.
Technology wise Junos is trailing XR, so any feature introduced into XR is
going to be available in Junos only on releases that are more towards the
bleeding edge.
Also the basic Junos documentation is incomplete and getting some deep level
information is next to impossible.
> > Anyone with experience on ISSU on these platforms?
>
> Yes. Don't.
>
Yeah the only platform out there that promises working ISSU are the NCS series
from Cisco, but would love to hear the real world stories.
And what about ASR903 it's very similar product to MX104.
adam
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: [email protected]
W: www.gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of
this email are confidential to the ordinary user of the email address to which
it was addressed. This email is not intended to create any legal relationship.
No one else may place any reliance upon it, or copy or forward all or any of it
in any form (unless otherwise notified). If you receive this email in error,
please accept our apologies, we would be obliged if you would telephone our
postmaster on +44 (0) 808 178 9652 or email [email protected]
Gamma Telecom Limited, a company incorporated in England and Wales, with
limited liability, with registered number 04340834, and whose registered office
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
