Hi Brian, Ok, I'll file a bug there. Until today, it was not clear to happen only with Neutron.
To explain, "LAN change" is connect a specific DHCP client from "namespace A" to "namespace B". Each namespace with a different provider:segmentation_id (VLAN) and Subnet, and the same gateway network. It's like change a "phone" from "AccessPoint router A" to "AccessPoint router B" and in this case, the WAN link from both routers is the same net(gateway). DNSMASQ debug config that I'm using are, log-queries + log-dhcp + log-facility=/tmp/dnsmasq.log Thanks -- Luis Kleber Em qui, 6 de dez de 2018 às 17:47, Brian Haley <haleyb....@gmail.com> escreveu: > Luis, > > You should probably file a bug against neutron > (https://bugs.launchpad.net/neutron/) with the relevant info, along with > the neutron commands you're running and debug from the dhcp-agent and > /var/lib/neutron/dhcp/xxx/ files as necessary. I don't exactly > understand what you mean by "LAN changing", perhaps if I knew the > commands you're using it would be clearer. > > Thanks, > > -Brian (from the Neutron team) > > On 12/6/18 9:47 AM, Luis Kleber wrote: > > Last days I install 2 servers, one with Centos7 and other with Debian8, > > without Openstack/Neutron. Both with the same DNSMASQ config I > > originally posted. > > On both I was using version 2.76 and upgraded to 2.78, using the same > > ethernet interface changing the IP address between 100.97.97.1/24 > > <http://100.97.97.1/24> and 100.98.98.1/24 <http://100.98.98.1/24>, and > > everything works as expected. I also tested with 2 different interfaces > > ont each case and also worked fine. > > The DHCP client always was the same in all cases (Debian8, Centos7, and > > Centos7 with Neutron). > > > > It seems that the problem only happens when using DNSMAQ with Neutron > > routers. > > How debug it better within Neutron? Another cache table, or how see > > more detailed debug infos? > > > > Thanks > > -- > > Luis Kleber > > > > > > Em sex, 30 de nov de 2018 às 19:07, Luis Kleber <luis.kle...@gmail.com > > <mailto:luis.kle...@gmail.com>> escreveu: > > > > Hi Stappers! > > > > No hardfeelings! There was only a question missing! :) > > Thanks for your reply and yes, it's a complex setup because of the > > Neutron use (all installation needed). > > > > After explained the problem, I was expecting a help to "how better > > debug", how see some other logs, activate another debug, another > > configuration, and so on... > > I'll try if the same problem happens without Neutron. Only using a > > DNSMASQ with 2 different access interfaces/networks. > > > > Tanks. > > -- > > Luis Kleber > > > > > > Em sex, 30 de nov de 2018 às 16:33, Geert Stappers > > <stapp...@stappers.nl <mailto:stapp...@stappers.nl>> escreveu: > > > > On Wed, Nov 28, 2018 at 08:49:57AM -0200, Luis Kleber wrote: > > > Em ter, 27 de nov de 2018 às 20:12, Geert Stappers escreveu: > > > > On Mon, Nov 26, 2018 at 04:42:05PM -0200, Luis Kleber wrote: > > > > <snip/> > > > > > > dhcp-range=set:infra-70-subnet,100.101.1.11,100.101.1.64,600s > > > > > dhcp-option=tag:infra-70-subnet,3,100.101.1.1 > > > > > > dhcp-range=set:infra-71-subnet,100.101.2.11,100.101.2.64,600s > > > > > dhcp-option=tag:infra-71-subnet,3,100.101.2.1 > > > > > > dhcp-range=set:infra-72-subnet,100.98.98.11,100.98.98.64,600s > > > > > dhcp-option=tag:infra-72-subnet,3,100.98.98.1 > > > > <snip> infra-73 ... infra-92 </snip> > > > > > > dhcp-range=set:infra-93-subnet,100.103.8.11,100.103.8.64,600s > > > > > dhcp-option=tag:infra-93-subnet,3,100.103.8.1 > > > > > > dhcp-range=set:infra-94-subnet,100.104.1.11,100.104.1.64,600s > > > > > dhcp-option=tag:infra-94-subnet,3,100.104.1.1 > > > > > > dhcp-range=set:infra-95-subnet,100.96.96.11,100.96.96.64,600s > > > > > dhcp-option=tag:infra-95-subnet,3,100.96.96.1 > > > > > > > > Why? > > > > > > > > > > "Why" what? > > > If the question is the all other dhcp-ranges (unused for this > > scenario), > > > the answer is because in production case these other networks > > for each dhcp > > > range exist. These other unused ranges for this test case, > > this cannot be a > > > problem. > > > > > > Thanks > > > > No problem, no hardfeelings. > > > > It was me who should have wrote in his initial reply > > > > > > Oops, that is a complex setup. Is really all the complexity > > needed? > > > > > > Anyway: Feel free to post, do known that it is been readed. > > > > > > Groeten > > Geert Stappers > > -- > > > this cannot be a problem. > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss