Resending the mail, as wrong dashboard logs were posted in the prev
question...
We are unable to get an IP address when a VM gets launched and the below
DHCP error is observed in the Dashboard logs
The setup in done on Fedora 18 using Openstack Grizzly. Its a 2 node setup,
with Network+ Controller node having 3 NIC's, and Compute node having 2
NIC's. Tried configuring networking in vlan mode.
em1 - mgmt network,
em2 - external/public network (br-ex is created on top of this iface)
eth1 - internal/data network (br-eth1 is created on top of this iface)
** *
plugin.ini
-
enable_tunneling = False
tenant_network_type = vlan
network_vlan_ranges = eth1:100:1000
integration_bridge = br-int
bridge_mappings = eth1:br-eth1,em2:br-ex
** *
Starting logging: OK
Initializing random number generator... done.
Starting acpid: OK
cirrosds 'local' up at 1.48
no results found for mode=local. up 1.53. searched: nocloud configdrive ec2
Starting network...
udhcpc (v1.20.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
WARN: /etc/rc3.d/S40network failed
cirrosds 'net' up at 181.79
checking http://169.254.169.254/20090404/instanceid
failed 1/20: up 181.83. request failed
failed 2/20: up 184.04. request failed
failed to read iid from metadata. tried 20
no results found for mode=net. up 222.36. searched: nocloud configdrive ec2
failed to get instanceid of datasource
Starting dropbear sshd: generating rsa key... generating dsa key... OK
=== network info ===
ifinfo: lo,up,127.0.0.1,8,::1
ifinfo: eth0,up,,8,fe80::f816:3eff:fede:dbc8
=== datasource: None None ===
=== cirros: current=0.3.1 uptime=222.60 ===
route: fscanf
=== pinging gateway failed, debugging connection ===
### route n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
route: fscanf
### cat /etc/resolv.conf
cat: can't open '/etc/resolv.conf': No such file or directory
### gateway not found
/sbin/cirrosstatus: line 1: can't open /etc/resolv.conf: no such file
### pinging nameservers
### uname a
Linux cirros 3.2.037virtual #58Ubuntu SMP Thu Jan 24 15:48:03 UTC 2013
x86_64 GNU/Linux
Could anyone help us in resolving this issue, we have tried following
different links and options available on internet, but couldnot resolve
this error. Let us know if further information is required to identify the
root cause.
Some more info, and if someone could possibly identify the root cause then
it would be of great help to me.
from the tcpdump output , I could track the DHCP discover packet at the
tapXXX , qbrXXX , qvbXXX, qvoXX, int-br-eth0, phy-br-eth0 interface, but
not after that
As per my understanding the flow of packets should be from tapXX - qbrXX
- qvbXX - qvoXX -- br-int - int-br-eth0 - phy-br-eth0 - br-eth0 -
eth0
So in this case is there a missing security group rules, which possibly
drop the packet.
I am not familiar with the iptables rules, so if I need to add any rules
could you please help me in adding the rule.
--
Regards
Gopi Krishna
On Wed, Jul 10, 2013 at 10:21 AM, Gopi Krishna B gopi97...@gmail.comwrote:
We are unable to get an IP address when a VM gets launched and the below
DHCP error is observed in the Dashboard logs
The setup in done on Fedora 18 using Openstack Grizzly. Its a 2 node
setup, with Network+ Controller node having 3 NIC's, and Compute node
having 2 NIC's. Tried configuring networking in vlan mode.
em1 - mgmt network,
em2 - external/public network (br-ex is created on top of this iface)
eth1 - internal/data network (br-eth1 is created on top of this iface)
** *
plugin.ini
-
enable_tunneling = False
tenant_network_type = vlan
network_vlan_ranges = eth1:100:1000
integration_bridge = br-int
bridge_mappings = eth1:br-eth1,em2:br-ex
** *
The console log from the dashboards is as below.
Initializing random number generator... done.
Starting network...
udhcpc (v1.18.5) started
Sending discover...
Sending select for 192.168.120.2...
Sending select for 192.168.120.2...
Sending select for 192.168.120.2...
No lease, failing
WARN: /etc/rc3.d/S40network failed
cirrosds 'net' up at 182.11
checking http://169.254.169.254/20090404/instanceid
failed 1/20: up 182.13. request failed
failed 2/20: up 184.34. request failed
failed 3/20: up 186.36. request failed
Could anyone help us in resolving this issue, we have tried following
different links and options available on internet, but couldnot resolve
this error. Let us know if further information is required to identify the
root cause.
Some more info, and if someone could possibly identify the root cause then
it would be of great help to me.
from the tcpdump output , I could track the DHCP discover packet at the
tapXXX , qbrXXX , qvbXXX, qvoXX, int-br-eth0, phy-br-eth0 interface,
