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.ubu...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
