IPv6 Router Test

It's Juniper versus the Japanese! * Test in China * IPv6 gains momentum * Where was Cisco?

February 26, 2003

9 Min Read
IPv6 Router Test

Over the past couple of years, at least three Japanese vendors have launched routers with special hardware aimed at delivering high performance when handling IPv6 traffic. They are:

  • Fujitsu Ltd. (KLS: FUJI.KL) with the Geostream R900 series,

  • Hitachi Ltd. (NYSE: HIT; Paris: PHA) with the GR2000 series, and

  • NEC Corp. (Nasdaq: NIPNY) with the CX5200 series.

Now those routers, together with the M20 from Juniper Networks Inc. (Nasdaq: JNPR), have undergone a series of conformance, interoperability, and performance tests conducted by BII Group, a Beijing-based institute that's led the charge on rolling out a commercial IPv6 network in China.

The tests, which were conducted using equipment from Agilent Technologies Inc. (NYSE: A), demonstrate that all of these routers could be used to build a "basic IPv6 core network," according to a report by Hua Ning, BII's CTO. That report can be downloaded by clicking on this link

By and large, the IPv6 routers in the test conform with key standards, they interoperate with each other, and they deliver good performance in most circumstances.

By demonstrating the availability of high performance equipment, the tests add to the momentum building behind IPv6. The vendors in the test deserve kudos for stepping forward to prove this point. And of course, that raises a question: Why didn't Cisco Systems Inc. (Nasdaq: CSCO) participate in this test? A Cisco spokeswoman told Light Reading today (Feb. 26) that "the request to support the Beijing Internet Institute test came in too late for Cisco China to pull together the equipment and prepare the test bed, so we had to decline."

Although the tests demonstrate some positive aspects about IPv6, they also point to the need for further development work among router vendors. In particular, the maximum number of routing table entries handled by the Japanese equipment is very low. And some of the routers also appear to struggle when handling floods of small packets.

It could be argued that vendors have got plenty of time to address these points. The amount of IPv6 traffic at Internet exchange points, the most likely location for these routers, totals "less than dozens of Mbit/s," according to BII's Ning. In other words, there isn't enough IPv6 traffic to come anywhere close to filling the OC48 (2.5 Gbit/s) interfaces on the routers tested by BII. In fact, a mere PC equipped with Zebra free routing software could handle that amount of traffic, writes Ning in his report.

So, why test IPv6 routers that are so massively over-sized for today's tiddly amount of traffic? The answer is that service providers need to think ahead when they're buying core routers – and IPv6 traffic volumes could explode in the coming years, as wireless access to the Internet takes hold. This is particularly true in the Asia/Pacific region, where the shortage of IPv4 addresses is most acute.

In his report, Ning studiously avoids criticizing vendors or their equipment and says the tests weren't intended as a performance comparison anyhow. All the same, the results invite such comparisons, which are undertaken in the report that follows.

Here's a hyperlinked summary:

  • Conformance and Interoperability

  • Performance

— Peter Heywood, Founding Editor, Light Reading

Want a deeper understanding of the issuesinvolved in integrating IP and optical technology? Check out the firstmodule of Light Reading University's course on the topic.Click on this link to check it out for free!

Before we get started, here's a quick clarification of the status of these tests. They were planned, undertaken, and entirely paid for by BII Group with no involvement from Light Reading. In other words, they appear to be independent, but Light Reading isn't in a position where it can vouch for the results (or the completeness of the results) in the way it can with tests that we pay for.

Here are the details of the routers that were tested:

Table 1: Equipment Tested



Operating System Version


Geostream R920




S-9181-61 07-01






02.0(2e) 45.08.00

Vendors supplied the routers with two OC48 singlemode ports on different boards.

BII says it couldn't get more than two OC48 ports from the vendors and thus had to make do with a very simple test setup, with Agilent's Router Tester sending packets into one port and receiving packets from the other port. It couldn't replicate a real-life scenario in which packets would arrive and leave via multiple ports – something Light Reading was able to achieve in the test of IPv4 core routers it conducted just over two years ago (see Internet Core Router Test).

BII lists the following requirements for IPv6-capable core routers:

  • IPv6 hardware forwarding, to ensure high performance

  • Dual IPv6 and IPv4 software stacks, as these routers are bound to handle both types of traffic simultaneously

  • RIPng, as defined in RFC2080 – an extension of Version 2 of the Routing Information Protocol (RIPv2) to carry IPv6 addresses and prefixes

  • OSPFv3, a version of the Open Shortest Path First (OSPF) interior gateway protocol that supports IPv6. "For real world applications, many operators regard OSPFv3 as a brand new protocol," writes Ning in his report. "Its stability and maturity need to be further verified." He adds that right now, service providers often make do with IS-ISv6 (RFC1195) instead.

  • BGP4+, which incorporates extensions of the existing Border Gateway Protocol 4 (RFC1771) to handle IPv6 network information. These are covered in a number of RFCs.

BII tested conformance of each vendor's BG4+ implementation to no fewer than 77 aspects of those RFCs. Details are in an appendix to Hua Ning's report, and the results are summarized below.

Table 2: BG4+ Conformance Test Summary


Failed test items

Capabilities not supported

Fujitsu GeoStream R920



Hitachi GR2000-20H


Juniper M20


NEC CX5210


Route reflector, Community

In a nutshell, only Hitachi's and Juniper's routers support a full set of BG4+ protocols, and Hitachi has a few improvements to make in its current software.

BII went on to conduct BG4+ interoperability trials, by linking together all four routers in a mesh configuration and then checking to see whether Interior BGP and Exterior BGP sessions could be established across them. Routing tables were also checked to make sure EBGP route advertisement worked. It did, as did everything else in this test, which only encompassed common BG4+ properties.

OSPFv3 interoperability was also checked, although in this case, only three vendors were included because the test equipment required routers to have a Fast Ethernet interface, and right now, NEC's CX5210 doesn't have one. Everything worked as expected.

As already noted, BII had to use a fairly basic method of measuring performance, because the routers only came with two OC48 interfaces. This meant that all it could do was pump packets into one port and analyse what came out of the other port. It wasn't possible to replicate a more likely scenario, with packets being pumped into one port and then being distributed among a number of output ports.

In his report, Ning also expresses regret that BII didn't have time to test flapping and convergence performance, an issue that's of particular concern in IPv6 environments where packets are likely to traverse trial networks in which routers are reset frequently, causing instability.

All the same, BII's tests came up with plenty of interesting results. Here's one of them:

Table 3: Routing Table Capacity

Maximum Learned Routes

Hitachi GR2000-20H


NEC CX5210


Fujitsu GeoStream R920


Juniper M20


Ning discusses these results in some depth in his report. He points out that right now, IPv6 routing tables only have 300 to 400 entries in them, but this is not to say that NEC's 4,000 capacity is more than ample. In fact, Ning and his team argue that IPv6 routers need to be able to handle just as many routing table entries as IPv4 routers. At present, that's between 110,000 and 130,000, according to Ning.By that reckoning, Juniper is alone in having sufficient routing table capacity. In Juniper's case, BII didn't see much point in seeing whether the M20 could handle more than 1 million entries. At that stage, it was clear that it could have handled even more.

Throughput and Latency When Handling Pure IPv6 Traffic

BII established the maximum forwarding rate with zero packet loss for different IPv6 packet sizes. Here's the results:

NEC and Juniper deliver outstanding performance, while Hitachi and Fujitsu have some problems handling floods of smaller, 64-byte packets.

Fujitsu comes off worst in the latency tests (see below). It's interesting to note that Fujitsu employs network processors rather than ASICs in its router (see Fujitsu Fuels Net Processor Hopes). Could there be a connection?

Performance When Handling a Mixture of IPv4 and IPv6 Packets

All of the routers achieved maximum throughput for larger packet sizes, but Hitachi and Fujitsu struggled with 64-byte packets again:

Juniper does best on the latency front, registering between 10 and 10 microseconds for all packet sizes and all mixes of IPv4 and IPv6 traffic. Next best is Hitachi.

At the other end of the scale, Fujitsu's latency is a lot worse than other vendors. It sticks at around the 60µs mark for smaller packet sizes, and rises to around 70 µs for 1,518-byte packets.

NEC's latency gets decidedly worse when handling flows of 64-byte packets, when the proportion of IPv4 traffic rises above 30 percent (see below).

Performance When Tunneling IPv6 over IPv4 Networks

This is how IPv6 islands are likely to be connected for the foreseeable future. Routers pop an IPv6 packet into the payload section of an IPv4 one and Bob's your uncle!quid pro quo for its not so hot latency performance?

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like