[rfe] update CIDR for subnet

Bug #1605343 reported by Atsuko Ito on 2016-07-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Use case to solve: as an operator I want to expand or shrink Public network without re-allocating all Floating IPs.

Currently, updating subnet CIDR is blocked by validation from API side. By the way, PD code is already updating CIDRs so far.

Generic approach is:

  1. Accept CIDR and optionally allocation pools and gateway_ip.
  2. If new allocation pool is not provided, and old pool is not fit into
     CIDR, then fail. Same for GW.
  3. Re-allocate IP if they're out of new allocation pool.

Here is a proposed patch https://review.openstack.org/#/c/345594/

What is your use case? Usually there are good reasons for making certain resources immutable, like the CIDR on a subnet.

Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
Carl Baldwin (carl-baldwin) wrote :

This would have to be pretty restrictive, I think. PD kind of gets away with it because there is a mechanism for disseminating the new subnet to hosts on the subnet in IPv6 router advertisements.

IPv4 really doesn't have a good mechanism. DHCP would be terrible for this. You'd have a long period of time where you would need to expect things to just not work as all the various ports on the subnet are updated through DHCP and RPC (router ports, DHCP server ports, etc). There is no way that I'm aware of to reliably trigger a forced update to DHCP clients.

So, this would have to be restricted to IPv6 subnets where RA is used to be viable at all. Even then, what's the point? You can always add a second IPv6 subnet to the network and then delete the first one. Have you tried that to satisfy your use case?

I'm going to mark this incomplete until a good use case is described.

tags: added: l3-ipam-dhcp
Changed in neutron:
status: Confirmed → Incomplete
Atsuko Ito (yottatsa) on 2016-07-22
description: updated
Atsuko Ito (yottatsa) wrote :

I want to expand or shrink Public or Provider network CIDR (and thus range) without re-allocating all IPs.

Adding new Subnet and deleting old one is not working until all Ports are updated to use address from new Subnet. Also, there is no way to set overlapping Subnet this way.

I'm aware of the fact that updating IPv4 addresses on VMs is barely possible. However, Neutron allows it with port-update mechanism, so I see no difference between allowing operator to change Fixed (Floating) IP for single port, and for many ports.

description: updated
Changed in neutron:
assignee: nobody → Vladimir Eremin (yottatsa)
Changed in neutron:
status: Incomplete → In Progress
Atsuko Ito (yottatsa) on 2016-07-27
description: updated
Carl Baldwin (carl-baldwin) wrote :

I don't think a port update works on a bound port.

Also, you can grow the address space by adding a second subnet. We don't have a way to shrink a subnet.

You don't have to delete anything, just add aside the existing subnets. Besides, altering a longstanding contract may have unexpected side effects on plugins that do not handle well the CIDR update. For that reason, I am compelled to mark this WONTFIX, but let's raise it for wider discussion.

Changed in neutron:
status: In Progress → Triaged
Atsuko Ito (yottatsa) wrote :

Update on bound port is working, this mechanism is exactly what is using for:

  1. DHCPv6 PD,
  2. When you update IP for VM,
  3. When you're moving your VMs into new subnet.

So there is no way port update will break anything. The only valid implication here is "unexpected side effects on plugins that do not handle well the CIDR update".

On 2013, Neutron was not able to update allocation pools, but now it can. So I don't see any reasons to withdrawn this idea completely.

I think with randomized ip allocations, you can't really reliably shrink a pool anymore. As for expansion, you already have an option to add a new pool. So the benefit here is pretty low for what I wonder.

I would suggest not to give much priority to this proposal.

Atsuko Ito (yottatsa) wrote :

If your network administrator will change network on hardware router, say, from to, you will not able to add new subnet any way, because they are overlapping.

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/345594
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Vladimir, then add

Sorry, it is (?).

Nevermind, I screwed the math. :) So yeah, seems like we can't really do it?

Changed in neutron:
status: Triaged → Incomplete
assignee: Vladimir Eremin (yottatsa) → nobody

This was discussed during the drivers meeting [1]. It sounds like expanding or shrinking the IP space dynamically and doing it reliably can be rather hard. Can you elaborate why adding new subnets to the space wouldn't address your use case?

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-01-19-22.02.log.html

Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers