[Dnsmasq-discuss] DNSMASQ wrong addresses allocated after changing DHCP Clients between Neutron vRouters

Brian Haley haleyb.dev at gmail.com
Thu Dec 6 19:47:12 GMT 2018


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.kleber at gmail.com 
> <mailto:luis.kleber at 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
>     <stappers at stappers.nl <mailto:stappers at 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 at lists.thekelleys.org.uk
>         <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>         http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



More information about the Dnsmasq-discuss mailing list