Xen devel - Jul 2006 - RE: [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@shark.ncsa.uiuc.edu
> # Node ID f0fa1126dae5f897eac9a162a6ccbb6ceca7f9b9
> # Parent  a1c2cede77c78d2af99088d7dece8f74f2a27260
> Disable iptables filtering of bridge traffic
> Signed-off-by: Mike Freemon mfreemon@ncsa.uiuc.edu
> 
> 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@ncsa.uiuc.edu> 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@lists.xensource.com
> >>http://lists.xensource.com/xen-devel
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Jul 11, 2006 at 06:45:01AM +0100, Ian Pratt
wrote:
> > 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?
IIRC, interface names in iptables rules are symbolic, so eth0 means what
currently stands for eth0.

For what is worth, I never understood why Xen decides to rename the real
interface or why it tries to manually set the bridge''s MAC address.

What I do, in my machines, is use the system''s method of bridge
configuration (/etc/sysconfig/network-scripts/ifcfg-xenbr0). That fixed
some problems I had with xen (some instances of connections resetted on
xend start and domU unable to talk to other domU on another machine).

-- 
lfr
0/0


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

Luciano Miguel Ferreira Rocha <strange@nsk.no-ip.org>
wrote:
>
>> 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?
> 
> IIRC, interface names in iptables rules are symbolic, so eth0 means what
> currently stands for eth0.
Correct.  Only the interface name is compared.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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