Validating Server Message Block with the BreakingPoint CTM
by Pat McGarryBy Pat McGarry
In this post, I’m going to walk you through the process of using a BreakingPoint CTM to validate an enterprise network using the Server Message Block (SMB) protocol [PDF link]. Learning to set up and run this process has many practical applications for enterprise IT staff involved in network operations — and is a great way to learn how to take a pre-existing BreakingPoint Super Flow and customize it for your own purposes.
BreakingPoint’s Implementation of SMB
Many networks that use Microsoft Windows-based PCs work with SMB, which is also known as Common Internet File System (CIFS). (It was also referred to as “Micosoft Windows Network” at one point, before the introduction of Active Directory.) There’s also an SMB 2.0 (SMB2), which debuted with Windows Vista. Variants of SMB installations remain quite prevalent in both consumer and enterprise environments, especially in situations where files need to be shared among PCs, Macs, and Linux installations.
As you might guess, BreakingPoint CTMs include out-of-the-box support for SMB and SMB2. We support them as part of our bidirectional traffic generation capabilities in our super flows, and therefore in our application profiles. In fact, several of our realistic default application profiles (such as Enterprise Datacenter) include SMB as part of their traffic configurations.
What you might not know is that we also support SMB in a one-arm environment. Our canned one-arm SMB super flow (it’s called “SMB File Stress ClientSim”) can be used as-is or can be modified, resulting in live, realistic SMB traffic generation from our Client Simulator layer 7 component against a live SMB target server of your choice.
So what does that mean? Well, for one, that means that you can use the BreakingPoint CTM to create a powerful validation process for a physical or virtual SMB installation.
A suitable process for an SMB server can be developed to determine how many simultaneous users the server can actively support while users are accessing a file share, writing files, verifying that files were written correctly, appending random data to the files, verifying that the files have changed, and finally deleting the files. We’re going to use the BreakingPoint CTM to do just that.
Setting Up the SMB Stress Test
We started the process by creating a Network Neighborhood to point to a particular virtualized VM server at 192.168.5.100 that contains an SMB server implementation. We’ve also set up our source network addresses to allow for up to thousands of simultaneous connections, in case our server outperforms even our wildest expectations. (In this particular example it won’t, but we can be optimistic!)
With our network configuration completed, we create a new test scenario that we call “VM-SMB Stress Test” and add a Client Simulator component in preparation for creating the super flow that will define the SMB traffic that we want to generate. To do that, we invoke the Application Manager and select the Super Flows tab.
Although you could create a suitable super flow from scratch, it is usually easier to work from one that already exists. In this case, we will use the canned “SMB File Stress ClientSim” super flow, save a copy under a new name, and make appropriate modifications. Within the Application Manager — seen in the screenshot below — select “BreakingPoint” in the Type field and “100” in the Max Returned field and then click Search; the “SMB File Stress ClientSim” super flow will be towards the bottom of the second page of listings. Once you select “SMB File Stress ClientSim,” it will auto-populate the fields on the right. Now click Save As in the lower-left and save the super flow with a meaningful name, such as “VM-SMB Stress,” and click Ok:
Now that we’ve saved the new super flow, we are allowed to make modifications to it. On the lower right-hand side, you’ll see a series of Defined Actions listed for the canned super flow that we’ve copied. The first one we’ll modify to suit our needs is action 1, “Authenticate.” Click that action to select it, and then click the bracketed ellipsis below it to bring up the detail dialog:
We now change the authentication parameters to match our SMB implementation. In this example, which matches our particular VM’s SMB server, the share name is “files,” the username and password are “bps,” and the protocol is SMB (or SMB2, but in our case we are running against an SMB server). Once we’ve made the changes, we click Apply Changes:
The second action writes a file to the share. When we select it and click the ellipsis to bring up the detail window, we see that we can specify several settings, including the filename and the minimum/maximum sizes for random file generation. For our example, we’ll use the filename “moby-dick-%f-%g.txt” and specify the file contents before uploading our own file.
The %f and %g in the filename are critical to the function of our stress test. Those are special values that our network processors treat as super flow variables, for the duration of the super flow. This is important since it allows subsequent action steps to use the same filename structure, which is important since we want to have many simultaneous users. We’ll talk more about these special %f and %g variables in short order.
We then deselect the minimum and maximum random file sizes in order to specify a particular file payload. To specify it, we click on Import File Contents and chose to upload Chapter 1 of Herman Melville’s Moby Dick (my electronic copy of Chapter 1 is 12,232 bytes), select it from the File Contents dropdown, and then Apply Changes:
Action 3 appends to a file on the share, and eventually we will indeed want to do that. But not now. Right now we want to verify that the file was written correctly. To do that, we perform a click-and-drag to bring action 4 (the verify action) above the existing action 3 (the append action), thereby reordering them. Once again, we’ll click on the ellipsis button to expand the detail for the verification action:
We then configure the verification action dialog to match our filename and the expected contents, then Apply Changes:
We’ve now written a file and verified its contents. Now we will append some random data to the file. Since our append action is already in the right sequence, we select it, expand it, configure it to append 30,000 – 50,000 characters to the file that we just wrote, and Apply Changes:
We’ve now appended between 30,000 and 50,000 random bytes to our file. Action 5 is another verification step. We select and configure it here so that we will be able to determine that the file has changed:
Our last action is the delete action, where we will delete the file, thereby ensuring that we clean up after ourselves. We select that action, expand its detail, update the filename, and Apply Changes:
Now we’re down to action step 6, which currently says “Disconnect.” But we’re not going to do that yet. Instead, we will add new logic to make our stress test even more realistic. What we’re going to do is setup a Goto action, so that we will loop back to action #2, thereby repeating our write-verify-append-verify-delete operation multiple times. To do that, we use the “Create a New Action” dropdown on the right-hand side of the screen to select “Client: Goto,” and then we click Add Action:
Once you’ve clicked Add Action, you’ll see that an eighth action step now exists with the new action “Goto – end.” Click-and-drag the new eighth action so that it is above the disconnect action. After finishing the operation, you’ll have:
We’ll now select our new action 7 and open up its dialog window using the bracketed ellipsis button, tell it to go back to action 2 using the dropdown list in the dialog, and choose five iterations. After five iterations have run, the sixth one will result in the Goto falling through to the next step, as opposed to looping back to action 2. Since we will have run once already when we get to the Goto the first time, and since we will loop back again five more times, we would expect six full iterations with this logic. This is similar to a “do-while” loop construct found in many programming languages:
Now that we’ve added the Goto action, we can talk more intelligently about our %f and %g variables. The %f variable is randomized at the start of the super flow, and will be the same throughout the entire duration of the super flow. The %g variable is the current iteration number, in countdown fashion. Since there is no Goto until action 7, the value of %g up until then will be 0. However, once the Goto occurs the first time, the value will be initialized to one less than the total number of iterations remaining. Since there are 5 iterations remaining at the first invocation of our Goto step, the %g value will become 4, and it will decrement each time through the logic loop that we’ve set up until it reaches zero again.
To make our lives easier when it comes time to verify our stress test results, we’re going to create one more new action, to introduce a delay step. Select the “Create a New Action” dropdown to the right to select “Client: Delay,” and then click Add Action:
Drag the new delay action above the “Delete file from share” action, yielding:
Now select the new Delay action and click the bracketed ellipsis to open its dialog, select the “Number of milliseconds” entry and enter a value of 1500, then click Apply Changes:
This step will introduce a 1.5 second (1500 millisecond) delay just before the file is deleted. That will give us plenty of time to execute Linux commands on our SMB server to witness file behavior in real-time before the BreakingPoint CTM deletes the file and begins the next iteration.
Our final action is the Disconnect action, and requires no changes. We can now save our super flow by clicking on Save Super Flow at the bottom right:
We can now go back to our scenario and tell the Client Simulator component to use the super flow that we’ve just finished creating. Usually, the easiest way to get back to the scenario is to click the fishhook-shaped blue return arrow near the top right corner of the screen, since your last view was likely your scenario view. (Alternatively, you could also use menu options Test > Open or Test > Open Recent Tests.) Once you are back to the scenario, choose the Parameters tab. Select “Super Flow” at the very bottom of the parameters list, and then in the right-hand pane click the dropdown and select the new super flow that we just created, “VM-SMB Stress,” and click Apply Changes:
Knowing that disk access (seeks, reads, and writes) is going to be the limiting factor in our file-based SMB stress test, we choose to set our initial value for “Session Configuration.Maximum Simultaneous Sessions” to 50, to see how well our server will stand up to 50 simultaneous users.
As we save and run the test, we begin to see activity in our SMB share. Here’s a partial snapshot taken during the test run, using the Linux command-line tool “watch”:
As this particular process continued, the VM server being validated didn’t do too well, and we witnessed several SMB transaction failures. These are really easy to isolate and identify in our comprehensive reporting:
Through intelligent trial and error — by backing off the number of simultaneous users in our scenario configuration — we found that our particular VM’s SMB server could handle 30 to 35 simultaneous high-activity users with no SMB transaction failures registered. That’s not bad for a small-scale SMB environment such as a small business. If better performance is needed for larger environments, then the SMB administrator has several options, including optimizing the SMB configuration, moving the VM to a machine with more resources, using multiple VMs, or improving the disk, to name a few.
The BreakingPoint CTM’s ability to quickly and efficiently configure a stress test scenario for SMB (and, for that matter, many other widely used protocols) quickly becomes an indispensable tool, allowing an administrator to determine the initial performance of the server, and then track that performance as both configuration and physical changes are made to the server over time.
If you have questions about anything in this post, please leave them in the comments below.
