> On Thu, Jan 15, 2015 at 10:38:45AM +0900, YAMAMOTO Takashi wrote:
>> > ovn-controller
>> > --
>>
>> neutron "ofagent" agent has a similar design to ovn-controller.
>> you might be able to reuse at least some of code if python+ryu
>> is acceptable.
>>
>> https://github.com/openstack/n
From: Thomas Graf
Date: Thu, 15 Jan 2015 03:53:54 +0100
> Implements supports for the Group Policy VXLAN extension [0] to provide
> a lightweight and simple security label mechanism across network peers
> based on VXLAN. The security context and associated metadata is mapped
> to/from skb->mark.
On Wed, Jan 14, 2015 at 12:02:05PM +, Finucane, Stephen wrote:
> > On 01/14/2015 01:15 PM, Finucane, Stephen wrote:
> > >> Thanks for the followup. I hope that the Automake maintainers consider
> > >> the issue.
> > >
> > > No reply after > 1 week. How could we proceed here, as I'm still unabl
On Tue, Jan 13, 2015 at 09:43:58PM +0100, Thomas Graf wrote:
> I obviously absolutely love this. I will provide my thoughts over
> the next days.
Great, looking forward to the discussion.
> On 01/13/15 at 11:29am, Ben Pfaff wrote:
> > Following are not well thought out:
> >
> > learn
> >
On Thu, Jan 15, 2015 at 10:38:45AM +0900, YAMAMOTO Takashi wrote:
> > ovn-controller
> > --
>
> neutron "ofagent" agent has a similar design to ovn-controller.
> you might be able to reuse at least some of code if python+ryu
> is acceptable.
>
> https://github.com/openstack/neutron/tre
On Wed, Jan 14, 2015 at 10:12:39AM -0600, Kyle Mestery wrote:
> On Tue, Jan 13, 2015 at 2:43 PM, Thomas Graf
> wrote:
>
> > On 01/13/15 at 11:29am, Ben Pfaff wrote:
> > > Open Virtual Network (OVN) Proposed Architecture
> > >
> > >
> > > The Open v
On 01/14/15 at 07:06pm, Tom Herbert wrote:
> > +struct vxlan_metadata {
> > + __be32 vni;
> > + u32 gbp;
>
> Should this be __be32 also and use ntohl/htonl when setting to/from skb->mark?
The bitmask is stored in host byte order in vxlan_metadata to be
compatible
> +struct vxlan_metadata {
> + __be32 vni;
> + u32 gbp;
Should this be __be32 also and use ntohl/htonl when setting to/from skb->mark?
> +};
> +
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/lis
On Wed, Jan 14, 2015 at 6:55 PM, Thomas Graf wrote:
> On 01/15/15 at 01:28am, Thomas Graf wrote:
>> What exactly is the problem of having a distinct bitmap used by
>> extensions? It is the least error prone method because it's clear that
>> all extensions must match and we don't have to maintain a
On 01/15/15 at 01:28am, Thomas Graf wrote:
> What exactly is the problem of having a distinct bitmap used by
> extensions? It is the least error prone method because it's clear that
> all extensions must match and we don't have to maintain an additional
> bitmask which can be forgotten to be update
Introduces support for the group policy extension to the VXLAN virtual
port. The extension is disabled by default and only enabled if the user
has provided the respective configuration.
ovs-vsctl add-port br0 vxlan0 -- \
set Interface vxlan0 type=vxlan options:exts=gbp
The configuration in
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to
Also factors out Geneve validation code into a new separate function
validate_and_copy_geneve_opts().
A subsequent patch will introduce VXLAN options. Rename the existing
GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
tunnel metadata options.
Signed-off-by: Thomas Graf
---
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to
A VXLAN net_device looking for an appropriate socket may only consider
a socket which has a matching set of flags/extensions enabled. If
incompatible flags are enabled, return a conflict to have the caller
create a distinct socket with distinct port.
The OVS VXLAN port is kept unaware of extension
nlattr_set() is currently hardcoded to two levels of nesting. This change
introduces struct ovs_len_tbl to define minimal length requirements plus
next level nesting tables to traverse the key attributes to arbitrary depth.
Signed-off-by: Thomas Graf
---
v5->v6:
- No change
v4->v5:
- No change
> ovn-controller
> --
neutron "ofagent" agent has a similar design to ovn-controller.
you might be able to reuse at least some of code if python+ryu
is acceptable.
https://github.com/openstack/neutron/tree/stable/juno/neutron/plugins/ofagent
> OVN database
>
midonet use
On 01/14/15 at 05:08pm, Tom Herbert wrote:
> On Wed, Jan 14, 2015 at 4:23 PM, Thomas Graf wrote:
> > Because we need to compare enabled extensions in vxlan_find_sock() to
> > make sure we are not sharing a VXLAN socket with extensions enabled
> > with a user which does not have the same extensions
> On Wed, Jan 14, 2015 at 12:18:26PM +0900, YAMAMOTO Takashi wrote:
>> Suppress the following warning:
>>
>> > cc1: warnings being treated as errors
>> > In file included from ../lib/dpif.h:394:0,
>> > from ../lib/netdev.c:28:
>> > ../lib/ovs-numa.h: In function 'ovs_numa_dump_cor
On Wed, Jan 14, 2015 at 4:23 PM, Thomas Graf wrote:
> On 01/14/15 at 04:18pm, Tom Herbert wrote:
>> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> > index 99df0d7..06f7196 100644
>> > --- a/drivers/net/vxlan.c
>> > +++ b/drivers/net/vxlan.c
>> > @@ -126,6 +126,7 @@ struct vxlan_dev {
On 01/14/15 at 04:18pm, Tom Herbert wrote:
> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> > index 99df0d7..06f7196 100644
> > --- a/drivers/net/vxlan.c
> > +++ b/drivers/net/vxlan.c
> > @@ -126,6 +126,7 @@ struct vxlan_dev {
> > __u8 tos; /* TOS override
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 99df0d7..06f7196 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -126,6 +126,7 @@ struct vxlan_dev {
> __u8 tos; /* TOS override */
> __u8 ttl;
> u32
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to
A VXLAN net_device looking for an appropriate socket may only consider
a socket which has a matching set of extensions enabled. If the
extensions don't match, return a conflict to have the caller create a
distinct socket with distinct port.
The OVS VXLAN port is kept unaware of extensions at this
nlattr_set() is currently hardcoded to two levels of nesting. This change
introduces struct ovs_len_tbl to define minimal length requirements plus
next level nesting tables to traverse the key attributes to arbitrary depth.
Signed-off-by: Thomas Graf
---
v4->v5:
- No change
v3->v4:
- No change.
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to
Introduces support for the group policy extension to the VXLAN virtual
port. The extension is disabled by default and only enabled if the user
has provided the respective configuration.
ovs-vsctl add-port br0 vxlan0 -- \
set Interface vxlan0 type=vxlan options:exts=gbp
The configuration in
Also factors out Geneve validation code into a new separate function
validate_and_copy_geneve_opts().
A subsequent patch will introduce VXLAN options. Rename the existing
GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
tunnel metadata options.
Signed-off-by: Thomas Graf
---
On Wed, Jan 14, 2015 at 3:32 PM, Thomas Graf wrote:
> On 01/14/15 at 03:25pm, Jesse Gross wrote:
>> On Wed, Jan 14, 2015 at 3:18 PM, Thomas Graf wrote:
>> > Thanks! Pushed to master.
>>
>> I think probably branch-2.3 would be a good idea as well?
>
> Had the same thought. Then noticed that 2.3 do
On 01/14/15 at 03:25pm, Jesse Gross wrote:
> On Wed, Jan 14, 2015 at 3:18 PM, Thomas Graf wrote:
> > Thanks! Pushed to master.
>
> I think probably branch-2.3 would be a good idea as well?
Had the same thought. Then noticed that 2.3 doesn't have the probe
feature.
___
On Wed, Jan 14, 2015 at 3:18 PM, Thomas Graf wrote:
> On 01/14/15 at 12:41pm, Jesse Gross wrote:
>> On Wed, Jan 14, 2015 at 9:21 AM, Thomas Graf wrote:
>> > User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
>> > and packet messages. This leads to an out-of-bounds access in
>> >
On 01/14/15 at 12:41pm, Jesse Gross wrote:
> On Wed, Jan 14, 2015 at 9:21 AM, Thomas Graf wrote:
> > User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
> > and packet messages. This leads to an out-of-bounds access in
> > ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
> >
Hi,
Would you be interested in Rackspace Users contacts list?
Data Field: Name, Job Title, Verified Phone Number, Verified Email Address,
Company Name & Address Employee Size, Revenue size, SIC Code, Industry Type
etc.,
We also provide other technology users like:
1.Amazon
From: Thomas Graf
Date: Wed, 14 Jan 2015 13:56:19 +
> User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
> and packet messages. This leads to an out-of-bounds access in
> ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
> OVS_PACKET_ATTR_MAX.
>
> Introduce a new OVS_PA
I don't think that anything has changed in this respect since then.
On Wed, Jan 14, 2015 at 1:31 PM, Liu, Yajun (Susan) wrote:
> Hi Jesse and Saleha,
>
>
>
> I am trying to configure NVGRE on existing GRE tunnel. I found you tried
> same on 9/05/2012. Have you found a solution yet? Can we confi
aFrom: Fan Du
Date: Wed, 14 Jan 2015 13:10:35 +0800
> Introduce ovs_tunnel_route_lookup to consolidate route lookup
> shared by vxlan, gre, and geneve ports.
>
> Signed-off-by: Fan Du
Applied.
___
dev mailing list
dev@openvswitch.org
http://openvswit
Hi Jesse and Saleha,
I am trying to configure NVGRE on existing GRE tunnel. I found you tried same
on 9/05/2012. Have you found a solution yet? Can we configure NVGRE on
existing GRE tunnel on OVS at all? If not, have you tried to program it through
ovs-ofctl? If yes, can you pass me an examp
On Wed, Jan 14, 2015 at 5:56 AM, Thomas Graf wrote:
> User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
> and packet messages. This leads to an out-of-bounds access in
> ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
> OVS_PACKET_ATTR_MAX.
>
> Introduce a new OVS_PACKET_A
On 01/14/15 at 03:37pm, David Miller wrote:
> From: Thomas Graf
> Date: Tue, 13 Jan 2015 17:20:41 +0100
>
> > Implements supports for the Group Policy VXLAN extension [0] to provide
> > a lightweight and simple security label mechanism across network peers
> > based on VXLAN. The security context
On Jan 14, 2015, at 1:42 AM, Sree Vidya S D wrote:
> Using floodlight controller I am sending some actions to the openvswitch
>
> Can anybody help me in identifying the function where these actions are
> applied to the incoming packets on a switch ?
The OpenFLow actions are not directly applie
On Wed, Jan 14, 2015 at 5:56 AM, Thomas Graf wrote:
> User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
> and packet messages. This leads to an out-of-bounds access in
> ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
> OVS_PACKET_ATTR_MAX.
>
> Introduce a new OVS_PACKET_A
On Wed, Jan 14, 2015 at 9:21 AM, Thomas Graf wrote:
> User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
> and packet messages. This leads to an out-of-bounds access in
> ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
> OVS_PACKET_ATTR_MAX.
>
> Introduce a new OVS_PACKET_A
From: Thomas Graf
Date: Tue, 13 Jan 2015 17:20:41 +0100
> Implements supports for the Group Policy VXLAN extension [0] to provide
> a lightweight and simple security label mechanism across network peers
> based on VXLAN. The security context and associated metadata is mapped
> to/from skb->mark.
On 01/14/15 at 04:21pm, Jorge Nevado wrote:
> Linux cots506 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4)
> x86_64 x86_64 x86_64 GNU/Linux
>
> We saw on another post that this situation can happen with kernel 3.14:
> http://openvswitch.org/pipermail/dev/2014-February/036401.html
User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
and packet messages. This leads to an out-of-bounds access in
ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
OVS_PACKET_ATTR_MAX.
Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
as OVS_FLOW_ATTR_PROBE to
Hi
We are experiencing an "oops" message when using openvswitch with linux kernel
3.12.28 version.
Current versions:
#ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.1.2
Compiled Oct 8 2014 16:20:50
# uname -a
Linux cots506 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4)
x86_64
Ben,
Thanks for your continued review of the auto-attach patches and yes, including
ovs-dev is fine.
We will take a closer look at the logic which handles LLDP_TLV_MGMT_ADDR.
We developed unit tests for the new Auto-Attach TLVs in the context of the open
source LLDP project on which our code is
On Tue, Jan 13, 2015 at 2:43 PM, Thomas Graf
wrote:
> On 01/13/15 at 11:29am, Ben Pfaff wrote:
> > Open Virtual Network (OVN) Proposed Architecture
> >
> >
> > The Open vSwitch team is pleased to announce OVN, a new subproject in
> > development wi
On 01/14/2015 03:53 PM, Finucane, Stephen wrote:
I dont remember the automake version I first encountered that, it was on
another project which had already been using ustar for several years but
then at some point during 2013 it started whining about large UIDs.
Assuming said project was open s
User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
and packet messages. This leads to an out-of-bounds access in
ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
OVS_PACKET_ATTR_MAX.
Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
as OVS_FLOW_ATTR_PROBE to
> I dont remember the automake version I first encountered that, it was on
> another project which had already been using ustar for several years but
> then at some point during 2013 it started whining about large UIDs.
Assuming said project was open source, how did they go about achieving this:
On 01/14/2015 02:02 PM, Finucane, Stephen wrote:
On 01/14/2015 01:15 PM, Finucane, Stephen wrote:
Thanks for the followup. I hope that the Automake maintainers consider
the issue.
No reply after > 1 week. How could we proceed here, as I'm still unable
to run 'make dist' (without manual patch
On 01/14/15 at 02:03pm, Florian Westphal wrote:
> Thomas Graf wrote:
> > Copying ovs-dev mailing list and thus qutoing full message.
> >
> > On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
> > > Hi,
> > >
> > > I was testing 3.19-rc4 with openvswitch and encountered the splat below.
> >
> > W
vSwitch public key infrastructure dependency package
ii openvswitch-switch
1.4.2+git20120612-9.1~deb7u1 amd64
Open vSwitch switch implementations
--
Sander
>> #addr2line -e
>> /b
Thomas Graf wrote:
> Copying ovs-dev mailing list and thus qutoing full message.
>
> On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
> > Hi,
> >
> > I was testing 3.19-rc4 with openvswitch and encountered the splat below.
>
> What version of OVS are you using? Did this work properly with rc3
; #addr2line -e
> /boot/vmlinux-3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+
> 818a1690
> /mnt/kernelbuild/linux-tip/net/openvswitch/datapath.c:527
> --
> Sander
>
> [ 463.033308] BUG: unable to handle kernel paging request at fff
> On 01/14/2015 01:15 PM, Finucane, Stephen wrote:
> >> Thanks for the followup. I hope that the Automake maintainers consider
> >> the issue.
> >
> > No reply after > 1 week. How could we proceed here, as I'm still unable
> to run 'make dist' (without manual patching) in the interim? Based on my
On 01/14/2015 01:15 PM, Finucane, Stephen wrote:
Thanks for the followup. I hope that the Automake maintainers consider
the issue.
No reply after > 1 week. How could we proceed here, as I'm still unable to run
'make dist' (without manual patching) in the interim? Based on my conversation
wit
> Thanks for the followup. I hope that the Automake maintainers consider
> the issue.
No reply after > 1 week. How could we proceed here, as I'm still unable to run
'make dist' (without manual patching) in the interim? Based on my conversation
with Eric, it looks like this is something that cou
Fixes issue for me also. Cheers.
Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Using floodlight controller I am sending some actions to the openvswitch
Can anybody help me in identifying the function where these actions are
applied to the incoming packets on a switch ?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org
61 matches
Mail list logo
