IPv6

(credit Wikimedia Commons)

On February 3, 2011, ICANN/IANA announced, Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied. The problem of IPv4 address exhaustion makes support for IPv6 a necessity, however there are significant challenges in supporting IPv6.

The article, There is no Plan B: why the IPv4-to-IPv6 transition will be ugly, provides a good introduction to some of the challenges. Critically, IPv6 is not backward compatible with IPv4, requiring a complex mixture of dual stack, NAT and tunneling strategies to maintain connectivity between IPv6 and IPv4 hosts:

• Dual-stack
• Dual-stack Lite (DS-Lite)
• NAT64
• 6in4
• 6over4
• 4in6
• Teredo
• ISATAP

In order to help network vendors and service providers test their IPv6 transition solutions, the Internet Society (ISOC) has organized World IPv6 Day for July 8th, 2011.

Visibility into network traffic provides vital information needed to manage IPv6 deployments. Even if an organization has no immediate plans to support IPv6, it is very likely that there is already IPv6 traffic present on the network since IPv6 support is enabled by default on many operating systems. Serious performance and security problems can result if IPv6 traffic isn't carefully monitored and managed.

The sFlow standard fully supports IPv6 monitoring. Most switch vendors include sFlow monitoring within their switch hardware, providing the visibility needed to manage the transition to IPv6, reporting on all IPv4 and IPv6 traffic as well as the different encapsulation and tunneling protocols for IPv6 transition. Switches supporting sFlow don't need to be upgraded in order to report on IPv6 traffic, the sFlow data exported by the switches contains packet header information that allows an sFlow analyzer to report on all different types of traffic on the network. The end-to-end visibility provided by sFlow ensures that traffic can be monitored and problems identified wherever they occur in the network.

For example, Amsterdam Internet Exchange (AMS-IX) uses sFlow to track the growth in IPv6 traffic on their network. The following chart trends IPv6 traffic over the last year:

(credit AMS-IX sFlow Stats)

Enabling sFlow monitoring in the network is a critical first step toward managing a smooth transition to IPv6. Proactive deployment of sFlow monitoring ensures that the data is available to troubleshoot and avoid problems as systems are transitioned to an IPv6 world.

Standards

Data center convergence and virtualization offer the promise of improved efficiency and flexibility. Developing a network visibility strategy when planning the network upgrades needed to support convergence is essential since only network equipment with embedded traffic monitoring will provide the data center wide visibility essential for effective control.

This article examines the proprietary and standards-based protocols for embedded traffic monitoring as well as their current status and level of support.

Before looking at the standards, it's important to understand how current traffic monitoring protocols fit in the protocol stack. The article, sFlow and NetFlow, describes how sFlow operates at layer 2 (switches) and Cisco NetFlow (and variants from other vendors such as j-Flow, NetStream, LFAP etc.) operates at layer 3 (routers).

There are two organizations responsible for most networking standards:

1. IETF (Internet Engineering Task Force) is responsible for layer 3-7 protocols (IP, routing, DNS, telnet, smtp etc.)
2. IEEE (Institute of Electrical and Electronics Engineers) is responsible for layer 2 protocols (Ethernet, switching, 802.11 etc.)

The IETF has recently developed a standard alternative to proprietary IP flow monitoring protocols (Cisco NetFlow, j-Flow, LFAP, NetStream etc.). The IPFIX standard was created in order "to transfer IP flow data from IPFIX exporters to collectors." This focus on IP flow export is consistent with the IETF's responsibility for the TCP/IP suite of protocols and explicitly avoids addressing layer 2 monitoring (switches). The IPFIX standard was published in 2008. Unfortunately, IPFIX has found little support among router vendors, who continue to implement proprietary solutions.

The IEEE publishes the standards for Ethernet and bridging/switching, and is currently developing the set of standards for Data Center Bridging (DCB) that are driving data center convergence. The IEEE would seem to be the natural place to standardize a protocol for monitoring switched Ethernet traffic, however, the IEEE's focus is on the mechanics of layer 2 connectivity and network management protocols have not been a priority.

The sFlow.org industry consortium was formed in order to develop a multi-vendor standard to address the need for network visibility in layer 2 devices. Many of the members of sFlow.org actively participate in the IEEE standards process, ensuring that sFlow is well matched to the challenge of monitoring current and emerging IEEE standard networks (Ethernet, 40/100G, DCB etc.). The sFlow standard was published in 2001 and it is now implemented by most switch vendors (see sFlow.org).

In selecting a standard for data center visibility, it is important to understand how data center networks are changing. The traditional three layer architecture, in which traffic is moved up to the core and back, does not scale well. Instead, the trend is to integrate access and aggregation layer switches into a flat layer 2 network using shortest-path bridging (IEEE 802.1aq) so that traffic bypasses the core to deliver the increased scalability, bandwidth and reduced latency needed to support converged data center workloads.

The shift in data center network architecture requires a corresponding shift in network management. Instead of monitoring and controlling at layer 3 in the core routers, visibility and control functions move to layer 2 switches and the network edge.

sFlow is the only standard specifically designed for embedded monitoring of layer 2 devices. Selecting switches with embedded sFlow provides a low cost, scalable means of obtaining layer 2-7 visibility into all traffic flowing over the switched network (including storage traffic). Building a network visibility strategy around the sFlow standard maximizes the choice of vendors and ensures interoperable monitoring in mixed vendor environments, eliminating vendor lock-in and facilitating "best in class" product selection.

LAN and WAN

There is widespread confusion about the differences between sFlow and NetFlow and they are often simply referred to collectively as xFlow, implying that the two technologies are interchangeable. The sFlow and NetFlow posting described some of the technical differences between the two technologies, in particular, describing how sFlow operates at the Switch/Ethernet/LAN level and NetFlow operates at the Router/IP/WAN level. This division helps understand where the two technologies fit in the market.

The chart breaks down networking into switching and routing on the x-axis and network speed on the y-axis and then plots the application areas for sFlow and NetFlow. Since sFlow is built into switch ASICs, it offers monitoring solutions that span the full range of layer 2-3 switching products, from inexpensive switches aimed at office and small business environments, to the most demanding applications in supercomputer data centers, Internet exchange points and digital effects render farms. NetFlow is typically found in enterprise class routers. Since performance critical components of NetFlow are often implemented in software, NetFlow isn't widely used for monitoring at the high end of the router market (tier-1 ISPs). The cost of NetFlow enabled equipment limits its use at the low end of the router market.

Dividing the market into routing and switching products and the related applications helps explain why some vendors support sFlow while others support NetFlow. The chart also explains why a vendor might offer sFlow on their switch products and NetFlow on their router products. In practice, most networks blend switching and routing in order to meet the varied requirements of the different services running on the network. In many cases, a network monitoring strategy that embraces both sFlow and NetFlow delivers the most complete visibility into network activity.