Base Class: IOModule

The InputPurge module is a generic I/O chain module capable of purging (releasing) packets that are being processed on a I/O module chain for an adapter. The module itself can be tuned in its current form to purge all packets (default) or to selectively purge packets based on the matches in the source or destination fields of the Ethernet or IPv4 headers.

Example Declaration (passthroughHidden.xml)

<InputModule type="InputPurge">
   <Ethernet>00:FA:34:56:12:34</Ethernet>
   <IPv4>10.0.0.1</IPv4>
</InputModule>

The above code show an InputPurge module taken from the passthroughHidden.xml example. The code defines an InputModule? on the chain of type InputPurge and creates filters such that it will purge any packets sent or destined to Ethernet address 00:FA:34:56:12:34 as well as any packets sent or destined to IPv4 address 10.0.0.1. The relationship in the listing is for a lazy OR evaluation meaning that if one of the addresses is a match in the source or destination aspect, the packet will be purged.

By default with no addresses listed, all packets entering this module would be purged.

Statistics

The number of packets purged is recorded for the module.

Tag - Ethernet

   <Ethernet>00:FA:34:56:12:34</Ethernet>

The Ethernet tag lists a valid 802.3 six byte MAC address, either as a list of sequential hex values or as a colon separated list of hex values. A match on either the source MAC or destination MAC address will result in the packet being purged from the input or output chain. Note that the broadcast address must be explicitly stated in order for it to be purged in the source or destination case. There is no limit to the number of MAC addresses that can be listed beyond the performance degradation that occurs with listing additional addresses.

Tag - IPv4

   <IPv4>10.0.0.1</IPv4>

The IPv4 tag lists a valid IPv4 address in dot notation. Host names are not allowed as the address must be a specific v4 address. Subnet support via the /bits notation is not currently enabled but will likely be enabled via a separate identifier (i.e. 10.0.0.0/8). Note that multicast or broadcast addresses must be explicitly stated in order to be considered. In order to trigger the comparison, the packet must be an IPv4 packet, i.e. outbound ARPs from a particular IP would not be caught. There is no limit to the number of IP addresses that can be listed beyond the performance degradation that occurs with listing additional addresses.

Other Considerations

• Should this be renamed to reflect input or output status?

Future

• The internals of the class will eventually be reworked once the filter mechanism is complete. The ability to single out MAC or IPv4 addresses will remain in future versions regardless of the underlying mechanism for comparison.