On Thu, Dec 01, 2011 at 12:02:46PM -0800, David Erickson wrote: > On 12/1/2011 12:01 PM, Ben Pfaff wrote: > >On Wed, Nov 30, 2011 at 06:18:15PM -0800, David Erickson wrote: > >>I think I've run into another semi-related issue with inband. I > >>recently changed the fail mode of my OVS instances from standalone > >>to secure because I wanted them to continue using the rules that had > >>been set in the event the controller died or needed restarting. > >>This had the unfortunate side effect that if the controller is down > >>long enough then the box can lose its DHCP lease, and be unable to > >>get a new one because DHCP requests are trying to be sent to the > >>controller, but the switch isn't able to connect to the controller > >>without an address, ie: > >> > >>Nov 30 21:04:52 localhost dhclient: DHCPDISCOVER on xenbr0 to > >>255.255.255.255 port 67 interval 4 > >>Nov 30 21:04:56 localhost dhclient: No DHCPOFFERS received. > >>Nov 30 21:04:56 localhost dhclient: No working leases in persistent > >>database - sleeping. > >>Nov 30 21:04:58 localhost ovs-vswitchd: > >>789878|stream_tcp|ERR|tcp:192.168.1.11:6633: connect: Network is > >>unreachable > >> > >>What is the behavior of the inband rules when the switch is in > >>secure mode and has lost connection to the controller? > >No different from any other time. > > > >>It seems to me like they are being ignored, or at least the DHCP > >>rule doesn't seem to be working. > >Please investigate further. I would start by finding out whether the > >DHCP requests are making it out on the wire, then if they are, whether > >DHCP replies are visible coming back across the wire. > > Ya the requests aren't making it onto the wire.
Please capture the kernel flow that matches the request with "ovs-dpctl dump-flows", then feed that flow back into "ofproto/trace" to see what OVS is actually doing with it. Thanks, Ben. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
