[c-nsp] Real life and worst-case performance of Cisco and Juniper?

[Mark Tinka]

On Friday 27 February 2009 10:08:02 pm Rick Ernst wrote:

> I'm looking at a network refresh and both Cisco and
> Juniper are on the radar.  We are currently almost
> all-Cisco.  The two platforms we are looking at are the
> Juniper M10i and the Cisco 7606/Sup7203BXL.

If you're looking at a much closer comparison, you'd be 
considering the ASR1004 or ASR1006 from Cisco to match 
Juniper's M10i platform.

> Our bandwidth needs are pretty modest; currently less
> than 500Mbs amd our packet consumption is about
> 75,000pps.  I'm currently projecting over 1Gbs in about a
> year.  Our existing gear (7200/7500/RSM) handles the load
> fairly well, but memory on the VIPs, RSMs, and older RSPs
> can't handle a full table.  We also need to be able to
> absorb high pps DDoSes.

No experience with the 7500 platform, but depending on your 
configuration, you could likely get 600Mbps to 750Mbps out 
of an NPE-G2 positioned as an edge router.

However, as you mention, you want some protection against 
DoS0-type traffic, so there isn't much headroom to work with 
in that respect. Besides, you're not likely to hit 1Gbps of 
routed traffic through the NPE-G2 either. Bottom line, the 
ASR1000 series might make more sense here (but watch out for 
feature support; things you're already running on your 
7200's).

> Juniper seems to essentially claim that "you get whatever
> the platform is spec'd for, regardless of packet
> size/type" at ~4-8Gbs.

We've spoken to our Juniper account team about these figures 
across their platforms. However, in actual practice for us, 
I guess we haven't yet pushed the routers to their limits to 
see this become an issue.

Yes, we are seeing far more tolerance than the 7200, but 
then again the M10i is a hardware platform, so that's not a 
fair comparison.

I'd suggest doing a PoC with your Juniper team as part of 
your purchase requirements, and throw various packet sizes 
at it and see if you are happy.

> Cisco claims 720Gbs
> (full-duplex?) and about 40Mpps on the 720 with DFC.

The advertised 720Gbps/400Mpps assumes v4 traffic at 
40Gbps/slot in, at least, a 9-slot chassis (which means 
fabric-enabled line cards running with DFC's installed 
pushing that much traffic). So you may not actually get this 
depending on how you populate each slot, how big your 
chassis is, and whether you decide to have a redundant 
supervisor engine. It doesn't mean the system isn't 
delivering, however.

The whole full-duplex/half-duplex thing is "marketing stuff" 
that gets in the way of technical capability. Grrrr... 
someone else should probably get into that :-).

And yeah, v6 traffic supposedly halves that forwarding 
capacity...

> Our border/core pretty much just moves packets, so I'm
> not too worried about the packet handling at that level. 
> A large portion of our customer traffic is
> rate-limited/policed (hundreds of ethernet connections).

Pretty standard.

> Does anybody have any "Yeah, Juniper really does that"
> stories, or experience with how packet manipulation
> impacts the Sup720 performance? Essentially, what could
> the Sup720 handle if every packet hit the CPU? Does the
> architectural difference between the Sup720 and 7200/7500
> at least somewhat mitigate CPU impact with CAR/policing?

You don't want (transit) packets hitting your CPU. The 
SUP720 supports some features in software; don't run them 
there if it can be helped (which should be all the time). 
Besides, word is if it's not done in hardware, it's not 
supported.

Policing can be done in hardware on the PFC/DFC, so no need 
to worry about that impacting your control plane.

As others have mentioned, consider the RSP720/MSFC4 instead, 
for the 7600. I'd say look at an ASR1000 as it looks closer 
to what your migration path might be, particularly if you're 
looking to terminate leased lines too, in addition to 
Ethernet.

AFAIK, Juniper, on the otherhand, don't generally punt to 
software. If it's not supported in hardware, it won't work. 
This means they'll offload some functions to specialized 
line cards, e.g., tunneling, flow collection/export, e.t.c., 
for platforms that don't have integrated components that can 
do this, or support them natively with limited 
functionality, i.e., enough not to break the box. This 
varies.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090227/c9e07016/attachment.bin>