Bug 1308979 - [RFE] Router interface creation fails if first address is already used
[RFE] Router interface creation fails if first address is already used
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Assaf Muller
Toni Freger
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-16 11:04 EST by Alex Stellwag
Modified: 2017-05-18 18:39 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-05-18 18:39:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Stellwag 2016-02-16 11:04:26 EST
Description of problem:

When a router interface is created, neutron always tries to assign the first available IP address and fails if it is already in use

Version-Release number of selected component (if applicable):

openstack-neutron.noarch     2015.1.2-6.el7ost

How reproducible:

100%

Steps to Reproduce:
1. create two networks
2. create a router w/o external network and give it an interface in each of the (internal) networks just created
3. create a second router (w/ external gateway)
4. give that second router an interface in one of the internal networks

Actual results:

The interface creation fails with (i.e.) "Address 172.16.0.1 is already in use"

Expected results:

Interface is properly created

Additional info:

The interface can be created by manually specifying an unused address but it should work automatically.
Comment 2 Assaf Muller 2016-02-16 11:23:27 EST
From my perspective this isn't strictly a bug, seeing as how the code is doing what it's supposed to be doing (Grab the first IP address on a CIDR for a router interface). We can modify the behavior to grab the first *available* address, but seeing as you can ask for a specific IP address when you attach a router to an interface, a workaround is readily available, and so the impact of this issue is low.
Comment 3 Assaf Muller 2016-04-11 19:05:58 EDT
(In reply to Alex Stellwag from comment #0)
> Description of problem:
> 
> When a router interface is created, neutron always tries to assign the first
> available IP address and fails if it is already in use
> 
> Version-Release number of selected component (if applicable):
> 
> openstack-neutron.noarch     2015.1.2-6.el7ost
> 
> How reproducible:
> 
> 100%
> 
> Steps to Reproduce:
> 1. create two networks
> 2. create a router w/o external network and give it an interface in each of
> the (internal) networks just created
> 3. create a second router (w/ external gateway)
> 4. give that second router an interface in one of the internal networks
> 
> Actual results:
> 
> The interface creation fails with (i.e.) "Address 172.16.0.1 is already in
> use"
> 
> Expected results:
> 
> Interface is properly created
> 
> Additional info:
> 
> The interface can be created by manually specifying an unused address but it
> should work automatically.

I understand the bug and why it happens. I can't say I understand the rationale or use case for solving it. Looking at the steps for reproduction, can you explain why that is useful?

You have R1 connected to N1 and N2, and R2 connected only to N2 and an external network. What's the use case here?
Comment 4 lpeer 2017-01-30 05:33:32 EST
(In reply to Assaf Muller from comment #3)
> I understand the bug and why it happens. I can't say I understand the
> rationale or use case for solving it. Looking at the steps for reproduction,
> can you explain why that is useful?
> 
> You have R1 connected to N1 and N2, and R2 connected only to N2 and an
> external network. What's the use case here?

There are regulations that require the DB to be on a separate network from the webserver for example (the regulations usually refers to 3 layers but two are as good for this discussion).

there is no reason for the DB to be connected to the external network but the webserver does need to be connected.

VM1 (DB) on N1
VM2 (webserver) on N2

you need VM1 to be reachable from VM2
you need external connectivity to VM2
Comment 5 Assaf Muller 2017-05-18 18:39:54 EDT
[...]

> 
> There are regulations that require the DB to be on a separate network from
> the webserver for example (the regulations usually refers to 3 layers but
> two are as good for this discussion).
> 
> there is no reason for the DB to be connected to the external network but
> the webserver does need to be connected.
> 
> VM1 (DB) on N1
> VM2 (webserver) on N2
> 
> you need VM1 to be reachable from VM2
> you need external connectivity to VM2

Understood. The use case can be satisfied by specifying the IP address the 2nd router should use. It can also be specified via a single router and security groups.

Since Neutron does allow you to specify the address of a router interface, I'm closing this RFE.

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