CPU protection supports the ability to explicitly limit the amount of ETH-CFM traffic that arrives at the CPU for processing. ETH-CFM packets that are redirected to the CPU by either a Management Endpoint (MEP) or a Management Intermediate Point (MIP) will be subject to the configured limit of the associated policy. Up to four CPU protection policies may include up to ten individual ETH-CFM-specific entries. The ETH-CFM entries allow the operator to apply a packet-per-second rate limit to the matching combination of level and opcode for ETH-CFM packet that are redirected to the CPU. Any ETH-CFM traffic that is redirected to the CPU by a Management Point (MP) that does not match any entries of the applied policy is still subject to the overall rate limit of the policy itself. Any ETH-CFM packets that are not redirected to the CPU are not subject to this function and are treated as transit data, subject to the applicable QoS policy.
The operator first creates a CPU policy and includes the required ETH-CFM entries. Overlap is allowed for the entries within a policy, first match logic is applied. This means ordering the entries in the correct sequence is important to ensure the correct behavior is achieved. Even though the number of ETH-CFM entries is limited to ten, the entry numbers have a valid range from 1 to 100 to allow for ample space to insert policies between one and other.
Ranges are allowed when configuring the level and the OpCode. Ranges provide the operator a simplified method for configuring multiple combinations. When more than one level or OpCode is configured in this manner the configured rate limit is applied separately to each combination of level and OpCode match criteria. For example, if the levels are configured as listed in Table: Ranges versus levels and OpCodes, with a range of five (5) to seven (7) and the OpCode is configured for 3,5 with a rate of 1. That restricts all possible combinations on that single entry to a rate of 1 packet-per-second. In this example, six different match conditions are created.
| Level | OpCode | Rate |
|---|---|---|
5 |
3 |
1 |
5 |
5 |
1 |
6 |
3 |
1 |
6 |
5 |
1 |
7 |
3 |
1 |
7 |
5 |
1 |
When the policy is created, it must be applied to a SAP or binding within a service for these rates to take effect. This means the rate is on a per-SAP or per-binding basis. Only one policy may be applied to each SAP or binding. The eth-cfm-monitoring option must be configured in order for the ETH-CFM entries to be applied when the policy is applied to the SAP or binding. If this option is not configured, ETH-CFM entries in the policy are ignored. It is also possible to apply a policy to a SAP or binding by configuring eth-cfm-monitoring which does not have an MP. In this case, although these entries are enforced, no packets are redirect to the CPU.
By default, rates are applied on a per-peer basis. This means each individual peer is subject to the rate. Use the aggregate option to apply the rate to all peers. MIPs, for example, only respond to loopback messages and linktrace messages. These are typically on-demand functions and per-peer rate limiting is not required, making the aggregate function more appealing.
The eth-cfm-monitoring and mac-monitoring commands are mutually exclusive and cannot be configured on the same SAP or binding. The mac-monitoring command is used in combination with the traditional CPU protection and is not specific to ETH-CFM rate limiting feature described here.
When an MP is configured on a SAP or binding within a service which allows an external source to communicate with that MP, for example a User to Network Interface (UNI), eth-cfm-monitoring with the aggregate option should be configured on all SAPs or bindings to provide the highest level of rate control.
The example below shows a policy configuration and the application of that policy to a SAP in a VPLS service configured with an MP.
Policy 1 entry 10 limits all ETH-CFM traffic redirected to the CPU for all possible combinations to 1 packet-per-second. Policy 1 entry 20 limits all possible combinations to a rate of zero, dropping all request which match any combination. If entry 20 did not exist then only rate limiting of the entry 10 matches would occur and any other ETH-CFM packets redirected to the CPU would not be bound by a CPU protection rate.
config>sys>security>cpu-protection#
policy 1
eth-cfm
entry 10 level 5-7 opcode 3,5 rate 1
entry 20 level 0-7 opcode 0-255 rate 0
config>service>vpls#
sap 1/1/4:100
cpu-protection 1 eth-cfm-monitoring aggregate
eth-cfm
mip
no shutdown