[openstack-dev] 答复: [neutron][dvr][fip] fg device allocated private ip address
Carl Baldwin
carl at ecbaldwin.net
Tue Aug 9 17:48:15 UTC 2016
On Wed, Aug 3, 2016 at 1:22 AM, zhuna <juno.zhu at huawei.com> wrote:
> Hi Carl,
>
>
>
> IMO, if the upstream router has the route to floating ip subnet, no need
> to assign additional IP address to the router.
>
>
>
> For example, there are 2 subnets in external network,
>
> Subnet1: 10.0.0.0/24 (fg ip address)
>
> Subnet2: 9.0.0.0/24 (fip)
>
>
>
> Suppose assign fip 9.0.0.10 for vm1, and the fg ip address is 10.0.0.10,
> so there are 2 ip address configured in fg, one is 9.0.0.10 and 10.0.0.10.
>
> +-------------------+
>
> | router ns |
>
> +-------------------+
>
> | fg (10.0.0.10, 9.0.0.10)
>
> |
>
> |
>
> | router-if (10.0.0.1)
>
> +---------------------------+
>
> | upstream router |---------------------------- Internet
>
> +---------------------------+
>
>
>
> The default route of router ns is 10.0.0.1, add a static route
> 9.0.0.10/32 10.0.0.10 to upstream router , or learn the route by routing
> protocol (neutron-dynamic-routing).
>
This could certainly work. It would require some changes in the L3 agent
because the L3 agent assumes that each of the subnets on the external
network has a gateway address. It doesn't currently distinguish between
different service types. So, when it gets its static address, 10.0.0.10/24,
it will expect a gateway address within that subnet (e.g. 10.0.0.1).
We could make changes to the L3 agent to accommodate this but I'm hesitant
to do this because it is much easier to get the default route from the
interface's static address. This is because the floating IP addresses come
and go and so we'd have to manage the default gateway for the router as
they do. Also, routers that happen to not be hosting any floating ip
addresses (CVRs, not DVRs) will not have any default gateway. It seems a
lot more straight-forward to me to just require that the upstream router
have an address on fg subnet.
Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160809/478db464/attachment.html>
More information about the OpenStack-dev
mailing list