Or, it could be a stupid mistake on my part...actually, it is. I *assumed* that, when I specified the openvswitch_mod and brcompat_mod in /etc/sysconfig/kernel to load at boot time, that they would be loaded fairly on in the boot process. Apparently not - apparently they are loaded well after networking starts, etc. So, the daemons were starting without the modules loaded, which was causing the problem. I modified the init script to load the modules when the init script runs, and this seems to solve all of the problems.
I believe the second issue, with promisc not be set up correctly, was related to the modules not loading - everything is working fine, now. Thanks, and sorry for clutter the list with silly questions like this! :-) -Nick >>> On 2010/09/08 at 18:03, Jesse Gross <[email protected]> wrote: > On Wed, Sep 8, 2010 at 1:29 PM, Nick Couchman <[email protected]> wrote: >> I'm having trouble configuring the OVS startup sequence correctly such that > ports are available when the Linux network subsystem attempts to start. I'm > running OpenSuSE 11.3 and OpenvSwitch 1.1.0pre1. The ovsdb-server, > ovs-vswitchd, and ovs-brcompatd daemons start correctly at boot time. I > currently have them starting before Linux attempts to start network devices, > as I was under the impression this would allow all of the devices to be > created successfully. However, this does not seem to be the case - although > these daemons start correctly, the interfaces (br0, my bridge, and dom0.0, an > internal interface I created) are not available when Linux tries to bring up > interfaces. If I shut down all of the daemons and restart them, the > interfaces show up correctly. > > Sounds like you have a timing issue, probably introduced by the bridge > compatibility layer. What happens if you add a sleep() as a debugging > measure? Is it possible to avoid using bridge compatibility and > directly use the Open vSwitch tools? > >> >> I've also noticed another problem. When eth0 is added to br0 (not via Linux > bridging, but via open vSwitch) it does not seem to operate in promiscuous > mode. This is problematic for internal interface that I've created, as > packets going back to that interface (right now, DHCP responses) don't get > put through. Any hints on how to solve this one? > > Open vSwitch puts the interfaces into promiscuous mode, so I somewhat > doubt that this is the problem. My guess is that something is > dropping the traffic for another reason. ovs-dpctl dump-flows > <brname> is a good tool for seeing what Open vSwitch is doing (it > shows the currently active flows from the last 5 seconds). Of course > tcpdump is useful as well and checking that there are no iptables > rules that might cause problems, etc. -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
