Utilizzo di tc per ritardare i pacchetti a un solo indirizzo IP


20

Sono nuovo di usare tc e netem . Voglio ritardare l'invio dei pacchetti a un indirizzo IP specifico. Tuttavia, i comandi seguenti causano il ritardo di tutti i pacchetti sul sistema, anziché solo all'indirizzo 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

La mia ipotesi è che alla fine ho bisogno di un qualche tipo di filtro catch-all per specificare che tutto il traffico rimanente non dovrebbe passare attraverso netem. Ma non riesco a far funzionare nulla. Come potrei farlo funzionare?

Risposte:


14

Ok, ho risolto il mio problema. Si scopre che se si eseguono le prime 3 righe sopra (quelle "tc qdisc"), si ritardano tutti i pacchetti perché non ci sono ancora filtri. La quarta riga la modifica per ritardare solo i pacchetti da quel singolo indirizzo IP. È possibile aggiungere ulteriori linee di filtro per aggiungere ulteriori indirizzi IP all'elenco "ritardato". Quindi: non creare una riga "netem delay" senza un filtro che punta ad essa.


Grazie per essere tornato e pubblicare la risposta. Stranamente ho scoperto che ha funzionato bene in entrambi i modi, ma comunque. Ho scritto uno script wrapper attorno a questi tre comandi per aiutare con i test, ho pensato di restituirmi un po ' :)
Arran Cudbard-Bell

13

La risposta scelta è errata / incompleta. Ho affrontato un problema simile, la risposta scelta mi ha dato un aiuto, ma non abbastanza.

Innanzitutto, il seguente comando non è davvero necessario.

tc qdisc del dev eth0 root

'Elimina' il root qdisc, ma viene immediatamente sostituito da uno pfifo_fast (in modo da non perdere la connettività).

Il secondo comando:

tc qdisc aggiungi dev eth0 root handle 1: prio

Sostituirà il qdisc pfifo_fast con quello prio. Per impostazione predefinita, la coda prio ha 3 bande (0, 1, 2) ciascuna gestita da una classe (1: 1, 1: 2 e 1: 3).

I pacchetti verranno inviati a una di quelle bande usando il campo TOS del pacchetto IP. Questa configurazione viene visualizzata quando si esegue:

tc qdisc ls

guardando i valori di 'priomap'.

Quindi, aggiungi un netd qdisc:

tc qdisc aggiungi dev eth0 parent 1: 1 handle 2: ritardo netem 500ms

Con questo comando si ritarda tutto il traffico diretto alla banda 1: 1 (fino a quando il filtro è in posizione).

Ma ci sono due avvertimenti:

  • Il tuo traffico può avere un valore TOS diverso e quindi essere inviato a un'altra banda.
  • Il prio qdisc può essere configurato in modo che il traffico passi a un'altra banda.

Di seguito ho risolto il mio problema per non essere influenzato dal netem mentre il filtro non è applicato. Invece dei passaggi precedenti, ho fatto:

tc qdisc aggiungi dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

Questo invierà tutto il traffico per impostazione predefinita alla banda 1: 3.

Quindi, ho aggiunto la regola per ritardare il traffico:

tc qdisc aggiungi dev eth0 parent 1: 1 handle 10: ritardo netem 100ms 10ms

Questo crea il qdisc nella banda 0, ma poiché tutto il traffico va alla banda 3, non mi ha influenzato.

Successivamente, ho aggiunto il filtro:

filtro tc aggiungi dev protocollo eth0 ip genitore 1: 0 prio 1 u32 corrispondenza ip dst 10.0.0.1/32 corrispondenza ip dport 80 0xffff flowid 1: 1

Ora con il filtro, sarà interessato solo l'IP / porta scelta, poiché reindirizziamo il traffico scelto alla banda 0.

Tutto il resto del traffico continua inalterato poiché continua a fluire verso la banda 3.


che cos'è "ip dst 10.0.0.1/32"? È l'IP di destinazione? significa che esiste un "ip src xxx.yyy.zz.www / aa"?
Zach Folwick,

Sì, è l'IP di destinazione nel mio esempio. E sì, c'è un'opzione 'ip src'.
Telegrapher,

Il motivo del primo comando (tc qdisc del) è quello di cancellare qualsiasi stato precedente - come potresti avere se stai sperimentando il tentativo di farlo funzionare. FWIW la risposta accettata ha funzionato per me.
Dan Pritts,

Grazie, questa risposta è stata DAVVERO utile.
PepeHands,

1

Semplice esempio da https://wiki.linuxfoundation.org/networking/netem che consente di ritardare i pacchetti a un determinato IP senza influire su nessun altro traffico, anche durante la configurazione:

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

Devo aggiungere un avvertimento, in seguito mi è sembrato che il ritardo si fosse applicato in modo più ampio di quanto mi aspettassi e non sono riuscito ad arrivare fino in fondo. Tuttavia, non tutto il traffico sembrava ritardato.
NeilenMarais, il

0

Non riesco a ritardare il traffico verso un IP mantenendo il traffico normale su altri IP normale con il metodo descritto in questo thread.

Tuttavia, riesco a farlo usando i seguenti comandi.

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

Per ritardare il 15001mstraffico verso l'IP 1.2.3.4dall'host su cui viene eseguito il comando. Il comando hostname -Iviene utilizzato per ottenere l'IP principale dell'host ma il valore può essere sostituito direttamente all'interno del comando.

Ho dovuto aggiungere un altro filtro con 0msritardo per abbinare il traffico proveniente dall'host. Di sicuro non è elegante ma non sono riuscito a far funzionare qualcosa di più bello.

L'ultimo comando può essere sostituito per abbinare una singola porta.

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

Per ritardare il traffico verso la porta 18583invece dell'IP 1.2.3.4.


Ho anche trovato un secondo metodo su questa risposta per ritardare il traffico 1.2.3.4:18583senza influire su altro traffico.

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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.