yahoo-eng-team team mailing list archive

[Boris Lukashev <1944083@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We run designate out of a private VLAN which is accessible via one of the two external networks in our wallaby cloud. In order to permit instances name resolution via those endpoints, we add a route to the subnet in that private VLAN via the 2nd router added to each network, the external network of which is our OutsidePrivate net (the External network which resides inside the DC, vs our OutsidePublic which is a VLAN to the actual WAN).
Unfortunately, despite setting up this 2nd router and explicit route, we see nova instances coming up with an explicit /32 route to each DNS server specified _via the .1 gateway_ in the network which is the router to OutsidePrivate, and despite an explicit route to the /24 (i know CIDR works in smallest subnet preference) which should be understood to encapsulate the 3 IPs of the NS' themselves and prevent the /32 routes from being created.
Even setting explicit /32 routes to each NS via the 2nd gateway @ .2 doesn't work - the original /32's via the .1 are still present, and the only fix we've found is to force nodes to static addressing and routing via cloud-init. ICMP redirect from the primary gateway to the secondary is hit-or-miss, and not how this should work anyway.
I've not found anything in the docs about how these default routes via the primary gateway are set up, and have therefore found no way to disable them so filing this a bug since it's a major impediment to anyone resolving names via any gateway but the one set as the default gateway for the network.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1944083

Title:
  Nova assumptions about /32 routes to NS' break name resolution under
  DHCP

Status in OpenStack Compute (nova):
  New

Bug description:
  We run designate out of a private VLAN which is accessible via one of the two external networks in our wallaby cloud. In order to permit instances name resolution via those endpoints, we add a route to the subnet in that private VLAN via the 2nd router added to each network, the external network of which is our OutsidePrivate net (the External network which resides inside the DC, vs our OutsidePublic which is a VLAN to the actual WAN).
  Unfortunately, despite setting up this 2nd router and explicit route, we see nova instances coming up with an explicit /32 route to each DNS server specified _via the .1 gateway_ in the network which is the router to OutsidePrivate, and despite an explicit route to the /24 (i know CIDR works in smallest subnet preference) which should be understood to encapsulate the 3 IPs of the NS' themselves and prevent the /32 routes from being created.
  Even setting explicit /32 routes to each NS via the 2nd gateway @ .2 doesn't work - the original /32's via the .1 are still present, and the only fix we've found is to force nodes to static addressing and routing via cloud-init. ICMP redirect from the primary gateway to the secondary is hit-or-miss, and not how this should work anyway.
  I've not found anything in the docs about how these default routes via the primary gateway are set up, and have therefore found no way to disable them so filing this a bug since it's a major impediment to anyone resolving names via any gateway but the one set as the default gateway for the network.

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