為什麼環回上的 tc-netem 也會影響其他介面？
我正在嘗試修改伺服器的網路行為，以模擬外部/WAN 連接行為（這意味著什麼）。
完成後
tc qdisc add dev lo root netem delay 100ms，我可以成功地為來自（和到？）的所有流量添加 100 毫秒延遲127.0.0.1。例如ping 127.0.0.1將有 200 毫秒的響應時間。但是，這也會影響我到其他介面的流量。例如，我在目前伺服器上有
eth1與 IP 地址的介面。如果我這樣做，它也會有 100 毫秒的延遲（導致 200 毫秒的響應時間）。192.168.0.1``A``ping 192.168.0.1我對這種行為感到困惑。我希望
lo與 無關eth1，但似乎並非如此。我假設這意味著 Linux 核心會自動辨識本地地址，並將所有流量（最初到）
192.168.0.1重新路由到？eth1``lo如果是這樣，有沒有辦法禁用這種行為？
背景：
即使伺服器上的程序想要相互通信（當然，通過給定本地地址和埠上的 TCP/IP），我也想模擬外部網路行為。
A本質上我想添加延遲eth1，但這在這個問題之上（見我的另一個問題）。我的伺服器執行的是 Ubuntu 18.04，但我相信這並不重要。
不，它不會影響其他介面。但是所涉及的路由使得從伺服器到自身的任何訪問都保持在本地，並使用
lo（環回）介面，無論 IP 地址分配到什麼介面。所以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>如您所見，使用了lo介面。
沒有理由禁用此行為。如果您通過猜測以某種方式設法將數據包發送到 192.168.0.1
eth1：您將不會在發出它的介面上收到它，因此它會失去。您可以進一步想像整個複雜的設置，包括配置eth1插入的交換機埠以將其接收到的發射器流量發送回它，但這遲早會破壞實驗的最初目的，並且實驗將不再按預期工作.要在處理網路時進行正確的測試，應始終將本地測試和遠端測試分開。如果沒有可用的遠端系統，這可以通過使用具有自己獨立的完整網路堆棧的其他網路命名空間來模擬。下面是一個範例（不受 OP 的影響
tc ... netem）。作為根使用者：
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有一些方法可以重用原始介面，但這需要對配置進行一些中斷。