Open Stack

The DHCP is just broadcast so it should go to all of the controllers and
the two it's scheduled to should respond. Are you not seeing the request
arriving at the other two controllers?

On Sat, Apr 30, 2016 at 12:42 PM, Jagga Soorma <jagga13 at gmail.com> wrote:

> So I have been digging more into this and looks like the dhcp request is
> going to the wrong controller.  It seems to be going to controller 3 when
> the dnsmasq processes seem to be on controller 1 & 2.  Am I missing
> something here?  If not, then why would this happen and how can I go about
> fixing it:
>
> --
> c1-m1-mgmt:~$ neutron net-list | grep -i exp
> | *1b67adc8-a049-4438-9533-2abe003aac0d* | exp-network
>     | e9565c6a-31b0-40e2-83dc-0958a7c0467f 192.168.1.0/24   |
>
>
>
> *** the below shows the dhcp agents running on controller 01 and 02 ***
> c1-m1-mgmt:~$ neutron dhcp-agent-list-hosting-net 1b67adc8-a049-4438-9533-
> 2abe003aac0d
> +--------------------------------------+--------------------
> ----+----------------+-------+
> | id                                   | host                   |
> admin_state_up | alive |
> +--------------------------------------+--------------------
> ----+----------------+-------+
> | 2bf750a1-5754-4f5a-b119-72248561787b | c1-m2-mgmt             | True
>         | :-)   |
> | 758d3766-1e00-4c13-9747-9846a41e2416 | c1-m1-mgmt             | True
>         | :-)   |
> +--------------------------------------+--------------------
> ----+----------------+-------+
>
>
> *** but the dhcp request for a instance connected to that
> bad network comes to controller 3 which never responds ***c1-m3-mgmt:~#
> tcpdump -n -i any | grep -i fa:16:3e:d8:00:20
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144
> bytes
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> fa:16:3e:d8:00:20, length 280
> ^C1073079 packets captured
> 1121416 packets received by filter
> 368 packets dropped by kernel
> --
>
> Any help with this would be appreciated.
>
> Thanks.
>
> On Thu, Apr 28, 2016 at 6:29 PM, Jagga Soorma <jagga13 at gmail.com> wrote:
>
>> I see the mac address of the instance asking for a dhcp address from the
>> compute node:
>>
>> --
>> # tcpdump -n -i any | grep -i fa:16:3e:b2:0f
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144
>> bytes
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> 01:23:34.588729 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> 01:23:34.588738 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> 01:23:34.588738 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> fa:16:3e:b2:0f:c0, length 300
>> 01:23:48.018979 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> 01:23:48.018989 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> 01:23:48.018989 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
>> from fa:16:3e:b2:0f:c0, length 300
>> ..snip..
>> --
>>
>>
>>
>> On Thu, Apr 28, 2016 at 5:55 PM, Jagga Soorma <jagga13 at gmail.com> wrote:
>>
>>> Hi Guys,
>>>
>>> I have a project with a priv network setup and any instance connected to
>>> it can't seem to get to its meta data service and no network gets setup on
>>> that instance.
>>>
>>> I created a new priv network in that project and was able to get
>>> communication on a new instance connected to that priv network with the
>>> same settings and using the same image and security group.
>>>
>>> Looks like there is something up with the network but I can't seem to
>>> find out what from the horizon ui.  They look and feel the same.  Any
>>> pointers on how I can further troubleshoot this problem?
>>>
>>> Thanks!
>>>
>>
>>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160502/fa2f0919/attachment.html>