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
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.