Re: tunneling and iptables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mer 10/03/2004 à 10:38, Hitesh Ballani a écrit :
> Sorry to bug you  ... that ROUTE extension is perfect for me  ...

Fine :)

> but with my design I will have around 2000~  tunnels created (i know
> this sounds crazy).. will the kernel be able to handle this or is this
> too much of an overhead .... leaving aside the start up overhead,
> during the actual forwarding is there any overhead besides the extra
> ip header being attached....

I must admit I don't know if kernel will be able to handle 2000 logical
interfaces, as I'm not a kernel guru. Maybe you should ask kernel
mailing list.

Speaking of tunneling overhead, it will closely depend on which
tunneling techno you use (defines additionnal header, compression and
encryption) and the medium that supports the tunnel (defines MTU). Most
of the time, overhead is very low. IPIP tunneling will use one more IP
header, GRE tunnel a couple of bytes more, etc., and regarding a 1500
bytes MTU, we're still around 2% or 3% of overhead one full frame,
without any compression or encryption. Now you can use stuff like PPP
over SSL that has overhead, compression and encryption, SSH stuff or
IPSEC stuff, or whatever you may want to use :)

So you have three things :

        . header overhead
        . compression (that can beat the overhead) [1]
        . encryption

I would be more worry by the computing time necessary to decapsulate
packets if you use compression or encryption, and the latency (and maybe
packet loss) it can induce.


[1] I remember a time when it was faster for me to read my mail via POP
    over SSH than plain clear just because SSH uses compression. When
    security meet end-user needs ;)

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux