Contact Us
+1.831.460.7010

Maxwell Pro Network Emulator and Protocol Tester


 

Maxwell Pro:  The Engineer's Network EmulatorTM

maxwell-pro-product
 

General:

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

Other:

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

waterfall


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 192.168.1.00 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()):
perform_nonburst_processing()
else:
time_from_prior = prior_packet.recv_time - current_packet.recv_time
if time_from_prior > coupling_interval:
perform_nonburst_processing()
else:
perform_burst_processing()

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

Image

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.

Image

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

Image

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

ImageImage

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.

Image

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.

Reordering

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.

Image

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

Image

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

Image

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

Image

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

Not sure what you need?

Client Reviews

 

With Maxwell we emulated network traffic from a ground location to an air traffic control tower to a satellite and back again.

 

-Software Engineer
Aerospace Manufacturer