Version 0.2
Date: 10/14/05

What Is MaxTap?

MaxTap is a way to use the Maxwell computer as a source or sink for network traffic.

In the absence of MaxTap it is necessary to physically impose Maxwell between two network segments so that the traffic passes through Maxwell.

MaxTap eliminates the need to interpose Maxwell between two network segments. Instead, with MaxTap, the user can run an application on the Maxwell computer and cause traffic flowing between that application and other devices to flow through the Maxwell engine.

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 that is to flow through Maxwell.

MaxTap works by creating 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, the maxtap interface serves as one of Maxwell's two ports. The other Maxwell port, as is normal is attached to one of the physical interfaces on the computer.

When an application sends IP traffic the underlying Linux kernel 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 opposite Maxwell port.

Creating a MaxTap

A MaxTap is created using the "-T" or "--tap" command line options to the standard impairment server (stdiserver). The parameter to these options is either "0" or "1" indicating whether the MaxTap is to be used as Maxwell's PORT0 or PORT1.

The following examples are equivalent. Both would cause a MaxTap interface to be created (with the interface name of "maxtap") and used by Maxwell as its PORT0.

stdiserver --tap 0

stdiserver -T 0

A MaxTap must be configured after it is created and before it is used to convey traffic.

Physical Topology

MaxTap is sensitive to the physical network topology in which it is used.

It is anticipated that MaxTap will be used in a topology such as the following. The difference between Figure 1 and Figure 2 is that in Figure 1 Maxwell's control port is attached to the local subnet while in Figure 2 it is attached to a remote subnet.

The topology of Figure 2 is preferred over that of Figure 1 because it eliminates some potential DUT confusion due to ARP replies coming from Maxwell’s control interface in reply to ARP queries for the MaxTap address.

            +-------------------+
|     MAXWELL       |
|                   |
|  +-------+        |
|  | Local |        |
|  |  App. |        |
|  +-----+-+        |
|        |          |
|     MaxTap/       |
|      PORT0        |
|                   |
+---+---------+-----+
|eth0/    | eth2/
|Control  | PORT1
+----------+    |         |
|  Local   |    |         |
|  Router  +----+---------+--+------+--... (local subnet/
| (default |                 |      |       Broadcast domain)
| gateway) |                 |      |
+---+------+                 |      |
|                        |      |
|                        |      |
|Remote subnets        DUT-1  DUT-2   (Local Devices
|                                      Under Test)
|
+---DUT-3
|          (Remote Devices Under Test)
+---DUT-4
|
|
+--------+
| Router +---- Internet services (DNS, NTP, etc.)
+--------+

FIGURE 1
Sample Configuration With Maxwell’s Control Port Attached to the Local Subnet

                 +-------------------+
|     MAXWELL       |
|                   |
|  +-------+        |
|  | Local |        |
|  |  App. |        |
|  +-----+-+        |
|        |          |
|     MaxTap/       |
|      PORT0        |
+------------- +                   |
| eth0/control |                   |
|              +-------------+-----+
|                            | eth2/
|                            | PORT1
|  +----------+              |
|  |  Local   |              |
|  |  Router  +--------------+--+------+--... (local subnet/
|  | (default |                 |      |       Broadcast domain)
|  | gateway) |                 |      |
|  +---+------+                 |      |
|      |                        |      |
+------+                        |      |
|Remote subnets        DUT-1  DUT-2   (Local Devices
|                                      Under Test)
|
+---DUT-3
|          (Remote Devices Under Test)
+---DUT-4
|
|
+--------+
| Router +---- Internet services (DNS, NTP, etc.)
+--------+

FIGURE 2
Sample Configuration With Maxwell’s Control Port Attached to a Remote Subnet

Figure 1 and Figure 2 are merely general representations. In actual practice the details may vary:

A. Maxwell's eth0/Control interface may not be connected at all. This is probably an unwise thing to do because both Maxwell and the locally hosted application probably will need to make use of network services, particularly DNS.)

B. The roles of MaxTap/PORT0 and eth2/PORT1 may be different than shown. The following pairs are all valid combinations that can be established through various combinations of the command line parameters to the Maxwell standard impairment server.

• MaxTap/PORT0 and eth1/PORT1

• MaxTap/PORT0 and eth2/PORT1

• MaxTap/PORT1 and eth1/PORT0

• MaxTap/PORT1 and eth2/PORT0

For convenience (and to avoid confusion) all the examples here will use the MaxTap/PORT0, eth2/PORT1 combination. That combination is established with the "--tap 0" (or "-T 0") command line parameter.

If not overridden by command line parameters Maxwell will associate eth1 with PORT0 and will associate eth2 with PORT1.

C. There may be a greater or smaller number of devices under test than shown in the diagram.

D. There may be DHCP and other internet services available on the local subnet or on the remote subnets.

E. There may be no connection to the internet at all. In that case all necessary network services must be provided locally. There may be a temptation to use the Maxwell computer as a host to provide those services, however, that requires expertise in system administration and may significantly reduce the reliability of the Maxwell impairment system even to the degree of rendering it inoperable. In other words, it is strongly recommended that the Maxwell computer not be considered for network services other than as a host for the locally hosted application that is to use the MaxTap.

Because network devices often require ancillary services, such as DNS, DHCP, or NTP, to work MaxTap is not expected to be used in a network topology in which there is no network path from the devices under test to those services. In particular, because Maxwell is not configured to act as a router, devices under test should not anticipate reaching network services via Maxwell's MaxTap mechanism.

Configuring a MaxTap

This configuration discussion presumes the network topology shown in Figure 1.

Before any traffic can flow between a locally hosted application and the MaxTap the MaxTap must be configured with an IP address, subnet mask, and optional routes.

Root privilege is usually required to configure the MaxTap.

The MaxTap takes the role of Maxwell's PORT0 or PORT1. That means that if the MaxTap is used as PORT0 then PORT1 is a physical port that is physically attached to some subnet. For purposes of discussion we'll refer to the PORT that is not the MaxTap port as "the opposite port". Thus if MaxTap was created using the "--tap 1" command line parameter, the opposite port would be PORT0.

From a conceptual point of view, the MaxTap will be an extension of the opposite port.

In Figure 1, the "opposite port" is eth2/PORT1.

We want to give the MaxTap an address and subnet mask that is appropriate for the subnet to which that opposite port is attached. Again, using Figure 1 as a reference, we want to give the MaxTap an address that is appropriate for (and unused on) the local subnet.

The easiest way to do this is to give the MaxTap an IP address and mask that defines a one-host subnet, i.e. a subnet with a 32-bit subnet prefix (also known as a /32.) Host routes can be later added to indicate to the operating system that packets to those hosts should be sent via the MaxTap.

CAVEATS: On Linux, the operating system on which Maxwell is constructed, changes to the MaxTap address or mask is likely to cause any routes that have been defined to use the MaxTap to disappear. Similarly, the user should anticipate that all such routing information will also disappear when the Maxwell impairment server is terminated or restarted.

Steps To Configure the MaxTap:

1. Ascertain the subnet address and mask for the subnet to which the opposite port is attached.

In Figure 1 this would be the address and mask of the "local subnet".

In the steps below the examples use the subnet address of 192.168.1/24 (i.e. a subnet ranging from address 192.168.1.0 through 192.168.1.255 with a netmask of 255.255.255.0.)

2. Ascertain a free IP address on the local subnet.

3. Configure the MaxTap with an IP address and subnet mask.

The IP address will be the free IP address ascertained in step #2 above.

The netmask depends on whether Maxwell is configured per Figure 1 or Figure 2.

If configured per Figure 1, then we will configure the MaxTap to be a one-host subnet within that larger subnet.

For example, if the opposite port is attached to a subnet with defined as 192.168.1/24 and you want the MaxTap to have address 192.168.1.50 then use the following command:

ifconfig maxtap 192.168.1.50 netmask 255.255.255.255

NOTE: One might think that one could use the following command:

ifconfig maxtap 192.168.1.50/32

However on Linux the /32 prefix seems to lead to a netmask of 0.0.0.0. Although this seems to work, it is safer to use the prior formulation of the command.

If configured per Figure 2 then we will configure the MaxTap with the native subnet mask of the local subnet as ascertained in step #1, above.

For example, if the opposite port is attached to a subnet defined as 192.168.1/24 and you want the MaxTap to have address 192.168.1.50 then use either of the following commands:

ifconfig maxtap 192.168.1.50 netmask 255.255.255.0

ifconfig maxtap 192.168.1.50/24

4. Add routes to reach the peer devices that will be interacting with the locally hosted application. This is the most complex part of the MaxTap configuration.

The first part of the configuration is to ascertain for each Device Under Test (DUT) whether that DUT is a member of the locally attached subnet or is more distant. In Figures 1 and 2 DUT-1 and DUT-2 are on the locally attached subnet but DUT-3 and DUT-4 are not.

When we configured the address and netmask for MaxTap we created it as a one host subnet (the result of the 255.255.255.255 mask.) What was left unsaid was that that address actually exists within some larger IP subnet to which the opposite port is attached. (We ascertained the address and mask of that subnet in step #1 above.)

We decide whether a DUT is part of the locally attached subnet by examining its address to see whether it is part of the subnet/mask for that locally attached subnet. (This examination is done by ANDing the subnet mask to both the subnet address and the DUT's address. If the results match then they are on the same subnet.)

4A: DUT(s) On the Locally Attached Subnet

If the peer device is part of that larger subnet than we can simply create a host route to it. For example, if our peer device is 192.168.1.55:

route add -host 192.168.1.55 dev maxtap

This will work because Linux will do an ARP request for 192.168.1.55 via the MaxTap interface. And because 192.168.1.55 is in the broadcast domain to which the opposite port is attached, that ARP request will flow via MaxTap, through Maxwell, and finally out onto the net through the opposite port. The ARP response will come back via the opposite path.

Thus, in Figure 1, we can create a host routes for DUT-1 and DUT-2:

route add -host <address of DUT-1> dev maxtap

route add -host <address of DUT-2> dev maxtap

4A: DUT(s) Not On the Locally Attached Subnet

When a DUT is not on the locally attached subnet we follow the same steps as for DUTs on the locally attached subnet. And then we do one more step.

First we add a host route. For example, if our peer DUT is 192.168.99.88:

route add -host 192.168.99.88 dev maxtap

Then we place an entry into the ARP cache. We will be using the MAC address of the first hop router/gateway through which the traffic must pass to reach the remote DUT.

(The easiest way to get this MAC address is to use the "ping" command to bounce a packet off of the local router than to use the "arp" command to view the MAC address that was obtained. Alternatively the "arping" command can be used, but that usually requires super-user privilege. Because routers have multiple interfaces and multiple MAC addresses it is important to take care to ascertain the MAC address of the interface that is physically attached to the local subnet.)

Assume that the MAC address of the local interface of the "Local Router" shown in Figure 1 and 2 is 00:E0:63:0E:6A:1A.

We want to stuff the ARP cache on the Maxwell computer so that there is an association between the IP address of the remote DUT and the MAC address of the local router. The following command does this. Note, however that the "arp" command requires super-user privileges.

arp -s 192.168.99.88 00:E0:63:0E:6A:1A

WARNING: ARP cache entries created this way will persist until the computer is rebooted or the entries are explicitly removed using a command such as:

arp -d 192.168.99.88

What About IPv6?

The MaxTap works for both IPv4 and IPv6. However, for IPv6 the tools to set the address, mask, and routes would be different from, but similar to, those described above.

Limitations

Only one MaxTap may be active at a time.

MaxTap is treated by the networking code of the underlying operating system just like any other network interface. Consequently if the addressing and routing of the MaxTap not set up correctly then some, or even all, of the network traffic of the computer, not just of the application that is intended to be hooked to the MaxTap, might flow via the MaxTap and Maxwell.

For most applications IP packets that are sent are given the source IP address of the interface that the operating system kernel selects for outgoing packets. That is the way it should be; returning packets will be addressed to the address from which the outgoing packets originated. However, some applications may force the operating system to use the "default" IP address or may listen only to the "default" IP address (different applications my have different notions of what constitutes these "defaults".) To use those applications with MaxTap it is necessary to coerce them, if possible, to use the address assigned to the MaxTap.