[ovs-dev] adding an option for GRE tunneling without an Ethernet header

thomas.morin at orange.com thomas.morin at orange.com
Fri Apr 11 13:24:01 UTC 2014


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

The result is the following:
- an option is added to GRE tunnel port, to allow making them OVS l3ports
- 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).

I would welcome feedback on this proposal.

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.morin at 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 at 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.



More information about the dev mailing list