Netem
Network の検証でたまーに遅延による影響を評価したくなることがある。いわゆる Network エミュレーション。遅延とかパケロスとかを発生させて上位レイヤがどう動くかを評価する。
データセンター内だとこの辺りはあまり問題にならない。でも、WAN 部分だと結構な影響が出てくる。音声通信の品質とか、End-End での死活監視タイマとか。当然こういった検証をするための遅延エミュレータもあるんだけれど、買うとなるとそれなりのお値段がする。
このあたり、お家で遊べないかなと調べてみたら、Linux では Netem というツールで実現できる様子ことが分かった。この手の装置はL2で使いたい。遅延装置にアドレス振ってしまうと Network の論理トポロジが崩れてしまうから。なので、Linux の Interfaceをブリッジで動作させ、そこを通過するパケットに対して遅延を発生させてみた。
検証条件
- Ubuntu 20.04 on GNS3 2.2.9
遅延を起こすこと自体に必要な Netem 自体はUbuntu 18.04でも20.04でも最初から入っていた。そんな大事ではなさそう。微量のトラフィック印加であれば特にCPU高騰などといったことはなかった。
検証構成
遅延サーバには Interface を3つ持たせた。遅延サーバ自体にアクセスするためのInterfaceが一つと、L2で透過させるための2 Interface が必要になる。ens4/5をブリッジとして動作させる。
ブリッジで動作させる
sudo apt install bridge-utils
sudo ip link set ens4 promisc on
sudo ip link set ens5 promisc on
sudo brctl addbr br0
sudo brctl addif br0 ens4
sudo brctl addif br0 ens5
sudo ip link set br0 up
遅延設定
例えばこんな感じ。
sudo tc qdisc add dev ens4 root netem delay 100ms #ENS4から入るパケットに100msの遅延を印加
sudo tc qdisc del dev ens4 root #遅延設定を削除
TCの使い方は、tcコマンドの使い方など、 多くの方がドキュメントを残して下さっているのでそちらを参照。
見え方
vyos@EoR1a:~$ ping 10.0.0.2
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
(snip)
64 bytes from 10.0.0.1: icmp_seq=135 ttl=64 time=0.869 ms
64 bytes from 10.0.0.1: icmp_seq=136 ttl=64 time=0.961 ms
64 bytes from 10.0.0.1: icmp_seq=137 ttl=64 time=1.19 ms
64 bytes from 10.0.0.1: icmp_seq=138 ttl=64 time=1.26 ms
64 bytes from 10.0.0.1: icmp_seq=139 ttl=64 time=100 ms # ここから遅延が乗ってきた
64 bytes from 10.0.0.1: icmp_seq=140 ttl=64 time=101 ms
64 bytes from 10.0.0.1: icmp_seq=141 ttl=64 time=101 ms