Contact Us

Maxwell Pro Network Emulator and Protocol Tester


Maxwell Pro:  The Engineer's Network EmulatorTM

  • Overview
  • Tech Specs
  • FAQ
  • Client Reviews
  • Compare Versions

Test Your App or Device Under Adverse Network Conditions

Maxwell Product Brief in PDF Maxwell-pro-product

Maxwell Pro vs. Brand "X"

Compare network emulators:

What is the value of saturating a hardware link with traffic?  Should you consider "rolling your own" with open source software? Robustness testing vs. load testing?  How do you value intelligent network protocol impairments? 

Remediate app performance before you deploy.  Let us show you how.

Read the Report

Protocol Testing With Maxwell Pro

Read More

Optimize Application Performance using Maxwell Pro Network Emulator

The Maxwell Pro Network Emulator helps engineers learn how their products will perform in mobile, cloud, and WAN networks. By capturing and changing network flows, Maxwell Pro can induce the conditions that cause network congestion, slow links, time outs, Lossy networks (LLNs), and many other adverse network conditions. Engineers can then see the effects on the device or application to find and fix bugs, solve network problems, and learn the limits of device and application performance.

  • Test, diagnose and remediate application performance in new releases by replicating the production network in the lab.
  • Understand how to correlate network behavior with the cause of that behavior to learn how the network operates and how a product performs --  useful for demonstrations, tradeshows, and classroom education.
  • Simulate all network technologies and applications, including VoIP, video conferencing, SANs, wireless, mobile, VPN, and many more with Maxwell Pro.

Solving Your Cloud Testing Challenges in PDF

Plug into Maxwell Pro’s powerful network emulation capabilities

When it comes to improving device performance in challenging conditions, there’s never been anything like Maxwell Pro to accurately emulate networks under adverse conditions.

Design and code reviews can only contribute so much to a product’s reliability. Eventually, the device needs to be exposed to near-real-world network traffic to see how it performs. Unfortunately, older methods of testing network devices—such as traffic generators, network emulators, and network simulators from the 1990’s — are too “coarse-gained”. They only operate at the packet level and are limited to packet operations like drop/lose, duplicate, delay, jitter and re-order.

Maxwell Pro’s network Emulation capabilities provide much finer grained control.

Maxwell Pro provides network, protocol, and packet level impairments

These capabilities are imperative for realistic testing of network-based applications and devices:

  • At the network level, Maxwell Pro can introduce standard, custom, coupled, and combinatorial network impairments.
  • At the protocol level, Maxwell Pro can intercept and change the characteristics of the protocol based on criteria, other network flows and other events.
  • At the packet level, Maxwell Pro can intercept and modify packet contents based on various conditions and events.

All of these capabilities can be usefully employed to accurately produce network simulations in the lab approximating real-world network conditions.

Historically, network devices were tested with primitive network impairment systems operating only on the packet as a whole. These systems could drop/lose, delay, duplicate, and/or re-order packets. That was all.

Demand greater granularity and fidelity

Today’s customers expect far greater granularity when emulating real-world networks. They expect that the real-world network they emulate in the lab will allow them to:

  • Initiate multiple concurrent network flows through the device under test, because real-world networks operate with multiple concurrrent network flows.
  • Introduce packet, protocol, and payload impairments, not just packet impairments, because real-world networks operate with impaired protocols and payloads, not just packets.

Maxwell Pro is designed from the ground up to help test engineers discover problems earlier, fix them, and release higher-quality products and applications. Its flexible, scriptable, programmable power enables an abundance of capabilities:

  • Send and receive packets from multiple devices
  • Delay, corrupt, drop, reorder, and create packets
  • Detect and track individual flows while remaining undetectable to other devices on the network
  • Intelligently test thousands of code paths, not just the most common paths, in a stateful manner
  • Simplify rigorous, repeatable, regression testing

With Maxwell Pro, product implementations can be tested in near-real-life conditions ranging from routine to extreme prior to release or large-scale deployment.

What do you want to accomplish today?

  • Check out performance under limited bandwidth?
  • Emulate a legacy protocol?
  • Determine application performance for branch office users?
  • Evaluate a video conferencing system under typical satellite conditions?
  • Select a Scenario to do it!

    Whatever the situation may be, one of Maxwell Pro's pre-defined scenarios can address it. Need modifications or changes? No problem. Maxwell Pro is fully customizable. Read More About Scenarios

    Maxwell Pro

    Find problems before anyone else does

    As network applications proliferate and users attach new types of devices to networks, the need for high QoS and better packet compensation algorithms increases. Through use of a network simulator,  you can discover hidden problems that only reveal themselves at the worst possible moments and fix them, saving time, money, and your reputation. Let us help add the Maxwell Pro Network Emulator to your lab!


    Package Specifications:

    See the Maxwell Product Brief in PDF pdf icon small for package options and specifications.


    Watch a Video

    Using Maxwell to Test TCP Congestion Avoidance

    Using Maxwell Pro Fluctuations


    Read a White Paper

    Are you allocating your test resources
    Allocate Resources
    Causes and Correlation of Network
    Rate Limiter vs. Bandwidth LimiterRate-Limitation-vs-Bandwidth-Limitation
    Limitations of ICMP Echo for Network Measurement
    Network Protocol Testing Overview
    Emulating 3G/4g Networks

    Want to Learn More about Maxwell Pro?

    Read More


    Technical Notes:

    General Tech Specs

    Standard Impairments:

    • Drop/Loss, Duplicate, Delay (latency), Rate Limiting, Jitter, Re-order, and/or Burst Errors

    Protocol Impairments:

    Protocol impairments test the ability of the destination device to respond properly to malformed and/or unexpected packets, and thus test the robustness and vulnerability of the device to security threats.  For example:

    • Change the source IP address to all ones (broadcast)
    • Remove all data from selected UDP packets (resulting in a malformed packet)
    • Append random data to the end of the message without adjusting Content Length
    • Create IPv4 or IPv6 fragments that contain missing or overlapping fragments

    Stateful Impairments:

    Maxwell performs stateful impairments.  Maxwell can track the conversation between two network devices over a period of time.  At a certain point in the protocol conversation, Maxwell can introduce an impairment to test if the receiving device responds correctly.  The TCP video is a good example.

    Since Maxwell examines both incoming and outgoing packets, more paths through the code can be tested and more network vulnerabilities and failures uncovered.

    In contrast to static packet filtering, in which only the headers of packets are checked, stateful tracking analyzes the entire packet, protocol and payload, and can make impairments based on intelligent criteria, helping the user uncover difficult bugs.

    User Programmable Impairments:

    The user can create his/her own customized network, packet, or protocol impairments and use Maxwell’s Plugin facility to add these impairments by creating a program in C or C++.   Sample templates are available.


    You can customize an impairment for a particular situation, e.g. legacy protocol

    Multiple Flows:

    Maxwell performs its standard, protocol, and user programmable impairments on multiple flows.

    A typical network device or application typically receives multiple flows of traffic concurrently.  These network flows originate from multiple sources.  Maxwell supports multiple flows concurrently to permit the user to apply different impairments to different sets of packets.  All of these variables are user selectable allowing you to quickly and easily create the problems your device will be exposed to in the real world.

    Multiple Flows

    Multiple Flows over Time:

    Standard, protocol, and/or stateful impairments can operate over minutes, days, or weeks.  The device's behavior could be sampled, before, during, and after this time period to determine if actual behavior was consistent with expected behavior.  Maxwell can apply a full range of statistical distributions to all these impairments over an extended time period.

    Easy Set-Up with Minimal Configuration:

    Since Maxwell operates like a bridge, you can quickly and easily set it up with your device(s).  Because it is not a router, you do not have to change your topology or reconfigure addresses.  There is no requirement for understanding complex routing protocol and configuration options.  Maxwell is completely invisible to your devices.

    Wide Range of Network Topologies:

    Maxwell can be used in a variety of network topologies, so you can set things up to replicate a customer's network, or to accommodate your lab environment.  Two Ethernet ports are provided for the bidirectional flow of traffic; the third Ethernet port serves as the control interface.

    Test lab set-ups can include LANs, WANs, VLANs -- tagged and untagged.  Example test configurations are available in the Maxwell User Guide.

    Single User - Multiple Flows:

    Maxwell handles multiple, concurrent, flows of network traffic.  Maxwell introduces its impairments while multiple devices concurrently send and receive packets.

    • There is no theoretical limit to the number of concurrent flows; Maxwell is only limited by available memory.
    • The graphical user interfaces offers two to 64 bidirectional flows.
    • More flows are available via plugins.

    Remote Access:

    • Command line interface
    • VNC remote control (allows you to view and interace with Maxwell using a VNC viewer)
    • Remote control and operation via programs written in Java, Perl, or Python
    • Remote access via Telnet or SSH

    Manipulating Contents of Headers and Payload:

    • Create a packet and selectively insert it into the flow
    • Dynamically create and change distinct flows of packets
    • Inspect packet headers to select packets for modification (ability to filter on any criteria)
    • Rewrite packet headers
    • Rewrite packet data
    • Select and modify packets based on:
    • The content of that packet
    • The content of predecessor packets
    • The content of packets in other flows
    • The mathematical model of the packet flows
    • The position in the protocol handshake

    Application Insertion:

    • Incorporate an application running inside Maxwell
    • Use that application to substitute for one end of the network flow
    • Examples include Asterisk (open source PBX)
    • Inject traffic as part of the internal application

    Alter Any Field Impairment

    With the Alter Impairment, engineers and quality assurance testers can replicate a specific fuzz test to verify the robustness of a network device. In fuzz testing, random bad data "fuzz" is sent to a network device. Some specific patterns of bad data will typically crash the device. The development engineer must correct the code in the network device and then replicate and repeat the specific patterns of bad data to make sure that the corrected code is now sufficiently robust and secure. With the Maxwell Alter Impairment, the development engineer can drill down and focus on the areas requiring correction.

    In addition, engineers can use the Alter Impairment to debug complex problems where the engineer has packet captures but not the original device (a form of capture and replay). Often problems occurring with a network device at a customer site can not be easily replicated. However, with packet captures and the Maxwell Alter Impairment, the problems can be reproduced in the lab for debugging and correction.

    Finally, the Alter Impairment allows engineers and quality assurance testers to create a new set of tests for a particular feature, without learning a programming language.

    Alter Impairment GUI

    During the network conversation the Alter Impairment can:

    • Insert or append bytes into a protocol packet's payload or header.
    • Remove bytes from a protocol packet's payload or header.
    • Find and remove specific IPv4, IPv6, or TCP options.
    • Rewrite any header field or payload bytes, such as source or destination IP addresses.
    • Automatically update protocol length fields after byte insertions and deletions.
    • Perform operations on byte strings inside the packet, such as addition, bit-wise "and", "or", and "xor".
    • Recompute all checksums upon the engineer's request.
    • Perform the alterations to a copy of the original packet and send the altered copy before or after the original packet - thus allowing insertion of entirely new packets into the network dialog.

    The Alter Impairment even understands tunneling - so, for example, a request to modify the first IPv6 datagram header will be performed even when that IPv6 datagram is tunneled inside an IPv4 datagram.

    Any Alter Impairments defined by an engineer may be saved and replayed at a future time.

    The Alter Impairment may also be combined with other standard impairments such as jitter, delay, re-ordering, etc.

    Compared with other commercial and open source tools (such as Scapy), the Alter Impairment:

    • Lets the engineer modify a live packet from a real-world network conversation; no need to create a new packet from scratch.
    • Supports "man in the middle" operation by sitting between two devices, intercepting the network traffic; it is not limited to creating a packet to send it to an end point.
    • Permits multiple, concurrent packets to be altered; operation is not limited to one packet at a time.
    • Operates via a point and click graphical interface; there is no requirement to learn a special programming language built on top of another programming language.
    • Keeps up with the flow of traffic for accurate network emulation; does not slow down and burden network operation.

    Packet Filters:

    Maxwell decodes or parses arriving packets so that you can filter the packets into different flows. Maxwell understands how to parse Ethernet headers, VLAN tags, MPLS labels, ARP messages, IPv4 and IPv6 datagrams, ICMPv4 and ICMPv6 messages, DHCPv4 and DHCPv6 messages, TCP and UDP network protocols, and several other protocols. This allows you to filter on the following packet characteristics:

    • IPv4 source address
    • IPv4 destination address
    • IPv6 source address
    • IPv6 destination address
    • TCP/UDP Source port
    • TCP/UDP Destination port
    • Protocol (any)
    • All packets / no packets
    • Source MAC address
    • Destination MAC address
    • MPLS label
    • VLAN tag
    • DSCP (Differentiated Services Code Point)
    • Bit Pattern anywhere in the packet
    • MAC Address
    • Apple talk
    • XNS
    • BACnet/IP

    Reports and Log Files:

    • Track the number of incoming and outgoing packets for each interface and each flow
    • User selectable packet details based on criteria
    • User selectable packet "fate" based on impairments (e.g. 17 packets were dropped)
    • Modifications applied to flows
    • Statistics per flow per interface
    • Optional date and time stamped for correlation with other systems and tools

    Statistical Application of Impairments:

    • As a function of predecessor packets (coupling)
    • As a function of a time interval
    • As a function of the packet arrival time withint the time interval (slew)
    • The extent of the impairments can be defined by the user:
    • The lower and upper limits of the start and end time
    • The type of statistical distribution
    • The type of deviation
    • The choice of piecewise or categorical functions

    Modification to Packets:

    • Unlimited modification possibilities via plugins
    • All packet filters can also be modified (see Packet Filters)
    • Special sets of protocol modifications (SIP, TCP, UDP, IPv4, IPv6, ICMP, DHCP) are available
    • Full fragmentation

    Packet Analyzer:

    • Industry standard "Wireshark" Network Protocol Analyzer
    • 759 protocols supported
    • Highlight and color packet summary information
    • All or part of captured network trace may be saved
    • Inspect data while session is in progress

    Packet Capture and Replay:

    • TCPdump (libpcap):
    • Capture and save packet data from a live session to a file
    • Read packets from the file rather than the network interface
    • TCPreplay:
    • User previously captured traffic in libpcap format
    • Classify traffic and rewrite Layer 2, 3, and 4 headers
    • Replay traffic back on the network
    • Replay at arbitrary speeds
    • Flowreplay - emulate a network client using a pcap file


    • Full support of jumbograms

    Flow Classification

    What is a "Network Flow"?

    A network flow is a sequence of packets from a source computer to a destination, which may be another host, a multicast group, or a broadcast domain.  Maxwell can "see" each packet and categorize these packets into flows, while imposing impairments on these flows.

    With Maxwell, the test engineer could place all domain name packets into one group, all SIP packets into another, all HTTP packets into yet another group, and put everything else into a catch-all category.

    Maxwell allows the test engineer to define criteria that divides the traffic flowing in either direction into groups of his choosing.  Those groups are "Flows".

    Why is it important to classify traffic into flows?

    Certain types of traffic that will appear on the test network are not appropriate and should not be included in the emulation. For example, ARP traffic or neighbor discovery traffic are not appropriate for a satellite emulation. Therefore, it is important to remove this traffic from the emulation via the classification/flow mechanism.


    Pattern matching of packet fields using the mask and compare method.

    Maxwell provides the user with a wide variety of pattern matching tools so that the fields in packet headers and even packet data can be examined and used to decide whether a given packet belongs to a particular flow or not.

    Thus, for example, a user may use fields from IEEE 802 headers, IPv4 or IPv6 headers, UDP or TCP headers, or even UDP or TCP data as a means of selecting packets for inclusion into a given flow.

    Most of Maxwell's flow pattern matching tools use a simple technique called "mask and compare".

    The mask and compare technique considers every header field of a packet to be a binary number.  Depending on the particular field that number may range from a few bits to as many as 48 bits.  For example, IEEE 802.1q VLAN Priority field is only 3 bits wide while an IEEE 802 MAC address is 48 bits wide.

    Masks and values are expressed in network byte order.  In other words the numbers that the user provides for mask and value will be converted into "Big Endian" format and then applied to the packet data.

    Note: IEEE MAC addresses are expressed by the user in the conventional format consisting of 12 hexadecimal digits, with optional colons or spaces as separators.  However, unlike IETF defined packets, each byte of the Ethernet/IEEE MAC address is transmitted low-order bit first.  This means that for MAC addresses the Group address bits are the low order bits of the first octet rather than the high order bits.  (Click here for more information about Mac Address Bit Ordering.)

    In mask and compare expressions the ones bits in the mask indicate the bits in the packet field that are of interest; the zeros bits in the mask indicate that the corresponding bits in the packet field are of no concern and play no part in the calculation.

    When evaluating a mask and compare expression, Maxwell uses logically "AND"s the bits of the mask against the bits of the packet field.  The result is then compared with the value that the user has provided.  If there is an exact match then the express is considered "true", otherwise it is considered "false".

    Supposed you want to define a mask and compare expression that will pick up packets with source IP address of 192.168.1.xx where xx is any value.  (This should feel similar to the way in which IP subnets are defined; the principles are the similar.)

    In hexadecimal the IP address is 0xC0.0xA8.0x01.0x00 (in binary this is 11000000.10101000.00000001.00000000.)

    So you would define a Mask of 0xFFFFFF00 (i.e. a binary value consisting of 24 ones followed by 8 zeros) - meaning that you are interested in the first 24 bits of the IP address.  And you would define the comparison value to be 0xC0A80100.

    For another discussion of masking and comparing bits see Mask (computing).

    Image Image Image

    In Maxwell there are many possible mask and compare expressions.  Typically a user will enable only a few of these and leave the remaining expressions inactive.

    Different mask and compare expressions may be defined for each separate flow.  In this way a user can, for example, select DNS (UDP port 53) packets into one flow and HTTP (TCP port 80) packets into another.

    Stateful matching

    Maxwell can go further than simple pattern matching.  If a user wants to classify packets based on some relationship, for example the first TCP connection after a DNS response, or the first RTP packet after an RTP packet with an "M" bit in its header, then the user can do so through user written software "plug in".  Plug-in code, however, operates after packets are classified into flows by the mask and compare expressions.

    How are incoming packets classified into a flow?

    Maxwell supports multiple flows. The number of flows is always an even number. Half of the flows are for packets flowing in one direction and the other half of the flows are for packets flowing in the reverse direction.

    Maxwell infers the direction of a packet's flow from the interface on which that packet was received. Incoming packets are sorted, using the mask and compare expressions, into flows using a waterfall technique.

    • If the packet arrived on interface 0 then it is considered to be flowing in the Interface 0 to interface 1 direction.
    • If the packet arrives on interface 1 then it is considered to be flowing in the other (interface 1 to interface 0) direction.
    • Based on the direction the list of flows appropriate for that direction is selected and used in the following steps.
    1. The first flow is selected as a candidate.
    2. The packet is evaluated against the active match and compare expressions that are defined for the candidate flow.
    3. If all of the active expressions return a "true" answer the packet be accepted into the candidate flow and the flow selection process will end.
    4. If the packet is not accepted into the candidate flow the next flow will be selected as the new candidate and the process will continue from step #2, above.  If there are no more flows, then the packet is simply discarded.

    Impairment processing begins when a packet is accepted into a flow.  That impairment processing is described elsewhere.  However it should be noted that just as distinct and different packet acceptance criteria may be defined for each flow, distinct and separate impairment criteria may be defined for each flow.

    Standard Impairments

    This technical note describes both Maxwell's "Standard Impairments" and the means for automating them.

    Standard Impairments are those network impairments that are built into the core of Maxwell without the need of any plugin code.  As a packet flows through Maxwell it passes through the impairment stages in the following sequence:

    1. Packet Drop
    2. Packet Duplication
    3. Fixed Packet Delay (same delay on every packet)
    4. Variable Packet Delay (jitter) and Reordering
    5. Rate Limitation
    6. Alter Impairment
    7. Bit Corruption
    8. Plugin (if any)

    Every packet, including those created by duplication, passes through all of those impairment stages.

    Burst (Coupled) Behavior

    Most of Maxwell's Standard Impairments can be configured to create bursts, i.e. a sequence of impairments that endures for a period of time.

    Maxwell uses the term "Coupled" rather than "burst" to clarify the fact that the impairment of a subsequent packet may be coupled to the impairment that was imposed on a prior packet.

    Most of Maxwell's standard impairments can be configured to operate in a coupled/burst mode.  The burst behavior for each impairment is separate and independent of the burst behavior for any other impairment.  And the burst behavior for a particular impairment is independent across flows.  In other words, the packet drop burst calculations in Flow X are independent from the packet drop burst calculations in Flow Y.  And burst activity for packet delay is independent for burst activity for packet jitter.

    The user may enable or disable impairment coupling (bursting) on individual impairments.  If coupling is disabled then each packet is an independent event and the treatment of each packet is independent of the fate of its predecessor packets.

    Maxwell remembers what it did to the previous packet that passed through the impairment engines.  Thus, for example, Maxwell remembers whether the previous packet to pass through a flow was subjected to a delay impairment and, if so, how much delay was imposed onto that packet.  Maxwell also remembers the arrival time of that prior packet.

    If enabled for a particular impairment Maxwell's coupled/burst processing begins by asking whether the prior packet in the flow was subjected to the particular impairment.  In other words, Maxwell's coupled/burst processing only begins when the preceding packet in the flow has been impaired.  Thus, for example, a packet drop burst only begins when a packet is dropped by the non-burst drop mechanism.  The same holds true for the other impairments - the coupled/burst behavior begins only when a packet receives an impairment though the operation of the normal, non-burst mechanisms.

    If enabled, the decision whether to perform coupled/burst processing operates as follows:

    if not (prior_packet_exists() and prior_packet_impaired()):
    time_from_prior = prior_packet.recv_time - current_packet.recv_time
    if time_from_prior > coupling_interval:

    As can be seen from the foregoing code snippet in order for coupled/burst processing to occur the preceding packet must have been impaired and the current packet must arrive within a user specified time window after that preceding packet.

    If the preceding code decides to perform coupled/burst processing then that burst processing proceeds.

    Like non-burst impairments, coupled/burst impairments are controlled by a probability - The user sets a probability giving the statistical chance that a given packet will be subjected to the impairment.  Maxwell uses a random number function to chose whether any given packet will receive the impairment or not.  The user sets a coupled/burst probability that is independent of the probability for the underlying impairment.  If a packet is to be processed normally, the basic probability is used, if it is to be processed using the coupled/burst mechanism, then the coupling probability is used.

    Maxwell allows the user to modify the basic coupling procedure by indicating that the coupling probability should be reduced from full effect to no effect over the period of the coupling interval.  This is called "slew".  If, for example, slew is in effect, then if the current packet arrives directly after the preceding packet, i.e. if the inter-packet gap is zero, then the coupling priority is used without diminishment.  If the packet arrives half way through the coupling interval then the coupling probability is cut in half.  The coupling probability diminishes to zero at the end of the coupling interval.

    The impairment that is applied to a packet as the result of coupling/bursting is the same impairment as was applied to the preceding packet.

    Since duplicate packets are created and have no arrival time, there is no coupling interval (or slewing) for the packet duplication impairment.

    The net effect of this coupling/burst processing is to create a chain of probabilities - a Markov chain - that creates a burst impairment for as long as the sequence of packet arrivals falls within the coupling interval and the roll of the probability dice yields decisions to impose the impairment.

    In a typical scenario, the user sets a low base probability for a particular impairment, often only a few percent (or lower).  However, it is usual to set a high coupling probability - 70% or even 90% are not unusual.  Even at 90% a burst is likely only to last an average of 5 packets.  A coupling probability of 100% would make an impairment that, once started, would endure as long as packets keep arriving within the coupling interval.  (The duplication impairment has a ceiling of 90% because in the case of duplication, all duplicates arrive, by definition, within the coupling interval.)


    Parameter Automation

    Maxwell's Graphical User Interface (GUI) can automate the changing of impairment parameters over a period of time ranging from a tenth of a second to more than a week.  The user can shape this automation to emulate impairments that change over time.  For example, the user could automate the delay impairment so that the delay increases over several minutes and then sharply falls back to a low value.  This would be useful for testing a TCP stack's ability to detect and handle increasing congestion and increasing RTT (Round Trip Time) and to recover when conditions go back to normal.

    Probabilities are not deterministic

    Maxwell's standard impairments are stochastic.  One can not tell in advance whether a given packet will be impaired or not.  But over a large number of packets the percentage of packets impaired will tend to approximate the impairment probability that the user has selected.

    If two identical streams of packets are sent through Maxwell it will be unlikely that every packet in the replay will be impaired in exactly the same way as the same packet in the first stream.  But if the streams contain enough packets the statistical results will be similar.


    Packet Drop

    Packet drop does exactly what its name implies - it makes a packet disappear.

    A dropped packet does not go through the subsequent impairments.

    The screen shot on the right shows Maxwell imposing a drop that increases from zero over a period of several seconds, holds steady for a while, and then descends back to zero.

    (Note: This kind of automation of drop over several seconds is a low frequency kind of change to impairments.  It should be distinguished from the higher frequency kind of rapid change in delay that is performed by Maxwell's jitter impairment.  These two methods of changing delay do overlap in part, but in general the automation system is for changes that occur over time scales of seconds to days while the jitter variation is usually for changes that occur on timescales of less than a second.)


    Packet Duplication

    Maxwell's packet duplication creates an exact duplicate of a packet.

    The duplicate packet is initially scheduled to be transmitted one millisecond after the packet from which it was created; however the actual times of transmission of the principal packet and the duplicate may be affected by their passage through the subsequent stages of impairment processing.

    The duplicate packet is sent back to the head of the impairment sequence.  In other words, the duplicate packet will face the full sequence of drop, duplication, delay/jitter, and rate limitation impairments.

    Delay, Jitter, and Jitter based Packet Reordering


    Maxwell does packet delay in two parts:

    • Fixed delay: A user defined amount of delay. 

    • Jitter: A variable amount of delay computed using user specified parameters.  

    These two parts are added together.  Thus if a packet receives 100 milliseconds of fixed delay and a variable/jitter delay of 80 milliseconds, the packet will be delayed by 180 milliseconds.  (The actual amount may be longer if the user has not allowed packet reordering, in which case a packet must wait for its predecessors to be sent even if its scheduled transmission time expires before theirs.)

    (Remember, delay and jitter are applied only to those packets that are selected by the stochastic (probability) base and coupled/burst mechanisms.)

    Maxwell delays packets by computing the time when they should be transmitted from the outbound interface.  This scheduled transmission time may be affected by subsequent impairments (most particularly rate limitation and a user provided plugin.)

    The order in which packets are transmitted is based on the scheduled transmission time.  However, unless packet reordering is permitted by the user, each packet must wait for its predecessors to be transmitted even if its own scheduled transmission time is earlier.

    For both fixed and variable delay (jitter) the burst/coupled behavior is to send the coupled packets with the same delay (whether fixed or variable) as the predecessor packet.

    Jitter in more detail

    Jitter is variable delay.  That simple idea is complicated by the question of how that variation should occur.

    When we say "variable delay" we mean that the delay on each separate packet may be different from any of its predecessors or successors.  Thus the question of how to shape the variation is one of the statistical "curve" that describes, over a large number of packets, how many packets are expected to receive each possible delay value.

    Maxwell builds jitter using three basic statistical building blocks.  (For more information on these, and other, statistical distributions, see Probability distribution.

    • Fixed value - every packet receives the same delay.

    • Uniform distribution - Over the range of possible delay values it is expected that a roughly equal number of packets will receive each possible delay.  In other words, a flat distribution.

    • Gaussian - This is the familiar normal bell curve.  More packets are expected to receive the statistical mean delay value.  As one moves the delay further above or below that mean fewer and fewer packets are expected to receive that delay.

    Complex distributions of jitter variation are constructed using a piecewise function in which the above elements are combined.


    Piecewise Functions

    A piecewise function is a way to assemble several of the basic distributions.  A piecewise function could be used, for instance, to create a jitter pattern in which an average of 15% of the packets are delayed according to a bell curve with a mean of 100ms and a std deviation of 20ms, 20% of the packets get hit with a delay of 250ms, and 30% are delayed uniformly between 300ms and 400ms, the rest going through without jitter.  This allows the user to create patterns that resemble the real-world internet; a world in which there are multiple causes of perceived impairments.

    A user creates a piecewise function by selecting the various pieces to be included: perhaps a couple of Gaussian curves, perhaps a few uniform distributions, and maybe a constant value or two.  The the user creates relative weights (or "width") for these pieces.  When a packet arrives Maxwell generates a random number, a kind of toss of the dice, to chose which of the pieces should be used for that packet.  The chance that any piece will be used is relative to its weight/width.  A piece that has twice the weight/width of another piece has twice the chance of being selected.

    Then the packet is jittered according to the selected piece.


    Maxwell does packet reordering as a side effect of the introduction of variable packet delay (jitter.)

    User written plug-in code can also do packet reordering (or even packet modification and generation.)

    When a packet is jittered it is very possible that, if it is given a small amount of delay, that it might want to be transmitted before one or more previous packets that are still awaiting transmission because they have been given a large amount of delay.

    Maxwell has a per-flow option that allows subsequent low-delay packets to pass those waiting long-delay packets.  This is reordering.

    Note that this reordering is done in the context of each flow.

    If the user does not allow jitter in the flow to cause reordering then a packet that would otherwise go out sooner is constrained to wait until its predecessors in the flow have reached their transmission time and have been sent.

    Rate Limitation

    Maxwell's rate limitation system is rather more intricate than the typical token bucket queue.  Maxwell gives the user the means to control many of the parameters that affect rate limitation.


    Maxwell, the intelligent network emulator, rate limitation mechanism.

    The rate limiter slows down transmission of packets so that they exit the opposite interface at a user specified effective bit rate. While no one packet is actually transmitted at the requested rate, the packets are spaced so that the time span encompassing two or more packets equals the requested bit rate.

    The rate parameters control the transmission so that, on average, no more than the given rate in bits/second is transmitted out the opposite interface (note that a rate of zero disables rate impairment). When an Ethernet frame is received, only the bits in its data section are included in the rate computation; the frame preamble, header, FCS, and so on, are ignored. To accurately compute the packet delays, the number of overhead bits in the emulated outgoing link layer needs to be included in the rate computation. To calculate the number of such overhead bits, the following aspects of the emulated link layer must be provided: the minimum and maximum payload bit size and the average number of bits in the emulated link layer's headers and tails, if any. To emulate discards properly a value for the maximum emulated transmission queue length (in bits, not bytes) must be provided. Lastly, for highest fidelity the actual measured transmission rate between Maxwell and the final endpoint is entered in bits/second and actual measured transit delay is entered. Note that setting the actual rate to zero excludes both the actual rate and actual transit duration from the rate computations.

    Note that actual rates are likely to be 10M, 100M, and 1000M bits/second. Typical actual transit delay through Maxwell for a packet is typically under 20 microseconds, though it can vary depending on any processing delay due to a loaded plugin. As an example, on a 100M Ethernet link the actual rate you would enter into the actual rate field is 100,000,000 and 0.00002 in the GUI (or 20 when using the Remote API) for actual delay.

    PlugIn Impairments

    Plugin based impairments are an extension to, but not part of, Maxwell's "Standard Impairments".  The effects of a plugin depend on which particular plugin (if any) is loaded.

    A plugin is the last stop that a packet makes as it flows through Maxwell's impairment system; in other words, the standard impairments are all performed before a packet reaches the plugin.

    Automation of the Standard Impairments


    This technical note describes how to vary an impairment over a period of time with Maxwell, the intelligent network emulator.

    For example, a user might want to emulate the effect of a tree that periodically is blown by the wind across a microwave network link.  Or one might want to emulate a slowly degrading path that, perhaps due to a routing change, suddenly becomes good.  (This latter scenario is useful when testing implementations of TCP congestion detection and recovery software.)


    This screen shot shows an automation of a delay that causes increasingly more intense spikes of delay over an 8 second period and then repeats.

    Maxwell's graphical user interface contains a very flexible tool that allows nearly every impairment parameter to be varied every tenth of a second over periods of time ranging from a 0.1 seconds to more than a week.

    Any of the numeric fields in the standard impairments may be varied over time, whether the numeric field is a percentage, a time value itself, a rate, number of bits, or some other unit. You have a choice of three different ways of telling Maxwell how it should vary the parameter over time:

    • A simple pulse model that requires entry of 6 numbers. The value is changed over time by first holding at a user defined "baseline" value for a user defined period of time (the "lead time"), followed by a rise (or fall) to another value (the "target value") over another period of time (the "onset time"), remaining at the target value for a while (the "hang time") and ending by falling (or rising) to the original baseline value over a final period of time (the "fall time"). Several pulse shapes can be created this way, including triangle, saw-tooth, and square.
    • Using an algebraic equation. An example would be varying transmission latency (delay) using a simple sine wave be entering this equation: y = 0.75*(1 + sin(2*pi*t/5)). This would vary packet delay from 0 to 1.5 seconds every 5 seconds.
    • By entering a list of time/value pairs that can be made to replicate within reasonable tolerances any variation conceivable. This can be used when neither of the other two mechanisms can be made to vary the value in the way desired. However, in extreme situations it may require entry of a great many pairs of numbers.


    Maxwell Rate Limitation Mechanism


    The rate limiter slows down transmission of packets so that they exit the opposite interface at a user specified effective bit rate. While no one packet is actually transmitted at the requested rate, the packets are spaced so that the time span encompassing two or more packets equals the requested bit rate.

    The rate parameters control the transmission so that, on average, no more than the given rate in bits/second is transmitted out the opposite interface (note that a rate of zero disables rate impairment). When an Ethernet frame is received, only the bits in its data section are included in the rate computation – the frame preamble, header, FCS, and so on, are ignored. To accurately compute the packet delays, the number of overhead bits in the emulated outgoing link layer needs to be included in the rate computation. To calculate the number of such overhead bits, the following aspects of the emulated link layer must be provided: the minimum and maximum payload bit size and the average number of bits in the emulated link layer's headers and tails, if any. To emulate discards properly a value for the maximum emulated transmission queue length (in bits, not bytes) must be provided. Lastly, for highest fidelity the actual measured transmission rate between Maxwell and the final endpoint is entered in bits/second and actual measured transit delay is entered. Note that setting the actual rate to zero excludes both the actual rate and actual transit duration from the rate computations.

    Note that actual rates are likely to be 10M, 100M, and 1000M bits/second. Typical actual transit delay through Maxwell for a packet is typically under 20 microseconds, though it can vary depending on any processing delay due to a loaded plugin. As an example, on a 100M Ethernet link the actual rate you would enter into the actual rate field is 100,000,000 and 0.00002 in the GUI (or 20 when using the Remote API) for actual delay.

    Use your application in the Maxwell Environment

    An easy way to incorporate your application for testing in the Maxwell Test Environment is to install and execute your application on Maxwell.   Traffic flowing between your application and other devices will be impaired by Maxwell.

    For example, for Voice over IP testing it is possible to load a soft phone or proxy or even a full PBX onto Maxwell so that it can act as one side of traffic.  The traffic will then flow through Maxwell to a destination such as a conference VoIP phone or other device.  

    MaxTap creates a virtual network interface called "maxtap". This virtual interface is like any real network interface - it can have an IP address and IP packets can be routed through it.

    Unlike physical interfaces, however, MaxTap  serves as one of Maxwell's two ports. The other Maxwell port is attached to another device or to the lab network.

    When an application sends IP traffic, a Maxwell process examines the destination address and, if the routing tables indicate that the destination is to be reached via the MaxTap interface, the IP packets are delivered internally to Maxwell. Maxwell, in turn, processes those packets and sends the resulting traffic out the opposite Maxwell port.

    Want to Learn More about Maxwell Pro?

    Contact an Expert

    Read More




    Q What kind of impairments can I do with Maxwell?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

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


    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.


    SimITU-T G.1050ulators 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.


    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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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?

    A 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.



    Want to know more about Maxwell Pro?

    Read More
    Apple products are used in a wide variety of customer environments; we use the Maxwell Network Emulator to mimic those customer environments.  We know that everyone's network connection is different, from a 20Mbps cable link with 15ms latency, to a 768Ksatellite link with up to 1.5s RTT.  By emulating these different situations in combination with testing various models of consumer Access Points, we can be assured that customers have a solid experience when they get new Apple software or hardware in their hands.

    In addition to this, we use various impairment tools in the Maxwell emulation suite to make sure that reasonable amounts of dropped or modified packets do not have an adverse affect on communication between devices. Visit Apple on the web at

    Dmitry Halavin, Apple Computer

    I am happy with the InterWorking Labs solution because I can just use it and it works!
    Lars Voelker, BMW
    We looked at a number of products, but selected Maxwell because of the ability to create custom impairments and custom filters.  This is very useful in our testing environment.

    Engineering Manager, Thomson Technology

    Maxwell allowed us to emulate very slow links for an aviation test.  We emulated network traffic travelling from a ground location to air traffic control tower to a satellite and back again.

    Prototype Engineer, Aerospace Manufacturer
    Maxwell TCP/IP, Interworking labs, Maxwell Network Emulator



    I love the way you can customize the tests.

    Michael MacFaden, Software Engineer, VMWare 

    For your information: We have now gone through all [the Maxwell TCP/IP] fragmentation tests and our stack failed more then 50% of them. We have found 12 individual bugs in the stack so the Maxwell TCP/IP Test Suite certainly does a good job :-).
    Lead Engineer, Swedish Aerospace Contractor

    Telit Wireless Solutions,, uses the Maxwell TCP/IP Test Environment to validate the performance of the IPEasy feature (embedded TCP/IP stack), reproducing critical TCP/IP scenarios coming from field trials and stressing GPRS and UMTS connections to GSM/GPRS/UMTS modems. Telit has integrated Maxwell Emulation into its test process connecting Maxwell to an Agilent 8960 test set. We have found the Maxwell TCP/IP tests a valuable addition to our test environment.
    SW Protocol Stack Manager, Telit Wireless Solutions

    We use Maxwell to filter and emulate BACnet/IP traffic in order to pinpoint issues and problems at our customer's sites.   Using Maxwell has saved us hundreds of thousands of dollars in labor and equipment as we can faithfully emulate a customer site without re-creating the customer network.
    Test Manager, Trane

    As the world leader in IP video management, Verint's Software Test Group was in search of a network tool that would allow us to simulate the harsh, and some times unpredictable, impairment conditions of real world network scenarios with IP video solutions. We were very fortunate to discover the Mini Maxwell. The Mini Maxwell tool is a unique testing solution that is easy to operate and extraordinarily cost-effective. It enabled us to emulate real-time effects of various network conditions such as packet loss, latency, and bandwidth, helping us detect and work to resolve any problems we find well in advance during our development process, assuring optimal performance from the end-user perspective. The Mini-Maxwell is now an important, integral part of our test lab.
    Bill Koufalis, Verint Video Intelligence Solutions, Team Lead, Software Testing Group

    We chose SilverCreek because the quality of the SNMPv3 tests, the test coverage, and the customer support were far superior to all the other products we evaluated. It was also easily extensible to provide proprietary test coverage.The SilverCreek SNMP test tools allowed us to move from a manual testing process to full SNMP test automation.
    John Scano, Software Development Manager, Juniper Networks, Inc 

    This de-facto industry standard, SilverCreek, guarantees a fast, easy-to-use and reliable verification of the SNMP-implementation.

    Luc Martens CEO, Excentis (Formerly tComLabs), the Euro-DOCSIS Certification Testing Lab 
    I found the SilverCreek tests very robust and exhaustive. In addition the rich set of APIs for SNMP and MIB test automation were very useful. 

    I want to give thanks specifically to the support team for the excellent and fast support provided. There response was unbelievably fast, bugs submitted were acknowledged and the feedback was proactive.
    Abhijit Parekh of Infosys 

    We use SilverCreek to automatically validate the correctness of our SNMP implementation including our private MIB. We have integrated SilverCreek into our test process and automation framework for both functional and regression testing. We really like its debugging and packet capturing capabilities as well as its scalability; our test engineers utilize all the features of SilverCreek including customization. It is the perfect product for Matisse Networks.
    Prabhat Mishra, VP of Engineering, Matisse Networks 

    We use SilverCreek to verify SNMP and MIB functionality, compliance, conformance, and performance. By using the extensive script library and automation tools, we have reduced both the manpower and the time required to complete our test plans (from 960+ man hours to 160 man hours). We test 24/7 without user interaction.
    R. Stovall and B. Kaluza, Software Engineers, Wind River Systems 

    SilverCreek has been an invaluable tool in debugging our SNMPv3 agent.
    Alan Luchuk, Software Engineer, SNMP Research 

    We are very pleased with the pre-defined testing scripts that came with SilverCreek. Using these scripts we were able to test and verify our compliance to the SNMP protocol and conduct extensive syntactic checking. We also wanted to do specific functionality testing on our Radio's MIB implementation, including testing for proper loopback and locking. Because the pre-defined scripts were well written and clearly documented, we could easily modify them and customize them for our specific functionality testing. In addition, we were very impressed with the Developer's Guide that defined the SilverCreek APIs and architecture providing us everything we need for our requirements now and in the future.
    Canh Nguyen, Senior Software Quality Engineer, Stratex Networks 

    We have integrated SilverCreek into our test process and use its facilities for tracking our test results for regression testing. We love its debugging capabilities and its scalability; our junior test engineers can use the novice features, and our senior engineers do customization. It is the perfect product for Terayon."
    Dave Salmon, Manager of Software QA, Terayon 

    We selected SilverCreek from InterWorking Labs for three reasons: (1) the company's reputation - InterWorking Labs is a well known and established company in the area of SNMP testing; (2) the committed, direct and professional marketing and technical support that InterWorking Labs offered during the evaluation period, and (3) the SilverCreek tool, which is a stable and robust application that suits RAD's complex needs. 
    In addition to the obvious employment of the tool for establishing compatibility with the SNMP standard, RAD also uses SilverCreek to verify that the full and the accurate scope of SNMP support (in relation to all the MIB variables that should be "included" or "excluded") is implemented by the agent. SilverCreek ensures it is done efficiently using one of its tests that detects objects defined in the loaded MIBs but are not returned by the agent during the MIB Walk.
    Gadi Ziv, Director of R&D, System-Tests at RAD Data Communications 

    Great for Emulating Mobile Networks

    At Validus Medical Systems we develop mobile applications for healthcare and we've used Mini Maxwell for many years to emulate various cellular networks from the comfort of our offices.

    Our QA department is able to quickly test with a variety of emulated cellular conditions. Our developers are then able to reliably reproduce those conditions for debugging. We don't use it every day, so it's important to us that it be easy and obvious to set up and configure. We can do that from a few concise setup pages.

    We're very happy to have Mini Maxwell in our toolbox.
    Craig Watkins, Validus Medical Systems


    Want to know more about InterWorking Labs' Products and Solutions?

    Contact an Expert

    Read More


    Click here to read the full reportMaxwell KMAX family compare versions



    Want to know more about the different versions of Maxwell?

    Contact an Expert

    Read More