lost and found ( for me ? )

Linux: traffic control

netem ( tcコマンド ) の基本的な使い方。

tc コマンドで、遅延、パケットロス、パケットの重複、パケットの到着順を変える、など模擬することができる。
遅延させ、WAN を模擬し、その時の、ネットワーク機器(フローテーブルをためたときの挙動)や、SLA(遅延が xx秒だとユーザ逃げちゃうだろうな)などのテストができそう。
あと、パケットの到着順をかえたときに、ロードバランサやFirewall が、処理できるか確認してみるとか。

・delay : outgoing に対して delay を設定  ( WANエミュレーション )

100ms の delay をかける。

[root@hat1-vm ~]# tc qdisc add dev eth0 root netem delay 100ms

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8001: limit 1000 delay 100.0ms

[root@hat1-vm ~]# ping 192.168.11.15
PING 192.168.11.15 (192.168.11.15) 56(84) bytes of data.
64 bytes from 192.168.11.15: icmp_seq=1 ttl=64 time=100 ms

削除

[root@hat1-vm ~]# tc qdisc del dev eth0 root netem delay 100ms

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc pfifo_fast 0: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

100ms ± 20ms といった設定も可能

[root@hat1-vm ~]# tc qdisc add dev eth0 root netem delay 100ms 20ms

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8001: limit 1000 delay 100.0ms  20.0ms

[root@hat1-vm ~]# ping 192.168.11.15
PING 192.168.11.15 (192.168.11.15) 56(84) bytes of data.
64 bytes from 192.168.11.15: icmp_seq=1 ttl=64 time=110 ms
64 bytes from 192.168.11.15: icmp_seq=2 ttl=64 time=83.7 ms

遅延 100ms ± 20ms に加え、ばらつき ( 正規分布 : normal distribution ) を設定。

# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal

[root@hat1-vm ~]# ping 192.168.11.15
PING 192.168.11.15 (192.168.11.15) 56(84) bytes of data.
64 bytes from 192.168.11.15: icmp_seq=1 ttl=64 time=161 ms
64 bytes from 192.168.11.15: icmp_seq=2 ttl=64 time=103 ms

・パケットロス

10%のパケットロス。(パケット 100 個中 10 個パケットロス)

[root@hat1-vm ~]# tc qdisc change dev eth0 root netem loss 10%

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8001: limit 1000 loss 10%

ping 100 回うったら、13個パケットロス

[root@hat1-vm ~]# ping 192.168.11.15 -c 100
100 packets transmitted, 87 received, 13% packet loss, time 99480ms
rtt min/avg/max/mdev = 0.761/0.859/1.089/0.067 ms

受信側でも一応確認。87パケット、キャプチャしている。13個パケットロス

[root@hat2-vm ~]# egrep -i request aa.txt | wc -l
87

・重複パケット

[root@hat1-vm ~]# tc qdisc change dev eth0 root netem duplicate 10%

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8001: limit 1000 duplicate 10%

DUP! なんて表示されるんだ。。

[root@hat1-vm ~]# ping 192.168.11.15
64 bytes from 192.168.11.15: icmp_seq=21 ttl=64 time=4.20 ms (DUP!)
64 bytes from 192.168.11.15: icmp_seq=22 ttl=64 time=4.55 ms
64 bytes from 192.168.11.15: icmp_seq=22 ttl=64 time=4.56 ms (DUP!)

reply が 2つきている。重複している。

[root@hat1-vm ~]# tshark -i eth0 icmp
 9.390787 192.168.11.14 -> 192.168.11.15 ICMP Echo (ping) request
 9.392571 192.168.11.15 -> 192.168.11.14 ICMP Echo (ping) reply
 9.392585 192.168.11.15 -> 192.168.11.14 ICMP Echo (ping) reply

・パケット破損 ( カーネル 2.6.16 以降から可能 )

[root@hat1-vm ~]# uname -r
2.6.18-194.17.1.el5

[root@hat1-vm ~]# tc qdisc change dev eth0 root netem corrupt 10%

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8001: limit 1000 corrupt 10%

キャプチャしてみたがパケット壊れていないような。。
確認できず。。

・パケットの到着順変更 ( re-ordering )

[root@hat1-vm ~]# tc qdisc add dev eth0 root netem delay 10ms reorder 25% 50%

[root@hat1-vm ~]# tc qdisc show dev eth0
qdisc netem 8002: limit 1000 delay 10.0ms reorder 25% 50% gap 1

25%のパケットはすぐ送信。残りは delay 10ms 。
すぐ送信されるパケットと、そうでないパケットがあるので到着順が変わる。
50% は correlation of 50% ,, correlation 相関、、50%の相関 ?? 。理解できず。

到着順がかわってる。

tc machine ( 192.168.11.14 ) から ssh で 192.168.11.100 に ssh したときのキャプチャデータより。

src 11.14 -> dst 11.100 宛てのパケット

seq # より到着順がかわっていることが読み取れる。

No.10

   Source: 192.168.11.14 (192.168.11.14)
   Destination: 192.168.11.100 (192.168.11.100)
257, Ack: 145, Len: 64
   Source port: ssh (22)
   Destination port: 53077 (53077)
   Sequence number: 257    (relative sequence number)

No.12

   Source: 192.168.11.14 (192.168.11.14)
   Destination: 192.168.11.100 (192.168.11.100)
145, Ack: 145, Len: 112
   Source port: ssh (22)
   Destination port: 53077 (53077)
   Sequence number: 145    (relative sequence number)

・incoming に対して delay

[root@hat1-vm ~]# modprobe ifb
[root@hat1-vm ~]# lsmod | grep ifb
ifb                     8901  0
[root@hat1-vm ~]# ip link set dev ifb0 up

[root@hat1-vm ~]# ifconfig ifb0
ifb0      Link encap:Ethernet  HWaddr A6:77:C4:D8:7A:C8
         inet6 addr: fe80::a477:c4ff:fed8:7ac8/64 Scope:Link
         UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:32
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root@hat1-vm ~]# tc qdisc add dev eth0 ingress
[root@hat1-vm ~]#  tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
[root@hat1-vm ~]#  tc qdisc add dev ifb0 root netem delay 500ms

[root@hat1-vm ~]# tc -s qdisc show dev eth0
qdisc pfifo_fast 0: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc ingress ffff: ----------------
Sent 276 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0

500msの遅延

[root@hat1-vm ~]# ping 192.168.11.15
PING 192.168.11.15 (192.168.11.15) 56(84) bytes of data.
64 bytes from 192.168.11.15: icmp_seq=1 ttl=64 time=500 ms
64 bytes from 192.168.11.15: icmp_seq=2 ttl=64 time=500 ms
64 bytes from 192.168.11.15: icmp_seq=3 ttl=64 time=500 ms

ping 先 ( 192.168.11.15 ) でキャプチャ
対抗先で delay がないので、受信後に遅延が発生している(incomingでdelay)と読み取れる。

[root@hat2-vm html]# tshark -i eth0 icmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
eth0: Promiscuous mode enabled.
 0.000000 192.168.11.14 -> 192.168.11.15 ICMP Echo (ping) request
 0.000013 192.168.11.15 -> 192.168.11.14 ICMP Echo (ping) reply
 1.003810 192.168.11.14 -> 192.168.11.15 ICMP Echo (ping) request
 1.003835 192.168.11.15 -> 192.168.11.14 ICMP Echo (ping) reply
 2.006794 192.168.11.14 -> 192.168.11.15 ICMP Echo (ping) request
 2.006820 192.168.11.15 -> 192.168.11.14 ICMP Echo (ping) reply

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.