シミュレーションのためにサーバーのネットワーク動作を修正しようとしています。外部/WAN接続動作（何を意味するのか）。
完了したらtc qdisc add dev lo root netem delay 100ms（そして？）で発生したすべてのトラフィックに100msの遅延を追加できます127.0.0.1。たとえば、ping 127.0.0.1応答時間は200msです。
ただし、これは他のインターフェイスへのトラフィックにも影響します。たとえば、eth1サーバーに現在のIPアドレスへのインターフェースがあります。これにより、100msの遅延が発生します（結果的に200msの応答時間が発生します）。192.168.0.1Aping 192.168.0.1
私はこの行動に混乱しています。私はloそれとは何の関係もないと思いましたが、eth1それは本当ではないようです。
これは、Linuxカーネルが自動的に192.168.0.1ローカルアドレスを認識し、eth1すべてのトラフィックを元のアドレスに再ルーティングすることを意味すると仮定しますlo。
それでは方法はないでしょうか障害を負うそのような行動？
背景：
シミュレーションしたい外部ネットワークこれは、サーバーのプロセスがA互いに通信したい場合でも同様です（もちろん、指定されたローカルアドレスとポートのTCP / IPを介して）。本質的に遅延を追加したいのですが、eth1これはこの質問を超えています（私その他の問題）。
私のサーバーはUbuntu 18.04を実行していますが、それは重要ではないと思います。
ベストアンサー1
いいえ、他のインターフェイスには影響しません。ただし、関連するルーティングは、loIPアドレスが割り当てられているインターフェイスに関係なく、サーバーからローカルへのすべてのアクセスを維持し（ループバック）、インターフェイスを使用します。だからlo影響を受けましたtc ... netem。
ip route getお客様の場合には、次のような内容を提供する次のコマンドを使用して確認できます。
$ ip route get 192.168.0.1
local 192.168.0.1 dev lo table local src 192.168.0.1 uid 1000
cache <local>
あなたが見たようにルオインターフェイスが使用されます。
この動作を無効にする理由はありません。どういうわけか192.168.0.1にパケットを送信することに成功した場合は、eth1推測してください。パケットを送信したインターフェイスからパケットを受信できないため、パケットは失われます。受信したトラフィックを送信機に送り返すように接続されたスイッチポートを設定するなど、複雑な設定をさらに想像できますが、近いうちにeth1実験目的が崩れ、実験が期待どおりに機能しなくなります。
ネットワークを扱うときに適切なテストを行うには、常にローカルテストとリモートテストを分離する必要があります。リモートシステムが利用できない場合は、独自の独立したフルネットワークスタックを持つ別のネットワークネームスペースを使用してエミュレートできます。以下は例です（OPの影響を受けませんtc ... netem）。
rootユーザーとして：
ip netns add remote
ip link add name vethtest up type veth peer netns remote name veth0
ip address add 192.0.2.1/24 dev vethtest
ip -n remote link set dev veth0 up
ip -n remote address add 192.0.2.2/24 dev veth0
ip netns exec remote ping 192.0.2.1
元のインターフェイスを再利用する方法がありますが、そのためには設定を中断する必要があります。