Protecting the control and management plane of each routing switch in the data center fabric (access leaf, border leaf, spine, and so on) from unauthorized or out-of-profile sources of traffic is important. Without control plane protection policies, routers are vulnerable to attacks on the data center infrastructure and performance degradation can occur due to misconfiguration.
The SR Linux supports a special Access Control List (ACL) type called a cpm-filter for control plane protection. There are separate cpm-filters for IPv4 traffic and for IPv6 traffic. The entries of each cpm-filter are installed on each line card and in the Control Processing Module (CPM) software. There are different types of cpm-filter actions that can be applied and all actions are not relevant at all locations. Section 5.2 defines each action and how to configure it.
The information and configuration in this chapter are based on SR Linux Release 19.11.
ACLs support primary and secondary actions. There are two mutually exclusive primary actions:
There are three optional secondary actions that are supported in any combination. Secondary actions extend the primary action with additional packet handling operations.
![]() | Note: The accept+log action is not supported on 7220 IXR-D1, D2, and D3 systems. Only the action drop+log true is supported. |
CPM filter rules that apply a system-cpu-policer and/or distributed-policer action do not directly specify the policer parameters. Instead, the rules refer to a generically defined policer under the ACL configuration tree. This allows different CPM filter entries, even across multiple ACLs, to use the same policer if needed. Optionally, each policer can be configured as entry-specific. This means that a different policer instance is used by each referring filter entry, even if they are part of the same ACL.
CPM filter ACL actions are applied to the following traffic flows:
The startup configuration of a new SR Linux router includes a default IPv4 cpm-filter policy and a default IPv6 cpm-filter policy. These default policies block packets associated with any protocol that is not supported by the SR Linux operating system. However, they do not limit the sending sources or enforce any rate limits aside from ICMPv4/ICMPv6 traffic, which is subject to an aggregate rate limit of 1000 pps. The default policies should be modified to add these additional restrictions, and to allow protocols associated with NetOps Development Kit (NDK) applications, if applicable.
The following examples define how to restrict the source subnets for incoming SSH traffic associated with remotely originated TCP connections to a specified IP address.
Example 1 (IPv4 address of 192.0.2.0/24)
Example 2 (IPv6 address of 2001:db8:3200/48)