Traffic Shaping mit TC - Bandbreite und Latenz

Hi,

ich habe vor mit eine WAN Simulation zwischen 2 Linux Systemen aufzubauen. Dazu verwende ich ein drittes Linux System als Router zwischen den beiden. Ich moechte die Bandbreite beschränken und eine erhoete Latenz simulieren und das ganze mittels tc und qdiscs umsetzen. Auf dem Router System fuehre ich dazu folgendes aus:

Code:
tc qdisc add dev eth0 root handle 1: htb default 12
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 1024kbps ceil 1024kbps
tc qdisc add dev eth0 parent 1:12 netem delay 50ms 5ms 25% loss 0.1% 25% duplicate 1% corrupt 0.1%

tc qdisc add dev eth1 root handle 1: htb default 12
tc class add dev eth1 parent 1:1 classid 1:12 htb rate 1024kbps ceil 1024kbps
tc qdisc add dev eth1 parent 1:12 netem delay 50ms 5ms 25% loss 0.1% 25% duplicate 1% corrupt 0.1%


Bei diesen Einstellungen messe ich die erwartetet Latenz:

Code:
root@site1-kvm00:~# ping 10.173.11.10
PING 10.173.11.10 (10.173.11.10) 56(84) bytes of data.
64 bytes from 10.173.11.10: icmp_req=1 ttl=63 time=109 ms
64 bytes from 10.173.11.10: icmp_req=2 ttl=63 time=94.2 ms
64 bytes from 10.173.11.10: icmp_req=3 ttl=63 time=98.8 ms
64 bytes from 10.173.11.10: icmp_req=4 ttl=63 time=103 ms
^C
--- 10.173.11.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 94.271/101.528/109.485/5.635 ms
root@site1-kvm00:~#

Nur die Bandbreite weicht ab:

Code:
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 59748 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  8.05 MBytes  6.72 Mbits/sec
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 59749 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  5.34 MBytes  4.45 Mbits/sec
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 59750 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  7.84 MBytes  6.49 Mbits/sec
root@site1-kvm00:~#

Woher kommt das?

Gruesse
serows
 
Hi,

ich habe noch das hier netem | The Linux Foundation gefunden. Hier wird folgendes vorgeschlagen:

Rate control

There is no rate control built-in to the netem discipline, instead use one of the other disciplines that does do rate control. In this example, we use Token Bucket Filter (TBF) to limit output.
# tc qdisc add dev eth0 root handle 1:0 netem delay 100ms # tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 256kbit buffer 1600 limit 3000

Auf dieser Website [SOLVED] Netem rate limiting (token bucket filter) not supported? - FedoraForum.org habe ich dann noch die Info gefunden, dass man die qdiscs anders rum aufbauen muss:

Code:
[root@f12-build ~]# tc qdisc add dev eth1 root handle 1: tbf rate 256kbit buffer 1600 limit 3000 [root@f12-build ~]# tc qdisc add dev eth1 parent 1: handle 10: netem delay 150ms

Wenn ich das mache, und hier die 256kbit einstelle, messe ich so um die 360 KBit/s:

Code:
root@site1-kvm00:~# iperf -c 10.173.11.10
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 43535 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.3 sec    504 KBytes    365 Kbits/sec
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 43536 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.4 sec    504 KBytes    364 Kbits/sec
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 43537 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.1 sec    480 KBytes    355 Kbits/sec
root@site1-kvm00:~# iperf -c 10.173.11.10 
------------------------------------------------------------
Client connecting to 10.173.11.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.173.10.10 port 43538 connected with 10.173.11.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.3 sec    504 KBytes    365 Kbits/sec
root@site1-kvm00:~#

Hmm, 256kbit eingestellt und 360 KBits/sec bekommen. Sind die Einheiten hier nicht diesselben? Ich gehe davon aus, dass ja, also stimmt doch hier schon wieder was nich, oder??

Grüße
serow
 
Ich hab noch nie erlebt, dass Traffic-Shaping wirklich genau funktioniert, da es sich ja immer nur auf den Daten-Teil der Netzwerk-Pakete bezieht und Header in ihrer Grösse (abhängig vom Protokoll) variieren können. Man kann höchstens Richtwerte einstellen.
 
Ok, dann nehm ich das mal so als gegeben.

Weisst du zufaellig wie ich die fuer die netem qdisc parameter wie delay, loss, duplicate, corrupt für eine gegebene WAN Verbindung testen kann? Delay und loss und duplicate sind klar: Da lass ich mal 1000 Pings drueber laufen und lese die werte einfach ab ;) bzw schau wo ping ein (DUP!) ausgibt. Aber wo kann ich auslesen wieviele Packet korrupt werden? (Hintergrund: ich will mit Linux einem Testaufbau eine WAN Strecke simulieren)

Grüße
serow
 
netstat -s

Tcp:
35019 Segmente erneut übertragen

Bei TcpExt steht auch noch was evtl. interessantes:
1070 fast retransmits
71 forward retransmits
17134 retransmits in slow start
 
Zurück
Oben