Ask Your Question

Revision history [back]

I am having the same issue. In my case, when the problem occurs, I am seeing the DHCPDISCOVER coming from the compute to the network (controller) node, and a DHCPOFFER returned, but it doesn't make it back to the compute node.

When it does work, I see the DHCPREQUEST back to the network node, and subsequent DHCPACK. (enable dnsmasq logging to see this outside of the syslog).

However, there does not seem to be any consistency. Sometimes it works, sometimes not. I don't like the idea of deleting and recreating the networks but I'll try that next.

I am having the same issue. In my case, when the problem occurs, I am seeing the DHCPDISCOVER coming from the compute to the network (controller) node, and a DHCPOFFER returned, but it doesn't make it back to the compute node.

When it does work, I see the DHCPREQUEST back to the network node, and subsequent DHCPACK. (enable dnsmasq logging to see this outside of the syslog).

However, there does not seem to be any consistency. Sometimes it works, sometimes not. I don't like tried on a new subnet..same thing. Yet, on an older subnet, it works. My controller and compute are on a trunked interface, allowing all vlans specified in the idea of deleting and recreating /etc/neutron/plugins/ml2/ml2_conf.ini network_vlan_ranges = physnet2:30:33 I also have dhcp snooping enabled, but have trusted the networks but I'll try that next.interface for the controller node, so dhcp responses are should be allowed. However, for some reason, the DHCPOFFER doesn't make it back to the compute node when the problem occurs.

I am having the same issue. In my case, when the problem occurs, I am seeing the DHCPDISCOVER coming from the compute to the network (controller) node, and a DHCPOFFER returned, but it doesn't make it back to the compute node.

When it does work, I see the DHCPREQUEST back to the network node, and subsequent DHCPACK. (enable dnsmasq logging to see this outside of the syslog).

However, there does not seem to be any consistency. Sometimes it works, sometimes not. I tried on a new subnet..same thing. Yet, on an older subnet, it works. My controller and compute are on a trunked interface, allowing all vlans specified in the /etc/neutron/plugins/ml2/ml2_conf.ini network_vlan_ranges = physnet2:30:33 I also have dhcp snooping enabled, but have trusted the interface for the controller node, so dhcp responses are should be allowed. However, for some reason, the DHCPOFFER doesn't make it back to the compute node when the problem occurs.

I am having the same issue. In my case, when the problem occurs, I am seeing the DHCPDISCOVER coming from the compute to the network (controller) node, and a DHCPOFFER returned, but it doesn't make it back to the compute node.

When it does work, I see the DHCPREQUEST back to the network node, and subsequent DHCPACK. (enable dnsmasq logging to see this outside of the syslog).

However, there does not seem to be any consistency. Sometimes it works, sometimes not. I tried on a new subnet..same thing. Yet, on an older subnet, it works. My controller and compute are on a trunked interface, allowing all vlans specified in the /etc/neutron/plugins/ml2/ml2_conf.ini

network_vlan_ranges = physnet2:30:33 physnet2:30:33

I also have dhcp snooping enabled, but have trusted the interface for the controller node, so dhcp responses are allowed. However, for some reason, the DHCPOFFER doesn't make it back to the compute node when the problem occurs.