Hi.
https://bugs.launchpad.net/neutron/+bug/1807382
--
Luis Kleber
>
>
> What became the URL of that bug report?
>
>
> Groeten
> Geert Stappers
> --
> Leven en laten leven
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
On Thu, Dec 06, 2018 at 08:00:24PM -0200, Luis Kleber wrote:
> Em qui, 6 de dez de 2018 às 17:47, Brian Haley escreveu:
> > 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 DNSMAS
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.
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
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 and
100.9
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
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:
> >
> > > dhcp-range=set:infra-70-subnet,100.101.1.11,100.101.1.64,600s
> > > dhcp-option=tag:infra-70-su
Hi Stappers.
"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
Em ter, 27 de nov de 2018 às 2
On Mon, Nov 26, 2018 at 04:42:05PM -0200, Luis Kleber wrote:
> 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-ra
Hi,
I'm using OpenStack, basically creating Virtual Routers with subnets, and
DNSMASQ is the DHCP Server for them (via neutron-dhcp driver).
My test scenario contains 2 vRouters (2 namespaces as router) with 1 DHCP
each (2 namespaces as dhcp servers) on the Neutron Network Server. The
Subnet are 1
10 matches
Mail list logo
