why linux bridge doesn't work

Question

I'd like to connect two pairs of veth on a linux bridge, and try to ping from one pair to the other, to test the bridge function.

The below script is tested on several machines, some of them work as expected and the others do not.

After some troubleshooting, I've found that:

• brctl showstp <br> tells both ports are in forwarding state
• brctl showmacs <br> shows both local and external macs correctly

Questions:

• Why the bridge won't forward packets? (don't know differencies among those machines)
• Or, how should I keep troubleshooting?

Any suggestions are appreciated.

--

#!/bin/bash

BR=br1

ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3
ip link add $BR type bridge
ip netns add ns0
ip netns add ns1
ip link set veth0 netns ns0
ip link set veth2 netns ns1
ip link set veth1 master $BR
ip link set veth3 master $BR
ip link set $BR up
ip link set veth1 up
ip link set veth3 up
ip netns exec ns0 ip link set veth0 up
ip netns exec ns1 ip link set veth2 up
ip netns exec ns0 ip addr add 172.30.0.1/24 dev veth0
ip netns exec ns1 ip addr add 172.30.0.2/24 dev veth2

ip netns exec ns0 ping 172.30.0.2

EDIT

tcpdump -ni br1 shows:

23:23:31.097396 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:23:31.097431 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
23:23:31.097443 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 1, length 64
23:23:32.096804 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 2, length 64
23:23:33.096803 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 3, length 64

ip netns exec ns1 tcpdump -ni veth2 shows

23:33:58.198790 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:33:58.198823 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
^C

The bridge is bridging arp packets but not bridging icmp packets?

Answer 1

I've solved this.

It turns out to be iptables who drops packets on bridge. Packets travel through FORWARD chain of the filter table, not matching any rules of it, so that the default policy DROP applies.

To test if it is caused by iptables, we can try

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

then see if the bridge works.

Answer 2

This was exactly my issue when troubleshooting a manually created bridge for use with lxd. I added the following rules to /etc/iptables/rules.v4:

-A FORWARD -o br0 -m comment --comment "allow packets to pass from lxd lan bridge" -j ACCEPT
-A FORWARD -i br0 -m comment --comment "allow input packets to pass to lxd lan bridge" -j ACCEPT