Description of problem: We are trying to add a second subnet to one of our external networks in Neutron, the one used to connect OpenStack to the Internet and to provide a poo of IP addresses that are public and reachable from the Internet. The first subnet we created looks like this: # neutron subnet-show ext_inet_subnet +------------------+---------------------------------------------------+ | Field | Value | +------------------+---------------------------------------------------+ | allocation_pools | {"start": "10.95.187.99", "end": "10.95.187.125"} | | cidr | 10.95.187.96/27 | | dns_nameservers | | | enable_dhcp | False | | gateway_ip | 10.95.187.126 | | host_routes | | | id | b418ac81-4696-4535-bd79-8f291a4b838e | | ip_version | 4 | | name | ext_inet_subnet | | network_id | 1cc11e66-50c5-4ab5-ae4f-eac7314d6728 | | tenant_id | c3308c46e77546d48763c51e506b5aa3 | +------------------+---------------------------------------------------+ and the second subnet created looks like this: # neutron subnet-show ext_inet_subnet2 +------------------+---------------------------------------------------+ | Field | Value | +------------------+---------------------------------------------------+ | allocation_pools | {"start": "10.95.223.99", "end": "10.95.223.125"} | | cidr | 10.95.223.96/27 | | dns_nameservers | | | enable_dhcp | False | | gateway_ip | 10.95.223.126 | | host_routes | | | id | 0ff3a576-2b9c-4f05-9a67-ff8cac319bec | | ip_version | 4 | | name | ext_inet_subnet2 | | network_id | 1cc11e66-50c5-4ab5-ae4f-eac7314d6728 | | tenant_id | 1a6430a017be44f3a69cbc2e4ec69096 | +------------------+---------------------------------------------------+ The problem is that adding this second subnet does not seem to create the necessary on-link routes, and traffic between these two subnets goes to the upstream router (effectively exiting the OpenStack network node) then back. This is very inefficient: # ip netns exec qrouter-fe8beab0-8be8-4568-ac1d-ea6f9a0e8f8b netstat -anr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.95.187.96 0.0.0.0 255.255.255.224 U 0 0 0 qg-c17e5a53-53 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-3d557150-e7 0.0.0.0 10.95.187.126 0.0.0.0 UG 0 0 0 qg-c17e5a53-53 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: # ip netns exec qrouter-fe8beab0-8be8-4568-ac1d-ea6f9a0e8f8b netstat -anr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.95.187.96 0.0.0.0 255.255.255.224 U 0 0 0 qg-c17e5a53-53 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-3d557150-e7 0.0.0.0 10.95.187.126 0.0.0.0 UG 0 0 0 qg-c17e5a53-53 Expected results: # ip netns exec qrouter-fe8beab0-8be8-4568-ac1d-ea6f9a0e8f8b netstat -anr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.95.187.96 0.0.0.0 255.255.255.224 U 0 0 0 qg-c17e5a53-53 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-3d557150-e7 10.95.223.99 0.0.0.0 <=================== A onlink route here 0.0.0.0 10.95.187.126 0.0.0.0 UG 0 0 0 qg-c17e5a53-53 Additional info: This problem is solved documented and solved here: https://bugs.launchpad.net/neutron/+bug/1312467
Eduard, Please see the link above posted by Ihar. This is a test package for the customer based on OSP-4. Please let us know if the build is providing the required functionality. After your confirmation we'll make it formally part of OSP-4 (available in OSP-4 A6). Thanks, Livnat
The fix to OSP-5 is merged.
Checked with openstack-neutron-2014.1.5-2.el7ost.noarch. When creating a router with multiple subnets I get the correct output: ip netns exec qrouter-07c1dc76-1926-47d6-ac90-add6e31ea1ae netstat -nar Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.35.175.101 0.0.0.0 UG 0 0 0 qg-e624b5da-33 10.35.175.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-e624b5da-33 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-e624b5da-33 When doing the following steps: 1. Create a network with one subnet 2. Set the router's gateway 3. Add a subnet to the network. With the this scenario there is no additional route. After restarting the L3 agent the route is being added. Is it the expected behaviour?
Indeed seems like a problematic behaviour. From my research it would seem that this is because the router doesn't get updated in such a scenario, thus the code to add the onlink route doesn't get triggered. When you restart the agent, the data is synced from the server so the agent does see the new route and adds it correctly. Since this backport is for icehouse and the code changed immensely, I suggest that you check if this still happens in Kilo (RHOS 7) and if it does report this as a new bug.
Verified using openstack-neutron-2014.1.5-2.el7ost.noarch. I'll open a bug upstream regarding comment #19.
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-2015-1754.html