Użycie tc do opóźnienia pakietów do tylko jednego adresu IP

Jestem nowy w używaniu tc i netem . Chcę opóźnić wysyłanie pakietów na określony adres IP. Poniższe polecenia powodują jednak opóźnienie wszystkich pakietów w systemie, a nie tylko adres IP 1.2.3.4:

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1

Domyślam się, że potrzebuję na końcu jakiegoś filtru typu catch-all, aby określić, że cały pozostały ruch nie powinien przechodzić przez netem. Ale nic nie mogę zrobić. Jak mam to zrobić?

Ok rozwiązałem swój problem. Okazuje się, że jeśli wykonasz pierwsze 3 wiersze powyżej (te „tc qdisc”), opóźni to wszystkie pakiety, ponieważ nie ma jeszcze filtrów. Czwarta linia zmienia ją tak, aby opóźniała pakiety tylko z tego jednego adresu IP. Można dodać dodatkowe linie filtrów, aby dodać dodatkowe adresy IP do listy „opóźnionych”. Więc: nie twórz linii „netem delay” bez skierowanego na nią filtra.

Wybrana odpowiedź jest niepoprawna / niepełna. Napotkałem podobny problem, wybrana odpowiedź pomogła, ale niewystarczająco.

Po pierwsze, następujące polecenie nie jest tak naprawdę potrzebne.

tc qdisc del dev eth0 root

„Usunie” root qdisc, ale natychmiast zostanie zastąpiony przez pfifo_fast (abyś nie stracił łączności).

Drugie polecenie:

tc qdisc dodaj uchwyt eth0 root 1: prio

Zamieni qdisc pfifo_fast na prio. Domyślnie kolejka prio ma 3 pasma (0, 1, 2), każdy zarządzany przez jedną klasę (1: 1, 1: 2 i 1: 3).

Pakiety zostaną wysłane do jednego z tych pasm przy użyciu pola TOS pakietu IP. Ta konfiguracja jest wyświetlana po wykonaniu:

tc qdisc ls

patrząc na wartości „priomap”.

Następnie dodajesz qdisc netem:

tc qdisc dodaj dev eth0 nadrzędny uchwyt 1: 1 2: opóźnienie netem 500ms

Za pomocą tego polecenia opóźniasz cały ruch do pasma 1: 1 (aż filtr zostanie zainstalowany).

Ale są dwa zastrzeżenia:

• Twój ruch może mieć inną wartość TOS, a następnie zostać wysłany do innego pasma.
• Kolejkę prio można skonfigurować tak, aby ruch trafiał do innego pasma.

Poniższe rozwiązało problem, który nie ma wpływu na netem, gdy filtr nie jest zastosowany. Zamiast powyższych kroków zrobiłem:

tc qdisc dodaj dev eth0 uchwyt root 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

Spowoduje to domyślnie wysłanie całego ruchu do pasma 1: 3.

Następnie dodałem regułę opóźniającą ruch:

tc qdisc dodaj dev eth0 nadrzędny uchwyt 1: 1 10: opóźnienie netem 100ms 10ms

To tworzy qdisc w paśmie 0, ale ponieważ cały ruch trafia do pasma 3, nie miało to na mnie wpływu.

Następnie dodałem filtr:

filtr tc dodaj protokół dev eth0 ip rodzic 1: 0 prio 1 u32 mecz ip dst 10.0.0.1/32 mecz ip dport 80 0xffff flowid 1: 1

Teraz z filtrem wpłynie to tylko na wybrany adres IP / port, ponieważ przekierowujemy wybrany ruch do pasma 0.

Cały pozostały ruch pozostaje niezmieniony, ponieważ nadal przepływa do pasma 3.

Prosty przykład z https://wiki.linuxfoundation.org/networking/netem, który pozwala opóźnić pakiety do danego adresu IP bez wpływu na inny ruch, nawet podczas konfiguracji:

tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \
   match ip dst 192.168.1.2 flowid 1:3

Nie udało mi się opóźnić ruchu do jednego adresu IP, utrzymując ruch normalny w stosunku do innych adresów IP normalnie, przy użyciu metody opisanej w tym wątku.

Udaje mi się to jednak wykonać za pomocą następujących poleceń.

tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1

Aby opóźnić 15001msruch do IP 1.2.3.4z hosta, na którym wykonywane jest polecenie. Polecenie hostname -Isłuży do uzyskania głównego adresu IP hosta, ale wartość można zastąpić bezpośrednio w poleceniu.

Musiałem dodać kolejny filtr z 0msopóźnieniem, aby dopasować ruch przychodzący z hosta. Na pewno nie jest elegancki, ale nie udało mi się uzyskać czegoś ładniejszego.

Ostatnie polecenie można zastąpić, aby pasowało do jednego portu.

tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1

Aby opóźnić ruch do portu 18583zamiast adresu IP 1.2.3.4.

Znalazłem również drugą metodę tej odpowiedzi, aby opóźnić ruch 1.2.3.4:18583bez wpływu na inny ruch.

tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 protocol ip  parent 1: prio 1 u32 match ip dst 1.2.3.4 match ip dport 18583 0xffff flowid 1:1
tc filter add dev eth0 protocol all parent 1: prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:2
tc filter add dev eth0 protocol all parent 1: prio 2 u32 match ip protocol 1 0xff flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 10ms
tc qdisc add dev eth0 parent 1:2 handle 20: sfq