date:20150114

[ovs-dev] applying flow rules to packets

2015-01-14 Thread Sree Vidya S D

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/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] test-atomic: Stop testing when running slow.

2015-01-14 Thread Finucane, Stephen

Fixes issue for me also. Cheers.

Stephen 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Finucane, Stephen

> 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 could be changed in a future 
Automake version but that could be months (or years :eek:) away. Additionally, 
there doesn't seem to be anyway to change that setting at compile time (which 
would be the preferred option).

Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Panu Matilainen


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 
with Eric, it looks like this is something that could be changed in a future 
Automake version but that could be months (or years :eek:) away. Additionally, 
there doesn't seem to be anyway to change that setting at compile time (which 
would be the preferred option).


BTW ustar is not really a solution to large UID/GID problems either, see
https://lists.gnu.org/archive/html/automake/2013-02/msg00075.html

Ever since that patch went in, tar-ustar is no longer usable for users 
with 32bit UID/GID (such as typically created by FreeIPA at least). I'd 
suggest going directly to tar-pax instead, compatibility shouldn't be an 
issue since OVS doesn't target antique commercial unixen anyway.


- Panu -
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Finucane, Stephen

> 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 with Eric, it looks like this is something that could be
> changed in a future Automake version but that could be months (or years
> :eek:) away. Additionally, there doesn't seem to be anyway to change that
> setting at compile time (which would be the preferred option).
> 
> BTW ustar is not really a solution to large UID/GID problems either, see
> https://lists.gnu.org/archive/html/automake/2013-02/msg00075.html
> 
> Ever since that patch went in, tar-ustar is no longer usable for users
> with 32bit UID/GID (such as typically created by FreeIPA at least). I'd
> suggest going directly to tar-pax instead, compatibility shouldn't be an
> issue since OVS doesn't target antique commercial unixen anyway.
> 
>   - Panu -

Ah...interesting. If Mr. Lattarini is to be believed, this change should have 
been in Automake 1.13.2, yet I'm using 1.13.4 and see no such issues (I haven't 
checked the Automake source to find the exact merge commit yet). Nonetheless, 
'tar-pax' works fine for me and I'd be happy to submit an update using that 
format, assuming lack of support in those older Unixes is truly irrelevant.

Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229

2015-01-14 Thread Thomas Graf

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 or
an older kernel?

> #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 880055f15000
> [  463.072154] IP: [] ovs_packet_cmd_execute+0x1f/0x229
> [  463.106202] PGD 1e10067 PUD 2097067 PMD 5ff54067 PTE 0
> [  463.126940] Oops:  [#1] SMP
> [  463.147505] Modules linked in:
> [  463.166938] CPU: 2 PID: 3049 Comm: ovs-vswitchd Not tainted 
> 3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ #1
> [  463.187507] Hardware name:  /D53427RKE, BIOS 
> RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
> [  463.208553] task: 880058d3 ti: 880055c38000 task.ti: 
> 880055c38000
> [  463.229734] RIP: e030:[]  [] 
> ovs_packet_cmd_execute+0x1f/0x229
> [  463.251082] RSP: e02b:880055c3ba48  EFLAGS: 00010296
> [  463.271786] RAX: 88004fe38818 RBX: 81ed4cc0 RCX: 
> 
> [  463.293072] RDX: 880055c3bb00 RSI: 880055c3bad0 RDI: 
> 8800559dc700
> [  463.314521] RBP: 8800559dc700 R08: 81b08d00 R09: 
> 7000
> [  463.336189] R10: 88004fe38814 R11: 81ed4cc0 R12: 
> 880055f14fc0
> [  463.356906] R13: 88004fe38800 R14: 880055f14fc0 R15: 
> 81b08c60
> [  463.377482] FS:  7f196321c700() GS:88005f70() 
> knlGS:88005f68
> [  463.398646] CS:  e033 DS:  ES:  CR0: 80050033
> [  463.419995] CR2: 880055f15000 CR3: 5622e000 CR4: 
> 00042660
> [  463.441577] Stack:
> [  463.462975]  000c 88004fe38814 0005 
> 8130b116
> [  463.485114]  81ed4cc0 81ed4cc0 8800559dc700 
> 880055f14fc0
> [  463.507367]  88004fe38800 0008 81b08c60 
> 81794364
> [  463.530186] Call Trace:
> [  463.552330]  [] ? nla_parse+0x57/0xe7
> [  463.574869]  [] ? genl_family_rcv_msg+0x243/0x2a9
> [  463.597276]  [] ? __slab_alloc.constprop.63+0x2bb/0x2e5
> [  463.619394]  [] ? genl_rcv_msg+0x38/0x5b
> [  463.641361]  [] ? __netlink_lookup+0x3a/0x40
> [  463.663192]  [] ? genl_family_rcv_msg+0x2a9/0x2a9
> [  463.685141]  [] ? netlink_rcv_skb+0x36/0x7c
> [  463.706874]  [] ? genl_rcv+0x1f/0x2c
> [  463.729152]  [] ? netlink_unicast+0x100/0x19c
> [  463.751315]  [] ? netlink_sendmsg+0x311/0x36b
> [  463.772483]  [] ? do_sock_sendmsg+0x62/0x7b
> [  463.793309]  [] ? copy_msghdr_from_user+0x158/0x17c
> [  463.814032]  [] ? ___sys_sendmsg+0x11f/0x197
> [  463.834595]  [] ? sock_poll+0xf2/0xfd
> [  463.854970]  [] ? ep_send_events_proc+0x91/0x153
> [  463.875603]  [] ? ep_read_events_proc+0x92/0x92
> [  463.896168]  [] ? _raw_spin_unlock_irqrestore+0x42/0x5b
> [  463.917050]  [] ? ep_scan_ready_list.isra.14+0x163/0x182
> [  463.938458]  [] ? ep_poll+0x250/0x2c4
> [  463.958214]  [] ? __sys_sendmsg+0x3b/0x5d
> [  463.977581]  [] ? system_call_fastpath+0x12/0x17
> [  463.996860] Code: ff 89 d8 5b 5d 41 5c 41 5d 41 5e c3 41 57 41 56 41 55 41 
> 54 55 53 48 83 ec 28 48 8b 46 18 4c 8b 76 20 48 89 44 24 08 49 8b 46 08 <49> 
> 8b 6e 40 48 85 c0 0f 84 e0 01 00 00 49 83 7e 10 00 0f 84 d5
> [  464.037236] RIP  [] ovs_packet_cmd_execute+0x1f/0x229
> [  464.056926]  RSP 
> [  464.076182] CR2: 880055f15000
> [  464.095097] ---[ end trace 8bcb28ced5309e55 ]---
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229

2015-01-14 Thread Florian Westphal

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 or
> an older kernel?

seems like it was introduced via 05da5898a96c
(openvswitch: Add support for OVS_FLOW_ATTR_PROBE).

It adds test for OVS_FLOW_ATTR_PROBE to ovs_packet_cmd_execute() but
this function seems to only expect OVS_PACKET_ATTR_* (so we get
out-of-bounds access)?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229

2015-01-14 Thread Sander Eikelenboom


Wednesday, January 14, 2015, 2:00:05 PM, you 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 or
> an older kernel?

Hi Thomas,

Don't know for sure, i haven't seen it before, but on the other hand after a 
reboot it is running fine now for some time.
So it seems it's not reliably reproducible :(.

OVS version is current Debian wheezy:
ii  openvswitch-common  
1.4.2+git20120612-9.1~deb7u1 amd64  
  Open vSwitch common components
ii  openvswitch-controller  
1.4.2+git20120612-9.1~deb7u1 amd64  
  Open vSwitch controller implementation
ii  openvswitch-pki 
1.4.2+git20120612-9.1~deb7u1 all
  Open vSwitch public key infrastructure dependency package
ii  openvswitch-switch  
1.4.2+git20120612-9.1~deb7u1 amd64  
  Open vSwitch switch implementations

--
Sander

>> #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 
>> 880055f15000
>> [  463.072154] IP: [] ovs_packet_cmd_execute+0x1f/0x229
>> [  463.106202] PGD 1e10067 PUD 2097067 PMD 5ff54067 PTE 0
>> [  463.126940] Oops:  [#1] SMP
>> [  463.147505] Modules linked in:
>> [  463.166938] CPU: 2 PID: 3049 Comm: ovs-vswitchd Not tainted 
>> 3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ #1
>> [  463.187507] Hardware name:  /D53427RKE, BIOS 
>> RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
>> [  463.208553] task: 880058d3 ti: 880055c38000 task.ti: 
>> 880055c38000
>> [  463.229734] RIP: e030:[]  [] 
>> ovs_packet_cmd_execute+0x1f/0x229
>> [  463.251082] RSP: e02b:880055c3ba48  EFLAGS: 00010296
>> [  463.271786] RAX: 88004fe38818 RBX: 81ed4cc0 RCX: 
>> 
>> [  463.293072] RDX: 880055c3bb00 RSI: 880055c3bad0 RDI: 
>> 8800559dc700
>> [  463.314521] RBP: 8800559dc700 R08: 81b08d00 R09: 
>> 7000
>> [  463.336189] R10: 88004fe38814 R11: 81ed4cc0 R12: 
>> 880055f14fc0
>> [  463.356906] R13: 88004fe38800 R14: 880055f14fc0 R15: 
>> 81b08c60
>> [  463.377482] FS:  7f196321c700() GS:88005f70() 
>> knlGS:88005f68
>> [  463.398646] CS:  e033 DS:  ES:  CR0: 80050033
>> [  463.419995] CR2: 880055f15000 CR3: 5622e000 CR4: 
>> 00042660
>> [  463.441577] Stack:
>> [  463.462975]  000c 88004fe38814 0005 
>> 8130b116
>> [  463.485114]  81ed4cc0 81ed4cc0 8800559dc700 
>> 880055f14fc0
>> [  463.507367]  88004fe38800 0008 81b08c60 
>> 81794364
>> [  463.530186] Call Trace:
>> [  463.552330]  [] ? nla_parse+0x57/0xe7
>> [  463.574869]  [] ? genl_family_rcv_msg+0x243/0x2a9
>> [  463.597276]  [] ? __slab_alloc.constprop.63+0x2bb/0x2e5
>> [  463.619394]  [] ? genl_rcv_msg+0x38/0x5b
>> [  463.641361]  [] ? __netlink_lookup+0x3a/0x40
>> [  463.663192]  [] ? genl_family_rcv_msg+0x2a9/0x2a9
>> [  463.685141]  [] ? netlink_rcv_skb+0x36/0x7c
>> [  463.706874]  [] ? genl_rcv+0x1f/0x2c
>> [  463.729152]  [] ? netlink_unicast+0x100/0x19c
>> [  463.751315]  [] ? netlink_sendmsg+0x311/0x36b
>> [  463.772483]  [] ? do_sock_sendmsg+0x62/0x7b
>> [  463.793309]  [] ? copy_msghdr_from_user+0x158/0x17c
>> [  463.814032]  [] ? ___sys_sendmsg+0x11f/0x197
>> [  463.834595]  [] ? sock_poll+0xf2/0xfd
>> [  463.854970]  [] ? ep_send_events_proc+0x91/0x153
>> [  463.875603]  [] ? ep_read_events_proc+0x92/0x92
>> [  463.896168]  [] ? _raw_spin_unlock_irqrestore+0x42/0x5b
>> [  463.917050]  [] ? ep_scan_ready_list.isra.14+0x163/0x182
>> [  463.938458]  [] ? ep_poll+0x250/0x2c4
>> [  463.958214]  [] ? __sys_sendmsg+0x3b/0x5d
>> [  463.977581]  [] ? system_call_fastpath+0x12/0x17
>> [  463.996860] Code: ff 89 d8 5b 5d 41 5c 41 5

Re: [ovs-dev] 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229

2015-01-14 Thread Thomas Graf

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.
> > 
> > What version of OVS are you using? Did this work properly with rc3 or
> > an older kernel?
> 
> seems like it was introduced via 05da5898a96c
> (openvswitch: Add support for OVS_FLOW_ATTR_PROBE).
> 
> It adds test for OVS_FLOW_ATTR_PROBE to ovs_packet_cmd_execute() but
> this function seems to only expect OVS_PACKET_ATTR_* (so we get
> out-of-bounds access)?

Absolutely, just came to the same conclusion independently. I'll send
a fix.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Panu Matilainen


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 patching) in the interim? Based on my
conversation with Eric, it looks like this is something that could be
changed in a future Automake version but that could be months (or years
:eek:) away. Additionally, there doesn't seem to be anyway to change that
setting at compile time (which would be the preferred option).

BTW ustar is not really a solution to large UID/GID problems either, see
https://lists.gnu.org/archive/html/automake/2013-02/msg00075.html

Ever since that patch went in, tar-ustar is no longer usable for users
with 32bit UID/GID (such as typically created by FreeIPA at least). I'd
suggest going directly to tar-pax instead, compatibility shouldn't be an
issue since OVS doesn't target antique commercial unixen anyway.

- Panu -


Ah...interesting. If Mr. Lattarini is to be believed, this change
should have been in Automake 1.13.2, yet I'm using 1.13.4 and see no
such issues (I haven't checked the Automake source to find the exact
merge commit yet). Nonetheless, 'tar-pax' works fine for me and I'd be
happy to submit an update using that format, assuming lack of support in
those older Unixes is truly irrelevant.


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.


Looking at 
http://www.gnu.org/software/tar/manual/html_section/tar_68.html the old 
v7 and ustar format share the same limit with UID/GID. Maybe the checks 
are buggier in some versions :)


As if the stored UID/GID in dist tarballs were somehow meaningful to 
begin with, sigh...


- Pan u-
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Finucane, Stephen

> 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: 
the same way or in a different manner? It would help to ensure this is (thus 
far) the best/only approach to this issue.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH net] openvswitch: packet messages need their own probe attribtue

2015-01-14 Thread Thomas Graf

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 grow the range of accepted packet attributes
while maintaining to be binary compatible with existing OVS binaries.

Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
Reported-by: Sander Eikelenboom 
Tracked-down-by: Florian Westphal 
Signed-off-by: Thomas Graf 
---
 include/uapi/linux/openvswitch.h | 4 
 net/openvswitch/datapath.c   | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 3a6dcaa..f714e86 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -174,6 +174,10 @@ enum ovs_packet_attr {
OVS_PACKET_ATTR_USERDATA,/* OVS_ACTION_ATTR_USERSPACE arg. */
OVS_PACKET_ATTR_EGRESS_TUN_KEY,  /* Nested OVS_TUNNEL_KEY_ATTR_*
attributes. */
+   OVS_PACKET_ATTR_UNUSED1,
+   OVS_PACKET_ATTR_UNUSED2,
+   OVS_PACKET_ATTR_PROBE,  /* Packet operation is a feature probe,
+  error logging should be suppressed. */
__OVS_PACKET_ATTR_MAX
 };
 
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4e9a5f0..b07349e 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -524,7 +524,7 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, 
struct genl_info *info)
struct vport *input_vport;
int len;
int err;
-   bool log = !a[OVS_FLOW_ATTR_PROBE];
+   bool log = !a[OVS_PACKET_ATTR_PROBE];
 
err = -EINVAL;
if (!a[OVS_PACKET_ATTR_PACKET] || !a[OVS_PACKET_ATTR_KEY] ||
@@ -610,6 +610,7 @@ static const struct nla_policy 
packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_PACKET] = { .len = ETH_HLEN },
[OVS_PACKET_ATTR_KEY] = { .type = NLA_NESTED },
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
+   [OVS_PACKET_ATTR_PROBE] = { .type = NLA_FLAG },
 };
 
 static const struct genl_ops dp_packet_genl_ops[] = {
-- 
1.9.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Panu Matilainen


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 source, how did they go about achieving this: 
the same way or in a different manner? It would help to ensure this is (thus 
far) the best/only approach to this issue.



Curse and whine at the pendantry, sulk for a while and then switch to 
tar-pax :)


http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d07af12947e8e8dfdab0644201a7a54309cd9cde

- Panu -
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread Kyle Mestery

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 within the Open vSwitch.  The full project announcement is
> > at Network Heresy and reproduced at:
> >
> > http://openvswitch.org/pipermail/dev/2015-January/050379.html
> >
> > OVN complements the existing capabilities of OVS to add native support
> > for virtual network abstractions, such as virtual L2 and L3 overlays
> > and security groups.  Just like OVS, our design goal is to have a
> > production-quality implementation that can operate at significant
> > scale.  This post outlines the proposed high level architecture for
> > OVN.
>
> I obviously absolutely love this. I will provide my thoughts over
> the next days.
>
> ++, same here.

One question I had at this point: Any thoughts as to the language we'll
choose to write OVN in? I ask because on the OpenStack side, there has been
interest in writing something like OVN in Python, so there may be some
developers we could pickup from there.

Regardless, this is really cool and I'm excited to see this happen!

Kyle


> > Following are not well thought out:
> >
> > learn
> > conntrack
>
> In particular how this can be tied into bidirectional ACLs.
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/3] auto-attach: Add support for IETF Auto Attach standard (v4)

2015-01-14 Thread Flynn, Dennis R (Dennis)

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 based.
We will look at porting those unit tests to the OvS unit test framework.

Dennis

-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com] 
Sent: Tuesday, January 13, 2015 6:36 PM
To: Flynn, Dennis R (Dennis)
Cc: Keene, Carl (Carl); dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/3] auto-attach: Add support for IETF Auto 
Attach standard (v4)

[adding ovs-dev back, hope that's OK]

On Tue, Jan 13, 2015 at 09:19:53PM +, Flynn, Dennis R (Dennis) wrote:
> Just wondering if you have been able to make any progress on this.
> We are very excited about the prospects of this being included in OvS 
> 2.4

One place I've become a little hung up is parsing LLDP_TLV_MGMT_ADDR.
I think that there's a bug in the length checking: I believe that 
CHECK_TLV_SIZE checks the total size of the attribute's value, but I think that 
the code here is passing the length of only the part of the TLV that it hasn't 
already passed through.  If you could take a look at that then I'd appreciate 
it.

Another thing that worries me a little is that there aren't any unit tests for 
LLDP decoding.  Protocol parsing is always a little tricky to get right and 
it's always reassuring to have some tests for it.

Thanks,

Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] oops in if_nlmsg_size

2015-01-14 Thread Jorge Nevado


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 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
But the patch provided in that case applies to a method 
"rtnl_link_get_slave_info_data_size" that does not exist on 3.12.28.
We found that another patch was added on 3.12.31:
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.31
"Commit 1d8faf48c74b8 ("net/core: Add VF link state control") added new
attribute to IFLA_VF_INFO group in rtnl_fill_ifinfo but did not adjust size
of the allocated memory in if_nlmsg_size/rtnl_vfinfo_size. As the result, we
may trigger warnings in rtnl_getlink and similar functions when many VF
links are enabled, as the information does not fit into the allocated skb."

Could this be the problem and so should we migrate to 3.12.31?(Basically we are 
using SUSE12 which ships with Linux 3.12.28)

Thanks in advance,
Jorge.

PD: This is the dmesg when the "oops" happen
...
[ 5332.257785] tun: Universal TUN/TAP device driver, 1.6
[ 5332.257790] tun: (C) 1999-2004 Max Krasnyansky 
[ 5432.060560] audit_printk_skb: 87 callbacks suppressed
[ 5432.060566] type=1006 audit(1421241301.720:130): pid=9737 uid=0 old 
auid=4294967295 new auid=0 old ses=4294967295 new ses=12 res=1
[ 5445.239586] type=1006 audit(1421241314.908:131): pid=5182 uid=0 old 
auid=4294967295 new auid=0 old ses=4294967295 new ses=13 res=1
[ 5493.502676] BUG: unable to handle kernel NULL pointer dereference at 
00a8
[ 5493.503388] IP: [] if_nlmsg_size+0xf8/0x220
[ 5493.504091] PGD 2f89067067 PUD 2f89ea4067 PMD 0
[ 5493.504798] Oops:  [#1] SMP
[ 5493.505507] Modules linked in: tun st nfsv3 nfs_acl rpcsec_gss_krb5 
auth_rpcgss nfsv4 dns_resolver nfs lockd sunrpc fscache iptable_filter 
ip_tables x_tables openvswitch(O) gre vxlan ip_tunnel libcrc32c iscsi_ibft 
iscsi_boot_sysfs af_packet joydev hid_generic ipmi_devintf iTCO_wdt 
iTCO_vendor_support dcdbas(X) usbhid coretemp kvm_intel ixgbe kvm tg3 ptp 
pps_core crct10dif_pclmul libphy crc32_pclmul crc32c_intel mdio dca 
ghash_clmulni_intel(X) shpchp aesni_intel aes_x86_64 lrw gf128mul glue_helper 
ablk_helper cryptd wmi pcspkr mei_me lpc_ich mei mfd_core ipmi_si 
ipmi_msghandler acpi_pad acpi_power_meter button processor ext4 crc16 mbcache 
jbd2 sr_mod cdrom sd_mod mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit 
ahci drm_kms_helper libahci ehci_pci ttm ehci_hcd libata drm usbcore 
megaraid_sas
[ 5493.511130]  usb_common dm_mod sg scsi_mod autofs4
...
[ 5493.534249] Call Trace:
[ 5493.535647]  [] rtmsg_ifinfo+0x30/0x100
[ 5493.537051]  [] rtnetlink_event+0x35/0x40
[ 5493.538457]  [] notifier_call_chain+0x4c/0x70
[ 5493.539879]  [] __netdev_upper_dev_link+0x3a3/0x440
[ 5493.541299]  [] netdev_create+0xcd/0x150 [openvswitch]
[ 5493.542744]  [] ovs_vport_add+0x42/0x90 [openvswitch]
[ 5493.544192]  [] new_vport+0xe/0x50 [openvswitch]
[ 5493.545622]  [] ovs_vport_cmd_new+0x11d/0x230 [openvswitch]

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Thomas Graf

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 grow the range of accepted packet attributes
while maintaining binary compatibility with existing OVS binaries.

Fixes: 9233ce ("datapath: Add support for OVS_FLOW_ATTR_PROBE.")
Reported-by: Sander Eikelenboom 
Signed-off-by: Thomas Graf 
---
 AUTHORS   | 1 +
 datapath/datapath.c   | 3 ++-
 datapath/linux/compat/include/linux/openvswitch.h | 4 
 lib/dpif-netlink.c| 2 +-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 3356ee8..ab82e24 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -301,6 +301,7 @@ Roger Leigh rle...@codelibre.net
 Rogério Vinhal Nunes
 Roman Sokolkov  rsokol...@gmail.com
 Ronaldo A. Ferreira ronal...@cs.princeton.edu
+Sander Eikelenboom  li...@eikelenboom.it
 Saul St. John   sstj...@cs.wisc.edu
 Scott Hendricks shendri...@nicira.com
 Sean Brady  sbr...@gtfservices.com
diff --git a/datapath/datapath.c b/datapath/datapath.c
index de912f6..c562e89 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -531,7 +531,7 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, 
struct genl_info *info)
struct vport *input_vport;
int len;
int err;
-   bool log = !a[OVS_FLOW_ATTR_PROBE];
+   bool log = !a[OVS_PACKET_ATTR_PROBE];
 
err = -EINVAL;
if (!a[OVS_PACKET_ATTR_PACKET] || !a[OVS_PACKET_ATTR_KEY] ||
@@ -618,6 +618,7 @@ static const struct nla_policy 
packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_PACKET] = { .len = ETH_HLEN },
[OVS_PACKET_ATTR_KEY] = { .type = NLA_NESTED },
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
+   [OVS_PACKET_ATTR_PROBE] = { .type = NLA_FLAG },
 };
 
 static struct genl_ops dp_packet_genl_ops[] = {
diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 67715f8..a59e109 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -197,6 +197,10 @@ enum ovs_packet_attr {
OVS_PACKET_ATTR_USERDATA,/* OVS_ACTION_ATTR_USERSPACE arg. */
OVS_PACKET_ATTR_EGRESS_TUN_KEY,  /* Nested OVS_TUNNEL_KEY_ATTR_*
attributes. */
+   OVS_PACKET_ATTR_UNUSED1,
+   OVS_PACKET_ATTR_UNUSED2,
+   OVS_PACKET_ATTR_PROBE,  /* Packet operation is a feature probe,
+  error logging should be suppressed. */
__OVS_PACKET_ATTR_MAX
 };
 
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 8f0eca6..a9d60f7 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -1530,7 +1530,7 @@ dpif_netlink_encode_execute(int dp_ifindex, const struct 
dpif_execute *d_exec,
 nl_msg_put_unspec(buf, OVS_PACKET_ATTR_ACTIONS,
   d_exec->actions, d_exec->actions_len);
 if (d_exec->probe) {
-nl_msg_put_flag(buf, OVS_FLOW_ATTR_PROBE);
+nl_msg_put_flag(buf, OVS_PACKET_ATTR_PROBE);
 }
 }
 
-- 
1.9.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] oops in if_nlmsg_size

2015-01-14 Thread Thomas Graf

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
> But the patch provided in that case applies to a method 
> "rtnl_link_get_slave_info_data_size" that does not exist on 3.12.28.

The oops looks very much like this bug. Is it possible that SUSE
backported "rtnetlink: provide api for getting and setting slave info"
but not the follow up fix?

In general, the bug does not look like its caused by OVS. OVS is merely
the trigger for the netdevice notification which causes the construction
of a Netlink message in this case.

I'd check with your distribution first.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/5 net-next v4] VXLAN Group Policy Extension

2015-01-14 Thread David Miller

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. This allows further mapping to a SELinux context
> using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> tc, etc.
> 
> The extension is disabled by default and should be run on a distinct
> port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
> which ignore unknown reserved bits will be able to receive VXLAN-GBP
> frames.

Thomas, unfortunately Tom's vxlan RCO patches were ready before your's
in my queue so I applied his work first.  You'll have to therefore
respin this series on top of it.

Thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH net] openvswitch: packet messages need their own probe attribtue

2015-01-14 Thread Jesse Gross

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_ATTR_PROBE with the same numeric value
> as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
> while maintaining to be binary compatible with existing OVS binaries.
>
> Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
> Reported-by: Sander Eikelenboom 
> Tracked-down-by: Florian Westphal 
> Signed-off-by: Thomas Graf 

This is kind of a nasty bug, thanks for fixing it.

Reviewed-by: Jesse Gross 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Jesse Gross

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_ATTR_PROBE with the same numeric value
> as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
> while maintaining binary compatibility with existing OVS binaries.
>
> Fixes: 9233ce ("datapath: Add support for OVS_FLOW_ATTR_PROBE.")
> Reported-by: Sander Eikelenboom 
> Signed-off-by: Thomas Graf 

Acked-by: Jesse Gross 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] applying flow rules to packets

2015-01-14 Thread Jarno Rajahalme

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 applied to incoming packets, so there is 
no function where that happens. OpenFlow actions are translated to internal 
flow state in ofproto/ofproto-dpif-xlate.c, internal state is translated to 
datapath actions in lib/odp-util.c. Different datapaths then apply these to the 
incoming packets, e.g., Linux kernel datapath in datapath/actions.c.

  Jarno

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/5 net-next v4] VXLAN Group Policy Extension

2015-01-14 Thread Thomas Graf

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 and associated metadata is mapped
> > to/from skb->mark. This allows further mapping to a SELinux context
> > using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> > tc, etc.
> > 
> > The extension is disabled by default and should be run on a distinct
> > port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
> > which ignore unknown reserved bits will be able to receive VXLAN-GBP
> > frames.
> 
> Thomas, unfortunately Tom's vxlan RCO patches were ready before your's
> in my queue so I applied his work first.  You'll have to therefore
> respin this series on top of it.

Sure, no problem.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH net] openvswitch: packet messages need their own probe attribtue

2015-01-14 Thread Pravin Shelar

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_ATTR_PROBE with the same numeric value
> as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
> while maintaining to be binary compatible with existing OVS binaries.
>
> Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
> Reported-by: Sander Eikelenboom 
> Tracked-down-by: Florian Westphal 
> Signed-off-by: Thomas Graf 
> ---

Looks good.
Acked-by: Pravin B Shelar 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Fwd: Implementing NVGRE on Open vSwitch

2015-01-14 Thread Liu, Yajun (Susan)

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 example?

Thanks
--Susan

On Tue, Sep 4, 2012 at 8:55 PM, Saleha Asad http://openvswitch.org/mailman/listinfo/dev>> wrote:

> -- Forwarded message --

> From: Saleha Asad  gmail.com>

> Date: Tue, Sep 4, 2012 at 8:08 PM

> Subject: Re: [ovs-dev] Implementing NVGRE on Open vSwitch

> To: Jesse Gross  nicira.com>

>

>

> Hey can you give some directions for starting the implementation of NVGRE. I

> have

> installed NOX on my machine and I am trying to figure out the ways of

> configuration of the already existing GRE tunnel on Open vSwitch to form

> NVGRE

> tunnel.

I'm sorry but I don't think we're going to be able to help you with

writing your controller here.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCHv3 net-next] openvswitch: Introduce ovs_tunnel_route_lookup

2015-01-14 Thread David Miller

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://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Fwd: Implementing NVGRE on Open vSwitch

2015-01-14 Thread Jesse Gross

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 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 example?
>
>
>
> Thanks
>
> --Susan
>
>
>
> On Tue, Sep 4, 2012 at 8:55 PM, Saleha Asad  wrote:
>
>> -- Forwarded message --
>
>> From: Saleha Asad 
>
>> Date: Tue, Sep 4, 2012 at 8:08 PM
>
>> Subject: Re: [ovs-dev] Implementing NVGRE on Open vSwitch
>
>> To: Jesse Gross 
>
>>
>
>>
>
>> Hey can you give some directions for starting the implementation of NVGRE.
>> I
>
>> have
>
>> installed NOX on my machine and I am trying to figure out the ways of
>
>> configuration of the already existing GRE tunnel on Open vSwitch to form
>
>> NVGRE
>
>> tunnel.
>
>
>
> I'm sorry but I don't think we're going to be able to help you with
>
> writing your controller here.
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH net] openvswitch: packet messages need their own probe attribtue

2015-01-14 Thread David Miller

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_PACKET_ATTR_PROBE with the same numeric value
> as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
> while maintaining to be binary compatible with existing OVS binaries.
> 
> Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
> Reported-by: Sander Eikelenboom 
> Tracked-down-by: Florian Westphal 
> Signed-off-by: Thomas Graf 

Applied, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Rachspace Users

2015-01-14 Thread Kitty Bonner

 

 

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 s3

2.Digital Ocean

3.Bluehost

4.Softlayer

5.Google App and many more...

 

We also provide IT Decision Makers, Sales and Marketing Decision Makers,
C-level Titles and other titles as per your requirement.

Please review and let me know your interest if you are looking for above
mentioned users list or other contacts list for your campaigns.

Await your response!

Thanks,

Kitty

Data Specialist

 

 

 

 

 

 

 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Thomas Graf

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 >
> > OVS_PACKET_ATTR_MAX.
> >
> > Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
> > as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
> > while maintaining binary compatibility with existing OVS binaries.
> >
> > Fixes: 9233ce ("datapath: Add support for OVS_FLOW_ATTR_PROBE.")
> > Reported-by: Sander Eikelenboom 
> > Signed-off-by: Thomas Graf 
> 
> Acked-by: Jesse Gross 

Thanks! Pushed to master.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Jesse Gross

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
>> > 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 grow the range of accepted packet attributes
>> > while maintaining binary compatibility with existing OVS binaries.
>> >
>> > Fixes: 9233ce ("datapath: Add support for OVS_FLOW_ATTR_PROBE.")
>> > Reported-by: Sander Eikelenboom 
>> > Signed-off-by: Thomas Graf 
>>
>> Acked-by: Jesse Gross 
>
> Thanks! Pushed to master.

I think probably branch-2.3 would be a good idea as well?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Thomas Graf

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.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif: Use separate OVS_PACKET_ATTR_PROBE for packet messges

2015-01-14 Thread Jesse Gross

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 doesn't have the probe
> feature.

Ah, OK :)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 3/5] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()

2015-01-14 Thread Thomas Graf

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 
---
v4->v5:
 - No change
v3->v4:
 - Renamed validate_and_copy_geneve_opts() to validate_geneve_opts() as
   suggested by Jesse
v2->v3:
 - No change
v1->v2:
 - Don't rename genev_tun_opt_from_nlattr() and keep it Geneve specific,
   pointed out by Jesse.
 - Factor out Geneve specific validation code into separate function as
   requested by Jesse.

 net/openvswitch/flow.c |  2 +-
 net/openvswitch/flow.h | 14 
 net/openvswitch/flow_netlink.c | 72 +++---
 3 files changed, 47 insertions(+), 41 deletions(-)

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index df334fe..e2c348b 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -691,7 +691,7 @@ int ovs_flow_key_extract(const struct ovs_tunnel_info 
*tun_info,
BUILD_BUG_ON((1 << (sizeof(tun_info->options_len) *
   8)) - 1
> sizeof(key->tun_opts));
-   memcpy(GENEVE_OPTS(key, tun_info->options_len),
+   memcpy(TUN_METADATA_OPTS(key, tun_info->options_len),
   tun_info->options, tun_info->options_len);
key->tun_opts_len = tun_info->options_len;
} else {
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index a8b30f3..d3d0a40 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -53,7 +53,7 @@ struct ovs_key_ipv4_tunnel {
 
 struct ovs_tunnel_info {
struct ovs_key_ipv4_tunnel tunnel;
-   const struct geneve_opt *options;
+   const void *options;
u8 options_len;
 };
 
@@ -61,10 +61,10 @@ struct ovs_tunnel_info {
  * maximum size. This allows us to get the benefits of variable length
  * matching for small options.
  */
-#define GENEVE_OPTS(flow_key, opt_len) \
-   ((struct geneve_opt *)((flow_key)->tun_opts + \
-  FIELD_SIZEOF(struct sw_flow_key, tun_opts) - \
-  opt_len))
+#define TUN_METADATA_OFFSET(opt_len) \
+   (FIELD_SIZEOF(struct sw_flow_key, tun_opts) - opt_len)
+#define TUN_METADATA_OPTS(flow_key, opt_len) \
+   ((void *)((flow_key)->tun_opts + TUN_METADATA_OFFSET(opt_len)))
 
 static inline void __ovs_flow_tun_info_init(struct ovs_tunnel_info *tun_info,
__be32 saddr, __be32 daddr,
@@ -73,7 +73,7 @@ static inline void __ovs_flow_tun_info_init(struct 
ovs_tunnel_info *tun_info,
__be16 tp_dst,
__be64 tun_id,
__be16 tun_flags,
-   const struct geneve_opt *opts,
+   const void *opts,
u8 opts_len)
 {
tun_info->tunnel.tun_id = tun_id;
@@ -105,7 +105,7 @@ static inline void ovs_flow_tun_info_init(struct 
ovs_tunnel_info *tun_info,
  __be16 tp_dst,
  __be64 tun_id,
  __be16 tun_flags,
- const struct geneve_opt *opts,
+ const void *opts,
  u8 opts_len)
 {
__ovs_flow_tun_info_init(tun_info, iph->saddr, iph->daddr,
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index d1eecf7..2e8a9cd 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -432,8 +432,7 @@ static int genev_tun_opt_from_nlattr(const struct nlattr *a,
SW_FLOW_KEY_PUT(match, tun_opts_len, 0xff, true);
}
 
-   opt_key_offset = (unsigned long)GENEVE_OPTS((struct sw_flow_key *)0,
-   nla_len(a));
+   opt_key_offset = TUN_METADATA_OFFSET(nla_len(a));
SW_FLOW_KEY_MEMCPY_OFFSET(match, opt_key_offset, nla_data(a),
  nla_len(a), is_mask);
return 0;
@@ -558,8 +557,7 @@ static int ipv4_tun_from_nlattr(const struct nlattr *attr,
 
 static int __ipv4_tun_to_nlattr(struct sk_buff *skb,
const struct ovs_key_ipv4_tunnel *output,
-   const struct geneve_opt *tun_opts,
-   int swkey_tun_opts_len)
+   const void *tun_opts, int swkey_tun_opts_len)
 {
if (output->tun_flags & TUNNEL_KEY &&
nla_put_be64(skb, OVS_TUNNEL_KEY_ATTR_ID, output->tun_id))
@@ -600,

[ovs-dev] [PATCH 5/5] openvswitch: Support VXLAN Group Policy extension

2015-01-14 Thread 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 interface to enable the extension is based on a new
attribute OVS_VXLAN_EXT_GBP nested inside OVS_TUNNEL_ATTR_EXTENSION
which can carry additional extensions as needed in the future.

The group policy metadata is stored as binary blob (struct ovs_vxlan_opts)
internally just like Geneve options but transported as nested Netlink
attributes to user space.

Renames the existing TUNNEL_OPTIONS_PRESENT to TUNNEL_GENEVE_OPT with the
binary value kept intact, a new flag TUNNEL_VXLAN_OPT is introduced.

The attributes OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS and existing
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS are implemented mutually exclusive.

Signed-off-by: Thomas Graf 
---
v4->v5:
 - No change
v3->v4:
 - Fixed OVS_VXLAN_EXT_MAX->OVS_VXLAN_EXT_GBP typo as spotted by Jesse
 - Only applied tunnel options if they are of the right type as
   suggested by Jesse
v2->v3:
 - No change
v1->v2:
 - Addressed Jesse's request to transport VXLAN options as Netlink
   attributes instead of a binary blob. Allows a partial transport of
   VXLAN extensions. Internally, the datapath continues to use a binary
   blob (defined in vport-vxlan.h) for performance reasons.
 - Added new TUNNEL_GENEVE_OPT and TUNNEL_VXLAN_OPT flags to mark
   tunnel option flavour
 - Correctly report VXLAN options to user space

 include/net/ip_tunnels.h |   5 +-
 include/uapi/linux/openvswitch.h |  11 
 net/openvswitch/flow_netlink.c   | 114 ++-
 net/openvswitch/vport-geneve.c   |  15 --
 net/openvswitch/vport-vxlan.c|  82 +++-
 net/openvswitch/vport-vxlan.h|  11 
 6 files changed, 218 insertions(+), 20 deletions(-)
 create mode 100644 net/openvswitch/vport-vxlan.h

diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 25a59eb..ce4db3c 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -97,7 +97,10 @@ struct ip_tunnel {
 #define TUNNEL_DONT_FRAGMENT__cpu_to_be16(0x0100)
 #define TUNNEL_OAM __cpu_to_be16(0x0200)
 #define TUNNEL_CRIT_OPT__cpu_to_be16(0x0400)
-#define TUNNEL_OPTIONS_PRESENT __cpu_to_be16(0x0800)
+#define TUNNEL_GENEVE_OPT  __cpu_to_be16(0x0800)
+#define TUNNEL_VXLAN_OPT   __cpu_to_be16(0x1000)
+
+#define TUNNEL_OPTIONS_PRESENT (TUNNEL_GENEVE_OPT | TUNNEL_VXLAN_OPT)
 
 struct tnl_ptk_info {
__be16 flags;
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 3a6dcaa..e474c95 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -248,11 +248,21 @@ enum ovs_vport_attr {
 
 #define OVS_VPORT_ATTR_MAX (__OVS_VPORT_ATTR_MAX - 1)
 
+enum {
+   OVS_VXLAN_EXT_UNSPEC,
+   OVS_VXLAN_EXT_GBP,  /* Flag or __u32 */
+   __OVS_VXLAN_EXT_MAX,
+};
+
+#define OVS_VXLAN_EXT_MAX (__OVS_VXLAN_EXT_MAX - 1)
+
+
 /* OVS_VPORT_ATTR_OPTIONS attributes for tunnels.
  */
 enum {
OVS_TUNNEL_ATTR_UNSPEC,
OVS_TUNNEL_ATTR_DST_PORT, /* 16-bit UDP port, used by L4 tunnels. */
+   OVS_TUNNEL_ATTR_EXTENSION,
__OVS_TUNNEL_ATTR_MAX
 };
 
@@ -324,6 +334,7 @@ enum ovs_tunnel_key_attr {
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS,/* Array of Geneve options. */
OVS_TUNNEL_KEY_ATTR_TP_SRC, /* be16 src Transport Port. */
OVS_TUNNEL_KEY_ATTR_TP_DST, /* be16 dst Transport Port. */
+   OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS, /* Nested OVS_VXLAN_EXT_* */
__OVS_TUNNEL_KEY_ATTR_MAX
 };
 
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 518941c..d210d1b 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -49,6 +49,7 @@
 #include 
 
 #include "flow_netlink.h"
+#include "vport-vxlan.h"
 
 struct ovs_len_tbl {
int len;
@@ -268,6 +269,9 @@ size_t ovs_tun_key_attr_size(void)
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_CSUM */
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_OAM */
+ nla_total_size(256)  /* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS */
+   /* OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS is mutually exclusive with
+* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS and covered by it.
+*/
+ nla_total_size(2)/* OVS_TUNNEL_KEY_ATTR_TP_SRC */
+ nla_total_size(2);   /* OVS_TUNNEL_KEY_ATTR_TP_DST */
 }
@@ -308,6 +312,7 @@ static const struct ovs_len_tbl 
ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX + 1]
[OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
[OVS_TUNNEL_KEY_ATTR_OAM]   = { .len = 0 },
[OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS]   = { .len = OVS_ATTR_NESTED },
+   [OVS_TUNNEL_K

[ovs-dev] [PATCH 4/5] openvswitch: Allow for any level of nesting in flow attributes

2015-01-14 Thread Thomas Graf

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. The spotted bug is unrelatd to this series and will be fixed
   in a separate patch
v2->v3:
 - No change
v1->v2:
 - New patch to allow nested Netlink attributes inside
   OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS

 net/openvswitch/flow_netlink.c | 106 ++---
 1 file changed, 56 insertions(+), 50 deletions(-)

diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 2e8a9cd..518941c 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -50,6 +50,13 @@
 
 #include "flow_netlink.h"
 
+struct ovs_len_tbl {
+   int len;
+   const struct ovs_len_tbl *next;
+};
+
+#define OVS_ATTR_NESTED -1
+
 static void update_range(struct sw_flow_match *match,
 size_t offset, size_t size, bool is_mask)
 {
@@ -289,29 +296,44 @@ size_t ovs_key_attr_size(void)
+ nla_total_size(28); /* OVS_KEY_ATTR_ND */
 }
 
+static const struct ovs_len_tbl ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX + 
1] = {
+   [OVS_TUNNEL_KEY_ATTR_ID]= { .len = sizeof(u64) },
+   [OVS_TUNNEL_KEY_ATTR_IPV4_SRC]  = { .len = sizeof(u32) },
+   [OVS_TUNNEL_KEY_ATTR_IPV4_DST]  = { .len = sizeof(u32) },
+   [OVS_TUNNEL_KEY_ATTR_TOS]   = { .len = 1 },
+   [OVS_TUNNEL_KEY_ATTR_TTL]   = { .len = 1 },
+   [OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT] = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_CSUM]  = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_TP_SRC]= { .len = sizeof(u16) },
+   [OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
+   [OVS_TUNNEL_KEY_ATTR_OAM]   = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS]   = { .len = OVS_ATTR_NESTED },
+};
+
 /* The size of the argument for each %OVS_KEY_ATTR_* Netlink attribute.  */
-static const int ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
-   [OVS_KEY_ATTR_ENCAP] = -1,
-   [OVS_KEY_ATTR_PRIORITY] = sizeof(u32),
-   [OVS_KEY_ATTR_IN_PORT] = sizeof(u32),
-   [OVS_KEY_ATTR_SKB_MARK] = sizeof(u32),
-   [OVS_KEY_ATTR_ETHERNET] = sizeof(struct ovs_key_ethernet),
-   [OVS_KEY_ATTR_VLAN] = sizeof(__be16),
-   [OVS_KEY_ATTR_ETHERTYPE] = sizeof(__be16),
-   [OVS_KEY_ATTR_IPV4] = sizeof(struct ovs_key_ipv4),
-   [OVS_KEY_ATTR_IPV6] = sizeof(struct ovs_key_ipv6),
-   [OVS_KEY_ATTR_TCP] = sizeof(struct ovs_key_tcp),
-   [OVS_KEY_ATTR_TCP_FLAGS] = sizeof(__be16),
-   [OVS_KEY_ATTR_UDP] = sizeof(struct ovs_key_udp),
-   [OVS_KEY_ATTR_SCTP] = sizeof(struct ovs_key_sctp),
-   [OVS_KEY_ATTR_ICMP] = sizeof(struct ovs_key_icmp),
-   [OVS_KEY_ATTR_ICMPV6] = sizeof(struct ovs_key_icmpv6),
-   [OVS_KEY_ATTR_ARP] = sizeof(struct ovs_key_arp),
-   [OVS_KEY_ATTR_ND] = sizeof(struct ovs_key_nd),
-   [OVS_KEY_ATTR_RECIRC_ID] = sizeof(u32),
-   [OVS_KEY_ATTR_DP_HASH] = sizeof(u32),
-   [OVS_KEY_ATTR_TUNNEL] = -1,
-   [OVS_KEY_ATTR_MPLS] = sizeof(struct ovs_key_mpls),
+static const struct ovs_len_tbl ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
+   [OVS_KEY_ATTR_ENCAP] = { .len = OVS_ATTR_NESTED },
+   [OVS_KEY_ATTR_PRIORITY]  = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_IN_PORT]   = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_SKB_MARK]  = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_ETHERNET]  = { .len = sizeof(struct ovs_key_ethernet) },
+   [OVS_KEY_ATTR_VLAN]  = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_ETHERTYPE] = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_IPV4]  = { .len = sizeof(struct ovs_key_ipv4) },
+   [OVS_KEY_ATTR_IPV6]  = { .len = sizeof(struct ovs_key_ipv6) },
+   [OVS_KEY_ATTR_TCP]   = { .len = sizeof(struct ovs_key_tcp) },
+   [OVS_KEY_ATTR_TCP_FLAGS] = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_UDP]   = { .len = sizeof(struct ovs_key_udp) },
+   [OVS_KEY_ATTR_SCTP]  = { .len = sizeof(struct ovs_key_sctp) },
+   [OVS_KEY_ATTR_ICMP]  = { .len = sizeof(struct ovs_key_icmp) },
+   [OVS_KEY_ATTR_ICMPV6]= { .len = sizeof(struct ovs_key_icmpv6) },
+   [OVS_KEY_ATTR_ARP]   = { .len = sizeof(struct ovs_key_arp) },
+   [OVS_KEY_ATTR_ND]= { .len = sizeof(struct ovs_key_nd) },
+   [OVS_KEY_ATTR_RECIRC_ID] = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_DP_HASH]   = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_TUNNEL]= { .len = OVS_ATTR_NESTED,
+.next = ovs_tunnel_key_lens, },
+   [OVS_KEY_ATTR_MPLS]  = { .len = sizeof(struct ovs_key_mpls) },
 };
 
 static bool is_all_zero(const u8 *fp, size_t size)
@@ -352,8 +374,8 @@ static int __parse_flow_nlattrs(const struct nlattr *attr,

[ovs-dev] [PATCH 0/5 net-next v5] VXLAN Group Policy Extension

2015-01-14 Thread 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 implement ACLs directly with nftables, iptables, OVS,
tc, etc.

The extension is disabled by default and should be run on a distinct
port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
which ignore unknown reserved bits will be able to receive VXLAN-GBP
frames.

Simple usage example:

10.1.1.1:
   # ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp
   # iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200

10.1.1.2:
   # ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp
   # iptables -I INPUT -m mark --mark 0x200 -j DROP

iproute2 [1] and OVS [2] support will be provided in separate patches.

[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] https://github.com/tgraf/iproute2/tree/vxlan-gbp
[2] https://github.com/tgraf/ovs/tree/vxlan-gbp

Thomas Graf (5):
  vxlan: Group Policy extension
  vxlan: Only bind to sockets with correct extensions enabled
  openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
  openvswitch: Allow for any level of nesting in flow attributes
  openvswitch: Support VXLAN Group Policy extension

 drivers/net/vxlan.c  | 125 +
 include/net/ip_tunnels.h |   5 +-
 include/net/vxlan.h  |  83 +++-
 include/uapi/linux/if_link.h |   1 +
 include/uapi/linux/openvswitch.h |  11 ++
 net/openvswitch/flow.c   |   2 +-
 net/openvswitch/flow.h   |  14 +-
 net/openvswitch/flow_netlink.c   | 286 ++-
 net/openvswitch/vport-geneve.c   |  15 +-
 net/openvswitch/vport-vxlan.c|  91 -
 net/openvswitch/vport-vxlan.h|  11 ++
 11 files changed, 500 insertions(+), 144 deletions(-)
 create mode 100644 net/openvswitch/vport-vxlan.h

-- 
1.9.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/5] vxlan: Only bind to sockets with correct extensions enabled

2015-01-14 Thread Thomas Graf

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 point.

Signed-off-by: Thomas Graf 
---
v4->v5:
 - No change
v3->v4:
 - No change
v2->v3:
 - No change
v1->v2:
 - Improved commit message, reported by Jesse

 drivers/net/vxlan.c   | 35 +--
 include/net/vxlan.h   |  2 +-
 net/openvswitch/vport-vxlan.c |  2 +-
 3 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 06f7196..ca94f2f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -265,14 +265,15 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct 
vxlan_fdb *fdb)
 }
 
 /* Find VXLAN socket based on network namespace, address family and UDP port */
-static struct vxlan_sock *vxlan_find_sock(struct net *net,
- sa_family_t family, __be16 port)
+static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
+ __be16 port, u32 exts)
 {
struct vxlan_sock *vs;
 
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
if (inet_sk(vs->sock->sk)->inet_sport == port &&
-   inet_sk(vs->sock->sk)->sk.sk_family == family)
+   inet_sk(vs->sock->sk)->sk.sk_family == family &&
+   vs->exts == exts)
return vs;
}
return NULL;
@@ -292,11 +293,12 @@ static struct vxlan_dev *vxlan_vs_find_vni(struct 
vxlan_sock *vs, u32 id)
 
 /* Look up VNI in a per net namespace table */
 static struct vxlan_dev *vxlan_find_vni(struct net *net, u32 id,
-   sa_family_t family, __be16 port)
+   sa_family_t family, __be16 port,
+   u32 exts)
 {
struct vxlan_sock *vs;
 
-   vs = vxlan_find_sock(net, family, port);
+   vs = vxlan_find_sock(net, family, port, exts);
if (!vs)
return NULL;
 
@@ -1963,7 +1965,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
 
ip_rt_put(rt);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
-  dst->sa.sa_family, dst_port);
+  dst->sa.sa_family, dst_port,
+  vxlan->exts);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -2022,7 +2025,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
 
dst_release(ndst);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
-  dst->sa.sa_family, dst_port);
+  dst->sa.sa_family, dst_port,
+  vxlan->exts);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -2192,7 +2196,7 @@ static int vxlan_init(struct net_device *dev)
 
spin_lock(&vn->sock_lock);
vs = vxlan_find_sock(vxlan->net, ipv6 ? AF_INET6 : AF_INET,
-vxlan->dst_port);
+vxlan->dst_port, vxlan->exts);
if (vs && atomic_add_unless(&vs->refcnt, 1, 0)) {
/* If we have a socket with same port already, reuse it */
vxlan_vs_add_dev(vs, vxlan);
@@ -2532,7 +2536,7 @@ static struct socket *vxlan_create_sock(struct net *net, 
bool ipv6,
 /* Create new listen socket if needed */
 static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
  vxlan_rcv_t *rcv, void *data,
- u32 flags)
+ u32 flags, u32 exts)
 {
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
@@ -2561,6 +2565,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net 
*net, __be16 port,
vs->rcv = rcv;
vs->data = data;
vs->flags = flags;
+   vs->exts = exts;
 
/* Initialize the vxlan udp offloads structure */
vs->udp_offloads.port = port;
@@ -2585,13 +2590,14 @@ static struct vxlan_sock *vxlan_socket_create(struct 
net *net, __be16 port,
 
 struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
  vxlan_rcv_t *rcv, void *data,
- bool no_share, u32 flags)
+

[ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread 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 implement ACLs directly with nftables, iptables, OVS,
tc, etc.

The group membership is defined by the lower 16 bits of skb->mark, the
upper 16 bits are used for flags.

SELinux allows to manage label to secure local resources. However,
distributed applications require ACLs to implemented across hosts. This
is typically achieved by matching on L2-L4 fields to identify the
original sending host and process on the receiver. On top of that,
netlabel and specifically CIPSO [1] allow to map security contexts to
universal labels.  However, netlabel and CIPSO are relatively complex.
This patch provides a lightweight alternative for overlay network
environments with a trusted underlay. No additional control protocol
is required.

   Host 1:   Host 2:

  Group AGroup BGroup B Group A
  +-+   +-++---+   +-+
  | lxc |   | SELinux CTX || httpd |   | VM  |
  +--+--+   +--+--++---+---+   +--+--+
  \---+---/ \+---/
  |  |
  +---+---+  +---+---+
  | vxlan |  | vxlan |
  +---+---+  +---+---+
  +--+

Backwards compatibility:
A VXLAN-GBP socket can receive standard VXLAN frames and will assign
the default group 0x to such frames. A Linux VXLAN socket will
drop VXLAN-GBP  frames. The extension is therefore disabled by default
and needs to be specifically enabled:

   ip link add [...] type vxlan [...] gbp

In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
must run on a separate port number.

Examples:
 iptables:
  host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
  host2# iptables -I INPUT -m mark --mark 0x200 -j DROP

 OVS:
  # ovs-ofctl add-flow br0 
'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
  # ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'

[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] http://lwn.net/Articles/204905/

Signed-off-by: Thomas Graf 
---
v4->v5:
 - Rebased on top of Tom's RCO work
 - Dropped IFLA_VXLAN_EXTENSION container attribute and embedded IFLA_VXLAN_GBP
   as top level VXLAN attribute like RCO for consistency. 
v3->v4:
 - Patch 1 was no longer needed due to Tom Herbert's 3bf394 ("vxlan: Improve
   support for header flags"). Moved remaining header description to this patch.
 - Zero out vxlan_metadata in vxlan_tnl_send() as suggested by Jesse.
 - Reported enabled extensions to user space as requested by Nicolas.
 - Use VXLAN_HF_GBP instead of bitfield to be in line with Tom's work.
v2->v3:
 - Removed empty struct vxlan_gbp as spotted by Alexei
v1->v2:
 - split GBP header definition into separate struct vxlanhdr_gbp as requested
   by Alexei

 drivers/net/vxlan.c   | 90 ---
 include/net/vxlan.h   | 81 +++---
 include/uapi/linux/if_link.h  |  1 +
 net/openvswitch/vport-vxlan.c |  9 +++--
 4 files changed, 160 insertions(+), 21 deletions(-)

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   flags;/* VXLAN_F_* in vxlan.h */
+   u32   exts; /* Enabled extensions */
 
struct work_struct sock_work;
struct work_struct igmp_join;
@@ -620,7 +621,8 @@ static struct sk_buff **vxlan_gro_receive(struct sk_buff 
**head,
continue;
 
vh2 = (struct vxlanhdr *)(p->data + off_vx);
-   if (vh->vx_vni != vh2->vx_vni) {
+   if (vh->vx_flags != vh2->vx_flags ||
+   vh->vx_vni != vh2->vx_vni) {
NAPI_GRO_CB(p)->same_flow = 0;
continue;
}
@@ -1183,6 +1185,7 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
struct vxlan_sock *vs;
struct vxlanhdr *vxh;
u32 flags, vni;
+   struct vxlan_metadata md = {0};
 
/* Need Vxlan and inner Ethernet header to be present */
if (!pskb_may_pull(skb, VXLAN_HLEN))
@@ -1216,6 +1219,29 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
vni &= VXLAN_VID_MASK;
}
 
+   /* For backwards compatibility, only allow reserved fields to be
+* used by VXLAN extensions if explici

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Tom Herbert

> 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   flags;/* VXLAN_F_* in vxlan.h */
> +   u32   exts; /* Enabled extensions */
>

Thomas, why not just make a VXAM_F_GPB flag? Then this setting can be
saved in the flags for vxlan_dev and vxlan_sock so no exts field.

Tom


> struct work_struct sock_work;
> struct work_struct igmp_join;
> @@ -620,7 +621,8 @@ static struct sk_buff **vxlan_gro_receive(struct sk_buff 
> **head,
> continue;
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Thomas Graf

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 */
> > __u8  ttl;
> > u32   flags;/* VXLAN_F_* in vxlan.h */
> > +   u32   exts; /* Enabled extensions */
> >
> 
> Thomas, why not just make a VXAM_F_GPB flag? Then this setting can be
> saved in the flags for vxlan_dev and vxlan_sock so no exts field.

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 enabled.

However, we do not want vxlan_find_sock() to compare all flags.

So we need a bitmap that is ignored during the share check (flags) and
a bitmap that must match to allow sharing (exts).

The RCO extension is currently suffering from this bug which is causing
a compatibility issue. I explained in the thread of your patch. I was
under the imrpession that you would either send a v2 or fix it in a
follow-up.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Tom Herbert

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 {
>> > __u8  tos;  /* TOS override */
>> > __u8  ttl;
>> > u32   flags;/* VXLAN_F_* in vxlan.h */
>> > +   u32   exts; /* Enabled extensions */
>> >
>>
>> Thomas, why not just make a VXAM_F_GPB flag? Then this setting can be
>> saved in the flags for vxlan_dev and vxlan_sock so no exts field.
>
> 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 enabled.
>
> However, we do not want vxlan_find_sock() to compare all flags.
>
> So we need a bitmap that is ignored during the share check (flags) and
> a bitmap that must match to allow sharing (exts).
>
> The RCO extension is currently suffering from this bug which is causing
> a compatibility issue. I explained in the thread of your patch. I was
> under the imrpession that you would either send a v2 or fix it in a
> follow-up.

As I mentioned, we would also need to match receive checksum settings
which is not appropriately called an extension. A mask of interesting
flags could be used to do the comparison in vxlan_find_sock.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovs-numa.h: Add a missing OVS_UNUSED

2015-01-14 Thread YAMAMOTO Takashi

> 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_cores_on_numa':
>> > ../lib/ovs-numa.h:150:33: error: unused parameter 'numa_id'
>> 
>> The problem was introduced by
>> commit 9da2564e2bfa4ffc5a05552630ce2aca00a521c9.
>> ("ovs-numa: Refine the module.")
>> 
>> Signed-off-by: YAMAMOTO Takashi 
> 
> Acked-by: Ben Pfaff 

thank you.  applied.

YAMAMOTO Takashi
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Thomas Graf

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 enabled.
> >
> > However, we do not want vxlan_find_sock() to compare all flags.
> >
> > So we need a bitmap that is ignored during the share check (flags) and
> > a bitmap that must match to allow sharing (exts).
> >
> > The RCO extension is currently suffering from this bug which is causing
> > a compatibility issue. I explained in the thread of your patch. I was
> > under the imrpession that you would either send a v2 or fix it in a
> > follow-up.
> 
> As I mentioned, we would also need to match receive checksum settings
> which is not appropriately called an extension. A mask of interesting
> flags could be used to do the comparison in vxlan_find_sock.

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 updated.

If you need to compare additional receive checksum settings for RCO
then that should be separate because as you say it's not an extension.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread YAMAMOTO Takashi

> 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 uses zookeeper (and cassandra) for similar purposes.
we might want to learn from there.

http://lists.midonet.org/pipermail/midonet-dev/2015-January/000280.html

YAMAMOTO Takashi
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 4/5] openvswitch: Allow for any level of nesting in flow attributes

2015-01-14 Thread Thomas Graf

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
v3->v4:
 - No change. The spotted bug is unrelatd to this series and will be fixed
   in a separate patch
v2->v3:
 - No change
v1->v2:
 - New patch to allow nested Netlink attributes inside
   OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS

 net/openvswitch/flow_netlink.c | 106 ++---
 1 file changed, 56 insertions(+), 50 deletions(-)

diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 2e8a9cd..518941c 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -50,6 +50,13 @@
 
 #include "flow_netlink.h"
 
+struct ovs_len_tbl {
+   int len;
+   const struct ovs_len_tbl *next;
+};
+
+#define OVS_ATTR_NESTED -1
+
 static void update_range(struct sw_flow_match *match,
 size_t offset, size_t size, bool is_mask)
 {
@@ -289,29 +296,44 @@ size_t ovs_key_attr_size(void)
+ nla_total_size(28); /* OVS_KEY_ATTR_ND */
 }
 
+static const struct ovs_len_tbl ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX + 
1] = {
+   [OVS_TUNNEL_KEY_ATTR_ID]= { .len = sizeof(u64) },
+   [OVS_TUNNEL_KEY_ATTR_IPV4_SRC]  = { .len = sizeof(u32) },
+   [OVS_TUNNEL_KEY_ATTR_IPV4_DST]  = { .len = sizeof(u32) },
+   [OVS_TUNNEL_KEY_ATTR_TOS]   = { .len = 1 },
+   [OVS_TUNNEL_KEY_ATTR_TTL]   = { .len = 1 },
+   [OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT] = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_CSUM]  = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_TP_SRC]= { .len = sizeof(u16) },
+   [OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
+   [OVS_TUNNEL_KEY_ATTR_OAM]   = { .len = 0 },
+   [OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS]   = { .len = OVS_ATTR_NESTED },
+};
+
 /* The size of the argument for each %OVS_KEY_ATTR_* Netlink attribute.  */
-static const int ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
-   [OVS_KEY_ATTR_ENCAP] = -1,
-   [OVS_KEY_ATTR_PRIORITY] = sizeof(u32),
-   [OVS_KEY_ATTR_IN_PORT] = sizeof(u32),
-   [OVS_KEY_ATTR_SKB_MARK] = sizeof(u32),
-   [OVS_KEY_ATTR_ETHERNET] = sizeof(struct ovs_key_ethernet),
-   [OVS_KEY_ATTR_VLAN] = sizeof(__be16),
-   [OVS_KEY_ATTR_ETHERTYPE] = sizeof(__be16),
-   [OVS_KEY_ATTR_IPV4] = sizeof(struct ovs_key_ipv4),
-   [OVS_KEY_ATTR_IPV6] = sizeof(struct ovs_key_ipv6),
-   [OVS_KEY_ATTR_TCP] = sizeof(struct ovs_key_tcp),
-   [OVS_KEY_ATTR_TCP_FLAGS] = sizeof(__be16),
-   [OVS_KEY_ATTR_UDP] = sizeof(struct ovs_key_udp),
-   [OVS_KEY_ATTR_SCTP] = sizeof(struct ovs_key_sctp),
-   [OVS_KEY_ATTR_ICMP] = sizeof(struct ovs_key_icmp),
-   [OVS_KEY_ATTR_ICMPV6] = sizeof(struct ovs_key_icmpv6),
-   [OVS_KEY_ATTR_ARP] = sizeof(struct ovs_key_arp),
-   [OVS_KEY_ATTR_ND] = sizeof(struct ovs_key_nd),
-   [OVS_KEY_ATTR_RECIRC_ID] = sizeof(u32),
-   [OVS_KEY_ATTR_DP_HASH] = sizeof(u32),
-   [OVS_KEY_ATTR_TUNNEL] = -1,
-   [OVS_KEY_ATTR_MPLS] = sizeof(struct ovs_key_mpls),
+static const struct ovs_len_tbl ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
+   [OVS_KEY_ATTR_ENCAP] = { .len = OVS_ATTR_NESTED },
+   [OVS_KEY_ATTR_PRIORITY]  = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_IN_PORT]   = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_SKB_MARK]  = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_ETHERNET]  = { .len = sizeof(struct ovs_key_ethernet) },
+   [OVS_KEY_ATTR_VLAN]  = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_ETHERTYPE] = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_IPV4]  = { .len = sizeof(struct ovs_key_ipv4) },
+   [OVS_KEY_ATTR_IPV6]  = { .len = sizeof(struct ovs_key_ipv6) },
+   [OVS_KEY_ATTR_TCP]   = { .len = sizeof(struct ovs_key_tcp) },
+   [OVS_KEY_ATTR_TCP_FLAGS] = { .len = sizeof(__be16) },
+   [OVS_KEY_ATTR_UDP]   = { .len = sizeof(struct ovs_key_udp) },
+   [OVS_KEY_ATTR_SCTP]  = { .len = sizeof(struct ovs_key_sctp) },
+   [OVS_KEY_ATTR_ICMP]  = { .len = sizeof(struct ovs_key_icmp) },
+   [OVS_KEY_ATTR_ICMPV6]= { .len = sizeof(struct ovs_key_icmpv6) },
+   [OVS_KEY_ATTR_ARP]   = { .len = sizeof(struct ovs_key_arp) },
+   [OVS_KEY_ATTR_ND]= { .len = sizeof(struct ovs_key_nd) },
+   [OVS_KEY_ATTR_RECIRC_ID] = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_DP_HASH]   = { .len = sizeof(u32) },
+   [OVS_KEY_ATTR_TUNNEL]= { .len = OVS_ATTR_NESTED,
+.next = ovs_tunnel_key_lens, },
+   [OVS_KEY_ATTR_MPLS]  = { .len = sizeof(struct ovs_key_mpls) },
 };
 
 static bool is_all_zero(const u8 *fp, size_t size)
@@ -352,8 +374,8 @@ static int __parse_flow_nlattrs(const struct nlat

[ovs-dev] [PATCH 2/5] vxlan: Only bind to sockets with compatible flags enabled

2015-01-14 Thread Thomas Graf

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 extensions at this point.

Signed-off-by: Thomas Graf 
---
v5->v6:
 - Keep sharing logic but base it off unsharable flags instead of exts
   member as suggested by Tom
v4->v5:
 - No change
v3->v4:
 - No change
v2->v3:
 - No change
v1->v2:
 - Improved commit message, reported by Jesse

 drivers/net/vxlan.c | 29 ++---
 include/net/vxlan.h |  3 +++
 2 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 6dbf8e0..6b6b456 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -263,15 +263,19 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct 
vxlan_fdb *fdb)
return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
 }
 
-/* Find VXLAN socket based on network namespace, address family and UDP port */
-static struct vxlan_sock *vxlan_find_sock(struct net *net,
- sa_family_t family, __be16 port)
+/* Find VXLAN socket based on network namespace, address family and UDP port
+ * and enabled unshareable flags.
+ */
+static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
+ __be16 port, u32 flags)
 {
struct vxlan_sock *vs;
+   u32 match_flags = flags & VXLAN_F_UNSHAREABLE;
 
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
if (inet_sk(vs->sock->sk)->inet_sport == port &&
-   inet_sk(vs->sock->sk)->sk.sk_family == family)
+   inet_sk(vs->sock->sk)->sk.sk_family == family &&
+   (vs->flags & VXLAN_F_UNSHAREABLE) == match_flags)
return vs;
}
return NULL;
@@ -291,11 +295,12 @@ static struct vxlan_dev *vxlan_vs_find_vni(struct 
vxlan_sock *vs, u32 id)
 
 /* Look up VNI in a per net namespace table */
 static struct vxlan_dev *vxlan_find_vni(struct net *net, u32 id,
-   sa_family_t family, __be16 port)
+   sa_family_t family, __be16 port,
+   u32 flags)
 {
struct vxlan_sock *vs;
 
-   vs = vxlan_find_sock(net, family, port);
+   vs = vxlan_find_sock(net, family, port, flags);
if (!vs)
return NULL;
 
@@ -1957,7 +1962,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
 
ip_rt_put(rt);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
-  dst->sa.sa_family, dst_port);
+  dst->sa.sa_family, dst_port,
+  vxlan->flags);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -2016,7 +2022,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
 
dst_release(ndst);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
-  dst->sa.sa_family, dst_port);
+  dst->sa.sa_family, dst_port,
+  vxlan->flags);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -2186,7 +2193,7 @@ static int vxlan_init(struct net_device *dev)
 
spin_lock(&vn->sock_lock);
vs = vxlan_find_sock(vxlan->net, ipv6 ? AF_INET6 : AF_INET,
-vxlan->dst_port);
+vxlan->dst_port, vxlan->flags);
if (vs && atomic_add_unless(&vs->refcnt, 1, 0)) {
/* If we have a socket with same port already, reuse it */
vxlan_vs_add_dev(vs, vxlan);
@@ -2593,7 +2600,7 @@ struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 
port,
return vs;
 
spin_lock(&vn->sock_lock);
-   vs = vxlan_find_sock(net, ipv6 ? AF_INET6 : AF_INET, port);
+   vs = vxlan_find_sock(net, ipv6 ? AF_INET6 : AF_INET, port, flags);
if (vs && ((vs->rcv != rcv) ||
   !atomic_add_unless(&vs->refcnt, 1, 0)))
vs = ERR_PTR(-EBUSY);
@@ -2761,7 +2768,7 @@ static int vxlan_newlink(struct net *net, struct 
net_device *dev,
vxlan->flags |= VXLAN_F_GBP;
 
if (vxlan_find_vni(net, vni, use_ipv6 ? AF_INET6 : AF_INET,
-  vxlan->dst_port)) {
+  vxlan->dst_port, vxlan->flags)) {

[ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread 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 implement ACLs directly with nftables, iptables, OVS,
tc, etc.

The group membership is defined by the lower 16 bits of skb->mark, the
upper 16 bits are used for flags.

SELinux allows to manage label to secure local resources. However,
distributed applications require ACLs to implemented across hosts. This
is typically achieved by matching on L2-L4 fields to identify the
original sending host and process on the receiver. On top of that,
netlabel and specifically CIPSO [1] allow to map security contexts to
universal labels.  However, netlabel and CIPSO are relatively complex.
This patch provides a lightweight alternative for overlay network
environments with a trusted underlay. No additional control protocol
is required.

   Host 1:   Host 2:

  Group AGroup BGroup B Group A
  +-+   +-++---+   +-+
  | lxc |   | SELinux CTX || httpd |   | VM  |
  +--+--+   +--+--++---+---+   +--+--+
  \---+---/ \+---/
  |  |
  +---+---+  +---+---+
  | vxlan |  | vxlan |
  +---+---+  +---+---+
  +--+

Backwards compatibility:
A VXLAN-GBP socket can receive standard VXLAN frames and will assign
the default group 0x to such frames. A Linux VXLAN socket will
drop VXLAN-GBP  frames. The extension is therefore disabled by default
and needs to be specifically enabled:

   ip link add [...] type vxlan [...] gbp

In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
must run on a separate port number.

Examples:
 iptables:
  host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
  host2# iptables -I INPUT -m mark --mark 0x200 -j DROP

 OVS:
  # ovs-ofctl add-flow br0 
'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
  # ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'

[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] http://lwn.net/Articles/204905/

Signed-off-by: Thomas Graf 
---
v5->v6:
 - Use flags instead of exts member to store enablement of GBP as suggested
   by Tom
v4->v5:
 - Rebased on top of Tom's RCO work
 - Dropped IFLA_VXLAN_EXTENSION container attribute and embedded IFLA_VXLAN_GBP
   as top level VXLAN attribute like RCO for consistency. 
v3->v4:
 - Patch 1 was no longer needed due to Tom Herbert's 3bf394 ("vxlan: Improve
   support for header flags"). Moved remaining header description to this patch.
 - Zero out vxlan_metadata in vxlan_tnl_send() as suggested by Jesse.
 - Reported enabled extensions to user space as requested by Nicolas.
 - Use VXLAN_HF_GBP instead of bitfield to be in line with Tom's work.
v2->v3:
 - Removed empty struct vxlan_gbp as spotted by Alexei
v1->v2:
 - split GBP header definition into separate struct vxlanhdr_gbp as requested
   by Alexei

 drivers/net/vxlan.c   | 84 ---
 include/net/vxlan.h   | 79 +---
 include/uapi/linux/if_link.h  |  1 +
 net/openvswitch/vport-vxlan.c |  9 +++--
 4 files changed, 152 insertions(+), 21 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 99df0d7..6dbf8e0 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -620,7 +620,8 @@ static struct sk_buff **vxlan_gro_receive(struct sk_buff 
**head,
continue;
 
vh2 = (struct vxlanhdr *)(p->data + off_vx);
-   if (vh->vx_vni != vh2->vx_vni) {
+   if (vh->vx_flags != vh2->vx_flags ||
+   vh->vx_vni != vh2->vx_vni) {
NAPI_GRO_CB(p)->same_flow = 0;
continue;
}
@@ -1183,6 +1184,7 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
struct vxlan_sock *vs;
struct vxlanhdr *vxh;
u32 flags, vni;
+   struct vxlan_metadata md = {0};
 
/* Need Vxlan and inner Ethernet header to be present */
if (!pskb_may_pull(skb, VXLAN_HLEN))
@@ -1216,6 +1218,24 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
vni &= VXLAN_VID_MASK;
}
 
+   /* For backwards compatibility, only allow reserved fields to be
+* used by VXLAN extensions if explicitly requested.
+*/
+   if ((flags & VXLAN_HF_GBP) && (vs->flags & VXLAN_F_GBP)) {
+   struct vxlanhdr_gbp *gbp;
+
+   gbp = (struct vxlanhdr_gbp *)vxh;
+   md.gbp = ntohs(gbp->policy_id);
+
+

[ovs-dev] [PATCH 3/5] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()

2015-01-14 Thread Thomas Graf

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 
---
v5->v6:
 - No change
v4->v5:
 - No change
v3->v4:
 - Renamed validate_and_copy_geneve_opts() to validate_geneve_opts() as
   suggested by Jesse
v2->v3:
 - No change
v1->v2:
 - Don't rename genev_tun_opt_from_nlattr() and keep it Geneve specific,
   pointed out by Jesse.
 - Factor out Geneve specific validation code into separate function as
   requested by Jesse.

 net/openvswitch/flow.c |  2 +-
 net/openvswitch/flow.h | 14 
 net/openvswitch/flow_netlink.c | 72 +++---
 3 files changed, 47 insertions(+), 41 deletions(-)

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index df334fe..e2c348b 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -691,7 +691,7 @@ int ovs_flow_key_extract(const struct ovs_tunnel_info 
*tun_info,
BUILD_BUG_ON((1 << (sizeof(tun_info->options_len) *
   8)) - 1
> sizeof(key->tun_opts));
-   memcpy(GENEVE_OPTS(key, tun_info->options_len),
+   memcpy(TUN_METADATA_OPTS(key, tun_info->options_len),
   tun_info->options, tun_info->options_len);
key->tun_opts_len = tun_info->options_len;
} else {
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index a8b30f3..d3d0a40 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -53,7 +53,7 @@ struct ovs_key_ipv4_tunnel {
 
 struct ovs_tunnel_info {
struct ovs_key_ipv4_tunnel tunnel;
-   const struct geneve_opt *options;
+   const void *options;
u8 options_len;
 };
 
@@ -61,10 +61,10 @@ struct ovs_tunnel_info {
  * maximum size. This allows us to get the benefits of variable length
  * matching for small options.
  */
-#define GENEVE_OPTS(flow_key, opt_len) \
-   ((struct geneve_opt *)((flow_key)->tun_opts + \
-  FIELD_SIZEOF(struct sw_flow_key, tun_opts) - \
-  opt_len))
+#define TUN_METADATA_OFFSET(opt_len) \
+   (FIELD_SIZEOF(struct sw_flow_key, tun_opts) - opt_len)
+#define TUN_METADATA_OPTS(flow_key, opt_len) \
+   ((void *)((flow_key)->tun_opts + TUN_METADATA_OFFSET(opt_len)))
 
 static inline void __ovs_flow_tun_info_init(struct ovs_tunnel_info *tun_info,
__be32 saddr, __be32 daddr,
@@ -73,7 +73,7 @@ static inline void __ovs_flow_tun_info_init(struct 
ovs_tunnel_info *tun_info,
__be16 tp_dst,
__be64 tun_id,
__be16 tun_flags,
-   const struct geneve_opt *opts,
+   const void *opts,
u8 opts_len)
 {
tun_info->tunnel.tun_id = tun_id;
@@ -105,7 +105,7 @@ static inline void ovs_flow_tun_info_init(struct 
ovs_tunnel_info *tun_info,
  __be16 tp_dst,
  __be64 tun_id,
  __be16 tun_flags,
- const struct geneve_opt *opts,
+ const void *opts,
  u8 opts_len)
 {
__ovs_flow_tun_info_init(tun_info, iph->saddr, iph->daddr,
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index d1eecf7..2e8a9cd 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -432,8 +432,7 @@ static int genev_tun_opt_from_nlattr(const struct nlattr *a,
SW_FLOW_KEY_PUT(match, tun_opts_len, 0xff, true);
}
 
-   opt_key_offset = (unsigned long)GENEVE_OPTS((struct sw_flow_key *)0,
-   nla_len(a));
+   opt_key_offset = TUN_METADATA_OFFSET(nla_len(a));
SW_FLOW_KEY_MEMCPY_OFFSET(match, opt_key_offset, nla_data(a),
  nla_len(a), is_mask);
return 0;
@@ -558,8 +557,7 @@ static int ipv4_tun_from_nlattr(const struct nlattr *attr,
 
 static int __ipv4_tun_to_nlattr(struct sk_buff *skb,
const struct ovs_key_ipv4_tunnel *output,
-   const struct geneve_opt *tun_opts,
-   int swkey_tun_opts_len)
+   const void *tun_opts, int swkey_tun_opts_len)
 {
if (output->tun_flags & TUNNEL_KEY &&
nla_put_be64(skb, OVS_TUNNEL_KEY_ATTR_ID, outp

[ovs-dev] [PATCH 0/5 net-next v6] VXLAN Group Policy Extension

2015-01-14 Thread 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 implement ACLs directly with nftables, iptables, OVS,
tc, etc.

The extension is disabled by default and should be run on a distinct
port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
which ignore unknown reserved bits will be able to receive VXLAN-GBP
frames.

Simple usage example:

10.1.1.1:
   # ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp
   # iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200

10.1.1.2:
   # ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp
   # iptables -I INPUT -m mark --mark 0x200 -j DROP

iproute2 [1] and OVS [2] support will be provided in separate patches.

[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] https://github.com/tgraf/iproute2/tree/vxlan-gbp
[2] https://github.com/tgraf/ovs/tree/vxlan-gbp

Thomas Graf (5):
  vxlan: Group Policy extension
  vxlan: Only bind to sockets with compatible flags enabled
  openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
  openvswitch: Allow for any level of nesting in flow attributes
  openvswitch: Support VXLAN Group Policy extension

 drivers/net/vxlan.c  | 113 
 include/net/ip_tunnels.h |   5 +-
 include/net/vxlan.h  |  82 ++-
 include/uapi/linux/if_link.h |   1 +
 include/uapi/linux/openvswitch.h |  11 ++
 net/openvswitch/flow.c   |   2 +-
 net/openvswitch/flow.h   |  14 +-
 net/openvswitch/flow_netlink.c   | 286 ++-
 net/openvswitch/vport-geneve.c   |  15 +-
 net/openvswitch/vport-vxlan.c|  91 -
 net/openvswitch/vport-vxlan.h|  11 ++
 11 files changed, 491 insertions(+), 140 deletions(-)
 create mode 100644 net/openvswitch/vport-vxlan.h

-- 
1.9.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 5/5] openvswitch: Support VXLAN Group Policy extension

2015-01-14 Thread 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 interface to enable the extension is based on a new
attribute OVS_VXLAN_EXT_GBP nested inside OVS_TUNNEL_ATTR_EXTENSION
which can carry additional extensions as needed in the future.

The group policy metadata is stored as binary blob (struct ovs_vxlan_opts)
internally just like Geneve options but transported as nested Netlink
attributes to user space.

Renames the existing TUNNEL_OPTIONS_PRESENT to TUNNEL_GENEVE_OPT with the
binary value kept intact, a new flag TUNNEL_VXLAN_OPT is introduced.

The attributes OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS and existing
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS are implemented mutually exclusive.

Signed-off-by: Thomas Graf 
---
v5->v6:
 - No change
v4->v5:
 - No change
v3->v4:
 - Fixed OVS_VXLAN_EXT_MAX->OVS_VXLAN_EXT_GBP typo as spotted by Jesse
 - Only applied tunnel options if they are of the right type as
   suggested by Jesse
v2->v3:
 - No change
v1->v2:
 - Addressed Jesse's request to transport VXLAN options as Netlink
   attributes instead of a binary blob. Allows a partial transport of
   VXLAN extensions. Internally, the datapath continues to use a binary
   blob (defined in vport-vxlan.h) for performance reasons.
 - Added new TUNNEL_GENEVE_OPT and TUNNEL_VXLAN_OPT flags to mark
   tunnel option flavour
 - Correctly report VXLAN options to user space

 include/net/ip_tunnels.h |   5 +-
 include/uapi/linux/openvswitch.h |  11 
 net/openvswitch/flow_netlink.c   | 114 ++-
 net/openvswitch/vport-geneve.c   |  15 --
 net/openvswitch/vport-vxlan.c|  82 +++-
 net/openvswitch/vport-vxlan.h|  11 
 6 files changed, 218 insertions(+), 20 deletions(-)
 create mode 100644 net/openvswitch/vport-vxlan.h

diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 25a59eb..ce4db3c 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -97,7 +97,10 @@ struct ip_tunnel {
 #define TUNNEL_DONT_FRAGMENT__cpu_to_be16(0x0100)
 #define TUNNEL_OAM __cpu_to_be16(0x0200)
 #define TUNNEL_CRIT_OPT__cpu_to_be16(0x0400)
-#define TUNNEL_OPTIONS_PRESENT __cpu_to_be16(0x0800)
+#define TUNNEL_GENEVE_OPT  __cpu_to_be16(0x0800)
+#define TUNNEL_VXLAN_OPT   __cpu_to_be16(0x1000)
+
+#define TUNNEL_OPTIONS_PRESENT (TUNNEL_GENEVE_OPT | TUNNEL_VXLAN_OPT)
 
 struct tnl_ptk_info {
__be16 flags;
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 3a6dcaa..e474c95 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -248,11 +248,21 @@ enum ovs_vport_attr {
 
 #define OVS_VPORT_ATTR_MAX (__OVS_VPORT_ATTR_MAX - 1)
 
+enum {
+   OVS_VXLAN_EXT_UNSPEC,
+   OVS_VXLAN_EXT_GBP,  /* Flag or __u32 */
+   __OVS_VXLAN_EXT_MAX,
+};
+
+#define OVS_VXLAN_EXT_MAX (__OVS_VXLAN_EXT_MAX - 1)
+
+
 /* OVS_VPORT_ATTR_OPTIONS attributes for tunnels.
  */
 enum {
OVS_TUNNEL_ATTR_UNSPEC,
OVS_TUNNEL_ATTR_DST_PORT, /* 16-bit UDP port, used by L4 tunnels. */
+   OVS_TUNNEL_ATTR_EXTENSION,
__OVS_TUNNEL_ATTR_MAX
 };
 
@@ -324,6 +334,7 @@ enum ovs_tunnel_key_attr {
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS,/* Array of Geneve options. */
OVS_TUNNEL_KEY_ATTR_TP_SRC, /* be16 src Transport Port. */
OVS_TUNNEL_KEY_ATTR_TP_DST, /* be16 dst Transport Port. */
+   OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS, /* Nested OVS_VXLAN_EXT_* */
__OVS_TUNNEL_KEY_ATTR_MAX
 };
 
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 518941c..d210d1b 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -49,6 +49,7 @@
 #include 
 
 #include "flow_netlink.h"
+#include "vport-vxlan.h"
 
 struct ovs_len_tbl {
int len;
@@ -268,6 +269,9 @@ size_t ovs_tun_key_attr_size(void)
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_CSUM */
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_OAM */
+ nla_total_size(256)  /* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS */
+   /* OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS is mutually exclusive with
+* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS and covered by it.
+*/
+ nla_total_size(2)/* OVS_TUNNEL_KEY_ATTR_TP_SRC */
+ nla_total_size(2);   /* OVS_TUNNEL_KEY_ATTR_TP_DST */
 }
@@ -308,6 +312,7 @@ static const struct ovs_len_tbl 
ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX + 1]
[OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
[OVS_TUNNEL_KEY_ATTR_OAM]   = { .len = 0 },
[OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS]   = { .len = OVS_ATTR_NESTED },

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Thomas Graf

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 updated.
> 
> If you need to compare additional receive checksum settings for RCO
> then that should be separate because as you say it's not an extension.

Tom,

OK. I have changed it to use flags instead of exts in v6. You should
be able to add whatever RCO flags need to be matched in
vxlan_find_sock() to the VXLAN_F_UNSHAREABLE bitmask.

Hope this makes everybody happy ;-)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Tom Herbert

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 an additional
>> bitmask which can be forgotten to be updated.
>>
>> If you need to compare additional receive checksum settings for RCO
>> then that should be separate because as you say it's not an extension.
>
> Tom,
>
> OK. I have changed it to use flags instead of exts in v6. You should
> be able to add whatever RCO flags need to be matched in
> vxlan_find_sock() to the VXLAN_F_UNSHAREABLE bitmask.
>
> Hope this makes everybody happy ;-)

Awesome. Thanks!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Tom Herbert

> +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/listinfo/dev

Re: [ovs-dev] [PATCH 1/5] vxlan: Group Policy extension

2015-01-14 Thread Thomas Graf

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 with skb->mark and converted to network byte order on
the wire, see:

gbp = (struct vxlanhdr_gbp *)vxh;
md.gbp = ntohs(gbp->policy_id);

and:

gbp->policy_id = htons(md->gbp & VXLAN_GBP_ID_MASK);
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread Ben Pfaff

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 vSwitch team is pleased to announce OVN, a new subproject in
> > > development within the Open vSwitch.  The full project announcement is
> > > at Network Heresy and reproduced at:
> > >
> > > http://openvswitch.org/pipermail/dev/2015-January/050379.html
> > >
> > > OVN complements the existing capabilities of OVS to add native support
> > > for virtual network abstractions, such as virtual L2 and L3 overlays
> > > and security groups.  Just like OVS, our design goal is to have a
> > > production-quality implementation that can operate at significant
> > > scale.  This post outlines the proposed high level architecture for
> > > OVN.
> >
> > I obviously absolutely love this. I will provide my thoughts over
> > the next days.
> >
> > ++, same here.
> 
> One question I had at this point: Any thoughts as to the language we'll
> choose to write OVN in? I ask because on the OpenStack side, there has been
> interest in writing something like OVN in Python, so there may be some
> developers we could pickup from there.
> 
> Regardless, this is really cool and I'm excited to see this happen!

On the OpenStack side the plugin will inevitably have to be written in
Python as I understand it.  I lean toward C for everywhere that it's
reasonable though, because the developers and the infrastructure we
already have are very much C-oriented.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread Ben Pfaff

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/tree/stable/juno/neutron/plugins/ofagent

I didn't know that there was an existing local controller.  I'll learn
something about the design.

> > OVN database
> > 
> 
> midonet uses zookeeper (and cassandra) for similar purposes.
> we might want to learn from there.
> 
> http://lists.midonet.org/pipermail/midonet-dev/2015-January/000280.html

Thanks for the info!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread Ben Pfaff

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
> > conntrack
> 
> In particular how this can be tied into bidirectional ACLs.

Conntrack is especially problematic given that it's not in OVS yet ;-)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] configure.ac: Enable 'tar-ustar' by default

2015-01-14 Thread Ben Pfaff

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 unable
> > to run 'make dist' (without manual patching) in the interim? Based on my
> > conversation with Eric, it looks like this is something that could be
> > changed in a future Automake version but that could be months (or years
> > :eek:) away. Additionally, there doesn't seem to be anyway to change that
> > setting at compile time (which would be the preferred option).
> > 
> > BTW ustar is not really a solution to large UID/GID problems either, see
> > https://lists.gnu.org/archive/html/automake/2013-02/msg00075.html
> > 
> > Ever since that patch went in, tar-ustar is no longer usable for users
> > with 32bit UID/GID (such as typically created by FreeIPA at least). I'd
> > suggest going directly to tar-pax instead, compatibility shouldn't be an
> > issue since OVS doesn't target antique commercial unixen anyway.
> > 
> > - Panu -
> 
> Ah...interesting. If Mr. Lattarini is to be believed, this change
> should have been in Automake 1.13.2, yet I'm using 1.13.4 and see no
> such issues (I haven't checked the Automake source to find the exact
> merge commit yet). Nonetheless, 'tar-pax' works fine for me and I'd be
> happy to submit an update using that format, assuming lack of support
> in those older Unixes is truly irrelevant.

After following this discussion I'd be happy to accept a patch against
Open vSwitch to use "tar-pax" format.

Stephen, thanks for all the followup.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/5 net-next v6] VXLAN Group Policy Extension

2015-01-14 Thread David Miller

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. This allows further mapping to a SELinux context
> using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> tc, etc.
> 
> The extension is disabled by default and should be run on a distinct
> port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
> which ignore unknown reserved bits will be able to receive VXLAN-GBP
> frames.
> 
> Simple usage example:
> 
> 10.1.1.1:
># ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp
># iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
> 
> 10.1.1.2:
># ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp
># iptables -I INPUT -m mark --mark 0x200 -j DROP
> 
> iproute2 [1] and OVS [2] support will be provided in separate patches.
> 
> [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
> [1] https://github.com/tgraf/iproute2/tree/vxlan-gbp
> [2] https://github.com/tgraf/ovs/tree/vxlan-gbp

Applied, thanks a lot Thomas.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN architecture

2015-01-14 Thread YAMAMOTO Takashi

> 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/tree/stable/juno/neutron/plugins/ofagent
> 
> I didn't know that there was an existing local controller.  I'll learn
> something about the design.

similar:

- it's a local OpenFlow controller running on each nodes

- it has ARP suppression feature implemented with packet-ins
  (called "local arp responder" there)

different:

- ofagent doesn't have a layer equivalent to "OVN database".
  it obtains the necessary info from its CMS (neutron) directly.

YAMAMOTO Takashi
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

61 matches

Mail list logo