<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Greg,<br>
<br>
I did have trouble with DHCP assignation (see my previous post in
this list), which was being fixed by deleting ovs bridges on
network node, recreating them and restarting OVS plugin and
L3/DHCP agents (which were all on the same physical node).<br>
Maybe it helps.<br>
<br>
Anyway, when DHCP'ing from your VM (asking for an IP), could you
please tcpdump : <br>
1. your virtual network interface on compute node<br>
2. your physical network interface on compute node<br>
3. your physical network interface on network node<br>
<br>
and see BOOTP/DHCP packets ?<br>
On the physical layer, you should see GRE packets (provided you
correctly followed the mentioned guide) encapsulating your
BOOTP/DHCP packets.<br>
<br>
If that's OK, could you please issue the below commands (on the
network node) :<br>
- brctl show<br>
- ip a<br>
- ovs-vsctl show<br>
- route -n<br>
<br>
Thanks,<br>
-Sylvain<br>
<br>
Le 19/02/2013 00:55, Greg Chavez a écrit :<br>
</div>
<blockquote
cite="mid:CAMTcKhas7Zxow0ycHGWAFsOdW0o5jO90C6MyEUS3cuSzqAp7wQ@mail.gmail.com"
type="cite">
<div dir="ltr">Third time I'm replying to my own message. It
seems like the initial network state is a problem for many first
time openstackers. Surely somewhere would be well to assist me.
I'm running out of time to make this work. Thanks.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Feb 17, 2013 at 3:08 AM, Greg
Chavez <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:greg.chavez@gmail.com" target="_blank">greg.chavez@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I'm replying to my own message because I'm
desperate. My network situation is a mess. I need to add
this as well: my bridge interfaces are all down. On my
compute node:
<div>
<br>
</div>
<div>
<div>root@kvm-cs-sn-10i:/var/lib/nova/instances/instance-00000005#
ip addr show | grep ^[0-9]</div>
<div>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc
noqueue state UNKNOWN </div>
<div>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP qlen 1000</div>
<div>3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP qlen 1000</div>
<div>4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc
noop state DOWN qlen 1000</div>
<div>5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc
noop state DOWN qlen 1000</div>
<div>9: br-int: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN </div>
<div>10: br-eth1: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN </div>
<div>13: phy-br-eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 1000</div>
<div>14: int-br-eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 1000</div>
<div>15: qbre56c5d9e-b6:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP </div>
<div>16: qvoe56c5d9e-b6:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast state UP qlen 1000</div>
<div>17: qvbe56c5d9e-b6:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master qbre56c5d9e-b6 state UP
qlen 1000</div>
<div>19: qbrb805a9c9-11:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP </div>
<div>20: qvob805a9c9-11:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast state UP qlen 1000</div>
<div>21: qvbb805a9c9-11:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master qbrb805a9c9-11 state UP
qlen 1000</div>
<div>34: qbr2b23c51f-02:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP </div>
<div>35: qvo2b23c51f-02:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast state UP qlen 1000</div>
<div>36: qvb2b23c51f-02:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master qbr2b23c51f-02 state UP
qlen 1000</div>
<div>37: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc pfifo_fast master qbr2b23c51f-02 state
UNKNOWN qlen 500</div>
</div>
<div><br>
</div>
<div>And on my network node:</div>
<div><br>
</div>
<div>
<div>root@knet-cs-gen-01i:~# ip addr show | grep ^[0-9]</div>
<div>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc
noqueue state UNKNOWN </div>
<div>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP qlen 1000</div>
<div>3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP qlen 1000</div>
<div>4: eth2:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu
1500 qdisc mq state UP qlen 1000</div>
<div>5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc
noop state DOWN qlen 1000</div>
<div>6: br-int: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN </div>
<div>7: br-eth1: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN </div>
<div>8: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc noqueue state UNKNOWN </div>
<div>22: phy-br-eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 1000</div>
<div>23: int-br-eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 1000</div>
<div><br>
</div>
<div>I gave br-ex an IP and UP'ed it manually. I assume
this is correct. By I honestly don't know.</div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Feb 15, 2013 at 6:54
PM, Greg Chavez <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:greg.chavez@gmail.com"
target="_blank">greg.chavez@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
Sigh. So I abandoned RHEL 6.3, rekicked my
systems and set up the scale-ready installation
described in these instructions:
<div>
<br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst"
target="_blank">https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst</a></div>
<div><br>
</div>
<div>Basically:</div>
<div><br>
</div>
<div>(o) controller node on a mgmt and public
net</div>
<div>(o) network node (quantum and openvs) on a
mgmt, net-config, and public net</div>
<div>
(o) compute node is on a mgmt and net-config
net</div>
<div><br>
</div>
<div>Took me just over an hour and ran into only
a few easily-fixed speed bumps. But the VM
networks are totally non-functioning. VMs
launch but no network traffic can go in or
out.</div>
<div><br>
</div>
<div>I'm particularly befuddled by these
problems:</div>
<div><br>
</div>
<div>( 1 ) This error in nova-compute:</div>
<div><br>
</div>
<div>ERROR nova.network.quantumv2 [-]
_get_auth_token() failed<br>
</div>
<div><br>
</div>
<div>( 2 ) No NAT rules on the compute node,
which probably explains why the VMs complain
about not finding a network or being able to
get metadata from 169.254.169.254.</div>
<div><br>
</div>
<div>
<div>root@kvm-cs-sn-10i:~# iptables -t nat -S</div>
<div>-P PREROUTING ACCEPT</div>
<div>-P INPUT ACCEPT</div>
<div>-P OUTPUT ACCEPT</div>
<div>-P POSTROUTING ACCEPT</div>
<div>-N nova-api-metadat-OUTPUT</div>
<div>-N nova-api-metadat-POSTROUTING</div>
<div>-N nova-api-metadat-PREROUTING</div>
<div>-N nova-api-metadat-float-snat</div>
<div>-N nova-api-metadat-snat</div>
<div>-N nova-compute-OUTPUT</div>
<div>-N nova-compute-POSTROUTING</div>
<div>-N nova-compute-PREROUTING</div>
<div>-N nova-compute-float-snat</div>
<div>-N nova-compute-snat</div>
<div>-N nova-postrouting-bottom</div>
<div>-A PREROUTING -j
nova-api-metadat-PREROUTING</div>
<div>-A PREROUTING -j nova-compute-PREROUTING</div>
<div>-A OUTPUT -j nova-api-metadat-OUTPUT</div>
<div>-A OUTPUT -j nova-compute-OUTPUT</div>
<div>-A POSTROUTING -j
nova-api-metadat-POSTROUTING</div>
<div>-A POSTROUTING -j
nova-compute-POSTROUTING</div>
<div>-A POSTROUTING -j nova-postrouting-bottom</div>
<div>-A nova-api-metadat-snat -j
nova-api-metadat-float-snat</div>
<div>-A nova-compute-snat -j
nova-compute-float-snat</div>
<div>-A nova-postrouting-bottom -j
nova-api-metadat-snat</div>
<div>-A nova-postrouting-bottom -j
nova-compute-snat</div>
</div>
<div><br>
</div>
<div>(3) A lastly, no default secgroup rules,
whose function governs... what exactly?
Connections to the VM's public or private
IPs? I guess I'm just not sure if this is
relevant to my overall problem of ZERO VM
network connectivity.</div>
<div><br>
</div>
<div>I seek guidance please. Thanks.</div>
<span><font color="#888888">
<div><br clear="all">
<div><br>
</div>
-- <br>
\*..+.-<br>
--Greg Chavez<br>
+//..;};
</div>
</font></span></div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
\*..+.-<br>
--Greg Chavez<br>
+//..;};
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
\*..+.-<br>
--Greg Chavez<br>
+//..;};
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
</body>
</html>