Ask Your Question
1

VM on controller node cannot get IP via DHCP

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

wenxin1234114 gravatar image

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

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
add a comment

3 answers

Sort by ยป oldest newest most voted
1

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

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 -0600 )edit
add a comment
0

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

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
add a comment
0

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

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
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

subscribe to rss feed

Stats

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

Seen: 1,200 times

Last updated: Dec 25 '13

Related questions

Flat Network Issue - Port Status showing down

juno neutron with gre tunnel, qrouter not pinging vm and vm not getting ip from dhcp

Port Forwarding through virtual router ip address

RDO, multi node, storage clarification questions

RDO Icehouse with ceph - libvirt error

compute node's linuxbridge agent is not listed in network agent list [closed]

Neutron Static IP

Multiple Provider VLAN network with one physical interface

Why Linux bridge Quantum plugin ?

swift user : how to give read only access to containers