[j-nsp] Going Juniper

[Saku Ytti]

Hey,


On 23 April 2018 at 16:25,  <adamv0025 at netconsultings.com> wrote:

> Well I envy you then :).
> But was it for more-less like to like HW? -say modular card in both cases -similar physical/logical BW to fabric and similar modules with similar port count?

Yes.

> Was it just one time RPF discount or a pricing framework for future deals.

Both have happened.

> Now with the knob available in 17 Junos the benefit of A9k architecture is reduced to the ability to protect high priority traffic when NPU is overloaded down to 10GE entity level whereas on Juniper it's just per NPU as a whole.

I think the scenario you have may not be scenario many have. I know
ASR9k drops on ingress on 10GE basis, so let's say your egress 10GE
port has 5 VLANs, you've shaped them to 1Gbps each. Then one VLAN gets
20Gbps DDoS, all of the VLANs are congested, because you're dropping
10G on the ingress NPU, unaware of the egress VLANs.
This same scenario would work just fine in MX.

I'm not saying MX is superior on QoS. I'm just saying when you know
the compromises made by each platform, and you cherry pick
compromises, you can make anything look bad/good, this is what vendors
pay Miercom to do. The results are not fabrications, but are they
practical or useful to most or even many?

> That's why I say in general, sure there are exceptions.

General would need thorough data. Our opinion is coloured by which
platform gets features that are relevant to us, we don't track those
unrelevant to us.

> Interesting, just curious how may VRFs/prefixes you ran into scaling issues?

No VRFs. We have RIB of some 10M prefixes and about up-to 1M lines of
config in device.

> That's certainly a valid viewpoint on the patches thing.
> I'm looking at it from a different angle though, the angle I'm looking at it is software testing (regression testing in particular).
> We spend significant effort on SW testing making sure it works as expected, now if midway or god forbid towards the end of the whole exercise we find out a show stopper we can't afford to repeat the whole process again for a different release that doesn't have this problem (or wait for one to be developed) this is where targeted patches are great help -you just need to test dependencies for the delta then.
> (and no having vendor to do the bug scrub and recommend bug free code for your specific case is not the solution, will get you some head start but you still need to perform the rigorous testing).

I can't agree with your testing point, the testing you've done is not
valid post SMU install. You are not spot fixing anything with the DDTS
SMU, it's just newer version of given binary with all the changes
included. Unless you're getting some engineering SMU and special build
for you, which they usually refuse to support in meaningful way, so
it's operationally risky.

-- 
  ++ytti