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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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.Let''s make the default larger (e.g. 4) after verifying that they only get created in dom0, and don''t consume significant memory unless actually brought ''up''. Please can someone check. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 ifupDidn''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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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, > IanI 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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, > NiveditaWith 2 machines and dom0/U''s sharing a broadcast domain this problem always occurs. Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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.We often don''t know the domain''s IP addr, so in general its not possible to use antispoof. There are also issues with antispoof breaking DHCP from domU''s when used with certain DHCP servers. I''d certainly keep the default as ''off'' at this stage in proceedings. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel