Light Reading

Stateful NAT64 Performance

Light Reading
Series Column
Light Reading
2/5/2012
50%
50%

EXECUTIVE SUMMARY: Cisco’s CRS-1 loaded with four CGSE cards successfully translated IPv6 traffic to IPv4 at 4 million translations per second. The same system scaled up to 78.4Gbit/s at a total of 67,107,840 translations with almost no loss.


While the industry embraces IPv6 now more than ever, it also recognizes that IPv4 services are not going away soon. The Internet is an obvious example where IPv4 addresses are going to be used for years to come. Cloud applications will use those addresses as well.

While data centers will have different IP migration strategies, they will likely look to serve both IPv4- and IPv6-based customers. Long-term strategies will include native IPv6 throughout the data center, but in the short term a complete IPv6 strategy might not be practical.

For this reason service providers and cloud operators are likely to find themselves needing to deploy Network Address Translation (NAT) from IPv6 users to IPv4 services (NAT64). Let's say an enterprise is building a brand-new large-scale office and wants to use unique IP addressing. The carrier could provide this adventurous customer with IPv6 addresses to use for internal hosts and servers. In order to communicate with the Internet, which at this point is still IPv4 heavy, the carrier could install a NAT64 device somewhere between the customer and their services to translate the IPv6 addressing to IPv4 before sending the datagrams to the Internet. Another example is the rollout of mobile services en masse using IPv6, to customers who still plan to access IPv4 services, including cloud services.

Cisco claimed to be ready for these scenarios -- delivering IPv4 services to IPv6 customers -- at scale. Since we have already reported results on Cisco's stateless NAT 64 capabilities we wanted to use this opportunity to verify Cisco's stateful NAT64 performance claims -- that by placing four Carrier-Grade Services Engine (CSGE) modules into a single CRS-1, we could scale up to 60 million NAT64 translations, at 4 million translations per second, all while transmitting up to 80Gbit/s of data.

Would any carrier need this performance? Probably not anytime soon, but we have learned that those who purchase large-scale core routers want to know that they can use their significant financial investment for a while.

Given the scale, we looked to verify each metric separately. Even with this divide-and-conquer approach, NAT can become complex to test. Cisco explained, and showed, that when their NAT64 implementation chooses an IPv4 address to map to an incoming IPv6 request, it is done at random. Now imagine manually configuring the tester for 60 million mappings, when all 60 million incoming requests are given random IPv4 addresses -- clearly this was not the way to go.

One alternative that we considered was to use stateful traffic using Ixia's IxLoad application, but emulating up to 60 million sessions would have required a significant amount of very high-performance test equipment -- again, not really a workable option. The solution we used involved Ixia's IxNetwork generating stateless traffic, with the appropriate TCP fields set to emulate a stateful session (TCP SYN/TCP ACKs). Since Cisco’s implementation randomly assigned TCP port numbers and IPv4 addresses to incoming IPv6 requests, we schemed to simply exhaust the entire pool of resources on the CRS-1. This way we were able to predict which addresses and ports would be used -- it would be all of them. If your head is spinning, we hope the following diagram will help.

To summarize, we sent client traffic from 1,024 IPv6 addresses -- each of whom opened 65,535 TCP sessions. In fact, this brought us to a total of 67,107,840 translations on the CRS-1. We sent traffic in return toward all 960 IPv4 addresses, each with all 65,535 TCP port numbers, as was configured in the CRS-1 pool. All traffic used IMIX frame sizes -- 122:7, 512:4, 1500:1 (106 in place of 122 on the IPv4 side) at a rate of 38.4Gbit/s toward the clients and 40Gbit/s toward the servers, all across four 10-Gigabit Ethernet links. Once the configuration was pre-staged and verified to be working, we could breathe a sigh of relief.

As we started the official test run we recorded only a small amount of loss -- 0.002 percent on eight of the 16 flows configured from the IPv6 emulated clients toward the IPv4 emulated servers. The other four of such flows ran with no loss, and no flows in the return direction observed any loss either. Considering that we had planned to only test 60 million translations rather than 67,107,840, the loss was considered very minimal. We also verified, using the CRS-1 Command Line Interface (CLI) that all expected translations appeared in the enormous translation table. We also measured latency. The maximum latency values were not very surprising given the translation work to be done by the CRS-1, but in general, given that the latency also included the seven other devices in the test bed, the average latency was quite low.

Next was performance. How quickly could these translations be built in hardware? Now that our test methodology was proven, we felt safe clearing the NAT table on the CRS-1. After doing so, we lowered all frame sizes to 150 bytes so we could increase the frame rate to 4 million frames per second -- 1 million frames per second on each of the four 10-Gigabit Ethernet ports. In order to add realism to the test we configured IxNetwork to randomly assign TCP ports to the IPv6 flows, so that they were not sequential. This however required that we also lower the total number of ports to 13,824, bringing the number of translations to 56,622,848 in total. We ran the test for two minutes without loss.

After some pretty long nights of some complex configuration, we had finally established a test that was able to verify the rate, translation capacity, and throughput of Cisco’s NAT64 solution. Impressive.


Next Page: IPv6 Rapid Deployment (RD) Performance
Previous Page: Intro: Cloud Intelligent Networks


Back to the Cisco Test Main Page

(1)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
TJ Evans
50%
50%
TJ Evans,
User Rank: Light Beer
6/17/2013 | 7:28:06 PM
re: Stateful NAT64 Performance
Are any numbers available for NAT64 performance on slightly more moderate platforms, ASR1k, ASR9k, etc.?
Flash Poll
From The Founder
Last week I dropped in on "Hotlanta," Georgia to moderate Light Reading's inaugural DroneComm conference – a unique colloquium investigating the potential for drone communications to disrupt the world's telecom ecosystem. As you will see, it was a day of exploration and epiphany...
Between the CEOs
Affirmed Networks CEO: Digging Into NFV

5|28|15   |   40:26   |   (2) comments


Hassan Ahmed, CEO of Affirmed Networks, is making some big claims for his NFV startup. I sat down with him at the Light Reading HQ in New York City to get the skinny on what this Acton, Mass.-based startup is up to.
LRTV Documentaries
Cable Eyeing SDN for Headend, Home Uses

5|26|15   |   05:57   |   (1) comment


CableLabs is looking at virtualizing CMTS and CCAP devices in the headend, as well as in-home devices, says CableLabs' Karthik Sundaresan.
LRTV Documentaries
Verizon's Emmons: SDN Key to Cost-Effective Scaling

5|22|15   |   03:53   |   (0) comments


For Verizon and other network operators to ramp up available bandwidth cost effectively, they need to move to SDN and agree on how to do that.
LRTV Documentaries
Lack of Universal SDN a Challenge

5|21|15   |   04:51   |   (3) comments


Heavy Reading Analyst Sterling Perrin talks about how uncertainty about SDN standards and approaches may be slowing deployment.
LRTV Custom TV
Steve Vogelsang Interview: Carrier SDN

5|20|15   |   05:02   |   (0) comments


Sterling Perrin speaks to Steve Vogelsang, Alcatel-Lucent CTO for IP Routing & Transport business, about the new Carrier SDN-enabling Network Services Platform and the operator challenges it solves.
LRTV Custom TV
Carrier SDN: On-Demand Networks for an On-Demand World

5|20|15   |   20:52   |   (0) comments


Steve Vogelsang, Alcatel-Lucent CTO for IP Routing & Transport business, talks about requirements and benefits of Carrier SDN during the keynote address at the Light Reading Carrier SDN event May 2015.
LRTV Documentaries
The Security Challenge of SDN

5|19|15   |   02:52   |   (0) comments


CenturyLink VP James Feger discusses concerns that virtualization could create new vulnerabilities unless network operators build in safeguards.
LRTV Custom TV
NFV Elasticity – Highly Available VNF Scale-Out Architectures for the Mobile Edge

5|18|15   |   5:50   |   (0) comments


Peter Marek and Paul Stevens from Advantech Networks and Communications Group talk about their NFV Elasticity initiative and the company's latest platforms for deploying virtual network functions at the edge of the network. Packetarium XL and the new Versatile Server Module: 'designed to reach parts of the network that other servers cannot reach.'
LRTV Huawei Video Resource Center
Bay Area Spark Meetup 2015

5|14|15   |   3:54   |   (0) comments


Developed in 2009, Apache Spark is a powerful open source processing engine built around speed, ease of use and sophisticated analytics. This spring, Huawei hosted a meetup for Spark developers and data scientists in Santa Clara, California. Light Reading spoke with organizers and attendees about Huawei's code contributions and long-term commitment to Spark.
LRTV Custom TV
The Transport SDN Buzz

5|12|15   |   06:01   |   (1) comment


Sterling Perrin, senior analyst at Heavy Reading, speaks with Peter Ashwood-Smith of Huawei and Guru Parulkar of ON.Lab about the evolution of transport SDN and the integration of technologies.
LRTV Custom TV
Next-Generation CCAP: Cisco cBR-8 Evolved CCAP

5|5|15   |   04:49   |   (0) comments


John Chapman, Cisco's CTO of Cable Access Business Unit and Cisco Fellow, explained the innovation design of Cisco's cBR-8, the industry's first Evolved CCAP, including DOCSIS 3.1 design from ground-up, distributed CCAP with Remote PHY and path to virtualization. Cisco's cBR-8 Evolved CCAP is the platform that will last through the transitions.
LRTV Custom TV
Meeting the Demands of Bandwidth & Service Group Growth

5|1|15   |   5:35   |   (0) comments


Jorge Salinger, Comcast's Vice President of Access Architecture, explains how DOCSIS 3.1 and multi-service CCAP can meet the demands of the bandwidth and service group growth.
Upcoming Live Events
June 8, 2015, Chicago, IL
June 9, 2015, Chicago, IL
June 9-10, 2015, Chicago, IL
June 10, 2015, Chicago, IL
September 29-30, 2015, The Westin Grand Müchen, Munich, Germany
October 6, 2015, The Westin Peachtree Plaza, Atlanta, GA
October 6, 2015, Westin Peachtree Plaza, Atlanta, GA
All Upcoming Live Events
Infographics
Procera has gathered facts, stats and customer experience feedback from a survey of 540 users from across the globe.
Hot Topics
Charter Seals Deals for TWC, Bright House
Mari Silbey, Senior Editor, Cable/Video, 5/26/2015
Eurobites: Alcatel-Lucent Trials 400G in Czech Republic
Paul Rainford, Assistant Editor, Europe, 5/26/2015
Will Carriers Follow Facebook's Networking Lead?
Mitch Wagner, West Coast Bureau Chief, Light Reading, 5/28/2015
Charter Plans Business Services, Wireless Push
Alan Breznick, Cable/Video Practice Leader, 5/27/2015
Facebook Reinvents Data Center Networking
Mitch Wagner, West Coast Bureau Chief, Light Reading, 5/26/2015
Like Us on Facebook
Twitter Feed
BETWEEN THE CEOs - Executive Interviews
On May 29th 1 PM ET, Steve Saunders, founder and CEO of Light Reading, will be drilling into the "pains and gains" of NFV with Saar Gillai, SVP & GM for NFV at Hewlett-Packard Co. (NYSE: HPQ) (HP). He has defined a four-step NFV model describing a sequence of technology innovation. It's a must-read doc for any network architect looking to get to grips with their NFV migration strategy. Join us for the interview, and the chance to ask Saar your NFV questions directly!
Hassan Ahmed, CEO of Affirmed Networks, is making some big claims for his NFV startup. I sat down with him at the Light Reading HQ in New York City to get the skinny on what this Acton, Mass.-based startup is up to.
Cats with Phones