yahoo-eng-team team mailing list archive

[OpenStack Infra <1549311@xxxxxxxxxxxxxxxxxx>]

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 <xiaohhui@xxxxxxxxxx>
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