On 20.09.2011 06:59, Ben Pfaff wrote:
On Tue, Sep 20, 2011 at 06:54:23AM +0200, S?bastien Riccio wrote:
I tried too, to get openvswitch datapath module compile with 3.1-rc6
kernel, but with no luck. Seems skipping the hh calls in tunnel.c
won't do it, it then complains about something else :/
-
Hi,
I tried too, to get openvswitch datapath module compile with 3.1-rc6
kernel, but with no luck. Seems skipping the hh calls in tunnel.c won't
do it, it then complains about something else :/
-> Back to 3.0 :)
CC [M] /usr/src/openvswitch/datapath/linux/vport-internal_dev.o
/usr/src/ope
On 15.09.2011 23:12, Jesse Gross wrote:
This type of rate limit won't help anyways because the CPU time will
have already been spent by the time the packet is dropped.
Yes, I thought that could be the case. But I've told myself let's try
and see, who knows it might help.
Sébastien
__
On 15.09.2011 22:47, Ben Pfaff wrote:
On Thu, Sep 15, 2011 at 10:36:43PM +0200, S?bastien Riccio wrote:
I'm still working on a topic I've already discussed before: I just
dont want a VM to be able for example
to be able to udp flood at a maximum rate and bring the whole thing
down and unrespons
On 15.09.2011 22:25, Ben Pfaff wrote:
On Thu, Sep 15, 2011 at 10:19:38PM +0200, S?bastien Riccio wrote:
I'm trying to figure out how to limit the output packets rate on a
vswitch port, but I'm a bit lost.
Is it even possible ? I know it is possible to limite the data rate,
but is it possible wit
Hi,
I'm trying to figure out how to limit the output packets rate on a
vswitch port, but I'm a bit lost.
Is it even possible ? I know it is possible to limite the data rate, but
is it possible with packets ?
Thanks for your help.
Cheers,
Sébastien
___
On 09.09.2011 20:09, Ben Pfaff wrote:
On Fri, Sep 09, 2011 at 08:05:00PM +0200, S?bastien Riccio wrote:
Okay thanks it's clear. I'm trying to find a way to be nearly sure
that on a xen host if a customer vm gets hacked and starts flooding
the network like hell, it doesn't render the whole host u
On 09.09.2011 19:54, Ben Pfaff wrote:
On Fri, Sep 09, 2011 at 07:47:52PM +0200, S?bastien Riccio wrote:
That's expected behavior. When new flows constantly pop up, it takes
CPU time to decide what to do with them, and eventually you run out of
CPU time. This will be true of any kind of smart s
On 09.09.2011 19:34, Ben Pfaff wrote:
On Wed, Sep 07, 2011 at 08:53:14PM +0200, S?bastien Riccio wrote:
For the details about the versions:
root@xen-blade13:~# ovs-vswitchd --version
ovs-vswitchd (Open vSwitch) 1.2.1+build0
Compiled Sep 6 2011 01:01:15
OpenFlow versions 0x1:0x1
It's the one f
Hi,
I just did a test to see how openvswitch handle a flood from a virtual
machine on a xen
host using it as the networking layer.
I just issued a :
vm1# hping3 -S -L 0 -p 80 -i u100 192.168.1.1
options I used are:
-S set SYN tcp flag
-L set ACK tcp flag
-p destination port
-i u100 = interv
On 09.07.2011 20:51, Ben Pfaff wrote:
On Sat, Jul 09, 2011 at 08:44:34PM +0200, Sébastien Riccio wrote:
Actually i'm interested to this question too. I'm trying to modify
xen network scripts in
order to have it bind the vif to the right bridge and with the right
vlan tag (if using a
b
On 09.07.2011 20:44, Sébastien Riccio wrote:
Actually i'm interested to this question too. I'm trying to modify xen
network scripts in
order to have it bind the vif to the right bridge and with the right
vlan tag (if using a
bridge with trunk ports).
I found that slackwar
Actually i'm interested to this question too. I'm trying to modify xen
network scripts in
order to have it bind the vif to the right bridge and with the right
vlan tag (if using a
bridge with trunk ports).
I found that slackware has some interesting scripts here:
http://palembang-slackers.org/
On 06.07.2011 16:55, Ben Pfaff wrote:
On Wed, Jul 06, 2011 at 11:27:28AM +0200, Sébastien Riccio wrote:
root# ovs-vsctl add-br trunk0
root# ovs-vsctl add-bond trunk0 bond0 eth0 eth1
root# ovs-vsctl add-port trunk0 mgmt0 tag=85
[hangs]
Ctrl-C
let's try again
root# ovs-vsctl add-port t
On 06.07.2011 10:53, Sébastien Riccio wrote:
It doesn't sound like a false problem if you were experiencing it.
From the tables you listed, I didn't see anything that would explain
that delay, and I've not heard anyone else having that problem. Did
you say in IRC that you
It doesn't sound like a false problem if you were experiencing it.
From the tables you listed, I didn't see anything that would explain
that delay, and I've not heard anyone else having that problem. Did
you say in IRC that you were running an unmodified 1.1.1 release (and
not from the mast
On 06.07.2011 10:16, Justin Pettit wrote:
On Jul 5, 2011, at 8:40 PM, Sébastien Riccio wrote:
I've rm'ed and recreated the conf.db file and restarted from scratch with the
exact same setup as described in
my previous mails, and now it's wokring good. I don't get it... :
On 05.07.2011 21:04, Sébastien Riccio wrote:
On 05.07.2011 20:46, Justin Pettit wrote:
Most of the packet processing intelligence happens in user-space, and
the kernel module maintains a cache of the active flows. Flows are
expired from the cache after five seconds of inactivity. My guess
s bridges?
--Justin
On Jul 5, 2011, at 12:18 AM, Sébastien Riccio wrote:
Hi,
Being new to openvswitch I'm still trying to get my setup working like a charm.
I'm close to reach my goal but I've run into an annoying problem.
When there is no activity on a bridge openvswitch miss t
Hi,
Being new to openvswitch I'm still trying to get my setup working like a
charm.
I'm close to reach my goal but I've run into an annoying problem.
When there is no activity on a bridge openvswitch miss the first packets
that are sent from or to the host, and I have no idea why :(
Distrib:
20 matches
Mail list logo
