Cisco Press
Rate your favorite Cisco Press books.
Years of innovation and work to continuously improve various transport technologies and network elements led operators to have high expectations of their networks. Although richness of supported features can differentiate networking equipment, high performance is expected by default. Nothing short of line-rate forwarding of raw traffic is expected for most high-speed interfaces of high-end routers and switches.
During the initial phases of its development, IPv6 was viewed as a mere feature, something new to play with and evaluate. Its implementation in software enabled router vendors to stay on the fast track of integrating the recommendations churned out by the standar-dization bodies. The IPv6 early adopters, universities and developers were offered the tools to play and experiment with the protocol. Cisco engaged on this path with a phased program that led to Cisco IOS software officially supporting IPv6 features as early as 2001 in release 12.2(2)T.
After the protocol consolidated and matured, the focus moved toward deployment considerations, and that naturally implied focus on IPv6 performance. Fast adoption of features remains important in the case of a still-evolving protocol. However, performance requirements force vendors to look at the entire architecture of their products and work on integrating IPv6 in every aspect of it. To meet competitive performance requirements, depending on router architecture, both software and hardware have to take into account the new protocol.
The whole topic of performance has an additional twist in the case of IPv6. Today, there are a few cases where brand new networks are built specifically for IPv6-based services. For all the other networks, which include the vast majority, the operators ask a natural question: “What is the impact on my network of turning on IPv6?” The IPv4 infrastructure remains the source of revenue and supports the most important services. Bringing IPv6 into the network must not impact it negatively. The performance implications of IPv4 and IPv6 coexistence can push the discussion from the network element level to a system level, a higher level of complexity.
This chapter discusses the various aspects of router performance and the challenges posed by IPv6. It provides information and guidelines on evaluating a router’s performance so that you can choose the right router for the job.
Aspects of Router IPv6 Performance
It is commonly understood that routers and layer 3 switches are performing functions at different levels of the OSI model. With the increased complexity of supported features, these devices started to operate at levels beyond the original first three. It is therefore expected that routers operate in one form or another on parameters that could relate to most of the seven layers of the OSI model.
However, the main focus of a router’s operation remains the network layer. Its functions can be separated into three categories:
Control plane—Handles the router’s interaction with the other network elements, providing the information needed to take decisions and control the overall router operation. This plane runs processes such as routing protocols and network management. These functions are generally complex.
Data plane—Handles packet forwarding from one physical or logical interface to another. It involves different switching mechanisms such as process switching and Cisco Express Forwarding (CEF) on Cisco IOS software routers.
Enhanced services—Cover router’s leverage of advanced features that are applied when forwarding data (for example, packet filtering, quality of service [QoS], encryption, translation, accounting).
Figure 11-1 provides a conceptual representation of these functions. The specifics of their implementation and operation depend on the router architecture.
Conceptual Representation of a Router: Data and Forwarding Planes
Each of these router functions has its own performance characteristics. It is therefore important to qualify a router’s performance in the context of its control-plane, data-plane, or enhanced-services operation. IPv6 presents each of these functions with specific new challenges.
IPv6 Control Plane
When IPv6 is enabled on a router, its control plane starts to operate processes specifically for it. Protocol characteristics shape the performance of these processes and the amount of resources necessary to operate them:
Size of IPv6 addresses—Address size impacts the information-processing functions of a router. Systems using a 64-bit CPU, bus, or memory structure can pass both the IPv4 source and destination address in a single processing cycle. For IPv6, the source and destination addresses require two cycles each, or a total of four cycles to process the (source address, destination address) information. For this reason, routers that rely exclusively on software processing could see lower performance compared to IPv4.
Nodes use multiple IPv6 addresses—Each IPv6 node can use several IPv6 unicast addresses such as link-local and global unicast with different interface ID values. The increased number of addresses used impacts the memory consumption of the Neighbor Discovery cache.
IPv6 routing protocols—The IPv6 routing protocols are similar to their IPv4 counterparts. However, an IPv6 prefix is four times larger than an IPv4 one, which means that routing updates have to carry more information in the case of IPv6. This remains true despite various optimizations made to address this difference.
Size is one of the natural concerns about the IPv6 networks and the IPv6 Internet. Larger networks are expected with the larger IPv6 address space. In principle, this implies larger routing tables and higher memory requirements to support them. At first, as deployments are incipient, this is not an issue. As the number and size of IPv6 networks increases, aggregation and strict prefix allocation through the provider-enforced hierarchy represent the means to control and reduce the size of the Internet routing table.
Currently, there are two main address types in the IPv6 Border Gateway Protocol (BGP) routing tables:
6Bone routing tables—3FFE::/16 prefix space allocated for development and experimentation
IPv6 production tables—2xyz::/16 prefix space allocated by the Regional Registries for production aggregation
The 6Bone network will be retired by June 2006. Allocation rate in the 2xyz::/16 range is growing steadily. More than 1000 prefixes are now (February 2005) allocated and present in the IPv6 Internet table. To monitor the growth and prefix distribution of the IPv6 Internet, several websites provide tools and statistics on IPv6 routing tables:
For a historical perspective, Figure 11-2 shows the prefix-allocation growth seen in the BGP routing tables since 1998 (source TILAB).
Growth of IPv6 Internet Tracked by the Size of the BGP Routing Table
At the time of this writing, the number of IPv6 prefixes in the BGP routing tables is 2573. According to the TILAB statistics, the main contributions to the total number of prefixes present in the routing tables were, at the date of the snapshot (January 2005), in this order:
IANA assigned prefixes. These are the IPv6 prefixes officially assigned by IANA and the Internet registries to the requesting organizations for production use of IPv6, the sTLA prefixes.
Unaggregated prefixes. These are the IPv6 prefixes belonging to the 6Bone addressing space that are longer than the correspondent pTLA delegation.
6Bone pTLA prefixes assigned to the backbone sites.
Invalid prefixes. These are IPv6 prefixes that do not belong to the address space assigned by IANA.
The growth rate depicted in Figure 11-2 is expected to accelerate in the coming years. Similar to IPv4, tracking the size of the BGP IPv6 routing tables remains very important for service providers (SPs) to better plan network resources such as router memory.
Independent of the routing table size, users want to know whether IPv6 routing protocols perform well in terms of convergence. Because of their similarity to the IPv4 counterparts, the convergence performance of the IPv6 routing protocols is generally similar to the IPv4 ones.
In general, it should be expected that IPv6 and IPv4 will be competing for the control-plane resources. For this reason, bringing IPv6 into an operational network has to be done in a controlled way and with full information about its potential impact. If justified by the available router resources or the network conditions, limitations can be placed on IPv6 processes or the router’s interaction with other network elements. The intent is to protect and reserve the CPU or memory resources for the existent revenue-generating IPv4 services.
IPv6 and the Data Plane
The data plane is responsible for forwarding the IP packets based on the decisions made by the control plane. The forwarding engine has to parse the relevant IP packet information. It then has to do a lookup to match the parsed information against the forwarding policies defined by the control plane. The performance of both “parsing” and “lookup” functions is impacted by IPv6 protocol specificities:
Parsing IPv6 extension headers—Applications such as mobile IPv6 or source routing often include IPv6 address information in the extension headers, which significantly increases their size. These additional fields need to be accounted for in the hardware registers to properly read the extension headers and, deeper into the packet load, the layer 4 headers. An example is the case where the router has access control lists (ACLs) that filter on layer 4 information. The router has to be able to apply them to packets with extension headers, too. If the length of the extension headers exceeds the fixed length of the hardware registers, hardware switching does not occur. In this case, the packet is punted to software switching, and that has a severe impact on the forwarding performance.
Note – Not all routers on the market choose to punt into the software path the packets that they cannot handle in hardware. In those cases, the packets are simply dropped.
IPv6 address lookup—The IPv6 lookup occurs when a valid packet enters the router and needs to find an output interface. When the forwarding decision is made based on the destination address, this process entails parsing a maximum of 128 bits rather than 32 bits for IPv4. To improve the lookup performance, the lookup algorithm has been modified. A 128-bit lookup is rare because it applies only to host routes, including anycast addresses, which should have a limited presence. An anarchic allocation of anycast addresses can be problematic because a lot of host routes would be injected in the IPv6 routing table. In a typical autonomous system, however, following the address allocation recommendations documented in RFC 3177, it is expected that for a service provider, the majority of lookups are centered on a few fixed values: /32 in the core of the network, /48 in the distribution layer, and /64 at the edge.
Depending on the router type, lookups are performed by a multipurpose CPU or by an application-specific integrated circuit (ASIC) with a fixed configuration or with a microcode. This impacts the performance and the versatility of the router functions. Software processing of the IPv6 lookup takes more time than for IPv4 because more bits must be processed. The multipurpose CPU is slower but can perform functions based on a limitless program. The ASIC with microcode allows for a certain degree of flexibility in the performed features, although the fixed ASIC performs only the functions for which it was initially designed. Because the IPv6 lookup is more demanding (theoretically four times more demanding), there is a natural tendency to leverage hardware-based lookup engines as much as possible. Hardware-based lookup designs generally lead to IPv6 line-rate forwarding at all interface speeds for most packet sizes.
Not all hardware forwarding platforms in the market achieve line-rate forwarding of IPv6. It is therefore important to evaluate a router’s capability, regardless of its architecture.
The hardware forwarding option can come to the detriment of feature richness. If new features need to be added, the ASICs need to be redesigned, which is a much longer and more costly process than that of implementing it in software.
The performance of the various processes and functions discussed in this section depends on the architecture of each router. An overview of these architectures is presented later in this chapter along with performance-data examples.
Measuring Forwarding Performance
Following the discussion about the various aspects of router performance, it is important to understand how to measure and test it. This is a significant part of evaluating a platform for a particular role within a deployed network. Consistent and universally accepted test methodologies should be observed for objective evaluations.
Most often, router performance is associated with its forwarding capabilities. Resource requirements can typically be addressed by increasing the router memory or selecting more powerful processors; however, the forwarding performance is generally limited by the platform design. For this reason, the focus of this section is on the best practices for measuring the IPv6 throughput of a router.
Regardless of the IP protocol type, forwarding performance testing is best performed in a black-box environment. The stimulus and the measurements are independent of the device tested and its architecture. RFC 2544 provides general guidelines and requirements for throughput testing:
Throughput, as defined in RFC 1242, is measured as nondrop rate (NDR), the maximum traffic rate with no packet drop.
The NDR should be determined in steps of 60 or fewer seconds and then verified by forwarding traffic for a minimum of a 60-second time interval at the determined NDR.
Frame sizes tested should cover the set recommended for the various media types. In the case of Ethernet, for example, 64, 128, 256, 512, 1024, 1280, and 1518 bytes.
Traffic should be bidirectional, unless otherwise specified.
These recommendations are made to evaluate the performance of forwarding unicast traffic. However, it is also important to evaluate the forwarding performance of multicast traffic, too. This type of traffic will most likely be present in the IPv6 deployments. With multicast, the test options are multiple because there are various ways in which the router can replicate traffic. For this reason, it is best for the evaluation to be performed based on traffic patterns and requirements specific to the network role for which the router is evaluated.
The larger IPv6 addresses require more intense lookups, and that can impact the router performance, as mentioned in the previous section. For this reason, it is more important to evaluate a router’s forwarding performance for prefixes of various lengths in the /16 and /64 range in IPv6 than in IPv4.
All major test tool vendors provide RFC 2544–based test suites that can be used to measure the NDR of devices under test (DUT). These suites can be executed with both IPv4 and IPv6 traffic. They are well suited to black-box testing, and they offer a certain level of consistency for this type of measurement.
The test tool suites offer multiple tuning parameters, so it is important to be aware of their settings and ensure they meet the requirements of RFC 2544.
The test tools that form the shell around the DUT should be complemented with a few probes that acquire data from the DUT itself. Relevant data that should be collected during test includes memory utilization and integrity, CPU values at box or linecard level, and general system messages. Although throughput data in itself is important as far as a standalone router is concerned, sometimes NDR is obtained at 100 percent use of the CPU. From a network operation perspective, this is unacceptable because the router might have to totally neglect its control-plane to meet the measured NDR.
Considering all the parameters that are being measured during the evaluation, it is always a good practice to define a baseline for the test environment that is being used.
The advantage of the black-box testing approach is that it allows for a consistent evaluation of forwarding performance of raw traffic as well as complex traffic that includes higher-layer content or extension headers. It also provides a good way to evaluate the impact on performance of advanced features (access lists, for example) enabled on the DUT. A black-box approach to testing allows for a clear one-to-one comparison of the results obtained in each of these cases. It also allows for meaningful comparisons between IPv4 and IPv6 throughput performance data.
Note that the minimum packet size for IPv6 is larger than IPv4 (IPv6 header: 40 bytes; IPv4 header: 20 bytes). This is important when considering the low-packet-size performance data.
It is important to mention that there are also two different ways to look at the throughput performance of a router:
Interface-to-interface throughput refers to measuring the NDR by sending bidirectional traffic through two same-type interfaces of the DUT.
System throughput refers to measuring the NDR by sending bidirectional traffic through all interfaces of a router that is fully populated in terms of linecards and interfaces.
Both tests are conceptually similar, and they should observe the RFC 2544 recommendations.
It is generally expected that a router’s IPv6 forwarding performance is similar to its IPv4 forwarding performance and as close as possible to the line rate of the tested interface.
The Right Router for the Job
When choosing a router for a certain role in a network, performance is not the only factor considered. Others are equally important, such as the following:
Feature richness and versatility
Price
Scalability
All these factors reflect certain aspects of a router’s design. Previous sections highlighted some of the IPv6-specific challenges faced by a router’s control and forwarding planes. Ultimately, a router’s performance is determined by its implementation of the control and forwarding functions as well as its integration of the IPv6 protocol. For this reason, it is important to have an idea of the overall design of the evaluated router when analyzing its performance data.
Router Architecture Overview
Routers evolved from mere specialized computers where all processing is software based to sophisticated devices where functionality is shared between software running on powerful CPUs and highly specialized hardware. Routers are becoming more powerful, more reliable, and more scalable; but all this comes at a cost. It is therefore important to build the right router for the right market segment. This explains the multitude of router types available from which to choose.
Software Versus Hardware Forwarding
The control-plane functions of a router are always performed in software. On the other hand, packet forwarding along with some advanced features can be performed by dedicated hardware resources. Based on the implementation of the forwarding plane, routers can be classified as follows:
Software forwarding router—A device using its main CPU for basic and enhanced packet forwarding; no hardware assistance is available.
Hardware Forwarding Router—A device that has hardware assistance for basic or enhanced packet forwarding.
Note – A packet that cannot be handled by the hardware is usually punted to software processing by default. This is not true for all router vendors.
Hardware-assisted forwarding often provides the best forwarding performance. This advan-tage comes at the expense of versatility. The dedicated hardware is designed to support a certain set of features, so additional features require its redesign. For this reason, hardware-forwarding-based platforms are generally well positioned in or close to the network core and edge. There the interfaces are high speed, and the focus is on forwarding performance rather than feature richness. Software-forwarding-based platforms are more suited in the access layer, where the interfaces are lower speed, and various features are being used.
Both types of routers are present in the Cisco product line:
Software forwarding routers—Cisco 800, 1700, 1800, 2600, 2800, 3600, 3700, 3800, 7200, and 7500 series
Hardware forwarding routers—Cisco 7600, 10000, 10720, 12000 series and the Cisco Carrier Routing System (CRS-1); layer 3 switches: Catalyst 6500, 3560 and 3750 series
Centralized Versus Distributed Forwarding
A router can take all its forwarding decisions in a centralized manner or it can distribute the function among multiple intelligent subsystems. This design choice separates routers in two categories:
Centralized forwarding router—Every packet-forwarding decision is made by a central forwarding engine.
Distributed forwarding router—Forwarding decisions are made on different forwarding engines that can control a linecard, a port, a section of a chassis, and so on.
All forwarding engines involved in the decision-making process have to support IPv6. If they do not, the router defaults to a centralized mode of operation.
The distributed architectures are particularly important for larger, modular routers that have to scale well with additional linecards. When the forwarding decision making is distributed to these intelligent cards, the router performance is not impacted by an increase in the number of interfaces and modules. This type of router is prevalent at the core and the edge of the network.
Examples of distributed, IPv6-capable routers from the Cisco family include the following:
Cisco 7500 series router
Cisco 7600 series router with distributed CEF 720 linecards
Cisco 12000 series Internet router
CRS-1 router
Note – A distributed architecture also allows software forwarding platforms to have a performance close to line rate and that scales linearly as cards are added. This is the case of the 7500 Cisco routers.
The concepts presented in this section represent a high-level overview of router architecture. These concepts can help you classify routers and have certain performance expectations from them based on their design. However, today’s routers are complex systems, and there is a lot more to a complete and thorough discussion of their architecture than what is covered in this brief discussion. For more detail on this topic, refer to the book Inside Cisco IOS Software Architecture (CCIE Professional Development) by Vijay Bollapragada, et al.
IPv6 Forwarding Performance of Cisco Routers
Armed with an understanding of the various router architectures and the methodology to test their performance, it is time to see the differences between their IPv4 and IPv6 performance. This section presents forwarding performance examples for the two protocol types on Cisco routers that target various segments of a network.
Low-End Routers
The low-end routers are typically deployed in the access layer of the network. They generally have low speed and few interfaces. Because they are software-based routers, they are easily enabled to support IPv6. The Cisco product line from the 830 series to the Cisco 3800 series can be easily enabled for IPv6 when it is upgraded to one of the supported Cisco IOS software release, such as 12.2T, 12.3, 12.4, 12.3T, and 12.4T. Low-end routers have a centralized architecture.
Note – CEF is available for IPv6 (Cisco Expressing Forwarding v6 and distributed Cisco Expressing Forwarding v6) starting with Cisco IOS Release 12.2(13)T.
Despite being software platforms, many of the low-end routers use powerful CPUs that enable them to achieve line-rate packet forwarding on their interfaces. To provide encryp-tion services, which are particularly CPU intensive, hardware assistance might be needed to sustain the same performances as the other services.
Table 11-1 presents an example of how IPv6 compares to IPv4 performance on a low-end router from the Cisco 3700 series. The throughput was determined between two Fast Ethernet interfaces, with bidirectional traffic and no advanced features enabled. The theoretical maximum throughput for the interface type analyzed is also listed for reference. Figure 11-3 is a graphical representation of the forwarding performance in percentage of the targeted line rate.
Table 11-1 IPv6 Basic Forwarding Between Two Fast Ethernet Interfaces, Bidirectional, No ACL on Cisco 3725
Packet Size (Ethernet II) | IPv4 (pps*) | IPv6 (pps) | Maximum (pps) |
|---|---|---|---|
64 bytes | 63,918.5 | 48,064 | 148,810 |
128 bytes | 63,431 | 49,867 | 84,449 |
256 bytes | 45,290 | 45,290 | 45,290 |
512 bytes | 23,492 | 23,492 | 23,497 |
1024 bytes | 11,973 | 11,973 | 11,973 |
1518 bytes | 8127 | 8127 | 8128 |
IMIX | 33,515 | 33,515 | 33,515 |
*Packets per second | |||
Note – IMIX is a 7:4:1 distribution of Ethernet-encapsulated packets of sizes 64, 570, and 1518 bytes. This leads to a 353-byte packet-size average.
Sometimes the performance numbers are multiplied by a factor of two when bidirectional traffic is used during testing. For this reason, it is important to fully qualify the test methodology used.
Example of IPv4 Versus IPv6 Forwarding Performance of a Low-End Router (Cisco 3725 – FastE)
It is worth noting that line-rate forwarding is obtained before the IMIX packet size, which represents a likely packet-size distribution in an operational network.
Mid-Range Routers
In the case of mid-range routers, finding the balance between cost, features, and perfor-mance becomes even more important. Routers in this market segment can be positioned in different roles and have to perform multiple functions from access to distribution/aggregation and even core at times. The versatility required of the mid-range platforms is reflected in the multitude of router architectures applied to them. Software and hardware forwarding, as well as centralized and distributed architectures, are all present.
Leveraging powerful CPUs allows routers with low density of ports to deliver competitive forwarding performance while maintaining the edge in terms of feature richness. Table 11-2 shows the performance data of a Cisco-software-based, centralized forwarding mid-range platform. The performance is measured with bidirectional traffic between two Gigabit Ethernet interfaces on a 7304 router with an NPE-G100 processor. Figure 11-4 is a graphical representation of the information in Table 11-2. It shows IPv4 versus IPv6 throughput performance in percentage of targeted line rate.
Table 11-2 Cisco 7304 NPE-G100 Performance Between 2 Gigabit Ethernet Interfaces, Bidirectional, No ACL
Packet Size (Ethernet II) | GE–IPv4 (pps) | GE–IPv6 (pps) | Maximum (pps) |
|---|---|---|---|
64 bytes | 569,103 | 330,213 | 1,488,095 |
128 bytes | 579,586 | 330,213 | 844,595 |
256 bytes | 452,898 | 332,877 | 452,898 |
512 bytes | 234,962 | 234,962 | 234,962 |
1024 bytes | 119,731 | 119,731 | 119,731 |
1518 bytes | 81,274 | 81,274 | 81,274 |
IMIX | 334,224 | 334,224 | 334,224 |
Example of IPv4 Versus IPv6 Forwarding Performance of a Mid-Range Router (Cisco 7304 – GigE)
The IPv6 forwarding performance is at line rate below IMIX average packet sizes. On the other hand, mid-range routers from this family can maintain high forwarding performance even with advanced features enabled such as access control lists (ACLs). This is not always the case with mid-range hardware platforms available on the market. Table 11-3 shows the impact of ACLs on the performance of a Cisco 7200 router with an NPE-G1 processor. Unidirectional traffic was used and 100 ACLs were enabled on the ingress interface. The data is graphically represented in Figure 11-5.
Table 11-3 Cisco 7200 NPE-G1 Performance Between 2 Gigabit Ethernet Interfaces, Unidirectional, With and Without ACLs
Packet Size (Ethernet II) | IPv6 Without ACLs (pps) | IPv6 With ACLs (pps) | Maximum (pps) |
|---|---|---|---|
64 bytes | 561,209 | 287,377 | 1,225,490 |
128 bytes | 558,280 | 288,403 | 753,012 |
256 bytes | 425,170 | 288,988 | 425,170 |
512 bytes | 227,272 | 227,272 | 227,273 |
1024 bytes | 117,702 | 117,702 | 117,702 |
1280 bytes | 94,840 | 94,840 | 94,841 |
1518 bytes | 81,274 | 81,274 | 81,274 |
IPv6 Forwarding Performance With and Without ACLs (Cisco 7206)
Note – If a router is evaluated in a role that involves the extensive use of advanced features such as ACLs, it is important to evaluate the impact of these features on its forwarding performance.
Note – The router performance when running advanced features is of particular importance in the case of IPv6. Transition mechanisms such as IPv6 over IPv4 tunneling are falling in this category, so it is important to evaluate a router’s performance in this context. Software platforms are well positioned in this case because packet switching is done in software for both native and tunneled IPv6 traffic. Hardware assist for IPv6 over IPv4 tunneling is not generally available.
When a mid-range platform is targeted for an aggregation role, a centralized, software forwarding design might be challenged by the high number of interfaces involved. In a distributed architecture, however, the forwarding performance is scaling linearly when interfaces are added to the system. An example of such a platform is the Cisco 7500 that leverages the distributed Cisco Express Forwarding (dCEF) feature. An example of forwarding performance numbers measured for the OC-3 interface of this router is shown in Table 11-4. Figure 11-6 also shows this data.
Table 11-4 Cisco 7500 RSP4 or RSP8 + VIP4-80 POSIP OC-3, Bidirectional, No ACL
Packet Size (Ethernet II) | OC-3 – IPv4 dCEF (pps) | OC-3 – IPv6 dCEF (pps) | Maximum (pps) |
|---|---|---|---|
64 bytes | 198,504 | 166,000 | 353,208 |
128 bytes | 153,500 | 153,490 | 160,000 |
256 bytes | 76,408 | 76,408 | 76,408 |
512 bytes | 37,365 | 37,365 | 37,365 |
1024 bytes | 18,480 | 18,480 | 18,480 |
1518 bytes | 12,422 | 12,422 | 12,422 |
Example of IPv4 Versus IPv6 Forwarding Performance of a Mid-Range Router (Cisco 7500 – OC3).
Higher performance needs generally make hardware forwarding assistance necessary in high-end routers.
High-End Routers
Moving closer to the core of the network, routers need to support multiple very high-speed interfaces such as Gigabit Ethernet, 10 Gigabit Ethernet, OC-48, OC-192, and OC-768. To maintain line-rate forwarding, routers cannot rely on CPUs anymore; hardware assistance becomes necessary. To exemplify this need on high-end routers, Table 11-5 depicts the differences in performance on a Cisco Catalyst 6500 series switch and Cisco 7600 Series Router for various switching paths.
Table 11-5 Performance of Various Switching Paths on Catalyst 6500 / Cisco 7600
Switching Path | Performance |
|---|---|
Process switched mode | 10–30 Kpps |
Software CEF switch mode | 230 Kpps |
Centralized PFC3 on a Supervisor Engine 720 for native IPv6 – Cisco IOS 12.2(17a)SX1 | +20 Mpps |
Supervisor Engine 720 with distributed PFC3 on linecards | +200 Mpps |
This data clearly shows the performance enhancements that come through hardware assist. Actual performance numbers for another high-end Cisco router that performs IPv6 forwarding in hardware are shown in Table 11-6.
Table 11-6 Cisco 12000 Engine 3 POSIP OC-48 HDLC Encapsulation CRC32, Bidirectional, No ACL
Packet Size (Layer 2) | OC-48 – IPv4 (Mpps) | OC-48 – IPv6 (Mpps) | Maximum (Mpps) |
|---|---|---|---|
64 bytes | 3.846 | 3.846 | 4.103 |
128 bytes | 2.321 | 2.321 | 2.321 |
256 bytes | 1.156 | 1.156 | 1.156 |
512 bytes | 0.579 | 0.579 | 0.579 |
1024 bytes | 0.289 | 0.289 | 0.289 |
1500 bytes | 0.198 | 0.198 | 0.198 |
Note – Consult Cisco documentation to identify the routers and router linecards that support hardware forwarding of IPv6.
Figure 11-7 shows the forwarding performance improvement at low packet sizes because of its implementation in hardware. The other advantage of hardware forwarding is that IPv4 and IPv6 traffic will not compete for processor resources. Turning IPv6 on is not going to impact the forwarding of existent IPv4 traffic.
Example of IPv4 Versus IPv6 Forwarding Performance of a High-End Router (Cisco 12000 – OC48)
Cisco CRS-1 is its flagship of core routers, and it represents the most compelling example of high performance achieved through advanced hardware forwarding design. Independent studies by the European Advanced Networking Test Center show that it can forward IPv4 and IPv6 traffic at line rate through OC-768 (40 Gbps) interfaces with and without advanced features enabled. The system throughput for the single chassis configuration is 640 Gbps, although the multichassis configuration is 1.28 terabits per second. It also achieves line rate at these speeds for traffic mixes (85 percent IPv4, and 15 percent IPv6).
6PE Forwarding Performance
6PE and 6VPE are key migration options in the deployment of IPv6. See the section “IPv6 over 6PE” in Chapter 3, “Delivering IPv6 Unicast Services,” and Chapter 7, “VPN IPv6 Architecture and Services,” for details about these technologies. IPv6 forwarding performance through a 6PE environment is an important factor when weighing a certain deployment strategy. A Multiprotocol Label Switching (MPLS)-enabled core has high forwarding performance, close to line rate, of labeled traffic irrespective of the IP version of the packets. It is thus up to the PE routers to avoid reducing the end-to-end forwarding performance of IPv6 in a 6PE deployment.
In the case of 6PE and 6VPE, there is a level of asymmetry in terms of forwarding performance. Routers will exhibit a certain performance when traffic flows from the IPv6 side toward the MPLS core (router performs label imposition) and when it flows in the opposite direction (router performs label disposition). For this reason, a simple bidirectional traffic test is not fully revealing because the forwarding performance result is shaped by the lowest of the performances in each individual direction. In this case, the right testing approach is to use unidirectional streams and analyze each direction separately.
Note – The same approach should be applied when evaluating the forwarding performance over IPv6 tunnels.
Table 11-7 lists the 6PE forwarding performance data for the OC-48 ISE card of the Cisco 12000. Forwarding is hardware assisted for this platform. The performance in the “label imposition” direction shapes the overall performance on the path. In the Cisco implementation of 6PE, a different label is usually associated with each prefix, so no IPv6 lookup is performed on the egress 6PE. For this reason, the expected performance in the “label disposition” direction is the usual MPLS performance (line rate on this card). This forwarding data is represented graphically in Figure 11-8.
Table 11-7 Unidirectional 6PE Traffic on Cisco 12000 with OC-48 Engine 3 Linecard
Packet size (IP) | Imposition – OC-48 (Mpps) | Disposition – OC-48 (Mpps) |
|---|---|---|
64 bytes | 3.8 | 3.84 |
128 bytes | 1.91 | 1.95 |
256 bytes | 1.11 | 1.11 |
512 bytes | 0.570 | 0.570 |
1024 bytes | 0.289 | 0.289 |
1500 bytes | 0.198 | 0.198 |
6PE Forwarding Performance in the Label Imposition and Label Disposition Directions (Cisco 12000 – OC48)
The forwarding performance for 6PE is close to line rate for most (and the relevant) packet sizes. Similar high performance is also available with software-switched platforms, and that certainly qualifies the 6PE solution for large-scale, high-performance deployments.
IPv6 Router Performance Evaluation Checklist
For the time being, the IPv6 networks are small compared with IPv4, and the IPv6 traffic most likely represents a fraction of the existent IPv4 traffic. For these reasons, operators would tend to look at IPv6 performance in terms of its impact on the revenue-generating IPv4 services. As focus moves toward large-scale deployments, router IPv6 performance becomes an important factor in network planning and design.
This chapter underlines the relevant aspects of router performance while showing the importance of keeping in balance all the other factors relevant in router selection, such as feature richness and cost. It also discusses the impact of IPv6 protocol specificities on router performance. The chapter provides guidelines on practical and objective evaluation methodologies of router IPv6 performance. From a practical perspective, this information can be summarized in a checklist of major items to be verified when evaluating a router’s IPv6 performance. Table 11-8 shows this list.
Table 11-8 IPv6 Router Performance Evaluation Checklist
Test Scope | Test Targets |
|---|---|
Control plane | Evaluate the CPU impact of targeted IPv6 features. For routers that will operate in dual-stack mode, add the result to the operational CPU values (generated by IPv4) to see whether it will lead to comfortable overall CPUs (typically below 60 percent under regular traffic loads). |
Evaluate the memory needs for the IPv6 routing tables. For routers that will operate in dual-stack mode, add to IPv4 memory use to see whether it leads to comfortable overall memory use. | |
Data plane | Measure unicast interface-to-interface and system-level throughput performance for basic IPv6 traffic and no advanced router features enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. |
Measure unicast interface-to-interface and system-level throughput performance for IPv6 traffic with various extension headers and no advanced router features enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. | |
Measure unicast interface-to-interface and system-level throughput performance for basic IPv6 traffic with advanced router features (the features targeted for the deployment such as ACLs, QoS, and so on) enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. | |
Evaluate the CPU impact of forwarding the expected IPv6 traffic rates. Both central and linecard (where applicable based on the router design) CPU should be measured. | |
Measure IPv6 multicast performance in terms of both forwarding rates and replication. |
This chapter is also making the point that today’s routers and layer 3 switches are ready to support large-scale, high-performance IPv6 networks. They deliver line-rate forwarding of IPv6 traffic in the range of packet sizes relevant for most applications. The data presented supports this statement in the case of platforms of various designs that address the entire market spectrum. IPv6 router performance meets the high standards set by IPv4.
Copyright © 2007 Pearson Education. All rights reserved.
