Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Overlapping Classification for IP Input Policy

    IP auxiliary input policy can be used with IP input policy to provide overlapping classification. Two policies, each with a set of independent rules and actions, run in sequence so that each policy can independently produce a set of actions in sequence. A packet that matches both the input policies and auxiliary input policies is subject to both sets of policy actions.

    E Series routers allow four input and two output policies per IP interface:

    • One secure input policy
    • Three nonsecure input policies
    • One secure output policy
    • One nonsecure output policy

    Each classifier-group has a set of associated actions that is taken if it is the highest priority match. The system performs only one set of actions per policy attachment. By using an input and secondary-input policy, you can have overlapping classification with multiple policy actions on ingress. Overlapping classification on egress is not supported.

    An additional policy attachment point enables overlapping classification within the input classification stage, between the input and secondary-input stages. There are five attachment points for IP policies that are executed in series:

    • input
    • secondary-input
    • secure-input
    • output
    • secure-output

    An explicit filter action, a forward action with a null next-interface, or a rate-limit action can cause an immediate packet discard at any stage. Other actions, such are marking and coloring can be done at each stage, with the last of each of these actions taking precedence over the others.

    For example, unique policies can be attached at each stage, all of which mark the IP TOS field differently. The packet then exits the router with the TOS value that was set in the output policy stage. However, if TOS is also used as a classification (input) term for each of these policies, three different TOS values are presented to the classifier:

    • Original TOS received
    • TOS modified by the input policy
    • TOS value modified by the secondary-input policy

    Figure 1 shows the input policy stage after the addition of the auxiliary substage. It is divided into three steps:

    1. Apply classification for both substages.
    2. Perform policy actions (if any) for the primary attachment.
    3. Perform policy actions (if any) for the auxiliary attachment.

      Figure 1: Input Policy with Primary Stage and Auxiliary Substage

      Input Policy with Primary Stage and Auxiliary
Substage

    The order of policy action execution for each attachment is:

    1. Filter
    2. Modify (includes setting of color, traffic class, user packet class) and Log
    3. Rate limit profile/color
    4. Mark TOS
    5. Exception
    6. Forward

    Starting Policy Processing

    Input and auxiliary-input classification operations, specified by the details of each policy, are performed in parallel. Classifier inputs for both policies are determined concurrently using the initial values of the classification terms. Policy attachments within a stage cannot communicate between the input and auxiliary-input classification operations. For example, any changes made by the input attachment to traffic-class, color, TOS, or user packet class are not visible in the auxiliary-input policy classification. If this communication is needed, it can only be done between different policy stages, rather than within a single stage.

    The results of the input policy actions are passed forward to the auxiliary-input policy action processing. This means that a color-aware rate limit profile action in the auxiliary substage recognizes any change in color caused by primary policy actions.

    Processing the Classifier Result

    The classifier result of the input policy attachment is processed and a set of actions is identified. When you configure filter, it is the first action taken and immediately discards the packet. This is followed by any modification, such as mark or logging. If a rate limit profile is configured, the packet is dropped or colored. If the packet is not dropped, it is sent to the exception path (if configured). If the packet is not exceptioned, any configured forward action is saved in the packet for use later (unless overridden in Step 3). (See Figure 1.)

    Some information generated by the action processing in Step 2 is forwarded to Step 3, where it may affect the action processing for the auxiliary-input attachment. This information can include color, exception information, and forwarding information. The color can affect a rate-limit in the auxiliary-input attachment. Step 3 acts on the exception and forwarding information, if it is not overridden by similar actions from the auxiliary-input attachment.

    The transmit information (transmit conditional, transmit unconditional, transmit final) generated with hierarchical policies does not carry forward from input to auxiliary-input action processing.

    Processing the Auxiliary-Input Policy Attachment

    If the packet is not filtered or exceptioned in policy Step 2, the classifier result of the auxiliary policy attachment is processed and a set of actions identified. The packet can be filtered or exceptioned at this time. These operations, if configured, are performed regardless of whether a forward action was performed in Step 2. If the packet is not discarded, either by a filter action or a rate limit, it can be exceptioned (if configured). If the packet is not filtered, rate-limited, or exceptioned, any configured forward action is applied and overrides any forward action from Step 2. If no forward action is configured, any forward action from Step 2 applies.

    Policy Actions

    The set of actions in the following list specified by the input and auxiliary-input policy attachments are executed in the order: input, auxiliary-input.

    • Color packet action—Explicitly sets the packet color. Each policy attachment can set the color and the final value persists. A rate limit profile action can also set the color, which overrides the value of the color packet action.
    • Mark action—Each attachment can set the TIP TOS, TOS precedence, and DS fields. The cumulative result of all configured mark actions determines the resulting value of these fields.
    • Mirror action—Executes in the order: secure input policy follows secondary input policy, secure output policy follows output policy. Mirror is the only supported action for secure policies.
    • Rate-limit profile action—Can be specified by any nonsecure input policy attachment. This enables the application of multiple rate limits either within a policy stage or across policy stages. These rate limits run serially; if the rate limit imposed in the primary substage causes the packet to drop, the auxiliary rate limit does not run and the associated token buckets are not affected. If you configure more than a single rate limit per interface, it significantly impacts forwarding performance. Attaching two policies with rate limit profiles in the same policy stage is equivalent to having two policies attached in the same order, but in separate stages.
    • Traffic class action—If both the input and auxiliary-input attachments need this action, the value configured in the auxiliary policy overwrites that of the primary policy.
    • User packet class action—Can be set twice per stage, with the second value overriding the first.
    • The filter, next-hop, forward interface, and forward next-hop actions are mutually exclusive within a classifier group. However, two policies in series can result in conflicting actions, which are resolved using the following precedence rules:
      • The filter action has highest priority. A filter action in input or auxiliary-input policy always prevails.
      • The exception action takes precedence over forward actions.
      • If multiple exception actions are required by the policy attachments, the last one takes precedence.
      • If forward operations are required by both input and auxiliary-input policy attachments, the auxiliary-input forward action takes precedence.

    Input policy attachments depend on the local keyword in classifier list entries. Using the local false keyword or using no local keyword (default) treats both local and non-local traffic equally and ignores the local true classifier list entries.

    Secondary input policies affect both local and non-local traffic and are processed by policies attached with the secondary-input keyword. Secondary input policies are controlled by the local keyword in the classifier list entries as follows:

    • local true keyword only affects local traffic
    • local false keyword only affects non-local traffic
    • no local keyword (default) affects both local and non-local traffic

    In Table 1, the filter action for the input policy takes precedence over the others so that if a filter action is configured for either policy, the packet is filtered. If neither policy has a filter action, but both policies specify a forward action, the action specified by the auxiliary policy takes precedence. If only one policy specifies a forwarding action, that action is executed. The next-hop rule is inoperative for auxiliary-input policies, just as it is for secondary input policies. This policy rule has been superseded (but not replaced) by the forward next-hop rule, which is operative for auxiliary-input policies.

    Table 1: Input Action and Secondary Input Actions

    Input Action

    Secondary Input Action

     

    None

    Exception

    Filter

    Next-hop

    Forward Interface

    Forward Next-hop

    None

    None

    Exception Auxiliary

    Filter

    None

    Forward Interface Auxiliary

    Forward Next-hop Auxiliary

    Exception

    Exception Primary

    Exception Auxiliary

    Filter

    Exception

    Exception Primary

    Exception Primary

    Filter

    Filter

    Filter

    Filter

    Filter

    Filter

    Filter

    Next-hop

    Next-hop Primary

    Exception Auxiliary

    Filter

    Next-hop Primary

    Forward Interface Auxiliary

    Forward Next-hop Auxiliary

    Fwd Interface

    Forward Interface Primary

    Exception Auxiliary

    Filter

    Forward Interface Primary

    Forward Interface Auxiliary

    Forward Next-hop Auxiliary

    Fwd next-hop

    Forward Next-hop Primary

    Exception Auxiliary

    Filter

    Forward Next-hop Primary

    Forward Interface Auxiliary

    Forward Next-hop Auxiliary

     

    Published: 2014-08-14