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:

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:

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:

Figure 7 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 7: 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 7.)

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.

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:

In Table 16, 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 16: 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

 

Related Documentation