Public bug reported:
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
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1805991
Title:
IP Route: subnet's host_houtes attribute and router's routes accept
the invalidate subnets.
Status in neutron:
New
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1805991/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
