Open Stack

See Sean Collins' review https://review.openstack.org/#/c/56381 which
disables hairpinning when Neutron is in use.  tl;dr - please upvote the
review.  Long form reasoning follows...

There's a solid logical reason for enabling hairpinning, but it only
applies to nova-network.  Hairpinning is used in nova-network so that
packets from a machine and destined for that same machine's floating IP
address are returned to it.  They then pass through the rewrite rules
(within the libvirt filters on the instance's tap interface) that do the
static NAT mapping to translate floating IP to fixed IP.

Whoever implemented this assumed that hairpinning in other situations is
harmless.  However, this same feature also prevents IPv6 from working -
returned neighbor discovery packets panic VMs into thinking they're using a
duplicate address on the network.  So we'd like to turn it off.  Accepting
that nova-network will change behaviour comprehensively if we just remove
the code, we've elected to turn it off only when Neutron is being used and
leave nova-network broken for ipv6.

Obviously, this presents an issue, because we're changing the way that
Openstack behaves in a user-visible way - hairpinning may not be necessary
or desirable for Neutron, but it's still detectable when it's on or off if
you try hard enough - so the review comments to date have been
conservatively suggesting that we avoid the functional change as much as
possible, and there's a downvote to that end.  But having done more
investigation I don't think there's sufficient justification to keep the
status quo.

We've also talked about leaving hairpinning off if and only if the Neutron
plugin explicitly says that it doesn't want to use hairpinning.  We can
certainly do this, and I've looked into it, but in practice it's not worth
the code and interface changes:

 - Neutron (not 'some drivers' - this is consistent across all of them)
does NAT rewriting in the routers now, not on the ports, so hairpinning
doesn't serve its intended purpose; what it actually does is waste CPU and
bandwidth by receives a packet every time it sends an outgoing packet and
precious little else.  The instance doesn't expect these packets, it always
ignores these packets, but it receives them anyway.  It's a pointless
no-op, though there exists the theoretical possibility that someone is
relying on it for their application.
- it's *only* libvirt that ever turns hairpinning on in the first place -
none of the other drivers do it
- libvirt only turns it on sometimes - for hybrid VIFs it's enabled, if
generic VIFs are configured and linuxbridge is in use it's enabled, but for
generic VIFs and OVS is in use then the enable function fails silently
(and, indeed, has been designed to fail silently, it seems).

Given these details, there seems little point in making the code more
complex to support a feature that isn't universal and isn't needed; better
that we just disable it for Neutron and be done.  So (and test failures
aside) could I ask that the core devs check and approve the patch review?
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140107/7cd99d13/attachment.html>