yahoo-eng-team team mailing list archive

[Alejandro Garcia <2102165@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Hi all. We have been struggling with this lately and would like to
trigger the discussion for an enhancement. We would like to have a way
of forbidding the usage of certain IP addresses in subnets. In other
words, we need to prevent ports or floating IPs from getting a certain
address in a range.

The current implementation relies only on the usage of allocation pools,
but this range of addresses is only valid for dynamically allocated
ports. Thus, a user could still manage to create a port with a fixed IP
address outside of the allocation pool range. We have not validated if
this can also be done with floating IPs.

The most common workaround that exist out there is to create a "dummy
port" in the subnet to reserve the blocked IP address. We have been
using this approach to block some VIPs, but with enough addresses it
becomes a problem to manage all those extra ports. Also, the accidental
deletion of any of those ports would release the address again, so this
does not represent a very robust solution.

What we would really like is another attribute for subnets/subnet pools
that would act as the hard-opposite of the allocation pool. For example:

openstack subnet create s1 --network n1
--subnet-range 192.168.10.0/24
--allocation-pool start=192.168.10.100,end=192.168.199.200
--ban-pool start=192.168.10.201,end=192.168.199.255

This should provide a real mechanism to truly forbidding the addresses
in the range 192.168.10.201-192.168.199.255. It would also allow for
some flexibility regarding the fixed IP addresses, as some ranges could
still be outside of both the allocation and the ban pools (i.e. the
addresses in the range 192.168.10.1-192.168.199.99 could still be used
for ports with fixed IPs).

Please let us know what would you think of a mechanism like this.

** 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/2102165

Title:
  [RFE] Forbid usage of certain IP addresses in subnet pools

Status in neutron:
  New

Bug description:
  Hi all. We have been struggling with this lately and would like to
  trigger the discussion for an enhancement. We would like to have a way
  of forbidding the usage of certain IP addresses in subnets. In other
  words, we need to prevent ports or floating IPs from getting a certain
  address in a range.

  The current implementation relies only on the usage of allocation
  pools, but this range of addresses is only valid for dynamically
  allocated ports. Thus, a user could still manage to create a port with
  a fixed IP address outside of the allocation pool range. We have not
  validated if this can also be done with floating IPs.

  The most common workaround that exist out there is to create a "dummy
  port" in the subnet to reserve the blocked IP address. We have been
  using this approach to block some VIPs, but with enough addresses it
  becomes a problem to manage all those extra ports. Also, the
  accidental deletion of any of those ports would release the address
  again, so this does not represent a very robust solution.

  What we would really like is another attribute for subnets/subnet
  pools that would act as the hard-opposite of the allocation pool. For
  example:

  openstack subnet create s1 --network n1
  --subnet-range 192.168.10.0/24
  --allocation-pool start=192.168.10.100,end=192.168.199.200
  --ban-pool start=192.168.10.201,end=192.168.199.255

  This should provide a real mechanism to truly forbidding the addresses
  in the range 192.168.10.201-192.168.199.255. It would also allow for
  some flexibility regarding the fixed IP addresses, as some ranges
  could still be outside of both the allocation and the ban pools (i.e.
  the addresses in the range 192.168.10.1-192.168.199.99 could still be
  used for ports with fixed IPs).

  Please let us know what would you think of a mechanism like this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2102165/+subscriptions