You should be close to the solution. Looking at your GRE tunnels, I only
see a one-to-one tunnel in between your compute node and your network
node (provided your netnode is 10.10.10.1). Could you please confirm
that your controller is either on the compute node or on the network node ?
One could suggest to restart nova-compute and check.
Also, could you please tcpdump your network node on your management IP
and check if you see GRE packets coming from your compute node (while
pinging or trying to get a lease) ?
-Sylvain
Le 05/03/2013 15:56, The King in Yellow a écrit :
That didn't quite do it. Rebooted 10.5.5.5/6 <http://10.5.5.5/6> and
they did not get IPs. Brought one up manually and could not ping
anything else. I note that I'm missing the "tag" statement on those
recreated interfaces in "ovs-vsctl show", so I deleted the interfaces
and reran the statements you gave with "tag=1" appended. Now, my
manually configured 10.5.5.5 COULD ping my working 10.5.5.7, and I
could ssh between the two. However, 10.5.5.5 still can not get a DHCP
address or (with hardcoded IP) reach 10.5.5.1 on the network node,
whereas 10.5.5.7 can. Here's how things look now:
root@os-compute-01:~# ovs-dpctl show br-int
system@br-int:
lookups: hit:236399 missed:45742 lost:0
flows: 1
port 0: br-int (internal)
port 2: qvo7dcd14b3-70
port 9: qvo0b459c65-a0
port 10: qvo4f36c3ea-5c
port 11: qvo62721ee8-08
port 12: qvocf833d2a-9e
port 13: patch-tun (patch: peer=patch-int)
root@os-compute-01:~# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvo0b459c65-a0"
tag: 1
Interface "qvo0b459c65-a0"
Port "qvo62721ee8-08"
tag: 1
Interface "qvo62721ee8-08"
Port "qvo4f36c3ea-5c"
tag: 1
Interface "qvo4f36c3ea-5c"
Port "qvocf833d2a-9e"
tag: 1
Interface "qvocf833d2a-9e"
Port "qvo7dcd14b3-70"
tag: 1
Interface "qvo7dcd14b3-70"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow,
remote_ip="10.10.10.1"}
ovs_version: "1.4.0+build0"
root@os-compute-01:~# brctl show
bridge name bridge id STP enabled interfaces
br-int 0000.222603554b47 no qvo0b459c65-a0
qvo4f36c3ea-5c
qvo62721ee8-08
qvo7dcd14b3-70
qvocf833d2a-9e
br-tun 0000.3abeb87cdb47 no
qbr0b459c65-a0 8000.3af05347af11 no qvb0b459c65-a0
vnet2
qbr4f36c3ea-5c 8000.e6a5faf9a181 no qvb4f36c3ea-5c
vnet1
qbr62721ee8-08 8000.8af675d45ed7 no qvb62721ee8-08
vnet0
qbr7dcd14b3-70 8000.aabc605c1b2c no qvb7dcd14b3-70
vnet4
qbrcf833d2a-9e 8000.36e77dfc6018 no qvbcf833d2a-9e
vnet3
root@os-compute-01:~#
On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza
<[email protected] <mailto:[email protected]>> wrote:
You get it. This is the bug I mentioned related to compute nodes.
Folks, anyone knowing the bug tracking numbre, btw ?
'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to
br-int (and mapped to vnet4, which I guess is the vnet device for
the correct VM).
Could you please try :
sudo ovs-vsctl add-port br-int qvo0b459c65-a0
sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
sudo ovs-vsctl add-port br-int qvo62721ee8-08
sudo ovs-vsctl add-port br-int qvocf833d2a-9e
sudo service quantum-plugin-openvswitch-agent restart
and check that your VMs get network back ?
-Sylvain
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
