Difference between revisions of "Bridge doesn't forward packets"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(no first level headings please)
m (Another Problem Case)
 
(4 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Sometimes bridge can mysteriously drop the packets and not forward them.
+
Sometimes a bridge can mysteriously drop packets and not forward them.
e.g. eyck user experienced a problem when some of the broadcasts were not delivered to VE via the bridge.
+
e.g. eyck user experienced a problem when some of the broadcasts were not
 +
delivered to container via the bridge.
  
 
Original report and the thread: [http://forum.openvz.org/index.php?t=tree&th=4052& forum thread]
 
Original report and the thread: [http://forum.openvz.org/index.php?t=tree&th=4052& forum thread]
Line 6: Line 7:
 
== Simplest configuration ==
 
== Simplest configuration ==
  
VE #101 with veth interface (veth101.0) connected to eth0 physical interface via bridge.
+
Container #101 with veth interface (veth101.0) connected to eth0 physical interface via bridge.
  
 
== Problem statement ==
 
== Problem statement ==
  
We faced a situation when some of the broadcast packets were not delivered to the VE.
+
We faced a situation when some of the broadcast packets were not delivered to
Actually it could happen with any packets, not with the broadcasts only. But broadcasts are
+
the container. Actually it could happen with any packets, not with the
simpler and obviously should have been delivered to all the networking interfaces with no doubt.
+
broadcasts only. But broadcasts are simpler and obviously should have been
 +
delivered to all the networking interfaces with no doubt.
  
Using tcpdump we see that BOOTP/DHCP request is visible on br0 interface in the host system (VE0):
+
Using tcpdump we see that BOOTP/DHCP request is visible on br0 interface in
 +
the host system ([[CT0]]):
 
   15:21:52.258220 00:1b:d5:2c:bf:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67:
 
   15:21:52.258220 00:1b:d5:2c:bf:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67:
 
     BOOTP/DHCP, Request from 00:1b:d5:2c:bf:38, length 308
 
     BOOTP/DHCP, Request from 00:1b:d5:2c:bf:38, length 308
Line 20: Line 23:
 
     BOOTP/DHCP, Reply, length 300
 
     BOOTP/DHCP, Reply, length 300
  
However, eth0 inside VE receives only 2nd packet with BOOTP/DHCP reply and doesn't see the 1st one with the request itself:
+
However, eth0 inside the container received only 2nd packet with a BOOTP/DHCP reply and doesn't see the 1st one with the request itself:
 
   15:21:52.291145 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:
 
   15:21:52.291145 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:
 
     BOOTP/DHCP, Reply, length 300
 
     BOOTP/DHCP, Reply, length 300
Line 26: Line 29:
 
== Resolution ==
 
== Resolution ==
  
It is not obvious at all, but bridges (though have own ebtables filters) do also call iptables FORWARD chain when forwarding packets between interfaces.
+
It is not obvious at all, but bridges (though they have their own ebtables filters) do also call iptables FORWARD chain when forwarding packets between interfaces.
 
Thus your FORWARD iptables rules should allow all the packets which are supposed to go through.
 
Thus your FORWARD iptables rules should allow all the packets which are supposed to go through.
  
Line 32: Line 35:
 
   iptables -A FORWARD -d 255.255.255.255 -j ACCEPT
 
   iptables -A FORWARD -d 255.255.255.255 -j ACCEPT
 
to fix the issue.
 
to fix the issue.
 +
 +
== Another Problem Case ==
 +
I had setup a bridge and got the same problem, but iptables was setup well. In my case the problem was lying in /proc/sys/net/bridge/.
 +
Everything inside had value "1". Changing them to "0" solved the problem. This stopped ARP and bridge packets from being
 +
passed through the FORWARD chain. These settings can be placed inside /etc/sysctl.conf (Debian) so that they are persistent.
  
 
== Credits ==
 
== Credits ==

Latest revision as of 05:02, 19 February 2012

Sometimes a bridge can mysteriously drop packets and not forward them. e.g. eyck user experienced a problem when some of the broadcasts were not delivered to container via the bridge.

Original report and the thread: forum thread

Simplest configuration[edit]

Container #101 with veth interface (veth101.0) connected to eth0 physical interface via bridge.

Problem statement[edit]

We faced a situation when some of the broadcast packets were not delivered to the container. Actually it could happen with any packets, not with the broadcasts only. But broadcasts are simpler and obviously should have been delivered to all the networking interfaces with no doubt.

Using tcpdump we see that BOOTP/DHCP request is visible on br0 interface in the host system (CT0):

 15:21:52.258220 00:1b:d5:2c:bf:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67:
   BOOTP/DHCP, Request from 00:1b:d5:2c:bf:38, length 308
 15:21:52.287269 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:
   BOOTP/DHCP, Reply, length 300

However, eth0 inside the container received only 2nd packet with a BOOTP/DHCP reply and doesn't see the 1st one with the request itself:

 15:21:52.291145 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:
   BOOTP/DHCP, Reply, length 300

Resolution[edit]

It is not obvious at all, but bridges (though they have their own ebtables filters) do also call iptables FORWARD chain when forwarding packets between interfaces. Thus your FORWARD iptables rules should allow all the packets which are supposed to go through.

in our case eyck had a default DROP policy on FORWARD and had to add:

 iptables -A FORWARD -d 255.255.255.255 -j ACCEPT

to fix the issue.

Another Problem Case[edit]

I had setup a bridge and got the same problem, but iptables was setup well. In my case the problem was lying in /proc/sys/net/bridge/. Everything inside had value "1". Changing them to "0" solved the problem. This stopped ARP and bridge packets from being passed through the FORWARD chain. These settings can be placed inside /etc/sysctl.conf (Debian) so that they are persistent.

Credits[edit]

Many credits to Dariush Pietrzak, who patiently helped to debug this.