[Openstack] havana dhcp issue
Paras pradhan
pradhanparas at gmail.com
Wed Nov 13 16:47:29 UTC 2013
I figured out this issue.
by default, interface_driver =
neutron.agent.linux.interface.OVSInterfaceDriver and dhcp_driver =
neutron.agent.linux.dhcp.Dnsmasq
in dhcp_agent.ini is commented.
Also, the line interface_driver =
neutron.agent.linux.interface.OVSInterfaceDriver in l3_agent.ini is
commented.
I uncommented them and I can now see qrouter and qdhcp with 'ip netns'
All looks well now.
Thanks
Paras.
On Mon, Nov 11, 2013 at 5:01 PM, Paras pradhan <pradhanparas at gmail.com>wrote:
> I am also seeing the respawsing in syslog.
>
> --
> Nov 11 17:00:12 havana kernel: [ 1019.203880] init: neutron-dhcp-agent
> main process (23258) terminated with status 1
> Nov 11 17:00:12 havana kernel: [ 1019.203962] init: neutron-dhcp-agent
> main process ended, respawning
> Nov 11 17:00:13 havana kernel: [ 1019.818240] init: neutron-dhcp-agent
> main process (23275) terminated with status 1
> Nov 11 17:00:13 havana kernel: [ 1019.818266] init: neutron-dhcp-agent
> main process ended, respawning
> --
>
> Paras.
>
>
> On Mon, Nov 11, 2013 at 12:06 PM, Paras pradhan <pradhanparas at gmail.com>wrote:
>
>> yes.
>>
>> ii openvswitch-datapath-dkms 1.10.2-0ubuntu2~cloud0
>> Open vSwitch datapath module source - DKMS version
>>
>>
>> Thanks
>> Paras.
>>
>>
>> On Mon, Nov 11, 2013 at 11:50 AM, Igor Cardoso <igordcard at gmail.com>wrote:
>>
>>> Flow gre-# is missing... Do you have openvswitch-datapath-dkms installed?
>>>
>>>
>>> On 11 November 2013 16:24, Paras pradhan <pradhanparas at gmail.com> wrote:
>>>
>>>> Yes br-tun is there. here is the o/p of ovs-ofctl.
>>>>
>>>> -
>>>> root at havana:~# ovs-ofctl show br-tun
>>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:00004e6501755448
>>>> n_tables:254, n_buffers:256
>>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>>>> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
>>>> SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>>> 1(patch-int): addr:42:9d:7c:13:4b:58
>>>> config: 0
>>>> state: 0
>>>> speed: 0 Mbps now, 0 Mbps max
>>>> LOCAL(br-tun): addr:4e:65:01:75:54:48
>>>> config: 0
>>>> state: 0
>>>> speed: 0 Mbps now, 0 Mbps max
>>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>>> --
>>>>
>>>> Thanks
>>>> Paras.
>>>>
>>>>
>>>> On Sat, Nov 9, 2013 at 3:44 AM, Igor Cardoso <igordcard at gmail.com>wrote:
>>>>
>>>>> I guess br-tun is created in a single node as well, someone correct me
>>>>> if I'm wrong please.
>>>>> What is the output of ovs-ofctl show br-tun ?
>>>>>
>>>>>
>>>>> On 9 November 2013 02:35, Paras pradhan <pradhanparas at gmail.com>wrote:
>>>>>
>>>>>> Yes gre . all (controller plus compute) in a single node though.
>>>>>> On Nov 8, 2013 5:17 PM, "Igor Cardoso" <igordcard at gmail.com> wrote:
>>>>>>
>>>>>>> Are you using GRE?
>>>>>>>
>>>>>>>
>>>>>>> On 8 November 2013 22:48, Paras pradhan <pradhanparas at gmail.com>wrote:
>>>>>>>
>>>>>>>> use_namespace is set to true, iproute is up to date from 12.04 LTS.
>>>>>>>>
>>>>>>>> This is what I see when tcpdump
>>>>>>>> -
>>>>>>>>
>>>>>>>> root at havana:/home/localadmin# tcpdump -i qvo6157a9aa-76
>>>>>>>> tcpdump: WARNING: qvo6157a9aa-76: no IPv4 address assigned
>>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>>> decode
>>>>>>>> listening on qvo6157a9aa-76, link-type EN10MB (Ethernet), capture
>>>>>>>> size 65535 bytes
>>>>>>>> 16:46:39.006180 IP6 fe80::40fa:38ff:fee3:a3fa > ff02::16: HBH
>>>>>>>> ICMP6, multicast listener report v2, 1 group record(s), length 28
>>>>>>>> 16:46:39.784902 IP6 :: > ff02::16: HBH ICMP6, multicast listener
>>>>>>>> report v2, 1 group record(s), length 28
>>>>>>>> 16:46:39.824273 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
>>>>>>>> BOOTP/DHCP, Request from fa:16:3e:9a:38:1e (oui Unknown), length 280
>>>>>>>> 16:46:39.933463 IP6 :: > ff02::1:ff9a:381e: ICMP6, neighbor
>>>>>>>> solicitation, who has fe80::f816:3eff:fe9a:381e, length 24
>>>>>>>> 16:46:40.325389 IP6 :: > ff02::16: HBH ICMP6, multicast listener
>>>>>>>> report v2, 1 group record(s), length 28
>>>>>>>> 16:46:40.934808 IP6 fe80::f816:3eff:fe9a:381e > ip6-allrouters:
>>>>>>>> ICMP6, router solicitation, length 16
>>>>>>>> 16:46:42.833239 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
>>>>>>>> BOOTP/DHCP, Request from fa:16:3e:9a:38:1e (oui Unknown), length 280
>>>>>>>> 16:46:44.936871 IP6 fe80::f816:3eff:fe9a:381e > ip6-allrouters:
>>>>>>>> ICMP6, router solicitation, length 16
>>>>>>>> 16:46:45.840668 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
>>>>>>>> BOOTP/DHCP, Request from fa:16:3e:9a:38:1e (oui Unknown), length 280
>>>>>>>> 16:46:48.945478 IP6 fe80::f816:3eff:fe9a:381e > ip6-allrouters:
>>>>>>>> ICMP6, router solicitation, length 16
>>>>>>>> 16:47:00.542029 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
>>>>>>>> 16:47:00.542036 IP6 fe80::d894:29ff:fe08:5ec > ip6-allnodes: HBH
>>>>>>>> ICMP6, multicast listener querymax resp delay: 10000 addr: ::, length 24
>>>>>>>> --
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Paras.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 8, 2013 at 4:26 PM, Rami Vaknin <rvaknin at redhat.com>wrote:
>>>>>>>>
>>>>>>>>> On 11/09/2013 12:18 AM, Paras pradhan wrote:
>>>>>>>>>
>>>>>>>>> dnsmaq is running, ip netns doesn't return anything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Empty output from "ip netns" can be either not using namespaces
>>>>>>>>> (run grep "use_namespaces /etc/neutron/l3_agent.ini" to find out) or using
>>>>>>>>> wrong iproute package.
>>>>>>>>> Could you please also check what does tcpdump report? could you
>>>>>>>>> see the discover on the dhcp nic (when using ovs it's a tapxxxxxxxx-xx
>>>>>>>>> nic)? could you see an offer sent from that nic?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Paras.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Nov 8, 2013 at 4:07 PM, Rami Vaknin <rvaknin at redhat.com>wrote:
>>>>>>>>>
>>>>>>>>>> On 11/08/2013 11:35 PM, Paras pradhan wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I gpt an instance UP but it doesnot get an IP address. neutron
>>>>>>>>>> agent-list lists DHCP agent happy. While booting I see cirros stuck at
>>>>>>>>>> sending discover... multiple times. dnsmasq process is running. how do i
>>>>>>>>>> debug?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would start with:
>>>>>>>>>> * ps -efl | grep dnsmasq | grep -v grep - to verify that the
>>>>>>>>>> dnsmasq process is running, you can also check the conf file appeas in this
>>>>>>>>>> output
>>>>>>>>>> * ip netns - to get the list of namespaces
>>>>>>>>>> * ip netns exec <the_right_dhcp_namespace_name> tcpdump -i any
>>>>>>>>>> ... - to look for the dhcp offer or arp issues
>>>>>>>>>> * ping each other - instance to dhcp address, and vice versa (the
>>>>>>>>>> second one should be done from within the namespace)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Rami Vaknin, QE @ Red Hat, TLV, IL.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Rami Vaknin, QE @ Red Hat, TLV, IL.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://igordcard.blogspot.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://igordcard.blogspot.com
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> http://igordcard.blogspot.com
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131113/0b86183e/attachment.html>
More information about the Openstack
mailing list