Filter Configuration Command Reference

This command creates a text description stored in the configuration file for a configuration context.

The no form of the command removes any description string from the context.

This command creates a configuration context for the specified IPv4 filter policy if it does not exist, and enables the context to configure the specified IPv4 filter policy.

The no form of the command deletes the IPv4 filter policy. A filter policy cannot be deleted until it is removed from all objects where it is applied.

This command creates a configuration context for the specified IPv6 filter policy if it does not exist, and enables the context to configure the specified IPv6 filter policy.

The no form of the command deletes the IPv6 filter policy. A filter policy cannot be deleted until it is removed from all objects where it is applied.

This command enables the context to activate system filter policies.

This command, creates a configuration context for the specified MAC filter policy if it does not exist, and enables the context to configure the specified MAC filter policy.

The no form of the command deletes the MAC filter policy. A filter policy cannot be deleted until it is removed from all objects where it is applied.

This command, creates a configuration context for the specified redirect policy if it does not exist, and enables the context to configure the redirect policy.

The no form of the command removes the redirect policy from the filter configuration only if the policy is not referenced in a filter and the filter is not in use (applied to a service or network interface).

This command, creates a configuration context for the specified filter log if it does not exist, and enables the context to configure the specified filter log.

The no form of the command deletes the filter log. The log cannot be deleted if there are filter entries configured to write to the log. All filter entry logging associations need to be removed before the log can be deleted.

This command configures the destination for filter log entries for the filter log ID.

Filter logs can be sent to either memory (memory) or to an existing Syslog server definition (syslog).

If the filter log destination is memory, the maximum number of entries in the log must be specified.

The no form of the command deletes the filter log association.

Administratively enables/disables (AdminUp/AdminDown) an entity. Downing an entity does not change, reset or remove any configuration settings or statistics. Many objects must be shutdown before they may be deleted.

The shutdown command administratively downs an entity. Administratively downing an entity changes the operational state of the entity to down.

Unlike other commands and parameters where the default state will not be indicated in the configuration file, shutdown and no shutdown are always indicated in system generated configuration files.

The no form of the command puts an entity into the administratively enabled state.

This command enables the context to configure log summarization. These settings will only be taken into account when syslog is the log destination.

This command defines the key of the index of the minitable. If key information is changed while summary is administratively enabled (no shutdown), the filter summary minitable is flushed and recreated with different key information. Log packets received during the reconfiguration time will be handled as if summary was not active.

The no form of the command reverts to the default parameter.

This command configures a memory filter log to log until full or to store the most recent log entries (circular buffer).

Specifying wrap-around configures the memory filter log to store the most recent filter log entries (circular buffer). When the log is full, the oldest filter log entries are overwritten with new entries.

The no form of the command configures the memory filter log to accept filter log entries until full. When the memory filter log is full, filter logging for the log filter ID ceases.

This command defines the default action to be applied to packets not matching any entry in this ACL filter policy or to packets for that match a PBF/PBR filter entry for which the PBF/PBR target is down and pbr-down-action-override per-entry is set to filter-default-action.

This command chains this filter to a currently active system filter. When the filter is chained to the system filter, the system filter rules are executed first, and the filter rules are only evaluated if no match on the system filter was found.

The no form of the command detaches this filter from the system filter.

Operational note:

If no system filter is currently active, the command has no effect.

This command activates an IPv4 system filter policy. Once activated, all IPv4 ACL filter policies that chain to the system filter (config>filter>ip-filter>chain-to-system-filter) will automatically execute system filter policy rules first.

The no form of the command deactivates the system filter policy.

This command activates an IPv6 system filter policy. Once activated, all IPv6 ACL filter policies that chain to the system filter (config>filter>ipv6-filter>chain-to-system-filter) will automatically execute system filter policy rules first.

The no form of the command deactivates the system filter policy.

This command embeds a previously defined IPv4, IPv6, or MAC embedded filter policy or Hybrid OpenFlow switch instance into this exclusive, template or system filter policy at the specified offset value. Rules derived from the BGP flowspec can also be embedded into template filter policies only.

Note: For MAC filters, embedding is supported for VSD filters or filter entries only.

The embed-filter open-flow ofs-name form of this command enables OpenFlow (OF) in GRT either by embedding the specified OpenFlow switch (OFS) instance with switch-defined-cookie disabled, or by embedding rules with sros-cookie:type “grt-cookie”, value 0 from the specified OFS instance with switch-defined-cookie enabled. The embedding filter can only be deployed in GRT context or be unassigned.

The embed-filter open-flow ofs-name system form of this command enables OF in system filters by embedding rules with sros-cookie:type “system-cookie”, value 0 from the specified OFS instance with switch-defined-cookie enabled. The embedding filter can only be of scope system.

The embed-filter open-flow ofs-name service {service-id | service-name} form of this command enables OF in VPRN/VPLS filters by embedding rules with sros-cookie:type “service-cookie”, value service-id from the specified OFS instance with switch-defined-cookie enabled – per service rules. The embedding filter can only be deployed in the specified VPRN/VPLS service. A single VPLS service can only support OF rules per SAP or per service.

The embed-filter open-flow ofs-name sap sap-id form of this command enables OF in VPLS SAP filters by embedding rules with sros-cookie:type “service-cookie”, value service-id and flow match conditions specifying the sap-id from the specified OFS instance with switch-defined-cookie enabled – per SAP OF rules. The embedding filter must be of type exclusive and can only be deployed on the specified SAP in the context of the specified VPLS service. A single VPLS service can only support OF rules per SAP or per service.

The no embed-filter open-flow ofs-name form of this command removes the OF embedding for the GRT context.

The embed-filter flowspec form of this command enables the embedding of rules derived from BGP flowspec routes into the filter policy that is being configured. The optional router parameter specifies the routing instance source of the BGP flowspec routes; if the parameter is not specifies, the routing instance is derived automatically from the context in which the filter policy is applied. Flowspec rules associated with one routing instance cannot be embedded in a filter applied to an interface of a different routing instance. Also, once flowspec rules associated with one routing instance are embedded into a filter, that filter policy cannot be applied to an interface of a different routing instance.

The no embed-filter flowspec form of this command removes the flowspec filter embedding from this filter policy.

The embed-filter vsd vsd-filter-id command refers to the VSD filter ID encoded _tmnx_vsd_filter-id. The filter is created dynamically and managed exclusively using the Python script, so rules can be inserted and removed in the proper VSD filters. The command is supported with IP, IPv6, and MAC filters. For more information on VSD filter provisioning, automation, and the Python script, refer to the Layer 2 Services and EVPN User Guide.

The no embed-filter vsd vsd-filter-id form of this command removes the VSD filter embedding from this filter policy.

The no embed-filter filter-id form of this command removes the embedding from this filter policy.

Please see the description of embedded filter policies in this guide for further operational details.

This command configures filter-name attribute of a given filter. filter-name, when configured, can be used instead of filter ID to reference the given policy in the CLI.

This command configures the filter policy scope as exclusive, template, embedded or system.

The scope of the policy cannot be changed when:

Changing the scope to/from system is only allowed when a policy is not active and the policy has no entries configured.

The no form of the command sets the scope of the policy to the default of template.

This command configures the low and high watermark for the number of RADIUS shared filters reporting

This command inserts point information for credit control for the filter.

The no form of the command reverts to the default.

This command inserts point information for RADIUS for the filter.

The no form of the command reverts to the default.

This command defines the range of filter and QoS policy entries that are reserved for shared entries received in Flow-Information AVP via Gx interface (PCC rules – Policy and Charging Control). The no form of this command disables the insertion, which will result in a failure of PCC rule installation.

This command configures the insert point for shared host rules from RADIUS.

This command configures the low and high watermark percentage for inserted filter entry usage reporting.

The no form of the command reverts to the default.

This command configures the MAC Filter Policy sub-type as being either normal, ISID or VID.

This command creates or edits an IPv4, IPv6, or MAC filter entry. Multiple entries can be created using unique entry-id numbers within the filter. Entries must be sequenced from most to least explicit.

An entry may not have any match criteria defined (in which case everything matches) but must have at least the keyword action for it to be considered complete. Entries without the action keyword will be considered incomplete and hence will be rendered inactive.

The no form of the command removes the specified entry from the filter. Entries removed from the filter are immediately removed from all services or network ports where that filter is applied.

This command enters the context to configure a primary (no option specified) or secondary (secondary option specified) action to be performed on packets matching this filter entry. An ACL filter entry remains inactive (is not programmed in hardware) until a specific action is configured for that entry.

A primary action supports any filter entry action, a secondary action is used for redundancy and defines a redundant L3 PBR action for an L3 PBR primary action or a redundant L2 PBF action for a L2 PBF primary action.

The no form of this command removes the specific action configured in the context of the action command. The primary action cannot be removed if a secondary action exists.

This command associates a filter log to the current filter policy entry and therefore enables logging for that filter entry.

The filter log must exist before a filter entry can be enabled to use the filter log.

The no form of the command disables logging for the filter entry.

This command allows overriding the default action that is applied for entries with PBR/PBF action defined, when the PBR/PBF target is down.

The no form of the command preserves default behavior when PBR/PBF target is down.

This command configures sticky destination behavior for redundant PBR/PBF actions. Configuring sticky destination has an effect on PBR/PBF actions whether or not a secondary action is configured.

The hold-time-up parameter allows the operator to delay programming of a PBR/PBF action for a specified amount of time. The timer is only started when transitioning from all configured targets being down (that is, the primary target if no secondary target is configured, or both the primary and secondary targets when both are configured) to at least one target being up.

When the timer expires, the primary PBR/PBF action is programmed if its target is up. If the primary PBR/PBF target is down and a secondary PBR/PBF action has been configured and its target is up, then this secondary PBR/PBF action is programmed. In all other cases, no specific programming occurs when the timer expires.

When sticky destination is configured and the secondary PBR/PBF target is up and its associated action is programmed, it is not automatically replaced by the primary PBR/PBF action when its target transitions from down to up. In this situation, programming the primary PBR/PBF action can be forced using the activate-primary-action tools command.

Changing the value of the timer while the timer is running takes effect immediately (that is, the timer is restarted immediately using the new value).

The no form of the command disables sticky destination behavior.

This command (under the config>filter>ip-filter>entry context) sets the context for specific action commands to be performed (under the config>filter>ip-filter>entry>action context) on packets matching this filter entry.

The following commands are available under the config>filter>ip-filter>entry>action context:

This command (under the config>filter>ipv6-filter>entry context) sets the context for specific action commands to be performed (under the config>filter>ipv6-filter>entry>action context) on packets matching this filter entry.

The following commands are available in the config>filter>ipv6-filter>entry>action context:

This command enables the context to configure an extended action for a filter entry's PBR action (configured under config>filter>ip-filter>entry>action and config>filter>ipv6-filter>entry>action context). The extended action is executed in addition to the configured PBR action.

The no version of the command removes the extended action.

Enables and configures the remarking of the DiffServ Code Points of packets matching the criteria of the IPv4/IPv6 filter policy entry, in conjunction with a PBR action. Packets are remarked regardless of QoS-based in-profile or out-of-profile classification. QoS-based DSCP remarking is overridden. If the status of the PBR target is tracked and it is down, the extended action will not be executed; otherwise, the extended action will be performed.

This command specifies that the configured PBR action is applicable to egress processing. The command should only be enabled in ACL policies used by residential subscribers. Enabling egress-pbr on filters not deployed for residential subscribers is not blocked but may lead to unexpected behavior and thus should be avoided.

The no form of this command removes the egress-pbr designation of the filter entry's action.

This command enables cflowd sampling for packets matching this filter entry.

If the cflowd is either not enabled or set to cflowd interface mode, this command is ignored.

The no form disables the cflowd sampling using this filter entry.

This command disables cflowd sampling for packets matching this filter entry, for the IP interface set to cflowd interface mode. This allows the option to not sample specific types of traffic when interface sampling is enabled.

If the cflowd is either not enabled or set to cflowd acl mode, this command is ignored.

The no form of this command enables sampling.

This command enables the context to enter match criteria for the filter entry. When the match criteria have been satisfied the action associated with the match criteria is executed.

A match context may consist of multiple match criteria, but multiple match statements cannot be entered per entry. More precisely, the command can be entered multiple times but this only results in modifying the protocol-id, and does not affect the underlying match criteria configuration.

The no form of the command removes all the match criteria from the filter entry and sets the protocol-id of the match command to none (keyword). As per above, match protocol none is however not equivalent to no match.

This command enables the context to enter match criteria for the filter entry. When the match criteria have been satisfied the action associated with the match criteria is executed.

A match context may consist of multiple match criteria, but multiple match statements cannot be entered per entry. More precisely, the command can be entered multiple times but this only results in modifying the next-header, and does not affect the underlying match criteria configuration.

The no form of the command removes all the match criteria from the filter entry and sets the next-header of the match command to none (keyword). As per above, match next-header none is however not equivalent to no match.

This command configures a DiffServ Code Point (DSCP) name to be used as an IP filter match criterion.

The no form of the command removes the DSCP match criterion.

This command configures a destination address range to be used as a filter policy match criterion.

To match on the IPv4 or IPv6 destination address, specify the address and its associated mask, e.g., 10.1.0.0/16. The conventional notation of 10.1.0.0 255.255.0.0 can also be used for IPv4.

The no form of this command removes the destination IPv4 or IPv6 address match criterion.

This command configures a destination TCP, UDP, or SCTP port number or port range for an IP filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "dst-port eq 0" match criterion, may match non-initial fragments when the destination port value is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the destination port match criterion.

This command configures the flow-label and optional mask match condition.

The no form of the command reverts to the default.

This command specifies match criterion for fragmented packets.

The no form of the command removes the match criterion.

This command enables match on existence of AH Extension Header in the IPv6 filter policy.

The no form of this command ignores AH Extension Header presence/absence in a packet when evaluating match criteria of a given filter policy entry.

This command enables match on existence of ESP Extension Header in the IPv6 filter policy.

The no form of this command ignores ESP Extension Header presence/absence in a packet when evaluating match criteria of a given filter policy entry.

This command enables match on existence of Hop-by-Hop Options Extension Header in the IPv6 filter policy.

The no form of this command ignores Hop-by-Hop Options Extension Header presence/absence in a packet when evaluating match criteria of a given filter policy entry.

Configures matching on ICMP/ICMPv6 code field in the ICMP/ICMPv6 header of an IPv4 or IPv6 packet as a filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "icmp-code 0" match criterion, may match non-initial fragments when the Layer 4 header is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the criterion from the match entry.

This command configures matching on the ICMP/ICMPv6 type field in the ICMP/ICMPv6 header of an IPv4 or IPv6 packet as a filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "icmp-type 0" match criterion, may match non-initial fragments when the Layer 4 header is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the criterion from the match entry.

This command configures matching packets with a specific IP option or a range of IP options in the first option of the IP header as an IP filter match criterion.

The option-type octet contains 3 fields:

1 bit copied flag (copy options in all fragments)

2 bits option class

5 bits option number

The no form of the command removes the match criterion.

This command configures matching packets that contain one or more than one option fields in the IP header as an IP filter match criterion.

The no form of the command removes the checking of the number of option fields in the IP header as a match criterion.

This command configures matching packets that contain any IP options in the IP header as an IP filter match criterion.

The no form of the command removes the checking of IP options in the IP header as a match criterion.

This command configures a TCP/UDP/SCTP source or destination port match criterion in IPv4 and IPv6 CPM (SCTP not supported) and/or ACL filter policies. A packet matches this criterion if the packet TCP/UDP/SCTP (as configured by protocol/next-header match) source OR destination port matches either the specified port value or a port in the specified port range or port-list. .

Operational Note: This command is mutually exclusive with src-port and dst-port commands. Configuring "port eq 0", may match non-initial fragments where the source/destination port values are not present in a packet fragment if other match criteria are also met.

The no form of this command deletes the specified port match criterion.

This command enables match on existence of Routing Type Extension Header type 0 in the IPv6 filter policy.

The no form of this command ignores Routing Type Extension Header type 0 presence/absence in a packet when evaluating match criteria of a given filter policy entry.

This command configures a source IPv4 or IPv6 address range to be used as an IP filter match criterion.

To match on the source IPv4 or IPv6 address, specify the address and its associated mask, for example, 10.1.0.0/16 for IPv4. The conventional notation of 10.1.0.0 255.255.0.0 may also be used for IPv4.

The no form of the command removes the source IP address match criterion.

This command configures a source TCP, UDP, or SCTP port number, port range, or port match list for an IP filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "src-port eq 0" match criterion, may match non-initial fragments when the source port value is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the source port match criterion.

This command enables source route option match conditions. When enabled, this filter should match if a (strict or loose) source route option is present/not present at any location within the IP header, as per the value of this object. The no form of the command removes the criterion from the match entry.

This command configures matching on the ACK bit being set or reset in the control bits of the TCP header of an IP packet as an IP filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The no form of the command removes the criterion from the match entry.

This command configures matching on the SYN bit being set or reset in the control bits of the TCP header of an IP packet as an IP filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The SYN bit is normally set when the source of the packet wants to initiate a TCP session with the specified destination IP address.

The no form of the command removes the criterion from the match entry.

This command enables the configuration context for match lists to be used in filter policies (IOM/FP and CPM).

This command creates a list of IPv4 prefixes for match criteria in IPv4 ACL and CPM filter policies.

The no form of this command deletes the specified list.

Operational Notes:

An ip-prefix-list must contain only IPv4 address prefixes.

An IPv4 prefix match list cannot be deleted if it is referenced by a filter policy.

Please see general description related to match-list usage in filter policies.

This command creates a list of IPv6 prefixes for match criteria in ACL and CPM IPv6 filter policies.

The no form of this command deletes the specified list.

Operational Notes:

An ipv6-prefix-list must contain only IPv6 address prefixes.

An IPv6 prefix match list cannot be deleted if it is referenced by a filter policy.

Please see general description related to match-list usage in filter policies.

This command enables the context to configure auto-generation of address prefixes for IPv4 or IPv6 address prefix match lists. The context in which the command is executed governs whether IPv4 or IPv6 prefixes will be auto-generated.

The no form of this command removes all auto-generation configuration under the apply-path context.

This command configures auto-generation of IPv4 or IPv6 address prefixes (as required by the context the command is executed within) based on the base router BGP instance configuration.

The no form of this command removes the bgp-peers configuration for auto-generation of address prefixes for the specified index value.

This command creates a list of TCP/UDP/SCTP port values or ranges for match criteria in IPv4 and IPv6 ACL and CPM filter policies.

The no form of this command deletes the specified list.

Operational notes:

SCTP port match is supported in ACL filter policies only.

A port-list must contain only TCP/UDP/SCTP port values or ranges.

A TCP/UDP/SCTP port match list cannot be deleted if it is referenced by a filter policy.

Please see general description related to match-list usage in filter policies.

This command adds a port or a range of ports to an existing port match list. The no form of this command deletes the specified port or range of ports form the list.

This command adds an IPv6 address prefix to an existing IPv6 address prefix match list.

The no form of this command deletes the specified prefix from the list.

Operational Notes:

To add set of different prefixes, execute the command with all unique prefixes. The prefixes are allowed to overlap IPv6 address space.

An IPv6 prefix addition will be blocked, if resource exhaustion is detected anywhere in the system because of filter policies that use this IPv6 address prefix list.

This command adds an IPv4 address prefix to an existing IPv4 address prefix match list.

The no form of this command deletes the specified prefix from the list.

Operational Notes:

To add set of unique prefixes, execute the command with all unique prefixes. The prefixes are allowed to overlap IPv4 address space.

An IPv4 prefix addition will be blocked, if resource exhaustion is detected anywhere in the system because of filter policies that use this IPv4 address prefix list.

The action command (under the config>filter>mac-filter>entry context) sets the context for specific action commands to be performed (under the config>filter>mac-filter>entry>action context) on packets matching this filter entry.

The following commands are available under the config>filter>mac-filter>entry>action context:

This command creates the context for entering/editing match criteria for the filter entry and specifies an Ethernet frame type for the entry.

A match context may consist of multiple match criteria, but multiple match statements cannot be entered per entry.

The no form of the command removes the match criteria for the entry-id.

Configures an IEEE 802.1p value or range to be used as a MAC filter match criterion.

When a frame is missing the 802.1p bits, specifying an dot1p match criterion will fail for the frame and result in a non-match for the MAC filter entry.

The no form of the command removes the criterion from the match entry.

Egress dot1p value matching will only match if the customer payload contains the 802.1p bits. For example, if a packet ingresses on a null encapsulated SAP and the customer packet is IEEE 802.1Q or 802.1p tagged, the 802.1p bits will be present for a match evaluation. On the other hand, if a customer tagged frame is received on a dot1p encapsulated SAP, the tag will be stripped on ingress and there will be no 802.1p bits for a MAC filter match evaluation; in this case, any filter entry with a dot1p match criterion specified will fail.

Configures an Ethernet 802.2 LLC DSAP value or range for a MAC filter match criterion.

This is a one-byte field that is part of the 802.2 LLC header of the IEEE 802.3 Ethernet Frame.

The snap-pid field, etype field, ssap and dsap fields are mutually exclusive and may not be part of the same match criteria.

Use the no form of the command to remove the dsap value as the match criterion.

Configures a destination MAC address or range to be used as a MAC filter match criterion.

The no form of the command removes the destination mac address as the match criterion.

Configures an Ethernet type II Ethertype value to be used as a MAC filter match criterion.

The Ethernet type field is a two-byte field used to identify the protocol carried by the Ethernet frame. For example, 0800 is used to identify the IPv4 packets.

The Ethernet type field is used by the Ethernet version-II frames. IEEE 802.3 Ethernet frames do not use the type field. For IEEE 802.3 frames, use the dsap, ssap or snap-pid fields as match criteria.

The snap-pid field, etype field, ssap and dsap fields are mutually exclusive and may not be part of the same match criteria.

The no form of the command removes the previously entered etype field as the match criteria.

This command configures an ISID value or a range of ISID values to be matched by the mac-filter parent. The pbb-etype value for the related SAP (inherited from the ethernet port configuration) or for the related SDP binding (inherited from SDP configuration) will be used to identify the ISID tag.

The no form of this command removes the ISID match criterion.

This command configures the matching of the second tag that is carried transparently through the service. The inner-tag on ingress is the second tag on the frame if there are no service delimiting tags. Inner tag is the second tag before any service delimiting tags on egress but is dependent in the ingress configuration and may be set to 0 even in cases where additional tags are on the frame. This allows matching VLAN tags for explicit filtering or QoS setting when using default or null encapsulations.

The inner-tag is not applicable in ingress on dot1Q SAPs. The inner-tag may be populated on egress depending on the ingress SAP type.

On QinQ SAPs of null and default that do not strip tags inner-tag will contain the second tag (which is still the second tag carried transparently through the service.) On ingress SAPs that strip any tags, inner-tag will contain 0 even if there are more than 2 tags on the frame.

The optional vid-mask is defaulted to 4095 (exact match) but may be specified to allow pattern matching. The masking operation is ((value and vid-mask) = = (tag and vid-mask)). A value of 6 and a mask of 7 would match all VIDs with the lower 3 bits set to 6.

For QoS the VID type cannot be specified on the default QoS policy.

The default vid-mask is set to 4095 for exact match.

This command configures the matching of the first tag that is carried transparently through the service. Service delimiting tags are stripped from the frame and outer tag on ingress is the first tag after any service delimiting tags. Outer tag is the first tag before any service delimiting tags on egress. This allows matching VLAN tags for explicit filtering or QoS setting when using default or null encapsulations.

On dot1Q SAPs outer-tag is the only tag that can be matched. On dot1Q SAPs with exact match (sap 2/1/1:50) the outer-tag will be populated with the next tag that is carried transparently through the service or 0 if there is no additional VLAN tags on the frame.

On QinQ SAPs that strip a single service delimiting tag, outer-tag will contain the next tag (which is still the first tag carried transparently through the service.) On SAPs with two service delimiting tags (two tags stripped) outer-tag will contain 0 even if there are more than 2 tags on the frame.

The optional vid-mask is defaulted to 4095 (exact match) but may be specified to allow pattern matching. The masking operation is ((value & vid-mask) = = (tag & vid-mask)). A value of 6 and a mask of 7 would match all VIDs with the lower 3 bits set to 6.

For QoS the VID type cannot be specified on the default QoS policy.

The default vid-mask is set to 4095 for exact match.

This command configures an IEEE 802.3 LLC SNAP Ethernet Frame OUI zero or non-zero value to be used as a MAC filter match criterion.

The no form of the command removes the criterion from the match criteria.

Configures an IEEE 802.3 LLC SNAP Ethernet Frame PID value to be used as a MAC filter match criterion.

This is a two-byte protocol id that is part of the IEEE 802.3 LLC SNAP Ethernet Frame that follows the three-byte OUI field.

The snap-pid field, etype field, ssap and dsap fields are mutually exclusive and may not be part of the same match criteria.

The snap-pid match criterion is independent of the OUI field within the SNAP header. Two packets with different three-byte OUI fields but the same PID field will both match the same filter entry based on a snap-pid match criteria.

The no form of the command removes the snap-pid value as the match criteria.

Configures a source MAC address or range to be used as a MAC filter match criterion.

The no form of the command removes the source mac as the match criteria.

This command configures an Ethernet 802.2 LLC SSAP value or range for a MAC filter match criterion.

This is a one-byte field that is part of the 802.2 LLC header of the IEEE 802.3 Ethernet Frame.

The snap-pid field, etype field, ssap and dsap fields are mutually exclusive and may not be part of the same match criteria.

The no form of the command removes the ssap match criterion.

This command copies existing filter list entries for a specific filter ID to another filter ID. The copy command is a configuration level maintenance tool used to create new filters using existing filters. It also allows bulk modifications to an existing policy with the use of the overwrite keyword. If overwrite is not specified, an error will occur if the destination policy ID exists.

This command renumbers existing MAC or IPv4/IPv6 filter entries to properly sequence filter entries. This may be required in some cases since the OS exits when the first match is found and executes the actions according to the accompanying action command. This requires that entries be sequenced correctly from most to least explicit.

This command defines a destination in a redirect policy. More than one destination can be configured. Whether a destination IPv4/IPv6 address will receive redirected packets depends on the effective priority value after evaluation.

The most preferred destination is programmed in hardware as action forward next-hop. If all destinations are down (as determined by the supported tests), action forward is programmed in hardware. All destinations within a given policy must be either IPv4 or (exclusive) IPv6. The redirect policy with IPv4 destinations configured can only be used by IPv4 filter policies. The redirect policy with IPv6 destinations configured can only be used by IPv6 filter policies.

This command configures sticky destination behavior for redirect policy. When enabled, the active destination is not changed to a new better destination, unless the active destination goes down or manual switch is forced using the tools>perform>filter>redirect-policy>activate-best-dest command.

The hold-time-up parameter allows the operator to delay programming of the PBR to the most-preferred destination for a specified amount of time when the first destination comes up (action forward remains in place). When the first destination comes up, the timer is started and upon the expiry, the current most-preferred destination is selected (which may differ from the one that triggered the timer to start) and programmed as a sticky PBR destination. Changing the value of the timer, while the timer is running takes immediate effect.

The no form of the command disables sticky destination behavior.

This command configures parameters to perform connectivity ping tests to validate the ability for the destination to receive redirected traffic.

This command specifies the number of consecutive requests that must fail for the destination to be declared unreachable and the time to hold destination unreachable before repeating tests.

This command specifies the amount of time, in seconds, between consecutive requests sent to the far end host.

Specifies the amount of time, in seconds, that is allowed for receiving a response from the far-end host. If a reply is not received within this time the far-end host is considered unresponsive.

Redirect policies can contain multiple destinations. Each destination is assigned an initial or base priority which describes its relative importance within the policy.

This command enables the context to configure SNMP test parameters.

This command specifies the OID of the object to be fetched from the destination.

This command specifies the criterion to adjust the priority based on the test result. Multiple criteria can be specified with the condition that they are not conflicting or overlap. If the returned value is within the specified range, the priority can be disabled, lowered or raised.

This command configures a unicast route test for this destination. A destination is eligible for redirect if a valid unicast route to that destination exists in the routing instance specified by config>filter>redirect-policy>router. The unicast route test is mutually exclusive with other redirect-policy test types.

The test cannot be configured if no router is configured for this redirect policy.

The no form of the command disables the test.

The context to enable URL test parameters. IP filters can be used to selectively cache some web sites.

Return codes are returned when the URL test is performed. Values for the specified range are the return codes which can be given back to the system as a result of the test been performed.

For example, error code 401 for HTTP is “page not found.” If, while performing this test, the URL is not reachable, you can lower the priority by 10 points so that other means of reaching this destination are prioritized higher than the older one.

This command specifies the URL to be probed by the URL test.

This command enhances VRF support in redirect policies. When a router instance is specified, the configured destination tests are run in the specified router instance, and the PBR action is executed in the specified router instance. If no destination is active or if the hardware does not support PBR action “next-hop router”, action forward will be executed (i.e. routing will be performed in the context of the incoming interface routing instance).

The no form of the command preserves backward-compatibility. Tests always run in the “Base” routing instance context, and the PBR action executes in the routing context of the ingress interface that the filter using this redirect policy is deployed on.

Administratively enables/disabled (AdminUp/AdminDown) an entity. Downing an entity does not change, reset or remove any configuration settings or statistics. Many objects must be shutdown before they may be deleted.

The shutdown command administratively downs an entity. Administratively downing an entity changes the operational state of the entity to down.

Unlike other commands and parameters where the default state will not be indicated in the configuration file, shutdown and no shutdown are always indicated in system generated configuration files.

The no form of the command puts an entity into the administratively enabled state.