Reviewed: https://review.openstack.org/285982 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1cea77b0aafbada6cad89a6fe0f5450004aef4e1 Submitter: Jenkins Branch: master
commit 1cea77b0aafbada6cad89a6fe0f5450004aef4e1 Author: Hong Hui Xiao <[email protected]> Date: Mon Feb 29 11:07:15 2016 +0000 DVR: Fix issue of SNAT rule for DVR with floating ip With current code, there are 2 issues. 1) The prevent snat rule that is added for floating ip will be cleaned, when restarting the l3 agent. Without this rule, the fixed ip will be SNATed to floating ip, even if the network request is to an internal IP. 2) The prevent snat rule will not be cleaned, even if the external device(rfp device) is deleted. So, when the floating ips are removed from DVR router, there are still dump rules in iptables. Restarting the l3 agent can clean these dump rules. The fix in this patch will handle DVR floating ip nat rules at the same step to handle nat rules for other routers(legacy router, dvr edge router) After the change in [1], the fip nat rules for external port have been extracted together into a method. Add all rules in that method in the same step can fix the issue of ping floating ip, but reply with fixed ip. [1] https://review.openstack.org/#/c/286392/ Change-Id: I018232c03f5df2237a11b48ac877793d1cb5c1bf Closes-Bug: #1549311 Related-Bug: #1462154 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1549311 Title: Unexpected SNAT behavior between instances with DVR+floating ip Status in neutron: Fix Released Bug description: This might be related with [1]. The fix in [1] should be applied to dvr_local_router. = Scenario = • Latest code • Single Neutron DVR router, multiple hosts • two instances in two tenant networks attached to DVR router, the two instances are in two different hosts • Instance A has a floatingip INSTANCE A: TestNet1=100.0.0.4, 172.168.1.53 INSTANCE B: TestNet2=100.0.1.4 Pinging from INSTANCE A to INSTANCE B: tcpdump from Instance B [root@dvr-compute2 fedora]# tcpdump -ni qr-ca45d1e3-5d icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on qr-ca45d1e3-5d, link-type EN10MB (Ethernet), capture size 262144 bytes 14:31:54.054629 IP 100.0.1.4 > 172.168.1.53: ICMP echo reply, id 18433, seq 0, length 64 The problem here is that it should be an internal communication, but the reply go through external network. [1] https://bugs.launchpad.net/neutron/+bug/1505781 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549311/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
