So...is this the root of my problem? The MAC addresses in my quantum
port-list do not match my real MAC addresses. Any time I restart
openvswitch/quantum-plugin-openvswitch-agent, my br-tun blocks my traffic
with incorrect flows.
What went wrong here...should these interfaces actually have
Perhaps somebody could give me the contents of their quantum node's ovs-ofctl
dump-flows br-tun and I could figure out what mine *should* look like?
On Tue, Mar 12, 2013 at 4:24 PM, The King in Yellow yellowk...@gmail.comwrote:
Okay, I have worked around my problem-- but I don't quite
A little more information, or a completely different problem...I just
realized my network node can't ping its public gateway. (Instead of
7.7.7.0/24, I am using 10.42.36.0/23. My gateway is .1 (and has
non-redundant IP of .10), and my Network Node IP is .130). This did work
at one time.
Your route is correct, 10.5.5.0/24 is resolved thru qr- by default.
I haven't had time to look at tcpdumps carefully, but it seems your
network node is receiving the ARP query and replying.
I would suggest to monitor all interfaces on both compute node and
network node using the tcpdump '-i
Le 05/03/2013 18:14, The King in Yellow a écrit :
I'm not clear on what the interfaces are, but q-9f9041ce-65 is
10.5.5.1 on the network node, so he seems to be seeing the traffic.
tap45ffdc5f-da is listed as 10.5.5.2, and I have no idea what function
that is performing.
qr-X is the
On Wed, Mar 6, 2013 at 10:15 AM, Sylvain Bauza
sylvain.ba...@digimind.comwrote:
Le 05/03/2013 18:14, The King in Yellow a écrit :
I'm not clear on what the interfaces are, but q-9f9041ce-65 is 10.5.5.1
on the network node, so he seems to be seeing the traffic. tap45ffdc5f-da
is listed as
I read the bug description
(https://bugs.launchpad.net/quantum/+bug/1091605) and
the fix (https://review.openstack.org/#/c/18302/). But I don't understand
who is the responsible to call the script on the startup.
Should I put it on something like rc.local? Or is quantum plugins'
responsibility to
This is up to your responsability to hit the script, afaik.
I haven't deployed the bugfix, I preferred creating my own script called
by rc.local by convenience (and also because I found the issue and
mitigated it before talking to the forum)
Once I'll migrate to 2012.2.3, I'll use this .py
Ok
I'm using the script (I'm calling it from rc.local) and everything works
fine, even for instances that already exist.
Thanks
2013/3/5 Sylvain Bauza sylvain.ba...@digimind.com
This is up to your responsability to hit the script, afaik.
I haven't deployed the bugfix, I preferred creating
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 :
Le 05/03/2013 13:57, Filipe Manco a écrit :
Ok
I'm using the script (I'm calling it from rc.local) and everything
works fine, even for instances that already exist.
Thanks
The bug is related to the tap device, ie. DHCP agent reboot.
The second bug I mentioned is related to a compute node
That didn't quite do it. Rebooted 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
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
I forgot to mention, could you please also check that
quantum-openvswitch-agent is started ('ps -ef' ) ?
Le 05/03/2013 17:19, Sylvain Bauza a écrit :
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
On Tue, Mar 5, 2013 at 11:19 AM, Sylvain Bauza
sylvain.ba...@digimind.comwrote:
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
Is the network node also acting as a Compute node ?
The issue you were mentioning was related to the tap virtual device (for
DHCP leases) : if the network node goes down, then the DHCP lease is
expiring on the vm without being reack, and then your instance is
loosing its IP address.
By
On Mon, Mar 4, 2013 at 3:18 AM, Sylvain Bauza sylvain.ba...@digimind.comwrote:
Is the network node also acting as a Compute node ?
No, I am running three separate nodes-- network, compute and controller.
The issue you were mentioning was related to the tap virtual device (for
DHCP leases)
In my case, it actually appears that my vms aren't up-- the instances panel
says they are up, but looking at the console, it appears they aren't
getting an IP address. This is a new instance:
Begin: Running /scripts/init-bottom ... done.
[2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
There is a known bug for the network bridges, when rebooting :
https://bugs.launchpad.net/quantum/+bug/1091605
Try to delete/recreate your br-int/br-ex and then restart
openvswitch_plugin/l3/dhcp agents, it should fix the issue.
-Sylvain
Le 01/03/2013 15:04, The King in Yellow a écrit :
In
On Mar 1, 2013, at 9:11 AM, Sylvain Bauza sylvain.ba...@digimind.com wrote:
There is a known bug for the network bridges, when rebooting :
https://bugs.launchpad.net/quantum/+bug/1091605
Hmm. Reading that page, it's not clear to me exactly where this bug is
actually fixed. From what I can
It says its fixed in quantum
2012.2.3https://launchpad.net/quantum/+milestone/2012.2.3as well.
How do we get 2012.3 in Ubuntu 12.04?
Regrads,
Balu
On Fri, Mar 1, 2013 at 8:51 PM, Brad Knowles bknow...@momentumsi.comwrote:
On Mar 1, 2013, at 9:11 AM, Sylvain Bauza sylvain.ba...@digimind.com
As said, you can also commit the changes (thanks to Gerrit) on your own
installation without waiting for 2012.2.3 ported to Ubuntu LTS.
Or, you can script by your own the fix. Anyway, you got the reason, it's
up to you on how you'll populate the changes.
-Sylvain
Le 01/03/2013 16:25,
Hi
response inline
On Wed, Feb 27, 2013 at 3:22 PM, The King in Yellow
yellowk...@gmail.com wrote:
I have been working on creating an OpenStack environment according to the
Basic Install doc. It was working fine last night! In order to make sure I
didn't mess anything up, I downed
Hi Aaron and The King in Yellow,
I also experienced this problem yesterday and I just solved.
Besides ensuring quantum-openvswitch-agent processes are all up
(except the controller node),
there is a typo in the network node in basic install doc:
On Wed, Feb 27, 2013 at 7:11 PM, Chuan-Heng Hsiao
hsiao.chuanh...@gmail.com wrote:
Hi Aaron and The King in Yellow,
I also experienced this problem yesterday and I just solved.
Besides ensuring quantum-openvswitch-agent processes are all up
(except the controller node),
there is a typo in
Hi Aaron,
I am very sorry that I made the conclusion too early because of not
having good understanding
of everything, and it is with high probability that I may made wrong conclusion.
However, based on my hypothesis (and my few experiments.)
The gateway setting is supposed to be corresponded to
Hi Hsiao,
You are absolutely correct! If 192.168.0.254 is set as the gateway
traffic will not be routed correctly. I also believe there is another
bug as the ip addresses are being placed on the ethX interfaces and
not bridge interfaces. I'll create a patch fixing these issues
tomorrow morning.
27 matches
Mail list logo
