[Dnsmasq-discuss] DNSMASQ wrong addresses allocated after changing DHCP Clients between Neutron vRouters
Luis Kleber
luis.kleber at gmail.com
Thu Dec 6 22:00:24 GMT 2018
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.dev at 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.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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20181206/aac74d32/attachment-0001.html>
More information about the Dnsmasq-discuss
mailing list