Cached network object in DHCP agent not updated with router interface changes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
High
|
Shih-Hao Li |
Bug Description
In Dnsmasq, the function get_isolated_
The implementation of this function checks all the router interface ports in a cached network object passed from DHCP agent. But the cached network object is not updated when a subnet is attached to or detached from a router.
This could cause problem when a new VM is booted on a subnet just attached to a router. The VM will get the metadata route to the DHCP port instead of to the route port from Dnsmasq.
Based on current DHCP agent implementation, if DHCP agent is restarted, it will try to restart all metadata proxies. But it will skip the metadata proxy for the networks with any subnet attached to a router. Instead, DHCP agent will start a metadata-proxy for the router. If old metadata proxy processes for the networks are still running, then the metadata route to the DHCP port should still work. But consider the case when a openstack network node is restarted, then all old processes are gone. Thus DHCP agent will not start those metadata proxies for networks with attached router. This means any VM that has routing table containing a metadata route to the DHCP port will fail to reach metadata service because the corresponding metadata proxy that handle 169.254.169.254:80 is not running.
description: | updated |
summary: |
- get_isolated_subnets does not return latest results + Cached network object in DHCP agent in not updated with router interface + changes |
summary: |
- Cached network object in DHCP agent in not updated with router interface + Cached network object in DHCP agent not updated with router interface changes |
Fix proposed to branch: master /review. openstack. org/290216
Review: https:/