VM on controller node cannot get IP via DHCP

asked 2013-11-28 05:09:20 -0500

wenxin1234114 gravatar image

updated 2013-11-29 17:04:23 -0500

smaffulli gravatar image

I have one controller node and two compute node ,vms on compute nodes can get ip by dhcp ,but vms on controller failed . I tcpdump the dhcp server port ,it seems vms on controller node request normally but can not receive the ip ,the tcpdump log as followed :

[root@cloud01 ~]# ip netns exec qdhcp-58265ecd-0429-4cdc-84b7-ee4bd745a99a tcpdump -i tapa126c086-96 host 10.10.12.109

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tapa126c086-96, link-type EN10MB (Ethernet), capture size 65535 bytes
15:59:38.105489 IP 10.10.12.101.bootps > 10.10.12.109.bootpc: BOOTP/DHCP, Reply, length 327
15:59:38.107455 IP 10.10.12.101.bootps > 10.10.12.109.bootpc: BOOTP/DHCP, Reply, length 327
15:59:41.112144 IP 10.10.12.101.bootps > 10.10.12.109.bootpc: BOOTP/DHCP, Reply, length 327
15:59:44.116861 IP 10.10.12.101.bootps > 10.10.12.109.bootpc: BOOTP/DHCP, Reply, length 327
15:59:49.116265 ARP, Request who-has 10.10.12.109 tell 10.10.12.101, length 28
15:59:50.116076 ARP, Request who-has 10.10.12.109 tell 10.10.12.101, length 28
15:59:51.116276 ARP, Request who-has 10.10.12.109 tell 10.10.12.101, length 28

I thought the client (10.10.12.109) can not receive the the dhcp server (10.10.12.101) reply ,so I tried to add this rule to iptables:

-A neutron-openvswi-sbba680a9-2 -s 10.10.12.101/32 -j RETURN

it still dones't work .my iptables rules as following :

*filter
:INPUT ACCEPT [1745990:547416332]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1720163:541995461]
:neutron-filter-top - [0:0]
:neutron-openvswi-FORWARD - [0:0]
:neutron-openvswi-INPUT - [0:0]
:neutron-openvswi-OUTPUT - [0:0]
:neutron-openvswi-ibba680a9-2 - [0:0]
:neutron-openvswi-local - [0:0]
:neutron-openvswi-obba680a9-2 - [0:0]
:neutron-openvswi-sbba680a9-2 - [0:0]
:neutron-openvswi-sg-chain - [0:0]
:neutron-openvswi-sg-fallback - [0:0]
:nova-api-FORWARD - [0:0]
:nova-api-INPUT - [0:0]
:nova-api-OUTPUT - [0:0]
:nova-api-local - [0:0]
:nova-filter-top - [0:0]
-A INPUT -j neutron-openvswi-INPUT 
-A INPUT -j nova-api-INPUT 
-A FORWARD -j neutron-filter-top 
-A FORWARD -j neutron-openvswi-FORWARD 
-A FORWARD -j nova-filter-top 
-A FORWARD -j nova-api-FORWARD 
-A OUTPUT -j neutron-filter-top 
-A OUTPUT -j neutron-openvswi-OUTPUT 
-A OUTPUT -j nova-filter-top 
-A OUTPUT -j nova-api-OUTPUT 
-A neutron-filter-top -j neutron-openvswi-local 
-A neutron-openvswi-FORWARD -m physdev --physdev-out tapbba680a9-2e --physdev-is-br idged -j neutron-openvswi-sg-chain 
-A neutron-openvswi-FORWARD -m physdev --physdev-in tapbba680a9-2e --physdev-is-br idged -j neutron-openvswi-sg-chain 
-A neutron-openvswi-INPUT -m physdev --physdev-in tapbba680a9-2e --physdev-is-br idged -j neutron-openvswi-obba680a9-2 
-A neutron-openvswi-ibba680a9-2 -m state --state INVALID -j DROP 
-A neutron-openvswi-ibba680a9-2 -m state --state RELATED,ESTABLISHED -j RETURN 
-A neutron-openvswi-ibba680a9-2 -p tcp -m tcp --dport 22 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -p icmp -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.108/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.105/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.100/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.107/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.103/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.104/32 -j RETURN 
-A neutron-openvswi-ibba680a9-2 -s 10.10.12.106/32 ...
(more)
edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted
1

answered 2013-12-02 04:22:33 -0500

kashyapc gravatar image

I'm just guessing, maybe you can do more tcpdump analysis on your Controller node to see where it's blocked. I'm assuming you're using GRE:

# On Controller node
$ tcpdump -envi eth0 | grep -i gre
$ tcpdump -i eth0 -n arp or icmp

# On your integration bridge
$ tcpdump -envi br-int

# On br-tun 
$ tcpdump -envi br-tun

Also, tcpdump on physical link used by GRE tunnels (on Controller node). This might isolate the problem to the compute node or the network node.

$ tcpdump -i eth0 -n ip proto gre

If you're using GRE, ensure to have these rules on both Compute & Controller nodes:

$ iptables -I OUTPUT -p gre -j ACCEPT
$ iptables -I INPUT -p gre -j ACCEPT
edit flag offensive delete link more

Comments

I am using flatdhcp .I am gonna to do more test

wenxin1234114 gravatar imagewenxin1234114 ( 2013-12-05 03:41:17 -0500 )edit
0

answered 2013-12-25 03:15:56 -0500

wenxin1234114 gravatar image

I haven't solved this issuce .Recently I am facing the xenserver problem .MY boss want to try xenserver .

edit flag offensive delete link more
0

answered 2013-12-15 19:40:18 -0500

dongfeng gravatar image

Has this problem been solved? I am now facing exactly the same issue. Pls update if there is any clue to this isse

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-11-28 05:09:20 -0500

Seen: 1,248 times

Last updated: Dec 25 '13