network-bridge script reworked

network-bridge script reworked

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 634 bytes --]

Hi,

I hacked on the network-bridge script.

It now works much better for me:
* we got rid of ifconfig
* it works for netdev != eth0
* arp on and off are symmetric as are ifdown and ifup
* ifup will be passed the ifcfg config file name if needed
  (the ifup may otherwise figure that the veth0 hardware is 
   NOT the same as the original ${netdev} and not use the same
   config -- this happens on SUSE. Charles Coffing tracked this
   one down.)

Please merge.
Let me know if you prefer a patch vs. the new script.

Signed-off-by: Kurt Garloff <garloff@suse.de>
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: network-bridge script reworked

[Ewan Mellor]

On Wed, Oct 19, 2005 at 11:35:02AM +0200, Kurt Garloff wrote:

> Hi,
> 
> I hacked on the network-bridge script.
> 
> It now works much better for me:
> * we got rid of ifconfig
> * it works for netdev != eth0
> * arp on and off are symmetric as are ifdown and ifup
> * ifup will be passed the ifcfg config file name if needed
>   (the ifup may otherwise figure that the veth0 hardware is 
>    NOT the same as the original ${netdev} and not use the same
>    config -- this happens on SUSE. Charles Coffing tracked this
>    one down.)
> 
> Please merge.
> Let me know if you prefer a patch vs. the new script.

Either is fine.

Thanks for doing this work Kurt -- I would like to apply it straight away.

Ewan.

Re: network-bridge script reworked

[Charles Duffy]

Kurt Garloff wrote:
> It now works much better for me:
> * we got rid of ifconfig
> * it works for netdev != eth0
> * arp on and off are symmetric as are ifdown and ifup
> * ifup will be passed the ifcfg config file name if needed
>   (the ifup may otherwise figure that the veth0 hardware is 
>    NOT the same as the original ${netdev} and not use the same
>    config -- this happens on SUSE. Charles Coffing tracked this
>    one down.)

Does this updated network-bridge, like my patch posted to this list on 
10/14 under the title "[PATCH] network-bridge script support for 
multiple external interfaces", allow support for multiple loopback 
interfaces?

I have a situation where my Xen host has physical interfaces on multiple 
networks and gives Xen instances access to one or the other based on 
where they're supposed to be; this implies modifying all the hardcoded 
references to veth0 or vif0.0.

Re: Re: network-bridge script reworked

[Ewan Mellor]

On Wed, Oct 19, 2005 at 06:15:18AM -0500, Charles Duffy wrote:

> Kurt Garloff wrote:
> >It now works much better for me:
> >* we got rid of ifconfig
> >* it works for netdev != eth0
> >* arp on and off are symmetric as are ifdown and ifup
> >* ifup will be passed the ifcfg config file name if needed
> >  (the ifup may otherwise figure that the veth0 hardware is 
> >   NOT the same as the original ${netdev} and not use the same
> >   config -- this happens on SUSE. Charles Coffing tracked this
> >   one down.)
> 
> Does this updated network-bridge, like my patch posted to this list on 
> 10/14 under the title "[PATCH] network-bridge script support for 
> multiple external interfaces", allow support for multiple loopback 
> interfaces?

If it does not, I shall make it so.  Your original patch looks fine to me, so
I shall merge the two together when I commit them.

Just waiting for that script, Kurt ;-)

Ewan.

Re: Re: network-bridge script reworked

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1550 bytes --]

Hi Charles,

On Wed, Oct 19, 2005 at 06:15:18AM -0500, Charles Duffy wrote:
> Kurt Garloff wrote:
> >It now works much better for me:
> >* we got rid of ifconfig
> >* it works for netdev != eth0
> >* arp on and off are symmetric as are ifdown and ifup
> >* ifup will be passed the ifcfg config file name if needed
> >  (the ifup may otherwise figure that the veth0 hardware is 
> >   NOT the same as the original ${netdev} and not use the same
> >   config -- this happens on SUSE. Charles Coffing tracked this
> >   one down.)
> 
> Does this updated network-bridge, like my patch posted to this list on 
> 10/14 under the title "[PATCH] network-bridge script support for 
> multiple external interfaces", allow support for multiple loopback 
> interfaces?

The network-bridge script currently expects to be started just once; 
on the second call you won't have a veth0 any more and thus the script 
will not do anything to your $netdev.

> I have a situation where my Xen host has physical interfaces on multiple 
> networks and gives Xen instances access to one or the other based on 
> where they're supposed to be; this implies modifying all the hardcoded 
> references to veth0 or vif0.0.

veth0 and vif0.0 are currently hardcoded; I did remove all occurences
of eth0 and peth0 though (and replace it by ${netdev} and p${netdev}).

Is it possible to create more than one veth0 in dom0?

Do you want ot have a look into combining your work into mine?

Best,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: network-bridge script reworked

[Kurt Garloff]

[-- Attachment #1.1.1: Type: text/plain, Size: 247 bytes --]

Hi Ewan,

On Wed, Oct 19, 2005 at 12:58:40PM +0100, Ewan Mellor wrote:
> Just waiting for that script, Kurt ;-)

Ouch it was measnt to be attached to the original message.
Sorry.

Best,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #1.1.2: network-bridge --]
[-- Type: text/plain, Size: 8460 bytes --]

#!/bin/sh
#============================================================================
# Default Xen network start/stop script.
# Xend calls a network script when it starts.
# The script name to use is defined in /etc/xen/xend-config.sxp
# in the network-script field.
#
# This script creates a bridge (default xenbr0), adds a device
# (default eth0) to it, copies the IP addresses from the device
# to the bridge and adjusts the routes accordingly.
#
# If all goes well, this should ensure that networking stays up.
# However, some configurations are upset by this, especially
# NFS roots. If the bridged setup does not meet your needs,
# configure a different script, for example using routing instead.
#
# Usage:
#
# network (start|stop|status) {VAR=VAL}*
#
# Vars:
#
# bridge     The bridge to use (default xenbr0).
# netdev     The interface to add to the bridge (default eth0).
# antispoof  Whether to use iptables to prevent spoofing (default yes).
#
# start:
# Creates the bridge and enslaves netdev to it.
# Copies the IP addresses from netdev to the bridge.
# Deletes the routes to netdev and adds them on bridge.
#
# stop:
# Removes netdev from the bridge.
# Deletes the routes to bridge and adds them to netdev.
#
# status:
# Print ifconfig for netdev and bridge.
# Print routes.
#
#============================================================================

# Gentoo doesn't have ifup/ifdown: define appropriate alternatives
which ifup >& /dev/null
if [ "$?" != 0 -a -e /etc/conf.d/net ]; then
    ifup() {
	/etc/init.d/net.$1 start
    }
    ifdown() {
	/etc/init.d/net.$1 stop
    }
fi

# Exit if anything goes wrong.
set -e 

# First arg is the operation.
OP=$1
shift

# Pull variables in args in to environment.
for arg ; do export "${arg}" ; done

bridge=${bridge:-xenbr0}
netdev=${netdev:-eth0}
antispoof=${antispoof:-no}

echo "*network $OP bridge=$bridge netdev=$netdev antispoof=$antispoof" >&2

legacy_mask_to_prefix() {
    mask=$1
    first=${mask%%.*}
    second=${mask#*.}
    third=${second#*.}
    fourth=${third#*.}
    second=${second%%.*}
    third=${third%%.*}
    declare -i INT FULLMASK BIT
    INT=$((((($first*256)+$second)*256+$third)*256+$fourth))
    FULLMASK=4294967295
    BIT=1
    for bit in `seq 32 -1 0`; do
	if test $FULLMASK -eq $INT; then PREFIX=$bit; return; fi
	FULLMASK=$(($FULLMASK-$BIT))
	BIT=$((BIT*2))
    done
    echo "ERROR converting netmask $mask to prefix"
    exit 1
}

# Usage: transfer_addrs src dst
# Copy all IP addresses (including aliases) from device $src to device $dst.
transfer_addrs () {
    local src=$1
    local dst=$2
    # Don't bother if $dst already has IP addresses.
    if ip addr show dev ${dst} | egrep -q '^ *inet ' ; then
	return
    fi
    # Address lines start with 'inet' and have the device in them.
    # Replace 'inet' with 'ip addr add' and change the device name $src
    # to 'dev $src'.
    ip addr show dev ${src} | egrep '^ *inet ' | sed -e "
s/inet/ip addr add/
s@\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+/[0-9]\+\)@\1@
s/${src}/dev ${dst}/
" | sh -e
    # Remove automatic routes on destionation device
    ip route list | sed -ne "
/dev ${dst}\( \|$\)/ {
  s/^/ip route del /
  p
}" | sh -e
}

# Usage: del_addrs src
del_addrs () {
    local src=$1
    ip addr show dev ${src} | egrep '^ *inet ' | sed -e "
s/inet/ip addr del/
s@\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\)/[0-9]\+@\1@
s/${src}/dev ${src}/
" | sh -e
    ip link set dev ${dst} up
}

# Usage: transfer_routes src dst
# Get all IP routes to device $src, delete them, and
# add the same routes to device $dst.
# The original routes have to be deleted, otherwise adding them
# for $dst fails (duplicate routes).
transfer_routes () {
    local src=$1
    local dst=$2
    # List all routes and grep the ones with $src in.
    # Stick 'ip route del' on the front to delete.
    # Change $src to $dst and use 'ip route add' to add.
    ip route list | sed -ne "
/dev ${src}\( \|$\)/ {
  h
  s/^/ip route del /
  P
  g
  s/${src}/${dst}/
  s/^/ip route add /
  P
  d
}" | sh -e
}

# Usage: create_bridge bridge
create_bridge () {
    local bridge=$1

    # Don't create the bridge if it already exists.
    if ! brctl show | grep -q ${bridge} ; then
	brctl addbr ${bridge}
	brctl stp ${bridge} off
	brctl setfd ${bridge} 0
    fi
    ip link set ${bridge} up
}

# Usage: add_to_bridge bridge dev
add_to_bridge () {
    local bridge=$1
    local dev=$2
    # Don't add $dev to $bridge if it's already on a bridge.
    if ! brctl show | grep -q ${dev} ; then
	brctl addif ${bridge} ${dev}
    fi
}

# Usage: antispoofing dev bridge
# Set the default forwarding policy for $dev to drop.
# Allow forwarding to the bridge.
antispoofing () {
    local dev=$1
    local bridge=$2

    iptables -P FORWARD DROP
    iptables -A FORWARD -m physdev --physdev-in ${dev} -j ACCEPT
}

# Usage: show_status dev bridge
# Print ifconfig and routes.
show_status () {
    local dev=$1
    local bridge=$2
    
    echo '============================================================'
    ip addr show ${dev}
    ip addr show ${bridge}
    echo ' '
    brctl show ${bridge}
    echo ' '
    ip route list
    echo ' '
    route -n
    echo '============================================================'
}

op_start () {
    if [ "${bridge}" == "null" ] ; then
	return
    fi

    create_bridge ${bridge}

    if ! ip link show 2>/dev/null | grep -q "^[0-9]*: veth0"; then
	return
    fi

    if ip link show veth0 2>/dev/null >/dev/null; then
	mac=`ip link show ${netdev} | grep 'link\/ether' | sed -e 's/.*ether \(..:..:..:..:..:..\).*/\1/'`
	eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- ${netdev}`
	transfer_addrs ${netdev} veth0
	if ! ifdown ${netdev}; then
	    # if ifup didn't work, see if we have an ip= on cmd line
	    if egrep 'ip=[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+:' /proc/cmdline; then
		kip=`sed -e 's!.*ip=\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\):.*!\1!' /proc/cmdline`
		kmask=`sed -e 's!.*ip=[^:]*:[^:]*:[^:]*:\([^:]*\):.*!\1!' /proc/cmdline` 
		kgate=`sed -e 's!.*ip=[^:]*:[^:]*:\([^:]*\):.*!\1!' /proc/cmdline`
		ip link set ${netdev} down
		ip addr flush ${netdev}
	    fi
	fi
	ip link set  ${netdev} name p${netdev}
	ip link set veth0 name ${netdev}
	ip link set p${netdev} down arp off
	ip link set p${netdev} addr fe:ff:ff:ff:ff:ff
	ip addr flush p${netdev}
	ip link set  ${netdev} addr ${mac} arp on
	add_to_bridge ${bridge} vif0.0
	add_to_bridge ${bridge} p${netdev}
	ip link set ${bridge} up
	ip link set vif0.0 up
	ip link set p${netdev} up 
	if ! ifup ${HWD_CONFIG_0} ${netdev} ; then
	    if [ ${kip} ] ; then
		# use the addresses we grocked from /proc/cmdline
		if [ -z "${kmask}" ]; then 
		    PREFIX=32; 
		else 
		    legacy_to_prefix ${kmask};
		fi
		ip addr add ${kip}/${PREFIX} dev ${netdev}
		ip link set dev ${netdev} up
		[ ${kgate} ] && ip route add default via ${kgate}
	    fi
	fi
    else
	# old style without veth0
	transfer_addrs  ${netdev} ${bridge}
	transfer_routes ${netdev} ${bridge}
    fi

    if [ ${antispoof} == 'yes' ] ; then
	antispoofing ${netdev} ${bridge}
    fi
}

op_stop () {
    if [ "${bridge}" == "null" ]; then
	return
    fi
    if ! ip link show ${bridge} >/dev/null 2>&1; then
	return
    fi

    if ip link show p${netdev} 2>/dev/null >/dev/null; then
	ip link set dev vif0.0 down
	mac=`ip link show ${netdev} | grep 'link\/ether' | sed -e 's/.*ether \(..:..:..:..:..:..\).*/\1/'`
	transfer_addrs ${netdev} p${netdev}
	ifdown ${netdev}
	ip link set ${netdev} down arp off
	ip link set ${netdev} addr fe:ff:ff:ff:ff:ff
	ip link set p${netdev} down
	ip addr flush  ${netdev}
	ip link set p${netdev} addr ${mac} arp on

	brctl delif ${bridge} p${netdev}
	brctl delif ${bridge} vif0.0
	ip link set ${bridge} down

	ip link set  ${netdev} name veth0
	ip link set p${netdev} name ${netdev}
	ifup ${netdev}

    else
	transfer_routes ${bridge} ${netdev}
	ip link set ${bridge} down
    fi
    brctl delbr ${bridge}
}

case ${OP} in
    start)
	op_start
	;;
    
    stop)
	op_stop
	;;

    status)
	show_status ${netdev} ${bridge}
	;;

    *)
	echo 'Unknown command: ' ${OP} >&2
	echo 'Valid commands are: start, stop, status' >&2
	exit 1
esac

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: network-bridge script reworked

[Charles Duffy]

Kurt Garloff wrote:
> The network-bridge script currently expects to be started just once; 
> on the second call you won't have a veth0 any more and thus the script 
> will not do anything to your $netdev.

Right, but if one wants to operate on veth1 and its match vif0.1 (or 
veth2 and vif0.2, etc) then some mechanism is needed to indicate this.

> Is it possible to create more than one veth0 in dom0?

Yes, by settings loopback.nloopbacks to a higher value.

> Do you want ot have a look into combining your work into mine?

I would be more than glad to do so -- though apparently Ewan has also 
offered to do the merge himself.

Re: Re: network-bridge script reworked

[Ewan Mellor]

I've put in the network-bridge patch, along with Charles' changes to support
multiple bridges.  I'm in no position to test a wide variety of
configurations, so I would appreciate some feedback from you guys.

We currently have

pdev="p${netdev}"
vdev="veth${vifnum}"

which seems to me to be strangely inconsistent, but this was the closest
behaviour to the two patches submitted.  It's not clear to me what should
happen if you set vifnum and netdev at the same time, and therefore whether

pdev="p${netdev}"
vdev="v${netdev}"

would be better.  Perhaps you could argue about it for a bit.

Thanks for your patches.  Things certainly seem to have improved!

Ewan.

Re: Re: network-bridge script reworked

[Charles Duffy]

Ewan Mellor wrote:
> I've put in the network-bridge patch, along with Charles' changes to support
> multiple bridges.  I'm in no position to test a wide variety of
> configurations, so I would appreciate some feedback from you guys.
> 
> We currently have
> 
> pdev="p${netdev}"
> vdev="veth${vifnum}"

Since the veth* device is tied to the vif0.* device, and not to the 
physical ethernet device in the machine, the way you merged it appears 
to me to be correct. I'll try it on my test machine, though, and 
validate that it Does The Right Thing.

RE: network-bridge script reworked

[Ian Pratt]

 
> I hacked on the network-bridge script.
> 
> It now works much better for me:
> * we got rid of ifconfig
> * it works for netdev != eth0
> * arp on and off are symmetric as are ifdown and ifup

Didn't we decide we needed to also set 'arp off' on the bridge to avoid
the 'seen packet with own mac address' complaints?

Thanks,
Ian

RE: network-bridge script reworked

[Ted Kaczmarek]

On Wed, 2005-10-19 at 22:44 +0100, Ian Pratt wrote:
>  > I hacked on the network-bridge script.
> > 
> > It now works much better for me:
> > * we got rid of ifconfig
> > * it works for netdev != eth0
> > * arp on and off are symmetric as are ifdown and ifup
> 
> Didn't we decide we needed to also set 'arp off' on the bridge to avoid
> the 'seen packet with own mac address' complaints?
> 
> Thanks,
> Ian

I was hoping one of those guys working for one of those big shops would
have put a tap on this by now. Would be nice to know what this ethernet
frame before disabling the arp.

Regards,
Ted

Re: network-bridge script reworked

[Nivedita Singhvi]

Ted Kaczmarek wrote:
> On Wed, 2005-10-19 at 22:44 +0100, Ian Pratt wrote:
> 
>> > I hacked on the network-bridge script.
>>
>>>It now works much better for me:
>>>* we got rid of ifconfig
>>>* it works for netdev != eth0
>>>* arp on and off are symmetric as are ifdown and ifup
>>
>>Didn't we decide we needed to also set 'arp off' on the bridge to avoid
>>the 'seen packet with own mac address' complaints?
>>
>>Thanks,
>>Ian
> 
> 
> I was hoping one of those guys working for one of those big shops would
> have put a tap on this by now. Would be nice to know what this ethernet
> frame before disabling the arp.

Retrying stuff this afternoon with new patch (the merge done by Ewan)
and possibly patch for new patch. Stay tuned...

thanks,
Nivedita

Re: network-bridge script reworked

[Ewan Mellor]

On Wed, Oct 19, 2005 at 06:00:15PM -0400, Ted Kaczmarek wrote:

> On Wed, 2005-10-19 at 22:44 +0100, Ian Pratt wrote:
> >  > I hacked on the network-bridge script.
> > > 
> > > It now works much better for me:
> > > * we got rid of ifconfig
> > > * it works for netdev != eth0
> > > * arp on and off are symmetric as are ifdown and ifup
> > 
> > Didn't we decide we needed to also set 'arp off' on the bridge to avoid
> > the 'seen packet with own mac address' complaints?
> > 
> > Thanks,
> > Ian
> 
> I was hoping one of those guys working for one of those big shops would
> have put a tap on this by now. Would be nice to know what this ethernet
> frame before disabling the arp.

We have seen the old script get things into a state whereby the machine's
routing tables claim to be going through peth0 rather than eth0.  At the very
least, if this happened with two Xen machines on the network, then one would
complain about packets coming from the other, and I have observed this behaviour
directly.

Can anyone claim to have seen the error message with only one Xen machine on
the network?

Ewan.

Re: network-bridge script reworked

[Ted Kaczmarek]

On Wed, 2005-10-19 at 23:40 +0100, Ewan Mellor wrote:
> On Wed, Oct 19, 2005 at 06:00:15PM -0400, Ted Kaczmarek wrote:
> 
> > On Wed, 2005-10-19 at 22:44 +0100, Ian Pratt wrote:
> > >  > I hacked on the network-bridge script.
> > > > 
> > > > It now works much better for me:
> > > > * we got rid of ifconfig
> > > > * it works for netdev != eth0
> > > > * arp on and off are symmetric as are ifdown and ifup
> > > 
> > > Didn't we decide we needed to also set 'arp off' on the bridge to avoid
> > > the 'seen packet with own mac address' complaints?
> > > 
> > > Thanks,
> > > Ian
> > 
> > I was hoping one of those guys working for one of those big shops would
> > have put a tap on this by now. Would be nice to know what this ethernet
> > frame before disabling the arp.
> 
> We have seen the old script get things into a state whereby the machine's
> routing tables claim to be going through peth0 rather than eth0.  At the very
> least, if this happened with two Xen machines on the network, then one would
> complain about packets coming from the other, and I have observed this behaviour
> directly.
> 
> Can anyone claim to have seen the error message with only one Xen machine on
> the network?
> 
> Ewan.
Nope, I have repeatedly tested and have only seen this when the
domU's/DomO's share a broadcast domain on the peth interface. Been
running test bed where eth0 is disconnected and xen-br0 is enslaved to
it for almost two days now. Not a single instance of this message.

Regards,
Ted

Re: network-bridge script reworked

[Nivedita Singhvi]

Ted Kaczmarek wrote:

>>We have seen the old script get things into a state whereby the machine's
>>routing tables claim to be going through peth0 rather than eth0.  At the very
>>least, if this happened with two Xen machines on the network, then one would
>>complain about packets coming from the other, and I have observed this behaviour
>>directly.
>>
>>Can anyone claim to have seen the error message with only one Xen machine on
>>the network?
>>
>>Ewan.
> 
> Nope, I have repeatedly tested and have only seen this when the
> domU's/DomO's share a broadcast domain on the peth interface. Been
> running test bed where eth0 is disconnected and xen-br0 is enslaved to
> it for almost two days now. Not a single instance of this message.

Ted, are you saying only one machine, or was that multiple machines?
Because we have not seen it with a single machine on the network (ok,
would someone from the "big shop" correct me if they have?).

Jerone has been trying to recreate it right now and hasn't seen it
so far.

I believe it is the scenario that Ewan describes above.

thanks,
Nivedita

Re: network-bridge script reworked

[Ewan Mellor]

On Wed, Oct 19, 2005 at 11:35:02AM +0200, Kurt Garloff wrote:

> I hacked on the network-bridge script.

Kurt, this line

	eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- ${netdev}`

looks a bit SuSE-specific to me.  It's certainly not working on my Debian
system.  What's the intention here?  Do you know what we can do to make this
more portable?

Ewan.

Re: network-bridge script reworked

[Ted Kaczmarek]

On Wed, 2005-10-19 at 16:45 -0700, Nivedita Singhvi wrote:
> Ted Kaczmarek wrote:
> 
> >>We have seen the old script get things into a state whereby the machine's
> >>routing tables claim to be going through peth0 rather than eth0.  At the very
> >>least, if this happened with two Xen machines on the network, then one would
> >>complain about packets coming from the other, and I have observed this behaviour
> >>directly.
> >>
> >>Can anyone claim to have seen the error message with only one Xen machine on
> >>the network?
> >>
> >>Ewan.
> > 
> > Nope, I have repeatedly tested and have only seen this when the
> > domU's/DomO's share a broadcast domain on the peth interface. Been
> > running test bed where eth0 is disconnected and xen-br0 is enslaved to
> > it for almost two days now. Not a single instance of this message.
> 
> Ted, are you saying only one machine, or was that multiple machines?
> Because we have not seen it with a single machine on the network (ok,
> would someone from the "big shop" correct me if they have?).
> 
> Jerone has been trying to recreate it right now and hasn't seen it
> so far.
> 
> I believe it is the scenario that Ewan describes above.
> 
> thanks,
> Nivedita

With 2 machines and dom0/U's  sharing a broadcast domain this problem
always occurs.


Ted

Re: Re: network-bridge script reworked

[David Hopwood]

Kurt Garloff wrote:
> # antispoof  Whether to use iptables to prevent spoofing (default yes).
[...]
> antispoof=${antispoof:-no}

Just a reminder to fix this inconsistency. The default should probably be
yes (unless there is some reason why antispoof doesn't work?)

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

Re: Re: network-bridge script reworked

[Ewan Mellor]

On Thu, Oct 20, 2005 at 05:56:04PM +0100, David Hopwood wrote:

> Kurt Garloff wrote:
> > # antispoof  Whether to use iptables to prevent spoofing (default yes).
> [...]
> > antispoof=${antispoof:-no}
> 
> Just a reminder to fix this inconsistency. The default should probably be
> yes (unless there is some reason why antispoof doesn't work?)

I have done (you haven't seen this on the public server yet, of course).  To
start with, I fixed it setting the default to no, because antispoof does
certainly seem to be broken, but I'm fixing that now, and hopefully the
default will be yes very soon.

Ewan.

Re: Re: network-bridge script reworked

[Nivedita Singhvi]

Ewan Mellor wrote:

>>>antispoof=${antispoof:-no}
>>
>>Just a reminder to fix this inconsistency. The default should probably be
>>yes (unless there is some reason why antispoof doesn't work?)

Er, antispoofing was causing quite a significant degradation
in performance (long ago), and there are quite a few people
who were thus interested in keeping it off.

Since performance work for Xen 3.0 has pretty much been on
the backburner no idea of the current situation and the value
of having it off/on.

thanks,
Nivedita

Re: Re: network-bridge script reworked

[Ewan Mellor]

On Thu, Oct 20, 2005 at 10:36:39AM -0700, Nivedita Singhvi wrote:

> Ewan Mellor wrote:
> 
> >>>antispoof=${antispoof:-no}
> >>
> >>Just a reminder to fix this inconsistency. The default should probably be
> >>yes (unless there is some reason why antispoof doesn't work?)
> 
> Er, antispoofing was causing quite a significant degradation
> in performance (long ago), and there are quite a few people
> who were thus interested in keeping it off.

Performance degradation due to a few iptables rules?  Really?

I still think that it ought to default to 'on', because that's the safer
option.  Propellor-heads always have the option to turn it off in the config
file.

Ewan.

Re: network-bridge script reworked

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --]

Hi Ewan,

On Thu, Oct 20, 2005 at 11:41:00AM +0100, Ewan Mellor wrote:
> Kurt, this line
> 
> 	eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- ${netdev}`
> 
> looks a bit SuSE-specific to me. 

Right, I should have removed that hunk or at least do something like
test -e /etc/SuSE-release && eval `...`
Sorry!

> It's certainly not working on my Debian system.  

Networking setup scripts differ quite a lot between distributions,
unfortunately.

> What's the intention here? 

It sets HWD_CONFIG_0 which is used a bit later 
          if ! ifup ${HWD_CONFIG_0} ${netdev} ; then
and does make sure, ifup uses the right configuration file for your
network device. The issue is that ifup (on SUSE) does more than looking
at the MAC address to identify a network interface and locate the right
config file.

> Do you know what we can do to make this more portable?

The config file matching may not be an issue on other distros, so the
test -e solution is not that bad. If you dislike it, please let me know;
we'll carry it around as custom patch then. It would of course not help
those folks that test your upstream versions rather than our RPMs, so I
think that's the second best solution.

Best,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: network-bridge script reworked

[Ewan Mellor]

On Thu, Oct 20, 2005 at 08:22:20PM +0200, Kurt Garloff wrote:

> Hi Ewan,
> 
> On Thu, Oct 20, 2005 at 11:41:00AM +0100, Ewan Mellor wrote:
> > Kurt, this line
> > 
> > 	eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- ${netdev}`
> > 
> > looks a bit SuSE-specific to me. 
> 
> Right, I should have removed that hunk or at least do something like
> test -e /etc/SuSE-release && eval `...`

Is this a reasonable solution:

if [ -e /etc/SuSE-release ]
then
  ifup()
  {
    eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- $1`
    /sbin/ifup ${HWD_CONFIG_0} $1
  }
  ifdown()
  {
    eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- $1`
    /sbin/ifdown ${HWD_CONFIG_0} $1
  }

In other words, override ifup and ifdown to do the right thing on SuSE.  That
way, in our scripts we can just write "ifup eth0".  We already are doing this
for Gentoo, so this would be my preferred solution, as it keeps all the
distro-specific stuff out of the script bodies.

My only doubt is that you use the eval before ifup and ifdown in op_start(),
but not in op_stop(), and I wonder whether that is important.

Ewan.

Re: network-bridge script reworked

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1521 bytes --]

On Fri, Oct 21, 2005 at 02:48:09PM +0100, Ewan Mellor wrote:
> On Thu, Oct 20, 2005 at 08:22:20PM +0200, Kurt Garloff wrote:
> Is this a reasonable solution:
> 
> if [ -e /etc/SuSE-release ]
> then
>   ifup()
>   {
>     eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- $1`
>     /sbin/ifup ${HWD_CONFIG_0} $1
>   }
>   ifdown()
>   {
>     eval `/sbin/getcfg -d /etc/sysconfig/network/ -f ifcfg- -- $1`
>     /sbin/ifdown ${HWD_CONFIG_0} $1
>   }

I like the approachm but it won't work.
The reason is that we do the eval before the renaming of network
interfaces. 
So we get the config of the physical device in ${HWD_CONFIG_0}, then
do the renaming, reassignment of MAC addresses and then use the config
to ifup the virtual device.

> In other words, override ifup and ifdown to do the right thing on SuSE.  That
> way, in our scripts we can just write "ifup eth0".  We already are doing this
> for Gentoo, so this would be my preferred solution, as it keeps all the
> distro-specific stuff out of the script bodies.
> 
> My only doubt is that you use the eval before ifup and ifdown in op_start(),
> but not in op_stop(), and I wonder whether that is important.

It's cleaner and safer to do it at both places.
But it's hard to get it right due to the interface renaming for ifdown.
So I did not address this: ifdown does little more than ip link down and
kill dhcpcd ... so this is not an issue in real life.

Best,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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