<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr"><div>From my perspective, it seems that the OVS bridges are not being brought up correctly. As you can see in my earlier post, the integration bridge (int) and the physical interface bridges (br-ex and br-eth1) are downed. I've tried to bring them up in promiscuous mode in the case of br-int, and with the physical interfaces ported to the bridge in the case of br-ex and br-eth1. I've had no luck unfortunately.</div>
<div><br></div><div>It seems that nothing is getting past br-int. I can see BOOTP packets on the VM side of br-int, and I can see VTP packets on the physical side of br-int. But that's where it ends.</div>
<div><br></div><div>For example, when I reboot my VM, I see this:</div><div><br></div><div><div>root@kvm-cs-sn-10i:/var/lib/nova/instances# tcpdump -i qvo5334a0cb-64</div><div><br></div><div>tcpdump: WARNING: qvo5334a0cb-64: no IPv4 address assigned</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</div><div>listening on qvo5334a0cb-64, link-type EN10MB (Ethernet), capture size 65535 bytes</div><div><br></div><div>13:42:08.099061 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:06:48:09 (oui Unknown), length 280</div>
<div>13:42:08.101675 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28</div><div>13:42:08.161728 IP6 :: > ff02::1:ff06:4809: ICMP6, neighbor solicitation, who has fe80::f816:3eff:fe06:4809, length 24</div>
<div>13:42:08.373745 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28</div><div>13:42:11.102528 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:06:48:09 (oui Unknown), length 280</div>
<div>13:42:14.105850 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:06:48:09 (oui Unknown), length 280</div><div><br></div><div>But that's as far as it goes. The dhcp agent never get this.</div>
<div><br></div><div>I"ve tried deleting and recreating the bridges, rebooting the systems, but nothing seems to work. Maybe it's just the right combination of things. I don't know. </div><div>
<br></div><div>Help!</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 5:23 AM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@digimind.com" target="_blank">sylvain.bauza@digimind.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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 type="cite"><div><div>
<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 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>
<div>
<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 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 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></fieldset>
<br>
</div></div><div><pre>_______________________________________________
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a>
</pre>
</div></blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>\*..+.-<br>--Greg Chavez<br>+//..;};
</div>
</div></div></div><br><br clear="all"><div><br></div>-- <br>\*..+.-<br>--Greg Chavez<br>+//..;};
</div>