Filt
Filters and QOS Configuration for Ethernet Routing Switch 5500
Technical Configuration Guide
3. Filter Functionality
3.1 Overall Classification Functionality
Classification with the Ethernet Routing Switch 5500 has some fundamental classification limitations,
imposed by hardware, that affect classification overall. The foremost limitation is related to the concept,
introduced by the latest classification hardware and the supporting data model, of “classification masks”.
A classification mask specifies the fields within a frame that will be used for matching purposes. The mask
itself does not specify the data to be matched but rather indicates which fields, or portions thereof, in the
various protocol headers (e.g., MAC, IPv4, IPv6 headers) will be examined during the classification
process. Currently, a maximum of 15 classification masks and 114 classifiers are available per port for
user-defined traffic classification. This effectively means that 15 or fewer unique combinations of
classification criteria (i.e., Layer 2, 3 and 4 data) can be specified per port. However, multiple data sets
can leverage the same classification mask. This means that, as long as the same protocol data fields are
being matched (e.g., IPv4 source address, IPv6 flow label, Layer 2 802.1p User Priority and VLAN Id), a
much larger number of classifiers, up to a maximum of 114 per port, can be defined containing unique
data values for matching against the fields/offsets identified by the classification mask.
3.2 Classifier Block Functionality
A user should take care when grouping a large number of individual classifiers into a classifier block.
Grouping is a quick way to inadvertently exhaust limited resources. For example, a limited number of
counters are available per interface for tracking matching/in-profile packets. Associating a block of
classifiers with a policy indicating that statistics are to be maintained could consume all counting
resources for a single interface with one policy. To avoid exhausting the number of counters available per
interface, one may select "aggregate classifier tracking" instead of "individual classifier tracking" when
creating the policy. By specifying "aggregate classifier tracking", a single counter resource is used to
track statistics for all the classifiers of that policy, rather than a single counter resource per classifier. The
obvious downside to this is the inability to track the statistics down to the granularity of each of the
classifiers associated with the policy. Individual attribute limitations include:
Individual classifier identification – a classifier set must exist prior to being referenced by the
Classifier-Block.
Individual classifier data compatibility – a classifier is eventually broken down into a bitmask
identifying fields in a packet header that are of interest and values to be matched against those
fields. Classifiers within a block must match the same protocol header fields, or portions thereof.
For example, all classifiers in a block must match against an IPv4 source host address, an IPv4
source subnet with the same number of significant bits or the Layer 2 EtherType field in a tagged
packet. A classifier matching against an IPv4 source host address and another matching against
an IPv4 destination host address may not be members of the same block as these classifiers do
not share a common classification mask. The values to be matched against may differ but the
fields being matched may not.
Referenced component consistency – all the elements that comprise a block (i.e., all classifier blocks with
the same block number) must either reference an action or a meter component or none of the elements
are permitted to reference an action or a meter. In other words, all block members must specify the same
type of information, be it action criteria, metering criteria or neither. The referenced action or metering
elements may differ across block members but all members must reference individual actions or meters
(but not actions and meters) if any do.
Filter example:
To Next Page
Loading...
