5

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?

Improve this question
3
  • 1
    Please 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 for iptables matches the saved state you've included in your question (i.e. no rules, and default policy ACCEPT).
    – roaima
    Mar 25, 2016 at 17:08
  • 1
    Is 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
    Mar 25, 2016 at 20:43
  • I'm facing a similar situation now, because I had a working bridge, on the exact some configuration as you, but the only way I had it working before was by enabling NetworkManager, and then letting the gui in kde autmatically set up my network, and then I used brctl to create the bridge. When I do it the "classic way," exactly as you have above (and great write-up btw), I have exactly the same problem.
    – forgotstackxpassword
    Apr 2, 2017 at 23:21

2 Answers 2

Reset to default
6

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:

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
Improve this answer
3
  • 1
    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. But bc_forwarding should enable brodcast forwarding as well, maybe without having to bother iptables.
    – Torxed
    Jan 10, 2020 at 19:21
  • @Torxed no, bc_forwarding is about turning a received routed IPv4 packet into a broadcast (kernelnewbies.org/Linux_4.19#Networking)
    – A.B
    Mar 23, 2022 at 7:40
  • Thank you! This pointed me to why my bridged wifi hotspot interface wouldn't allow any clients traffic pass.
    – lkraav
    Apr 7 at 19:05
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
Improve this answer
4
  • 2
    You don't need a value for spanning tree delay when spanning tree is not enabled ( as brctl shows ).
    – psusi
    Mar 25, 2016 at 20:40
  • @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.
    – roaima
    Mar 25, 2016 at 21:08
  • I 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
    Apr 2, 2017 at 23:22
  • you 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
    – forgotstackxpassword
    Apr 2, 2017 at 23:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .