Filter policies

Overview

You can use the NFM-P to configure a filter policy to define the network traffic filtering criteria used by routers and switches to allow or deny traffic on a device. You can specify a forwarding action for packets based on the matching criteria configured in the policy. For example, if you configure an ACL IPv6 filter policy, the network device analyzes the data that passes through the interface based on IPv6 matching criteria, compares it to the configuration set in the policy, and if the conditions are met, the traffic is forwarded as specified by the forwarding action. The process stops when the first complete match is found and the action defined in the entry is executed.

You can assign up to two filters to each applicable interface, circuit, or service the filter policy applies to; one in the receive direction and one in the transmit direction.

Note: When an interface, circuit, or service is not configured with a filter policy, all traffic is forwarded by the device. By default, no filters policies are applied by the NFM-P.

ACL IP and ACL IPv6 shared filter entries

RADIUS attributes can be used to enhance a locally configured IPv4 or IPv6 filter list with dynamic entries that can be shared between multiple subscriber hosts.

The ACL IP filter policy and ACL IPv6 filter policy include a High Watermark and Low Watermark configuration which specifies alarm thresholds for dynamically-inserted filter table counts.

Filter policy design considerations

Consider the following when you create NFM-P filter policies:

• The maximum number of filter entries varies depending on the NE and release. Confirm the allowable range of values for the intended device before you assign entry IDs.

• You can create up to 2000 MAC filter policies per managed NE.

• You can create up to 2000 IP filter policies per managed NE.

• The 7705 SAR has the following configuration limits for ACL filter entries:

  • For non-extended range filter entries, the match criteria cannot be defined to match more than 256 packets.

  • For extended range filter entries, there is no limit on the number of packet matches for the defined criteria; however, the total number of unique match criteria in use across all extended range filter entries within the same ACL IP filter cannot exceed eight.

• To expedite the creation of filter policies, you can copy the filter entries of one filter policy to another filter policy; see To copy filter policy filter entries.

ACL MAC and ACL IP SAP and service tunnel forwarding

ACL MAC and ACL IP filters contain options for delivering packets to specific destination SAPs and service tunnels based on the match criteria. Because the forwarding action is specified separately from device configuration, the packet destination name must be entered directly in text form (for example, 1/1/2:500) and validated by the NFM-P.

Consider the following before you create a SAP or service tunnel forwarding filter:

• Although you can configure them on other service types, you should only create these filters on a VPLS. On other service types, packets are dropped.

• You can apply these filters on an ingress, but not an egress, SAP or service tunnel.

• The destination SAP or service tunnel must be on the same service as the device on which the filter is applied.

• The encapsulation type of the destination SAP and the associated port must be the same. Supported encapsulations are Ethernet Null, dot1q, QinQ, BCP, bridged Ethernet, FR, and ATM.

Embedded filter policy support

The NFM-P supports the use of embedded policies in ACL MAC, ACL IP, and ACL IPv6 filter policies that allow you to define a common set of filter policy rules that can then be embedded, or nested in one or more ACL filter policies.

When an exclusive or template filter policy that embeds one or more embedded filter policies is created, absolute values for all filter policy entries for both embedded and embedding filters are preserved. In the case of a conflict between entries (for instance, the same policy entry index), a higher priority filter entry is activated. The embedding filter has the highest priority, allowing its filter entries to always overwrite any embedded filter entries. This allows for customization of the common embedded filter policy rules within the embedding filter.

Any edits made to an embedded policy are automatically applied to all embedding filter policies that use the embedded filter policy.

The system ensures that system and hardware resources exist when a new embedded filter policy is created, changed or embedded by another filter policy, and either fails the configuration attempt or does not embed the embedded filter (depending on what resources are exhausted). An embedded filter is never embedded partially into another filter. If a change occurs to an already embedded filter fails due to a lack of hardware resources, the embedded filter will be removed from the embedding filter.

See To configure an embedding filter with embedded filter policies for information about configuring embedded filter policies.

ACL MAC, ACL IP, and ACL IPv6 web portal redirects

ACL MAC, ACL IP, and ACL IPv6 filter policies contain options for redirecting hosts to a URL address. The 7750 SR-7, 7750 SR-12, and 7950 XRS open a new connection to the specified web portal. The host can use the web portal to create or modify a service profile. The web portal updates the ACL policy to remove the redirection policy.

Note: The 7750 SR-1 does not support web portal redirect.

ACL MAC, ACL IP, and ALC IPv6 log filter configurations

You can optionally create the following policy types for ACL MAC, ACL IP, and IPv6 filter entries that can be used to specify where and how device related log information is collected and stored for a device. You can analyze the logs and extracted information on an ongoing basis to ensure your network is secure, or as required, to initiate the appropriate remediation action. See the appropriate SR node documentation for information about accessing log information on the SR device.

• Syslog policy that is used by the ACL Filter Log policy; the Syslog policy defines the destination details for log messages such as the target address and target UDP port, when the ACL Filter Log policy specifies a Syslog destination for storing log information. See To configure a Syslog policy.

• ACL Filter Log policy that defines where log information for all actions performed on 7210 SAS, 7705 SAR, and 7x50 NEs which match ACL MAC, ACL IP, and ACL IPv6 filter entry criteria are written (memory or Syslog), how many log entries can be stored, and what action is performed when the log files meet the specified threshold. See To configure a ACL Filter Log policy.

Redirect filters

A redirect filter policy allows operators to specifying multiple redirect target destinations and define health check test methods used to validate the ability for a given destination to receive redirected traffic. This destination monitoring allows a router to react to target destination failures. Operators can define IPv4 and IPv6 filter policies by specifying destinations to be IPv4 or IPv6 addresses respectively, and then referencing the redirect filter policy in the appropriate line card filter.

Reachability tests for specific destination addresses can be configured, including SNMP, URL, ping, and unicast route reachability. When a unicast route reachability test is configured, a destination becomes eligible for redirect policy destination selection only when the destination is reachable within the routing context that the policy is applied.

See To configure a Redirect Filter policy for information regarding configuring a redirect filter policy.

System filters

A system filter allows operators to configure a single set of filter policy rules that can then be activated in a system and used by other exclusive or template ingress IPv4 or IPv6 filter policies. When a system filter policy is activated (or when its configuration is changed), its entries are automatically downloaded to all line cards in the system. For packets to match system filter policy entries, an operator “chains” deployed IPv4/IPv6 ingress filter policies to the system filter. In this way, system filter entries are not duplicated into the chained filters. By employing such a chain, the active system filter policy rules are evaluated first. If a match occurs, the chained system filters are ignored. If no match occurs, only then are the rules of any chained filter policies evaluated. This allows a system filter policy to be used for implementing system blacklist rules, or security rules when multiple filter policies are required for other operational reasons (such as PBR).

Nokia recommends using a system filter policy with drop/forward actions. Other actions, for example, PBR actions or redirection to ISAs, should not be used unless the system filter policy is activated only in filters used by services that support such actions. Failure to observe this restriction can lead to undesired behavior, since system filter actions are not verified against the services that the chaining filters are deployed for.

The system filter policy supports all IPv4/IPv6 filter policy match rules and actions, however, system policy entries cannot be LI or mirror sources. The system filter policy also does not support Radius, flowspec, or Gx inserted entries. Note that a system filter policy also requires chassis mode D to be set on an NE to which it is deployed.

See To configure a System Filter for information regarding configuring a system filter policy.