Hi Zhi, Thanks very much for your help☺ Even turn off “ARP Spoofing” cannot work. But now, I find the cause for this: For ovs-agent-plugin, it wil loop to check OVS status and port status. But in my case, during the loop, it cannot detect there is new port added, so it fails to add tag for this port, and thus all package will be dropped. Therefore, the dhcp request cannot be reached by dhcp agent, and the VM cannot get ip all the time.
My current walk around is set an configuration item in compute node’s ml2_conf.ini [agent] minimize_polling = False Although it can work, but I’m still wondering why the new added port cannot be detected even “minimized_polling = True” It seems the ovsdb monitor cannot detect that. Do you have any suggestions for this part? BR//Huan From: zhi [mailto:changzhi1...@gmail.com] Sent: Monday, September 07, 2015 2:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Fail to get ipv4 address from dhcp hi, if you turn off the "ARP Spoofing" flag and restart the q-agt service. Does vm can get IP successfully? 2015-09-06 17:03 GMT+08:00 Huan Xie <huan....@citrix.com<mailto:huan....@citrix.com>>: Hi all, I’m trying to deploy OpenStack environment using DevStack with latest master code. I use Xenserver + neutron, with ML2 plugins and VLAN type. The problem I met is that the instances cannot really get IP address (I use DHCP), although we can see the VM with IP from horizon. I have tcpdump from VM side and DHCP server side, I can get DHCP request packet from VM side but cannot see any request packet from DHCP server side. But after I reboot the q-agt, the VM can get IP successfully. Checking the difference before and after q-agt restart, all my seen are the flow rules about ARP spoofing. This is the q-agt’s br-int port, it is dom0’s flow rules and the bold part are new added NXST_FLOW reply (xid=0x4): cookie=0x824d13a352a4e216, duration=163244.088s, table=0, n_packets=93, n_bytes=18140, idle_age=4998, hard_age=65534, priority=0 actions=NORMAL cookie=0x824d13a352a4e216, duration=163215.062s, table=0, n_packets=7, n_bytes=294, idle_age=33540, hard_age=65534, priority=10,arp,in_port=5 actions=resubmit(,24) cookie=0x824d13a352a4e216, duration=163230.050s, table=0, n_packets=25179, n_bytes=2839586, idle_age=5, hard_age=65534, priority=3,in_port=2,dl_vlan=1023 actions=mod_vlan_vid:1,NORMAL cookie=0x824d13a352a4e216, duration=163236.775s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,in_port=2 actions=drop cookie=0x824d13a352a4e216, duration=163243.516s, table=23, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop cookie=0x824d13a352a4e216, duration=163242.953s, table=24, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop cookie=0x824d13a352a4e216, duration=163215.636s, table=24, n_packets=7, n_bytes=294, idle_age=33540, hard_age=65534, priority=2,arp,in_port=5,arp_spa=10.0.0.6 actions=NORMAL I cannot see other changes after reboot q-agt, but it seems these rules are only for ARP spoofing, however, the instance can get IP from DHCP. I also google for this problem, but failed to deal this problem. Is anyone met this problem before or has any suggestion about how to debugging for this? Thanks a lot BR//Huan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev