netdev
[Top] [All Lists]

GRE Ethernet tunneling

To: netdev@xxxxxxxxxxx
Subject: GRE Ethernet tunneling
From: Boian Bonev <boian@xxxxxxxxx>
Date: Wed, 9 Mar 2005 10:15:01 +0200
Sender: netdev-bounce@xxxxxxxxxxx
hi,

first to explain why i need to make this stuff in kernel space:
 - userland ethernet tunneling provides more features like encryption but not 
high performance and low latency
 - low MHz cpus choke on high traffic with userland tunnels (have a look at 
WRAP boards at www.pcengines.ch)
 - since we have many setups with 802.11a cards and 802.11a protocol does not 
support direct bridging of interfaces the lack of kernel ethernet tunnel limits 
linux use in this area

btw. mikrotik (www.mikrotik.com - a linux based closed source router os) 
implements a tunnel called eoip the gre way
btw2. 802.11a cards support mtus over 1500 so at least software fragmentation 
may be avoided. i am not sure what happens at lower layers but it performs 
without much cpu usage increase or speed loss

before writing here i have made a concept proof - i cloned the ip_gre.c module 
and changed:
 - device creation to be ethernet alike (mtu 1500, ARPHRD_ETHER, hard_header, 
etc)
 - the protocol to be IPPROTO_GRE+1 (just for testing - not to interferre with 
existing gre tunnels)
 - removed all code that mangled ttl, ecn, mtu etc
 - GRE protocol to 0x6558 (Ethernet over GRE)

then i dirty patched iproute to manage the new interfaces and here i discovered 
something not very clean in interface management by iproute - when listing 
interfaces iproute performs a SIOCGIFHWADDR and checks for ARPHRD_TUNNEL... 
this may be clean for ip tunnels but it cant work for ethernet tunnels.

now i am looking for a clean way to identify ethernet tunnels in iproute:
 - if i change the type to APRHRD_TUNNEL this will break consistency with both 
userland utils and kernel side.
 - SIOCDEVPRIVATE + x is not appropriate because it may conflict with some real 
ethernet device
 - dev->flags are all defined
 - dev->priv_flags in not visible in userspace

i need help to choose a clean and consistent strategy for iproute <---> kernel 
comm
then i will be able to integrate my concept proof code into ip_gre.c

another thing that comes to mind is to implement a small subset ot ethtool 
ioctls but this does not seem consistent to me...

b.
<Prev in Thread] Current Thread [Next in Thread>
  • GRE Ethernet tunneling, Boian Bonev <=