I thought I had this all worked out, but it seems not. The following tc
configuration:
tc qdisc del dev ppp0 root 2> /dev/null > /dev/null
tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit burst 1200 limit 1
tc qdisc add dev ppp0 parent 1:1 handle 2: prio bands 3
tc qdisc add dev ppp0 parent 2:1 handle 10: sfq perturb 20
tc qdisc add dev ppp0 parent 2:2 handle 20: sfq perturb 20
tc qdisc add dev ppp0 parent 2:3 handle 30: sfq perturb 20
# ICMP so we can see PRIO working
tc filter add dev ppp0 parent 2:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 2:1
Is producing the following tc rules:
qdisc tbf 1: rate 120000bit burst 1199b lat 4294.9s
Sent 2024323 bytes 38831 pkt (dropped 54, overlimits 280 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc prio 2: parent 1:1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 2024323 bytes 38831 pkt (dropped 0, overlimits 0 requeues 280)
rate 0bit 0pps backlog 0b 0p requeues 280
qdisc sfq 10: parent 2:1 limit 128p quantum 1452b perturb 20sec
Sent 123362 bytes 1983 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 20: parent 2:2 limit 128p quantum 1452b perturb 20sec
Sent 122669 bytes 1007 pkt (dropped 0, overlimits 0 requeues 127)
rate 0bit 0pps backlog 0b 0p requeues 127
qdisc sfq 30: parent 2:3 limit 128p quantum 1452b perturb 20sec
Sent 1778292 bytes 35841 pkt (dropped 0, overlimits 0 requeues 153)
rate 0bit 0pps backlog 0b 0p requeues 153
And I have the following iptables rules:
Chain PREROUTING (policy ACCEPT 1564K packets, 875M bytes)
pkts bytes target prot opt in out source destination
1560K 872M tcpre all -- * * 0.0.0.0/0 0.0.0.0/0
Chain tcpre (1 references)
pkts bytes target prot opt in out source destination
1504K 864M CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore mask 0xff
1280K 726M RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0/0xff
86 8988 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.7.2 --bit MARK set 0x1
86 8988 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x1/0xff CONNMARK save mask 0xff
Chain POSTROUTING (policy ACCEPT 1533K packets, 866M bytes)
pkts bytes target prot opt in out source destination
599K 29M CLASSIFY tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x10 length 0:128 CLASSIFY set 2:1
1529K 864M tcpost all -- * * 0.0.0.0/0 0.0.0.0/0
Chain tcpost (1 references)
pkts bytes target prot opt in out source destination
212K 111M CLASSIFY all -- * * 0.0.0.0/0 0.0.0.0/0 CLASSIFY set 2:2
549K 28M CLASSIFY all -- * ppp0 0.0.0.0/0 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 2:3
713K 689M CLASSIFY all -- * eth0 0.0.0.0/0 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 2:3
30518 2862K CLASSIFY all -- * * 10.75.22.1 66.1.2.3 CLASSIFY set 2:1
0 0 CLASSIFY all -- * * 66.1.2.3 66.9.8.7 CLASSIFY set 2:1
0 0 CLASSIFY udp -- * * 0.0.0.0/0 66.9.8.7 udp dpt:29378 CLASSIFY set 2:1
0 0 CLASSIFY udp -- * * 10.75.22.1 0.0.0.0/0 udp spt:29378 CLASSIFY set 2:1
But it seems that some outbound flows are being blocked entirely. I
don't think they are being starved though. Even if they end up in 2:3,
they should at least be treated fairly. But I am producing a flow to
66.1.2.3 which does increment the counters in 2:1 but after a few
packets the flow stalls:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 8240 10.75.22.1:55318 66.1.2.3:922 ESTABLISHED 21028/ssh
And that flow stays stuck with 8240 bytes in the Send-Q.
What have I done wrong? I am so close to my desired behaviour with the
exception being of course that some flows seem to get stuck. I should
add that some initial packets in that stuck flow above (port 922) are
processed. It seems that at some point they just stop getting
processed. The last packets that went out on that flow were:
11:26:47.691755 IP 66.1.2.3.922 > 66.9.8.7.55318: P 1872:1920(48) ack 2261 win 9968 <nop,nop,timestamp 8735287 43843955>
11:26:47.731489 IP 66.9.8.7.55318 > 66.1.2.3.922: . ack 1920 win 2548 <nop,nop,timestamp 43844116 8735287>
11:26:47.855781 IP 66.1.2.3.922 > 66.9.8.7.55318: P 1920:1968(48) ack 2261 win 9968 <nop,nop,timestamp 8735300 43844116>
11:26:47.856142 IP 66.9.8.7.55318 > 66.1.2.3.922: . ack 1968 win 2548 <nop,nop,timestamp 43844240 8735300>
11:26:47.857866 IP 66.9.8.7.55318 > 66.1.2.3.922: P 2261:2373(112) ack 1968 win 2548 <nop,nop,timestamp 43844242 8735300>
11:26:48.072776 IP 66.1.2.3.922 > 66.9.8.7.55318: P 1968:2016(48) ack 2373 win 9968 <nop,nop,timestamp 8735316 43844242>
11:26:48.321959 IP 66.1.2.3.922 > 66.9.8.7.55318: P 1968:2016(48) ack 2373 win 9968 <nop,nop,timestamp 8735352 43844242>
11:26:48.322384 IP 66.9.8.7.55318 > 66.1.2.3.922: . ack 2016 win 2548 <nop,nop,timestamp 43844707 8735352,nop,nop,sack 1 {1968:2016}>
So maybe for some reason that last ack is not being dequeued? But
surely it should as classes 2:1 and 2:2 are virtually quiet and class
2:3 while having steady traffic, should at least treat it all fairly,
no?
b.
--
My other computer is your Microsoft Windows server.
Brian J. Murrell
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
