Bug Description
Description:
The type:hostroutes validator is not properly validating subnets that have non-zero values in the host portion of the network address (e.g., 1.2.3.1/24 rather than 1.2.3.0/24). This can cause issues for backends/drivers that assume that the data coming down from the server is valid.
For example, using those values with the Linux command line utilities will result in an error:
$ sudo ip route add 192.0.2.5/24 via 192.168.1.2
RTNETLINK answers: Invalid argument
But using the correct network address value results in a successful operation:
$ sudo ip route add 192.0.2.0/24 via 192.168.1.2
The issue can be reproduced on the latest devstack
Version: openstack_latest in latest devstack
scenario 1： subnet's host_routes
Steps to reproduce:
1. create network
$ openstack network create TestNet
2. create subnet
$ openstack subnet create TestSubnet --host-route destination=10.10.10.1/24,gateway=10.10.10.1 --network=TestNet --subnet-range 10.10.10.0/24
Expected output:'10.10.10.1/24' isn't a recognized IP subnet cidr, '10.10.10.0/24' is recommended.
Actual output: success
scenario 2: router's routes
Steps to reproduce:
1. create router
$ openstack router create TestRouter
2. add subnet to router
$ openstack router add subnet TestRouter TestSubnet
3. set the router
$ openstack router set --route destination=10.10.10.1/24,gateway=10.10.10.17 TestRouter
Expected output:'10.10.10.1/24' isn't a recognized IP subnet cidr, '10.10.10.0/24' is recommended.
Actual output: success
Thank you for your bug report.
I managed to reproduce the problem with:
neutron master @ dd14501c12243a8
neutron-lib master @ 1e6a07c5fc8275b
This is the first error message I see in the l3-agent log.
# journalctl -u devstack@neutron-l3
dec 03 11:32:13 devstack0 neutron-
24', 'via', '10.10.10.17'] {{(pid=24589) execute_
dec 03 11:32:13 devstack0 neutron-
I'm setting the importance to 'low', because it looks like to me there's no regression introduced here.
Looking at the code (starting here https:/
As a first attempt I'd suggest improving the subnet validation by rejecting subnet definitions in the format 'IP/prefix' instead of the conventional 'network address/prefix' format. Technically that seems easy with netaddr:
>>> import netaddr
>>> n = netaddr.
>>> if n.ip != n.network:
>>> ... the expected error message
Then tests and reviewers could tell if narrowing what we consider valid subnet input works out or we have to think about an alternative. I'm assuming you're working on a patch since you assinged the bug to yourself.