Messages in this thread | | | Date | Thu, 18 Nov 1999 03:23:19 +0100 | From | Bram Avontuur <> | Subject | traffic shaping & tunneling & 2.3 kernels. |
| |
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ð2 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/
| |