yahoo-eng-team team mailing list archive

[Itsuro Oda <oda@xxxxxxxxxxxxx>]

Public bug reported:

If one try to communicate from a tenant network to floatingip which attached to
a port on the same network, the communication fails.

------------------------------------------------------------
for example, unable to communicate from 10.0.0.3 to 100.0.0.5

  --------+---------   exeternal
          |           100.0.0.0/24
     +----+----+
     | router  |
     +----+----+
          |         10.0.0.0/24
  --+-----+----+----   internal
    |          |                
  10.0.0.3  10.0.0.4             
           (100.0.0.5)
-------------------------------------------------------------

Note that ping is not adequate to check connection.
icmp reply is returned thus ping success but the from address is different. 
---
<10.0.0.3 host>: $ ping 100.0.0.5
PING 100.0.0.5 (100.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=3.45 ms   (must be returned from 100.0.0.5)
---
(This is because destination address (100.0.0.5) is DNATed to fixed ip (10.0.0.4)
on the router, but reply does not go through the router.)

Use TCP/IP (ex. ssh) to check connection.

This problem is a regression cased by https://review.openstack.org/#/c/131905/ .
(it is my fault.)
This maybe not common use case but should be fixed since it was OK before the patch.

** Affects: neutron
     Importance: Undecided
     Assignee: Itsuro Oda (oda-g)
         Status: New


** Tags: l3-ipam-dhcp

** Tags added: l3-ipam-dhcp

** Changed in: neutron
     Assignee: (unassigned) => Itsuro Oda (oda-g)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1428887

Title:
  Unable to communicate to floatingip on a same network

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If one try to communicate from a tenant network to floatingip which attached to
  a port on the same network, the communication fails.

  ------------------------------------------------------------
  for example, unable to communicate from 10.0.0.3 to 100.0.0.5

    --------+---------   exeternal
            |           100.0.0.0/24
       +----+----+
       | router  |
       +----+----+
            |         10.0.0.0/24
    --+-----+----+----   internal
      |          |                
    10.0.0.3  10.0.0.4             
             (100.0.0.5)
  -------------------------------------------------------------

  Note that ping is not adequate to check connection.
  icmp reply is returned thus ping success but the from address is different. 
  ---
  <10.0.0.3 host>: $ ping 100.0.0.5
  PING 100.0.0.5 (100.0.0.5) 56(84) bytes of data.
  64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=3.45 ms   (must be returned from 100.0.0.5)
  ---
  (This is because destination address (100.0.0.5) is DNATed to fixed ip (10.0.0.4)
  on the router, but reply does not go through the router.)

  Use TCP/IP (ex. ssh) to check connection.

  This problem is a regression cased by https://review.openstack.org/#/c/131905/ .
  (it is my fault.)
  This maybe not common use case but should be fixed since it was OK before the patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428887/+subscriptions