BUM Policer (LAN9645X)

1. Overview

BUM policing — also known as storm control — rate-limits Broadcast, Unknown unicast, and Multicast traffic entering a switch. These three traffic types are flooded to multiple ports by design: broadcast frames reach every port, unknown unicast frames are flooded because the switch has no forwarding entry for the destination, and multicast frames are forwarded to all members of a group. A single misbehaving host or network loop can therefore generate a storm of flooded frames that consumes bandwidth across the entire network.

A BUM policer sets a per-type frame rate limit. Frames that exceed the configured rate are dropped. This protects the network from broadcast storms and limits the impact of excessive flooding while still allowing normal levels of BUM traffic to pass through.

A policer can act on traffic towards the front ports, towards the CPU, or both. See mode below. Policing towards the CPU is the useful direction when the concern is CPU load rather than link bandwidth, for example when frames that the classifier redirects to the CPU are being software-forwarded back into the network.

2. Debugfs Interface

On LAN9645X, BUM policers are configured through a debugfs interface rather than tc commands. The debugfs files are located under:

/sys/kernel/debug/lan9645x_sw/bum

The directory tree is structured as follows:

/sys/kernel/debug/lan9645x_sw/bum
|-- bc
|   |-- cpu_redir_ena
|   |-- frames_per_second
|   |-- known_ena
|   |-- mode
|   `-- unknown_ena
|-- burst
|-- mc
|   |-- cpu_redir_ena
|   |-- frames_per_second
|   |-- ipmc_known_ena
|   |-- ipmc_unknown_ena
|   |-- known_ena
|   |-- mode
|   `-- unknown_ena
|-- no_pol_dis
|-- stats
`-- uc
    |-- cpu_redir_ena
    |-- frames_per_second
    |-- known_ena
    |-- mode
    `-- unknown_ena

There are three policer types: unicast (uc), broadcast (bc), and multicast (mc). Each has its own subdirectory with per-policer configuration files. The burst, no_pol_dis and stats files are global and shared across all policer types.

3. Configuration Parameters

3.1. Per-policer parameters (uc, bc, mc)

File Type Description

known_ena

Boolean

Enable policing of frames with a known destination address.

unknown_ena

Boolean

Enable policing of frames with an unknown destination address.

frames_per_second

Integer

The policing rate in frames per second. The hardware only supports a fixed set of values; the closest supported value is used (see Supported Rate Values).

mode

Integer (0-3)

Selects which ports are policed: 0 = disabled, 1 = CPU port only, 2 = front ports only, 3 = CPU and front ports. Default: 3.

cpu_redir_ena

Boolean

Selects whether frames that the classifier has redirected to the CPU are subject to this policer at all. This is a scope selector, not an action. It does not cause frames to be redirected to the CPU, and it does not change dropping into redirecting. When enabled, CPU-redirected frames are policed and counted. When disabled they bypass the policer. BPDU, IGMP and MLD frames remain exempt even when this is enabled. See no_pol_dis.

The multicast policer (mc) has two additional boolean parameters:

File Type Description

ipmc_known_ena

Boolean

Enable policing of known IP multicast frames.

ipmc_unknown_ena

Boolean

Enable policing of unknown IP multicast frames.

Boolean parameters accept standard kernel boolean values (0/1, Y/N, y/n).

3.2. Global parameters

File Type Description

burst

Integer

The burst size in frames, shared by all policer types. The hardware only supports power-of-two values from 1 to 4096; the closest supported value is used. Default: 128.

no_pol_dis

Boolean

Lifts the exemption that BPDU, IGMP and MLD frames otherwise enjoy. With cpu_redir_ena set, CPU-redirected frames are policed but those three classes are still excepted. Setting no_pol_dis brings every class the classifier redirects to the CPU (VRAP, BPDU, GARP, CCM, IGMP, MLD) into scope. It is global rather than per policer type. Default: 0.

cpu_redir_ena and no_pol_dis are both required to police IGMP or MLD towards the CPU, and neither is sufficient alone.

stats

Read-only

Shows the number of frames that have been policed (dropped) per type.

4. Supported Rate Values

The hardware supports a fixed set of frame rates. When writing a value to frames_per_second, the driver selects the closest supported value. Reading the file back shows the actual value that was applied.

For example:

$ echo "1700" > /sys/kernel/debug/lan9645x_sw/bum/bc/frames_per_second
$ cat /sys/kernel/debug/lan9645x_sw/bum/bc/frames_per_second
2000

The supported values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 1000, 2000, 4000, 8000, 16000, 32000, 64000, 128000, 256000, 512000, and 1024000 frames per second.

The burst parameter similarly snaps to the closest power-of-two value: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, or 4096 frames.

5. Defaults

By default, all policers are disabled (known_ena and unknown_ena are both N). The default rate is 16000 frames per second and the default burst is 128 frames. The default mode is 3 (police both CPU and front ports).

6. Examples

6.1. Enable broadcast policing

Enable the broadcast policer for both known and unknown broadcast frames, using the default rate and burst:

$ echo "1" > /sys/kernel/debug/lan9645x_sw/bum/bc/unknown_ena
$ echo "1" > /sys/kernel/debug/lan9645x_sw/bum/bc/known_ena

Verify the current rate and burst:

$ cat /sys/kernel/debug/lan9645x_sw/bum/bc/frames_per_second
16000
$ cat /sys/kernel/debug/lan9645x_sw/bum/burst
128

Send broadcast frames and check the drop statistics:

$ cat /sys/kernel/debug/lan9645x_sw/bum/stats
UC:          0
BC:      98481
MC:          0

6.2. Set a custom rate

Lower the broadcast policer rate to 2000 frames per second:

$ echo "2000" > /sys/kernel/debug/lan9645x_sw/bum/bc/frames_per_second
$ cat /sys/kernel/debug/lan9645x_sw/bum/bc/frames_per_second
2000

6.3. Enable unknown unicast policing

$ echo "1" > /sys/kernel/debug/lan9645x_sw/bum/uc/unknown_ena

6.4. Police only front ports

To police only the front ports (exclude the CPU port), set the mode to 2:

$ echo "2" > /sys/kernel/debug/lan9645x_sw/bum/bc/mode

6.5. Bound IP multicast control traffic towards the CPU

Limit the IP multicast frames reaching the CPU, without touching front port forwarding. mode 1 selects the CPU direction only, cpu_redir_ena brings CPU-redirected frames into scope, and no_pol_dis lifts the BPDU/IGMP/MLD exemption.

Both IPMC scopes are needed, because two different paths deliver IP multicast to the CPU. ipmc_unknown_ena covers the frames the classifier redirects, and ipmc_known_ena covers the frames that hit a MACV4 or MACV6 entry in the MAC table. Host MDB entries for groups the local stack has joined carry the CPU port, so IPv6 neighbour discovery and MLD arrive by the second route. Note that the plain unknown_ena mask does not apply to any of them, since IGMP and MLD are IP multicast.

$ echo "1"    > /sys/kernel/debug/lan9645x_sw/bum/mc/mode
$ echo "1"    > /sys/kernel/debug/lan9645x_sw/bum/mc/cpu_redir_ena
$ echo "1"    > /sys/kernel/debug/lan9645x_sw/bum/no_pol_dis
$ echo "1"    > /sys/kernel/debug/lan9645x_sw/bum/mc/ipmc_unknown_ena
$ echo "1"    > /sys/kernel/debug/lan9645x_sw/bum/mc/ipmc_known_ena
$ echo "1024" > /sys/kernel/debug/lan9645x_sw/bum/mc/frames_per_second

This is required when running MRP with multicast snooping. See MRP.

Leave the plain known_ena and unknown_ena masks clear. Those cover non-IP multicast, which on a ring running a redundancy protocol carries that protocol’s own control frames. Policing those towards the CPU can break the protocol’s software path.