Description of problem: Backport ipencap (ipip) support from queens to pike in neutron-lib commit f4c4b0f20a796caf2133f6029ca3455382cd50ad Author: German Eichberger <German.eichberger> Date: Tue Sep 12 15:18:46 2017 -0600 Adds IPinIP protocol Neutron doesn't support the IP-in-IP protocol by name in security group rules. With this change a user can now declare the IP-in-IP protocol by using the name 'ipip' Note: This doesn't fix an underlying problem with the Neutron protocol number validator, but serves as a work around for users wanting to use the IP-in-IP protocol. Partial-bug: #1716045 Change-Id: I18e5e42b687e12b64f5a9c523a912c8dd1afa9d2 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We also need this one in neutron: commit 7ff492c5bb9ce9f24f12db40c8e3a33beb47f87b Author: Brian Haley <bhaley> Date: Thu Oct 12 15:25:26 2017 -0400 Support protocol numbers in security group API Somewhere along the way we broke supporting numbers in the security group API that were not in our known list of protocols. In order to fix this properly we must use the correct arguments when using iptables-save, as it could use a name instead of a number, or vice-versa. Determined the list of mappings by doing: for num in {0..255}; do iptables -A INPUT -p $num; done # iptables-save Change-Id: I5895250b47ddf664d214cf085be693c3897e0c87 Closes-bug: #1716045 Closes-bug: #1716790
Hello, Customer from case https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000b7kNe&sfdc.override=1 reported that they are able to create the security group using --protocol 4 in their environment, they`re currently running OSP12 and bellow I posted his env installed pakages. I would like to know why it's working in his env, and not on the env I recently deployed with OSP12 using director? Customer had his environemnt upgraded to OSP12 from OSP11, where the security group are supposed to work. Customer Environemnt: on compute: rpm -qa | grep openstack openstack-neutron-11.0.2-1.el7ost.noarch python-openstackclient-lang-3.12.0-1.el7ost.noarch openstack-nova-compute-16.0.4-5.el7ost.noarch python-openstackclient-3.12.0-1.el7ost.noarch openstack-neutron-openvswitch-11.0.2-1.el7ost.noarch openstack-utils-2015.2-1.el7ost.noarch openstack-nova-common-16.0.4-5.el7ost.noarch python-openstacksdk-0.9.17-1.el7ost.noarch openstack-neutron-ml2-11.0.2-1.el7ost.noarch openstack-selinux-0.8.13-2.el7ost.noarch openstack-neutron-common-11.0.2-1.el7ost.noarch On controller: rpm -qa | grep openstack openstack-dashboard-12.0.2-1.el7ost.noarch openstack-cinder-11.1.0-1.el7ost.noarch openstack-neutron-common-11.0.2-1.el7ost.noarch openstack-nova-api-16.0.4-5.el7ost.noarch openstack-heat-engine-9.0.3-1.el7ost.noarch openstack-utils-2015.2-1.el7ost.noarch python-openstacksdk-0.9.17-1.el7ost.noarch openstack-nova-conductor-16.0.4-5.el7ost.noarch openstack-neutron-openvswitch-11.0.2-1.el7ost.noarch openstack-keystone-12.0.0-4.el7ost.noarch python-openstackclient-3.12.0-1.el7ost.noarch openstack-heat-common-9.0.3-1.el7ost.noarch openstack-nova-common-16.0.4-5.el7ost.noarch openstack-nova-scheduler-16.0.4-5.el7ost.noarch openstack-nova-novncproxy-16.0.4-5.el7ost.noarch openstack-neutron-ml2-11.0.2-1.el7ost.noarch openstack-heat-api-9.0.3-1.el7ost.noarch openstack-nova-console-16.0.4-5.el7ost.noarch openstack-heat-api-cfn-9.0.3-1.el7ost.noarch openstack-dashboard-theme-12.0.0-3.el7ost.noarch python-django-openstack-auth-3.5.0-3.el7ost.noarch openstack-neutron-lbaas-ui-3.0.1-3.el7ost.noarch openstack-neutron-lbaas-11.0.2-2.el7ost.noarch openstack-glance-15.0.0-4.el7ost.noarch python-openstackclient-lang-3.12.0-1.el7ost.noarch openstack-neutron-11.0.2-1.el7ost.noarch openstack-nova-placement-api-16.0.4-5.el7ost.noarch openstack-heat-api-cloudwatch-9.0.3-1.el7ost.noarch openstack-selinux-0.8.13-2.el7ost.noarch
So we just pulled stable/pike downstream, so this fix should be in the latest candidate package, openstack-neutron-11.0.4-1.el7ost
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2514