Description of problem: quantum CIDR is not checked. 1. user can configured incorrect subnet like 10.10.1.1/24 and gw 10.10.1.1 2. subnet must be 10.10.1.0/24 3. this was checked via Horizon another example subnet 50.50.0.77/25 and gw 50.50.1.1 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. configured subnet 10.10.1.1/24 gw 10.10.1.1 2. configure subnet 50.50.0.77/25 and gw 50.50.1.1 3. Actual results: it passed Expected results: pool is :50.50.0.1 - End 50.50.0.126 and gw 50.50.1.2 configuration must fail Additional info:
A fix for upstream has been proposed - https://review.openstack.org/#/c/19048/
It is still not enforced [root@puma34 ~(keystone_admin)]$ quantum subnet-create net1 55.53.1.1/24 --gateway_ip 55.53.2.1 --tenant-id 85cb49f7ab1b4f4d89c33c07b74a967d Created a new subnet: +------------------+----------------------------------------------+ | Field | Value | +------------------+----------------------------------------------+ | allocation_pools | {"start": "55.53.1.1", "end": "55.53.1.254"} | | cidr | 55.53.1.1/24 | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 55.53.2.1 | | host_routes | | | id | e0043c88-678e-48a0-a0af-27fb0fcc0e48 | | ip_version | 4 | | name | | | network_id | 3991fec8-d178-47d3-8f54-72def3d889f8 | | tenant_id | 85cb49f7ab1b4f4d89c33c07b74a967d | +------------------+----------------------------------------------+ [root@puma34 ~(keystone_admin)]$ quantum subnet-create net1 55.54.1.1/24 --gateway_ip 60.53.2.1 --tenant-id 85cb49f7ab1b4f4d89c33c07b74a967d Created a new subnet: +------------------+----------------------------------------------+ | Field | Value | +------------------+----------------------------------------------+ | allocation_pools | {"start": "55.54.1.1", "end": "55.54.1.254"} | | cidr | 55.54.1.1/24 | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 60.53.2.1 | | host_routes | | | id | 5027c803-60b9-482f-8fd6-dbea4967b848 | | ip_version | 4 | | name | | | network_id | 3991fec8-d178-47d3-8f54-72def3d889f8 | | tenant_id | 85cb49f7ab1b4f4d89c33c07b74a967d | +------------------+----------------------------------------------+ [root@puma34 ~(keystone_admin)]$ rpm -qa | grep quantum python-quantum-2012.2.3-3.el6ost.noarch openstack-quantum-openvswitch-2012.2.3-3.el6ost.noarch python-quantumclient-2.1.10-3.el6ost.noarch openstack-quantum-2012.2.3-3.el6ost.noarch
In the configuration file file quantum.conf there ia a new configuration vaiable - force_gateway_on_subnet. This is by default False. If you set this as True then the functionality that you require will be enforced. We can discuss whether or not True should be the default. At the moment is is False to ensure that we have backward compatibility. # Ensure that configured gateway is on subnet # force_gateway_on_subnet = False Thanks Gary
please not that this should be in the DEFAULT section
quantum subnet-create net1 78.54.1.0/24 --gateway_ip 78.54.1.15 --tenant-id 85cb49f7ab1b4f4d89c33c07b74a967d Created a new subnet: +------------------+-----------------------------------------------+ | Field | Value | +------------------+-----------------------------------------------+ | allocation_pools | {"start": "78.54.1.1", "end": "78.54.1.14"} | | | {"start": "78.54.1.16", "end": "78.54.1.254"} | | cidr | 78.54.1.0/24 | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 78.54.1.15 | | host_routes | | | id | 1ca4e943-b99a-4ab0-8b06-39756c34908f | | ip_version | 4 | | name | | | network_id | 3991fec8-d178-47d3-8f54-72def3d889f8 | | tenant_id | 85cb49f7ab1b4f4d89c33c07b74a967d | +------------------+-----------------------------------------------+ [root@puma34 ~(keystone_admin)]$ quantum subnet-create net1 78.55.1.0/24 --gateway_ip 78.57.1.15 --tenant-id 85cb49f7ab1b4f4d89c33c07b74a967d Invalid input for operation: Gateway is not valid on subnet.
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. http://rhn.redhat.com/errata/RHBA-2013-0593.html