Description of problem: We have a customer using OSP10 for a NVF project. He has a VNF that is connected to 2 provider networks and 1 tenant network for management. The VNF is using different MAC address and IPs that Neutron knows about but the port_security_enabled is set to False on these 2 provider networks. Still ICMP and TCP traffic is catch by this iptables rule on computes and blocked: [root@lxvcw1co202 heat-admin]# iptables -nL FORWARD --line-numbers Chain FORWARD (policy ACCEPT) num target prot opt source destination [...] 3 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited With port_security_enabled set to False the the packet should have been allowed before it hits the default REJECT rule for FORWARD chain. Version-Release number of selected component (if applicable): [root@lxvcw1co201 heat-admin]# rpm -qa | grep openstack-neutron openstack-neutron-9.1.0-7.el7ost.noarch openstack-neutron-bigswitch-lldp-9.40.0-1.1.el7ost.noarch openstack-neutron-sriov-nic-agent-9.1.0-7.el7ost.noarch openstack-neutron-lbaas-9.1.0-1.el7ost.noarch openstack-neutron-openvswitch-9.1.0-7.el7ost.noarch openstack-neutron-ml2-9.1.0-7.el7ost.noarch openstack-neutron-bigswitch-agent-9.40.0-1.1.el7ost.noarch openstack-neutron-metering-agent-9.1.0-7.el7ost.noarch openstack-neutron-common-9.1.0-7.el7ost.noarch How reproducible: Every time. Steps to Reproduce: 1. Create provider networks. 2. Disable port_security 3. Try to ping Actual results: iptable rules is blocking the traffic on the compute. Expected results: iptable rules should not block the traffic. Additional info:
@Alexandre, Would you please elaborate further on the reproduction steps? When a port is created it picks up the port_security_enabled flag set to the the network that it belongs to. So depending on the order, this could've happened: 1. Create network (port security is enabled by default) 2. Create ports (they'll get port_security_enabled=True) from the network 3. Update network and disable port security At this point, all ports will still have port_security_enabled=True so you need to manually disable it per port. Could you please post the output of net-show and port-show commands so that we can tell if that's the case? Also, a sosreport would be useful if all ports have port_security_enabled set to False and traffic's still blocked. Thanks, Daniel
Hi, I can confirm that the port_security_enabled was set to False on the network and on the ports. I can't access the platform at the moment but I will try to upload a sosreport next time. Nothing really special was configured in the templates so it should be quite easy to reproduce.
I cannot reproduce it. Also, tests apparently work as Toni and @ekuris point out. I think we need the sosreport and also more details. Let me recap to check whether I understood the issue: - VM with port1 on provider network A and port2 on provider network B. - From provider network A you can't ping VM port1 IP address - From provider network B you can't ping VM port2 IP address - port_security is disabled on network A, network B, port1 and port2 Is that correct? Thanks, Daniel
@Alexandre, I can get back into this as soon as you can access the platform and provide some more details. Thanks a lot! Daniel
Created attachment 1241413 [details] updated test template
It's possible that the REJECT rule is added by Director. But isn't the real problem the absence of ACCEPT --physdev rule when port security is disabled if that rule is expected to be there? When the port security is enabled, packets that need to be rejected will not be rejected here, but at neutron-openvswitch-sg-fallback chain. so it's not present there because other vms use port security enabled. Just my 2 cents.
OSP-10 -p 2017-02-15.1 [stack@undercloud-0 ~]$ rpm -qa |grep openstack-neutron-9 openstack-neutron-9.2.0-2.el7ost.noarch verified and fixed steps - 1. neutron net-create net-64-2 --port_security_enabled false 2. neutron subnet-create net-64-2 10.0.5.0/24 --name subnet_4 --enable_dhcp true 3. neutron router-create Router_eNet 4. neutron router-interface-add Router_eNet dd073541-b444-4ab6-8187-346d7a8eb96a 5. neutron router-gateway-set Router_eNet 25df8c01-0632-4b49-ac8c-31d0155bfb0e 6. nova boot --flavor 3 --image rhel VM1 --nic net-id=551f3ab9-2292-4d43-b8bd-b7bd59951799 7. neutron port-show 104ab04f-3b1f-408e-bee0-10ba0d6dab35 |grep security verify port_security_enabled = False 8. connectivity check from qrouter to VM1 ip net exec qrouter-5d10b101-4bc5-4261-aa3d-9c192e85ee06 ping 10.0.5.4 worked well !
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://rhn.redhat.com/errata/RHBA-2017-0314.html
*** Bug 1434016 has been marked as a duplicate of this bug. ***