You should probably file a bug against 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.


-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 <> and <>, 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?

Luis  Kleber

Em sex, 30 de nov de 2018 às 19:07, Luis Kleber < <>> 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.

    Luis Kleber

    Em sex, 30 de nov de 2018 às 16:33, Geert Stappers
    < <>> 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,,,600s
         > > > dhcp-option=tag:infra-70-subnet,3,
         > > > dhcp-range=set:infra-71-subnet,,,600s
         > > > dhcp-option=tag:infra-71-subnet,3,
         > > > dhcp-range=set:infra-72-subnet,,,600s
         > > > dhcp-option=tag:infra-72-subnet,3,
         > >     <snip> infra-73 ... infra-92 </snip>
         > > > dhcp-range=set:infra-93-subnet,,,600s
         > > > dhcp-option=tag:infra-93-subnet,3,
         > > > dhcp-range=set:infra-94-subnet,,,600s
         > > > dhcp-option=tag:infra-94-subnet,3,
         > > > dhcp-range=set:infra-95-subnet,,,600s
         > > > dhcp-option=tag:infra-95-subnet,3,
         > >
         > > Why?
         > >
         > "Why" what?
         > If the question is the all other dhcp-ranges (unused for this
         > 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

        Anyway: Feel free to post, do known that it is been readed.

        Geert Stappers
-- > this cannot be a problem.

        Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Reply via email to