[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] Re: network-bridge script breaks networkconnectivity


  • To: "Mike Freemon" <mfreemon@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 11 Jul 2006 06:45:01 +0100
  • Delivery-date: Mon, 10 Jul 2006 22:45:27 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acakk/mgDf0uVpX/TgWtdbzc2rOo4QAF3a9g
  • Thread-topic: [Xen-devel] [PATCH] Re: network-bridge script breaks networkconnectivity

> This patch configures the bridge to *not* apply iptables filtering.
This
> makes the virtual bridge more like a real bridge (in that ip-layer
filter
> does not happen) and it makes the installation/configuration of xen
from
> sources easier (at least on FC5).

The interaction with host firewall rules has always been a bit icky, not
least because the xen network scripts typically run after the host's
firewall scripts (and rename the network device). I've never understood
what happens to the firewall rules - do they stay with the old eth0 (now
peth0) or do they now apply to the new device name?

If the latter, I can see how your patch is useful.

Thanks,
Ian
 
> Submitted for your consideration...
> 
> - Mike
> 
> 
> # HG changeset patch
> # User root@xxxxxxxxxxxxxxxxxxx
> # Node ID f0fa1126dae5f897eac9a162a6ccbb6ceca7f9b9
> # Parent  a1c2cede77c78d2af99088d7dece8f74f2a27260
> Disable iptables filtering of bridge traffic
> Signed-off-by: Mike Freemon mfreemon@xxxxxxxxxxxxx
> 
> diff -r a1c2cede77c7 -r f0fa1126dae5
tools/examples/xen-network-common.sh
> --- a/tools/examples/xen-network-common.sh      Mon Jul 10 15:01:49
2006
> +0100
> +++ b/tools/examples/xen-network-common.sh      Mon Jul 10 15:39:56
2006 -
> 0500
> @@ -127,6 +127,12 @@ create_bridge () {
> 
>       # Don't create the bridge if it already exists.
>       if [ ! -e "/sys/class/net/${bridge}/bridge" ]; then
> +        # use brctl to force initialization of bridge-nf
> +        brctl show >/dev/null 2>&1
> +        # disable iptables filtering in bridge
> +        sysctl -w "net.bridge.bridge-nf-call-arptables=0"
> +        sysctl -w "net.bridge.bridge-nf-call-ip6tables=0"
> +        sysctl -w "net.bridge.bridge-nf-call-iptables=0"
>          brctl addbr ${bridge}
>          brctl stp ${bridge} off
>          brctl setfd ${bridge} 0
> 
> 
> 
> 
> 
> 
> At 7/8/2006 05:28 PM  Saturday, Mike Freemon wrote:
> >You are correct -- My short summary was technically accurate in only
the
> >most abstract of ways  :-)
> >
> >After some more digging, I found that the iptables rules were
blocking
> >traffic passing across the xenbr0 bridge (bridge-nf).  I am using the
same
> >"fedora default" iptables rules as my other xen machines (dumped
below),
> >so I was confused as to why this machine was different.  This happens
to
> >be the first machine I have compiled Xen from hg sources (to pull in
the
> >latest vt-x vmx stuff).
> >
> >What I found was that the fedora distro of Xen contains the following
> >lines in the create_bridge() method of
/etc/xen/scripts/network-bridge:
> >
> >sysctl -w "net.bridge.bridge-nf-call-arptables=0"
> >sysctl -w "net.bridge.bridge-nf-call-ip6tables=0"
> >sysctl -w "net.bridge.bridge-nf-call-iptables=0"
> >
> >This disables the iptables filtering on the bridge.
> >
> >This seems like a reasonable default since bridges don't normally do
> >IP-layer filtering.
> >
> >What is the view of the Xen team on this?  Are there reasons why this
> >could not be included in the xen sources as well?
> >
> >- Mike
> >
> >
> >:INPUT ACCEPT [0:0]
> >:FORWARD ACCEPT [0:0]
> >:OUTPUT ACCEPT [8335:620449]
> >:RH-Firewall-1-INPUT - [0:0]
> >-A INPUT -j RH-Firewall-1-INPUT
> >-A FORWARD -j RH-Firewall-1-INPUT
> >-A RH-Firewall-1-INPUT -i lo -j ACCEPT
> >-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
> >-A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT
> >-A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT
> >-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j
ACCEPT
> >-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
> >-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
> >-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> >-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22
-j
> ACCEPT
> >-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> >COMMIT
> >
> >
> >
> >
> >At 7/8/2006 10:47 AM  Saturday, Christian Limpach wrote:
> >>On 7/7/06, Mike Freemon <mfreemon@xxxxxxxxxxxxx> wrote:
> >>>Hi All,
> >>>
> >>>First, I wasn't sure whether to report this via bugzilla or the
xen-
> devel
> >>>list.  Since this is against the current tip of xen-unstable, I
went
> here
> >>>first.  I can move this to bugzilla if you want, just let me know.
> >>>
> >>>Summary is -->  the "network-bridge start" script breaks all
network
> >>>connectivity.  ICMP broken, DHCP fails, etc.  I am running current
FC5
> >>>EM64T x86_64 VT-x with the latest xen-unstable.  Running
"network-bridge
> >>>stop" restores network functionality.
> >>>
> >>>Below is the relevant data -- before and after dumps, config files,
and
> a
> >>>trace of the network-bridge script itself.  Any help is
> >>>appreciated.  Thanks...
> >>
> >>What does your /etc/resolv.conf look like before/after
network-bridge
> start?
> >>Does ping with an IP address work?
> >>You say that DHCP fails but the log looks like it succeeds and even
> >>ping of your gateway address seems to work.
> >>
> >>     christian
> >>
> >>_______________________________________________
> >>Xen-devel mailing list
> >>Xen-devel@xxxxxxxxxxxxxxxxxxx
> >>http://lists.xensource.com/xen-devel
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.