[lime-dev] BMX features Was: magic icmp

Axel Neumann neumann at cgws.de
Sun May 19 16:44:09 UTC 2013


On 05/17/2013 11:13 AM, Gioacchino Mazzurco wrote:
> On Thursday 16 May 2013 10:45:10 Gioacchino Mazzurco wrote:
>>> 2) to support virtual (overlay) links on top of an existing network by
>>> specifying a remote ip address instead of a interface for meshing.
>>> This way, it would be easily possible to interconnect clouds that have
>>> no direct link between each other (eg over the internet, similar to what
>>> tinc or other VPNs are doing).
>> This would be very good and give to bmx6 a lot of advantages in respect to
>> other routing protocol :D
> This would also save per packet overhead due to the elimination of the VPN (
> tinc for example ) in the middle, this also mean less MTU problem, definely we
> want this :D

hehe, dont be over optimistic.
it'll be another end-to-end tunnel between the ip addresses of two bmx6 
instances with a reduced MTU for all data traversing this virtual link.
Therefore one reason is to react on ICMP MTU exceeded messages which 
should then trigger bmx6 to reduce the MTU of the related incoming 
interfaces.
Anyway, its just an idea yet and I think it doesnt make sense to discuss 
such details before a general design of the concept is available.


Regarding the other question, why libpcap and not ICMP.
Currently the linux kernel silently drops incoming tunnel (ipip) packets 
unless a corresponding tunnel interface with proper local and remote 
addresses already exists.
But with the automatic bidirectional tunnel setup I want to achieve that 
these tunnel interfaces would be setup as a reaction on receiving such 
ipip packets.
Libpcap could be used to deliver this packets to the bmx6 process. Bmx6 
then creates the needed tunnel interface (with proper local/remote 
addresses) and pops the packet back into the linux kernel. I dont know 
any alternative way to easily capture such packets.

And another advantage for using libpcap instead of user space RAW 
sockets is that with libpcap you could already filter for the desired 
packets in kernel space
so that your user space process would not be loaded with all the 
uniteresting ICMP packets (think of a ping flood).


/axel



More information about the lime-dev mailing list