Network-equipment manufacturers use lab network environments to perform scenario testing on new products, and they need to be able to reconfigure those networks quickly, accurately, and cost-effectively to support efficient and timely development. Physical-layer management delivers the network visibility to speed the development process, ensure the accuracy of network changes, and identify any failures.
Labs in Flux
Network-equipment lab networks are constantly changing. Rapid change occurs amongst many competing network architectures (top of rack, end of row, central patching, etc.) in order to achieve the highest speeds and performance. Each of these architectures impacts the cost and configuration of data-center hardware. For example, a top-of-rack architecture makes more sense, but you have to buy lots of switches. An end-of-row architecture is a little easier to administer, but you must buy more trunk cabling. In any case, network-equipment makers must test for all of these scenarios. Large enterprises also do testing to determine which configuration costs more and which is easier to maintain.
This file type includes high resolution graphics and schematics when applicable.
As a result, companies that develop (and sometimes purchase) network equipment need to test that equipment in a variety of ways, which means reconfiguring the lab network. Equipment test lab networks are dynamic because companies make many changes over the course of a day or a week. Lab techs might install one piece of equipment, test it, reconfigure the network, test it again, and then install another piece of equipment and reconfigure the network again. The process is ongoing.
Even when testing the same piece of equipment at various stages of its development cycle, it’s important to be able to reproduce exactly the same network settings, particularly when performing latency tests.
Throughout the testing process, technicians must be able to understand what’s connected to what in real time, and what each port is connected to in the design. For example, a company might be designing a new router and want to test dynamic-load balancing. This requires that the appropriate subnets or devices be connected to the router with the appropriate loads. For such a test, the lab needs to make sure that the correct quantity of server stacks are connected on appropriate ports and that the right circuits are going to the right ports on the router.
Test labs have their own teams that physically hook up the gear, as well as teams around the world running projects on that gear. Lab technicians are typically asked to manually document network changes. But in a lab environment where things change quickly, manual record keeping doesn’t work very well: Lab workers fail to document which ports are connected; it takes time to update records and send the updates to far-flung test engineers; and engineers often have to call in or send e-mails to check on the configuration. All of this takes time and is prone to errors. In a large lab, it can take an hour or more to trace a cable connection and document it properly, and it may be impossible to guarantee the exact reproduction of the setup at a later date.
Physical-Layer Management Streamlines Testing
A better alternative than the above is to automate network documentation in real time and provide design teams with browser-based access to that information. This is the domain of physical-layer management. Physical-layer management systems use intelligent patch panels and patch cords that report the state of each connection, the type of cable being used, the connection’s throughput, and other information to a database where it can be graphically represented. With a physical-layer-management system, a Chinese design team can see that a network device in California is connected to the right ports, and therefore will know that a test is being done properly. In addition, they can see the exact properties of cables connecting the two devices in terms of cable length and other metrics, which can be important when interpreting test results.
By having a physical-layer-management system in place in a development lab, the organization can execute many more network reconfigurations and iterations than before because it doesn’t have to stop to document the process—every connection that’s made is reported to the system. Moreover, reports can be generated for each specific test setup, enabling it to be reconstructed at a later date for backward-compatibility testing. For example, designers might want to know whether a new wireless baseband unit will work well with previous versions of remote radio heads.
Real-time event detection can make the difference between fast and successful equipment testing and a network nightmare. An inadvertent cable disconnection can make a test fail, for example, and engineers may wind up searching for weeks to find the problem. A physical-layer-management system, however, immediately reports the fault.
By using a work-order system within the physical-layer-management system, design engineers can instruct lab technicians on specific ports to connect and disconnect. For instance, a CONNECT command might trigger the green LEDs on the target port to flash, while a DISCONNECT command could trigger the amber LEDs to flash.
This file type includes high resolution graphics and schematics when applicable.
Another advantage to using physical-layer management in the network-equipment testing process is enhanced security. Since each cable has a specific serial number, design engineers can assign specific cables to specific ports to make sure that the appropriate performance level is tested on each port. Without physical-layer management, this process would require manual intervention.
In general, physical-layer management lets network-equipment engineers know that the port connection information in their labs is accurate in real time. This breeds better operational efficiency: They can instead focus on equipment performance metrics rather than worrying about whether or not things are connected properly, which translates into faster testing cycles.