yahoo-eng-team team mailing list archive

[Aleš Rothbauer <1847763@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We are encountering problems with an unreachable instances when we are
trying to reuse (released) floating IP and creating new port with this
IP address as a fixed-ip. Currently I could test it with older OS Mitaka
and newer Queens versions. It seems both versions are behaving slightly
differently, but with the same result.

Our external network from which floating IPs are provided is called
"provider" (uuid = e2ebbb95-8b02-4bca-a7ab-4dd8670f9de0) and it's only
subnet is called "provider-sub" (uuid = 1c504dad-6d3c-
48a8-ae46-b88df78bce3c). Internal Neutron networks are irrelevant for
now.

Steps to reproduce:

1) Create linux (in my case Ubuntu Bionic) instance with one neutron-port with internal network IP address
2) Associate a floating IP from "provider" network, ping/ssh to instance - everything is OK
3) Disassociate the floating IP and detach interface with the internal IP address // now instance is unavailable as it is without any IP address - nothing strange or unawaited
4) Release the floating IP
5) Create a new port with fixed-ip (the same one as was used for floating-ip before); command for Neutron CLI would be like this: `neutron port-create --fixed-ip subnet_id=1c504dad-6d3c-48a8-ae46-b88df78bce3c,ip_address=10.248.236.16 e2ebbb95-8b02-4bca-a7ab-4dd8670f9de0` // sorry for still using neutron-cli - I hope this is not the problem, but it shouldn't be because we saw the same behaviour also when doing it with Horizon)
6) Attach the interface to testing instance (instance uuid = 47d0055a-f94d-498b-9e7a-bc1b6ae1410a) like this: `nova interface-attach --port-id f6c81ee6-9c5e-4314-a514-29126b4fb35a 47d0055a-f94d-498b-9e7a-bc1b6ae1410a`

After this I can see a duplicate in lease file for the external network
(this is from Mitaka, so IP address is different then the one above):

fa:16:3e:c6:e2:8d,host-10-4-131-96.openstacklocal,10.4.131.96
fa:16:3e:67:7d:38,host-10-4-131-96.openstacklocal,10.4.131.96

OR... there is nothing in lease file at all for the external network in
case of our Queens OS - but it's probably OK, because it could be
handled statically or by Calico - I'm really not sure about this,
because the Queens OS version was deployed by external company.

But an important think is that after this, on both OS clouds, the VM
lose connectivity. At least on Mitaka, we are able to get it up when we
restart all neutron-dhcp-agents (or at least the one residing on compute
where the VM runs). Also I didn't see in logs that there was DHCPRELEASE
message send to neutron-dhcp-agents, after floating IP release call. I
guess that it's possible the DHCPRELEASE message isn't send at all and
that's why we got duplicates in this case.

This is probably a minor issue because the way of releasing floating-ip
and reusing it on a new port as fixed-ip isn't quite standard, but still
- Neutron let you do it, so it should work then.

** Affects: neutron
     Importance: Undecided
         Status: New

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

Title:
  cannot reuse floating IP as port's fixed-ip

Status in neutron:
  New

Bug description:
  We are encountering problems with an unreachable instances when we are
  trying to reuse (released) floating IP and creating new port with this
  IP address as a fixed-ip. Currently I could test it with older OS
  Mitaka and newer Queens versions. It seems both versions are behaving
  slightly differently, but with the same result.

  Our external network from which floating IPs are provided is called
  "provider" (uuid = e2ebbb95-8b02-4bca-a7ab-4dd8670f9de0) and it's only
  subnet is called "provider-sub" (uuid = 1c504dad-6d3c-
  48a8-ae46-b88df78bce3c). Internal Neutron networks are irrelevant for
  now.

  Steps to reproduce:

  1) Create linux (in my case Ubuntu Bionic) instance with one neutron-port with internal network IP address
  2) Associate a floating IP from "provider" network, ping/ssh to instance - everything is OK
  3) Disassociate the floating IP and detach interface with the internal IP address // now instance is unavailable as it is without any IP address - nothing strange or unawaited
  4) Release the floating IP
  5) Create a new port with fixed-ip (the same one as was used for floating-ip before); command for Neutron CLI would be like this: `neutron port-create --fixed-ip subnet_id=1c504dad-6d3c-48a8-ae46-b88df78bce3c,ip_address=10.248.236.16 e2ebbb95-8b02-4bca-a7ab-4dd8670f9de0` // sorry for still using neutron-cli - I hope this is not the problem, but it shouldn't be because we saw the same behaviour also when doing it with Horizon)
  6) Attach the interface to testing instance (instance uuid = 47d0055a-f94d-498b-9e7a-bc1b6ae1410a) like this: `nova interface-attach --port-id f6c81ee6-9c5e-4314-a514-29126b4fb35a 47d0055a-f94d-498b-9e7a-bc1b6ae1410a`

  After this I can see a duplicate in lease file for the external
  network (this is from Mitaka, so IP address is different then the one
  above):

  fa:16:3e:c6:e2:8d,host-10-4-131-96.openstacklocal,10.4.131.96
  fa:16:3e:67:7d:38,host-10-4-131-96.openstacklocal,10.4.131.96

  OR... there is nothing in lease file at all for the external network
  in case of our Queens OS - but it's probably OK, because it could be
  handled statically or by Calico - I'm really not sure about this,
  because the Queens OS version was deployed by external company.

  But an important think is that after this, on both OS clouds, the VM
  lose connectivity. At least on Mitaka, we are able to get it up when
  we restart all neutron-dhcp-agents (or at least the one residing on
  compute where the VM runs). Also I didn't see in logs that there was
  DHCPRELEASE message send to neutron-dhcp-agents, after floating IP
  release call. I guess that it's possible the DHCPRELEASE message isn't
  send at all and that's why we got duplicates in this case.

  This is probably a minor issue because the way of releasing floating-
  ip and reusing it on a new port as fixed-ip isn't quite standard, but
  still - Neutron let you do it, so it should work then.

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