<div dir="ltr">See Sean Collins' review <a href="https://review.openstack.org/#/c/56381">https://review.openstack.org/#/c/56381</a> which disables hairpinning when Neutron is in use.  tl;dr - please upvote the review.  Long form reasoning follows...<br>

<br>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.<br>

<br>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.<br>

<br><div>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.<br>

<br>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: <br><br> - 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.<br>

</div><div>- it's *only* libvirt that ever turns hairpinning on in the first place - none of the other drivers do it<br>-
 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).<br>

<br>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?<br>

-- <br></div>Ian.</div>