OK, so for the record, in a F20 environment, this cannot be reproduced by just restarting ovsdb-server as documented by by James @ [1] . I *could* reproduce it but only by restarting the openvswitch service altogether.
NOTE: one thing that confused my is that in fedora, the service is 'openvswitch' and not 'openvswitch-switch' as in ubuntu, please someone correct me if I'm wrong.
After doing 'service openvswitch restart' I could no longer see the DHCP traffic on the tap interface of the internal bridge (only on br-ctlplane for example). As suggested above, doing a 'service neutron-openvswitch-agent restart' fixed the problem and traffic again flows through/to the internal bridge.
OK, so for the record, in a F20 environment, this cannot be reproduced by just restarting ovsdb-server as documented by by James @ [1] . I *could* reproduce it but only by restarting the openvswitch service altogether.
NOTE: one thing that confused my is that in fedora, the service is 'openvswitch' and not 'openvswitch- switch' as in ubuntu, please someone correct me if I'm wrong.
After doing 'service openvswitch restart' I could no longer see the DHCP traffic on the tap interface of the internal bridge (only on br-ctlplane for example). As suggested above, doing a 'service neutron- openvswitch- agent restart' fixed the problem and traffic again flows through/to the internal bridge.
thanks! marios
[1] https:/ /bugs.launchpad .net/neutron/ +bug/1290486/ comments/ 7