linux-kernel - Re: [patch v7, kernel version 3.2.1] net/ipv4/ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Feb 2012 00:32:04 +0100
From:	Štefan Gula <steweg@...t.sk>
To:	David Miller <davem@...emloft.net>
Cc:	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch v7, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet
 multipoint GRE over IP

2012/1/31 David Miller <davem@...emloft.net>:
> From: Stefan Gula <steweg@...t.sk>
> Date: Tue, 31 Jan 2012 14:21:51 +0100 (CET)
>
>>   - neither NVGRE nor VXLAN are part of the openvswitch for now
>
> Too bad, it means we'll have this new user API of your's so when
> openvswitch does add the necessary code we CANNOT REMOVE your stuff.
>
> I'm not applying this until you at least attempt an openvswitch
> version, and that's basically the end of this discussion.
I actually tried to deploy it on one of my linux based APs. And that's
when I realize that openvswitch have several limitations why I cannot
use it in my scenario on it's own. I tried to put only standard one
point-to-point GRE tunnel from openvswitch without any modifications
of my own and find out that it will never work ok as it is missing the
security parts (ebtables/arptables/iptables), so in my scenario I end
up with original bridge for security and openvswitch bridge with
opevswitch gre tunnel, all linked together by veth link. Result of
performance was that (veth code + openswitch bridge + openvswitch gre
code) was worse than using only my gretap code. On the other hand if I
omit the fact about the missing the security features (omitting also
use of the original bridge code), then the result was in favor of
openvswitch (that's the same result as Joseph provided).

About the new API. Openvswitch is using it's own GRE code, with it's
own API. So if the finally NVGRE or VXLAN will be added to
openvswitch,it doesn't breaks anything to leave also my API as is. For
those who will be using my API in that time, they could consider
migrations of their scripts from standard bridge based code with
gretap interfaces towards openvswitch with NVGRE code or VXLAN code
instead. Until that time they can consider using bridge code with
gretap interfaces or openvswitch code with the same gretap interfaces
=> both switches can benefit from it. So no harm done on this side -
maybe I am not seeing something that you do, am I?

About the porting of my code into openvswitch directly. I believe that
developing/porting something, that will be most probably replaced
eventually with something based on RFC standards like NVGRE, which is
still in progress of developing, and cannot be really used in managed
networks, like my own, at all due other missing features, is a huge
waste of anybody's time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/