[openstack-dev] [Neutron] L3 HA VRRP concerns

Salvatore Orlando sorlando at nicira.com
Mon Feb 24 19:13:42 UTC 2014


Hi Assaf,

some comments inline.
As a general comment, I'd prefer to move all the discussions to gerrit
since the patches are now in review.
This unless you have design concerns (the ones below look more related to
the implementation to me)

Salvatore


On 24 February 2014 15:58, Assaf Muller <amuller at redhat.com> wrote:

> Hi everyone,
>
> A few concerns have popped up recently about [1] which I'd like to share
> and discuss,
> and would love to hear your thoughts Sylvain.
>
> 1) Is there a way through the API to know, for a given router, what agent
> is hosting
> the active instance? This might be very important for admins to know.
>

I reckon the current agent management extension already provides this
information, but I'll double check this.
This is an admin-only extension.


>
> 2) The current approach is to create an administrative network and subnet
> for VRRP traffic per router group /
> per router. Is this network counted in the quota for the tenant? (Clearly
> it shouldn't). Same
> question for the HA ports created for each router instance.
>

That is a good point. I have not reviewed the implementation so I cannot
provide a final answer.
I think it should be possible to assign to admins rather than tenants; if
not I would consider this an important enhancement, but I would not hold
progress on the patches currently on review because of this.


> 3) The administrative network is created per router and takes away from
> the VLAN ranges if using
> VLAN tenant networks (For a tunneling based deployment this is a
> non-issue). Maybe we could
> consider a change that creates an administrative network per tenant (Which
> would then limit
> the solution to up to 255 routers because of VRRP'd group limit), or an
> admin network per 255
> routers?
>

I am not able to comment on this question. I'm sure the author(s) will be
able to.


>
> 4) Maybe the VRRP hello and dead times should be configurable? I can see
> admins that would love to
> up or down these numbers.
>
>
I reckon this a reasonable thing to have. This could be either pointed out
in the reviews or pushed as an additional change on top of the other ones
in review.


> 5) The administrative / VRRP networks, subnets and ports that are created
> - Will they be marked in any way
> as an 'internal' network or some equivalent tag? Otherwise they'd show up
> when running neutron net-list,
> in the Horizon networks listing as well as the graphical topology drawing
> (Which, personally, is what
> bothers me most about this). I'd love them tagged and hidden from the
> normal net-list output,
> and something like a 'neutron net-list --all' introduced.
>

I agree this should be avoided; this is also connected to the point you
raised at #2.


>
> 6) The IP subnet chosen for VRRP traffic is specified in neutron.conf. If
> a tenant creates a subnet
> with the same range, and attaches a HA router to that subnet, the
> operation will fail as the router
> cannot have different interfaces belonging to the same subnet. Nir
> suggested to look into using
> the 169.254.0.0/16 range as the default because we know it will
> (hopefully) not be allocated by tenants.
>

We adopted a similar approach in the NSX plugin for a service network which
the plugin uses for metadata access.
In that case we used the link-local network, but perhaps an easier solution
would be to make the cidr specified in neutron.conf "reserved" thus
preventing tenants from specifying subnets overlapping with this range in
the first place.
I reckong the link-local range is a good candidate for the default value.


>
> [1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
>
>
> Assaf Muller, Cloud Networking Engineer
> Red Hat
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/e3a3ee7c/attachment-0001.html>


More information about the OpenStack-dev mailing list