Red Hat Bugzilla – Bug 1002569
Make calls to ip6tables conditional on net.ipv6.conf.all.disable_ipv6 != 1 or on presence of /proc/net/snmp6
Last modified: 2016-04-26 22:33:26 EDT
Description of problem: Instances do not get ip address from dhcp server. Upon investigation figured out qvoxxxx interface was brought up without a tag on top of it. I checked openvswitch-agent.log on compute node and could see it's looping with below error and does not reach to a stage where the code adds the tag. 2012-05-29 16:01:19 ERROR [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Error in agent event loop Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py", line 699, in rpc_loop sync = self.process_network_ports(port_info) File "/usr/lib/python2.6/site-packages/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py", line 654, in process_network_ports resync_a = self.treat_devices_added(port_info['added']) File "/usr/lib/python2.6/site-packages/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py", line 600, in treat_devices_added self.sg_agent.prepare_devices_filter(devices) File "/usr/lib/python2.6/site-packages/quantum/agent/securitygroups_rpc.py", line 114, in prepare_devices_filter self.firewall.prepare_port_filter(device) File "/usr/lib64/python2.6/contextlib.py", line 23, in __exit__ self.gen.next() File "/usr/lib/python2.6/site-packages/quantum/agent/firewall.py", line 107, in defer_apply self.filter_defer_apply_off() File "/usr/lib/python2.6/site-packages/quantum/agent/linux/iptables_firewall.py", line 284, in filter_defer_apply_off self.iptables.defer_apply_off() File "/usr/lib/python2.6/site-packages/quantum/agent/linux/iptables_manager.py", line 304, in defer_apply_off self._apply() File "/usr/lib/python2.6/site-packages/quantum/openstack/common/lockutils.py", line 228, in inner retval = f(*args, **kwargs) File "/usr/lib/python2.6/site-packages/quantum/agent/linux/iptables_manager.py", line 331, in _apply root_helper=self.root_helper)) File "/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py", line 61, in execute raise RuntimeError(m) RuntimeError: Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 'ip6tables-save', '-t', 'filter'] Exit code: 1 Stdout: '' Stderr: 'ip6tables-save v1.4.7: Cannot initialize: Address family not supported by protocol\n\n' Then found /etc/modprobe.d/ipv6.conf which has below details. # Anaconda disabling ipv6 options ipv6 disable=1 I requested the customer to move that file and reboot compute node so that ipv6 will be enabled. Once done had the customer restart ovs-agent. qvoXXXXXX got a vlan tag on it and instance got ip address from dhcp server. Please fix this by making calls to ip6tables conditional on net.ipv6.conf.all.disable_ipv6 != 1 or on presence of /proc/net/snmp6 or by any other solutions.
@sputhenp, just to make sure I understand the issue. The customer is not using ipv6 at all, but what you are seeing is that even when ipv6 is explicitly disabled via "options ipv6 disable=1" the opevswitch agent is still trying to call ip6tables? So you are not looking to enable ipv6 support, but are just looking to make sure that when ipv6 is listed as disabled by the base system, that openvswitch agent is smart enough to not execute the ip6 related commands (like ip6tables) If that is correct let me know and we'll figure out how to push this through.
(In reply to Perry Myers from comment #3) > @sputhenp, just to make sure I understand the issue. > > The customer is not using ipv6 at all, but what you are seeing is that even > when ipv6 is explicitly disabled via "options ipv6 disable=1" the opevswitch > agent is still trying to call ip6tables? > > So you are not looking to enable ipv6 support, but are just looking to make > sure that when ipv6 is listed as disabled by the base system, that > openvswitch agent is smart enough to not execute the ip6 related commands > (like ip6tables) > > If that is correct let me know and we'll figure out how to push this through. Yes, your understanding is correct. Customer is not using ipv6 and not looking to enable it, but disabling ipv6 breaks openvswitch. l2 agent still calls ip6tables commands and loops when it hits failure. Due to this loop, it does not reach to the commands that sets tag (/usr/bin/ovs-vsctl --timeout=2 set Port qvo5db7bef7-4b tag=1) to the port after the port added to the ovs bridge and network communication fails.
Ok, great. Thanks for the confirmation.
The customer closed the ticket per the work around above. since this issue was not encounter in havana I am closing this bug.
since there is a workaround I'm pushing this for the next version.
Is this duplicate of bug 1125207 ?
Jakub already working on this: https://review.openstack.org/#/c/112253/ (In reply to Jakub Libosvar from comment #18) > Is this duplicate of bug 1125207 ? I believe it is.
Closing, if it appears to be different issue, feel free to re-open. *** This bug has been marked as a duplicate of bug 1125207 ***