The ONL NPR Tutorial

NPR Tutorial >> Examples

TOC

Using An Auxilliary Filter

Introduction

We demonstrate how an auxilliary filter in combination with the nstat plugin can be used for gathering statistics on flow types in a probabilistic manner. Recall that an auxilliary filter can make a copy of a matching packet allowing the original packet to proceed in the normal manner while the copy can be processed by a plugin or directed towards a monitoring host. In this example, we use an auxilliary filter to:

• Get samples of the matching packets rather than making a copy of every matching packet.
• Send a sample of all matching packets to the nstat plugin for counting.

Steps (Index):

1. Set up the network configuration.
2. Create the auxilliary filter.
3. Install a plugin to monitor our sampled packets.
4. Set up monitoring of the plugin.
5. Send packets through the filter.
6. Change the sampling rate.

Steps (In Detail):

Step 1: Set up the network configuration.

Create the standard dumbell configuration shown below which we already created in the earlier example NPR Tutorial => Examples => The Remote Laboratory Interface.

Step 2: Create the auxilliary filter.

In this step, we install an auxilliary filter that will be used to select a sampling of packets for our plugin to process.

• RLI Window: Select NPR 1, Port 3 => Configuration => Filter Table
• Filter Table Window: Select Edit => Add Filter
• Add Filter Window:
  • Select * as the protocol.
  • Check the aux box.
  • Select plugin only for port/plugin selection.
  • Enter 4 as the output port.
  • Enter 0 as the output plugin.
  • Select 25% from the sampling type (aux only) drop down menu

• Add Filter Window: Click the Add button to create your filter.

Step 3: Install a plugin to monitor our sampled packets.

Next, we will install the nstats plugin at NPR 1 to count packets forwarded to it by the auxilliary filter we just installed.

• RLI Window: Select NPR 1 => Configuration => Plugin Table.
• Router NPR.1 Plugins Window: Select Edit => Add Plugin => nstats.
• Router NPR.1 Plugins Window: An entry for nstats should have now appeared in the plugins table. Double click in the second column (the microengine column) and change the 1 to a 0.
• Commit your current configuration, and save the configuration (if desired).

Step 4: Set up monitoring of the plugin.

In this step, we add a monitoring display to track the packets detected by the nstats plugin.

• RLI Window: Select Monitoring => Add Monitoring Display
• Graph Title Window: Enter Monitoring Counts as the graph title and click the Enter button.
• Monitoring Counts Monitoring Display: Select Parameter => Add Parameter
• RLI Window: Select NPR 1 => Monitoring => PluginCounter
• Add Parameter Window: Accept a Polling Rate of 1 sec, keep microengine as 0, and set counter to 0. Press the Enter button.
• Monitoring Counts Monitoring Display: Click on PlugingCounter to change the line name to Counter 0.0 (ICMP) and press the Change button in the dialogue box that appears.
• Repeat the above three steps setting counter to 1 and changing the line name to Counter 0.1 (TCP) and then again setting counter to 2 and changing the line name to Counter 0.2 (UDP). When you are done, your monitoring display should look like the one below:

Step 5: Send packets through the filter.

In this step, we will send ping and iperf traffic through the network and confirm that the filter forwards copies of about 25% of the packets to our nstats plugin. Begin by opening two shell windows.

• Shell Window 1: Enter the following lines:

  remote> ssh onl.arl.wustl.edu
  onlusr> source ~onl/.topology
  onlusr> ssh $n1p3
  $n1p3>
  

• Shell Window 1: Enter:

  $n1p3> ping -c 40 n2p2
  

You should observe that all of these ping packets get through (ie drop rate is 0%), but you should also observe your Monitoring Counts monitoring display showing an increase in the Counter 0.0 (ICMP) line. Since this line is an absolute value, you should see it increasing from time to time (ie each time the aux filter makes a copy of a packet and sends it to the plugin). After the ping command is done running, you should see the line level out at a value that is approximately 25% of 40. In the case of the run of this example shown below, the graph leveled out at 11 packets.

• Shell Window 2: In a second shell window, enter the following lines:

  remote> ssh onl.arl.wustl.edu
  onlusr> source ~onl/.topology
  onlusr> ssh $n2p2
  $n2p2>
  

• Shell Window 2: Enter

  $n2p2> iperf -s -u
  

  We are setting up the iperf receiver to receive iperf traffic at the receiving host.

• Shell Window 1: Enter

  $n1p3> iperf -c n2p2 -u -b 1m -t 5.88
  

  • With this line, we are telling the sender to send udp traffic at a rate of 1 Mbps for 5.88 seconds. Sending 1 Mbps for 5.88 seconds means we will send a total of 1 Mbps * 5.88 seconds = 5.88 Mb (5,880,000 bits or 735,000 bytes) of data. Since each packet of UDP iperf traffic is 1470 bytes, this means we should be sending a total of 735,000 bytes / (1470 bytes per packet) = 500 packets of data when we run this command.
  • After running this command, you should see output similar to this in Shell Window 1:
  You can see that the receiver successfully received 500 packets with 0% packet loss from the output line:

  ([  3]  0.0- 5.9 sec    719 KBytes  1.00 Mbits/sec  0.001 ms    0/  500 (0%))
  

• Now look at your Monitoring Counts display. You should see that the line for Counter 0.2 (UDP) has increased up to a value approximately 25% of 500 (i.e., near 125). In the case of the test displayed in the image below, exactly 125 packets were forwarded to the plugin, but your results will probably not be this exact since the filter probabilistically determines whether to copy a packet or not for each packet separately, and thus the percentage of packets copied and logged is often not exactly 25% of the total number of packets sent.

Step 6: Change the sampling rate.

In this step, we change the sampling percentage of our auxilliary filter and see how this affects our output.

• RLI Window: Select NPR 1, port 3 => Configuration => Filter Table
• Filter Table Window: Highlight the filter you created in step 2.
• Filter Table Window: Select Edit => Edit Filter
• Edit Filter Window: Change the value of the sampling type (aux only) drop down menu to be 50.0% and press the Edit button.
• Repeat Step 5 as listed above.

  You should observe that about half of the packets sent in each case are sent to and counted by the plugins.

Test Your Understanding

Multiple Flows Through the Filter

What happens if we send multiple flows of packets through the auxilliary filter? Try using an auxilliary filter with a sampling rate of 25%. Send 40 ping packets from n1p3 to n2p2, and at approximately the same time, send 40 ping packets from n1p2 to n2p3. How many packets do you see counted by the ICMP counter of the nstats plugin? Is this what you expect?

Using Other Plugins

What happens if we use other plugins instead of nstats? Try repeating all the steps of the original experiment, but with the following changes:

• Install the "count" plugin in place of the nstats plugin.
• For your Monitoring Counts display, create only a counter for ME 0, counter 0. The count plugin only maintains one count of the total number of packets it has seen, so in your Monitoring Counts display, you would only see counter 0 incremented no matter what kind of packets are passing through.

Besides the fact that all packets are counted together by the count plugin, what do you notice that is different from when the nstats plugin was used (looking particularly at the results printed in your shell windows)? If you consider the fact that the nstats plugin drops the packets it receives whereas the count plugin forwards them on to their destination, does this difference make sense? Why would we prefer to use the nstats plugin instead of the count plugin in an experiment like this?

NPR Tutorial >> Examples	TOC