Hi Thomas, On 4/11/14, 4:24 PM, thomas.mo...@orange.com wrote:
Hi Lori,I've ported my GRE patches to your l3port patches. You can find my changes at: https://github.com/tmmorin/openvswitch/tree/l3_v3_gre
Great! Always good to see one's work being useful to others. Also, it looks like it doesn't need may lines of code to enable L3 GRE!
The result is the following: - an option is added to GRE tunnel port, to allow making them OVS l3ports
My first impression is that starting with my patches and now yours there are a lot of different places with is_layer3 or l3port type of bool members, but I don't really have a more elegant proposal either.
- the vport-gre.c code is adapted to treat GRE ethertype consistently with the type of the port (i.e. on emission the GRE ethertype is chosen based on whether or not the skb is layer3; symmetrically on reception) I also adapted pop_eth code, so that it strips the Ethernet and VLAN headers, but not the MPLS headers if there is any (I only modified the linux kernel datapath actions, the userland datapath I left untouched for now).
This is an issue for LISP, since it cannot have MPLS headers in the encapsulated packets. I see two solutions: 1) add an option to the pop_eth action to specify if MPLS header(s) should stay there; or 2) or just use pop_eth() as is and add push_mpls() actions to push the MPLS headers back (they should be saved somehow).
Or maybe there's a better solution, I'll let the core developers to voice their opinions.
I would welcome feedback on this proposal.
In general it looks good to me, but I'm pretty much an OVS n00b, so I think you should post an RFC patch at this point to the mailing list (saying that your work depends on my patches) and you'll likely get more feedback. I hope I'll be able to post v3 of my patches next week.
-Lori
Thank you, -Thomas 2014-02-27, Lori Jakab:Hi Thomas, I'm the original contributor of the LISP tunneling code. Since it was originally accepted, I have been working on a series of patches to enable more generic support for layer 3 packets in OVS. While I was doint it with LISP in mind, I did consider enabling IP-over-GRE at some point. It's great that you're interested in this too! Instead of this patch, would you consider implementing IP-over-GRE support based on my patch series? I will soon post a v3 of it for review, but you can always find the lastest version in my Github repo: https://github.com/ljakab/openvswitch/tree/l3 HTH, -Lori On 2/27/14, 7:16 PM, thomas.mo...@orange.com wrote:Hello, Currently, OVS GRE tunnels use Ethertype 6558 and the GRE packets produced by OVS hence always are xxx-over-Ethernet-over-GRE. Symmetrically OVS expects received GRE packets to be of the same ethertype and carry an Ethernet payload. I have written the included patch, which does the following: - add a "noeth" option for a GRE tunnel, so that the Ethernet header is stripped before GRE encapsulation (the option, of course, defaults to the current behavior) - on reception, recreates a fake Ethernet header if the ethertype of the received packet is not 6558 -- this behavior is similar to what the LISP tunneling code does Note that, in both cases, the code takes care of preserving correct ethertypes. As a result, this patch allows to setup GRE tunnels to interconnect OVS with network devices doing a usual x-over-GRE approach such as IP/MPLS routers. The patch builds and passes unit tests. It has been tested to confirm with a packet capture that: - with the option set on a tunnel, the GRE packets from this tunnel are send and received as expected - for a tunnel without this option, or we the option disabled, the current behavior is preserved Caveats: - documentation and unit test are missing, but I'll be happy to contribute these later - I not an experimented C coder, please be kind :) - some parts of the code are a bit of a guess work from me: I'm unsure of what needs to be done for GSO (possibly it can be done later?), or if re-checksumming is really needed after recreating a fake Ethernet header I'd be happy to have comments on the approach and on the patch and to take them into account. Thank you, -Thomas datapath/datapath.c | 1 datapath/flow_netlink.c | 7 +++ datapath/linux/compat/include/net/gre.h | 4 + datapath/linux/compat/include/net/ip_tunnels.h | 1 datapath/vport-gre.c | 57 ++++++++++++++++++++++++- include/linux/openvswitch.h | 1 lib/flow.c | 2 lib/flow.h | 1 lib/netdev-vport.c | 9 +++ lib/netdev.h | 1 lib/odp-util.c | 11 ++++ lib/odp-util.h | 3 - ofproto/tunnel.c | 7 ++- 13 files changed, 101 insertions(+), 4 deletions(-) _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
