Bug 1824475 - [RFE] Full support for /31 subnets
Summary: [RFE] Full support for /31 subnets
Keywords:
Status: POST
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 18.0 (Zed)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: OSP Team
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-16 09:45 UTC by Bernard Cafarelli
Modified: 2023-07-12 16:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1580927 0 None None None 2020-04-16 09:47:31 UTC
OpenStack gerrit 318542 0 None MERGED Using 31-Bit and 32-Bit prefixes for IPv4 reasonably 2022-10-25 11:48:00 UTC
Red Hat Issue Tracker OSP-2372 0 None None None 2022-02-22 05:46:33 UTC

Description Bernard Cafarelli 2020-04-16 09:45:52 UTC
/31 networks can be used for point-to-point interfaces and are used in Telco environments - RFC 3021 [0] describes such prefixes
These subnets do not have DHCP or gateway and should be created with correct options. 

Neutron API allows such subnets creation, but some parts of neutron-server especially around IPAM and allocation pools will not allow its actual use [1].

This happens if code does not handle such network type, where the two possible addresses match the typical network and broadcast ones (first and last).

For some drivers, additional work may be required to support them. For instance with OVN, support should be added to skip metadata port creation for such subnets [2]

Typical test case would be to create a /31 subnet without DHCP/gateway/medatata, create 2 VMs using the 2 possible addresses and check connectivity between them

[0] https://tools.ietf.org/html/rfc3021
[1] https://bugs.launchpad.net/neutron/+bug/1580927
[2] https://github.com/openstack/neutron/blob/da63adc96bf9f8eafd66d0aeea5d6f8f787420ed/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L2282

Comment 1 Slawek Kaplonski 2020-04-16 10:48:00 UTC
So IIUC, currently in Neutron with e.g. ML2/OVS we can do that but user needs to manually set --no-gateway and --no-dhcp for such subnet. And then it should works fine, right?
In case of OVN driver there is an issue with metadata port which will be always created.

If that is correct, what exactly we should do in this new RFE? Some API changes which will force no gateway and no dhcp in case of /31 subnets always? Or is it just about Metadata port in OVN driver (and some documentation about how to create such networks in Neutron)?

I'm asking about that because I'm not sure if we really need to treat this as new RFE or just "bug" in OVN driver.

Comment 2 Bernard Cafarelli 2020-04-16 11:58:00 UTC
API allows the subnet creation indeed (remembering to skip gateway and DHCP), but it cannot be used after that. Testing with ML2/OVS I see same issue as in original linked LP, allocation pool and IP validity checks fail.

Something like the original suggested change plus generate_pools() would need a similar update - it handles /31 networks but only by skipping allocation pool creation for them:
https://opendev.org/openstack/neutron/src/branch/master/neutron/ipam/utils.py#L68
In same code, check_subnet_ip() also needs an update to allow the use of network itself as an IP


Note You need to log in before you can comment on or make changes to this bug.