br_netfilter module loading or incorrect sysctl settings that block Layer 2 traffic inspection. Restoring connectivity requires verifying module availability and enabling specific netfilter hooks to allow ARP frames to traverse the bridge correctly.
Understanding Bridge Filtering and ARP
A Linux bridge operates at Layer 2 of the OSI model, forwarding frames based on MAC addresses. However, modern Linux networking often requires interaction with Layer 3 tools likeiptables or nftables. To enable this interaction, the kernel uses a subsystem called br_netfilter. Without this subsystem, the bridge acts as a blind switch, ignoring firewall rules but also potentially dropping packets if certain security modules or eBPF programs interfere. ARP (Address Resolution Protocol) is critical because it maps IP addresses to MAC addresses. If ARP requests are dropped, hosts cannot discover each other, leading to complete isolation despite correct physical or virtual cabling.
The core problem is often that br_netfilter is not loaded by default in minimal container environments or custom kernels. When this module is absent, the bridge does not pass ARP packets through the netfilter hooks, which can cause unexpected drops if other network policies are active. Additionally, even with the module loaded, specific sysctl parameters may restrict bridged traffic.
Verifying Module Availability
The first diagnostic step is to confirm whether thebr_netfilter kernel module is present and loaded. You can check for its existence using the lsmod command. If the module is not listed, you must load it manually.
```bash
sudo modprobe br_netfilter
```
After loading the module, verify it is active by running:
```bash
lsmod | grep br_netfilter
```
If the output shows br_netfilter, the module is successfully loaded. In persistent setups, such as those managed by systemd or container runtimes, you should ensure this module is added to your system’s module configuration files to prevent dropout after reboot. For example, adding br_netfilter to /etc/modules-load.d/br-netfilter.conf ensures automatic loading on boot.
Checking Sysctl Configuration
Once the module is loaded, you must verify the sysctl settings that control how the bridge interacts with netfilter. Two key parameters are essential:bridge-nf-call-iptables and bridge-nf-call-ip6tables. These settings determine whether IPv4 and IPv6 packets traversing the bridge are passed to iptables for processing. While ARP is technically Layer 2, the br_netfilter module relies on these hooks to manage packet flow and state tracking.
Check the current values using:
```bash
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.bridge.bridge-nf-call-ip6tables
```
Both values should be set to 1. If they are 0, the bridge ignores netfilter rules, which can lead to inconsistent behavior depending on your network setup. To enable them permanently, add the following lines to /etc/sysctl.conf:
```text
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
```
Apply the changes immediately with:
```bash
sudo sysctl -p
```
This configuration ensures that the bridge properly handles packets that require Layer 3 inspection, including those involved in address resolution processes managed by higher-level network stacks.
Diagnosing Interface State and Rules
If ARP is still dropped, inspect the bridge interface itself usingip link show. Ensure that all slave interfaces are in the UP state. A common mistake is having a veth pair or physical NIC down while the bridge remains up. Use ip addr show dev <bridge-name> to verify IP assignments if any are configured on the bridge device itself.
Refer to How to get the IP address of veth in a bridge? for detailed steps on managing interface states and addressing. Incorrect MTU settings on slave interfaces can also fragment ARP packets, causing them to be discarded. Check MTU consistency across all bridge members using ip link show.
Additionally, review any existing iptables rules that might explicitly drop ARP traffic. Although standard iptables filters do not natively handle ARP packets directly via protocol number, some configurations use arp_tables or eBPF programs. Check for rules targeting the bridge interface specifically. If you suspect NAT issues affecting bridged traffic, consult IPTables: NAT Source Address Bridge Interface on Linux for guidance on adjusting source address translation rules that might inadvertently impact bridged segments.
Testing Connectivity
To validate the fix, generate an ARP request from one host to another within the bridge domain. Usearping or ping to trigger address resolution. For example:
```bash
arping -I dmesg for any bridge-related errors or warnings about packet drops. Also, ensure that no external firewalls or cloud provider security groups are interfering with the underlying virtual network infrastructure.
For related troubleshooting on VLAN sub-interfaces, see Bridging VLAN sub-interfaces, as misconfigured VLAN tagging can also result in apparent ARP failures.
Frequently Asked Questions
Why is br_netfilter not loaded by default?
In many minimal installations or container environments, only essential kernel modules are loaded to save resources. Since br_netfilter is primarily needed for advanced firewall integration, it is often omitted from default configurations. Administrators must explicitly load it when requiring Layer 3 filtering on bridged networks.
Can I use nftables instead of iptables with br_netfilter?
Yes, br_netfilter works with both iptables and nftables. The sysctl parameters bridge-nf-call-iptables and bridge-nf-call-ip6tables control the hook injection regardless of the backend tool. However, nftables offers more efficient rule management for complex bridged scenarios.
What happens if bridge-nf-call-iptables is set to 0?
Setting this value to 0 disables the passage of bridged packets through the iptables filter chain. This can improve performance slightly but removes the ability to apply firewall rules to bridged traffic. It may also cause inconsistencies if other network components expect filtered traffic.
How do I check if ARP packets are actually being dropped?
Use tcpdump -i <bridge-name> arp to capture ARP traffic on the bridge interface. If you see requests without replies, or if the counter for dropped packets increases in ip -s link show, it indicates a filtering issue. Comparing captures on slave interfaces versus the bridge can isolate where the drop occurs.
Does this issue affect Docker containers?
Yes, Docker uses Linux bridges extensively. If br_netfilter is not enabled, Docker’s port mapping and internal DNS resolution may fail due to dropped ARP or ICMP packets. Ensuring br_netfilter is loaded and sysctls are set is a prerequisite for stable Docker networking.