Open Stack

The logic makes sense to me here. I’m including Evan Callicoat in this response in case he has any comments on the points you make below.

Vish
 
On Jan 7, 2014, at 4:57 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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.
> _______________________________________________
> 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/20140108/af90a1f0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/af90a1f0/attachment.pgp>