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-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
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

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,168 times

Last updated: Dec 25 '13

Related questions

missing public network

[RDO - packstack] Openvswitch agent crash [closed]

neutron: Error, "AgentNotFoundByTypeHost: Agent with agent_type=L3 agent and host=compute1.example.com could not be found", caused by 'l2population'

Havana Neutron Networking - can't escape namespace

Small Horizon dashboard modifications

Slow iperf performance between vms

what is the difference between GRE and VXLAN networks [closed]

Pike install linuxbridge-agent.service failed on Compute

Allowed address Pairs

RDO How to configure neutron network with Flat?