traffic shaping & tunneling & 2.3 kernels.

Bram Avontuur (brama@chello.nl)
Thu, 18 Nov 1999 03:23:19 +0100


Hi, a few questions:

I am running 2.3.26 on a x86 box with 3 NIC's, a VPN (by means of ipip
tunnels), masquerading all that leaves the first NIC (eth0), and
traffic shaping. eth1&eth2 are LAN nics and cover 192.168.1/24 and
192.168.3/24.

The biggest problem with 2.3 kernels on my system is that it crashes
often when traffic shaping is enabled. I use the cbq.init script bij
Pavel Golubev to have interactive connections (destinationport=22 or
23) that lead outside the LANs get 40kbit bandwith at any time. Is it
a known problem that traffic shaping using cbq is unreliable in 2.3.*
(it never crashed on 2.2.10-13, which I used for several months)? If
not, I will try to catch the panic messages.

Furthermore, using ipip tunnels on 2.3.25/26 produce tons of kernel
messages when data is sent over them. Here's sample output:

---8<---
Nov 18 02:51:52 mp3 kernel: nf_hook: hook 0 already set.
Nov 18 02:51:52 mp3 kernel: skb: pf=2 (unowned) dev=tunl0 len=52
Nov 18 02:51:52 mp3 kernel: PROTO=6 192.168.142.2:57707 192.168.3.2:1263 L=52 S=0x10 I=22534 F=0x4000 T=63
Nov 18 02:51:52 mp3 kernel: ip_finish_output: bad unowned skb = c135c0e0: PRE_ROUTING LOCAL_IN FORWARD POST_ROUTING
Nov 18 02:51:52 mp3 kernel: skb: pf=2 (unowned) dev=eth1 len=52
Nov 18 02:51:52 mp3 kernel: PROTO=6 192.168.142.2:57707 192.168.3.2:1263 L=52 S=0x10 I=22534 F=0x4000 T=62
Nov 18 02:51:52 mp3 kernel: nf_hook: hook 4 already set.
Nov 18 02:51:52 mp3 kernel: skb: pf=2 (unowned) dev=eth0 len=1500
Nov 18 02:51:52 mp3 kernel: PROTO=4 212.83.81.124:0 212.83.75.70:0 L=1500 S=0x00 I=24134 F=0x4000 T=63
Nov 18 02:51:52 mp3 kernel: nf_hook: hook 4 already set.
Nov 18 02:51:52 mp3 kernel: skb: pf=2 (unowned) dev=eth0 len=1500
Nov 18 02:51:52 mp3 kernel: PROTO=4 212.83.81.124:0 212.83.75.70:0 L=1500 S=0x00 I=24135 F=0x4000 T=63
---8<---

Same Q: Known problem? And if so, do gre tunnels have this problem
too? I used a recent 'ip' tool to set up the tunnels.

Then, a final question about traffic shaping (perhaps slightly
off-topic but you try to find practical documentation on it other than
theory books ;):

As I mentioned, I give all traffic leaving the LAN to port 22 or 23 a
separate class with 40kbit bandwith (and another class for all the
remaining bandwith). This works reasonably well if the other bandwith
is overloaded, however it does not work for interactive traffic in
tunnels because I can't figure out how to put interactive traffic over
tunnels in this 'interactive' class. Furthermore since traffic
leaving eth0 is always masqueraded, the source address of all traffic
is set to the IP-address given by my ISP. This means I can't shape
based on the private net source IP's on eth0. IOW, it would be nice if
the shaping could be done before the masquerading, though I fear that
would probably prove impossible, right?

An implication of having a separate 40kbit class for interactive
traffic and another class for all the remaining traffic&bandwidth, is
that if there is *no* interactive traffic but heavy other traffic, the
40kbits remain unused which is obviously a sin if you don't have much
bandwidth. I read a paper on the cbq algorithm and an implementation
of it in solaris, and they both talk about 'borrowing' traffic from
another class when there's bandwidth left unused. Is this possible in
the current linux implementation as well?

What I really want, obviously, is that interactive traffic ALWAYS has
the highest priority over non-interactive traffic, so that the latency
is guaranteed even when there's too much traffic waiting to get
through (and thus drop all the packets that have lower priority and
don't fit). If it can be done this way, I don't have to bother with
fixed bandwith classes (only with a max. bandwith for interactive
traffic perhaps).

All this is because the upload limit of the cable modem hooked up to
eth0 is limited to 128kbit/s, and when someone from the LAN uses this
to its full extend all interactive connections get a horrible latency.

Thanks for your time,

Bram

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/