Seven steps to network lab automation--Part II

Step 2: Deciding what to automate
The next step is to determine exactly which sections of a lab will benefit most from physical-layer automation. Seldom does it make sense to connect every single port in a test lab to a physical-layer switching infrastructure, especially early in the automation process. That means lab managers must spend a fair amount of the assessment process understanding which areas of their labs undergo the most reconfiguration or can be better utilized or shared. The goal here is to understand where dynamic configuration of the lab's physical infrastructure can help the most.

For some labs, it will be ensuring that the most expensive pieces of equipment--traffic generators, for example--are put on the switched environment. This facilitates improved sharing of those resources among multiple users or across multiple functions, giving the organization the most bang for the buck on these devices. For others, it may simply be to consolidate multiple patch panels and cabling systems that take hours to move between each test. Or it could be to interconnect dedicated test equipment--used by individual engineers at their workstations--to a set of shared equipment within the lab.

A point worth noting: Most labs will want to take a phased approach to the automation process, starting where they need help the most, and adding resources to the infrastructure over time. Because of this, the lab OS software should allow all devices, whether connected to the switching infrastructure or not, to be designed into test topologies and reserved and tracked equally.

Step 3: Choosing the infrastructure
The capabilities of physical-layer switches vary and a careful analysis is important to get the best fit for a particular lab environment. Making this decision will involve examining a wide range of factors, ranging from form factor to interfaces and technologies supported by the various vendors' switches to the conditions in the particular lab being automated.

Before continuing, let's take a step back and briefly describe what a physical-layer switch is and, more importantly, what it is not. In basic terms, a physical-layer switch operates similarly to a manual patch panel, except that patching is controlled electronically through software. A physical-layer switch patches physical circuits, essentially simulating the actual plugging/unplugging of cables in/out of a manual patch panel.

A physical-layer switch, or Layer 1 switch, operates at Layer 1 of the Open System Interconnection (OSI) model. A physical-layer switch merely establishes a physical connection between two ports, and can provide media conversion. It does not read, modify or route data based on packet or frame headers. Data traversing the circuit is unimpeded by the overhead of packet processing. In addition, physical-layer switches are non-blocking (to a point), protocol-independent devices that operate at full line speed. Contrast this with a typical Ethernet switch, which operates at Layer 2 or 3 in the OSI model and switches packets by reading packet or frame headers and routing data to the destination ports designated in the packet header.

Some labs use Layer 2/3 switches rather than Layer 1 switches for interconnecting devices into a physical topology, but doing so is not appropriate for many labs. Firstly, Layer 2/3 switches can impact the results of tests. A Layer 2/3 switch, for instance, will filter bad packets or fragments, or determine where to send a packet based on IP address, for example, which are behaviors that may not be appropriate in a test environment. Additionally, Layer 2/3 switches may be costly to scale, and don't provide the flexibility of Layer 1 switches to support a mix of media types and media conversion.

When assessing which physical-layer switches to deploy, lab managers should consider the performance characteristics required by their lab, the OSI layer at which they are testing, the number of ports they need to interconnect, data rates and interfaces in use, the any-to-any capabilities their lab requires, the copper and fiber cabling requirements of the lab, and the requirements for inserting test, analysis, or impairment equipment into connections between devices.

Most labs today deploy a mix of physical-layer switches from different manufacturers. This allows the lab to better support a variety of data and interface types and the various characteristics of the technologies that need to be tested. In addition, feature and function differences of otherwise similar switches may dictate deploying several different switches for addressing a variety of needs within a lab. Economic factors may also come into play here. Certain types of ports may be available in many types of switches, but may be more cost effective in a particular type or brand depending on scale and other factors.

Step 4: Lab Management: Choosing the right solution
Because the lab OS software provides the support structure for managing and automating the infrastructure of your lab, your choice of a solution is a critical decision.

Many labs use home-grown solutions for managing various lab processes. For the most part, the use of home-grown solutions has been perpetuated by a lack of commercially available solutions for lab management. Disparate solutions for managing individual devices, test scripts, or specific test gear have not been designed with the holistic lab in mind, requiring front-end interfaces to be designed by lab personnel. But with the addition of physical-layer automation and the solutions available today, buying an off-the-shelf lab-management solution is a no-brainer.

Thoroughly investigate your options, and focus on the features that are important for your environment. Here are just a few of the key things to look for when choosing a lab-management solution.

• An open solution that manages multiple vendors' physical-layer switches. As mentioned in step 3, most labs today are heterogeneous and require a mix of switch technologies accommodating different media types or special features provided by different switches. Proprietary solutions from switch vendors themselves or from customized solutions will lock the lab into a single hardware vendor, which is never a good idea. A hardware independent solution allows the lab manager to select switches based on features, performance, port density, quality, and value rather than on a limitation of the lab's deployed management software. And because this hardware-independence forces competition among the switch vendors, it also helps to commoditize the switches and compel vendors to provide additional value to their customers. Further, a common front end or set of commands that masks the particulars of the switching infrastructure is a key factor in the efficiency, reusability, and portability of test scripts. While hardware-independence is important, feature integration is also important, ensuring the software provides intuitive access to hard-to-use switch features such as connection tapping, multicasting, rate and framing settings, and SFP (small form-factor pluggable) diagnostics.





Page 2: next page
Page 1 | 2