The system supports four different filter policies:
scope template
scope exclusive
scope embedded
scope system
Each scope provides different characteristics and capabilities to deploy a filter policy on a single interface, multiple interfaces or optimize the use of system resources or the management of the filter policies when sharing a common set of filter entries.
Template and Exclusive
A filter policy of scope template can be re-used across multiple interfaces. This filter policy uses a single set of resources per line card regardless of how many interfaces use it. Template filter policies used on access interfaces consume resources on line cards where the access interfaces are configured only. A filter policy of scope template is the most common type of filter policies configured in a router.
A filter policy of scope exclusive defines a filter dedicated to a single interface. An exclusive filter allows the highest level of customization but uses the most resources on the system line cards as it cannot be shared with other interfaces.
Embedded
To simplify the management of filters sharing a common set of filter entries, the operator can create a filter policy of scope embedded. This filter can then be included in (embedded into) a filter of scope template, exclusive or system.
Using filter scope embedded, a common set of filter entries can be updated in a single place and deployed across multiple filter policies. The scope embedded is supported for IPv4 and IPv6 filter policies.
A filter policy of scope embedded is not directly downloaded to a line card and cannot be directly referenced in an interface. However, this policy helps the network operator provision a common set of rules across different filter policies.
The following rules apply when using filter policy of scope embedded:
The operator explicitly defines the offset at which to insert a filter of scope embedded in a template, exclusive or system filter. The embedded filter entry-id X becomes entry-id (X + offset) in the main filter.
Multiple filter policies of scope embedded can be included (embedded into) in a single filter policy of scope template, exclusive or system.
The same filter policy of scope embedded can be included in multiple filter policies of scope template, exclusive or system.
Configuration modifications to embedded filter policy entries are automatically applied to all filter policies that embed this filter.
The system performs a resource management check when a filter policy of scope embedded is updated or embedded in a new filter. If resources are not available, the configuration is rejected. In rare cases, a filter policy resource check may pass but the filter policy can still fail to load because of a resource exhaustion on a line card (for example, when other filter policy entries are dynamically configured by applications like RADIUS in parallel). If that is the case, the embedded filter policy configured is deactivated (configuration is changed from activate to inactivate).
An embedded filter is never embedded partially in a single filter and resources must exist to embed all the entries in a specific exclusive, template or system filter. However, an embedded filter may be embedded only in a subset of all the filters it is referenced into, only those where there are sufficient resources available.
Overlapping of filter entries between an embedded filter and a filter of scope template, exclusive or system filter can happen but should be avoided. It is recommended instead that network operators use a large enough offset value and an appropriate filter entry-id in the main filter policy to avoid overlapping. In case of overlapping entries, the main filter policy entry overwrites the embedded filter entry.
Configuring a default action in a filter of scope embedded is not required as this information is not used to embed filter entries.
Figure: Embedded Filter Policy shows a configuration with two filter policies of scope template, filter 100 and 200 each embed filter policy 10 at a different offset:
Filter policy 100 and 200 are of scope template.
Filter policy 10 of scope embedded is configured with 4 filter entries: entry-id 10, 20, 30, 40.
Filter policy 100 embed filter 10 at offset 0 and includes two additional static entries with entry-id 20010 and 20020.
Filter policy 200 embed filter 10 at offset 10000 and includes two additional static entries with entry-id 100 and 110.
As a result, filter 100 automatically creates entry 10, 20, 30, 40 while filter 200 automatically creates entry 10010, 10020, 10030, 10040. Filter policy 100 and 200 consumed in total 12 entries when both policies are installed in the same line card.
*A:7750>config>filter# info
----------------------------------------------
ip-filter 10 name "10" create
scope embedded
entry 10 create
... ...
exit
entry 20 create
... ...
exit
entry 30 create
... ...
exit
entry 40 create
... ...
exit
exit
ip-filter 100 name "100" create
scope template
embed-filter 10
entry 20010 create
... ...
exit
entry 20020 create
... ...
exit
exit
ip-filter 200 name "200" create
scope template
embed-filter 10 offset 10000
entry 100 create
... ...
exit
entry 110 create
... ...
exit
exit
----------------------------------------------
System
The filter policy of scope system provides the most optimized use of hardware resources by programming filter entries after the line cards regardless of how many IPv4 or IPv6 filter policies of scope template or exclusive use this filter. The system filter policy entries are not duplicated inside each policy that uses it, instead, template or exclusive filter policies can be chained to the system filter using the chain-to-system-filter command.
When a template of exclusive filter policy is chained to the system filter, system filter rules are evaluated first before any rules of the chaining filter are evaluated (that is chaining filter's rules are only matched against if no system filter match took place).
The system filter policy is intended primarily to deploy a common set of system-level deny rules and infrastructure-level filtering rules to allow, block, or rate limit traffic. Other actions like, for example, PBR actions, or redirect to ISAs should not be used unless the system filter policy is activated only in filters used by services that support such action. The ‟nat” action is not supported and should not be configured. Failure to observe these restrictions can lead to unwanted behavior as system filter actions are not verified against the services the chaining filters are deployed for. System filter policy entries also cannot be the sources of mirroring.
System filter policies can be populated using CLI, SNMP, Netconf, Openflow and Flowspec. System filter policy entries cannot be populated using RADIUS or Gx.
An example for IPv4 system filter configuration is shown as follows:
System filter policy 10 includes a single entry to rate limit NTP traffic to the Infrastructure subnets.
Filter policy 100 of scope template is configured to use the system filter using the chain-to-system-filter command.
*7750>config>filter# info
----------------------------------------------
ip-filter 10 name "10" create
scope system
entry 10 create
description "Rate Limit NTP to the Infrastructure"
match protocol udp
dst-ip ip-prefix-list "Infrastructure IPs"
dst-port eq 123
exit
action
rate-limit 2000
exit
exit
exit
ip-filter 100 name "100" create
chain-to-system-filter
description "Filter scope template for network interfaces"
exit
system-filter
ip 10
exit
----------------------------------------------