Hi *, we recently upgraded our Ocata Cloud to Train and also switched from linuxbridge to openvswitch. One of our instances within the cloud works as DHCP server and to make that work we had to comment the respective part in this file on the compute node the instance was running on: /usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_firewall.py Now we tried the same in /usr/lib/python3.6/site-packages/neutron/agent/linux/openvswitch_firewall/firewall.py /usr/lib/python3.6/site-packages/neutron/agent/linux/iptables_firewall.py but restarting openstack-neutron-openvswitch-agent.service didn't drop that rule, the DHCP reply didn't get through. To continue with our work we just dropped it manually, so we get by, but since there have been a couple of years between Ocata and Train, is there any smoother or better way to achieve this? This seems to be a reoccuring request but I couldn't find any updates on this topic. Maybe someone here can shed some light? Is there more to change than those two files I mentioned? Any pointers are highly appreciated! Best regards, Eugen
On 8/19/20 8:36 AM, Eugen Block wrote:
Hi *,
we recently upgraded our Ocata Cloud to Train and also switched from linuxbridge to openvswitch.
One of our instances within the cloud works as DHCP server and to make that work we had to comment the respective part in this file on the compute node the instance was running on:
/usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_firewall.py
Now we tried the same in
/usr/lib/python3.6/site-packages/neutron/agent/linux/openvswitch_firewall/firewall.py
/usr/lib/python3.6/site-packages/neutron/agent/linux/iptables_firewall.py
but restarting openstack-neutron-openvswitch-agent.service didn't drop that rule, the DHCP reply didn't get through. To continue with our work we just dropped it manually, so we get by, but since there have been a couple of years between Ocata and Train, is there any smoother or better way to achieve this? This seems to be a reoccuring request but I couldn't find any updates on this topic. Maybe someone here can shed some light? Is there more to change than those two files I mentioned?
You might try disabling port-security on the instance's port. That's what we use in OVB to allow a DHCP server in an instance now. neutron port-update [port-id] --port_security_enabled=False That will drop all port security for that instance, not just the DHCP rule, but on the other hand it leaves the DHCP rule in place for any instances you don't want running DHCP servers.
Any pointers are highly appreciated!
Best regards, Eugen
That sounds promising, thank you! I had noticed that option but didn’t have a chance to look closer into it. I’ll try that tomorrow. Thanks for the tip! Zitat von Ben Nemec <openstack@nemebean.com>:
On 8/19/20 8:36 AM, Eugen Block wrote:
Hi *,
we recently upgraded our Ocata Cloud to Train and also switched from linuxbridge to openvswitch.
One of our instances within the cloud works as DHCP server and to make that work we had to comment the respective part in this file on the compute node the instance was running on:
/usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_firewall.py
Now we tried the same in
/usr/lib/python3.6/site-packages/neutron/agent/linux/openvswitch_firewall/firewall.py /usr/lib/python3.6/site-packages/neutron/agent/linux/iptables_firewall.py
but restarting openstack-neutron-openvswitch-agent.service didn't drop that rule, the DHCP reply didn't get through. To continue with our work we just dropped it manually, so we get by, but since there have been a couple of years between Ocata and Train, is there any smoother or better way to achieve this? This seems to be a reoccuring request but I couldn't find any updates on this topic. Maybe someone here can shed some light? Is there more to change than those two files I mentioned?
You might try disabling port-security on the instance's port. That's what we use in OVB to allow a DHCP server in an instance now.
neutron port-update [port-id] --port_security_enabled=False
That will drop all port security for that instance, not just the DHCP rule, but on the other hand it leaves the DHCP rule in place for any instances you don't want running DHCP servers.
Any pointers are highly appreciated!
Best regards, Eugen
Hi, just a quick follow-up on this: disabling port_security only on the specified port works as expected. Although this is still not an optimal solution we can live with it for now. Thanks again and best regards, Eugen Zitat von Eugen Block <eblock@nde.ag>:
That sounds promising, thank you! I had noticed that option but didn’t have a chance to look closer into it. I’ll try that tomorrow.
Thanks for the tip!
Zitat von Ben Nemec <openstack@nemebean.com>:
On 8/19/20 8:36 AM, Eugen Block wrote:
Hi *,
we recently upgraded our Ocata Cloud to Train and also switched from linuxbridge to openvswitch.
One of our instances within the cloud works as DHCP server and to make that work we had to comment the respective part in this file on the compute node the instance was running on:
/usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_firewall.py
Now we tried the same in
/usr/lib/python3.6/site-packages/neutron/agent/linux/openvswitch_firewall/firewall.py /usr/lib/python3.6/site-packages/neutron/agent/linux/iptables_firewall.py
but restarting openstack-neutron-openvswitch-agent.service didn't drop that rule, the DHCP reply didn't get through. To continue with our work we just dropped it manually, so we get by, but since there have been a couple of years between Ocata and Train, is there any smoother or better way to achieve this? This seems to be a reoccuring request but I couldn't find any updates on this topic. Maybe someone here can shed some light? Is there more to change than those two files I mentioned?
You might try disabling port-security on the instance's port. That's what we use in OVB to allow a DHCP server in an instance now.
neutron port-update [port-id] --port_security_enabled=False
That will drop all port security for that instance, not just the DHCP rule, but on the other hand it leaves the DHCP rule in place for any instances you don't want running DHCP servers.
Any pointers are highly appreciated!
Best regards, Eugen
participants (2)
-
Ben Nemec
-
Eugen Block