Bandwidth plugin prevents NP enforcement

[jayanthvn]

Bandwidth plugin uses TC filter and attaches TBF(token bucket filter) queuing discipline (qdisc) on both ingress and egress. But we use NP enforcement with TC filter "clsact" which will collide with B/W plugin.

We are working on providing a solution for co-existence.

[oOraph]

note that there is a pending pr in the bandwidth plugin to change the queuing disc from tbf to htb to add some feature there.

if the solution you find was compatible with this qdisc too that would be great :)

containernetworking/plugins#921

thanks

[benben]

@jayanthvn Did you manage to make any progress on this issue? We would like to use both. Thanks!

[jsferner]

+1

[a7i]

@jayanthvn any updates on this? happy to contribute if you can point us in the right direction

[jayanthvn]

Sorry we aren't planning to support this year due to other commitments. We will review in Q3 26 to update if anything changed with the product prioritization.

@a7i - Happy to take PRs. Haven't spent much time on this but the initial thought process was - since the bandwidth plugin may be enabled either before or after network policy enforcement, the agent must not assume tc state is static or that it owns clsact. Instead, the agent should discover existing qdiscs and tc attachments on the pod veth and attach policy eBPF programs in a qdisc-aware, idempotent manner. If another plugin later replaces qdiscs (for example, when bandwidth shaping is enabled), the agent should re-discover and safely re-attach its filters without modifying or deleting qdiscs it does not own, allowing bandwidth shaping and network policy enforcement to coexist reliably.