Packets not moving through linux ethernet bridge
Solution 1
This is a quite old question, but it might be helpful for others.
Linux bridge might drop packets, if not configured correctly. I had a likewise problem and could solve it with the following information:
- https://serverfault.com/questions/347676/linux-bridge-brctl-is-dropping-packets
- https://superuser.com/questions/1211852/why-linux-bridge-doesnt-work
In short, there are options to configure the bridge: e.g.
# do not query iptables for packet routing
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
# no additional processing for multicast packets
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_querier
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
Solution 2
The configuration looks broadly correct (i.e. I can't see anything wildly wrong with it).
You are missing a value for the spanning tree delay, though, which means that the bridge won't forward any packets for (the default value of) 15 seconds after it's been brought up. Fix by adding bridge_fd
to your interface configuration. Use the value 0
if there are no other relevant bridges, or a larger value if there may be loops in your network.
Also, while you're adding values I would suggest you drop the maximum amount of time to wait before moving on during bridge initialisation. I find that setting bridge_maxwait
to one second more than the bridge_fd
value is generally sufficient.
bridge_fd 0
bridge_maxwait 1
Related videos on Youtube
richd
Updated on September 18, 2022Comments
-
richd almost 2 years
I am trying to set up a debian 8.3 machine with eth0 and eth1 bridged, but I can't get packets to traverse the bridge. Currently, eth0 is connected to a LAN with many other hosts, including a DHCP server. Eth1 is connected to a regular switch, with one machine attached.
This is my /etc/network/interfaces:
iface eth0 inet manual iface eth1 inet manual allow-hotplug br0 auto br0 iface br0 inet static bridge_ports eth0 eth1 address 172.16.1.111 netmask 255.255.0.0 broadcast 172.16.255.255 gateway 172.16.1.254 dns-servers 172.16.1.1
/proc/sys/net/ipv4/ip_forward is set to 1.
According to tcpdump running on the test machine connected to the eth1 network, the test machine is sending out DHCP requests, but according to tcpdump running on the bridge host, it is receiving no such requests.
Another host plugged into the switch connected to eth1 can also see that the test machine is indeed sending out DHCP requests, but again, running tcpdump on the bridge host shows no incoming DHCP requests.
When I run tcpdump on eth1 on the bridge host, I do see packets supposedly going out eth1 that originated from the eth0 side of the network, but even though tcpdump claims that those packets are exiting eth1, no host on eth1's network can see any of them.
If I give the test machine connected to eth1 a static ip of 172.16.1.112, it gets no ping response from the bridge host (172.16.1.111). Another host plugged in to the switch can see the test host sending out arp who-has 172.16.1.111 requests, but tcpdump running on eth1 on the bridge host shows no incoming arp requests.
If I delete the bridge all together, assign eth1 an ip of 192.168.200.1 and the test machine plugged in to eth1 an ip of 192.168.200.2, then ping, ssh, and everything else works, indicating that there is nothing wrong with the physical network connections. Also, "ifconfig ethx promisc up" for both interfaces didn't help.
From ifconfig:
br0 Link encap:Ethernet HWaddr 00:22:19:d5:48:a5 inet addr:172.16.1.111 Bcast:172.16.255.255 Mask:255.255.0.0 inet6 addr: fe80::222:19ff:fed5:48a5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1789546 errors:0 dropped:0 overruns:0 frame:0 TX packets:7077 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:89574606 (85.4 MiB) TX bytes:1096756 (1.0 MiB) eth0 Link encap:Ethernet HWaddr 00:22:19:d5:48:a5 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:1796423 errors:0 dropped:6430 overruns:0 frame:0 TX packets:7124 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:123614592 (117.8 MiB) TX bytes:1159358 (1.1 MiB) Interrupt:16 eth1 Link encap:Ethernet HWaddr 00:22:19:d5:48:a6 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:6437 errors:0 dropped:6435 overruns:0 frame:0 TX packets:1782083 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1737578 (1.6 MiB) TX bytes:121076196 (115.4 MiB) Interrupt:17
Other places talked about ebtables, this is what I have:
root@face:~# ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
And, iptables:
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016 *mangle :PREROUTING ACCEPT [160073:12825881] :INPUT ACCEPT [125398:10762899] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [2598:515898] :POSTROUTING ACCEPT [2598:515898] COMMIT # Completed on Fri Mar 25 12:07:16 2016 # Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016 *filter :INPUT ACCEPT [125467:10767745] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [2631:519386] COMMIT # Completed on Fri Mar 25 12:07:16 2016 # Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016 *nat :PREROUTING ACCEPT [59097:4965900] :INPUT ACCEPT [24420:2902790] :OUTPUT ACCEPT [513:27017] :POSTROUTING ACCEPT [513:27017] COMMIT # Completed on Fri Mar 25 12:07:16 2016
brctl stuff:
root@face:~# brctl show bridge name bridge id STP enabled interfaces br0 8000.002219d548a5 no eth0 eth1 root@face:~# bridge link show 2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4 3: eth1 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 root@face:~#
I must be missing something silly, but I can't see what it is. What am I doing wrong?
edits: I can indeed confirm that the iptables-save dump pasted above was the entirety of the running iptables configuration. Now, after a reboot, iptables-save returns nothing.
I also added "bridge_fd 0" and "bridge_maxwait 1" to the br0 section of the interfaces config, but it's been about 10 minutes after a reboot with those changes, and still no traffic is getting anywhere.
I switched the eth0 and eth1 cords around, and it looks like wherever eth0 is plugged in is where the br0 will respond to pings. Still no traffic making its way through, after several minutes of pings.
To further investigate matters, I swapped mac addresses in /etc/udev/rules.d/70-persistent-net.rules so that eth0 is now eth1 and eth1 is has the former eth0 mac address. After a reboot, the br0 still has the mac of what was eth0, and is now eth1, which is still the only side to acknowledge any incoming packets. Can br0 be set to a third, non eth0 or eth1 mac address?
-
roaima over 8 yearsPlease can you either show the output of
iptables -t filter -nvL ; iptables -t nat -nvL ; iptables -t mangle -nvL
or confirm that the actual settings foriptables
matches the saved state you've included in your question (i.e. no rules, and default policy ACCEPT). -
psusi over 8 yearsIs this one of those expensive managed switches? My only guess is that it is and is configured not to allow bridging on that port and so it shuts it down when it sees you try. Wait; another possibility is that eth1 does not allow MAC spoofing. Try switching the order of eth0 and eth1 in your interfaces file so that br0 gets the mac address from eth1 instead of eth0.
-
-
psusi over 8 yearsYou don't need a value for spanning tree delay when spanning tree is not enabled ( as brctl shows ).
-
roaima over 8 years@psusi happy to defer to you on that one. However I've found it helpful to set the delays low/zero even with STP disabled. May be a hangover from an early implementation, I don't recall.
-
forgotstackxpassword about 7 yearsI had it working before was by enabling
NetworkManager,
and then letting my eth0 auto-config, and building the bridge after that. it did not matter if stp was enabled or not enabled. you only need that if you have mutlipe bridges that might get mixed up with each other -
forgotstackxpassword about 7 yearsyou will also need to define routes (unless the /etc/network.. config you put at the top, is certainly working, and up), e.g. see 2nd secdtion on tldp
-
Torxed over 4 years
sysctl -w net.ipv4.conf.br0.bc_forwarding=1
might also work, haven't tried it extensively and I might be wrong because I played around with the stuff in your answer. Butbc_forwarding
should enable brodcast forwarding as well, maybe without having to bother iptables. -
A.B over 2 years@Torxed no,
bc_forwarding
is about turning a received routed IPv4 packet into a broadcast (kernelnewbies.org/Linux_4.19#Networking)