Optical/IP Networks

Internet Core Router Test

Juniper Wins!

It’s worth repeating: Juniper wins.

But it’s also worth noting: its archrival, Cisco Systems, ran a close second.

Here's the sound bite: After 10 years at the top, Cisco Systems no longer has to worry about the competition catching up. Now it has a new challenge: Playing catch-up to the performance of routers from rival Juniper Networks.

That’s the simple conclusion to be drawn from six months of arduous testing that pitted Juniper’s flagship M160 against Cisco’s brand-new 12416 in the first head-to-head comparison of 10-Gbit/s routers. It’s also the first time Cisco has agreed to let any of its gear be evaluated in an independent public test.

Actually, “test” is a pretty bland word for what would be considered cruel and unusual punishment in most states. Basically, we threw all the traffic on the Internet — and then some — at these bit-blasters in hopes of cutting through the white noise of vendor white papers. At every step of the way we were ably aided and abetted by our partners in crime: Network Test Inc. of Hoboken, N.J., a benchmarking and network design consultancy; and Spirent Communications of Calabasas, Calif., a test equipment supplier.

Here’s what we found:

Juniper’s M160 is the best of breed. It beat out Cisco’s product in three out of four overall areas: IP, MPLS, and OC192 (10 Gbit/s). Cisco and Juniper shared the honors in the fourth category: OC48 (2.5 Gbit/s) performance.

In some areas, the M160 is in a class by itself: It holds more BGP routes and more MPLS label-switched paths than any other box. It deals with network instability far better. And it exhibits much lower average latency and latency variation.

Specifically, the M160 outpaced the Cisco 12416 in seven out of the 16 individual tests offered, and tied for first with Cisco in five events (see Table 1). Where does that leave Cisco? With an impressive product that pulled ahead of Juniper in the four remaining tests.

Table 1: Results Summary
Charlotte's Networks Cisco Systems Foundry Networks Juniper Networks Winner
IP baseline tests: OC48 3* 1 4 2 Cisco
MPLS baseline tests: OC48 N/A 1 N/A 1 Cisco, Juniper
IP baseline tests: OC192 N/A 1 N/A 1 Cisco, Juniper
MPLS baseline tests: OC192 N/A 1 N/A 1 Cisco, Juniper
Longest-match lookup: OC48 N/A 1 2 2 Cisco
Longest-match lookup: OC192 N/A 1 N/A 2 Cisco
BGP table capacity N/A 2 3 1 Juniper
MPLS LSP capacity N/A 2 N/A 1 Juniper
Route flapping: OC48 N/A 1 3 1 Cisco, Juniper
Route flapping: OC192 N/A 2 N/A 1 Juniper
Convergence: OC48 N/A 2 3 1 Juniper
Convergence: OC192 N/A 2 3 1 Juniper
Filtering: OC48 N/A N/A 2 1 Juniper
Filtering: OC192 N/A N/A N/A 1 Juniper
Class of service: OC48 N/A 1 N/A 1 Cisco, Juniper
Class of service: OC192 N/A 1 N/A 2 Cisco
* Numbers represent relative ranking
N/A = Not applicable
OC48 = 2.5 Gbit/s
OC192 = 10 Gbit/s
BGP = Border gateway protocol
LSP = Label-switched path
MPLS = Multiprotocol label switching

For a yet more detailed breakdown of the test results, click here. There’s no doubt that the 12416, with its OC192c interfaces and 320-Gbit/s switching fabric, is a vast improvement over its GSR predecessor. Keep in mind that Cisco’s product is new — and thus less seasoned than Juniper’s M160, which has been shipping since spring 2000. In fact, Cisco’s new offering is just a memory upgrade and a couple of features away from being a serious threat to Juniper.

Now things get interesting.

There’s only one way for Cisco Systems Inc. (Nasdaq: CSCO) to take its second-place finish: personally. Over the past few years it’s watched Juniper Networks Inc. (Nasdaq: JNPR) walk away with market share (some would suggest that “run away” is a more apt description). Its stock, which once seemed to deny the laws of gravity, is in freefall. Cisco didn’t just want a win; it needed one. But the test results prove it’s not about to walk away from the core market.

So if Cisco and Juniper have at each other, does that mean other core router vendors stand to benefit from the bloodshed? Not in this market. True, there are a bunch of startups out there that claim they can deliver something the market leaders can’t. Unfortunately, what most can’t deliver is a core router. We issued our call for products to 11 vendors. There were only two other takers besides Cisco and Juniper: Charlotte’s Networks Ltd. and Foundry Networks Inc. (Nasdaq: FDRY).

How did they do? Let’s just say we were underwhelmed by the test results. Maybe Foundry got the message. After we’d finished testing its product, it announced that it was bailing out of the core router business. Smart move (see Foundry Retreats from the Core). This market belongs to our two top finishers for the foreseeable future.

Then again, both Foundry and Charlotte’s Networks deserve credit for having the guts to show up. Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7), which is the number three core router player in terms of market share, had agreed to take part but, in the end, thought better of it — they didn't show.

Links to the individual sections:

The Core of the Problem
Building a Better Testbed
OC48 Throughput and Forwarding
OC192 Throughput
MPLS Throughput
Looking at Latency
Packet Ordering
Longest-Match Lookups
BGP Table Capacity
MPLS Tunnel Capacity
Route Flapping
Convergence Testing
Focus on Filtering
Quality of Service

Test Methodology
1 of 15
Next Page
Page 1 / 44   >   >>
gereizt 12/5/2012 | 3:17:16 PM
re: Internet Core Router Test Goto any looking glass and show the ip routing table. As for ACL rules, forget about it. You are asking someone to show you the addresses they allow and block and what, how and why. You aren't going to get it from a major provider and shouldn't get it from anyone with any kind of security sense.

Tony Li 12/5/2012 | 1:21:24 AM
re: Internet Core Router Test In fact, both matter, but the packets/sec is harder to achieve. Consider that for each packet, a router has to perform an IP lookup, make a switching decision and get the packet to the correct output interface with the correct encapsulation.

The amount of work is the same regardless of the size of the packet. This leads some manufacturers to skimp on the processing power for packet processing, so they will underperform when tested with small packets. With large packets, the packet processing rate is lower, so it's simply a matter of bandwidth. Most players get that right, or come arbitrarily close.

rsunkara 12/5/2012 | 1:21:24 AM
re: Internet Core Router Test Hi,

I am interested in knowing why the router performance is measured in packets/sec and not bits/sec??

bgopi 12/5/2012 | 12:57:39 AM
re: Internet Core Router Test Hi,

Is there any place where i can get the typical core router' routing table dump and the ACL rules dump of the same?

Can someone help me in this regard.

Please mail me at [email protected]
Mathew Orman 12/5/2012 | 12:19:04 AM
re: Internet Core Router Test http://www.ultra-faster-than-l...
Mathew Orman 12/5/2012 | 12:19:04 AM
re: Internet Core Router Test http://www.ultra-faster-than-l...
Chughster 12/4/2012 | 11:22:58 PM
re: Internet Core Router Test Can some one explain the possible causes of the following trend:

With NAT enabled throughput for larger sized packets is lower than the throughput for smaller sized packets. That is, Packet streams with 64 byte size packets have a higher throughput compared to packets with 1500 byte size packets. The media is Fast ethernet. I am not sure if this is related to NAT in any way or if it is just an inherent switching performance any general router. Anyone with packet-switching knowledge please comment. The router is of VXR(NPE400). The MTU size is standard 1500 bytes for the interfaces.

What could be a logical explanation of this trend?

Janus Chu
metrodude 12/4/2012 | 11:03:20 PM
re: Internet Core Router Test Hello David,

A would like to suggest/request from Network Test
and LR for any future testing scenario's that
you please revisit the methodologies, tools if required, Etc..

Have you looked at what a Spirent "Smartbits" unit
actually puts on the wire with a protocol analyzer ? It does some things that may effect
the validity of what your trying to accomplish.

What is your criteria for selecting test equipment?

How about very detailed representation in the tests and criteria that is defined by standards to acomplish these.

Spreadsheet format. With nothing to guess at, or missing from the equation.

You will find that not all test equipment is created equal.

jit 12/4/2012 | 10:59:20 PM
re: Internet Core Router Test I know this isn't a multicast thread, but does anyone know if Juniper really supports dvmrp. I think Cisco refuses to and Juniper says they do, but I wonder if there are any real dvmrp networks out there. I couldn't see that tested here. Maybe there should be a multicast test given the growing use.
skeptic 12/4/2012 | 10:59:19 PM
re: Internet Core Router Test I know this isn't a multicast thread, but does anyone know if Juniper really supports dvmrp. I think Cisco refuses to and Juniper says they do, but I wonder if there are any real dvmrp networks out there. I couldn't see that tested here. Maybe there should be a multicast test given the growing use.

If there was a multicast test, it should be on
PIM sparse-mode rather than DVMRP or anything

I think cisco supports some sort of DVMRP
"interoprability mode". Juniper I think support
more, but I've never used multicast on a
juniper system. But (its an old story) just
because a vendor claims to have something is
no reason to trust that they really have it or
that it works (especially in the case of multicast).
Page 1 / 44   >   >>
Sign In