bridge: add group_fwd_mask support for multicast forwarding (PTP)

[VaishnavSreekumar]

Adds support for configuring the group_fwd_mask attribute in the bridge CNI plugin. This allows the Linux bridge to forward specific link-local multicast frames (e.g., LLDP, PTP, or LACP) that are typically dropped by default.

Why is this needed?

Currently, the Linux kernel allows overriding default bridge behavior via /sys/class/net//bridge/group_fwd_mask, but the CNI bridge plugin lacks an interface to expose this configuration. This is a blocker for high-precision networking environments, specifically:

PTP (IEEE 1588): Used for sub-microsecond clock synchronization.

Telecom Profiles: Environments utilizing G.8275.1 that require specific multicast forwarding.

Changes

Schema Update: Added GroupFwdMask as an optional integer field to the NetConf struct.

Sysfs Integration: Implemented logic to write the user-defined mask to the bridge's sysfs path during setup.

Validation: Included checks to ensure the value is only applied when explicitly set, maintaining default kernel behavior otherwise.

Proposed Configuration

Users can now specify the mask in their CNI configuration file:

JSON

{
  "type": "bridge",
  "name": "mynet",
  "bridge": "cni0",
  "groupFwdMask": 16384,
  "ipam": {
    "type": "host-local",
    "subnet": "10.10.0.0/16"
  }
}

Technical Details

Backward Compatibility: Fully backward compatible; if the field is omitted, no changes are made to the bridge mask.

Target Version: Intended for integration into upcoming Kubernetes network driver releases.

Testing Done

Verified that the group_fwd_mask file in /sys is correctly updated when the CNI is invoked.

Confirmed that PTP traffic (multicast MAC 01-80-C2-00-00-0E) is forwarded when the mask is set appropriately.

Release note

bridge: add group_fwd_mask configuration to control multicast forwarding behavior

[s1061123]

Thank you so much for the PR! We also need document modification because we maintain the document side as well, which is in https://github.com/containernetworking/cni.dev

Could you please create doc PR as well?

[squeed]

Could you add tests? Otherwise, seems reasonable.

[squeed]

This seems unnecessary? You can set .git/info/exclude for local files (doc)

[squeed]

Is n.BrName sanitized here? Could it contain ..? That would be... bad.

[squeed]

Is this useful for other kinds of interfaces? Should we also add this setting to the tuning plugin?

[VaishnavSreekumar]

I have

• Added input validation via helper function
• Improved error message with bridge context
• Added comment clarifying default (0) behavior

Also added a unit test for validation logic
I am working on the corresponding documentation PR in cni.dev and will link it here shortly
Please let me know if you'd like additional tests around bridge setup behavior

[VaishnavSreekumar]

Added documentation PR
This documents the groupFwdMask configuration option for the bridge plugin, including its usage and behavior for enabling forwarding of link-local multicast traffic
[(https://github.com/containernetworking/cni.dev/pull/152)]

Please let me know if those matches what u had in mind

[VaishnavSreekumar]

Is this useful for other kinds of interfaces? Should we also add this setting to the tuning plugin?

That’s a good point.

My understanding is that group_fwd_mask is specific to Linux bridge interfaces, which is why I implemented it in the bridge plugin. For other interface types, this setting wudnt apply in the same way

with that if there are scenario where similar control is useful across different interfaces extending it via the tuning plugin could make sense as a followup enhancement.

Happy to explore that separately if needed.

[squeed]

It looks like you checked in some extra files. Please remove them from the commit.

[squeed]

Ah, good idea. Let's also exclude the name of .. just to be paranoid.

[mlguerrero12]

I think it's better to add tests in bridge_test.go following the existing pattern. You can verify that an add command with this config succeeds, or fails when the value is invalid.