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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
