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 |
|---|---|---|
|
Boolean |
Enable policing of frames with a known destination address. |
|
Boolean |
Enable policing of frames with an unknown destination address. |
|
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). |
|
Integer (0-3) |
Selects which ports are policed: |
|
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 |
The multicast policer (mc) has two additional boolean parameters:
| File | Type | Description |
|---|---|---|
|
Boolean |
Enable policing of known IP multicast frames. |
|
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 |
|---|---|---|
|
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: |
|
Boolean |
Lifts the exemption that BPDU, IGMP and MLD frames otherwise enjoy. With
|
|
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.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.