The ONL Tutorial

Tutorial >> Router Plugins TOC

Predefined Plugins

Predefined plugins are defined in the ~onl/stdPlugins/ directory. We have already introduced the pdelay and stats plugins in this section. The tutorial page Predefined Plugins summarizes the predefined plugins. This section gives an overview of the stringSub plugin and the multicast plugin to broaden your appreciation of what can be done with plugins. The More Plugins provides a detailed description of their inner workings and a tour of the source code.

We have already shown how the stats plugin can inspect the protocols field of an IP packet header and discard packets. We have also discussed how the pdelay plugin delays packets by queueing them and then forwarding them at a later time. This page describes the following two plugins that demonstrate additional plugin features:

Because the set of predefined plugins continues to grow, these tutorial pages only touch on the most basic ones.

The stringSub Plugin

The stringSub plugin replaces every occurrence of the string "HELLO" with the string "adieu" in the packet payload. Since the plugin modifies the packet, it must also recompute the packet checksum stored in the IP header.


Fig. 1. n2p3 (onl29) sftp's to n2p2.

In order to test the plugin, we transfer the ASCII file ~jst/misc/foo from n2p3 to the file ~jst/foo using sftp on n2p2. In reality, the two files will be in the same file system because the home directory ~jst is remote mounted on all ONL hosts, but the transfer will be from ~jst/misc/foo to ~jst/foo. Fig. 1 shows that n2p3 has onl29 as its external interface name.


Fig. 2. Plugin and Filter Tables at Ingress Port 2.3.

Fig. 2 shows that we have installed the stringSub plugin at ingress port 2.3 and bound it to a GM filter through SPC queue 100. Furthermore, after plugin processing, packets will be placed in VOQ 2 for forwarding to port 2 (the forward to voq entry).


Fig. 3. Test of stringSub Plugin.

Fig. 3 shows a test of the plugin. At the top, we see that we have logged into onl29.arl.wustl.edu which is the n2p3 host. The command test sequence is:

Command Explanation
cd /users/jst/misc Directory contains the source file /users/jst/misc/foo
m(ore) foo Display the contents of the file foo
ftp n2p2 ... put foo Transfer the file foo to n2p2:/users/jst/foo
m(ore) ../foo Display the file /users/jst/foo

The last step displays the file that was received at n2p2. Clearly, all occurrences of the string "HELLO" (all caps) have been replaced by the string "adieu". Note that the string "Hello" remained in unaffected by the transfer.

The multicast Plugin

The multicast plugin sends a copy of a packet to every port indicated in a destination vector. The user can configure the destination vector through control messages. Normally, a packet coming back to the FPX from an SPC plugin is reclassified and forwarded according to the tables in the CARL lookup engine. But in this application, the mulicast plugin sets the output port destination in the intraport shim and instructs the FPX to omit the reclassification step by disabling the reclassify flag in the shim.


Fig. 4. Plugin and Filter Tables and Multicast Destination.

Fig. 4 shows the Plugin and Filter Tables at ingress port 2.3 as in the stringSub example except with the multicast plugin instead of the stringSub plugin. It also shows the dialogue box from selecting Port 3 Plugins => Edit => Send Command to Instance . In this case, command 2 inserts the parameter 3 adds port 3 to the set of multicast destination ports. The charts below indicate that we have added output ports 1 through 7 to the multicast destination vector in a similar manner.


Fig. 5. Traffic Bandwidth from VOQs 1-7 at Ingress Port 3.

Fig. 5 shows the resulting traffic when we send ping traffic into ingress port 2.3 and add output ports to the destination vector every 6 seconds and then begin removing output ports at T = 2,805.


Fig. 6. Packet Counts To/From SPC and Arrived.

Fig. 6 charts further verifies that the multicast plugin is working as expected. For every packet going to the SPC, one or more packets are coming back from the SPC depending on the number of output ports in the multicast destination vector. The number of ports increases by one every 6 seconds until it peaks at T = 2,567. Also, the number of packets arriving to ingress port 3 is equal the number going to the SPC as expected.


Revised: Fri, June 9, 2006

 Revised:  Wed, July 12, 2006 

  
  

Tutorial >> Router Plugins TOC