yahoo-eng-team team mailing list archive

[Eugene Nikanorov <enikanorov@xxxxxxxxxxxx>]

Public bug reported:

WIth private network plugged into a router and router serving metadata:

When windows accesses metadata url, it tries to resolve mac address of it despite of routing table that tells to go to default gateway. That is because of nature of 169.254 which is considered local by default.
Such behavior causes big delay before connection could be established.
This, in turn, causes lots of issues during cloud init phase: slowness, timeouts, etc.

The workaround could be to add explicit route to a subnet, e.g.
169.254.169.254/32 via subnet's default gateway.

It makes sense to let DHCP agent inject such route by default via
dnsmasq config.

** Affects: neutron
     Importance: Medium
     Assignee: Eugene Nikanorov (enikanorov)
         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/1460793

Title:
  Metadata IP is resolved locally by Windows by default, causing big
  delay in URL access

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  WIth private network plugged into a router and router serving
  metadata:

  When windows accesses metadata url, it tries to resolve mac address of it despite of routing table that tells to go to default gateway. That is because of nature of 169.254 which is considered local by default.
  Such behavior causes big delay before connection could be established.
  This, in turn, causes lots of issues during cloud init phase: slowness, timeouts, etc.

  The workaround could be to add explicit route to a subnet, e.g.
  169.254.169.254/32 via subnet's default gateway.

  It makes sense to let DHCP agent inject such route by default via
  dnsmasq config.

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