Thanks Florian, very appreciate for your comments. I'm not familiar with the bridge netfilter history and usage. I will summary and update the doc with your comments in next version(with the other's comments). Hope you could review it again. Regards Hangbin On Fri, Oct 27, 2023 at 02:31:30PM +0200, Florian Westphal wrote: > Hangbin Liu <liuhangbin@xxxxxxxxx> wrote: > > [ cc nf-devel ] > > > The current bridge kernel doc is too old. It only pointed to the > > linuxfoundation wiki page which lacks of the new features. > > Indeed, thanks for taking time to improve the documention. > > > +Netfilter > > +========= > > + > > +The bridge netfilter module allows packet filtering and firewall functionality > > +on bridge interfaces. As the Linux bridge, which traditionally operates at > > +Layer 2 and connects multiple network interfaces or segments, doesn't have > > +built-in packet filtering capabilities. > > No, this is not what this module does. br_netfilter module should NEVER > be used. I'd love to remove it, but its very popular unfortunately. > > Suggestion: > > The bridge netfilter module is a legacy feature that allows to filter bridged > packets with iptables and ip6tables. Its use is discouraged. Users > should consider using nftables for packet filtering. > > The older ebtables tool is more feature-limited compared to nftables, but > just like nftables it doesn't need this module either to function. > > The br_netfilter module intercepts packets entering the bridge, performs > minimal sanity tests on ipv4 and ipv6 packets and then pretends that > these packets are being routed, not bridged. br_netfilter then calls > the ip and ipv6 netfilter hooks from the bridge layer, i.e. ip(6)tables > rulesets will also see these packets. > > br_netfilter is also the reason for the iptables 'physdev' match: > This match is the only way to reliably tell routed and bridged packets > apart in an iptables ruleset. > > Side note: > > You might want to somehow massage the bits below, perhaps it would be > good to have the historical context as to why br_netfilter exists in the > first place. > > > +With bridge netfilter, you can define rules to filter or manipulate Ethernet > > +frames as they traverse the bridge. These rules are typically based on > > +Ethernet frame attributes such as MAC addresses, VLAN tags, and more. > > +You can use the *ebtables* or *nftables* tools to create and manage these > > +rules. *ebtables* is a tool specifically designed for managing Ethernet frame > > +filtering rules, while *nftables* is a more versatile framework for managing > > +rules that can also be used for bridge filtering. > > ebtables and nftables will work fine without the br_netfilter module. > > iptables/ip6tables/arptables do not work for bridged traffic because they > plug in the routing stack. > > nftables rules in ip/ip6/inet/arp families won't see traffic that is > forwarded by a bridge either, but thats very much how it should be. > > br_netfilter is only needed if users, for some reason, need to use > ip(6)tables to filter packets forwarded by the bridge, or NAT bridged > traffic. > > Historically the feature set of ebtables was very limited (it still is), > so this module was added to pretend packets are routed and invoke the > ipv4/ipv6 netfilter hooks from the bridge so users had access to the > more feature-rich iptables matching capabilities (including conntrack). > > nftables doesn't have this limitation, pretty much all features work > regardless of the protocol family. > > > +The bridge netfilter is commonly used in scenarios where you want to apply > > +security policies to the traffic at the data link layer. This can be useful > > +for segmenting and securing networks, enforcing access control policies, > > +and isolating different parts of a network. > > See above, for pure link layer filtering, this module isn't needed.
