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