Re: [neutron][queens] dhcp issue
Slawek, I got same errors in /var/log/messages: Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send DHCP/BOOTP option 121: no space left in packet Il giorno mer 11 dic 2019 alle ore 09:19 Slawek Kaplonski < skaplons@redhat.com> ha scritto:
Hi,
Can You maybe give us some more details? Like how exactly this network and subnets looks like (neutron net-show and neutron subnet-show), and please also check dnsmasq config files - those are located on node where DHCP agent is running. If You will do something like:
ps aux | grep <network_id>
You will find dnsmasq process for this network.
On 10 Dec 2019, at 16:52, Ignazio Cassano <ignaziocassano@gmail.com> wrote:
Hello Everyone, I have an openstack queens installation based on centos 7. I created a shared vlan network and multiple subnet under it. When I start an instance on one of the subnet network it gets the correct ip based on its subnet but the gateway seems random (one of the subnet of the vlan).
Any suggestion, please ?
Ignazio
— Slawek Kaplonski Senior software engineer Red Hat
On 2019-12-11 10:10:17 +0100 (+0100), Ignazio Cassano wrote: [...]
Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send DHCP/BOOTP option 121: no space left in packet [...]
This error is fairly straightforward. DHCP replies are limited to what you can fit in a single UDP packet and how large of a datagram the client agrees to accept. The number of routes you're trying to include in via option 121 could be the problem (is it a bunch?) but also the other fields and their lengths can also contribute, as can the MTU on that network segment: https://tools.ietf.org/html/rfc2131 According to IETF RFC 2131 you should be able to assume clients will accept a datagram of up to 576 octets in length (which implies your entire options field can use at least 312 octets). Anything over this requires negotiation of a maximum DHCP message size with the client. -- Jeremy Stanley
Hello Jeremy, thanks for your help. Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets. Is it correct? Ignazio Il Mer 11 Dic 2019, 16:29 Jeremy Stanley <fungi@yuggoth.org> ha scritto:
On 2019-12-11 10:10:17 +0100 (+0100), Ignazio Cassano wrote: [...]
Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send DHCP/BOOTP option 121: no space left in packet [...]
This error is fairly straightforward. DHCP replies are limited to what you can fit in a single UDP packet and how large of a datagram the client agrees to accept. The number of routes you're trying to include in via option 121 could be the problem (is it a bunch?) but also the other fields and their lengths can also contribute, as can the MTU on that network segment:
https://tools.ietf.org/html/rfc2131
According to IETF RFC 2131 you should be able to assume clients will accept a datagram of up to 576 octets in length (which implies your entire options field can use at least 312 octets). Anything over this requires negotiation of a maximum DHCP message size with the client. -- Jeremy Stanley
On 2019-12-11 18:36:16 +0100 (+0100), Ignazio Cassano wrote:
Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets. Is it correct? [...]
I'm afraid my expertise in this matter is limited to directly managing DHCP servers, I'm not personally familiar with running Neutron. Hopefully someone with more architectural background on Neutron itself can answer that part of your question. -- Jeremy Stanley
No problem Jeremy. Thanks for information you sent me. Ignazio Il Mer 11 Dic 2019, 19:43 Jeremy Stanley <fungi@yuggoth.org> ha scritto:
On 2019-12-11 18:36:16 +0100 (+0100), Ignazio Cassano wrote:
Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets. Is it correct? [...]
I'm afraid my expertise in this matter is limited to directly managing DHCP servers, I'm not personally familiar with running Neutron. Hopefully someone with more architectural background on Neutron itself can answer that part of your question. -- Jeremy Stanley
On 12/11/19 12:36 PM, Ignazio Cassano wrote:
Hello Jeremy, thanks for your help. Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets. Is it correct?
Yes, this behavior is correct, the dhcp-agent will add host routes for all subnets in a network. I looks like in your case you had a network with 12 subnets? I wonder whether it's worth checking either the number of subnets is below some threshold (10?) and just stop supplying the routes, or if there is some other way to determine the packet size. The only issue with limiting the packet size in the reply is the admin wouldn't know we did it, since adding the subnet is asynchronous from the dhcp-agent adding it's option logic, and things might fail in random ways, but I guess having a running dnsmasq is better than not. I guess at worst we should document that adding too many subnets, or extra dhcp options for that matter, could cause issues. -Brian
Il Mer 11 Dic 2019, 16:29 Jeremy Stanley <fungi@yuggoth.org <mailto:fungi@yuggoth.org>> ha scritto:
On 2019-12-11 10:10:17 +0100 (+0100), Ignazio Cassano wrote: [...] > Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send > DHCP/BOOTP option 121: no space left in packet [...]
This error is fairly straightforward. DHCP replies are limited to what you can fit in a single UDP packet and how large of a datagram the client agrees to accept. The number of routes you're trying to include in via option 121 could be the problem (is it a bunch?) but also the other fields and their lengths can also contribute, as can the MTU on that network segment:
https://tools.ietf.org/html/rfc2131
According to IETF RFC 2131 you should be able to assume clients will accept a datagram of up to 576 octets in length (which implies your entire options field can use at least 312 octets). Anything over this requires negotiation of a maximum DHCP message size with the client. -- Jeremy Stanley
participants (3)
-
Brian Haley
-
Ignazio Cassano
-
Jeremy Stanley