RFC EOIP Tunnel

RFC EOIP Tunnel

[Boian Bonev]

Hi,

EOIP is a proprietary ethernet over IP tunneling protocol introduced
by MikroTik's commercial product RouterOS. It uses GRE as protocol id
but with non-standard header.

Unlike EtherIP (RFC 3378) that is documented but not used, EOIP is not
documented but used for transparent Layer2 over wireless links and in
providing Layer2 services through multiple management domain networks
where pure L2 is as hard as near to impossible.

Long story short: my primary motivation behind doing this work was to
reduce the number of points of failure in a Linux+RouterOS and many
RouterOS endpoints setup. Old RouterOS endpoints do not support any
standard ethernet tunneling (upgrading is not an option) while Linux
does not support the EOIP protocol. On the other hand RouterOS cannot
be as flexible as Linux can be for routing and magic.

Judging from the existence of at least two separate opensource
projects doing this tunneling in userspace
(https://github.com/katuma/eoip and
https://code.google.com/p/linux-eoip/) I believe that this will be
useful for people using Linux in networked setups.

Before going in technical details and submitting patches I want to
know opinions if this work is suitable for merging upstream or is
better to be kept as a side kernel patch project.

With best regards,
b.

ps. https://github.com/bbonev/eoip contains 3.2.x patches + somehow
working but quite crappy config tool

Re: RFC EOIP Tunnel

[Hannes Frederic Sowa]

On Sun, May 19, 2013 at 06:31:40PM +0300, Boian Bonev wrote:
> EOIP is a proprietary ethernet over IP tunneling protocol introduced
> by MikroTik's commercial product RouterOS. It uses GRE as protocol id
> but with non-standard header.

Actually, I does get used in BSD land. I have seen several setups some time
ago where gif interfaces got added to a bridge interface, which behaves like
EtherIP then. Prior to FreeBSD 8 they reversed the bytes of the version field
so they still have to provide knobs for backwards compatibility.

> Before going in technical details and submitting patches I want to
> know opinions if this work is suitable for merging upstream or is
> better to be kept as a side kernel patch project.

If the side kernel patch has matured and you are fine with it just propose it
to get merged.

> ps. https://github.com/bbonev/eoip contains 3.2.x patches + somehow
> working but quite crappy config tool

Configuration should be done by iproute.

Greetings,

  Hannes

Re: RFC EOIP Tunnel

[Boian Bonev]

Hi,

> Actually, I does get used in BSD land. I have seen several setups some time
> ago where gif interfaces got added to a bridge interface, which behaves like
> EtherIP then. Prior to FreeBSD 8 they reversed the bytes of the version field
> so they still have to provide knobs for backwards compatibility.

In FreeBSD the same thing is implemented as netgraph node...

>> Before going in technical details and submitting patches I want to
>> know opinions if this work is suitable for merging upstream or is
>> better to be kept as a side kernel patch project.
>
> If the side kernel patch has matured and you are fine with it just propose it
> to get merged.

It is mature enough for the 3.2 series kernels (but obviously this is
not ok for submitting). Since then tunnels have got refactored to have
common code in a single place used by all tunnels and also GRE GSO
support was added. I am not very confident if I can get the GSO part
the right way and properly test it...

Thanks for the pointers - will follow your advice and submit a patch.

>> ps. https://github.com/bbonev/eoip contains 3.2.x patches + somehow
>> working but quite crappy config tool
>
> Configuration should be done by iproute.

This is my plan. The config tool is more like a proof of concept thing.

With best regards,
b.

Re: RFC EOIP Tunnel

[Stephen Hemminger]

Rather than burdening the kernel maintainers with a proprietary
protocol that is non-standard. Why not just clean up the user space
implementation, and use tun like OpenVPN etc.

IMHO Mikrotik is violating GPL by having modules that claim to be GPL
and not releasing source. Plus modifying GRUB to do license
enforcement violates the intent of GPL as well.


On Tue, May 21, 2013 at 5:29 PM, Boian Bonev <bbonev@ipacct.com> wrote:
> Hi,
>
>> Actually, I does get used in BSD land. I have seen several setups some time
>> ago where gif interfaces got added to a bridge interface, which behaves like
>> EtherIP then. Prior to FreeBSD 8 they reversed the bytes of the version field
>> so they still have to provide knobs for backwards compatibility.
>
> In FreeBSD the same thing is implemented as netgraph node...
>
>>> Before going in technical details and submitting patches I want to
>>> know opinions if this work is suitable for merging upstream or is
>>> better to be kept as a side kernel patch project.
>>
>> If the side kernel patch has matured and you are fine with it just propose it
>> to get merged.
>
> It is mature enough for the 3.2 series kernels (but obviously this is
> not ok for submitting). Since then tunnels have got refactored to have
> common code in a single place used by all tunnels and also GRE GSO
> support was added. I am not very confident if I can get the GSO part
> the right way and properly test it...
>
> Thanks for the pointers - will follow your advice and submit a patch.
>
>>> ps. https://github.com/bbonev/eoip contains 3.2.x patches + somehow
>>> working but quite crappy config tool
>>
>> Configuration should be done by iproute.
>
> This is my plan. The config tool is more like a proof of concept thing.
>
> With best regards,
> b.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html