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 manualiface eth1 inet manualallow-hotplug br0auto br0iface 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 -LBridge table: filterBridge chain: INPUT, entries: 0, policy: ACCEPTBridge chain: FORWARD, entries: 0, policy: ACCEPTBridge 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 showbridge name     bridge id               STP enabled     interfacesbr0             8000.002219d548a5       no              eth0                                                        eth1root@face:~# bridge link show2: 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?

askedMar 25, 2016 at 16:31
richd's user avatar
3
  • 1
    Please can you either show the output ofiptables -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).CommentedMar 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.CommentedMar 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 enablingNetworkManager, and then letting the gui inkde 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.CommentedApr 2, 2017 at 23:21

2 Answers2

9

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 routingecho 0 > /proc/sys/net/bridge/bridge-nf-call-iptables# no additional processing for multicast packetsecho 0 > /sys/devices/virtual/net/br0/bridge/multicast_querierecho 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
answeredOct 29, 2018 at 13:08
smilee89's user avatar
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. Butbc_forwarding should enable brodcast forwarding as well, maybe without having to bother iptables.CommentedJan 10, 2020 at 19:21
  • @Torxed no,bc_forwarding is about turning a receivedrouted IPv4 packet into a broadcast (kernelnewbies.org/Linux_4.19#Networking)CommentedMar 23, 2022 at 7:40
  • Thank you! This pointed me to why my bridged wifi hotspot interface wouldn't allow any clients traffic pass.CommentedApr 7, 2023 at 19:05
3

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 addingbridge_fd to your interface configuration. Use the value0 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 settingbridge_maxwait to one second more than thebridge_fd value is generally sufficient.

bridge_fd 0bridge_maxwait 1
answeredMar 25, 2016 at 17:08
Chris Davies's user avatar
4
  • 2
    You don't need a value for spanning tree delay when spanning tree is not enabled ( as brctl shows ).CommentedMar 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.CommentedMar 25, 2016 at 21:08
  • I had it working before was by enablingNetworkManager, 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 otherCommentedApr 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 ontldpCommentedApr 2, 2017 at 23:30

You mustlog in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.