The final of the four testing challenges developers of FCoE network equipment face when verifying equipment behavior, performance, and responsiveness is being able to not only test both the LAN and SAN components of the network simultaneously but to also combine test results and expertise onto a single, converged platform.

Currently, the LAN and SAN are separate networks which have their own tools and different testing focuses. For example, LAN testing focuses on the switch and network only. SAN testing, in contrast, requires network-to-end-device verification as all hosts, fabrics, and targets contribute to the overall performance of the network. Given that the LAN fabric is based on best effort delivery while the SAN has complete traffic control end-to-end governed by Fibre Channel’s protocol for zero frame loss, LAN QoS testing does not apply to storage networks. Rather, SAN testing measures the performance of Fibre Channel links through mechanisms such as buffer to buffer credit management from the host through the fabric to the storage. In addition, as SAN testing must verify the delivery of every single frame, it requires a wholly different dimension of performance and latency measurements compared to LAN testing.

Convergence of the LAN and SAN networks, however, needs to extend beyond simply carrying traffic out to all aspects of network management and testing. As the LAN and SAN become a single logical network under FCoE, analysis and monitoring tools need to accommodate this convergence as well, enabling developers to utilize a single test and development platform.

A common misconception is that as the network has converged on Enhanced Ethernet, converged testing should follow Ethernet’s traditional QoS-based structure. However, since all the new, enhanced features are designed to enable storage data to be converged with LAN data with performance comparable to a separate SAN, testing must actually focus on the SAN’s more stringent requirements. Thus, when designing a test setup for a converged Enhanced Ethernet network, developers must step away from QoS-based testing, which is a measure of lossy network performance, in order to focus on performance testing of a lossless network with zero tolerance for packet drop.

The challenge of testing Enhanced Ethernet is how to combine the expertise required for testing lossy traffic with that required for testing lossless traffic. As the testing focus of these two different types of traffic are difficult to reconcile, the analysis instrumentation itself must be integrated as a converged platform. In this way, it becomes possible to test the various convergence properties such as the priority groups and traffic classes as well as the influences these have on the converged network as a whole.

As I discussed previously, developers of FCoE network equipment face four key challenges when verifying equipment behavior, performance, and responsiveness.  The third testing challenge developers must address lies in testing long-term network congestion management mechanisms.

When performing conventional Ethernet LAN analysis, most tests involve only the switches as the QoS performance of the LAN network is mainly determined by them. FCoE developers may be tempted to employ fabric-only tests which utilize traffic generation tools to simulate the majority of nodes “operating” over the network.  Such fabric-only based testing, however, only exercises a subset of the Enhanced Ethernet capabilities that connect an FCoE network. 

For example, certain Data Center Bridging (DCB) protocols – such as congestion notification (CN) – require that all devices in a link participate in network management.  To comprehensively test CN mechanisms, then, developers must be able to create long-term congestion situations, monitor the resulting CN messages generated, and verify how end stations react to each CN message.

Useful inline test tools include protocol analyzers, error injectors (Jammers), and delay emulators. Delay Emulation allows developers to shape traffic bandwidth per priority, re-order frames, and emulate distance delays. For full control of traffic, Delay Emulation technology can be combined with Analyzer and Jammer functions to enable testing of extremely complex networks, including full CN message testing.

Continuing my discussion of the four key testing challenges developers of FCoE network equipment must face, the second challenge is the need for hardware-based protocol tools. With their high throughput and advanced capabilities, FCoE and Enhanced Ethernet technology have created the new need for hardware-based test tools.

Software-based analysis tools already struggling to evaluate Gigabit Ethernet will provide significantly degraded performance at 10 Gb/s.  Rather than providing 100% visibility into network interactions, software-based analyzers require developers to pare down what information is collected and made available for offline analysis.  Identifying problems is often the most difficult part of troubleshooting, especially when working with new protocols like FCoE with which developers are still becoming familiar.  Working with limited information obscures problems and complicates troubleshooting.  This is especially true for SAN analysis where it is almost impossible to debug issues using broken or incomplete traces. 

Another complication that arises is that all Data Center Bridging (DCB) protocols communicate at the lower data layers, making them inaccessible to software analysis tools.  To troubleshoot DCB issues requires hardware-based access in order to guarantee accurate, 100% capture at line-rate.  In addition, end node SPAN ports have a limitation of 10 GE because their aggregation mechanism requires higher bandwidth such as 40 GE, a technology which is still under development.  Only hardware-based protocol analyzers that guarantee100% line-rate analysis of everything on the wire can effectively capture all the necessary data to facilitate efficient network debugging and troubleshooting.