Maxwell Pro FAQ

Frequently Asked Questions about the Maxwell Pro Network Emulator

Topics covered:

  • What kind of impairments can I do with Maxwell?

  • What is the purpose of creating a packet and selectively inserting it into the flow?

  • How can you have multiple impairment sessions when you only have two interfaces?

  • How does Maxwell keep track of thousands of sessions?

  • What does Maxwell look like to the devices on the network? Is it like a router?

  • If Maxwell does not have an IP address, then how do you control Maxwell?

  • If Maxwell is a layer two bridge, how can I modify MAC addresses on traffic going through Maxwell?

  • What about VLANS?

  • What about IP tunnels?

  • What about encrypted tunnels?

  • How does Maxwell emulate DS3, E3, OC-3, and OC-12 links?

  • How were Maxwell's tests selected?

  • Why are my impairment settings not having any effect?

  • If a packet does not match a filter what flow does it go into?

  • How do I use Maxwell with fiber optic Ethernet?

  • How do I use Maxwell with wireless?

  • Can Maxwell support High Definition television traffic?

  • Can Maxwell limit bandwidth?

Q: What kind of impairments can I do with Maxwell?

You can do all the conventional impairments and you can create your own.

The conventional impairments include: packet delay, loss, duplication, jitter, re-ordering, fragmentation, burst errors, and all their variations.

The more important and interesting impairments are the ones that exercise network protocols.

Here are two examples of creating your own impairments for testing video products, such as video conferencing systems. Video conferencing systems typically use the Real-Time Protocol (RTP).

In the RTP protocol, you could delete the Marker bit (the "M" bit) from the header of a video stream. The M bit indicates that the packets following it are video packets and must be played in the proper order at the destination device. If the marker bit is removed or corrupted, what is the effect on the destination device? Will it generate an error message for the user? Will it play the video packets out of order, thereby producing a distorted film? Will it simply reject the packet stream? Or, will the device crash?

Another part of the RTP protocol is the Synchronization Source Identifier (SSRC). This is a randomly generated number that is independent of the network address. In a video conference of five participants, there would be five SSRCs, each one identifying a unique participant's communication. In this scenario, Maxwell could identify two different streams of RTP packets and change the SSRC numbers to be identical. The end device should properly detect the duplicate identifiers in the streams and avoid collision.

Q: I read that Maxwell allows the user to create a packet and selectively insert it into the flow? Why would I want to do that? Can you provide an example?

Yes. Your objective is to make sure that the product you are developing is sufficiently robust to handle any series of packets that it receives. Your product should exhibit the proper behavior, whether that is to discard the packet(s), generate an error message, or time out.

Using the "M" bit example from RTP, you could insert an extra packet before the "M" bit, duplicate the "M" bit packet, or insert an extra packet after the "M" bit. The destination device receiving the flow of RTP packets should not crash, but instead, exhibit the proper behavior.

In the Transmission Control Protocol (TCP), you could insert a reset packet. By inserting a reset packet in the middle of a TCP connection, the receiving device might reset. The receiving device should check that the reset packet is valid before executing it.

Thus, the ability to insert packets and change their contents allows you to more thoroughly test your product.

Q: How can you have multiple impairment sessions when you only have two interfaces?

Maxwell can detect and track sessions independently of the physical interface that may be associated with the session. Maxwell only has to be astride the path between any number of sources or destinations. Think of a session as containing one source IP address and port number and one destination IP address and port number. Now think of thousands of sessions. Maxwell can handle thousands of sessions. Maxwell can detect a session on a T3 circuit, for example, without having any kind of T3 interface, or connecting to the T3 interface.

Furthermore, Maxwell can identify a session in several ways; besides the source and destination IP address, Maxwell can detect the session or flow, based on port numbers, VLAN tags, protocol types, packet payload contents, IEEE 802 header information, and many other criteria.

In addition, Maxwell can detect the session at any point in the session, not just at the beginning. For example, Maxwell can detect a video conferencing session well into the session based on the SSRC. Other products are quite limited and can only identify traffic based on the physical interface of the devices in use.

Q: Well… how can Maxwell do that? How can it keep track of thousands of sessions?

Maxwell uses state machines to keep track of all the sessions.

Q: What does Maxwell look like to the devices on the network? Is it like a router?

Maxwell is invisible to the other devices on the network. The other devices do not perceive Maxwell as a "neighbor" with an IP address, nor is it the next "hop" in the network. Maxwell functions like a layer 2 or 3 device. Maxwell is not like a router; Maxwell functions more like a bridge.

Q: If Maxwell does not have an IP address, then how do you control Maxwell?

Maxwell has a separate physical interface with an IP address that is used for control purposes. Maxwell has a total of three Ethernet interfaces, two of which are used for emulation (bound to the Maxwell daemon rather than an IP stack) and the third is bound to an IP stack for management and control.

Q: If Maxwell is a bridge at layer two, how can I modify MAC addresses on traffic going through Maxwell?

Maxwell can change the MAC address, duplicate the MAC address, insert an illegal MAC address, and inspect MAC addresses matching certain criteria, and then select their associated packets for special processing, such as changing the contents.

Q: What about VLANS?

Maxwell can move packets from one tagged VLAN to another. Maxwell can move packets from a tagged VLAN to an untagged VLAN. Maxwell has full capabilities to manipulate IEEE VLAN headers.

Q: What about IP tunnels?

Maxwell understands IP within IP. Maxwell can view and manipulate nested IP headers independently of one another. Maxwell can also work with TCP and IP inside IP.

Q: What about encrypted tunnels?

If you provide Maxwell the decryption keys, it can perform the classic man-in-the-middle attack.

Q: It seems that Maxwell is limited to two 10/100/1000 ethernet interfaces, so you have no solution for introducing impairments for DS3, E3, OC-3, and OC-12?

The other physical interfaces are not required. Nearly all clients and servers are Ethernet based. When they connect to other high performance networks with higher speed media, they nearly always do so via a router. Maxwell does not require a physical interface to a particular type of media to track and impair sessions traversing that media.

Q: Where does Maxwell fit with other impairment products?

In network impairment testing, there are modelers, emulators, and simulators. They all have different roles to play.

Modelers:

Network modelers represent phenomenon as a set of mathematical equations. A network modeler lets you define traffic volumes, flows, network architectures, etc. So you can visualize the application performance, and do "what-if" analysis. Modelers do not deal with real traffic; no packets flow through a modeler. OpNet is an example of a modeler.

Simulators:

Simulators generate test conditions approximating actual or operational conditions. Simulators rely on mathematical formulas to determine behavior.

For example, an SNMP agent simulator running on an inexpensive PC, would simulate the behavior of the SNMP agent inside an expensive router. You could query this simulated SNMP agent for the values of MIB objects. Or the simulated agent could send an alarm that a link was down. However, the values would not be real and there is no real link that is down. So, what is simulated is the behavior of an agent, but not a real link down condition, or the real value of a MIB object in the router.

A network simulator uses mathematical models to simulate, for example, a frame relay connection. It appears to the client-server application that it is operating over a frame relay "cloud", however, it is really running over a mathematical model that has made several assumptions about how frame relay connections operate. Shunra is an example of a simulator.

Emulators:

An emulator imitates the function of (another system), as by modifications to hardware, software, or network activity that allow the imitating system (the emulator) to accept the same data, execute the same programs, and achieve the same results as the imitated system.

Maxwell is an emulator because it can, for example, behave like one part of a TCP session; Maxwell imitates the device that would normally be on one side of the session. Emulation tricks the software into believing that one device is really some other device. Some router companies, for example, emulate Cisco’s IOS, so that their router behaves like a Cisco router. Some printer companies emulate HP printers so that their printer is compatible with all the applications and drivers that the HP printer supports.

Q: Why are there hundreds of protocol tests rather than hundreds of thousands?

It is rarely necessary to test every possible value of every protocol field. For most protocol fields there are certain values that are likely to cause trouble, for example, zero, 1, -1, and values where a bit at a byte boundary goes from 0 to 1 or vice versa.

Some test suites enumerate every possible value. This allows those suites to claim prodigious numbers of test cases. However, it is almost always the case that all but a very few of those test cases are of very little, if any, value.

For example, one might test every possible value of a TCP segment size, all 4,294,967,295 possible values. But experience has shown that programmers are likely to make errors when the value is at 0, 1, 0xFFFFFFFF, 0x80000000, 0x0000FFFF, 0x00010000, or +/-1 one from those values. In other words, problems are likely due to programmers who mistakenly use signed rather than unsigned arithmetic, who use 16-bit variables rather than 32-bit, or who do not properly calculate differences when one of the two values being compared has a high order bit set and the other value does not (for example when computing the effect of a TCP window wrap.)

In addition to the "fuzzing" of protocol fields (a small part of Maxwell's overall capabilities), many of Maxwell's protocol tests split single packets into several packets. For example, one of Maxwell's TCP/IP tests splits what is the typical FIN/ACK packet used when closing a TCP connection into a pair of packets, one with the FIN and another with the ACK. Simple minded test suites that enumerate all possible field values do not do this kind of thing.

Q: How were Maxwell's tests selected?

Maxwell is based on years of real experience with protocol implementation. We have drawn upon the following sources for guidance about what tests would be useful:

Internet RFCs often highlight areas of concern by marking certain protocol aspects as "MUST", or "SHOULD". Those are usually good things to test. But even more useful are often those things that RFC's mark as "MUST NOT" or "SHOULD NOT".

  • Reports from security groups such as the CERT.

  • Anecdotes about protocol failures and penetrations.

  • Comments made by system crackers.

  • Observation of common programming errors, most notably the improper mixing of signed and unsigned arithmetic, the use of variables that are too-small to hold the range of data that may be loaded into them, inadequate attention to arithmetic in a wrapping number space, and opportunities for buffer overruns.

Q: Why are my impairment settings not having any effect?

The most frequent reasons why a user's settings are not having any apparent effect are these:

The impairment was applied to the other direction. Each of Maxwell's "flows" is composed of a pair of impairment settings. One of these settings establishes the impairments to be used on packets arriving on PORT0 and leaving via PORT1. The other establishes the impairments to be used on packets arriving on PORT1 and leaving via PORT0.

The impairment was applied to a different flow than the one that the packets are flowing through. Maxwell uses the user-specified flow specification to sort incoming packets into the various flows. There are different impairment settings for each flow.

A useful trick for isolating these kinds of problems is to go through all of the flows, and for the PORT0 to PORT1 (uphill) and PORT1 to PORT0 (downhill) directions and set the drop probability to 100%. This should have the effect of stopping all traffic. Then those drop settings can be removed, one by one, until the traffic resumes. That should give a good indication of which group of settings is affecting (and not affecting) your traffic.

Q: If a packet does not match a filter what flow does it go into?

When a packet arrives it is compared against the packet specification for the first flow. If it is a match, the packet is accepted into the first flow. The packet matching stops when the packet is accepted into the flow.

If a packet does not meet the flow specification for the first flow then the next flow is tried, and then the next, and the next, and so forth.

If the packet runs the gauntlet and does not match the specification for any flow, the packet is discarded.

For this reason it is often useful to set some obvious impairment – like a large delay – on both the uphill and downill sides of the last flow so that any packets that slip past the filter settings will be impaired in a way that is fairly easy to notice.

Q: How do I use Maxwell with fiber optic ethernet?

InterWorking Labs has tested the TRENDnet TFC-1000MSC Multi-Mode Fiber Converter with SC-Type Connector, an external copper-to-fiber conversion box, available from many on-line sellers. Other converters will probably work.

Note: Some types of converter may lock link-state on the copper ethernet side to an "on" state without regard whether optical link state has been achieved.

Q: How do I use Maxwell with wireless?

The easiest way to do this is to attach a wireless "access point" to either Port0 (eth1) or Port1 (eth2) on Maxwell.

Some wireless base stations act as more than a mere access point – for instance many act as routers, firewalls, or network address translators. In nearly every case you simply want to attach Maxwell to the wireless base station in the same way you would attach other wired devices that need to communicate with wireless devices. Often this means attaching Maxwell to the "harmonica" of wired network ports found on many wireless stations that also include a built-in ethernet switch.

Some wireless base station devices work under the control of a manager. In these cases please feel free to discuss this with our support staff.

Q: Can Maxwell support high definition television traffic?

Yes. Consider a compressed HDTV stream of about 18,000,000 bits/second. Most of these bits will be carried in full-sized packets of about 1500 bytes each. That works out to about 1500 packets per second, well within Maxwell's packet per second capacity.

Q: Can Maxwell limit bandwidth?

Yes.

Maxwell's bandwidth limitation mechanism are quite sophisticated. Rather than using a typical token bucket queue, Maxwell takes into account several parameters, including, among others, data propagation rates, link distance, and frame encapsulation overhead.

Maxwell's approach to bandwidth limitation is to compute when the last bit of a packet should arrive at the destination's network interface. Maxwell holds the packet until that time and then releases it. Because Maxwell generally is used in a lab environment in which Ethernet paths are virtually instantaneous, this approach yields a very good approximation of actual packet flow rates across a bandwidth limited network path.