 |
|
|
Appendix B - The Test Equipment Spirent Communications SmartBits SMB-6000/SMB-600 Spirent Communications (www.spirentcom.com) provides network and communications testing solutions for developers, manufacturers, evaluators and operators of communications equipment, networks and services. The SmartBits 6000 (and its smaller sibling the SmartBits 600) are multi-port network performance analysis systems designed to measure the performance limits of complex network configurations and network devices.
The SmartBits 6000 is a high port density network performance analysis test system. Each chassis can hold up to six SmartModules in various combinations to support up to 24 Gigabit Ethernet ports, 96 10/100 Mbps Ethernet ports, 12 POS (Packet over SONET) ports, 12 SmartMetrics Gigabit ports, or a mixture of these port types. Multiple SmartBits 6000 chassis can also can be daisy-chained together to achieve even higher port densities. The SmartBits 6000 is controlled from a Windows-based PC or a UNIX workstation through a 10/100 Mbps Ethernet connection. Control is via a �soft front panel� SmartWindow application, and the system also includes SmartApplications software, which automates industry standard performance tests as defined in RFC 1242 and RFC 2544. Spirent�s SmartBits SMB-600 chassis is a portable and compact version of the SMB-6000, providing all the same features and holding up to two modules. It can support up to 4 Gigabit Ethernet ports, 16 10/100 Mbps Ethernet ports, 2 POS (Packet over SONET) ports, 2 SmartMetrics Gigabit ports, or a mixture of these port types. Spirent has recently introduced a new generation of SmartBits network and Internet test systems called TeraMetrics. The TeraMetrics open architecture is a foundation for a new family of SmartBits test systems to meet the accelerating demands, complexity, increased speeds and scalability of terabit (up to 10 gigabits per second) switching. The range of SmartBits products also includes a set of software tools that allow SmartBits systems to be used for a variety of applications, ranging from industry standard tests to specific applications for new and emerging Internet and data technologies. Those used extensively within NSS include: SmartWindow � SmartBits virtual front panel. Within SmartWindow, the test engineer simply needs to select a protocol, set class of service parameters, and then test any of the following: NIC cards, servers, bridges, cable modems, xDSL modems, switches, routers, VLANs, firewalls, live networks, or multimedia scenarios.
SmartApplications � Provides automated performance analysis for bridges, switches, and routers per RFC 1242 (Benchmarking Terminology for Network Interconnection Devices) and RFC 2544 (Benchmarking Methodology for Network Interconnect Devices). Tests are available for Ethernet, Token Ring, ATM, and Frame Relay. SmartFlow � Tests line rate QoS. Enables both forwarding and policy tests. Analyses each incoming stream to test a device's (or network's) ability to forward very large numbers of flows. Analyses the device's ability to correctly handle policies implemented in the network or device under test. SmartTCP � Tests load balancer performance. Tests measure the TCP session performance of server load balancer devices that make forwarding decisions based on Layer 4-7 information. SmartTCP benchmarks both the rate and connection capacities of the device under test to establish, maintain, and tear down TCP sessions. WebSuite/Firewall � Designed to simulate real-world traffic loads in order to support the testing of content delivery and network equipment. Gauges the performance of a firewall's performing NAT (Network Address Translation). Determines maximum application transaction capacity. Measures application throughput with TCP acting as the transport agent. Evaluates a firewall's ability to deal with DoS (Denial of Service) attacks. TeraVPN � Designed to measure the network performance of IP Virtual Private Networks. Determines IP-VPN tunnel creation capacity using IPSec protocols. Also generates UDP or HTTP traffic over each tunnel and measures data performance characteristics like packet loss, latency, and response time.
SmartWindow and SmartFlow are used to generate background traffic for the 64 and 1514 byte tests in this report. In general, the Spirent software is not particularly easy to use, lacking a consistent look-and-feel across the range making it difficult to switch from one product to another. Not all of the software packages run across all of the SmartModules either, making it difficult to select the exact combination of hardware and software required to perform a range of tests. However, the hardware is solid and reliable, and provides a means to generate high volumes of layer 2/3 traffic up to multi-Gigabit speeds. Caw Networks WebAvalanche and WebReflector Whether you are building network equipment or providing a service, you must deliver consistent performance under all conditions. Until now, capacity assessment at high-loads has been a costly and complex process. For this reason Caw Networks (www.caw.com) introduced the WebAvalanche and WebReflector appliances to assist with the challenge (Caw Networks has recently been acquired by Spirent Communications). At NSS we have taken these capacity planning products and integrated them into our test-bed to aid in simulating real-life Internet conditions � the sort of conditions that the average user experiences daily.
WebAvalanche is described by Caw as a capacity assessment product that challenges any computing infrastructure or network device to stand up to the real-world load and complexity of the Internet or intranets. The system generates simulated network traffic that features real-world characteristics such as connection speed, packet loss, browser emulation, user think-time and aborted transactions. This helps provide invaluable information about a site's architectural effectiveness, points of failure, modes of performance degradation, robustness under critical load, and potential performance bottlenecks. Using WebAvalanche to generate Internet user traffic and WebReflector to emulate large clusters of data servers, it is possible to simulate the largest customer environments. Between them they can set up, transfer data over, and tear down connections at rates of more than 20,000 per second-all while handling cookies, IP masquerading for large numbers of addresses, traversing tens of thousands of URLs and operating under a realistic mix of traffic. Protocols supported include HTTP/1.0, HTTP/1.1, FTP, and RTSP/RTP, and the system also allows modelling of user behaviour, supporting such actions as use of proxies, user think times, click streams, and HTTP aborts (�click-aways�). Support is also provided for HTTP forms, HTTP posts and SSL-encrypted traffic, and the tester can specify a list of URLs and data object parameters that can be changed on a per-transaction basis. WebAvalanche includes a high-accuracy delay factor that mimics latencies in users' connections by simulating the long-lived connections that tie up networking resources. Long-lived, slow links can have a completely different effect on performance than a large number of short-lived connections, so this approach provides the ability to finely tune the test scenario for more realistic results. As does the ability to introduce conditions that can seriously affect real-world performance such as packet loss levels, TCP/IP stack characteristics and, of course, line speed. User profiles can be created which enable Web Avalanche to mix different user types in a single test � perhaps one group of users could be running over a GSM link with high latency and heavy packet loss, whilst another group could be running over a 64K ISDN line, and yet another over a T1 connection.
WebAvalanche is capable of initiating and maintaining over a million concurrent connections, each appearing to come from a different IP address. The dual-CPU dual-Gigabit card version of the product can generate over 1.2Gbps of traffic, at rates of up to 45,000 HTTP GETs per second. This allows realistic and accurate capacity assessment of routers, firewalls, load-balancing switches, and Web, application, and database servers. It helps identify potential bottlenecks from the router connection all the way to the database, or can simply be used to generate a background test load of realistic traffic. Load can be specified in a number of ways, using user sessions, user sessions per second, transactions, transactions per second, connections or connections per second. While WebAvalanche focuses on the client activity, WebReflector realistically simulates the behaviour of large Web, application, and data server environments. Combined with WebAvalanche it therefore provides a total solution for recreating the world's largest server environments. By generating accurate and consistent HTTP responses to WebAvalanche's high volume of realistic Internet user requests, WebReflector tests to capacity any equipment or network connected between the two systems. The operating system for both units is proprietary � Unix-like in appearance � and is loaded from flash cards at boot time. Luckily, it is rarely necessary to get to grips with the underlying OS, since all configuration for both WebAvalanche and WebReflector is performed via a Web-based graphical interface. A WebAvalanche test consists of a sequence of phases, each of which are defined in the Test Specification. The operator configures the number of sessions, connections or transactions initiated (either per second, or throughout the entire test), the maximum number of active simultaneous user sessions, and the duration of each phase. The Test Specification consists of two main categories: Load Profiles and Network Profiles. The Load Profile settings control how traffic is generated during a test, while the Network Profile options enable special routing, DNS and TCP functionality of WebAvalanche. Test Specifications can be used with one or more User Profile definitions to simulate a variety of user behaviours. Each User Profile consists of three sections: User Behaviour, Connection Properties, and Browser Emulation.
User Behaviour settings control a user�s actions, such as the period of time for which they view a Web page (think time), how often the abandon a slow-loading page (click-away), as well as the URLs targeted, form data submitted, and cookies used during a user session. Connection Properties settings determine the amount of packet loss, the connection line speed, and the IP addresses of the users. Finally, the Browser Emulation settings control HTTP protocols, HTTP headers, SSL configuration, and user authorisation. A similar process is required on the WebReflector unit, where a test consists of Test Specifications with a defined number of servers (Server Profiles) handling specified types of transactions (Transaction Profiles). Server Profiles consist of connection properties and server emulation settings. Transaction Profiles control things like status codes, data and MIME types, HTTP headers, response size, placement of operator-defines response data, and response latency. Test Specifications are extremely complex things to create, though there is extensive assistance available in the form of context sensitive help in the console and good hard-copy documentation. It is, however, very difficult to create tests that provide exactly the sort of network traffic you may be looking for. For example, a delicate balance needs to be struck between the connections per second and the number or type of URLs to be retrieved. If an attempt is made to alter the mix of packet sizes returned by WebReflector, for example, the operator could suddenly find that the traffic becomes very bursty, or the number of connections per second increases to unacceptable levels. This balancing act is very difficult to master, and this is one area where the documentation is not much help. The operation of the GUI has improved significantly with the release of the latest version of the software, with a significant increase in speed of response making the user experience much more enjoyable. There is still no facility to copy or backup Test Specifications or individual component parts of those tests, however, and so it is impossible to make copies of any of the default tests to use as building blocks for your own. Likewise, it is often necessary to have two or three different versions of tests each with slightly differing parameters � having to create each one from scratch rather than create multiple copies and change one or two settings is extremely frustrating. Once the tests are running, there is an excellent real-time display available at the console which provides detailed information on the progress of the test, transactions, network traffic, sessions, response times and use of resources. Once the test is finished, results are written to a CSV file, which can then be imported into a third party reporting package � such as Excel � for further analysis. It would be nice to see some form of built-in reporting capability within the WebAvalanche console. Despite the problems mentioned above, the Caw equipment remains one of only a handful of devices capable of performing this type of �real world� testing concentrating on layer 4 to 7. In addition to the capabilities of the software, however, it is the ability to generate over 1Gbps of traffic and over 1 million simultaneous users in a single chassis (or two if you want to make use of the matched WebReflector unit) which makes Web Avalanche so attractive. The evolution from hubs to switches, coupled with increased security concerns and risks, makes the deployment of traditional NIDS systems problematic on most current networks. While switched LANs have dramatically increased bandwidth, they have also introduced the problem of visibility into full-duplex switched LANs. Intrusion Detection Systems cannot plug into multiple point-to-point full-duplex links to monitor them. Port mirroring is a partial answer but has limitations in that error packets are not duplicated to the mirror port, and at higher speeds, we have found that most switches are simply unable to present anything like the full bandwidth to the mirror part. The act of mirroring can also degrade the normal switch performance on other ports. Further, mirror ports only present one side of a full-duplex connection, leaving you to blind to half of the traffic on a link.
These problems can be overcome by utilising network taps, which allow an IDS device to be placed �in line� with the data stream from a switch port � everything that port sees is duplicated on the tap ports, full duplex, and including all errors. The tap thus allows the IDS to see both sides of a full-duplex conversation, and has the added benefit that it prevents direct connection to the IDS from any point on the network � a useful additional security precaution. Another benefit from the network administrator�s point of view is that taps eliminate the need for network connections to be broken and re-cabled each time a network segment needs to be analysed or monitored. Thus once the tap is in place, changes to the IDS infrastructure do not impact on the overall network. For this test, we used the 10/100 4 Port Critical Tap from Network Critical (www.networkcritical.co.uk). This is a fault-tolerant wiring device that can be inserted into full-or half-duplex 10/100 Mbps Ethernet links for use with Intrusion Detection Systems, providing the ability to view up to four full-duplex segments simultaneously from an array of IDS engines. It also allows an IDS sensor to monitor errors such as undersize and oversize packets, and packets with a bad CRC. The Critical Tap does not impact the traffic flow in any way, and thus causes no degradation to the network. On the other hand, its use can certainly alleviate switch performance degradation due to port mirroring. The four-way taps used in our labs consist of four identical independent taps marked as TAP POINT 1 to TAP POINT 4. Each Tap Point consists of four UTP connectors (one to switch, one to server, and two for full duplex mirrored traffic) and a Power Status LED. The LED indicates that power is available in the Tap and that the echoed data should be available at the RX Data ports.
Cabling must not exceed 90 metres between end devices or 45 metres on either side of the tap. Cabling lengths above this can induce errors and dropped packets in the tapped link. All patch panels, drop leads and other equipment between the switch and server when taking maximum lengths into account. Installation and subsequent use is simple � simply connect up the cables and go. It is important to ensure that cables are connected the right way round between server and switch, however. If not, traffic will not be echoed to the tap ports, though normal network traffic will not be affected in any way. This is an important feature, since it provides a degree of fault tolerance. Should the tap ever fail, for example, the bypass circuit ensures that normal traffic remains unaffected. Although the IDS becomes blind in such situations, at least the tap failure does not act as a Denial of Service for the rest of the network. Click here to return to the IDS Index Section |
Security Testing
|
Send mail to webmaster
with questions or
|
