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
Fixes issue for me also. Cheers.
Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
> 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
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
> 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
; #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
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
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
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
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
> 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:
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
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
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
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
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
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
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
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 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
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 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 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
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
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
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
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
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
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 >
> >
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 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: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
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
---
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
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
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
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
> 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
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
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 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 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
> 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
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
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
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
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
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
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
> +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 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
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 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 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 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
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 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
61 matches
Mail list logo
