Bug 1042536 - [RFE][neutron]: Enhance floating IP router lookup to consider extra routes
Summary: [RFE][neutron]: Enhance floating IP router lookup to consider extra routes
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact: Ofer Blaut
URL: https://blueprints.launchpad.net/neut...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-13 00:17 UTC by RHOS Integration
Modified: 2016-04-26 14:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 11:07:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-13 00:17:42 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/floating-ip-extra-route.

Description:

Scope: When a floating IP is associated with an internal address, there
is a verification that the internal address is reachable from the
router. Currently it only considers internal addresses that are
directly connected to the router.
The proposed change is to extend the verification to allow association
if the internal address belongs to a network that is reachable by an
extra route, over other gateway devices (such as routers, or
multi-homed compute instances).


Use Cases: A setup that has a gateway that is implemented by a compute
instance, that protects an internal network. The user wants to make an
instance in the internal network reachable over the Internet by
associating a floating IP to the internal instance.


Implementation Overview:
The L3_NAT_db_mixin._get_router_for_floatingip() method in
neutron/db/l3_db.py should be enhanced to allow the new use case. If
the internal network is not connected directly, go over the routers
that are connected to the external network, and match their extra
routes (if available) with the internal address. If a match is found,
find the network of the nexthop of the matching route, then verify
that a path exists over ports connecting networks and devices from
the nexthop network all the way to the internal network.
Also, because this method is overridden by a plugin to provide extra
validation of candidate routers, there is a need to accommodate adding
optional extra validation, by passing in an optional 'validate_router'
function that accepts a candidate router id and returns True/False.


Data Model Changes: N/A


Configuration variables: N/A


API's: N/A


Plugin Interface: The method signature for
L3_NAT_db_mixin._get_router_for_floatingip() will change. It will
include extra parameters:
internal_ip_address - (mandatory) the intenal address
validate_router - (optional) a function to filter candidate routers
(for example, filter out routers that do not support NAT)


Required Plugin support: Plugins that override the method in the
previous section, should be modified to comply with the changes.
Plugins that implement their own validate_router function, should call
the passed-in validation function (if any) and then call their own.


Dependencies: N/A, the change is contained in Neutron.


CLI Requirements: N/A, the proposed change is only in verification not
configuration.


Horizon Requirements: N/A, the proposed change is only in verification
not configuration.


Usage Example: Implement the use case above.


Test Cases: A new test: neutron.tests.unit.test_extension_extraroute:
ExtraRouteDBTestCaseBase.test_floatingip_reachable_by_route() will be
added to define following topology:

public-net -- r1 -- intermediate-net -- r2 -- internal-net --

Then, test association of a floating IP to the internal network.

Please also see:  https://bugs.launchpad.net/neutron/+bug/1250105


Specification URL (additional information):

None

Comment 4 Nir Yechiel 2014-03-06 14:44:09 UTC
Updating based on upstream milestone

Comment 5 lpeer 2015-03-19 11:07:48 UTC
This RFE was automatically opened to track status of upstream development.
At this point we see no reason to keep track of this in Red Hat bugzilla, thus closing it.


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