Using Avalanche to test MAC Address Capacity of Stateful Network Devices

Using Avalanche to test MAC address capacity of stateful network devices

Using a lot of MAC addresses in an Avalanche test is something we see on a regular basis. This can be used for Network Access Control, RADIUS, 802.1x, or simply to stress the MAC table of a switch. Avalanche can do that; in two different ways, even. One way is simple but gives you less flexibility than the second, more complex solution that gives you more control.

TL; DR: Here's a 3.60 SPF file that contains two tests, one for each method.

First method

Let's take a look at the simple way first. Using this method, the first two bytes of each SimUser's MAC address will increment with each new SimUser born - and then cycle back to the start. The remainder of the MAC will come from the SimUser's IP address. To set this, simply go to Client(Server)/Subnet and check the "MAC" box at the top of the screen:

This will enable the MAC options (the "MAC" checkbox and the two "Byte" fields). Checking the box will make the two fields editable. By default the fields will be filled with "12" and "22", but you are of course free to change that to whatever you need this to be (remember, MAC addresses use hexadecimal values). It goes without saying that Multicast MAC addresses will not be accepted as this is only for unicast testing.

If you want to make sure that, during the test, no two MAC are the same, you can check the "Randomize" box. What this does is that each time a SimUser is born, instead of taking the next IP address in the range a random one will be picked from the pool. But since the MAC address bytes increment in a linear fashion, this creates a randomness that in most cases ensures that no two MAC addresses are the same in the test. And of course, the larger the subnet, the lower the chances to use the same MAC twice.

The picture below illustrates that kind of large, random subnet (that would probably kill most switches, too!):

One last important note about this feature: if you uncheck the "MAC" checkbox sitting on top of the list of subnets, it does not disable the feature. This checkbox merely hides the settings but, I'll say it again, does not disable them.

Second method

The second method is slightly more complex - depending on how you look at it - but allows you to specify the whole MAC (instead of only setting the last four bytes from the SimUser's IP address). This can be useful in test cases where specific MAC must be used (e.g.: only MAC 00:00:00:00:00:00 can access the subnet 192.168.43.0/24).

To test in this way, the work doesn't take place in the Subnets but in the Action List. Advanced users will immediately know what this mean: you cannot influence the servers' MAC using this method (but you can use the first one for the server-side while using the second method for the client side).

The example below pulls the MAC addresses from a Form Database (more on this below) named "myMacs", will apply it to the current SimUser, which will then do a HTTP GET, then die:

Action List Commands:

ASSIGN VARIABLE

ETHSETTING MACADDR =

1 GET http://192.168.0.10/

The only thing left to do is create the previously mentioned Forms Database. Forms DBs are very handy comma-separated flat files you can pull data from. There are not set limits to the number of columns or rows. In our example, however, we'll just keep it simple with one column and multiple rows:

You will notice three checkboxes. "Auto Increment" does just what it says: for each new SimUser, the next row will be used. When the last row is reached, Avalanche cycles back to the first row.

"Skip First Row" can be pretty handy. FormsDB are pretty much CSV files. And in many cases, the first row in a CSV file is used to describe the name of that column ("email,firstName,lastName,areaCode", etc..). This feature exists to allow user to keep these column names.

Last but not least, the "URL Encode Form" means that Avalanche will URL Encode the content of the FormsDB for you. This is usually needed when testing against HTTP servers or HTTP-aware devices, and is therefore not needed for dynamic MAC addressing.

Conclusion

There are multiple ways of doing same thing, the question is do you want it to be fast and easy or do you want high control. That's about it regarding these two separate, yet similar, features. If you have any more questions, feel free to contact me at arnaud.castaner@spirent.com.