Transcript for this video
Welcome back to our Mini Maxwell and Maxwell G video series.
In an earlier video, we showed you how to configure your Maxwell Network Emulator, and we showed how to introduce 1% packet drop.
Now, we're going to show you how to use filters, allowing you to introduce impairments to specific types of traffic.
The reason it's important to be able to do this is that in the real world, certain types of traffic will be impaired or not impaired depending on the situation.
For example, a slow DNS server means that DNS traffic will be delayed.
However, other types of traffic will not be affected and should not be delayed or otherwise impaired.
It's crucially important to be able to emulate a network realistically this way—otherwise, you'll have results that are inaccurate or even meaningless.
In this example, note that we have different impairments on different traffic types, including no impairments.
However, other network emulators incorrectly apply impairments to ALL the packets.
In this example, let's emulate some real-world problems with Cloud Computing.
Cloud servers extensively use the HTTP protocol.
Fairly often, you'll have performance problems with HTTP.
So let's see how we can emulate a slow cloud server.
To do this, we'll go to the Filter Map, and select the TCP HTTP source and destination ports.
We'll put them in Band One for the traffic flowing from A to B—that is, from the client to the server—and also in Band One for the traffic flowing from B to A—from the server to the client.
Then we click Submit.
This will allow us to apply specific impairments just to the traffic that's flowing in Band One—in this case, the HTTP traffic.
Now that we've selected our HTTP traffic for filtering on Band One, we click on Home...then on Bands and Impairments.
To add impairments, first, we make sure we're in Band One.
Later, we'll be adding different impairments to other bands.
Notice that on the left side, we have a selection of impairments for A to B, the client to the server.
We'll select Band One and enter 100 ms in the Delay and Jitter box.
Then on the right side, we have a selection of impairments for B to A, the server to the client.
We'll enter 500 ms in the Delay and Jitter box.
This means the HTTP traffic will have five times the delay from the server to the client, as from the client to the server.
In the real world this can happen for a variety of reasons, for example when a cloud server is overloaded and underprovisioned.
Now that we've entered our impairments we can click Submit, then Home.
Now our simulation has started.
The HTTP traffic is delayed from both the client to the server and from the server to the client.
We can take a look at the traffic graphs to see the effect.
The top graph shows the packets delayed in HTTP traffic from the client to the server, and conversely this third graph shows the packets delayed in HTTP traffic from the server to the client.
For a user or client working in a web browser, the response time of the server is very poor.
Now that we've emulated a slow web server, we can give this a title and description by clicking here.
Let's call this “Slow Web Server”, and in the configuration description we can enter “client to server delay 100 ms and server to client delay 500 ms.”
Then we just click Submit, and the configuration is updated.
If Maxwell is power-cycled or restarted, it won't remember this configuration, but we can re-use this Slow Web Server Emulation by saving it.
To do this we click “Export to Windows,” and get a pop-up box to save the configuration file.
The next time we want to use this emulation, we can click on the Import button here.
Now let's take our emulation one step further.
We know that for cloud computing, three types of protocols are extensively utilized.
These are: HTTP, HTTPS, and DNS
So let's take a look at what would happen if we add DNS to our emulation.
When a user or client is accessing a cloud server through a website, several DNS lookups are typically generated.
DNS, the Domain Name System, has to resolve these queries, and some DNS servers can be slow.
Let's look at what happens when DNS traffic is delayed.
We'll select DNS source and destination traffic from both the client to the server and server to the client.
Since these DNS impairments are different from the ones we are applying to the HTTP traffic in Band One, we'll put the DNS filters in Band Two.
Let's submit these changes and go to Bands and Impairments.
Let's make sure we're in Band Two.
Now, let's impose a 500 millisecond delay on packets flowing through Band TWO in both directions.
This will result in a general DNS resolution delay of about one second, which should have a substantial negative impact on the setup time for many applications, especially those that do a lot of DNS queries, such as web browsers.
Let's submit these changes and check the Traffic Graphs.
Once again, the first section of our graph shows the packets delayed in traffic from the client to the server, and the third section shows the packets delayed from the server to the client.
This time we are looking at the aggregate traffic delay with both HTTP and DNS delays.
As you can see, the new DNS delay we just added has a dramatic effect on the packets.
Now that we've added DNS impairments, we can change the Title and Description.
Let's call it “Slow Web Server with HTTP & DNS Delays.”
We'll also want to click on the “Export to Windows” button again and save the configuration file.
We've now seen how to put together a network emulation for Cloud Computing.
We've very precisely introduced delay to the key protocols that form the cornerstone of cloud performance, and this emulation can be easily reloaded for use at a later date.
Thanks for watching!
Want to Know More?
|Find more videos||How to buy||Contact an Expert|