LinuxParty

Traffic Control (tc) es una utilidad de Linux muy útil que le brinda la capacidad de configurar el programador de paquetes del núcleo. Si está buscando razones para meterse con el programador del núcleo, aquí hay algunas: en primer lugar, es divertido jugar con las diferentes opciones y familiarizarse con todas las características de Linux. Además, puede utilizar las útiles herramientas de Linux para simular el retraso y la pérdida de paquetes para aplicaciones UDP o TCP, o limitar el uso de ancho de banda de un servicio particular para simular conexiones de Internet (DSL, Cable, T1, etc.).

En Debian Linux, tc viene incluido con iproute, por lo que para instalarlo debe ejecutar:

Retraso de red

El primer ejemplo es cómo agregar un retraso constante a una interfaz. La sintaxis es la siguiente (ejecutar esto como root):

Esto es lo que significa cada opción:

qdisc: modificar el planificador (también conocido como disciplina de colas )
add: agregar una nueva regla
dev eth0: las reglas se aplicarán en el dispositivo eth0
root: modificar el planificador de tráfico saliente (también conocido como el qdisc de salida)
netem: usar el emulador de red para emular una rend WAN
delay: especifica una propiedad de retardo de propiedad la propiedad de red que se ha modificado en 200 ms
: introduce un retardo de 200 ms

Nota: esto agrega un retraso de 200 ms al planificador de salida, exclusivamente. Si se agregara la demora a los planificadores de entrada y salida, la demora total habría totalizado 400 ms. En general, todas estas reglas de control de tráfico se aplican solo al planificador de salida.

Así es como se ve el ping antes:

1
2
3
4
5
6

$ ping google.com
PING google.com (172.217.6.78) 56(84) bytes of data.
64 bytes from sfo07s17-in-f78.1e100.net (172.217.6.78):
icmp_seq=1 ttl=53 time=11.9 ms
64 bytes from sfo07s17-in-f78.1e100.net (172.217.6.78):
icmp_seq=2 ttl=53 time=12.0 ms

Así es como se ve el ping después de aplicar esta regla:

1
2
3
4
5
6

$ ping google.com
PING google.com (172.217.5.110) 56(84) bytes of data.
64 bytes from sfo03s07-in-f14.1e100.net (172.217.5.110):
icmp_seq=1 ttl=53 time=213 ms
64 bytes from sfo03s07-in-f14.1e100.net (172.217.5.110):
icmp_seq=2 ttl=53 time=210 ms

Para mostrar las reglas activas use:

1
2

$ tc qdisc show  dev eth0
qdisc netem 8003: root refcnt 2 limit 1000 delay 200.0ms

Puede ver los detalles de las reglas existentes que agregan 200.0 ms de latencia.

Para eliminar todas las reglas, use el siguiente comando:

Y ahora podemos ver cuáles son las reglas predeterminadas del planificador de Linux:

1
2

$ tc qdisc show  dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sin entrar en demasiados detalles, vemos que el planificador funciona bajo las reglas Primero en entrar, primero en salir (FIFO), que es la regla más básica y justa si no desea establecer prioridades en paquetes específicos. Puede pensarlo como la línea en el banco: los clientes están siendo atendidos en el orden en que llegan.

Tenga en cuenta que si tiene una regla existente, puede cambiarla usando “ tc qdisc change ... ” y si no tiene ninguna regla, agregue reglas con “ tc qdisc add . . . "

Aquí hay algunos otros ejemplos:

-Retraso de 100 ms y aleatorio + -10ms distribución uniforme:

tc qdisc change dev eth0 root netem delay 100ms 10ms

-Retraso de 100 ms y 10 ms al azar de variación uniforme con valor de correlación 25% (desde retrasos en la red no son completamente al azar):

tc qdisc change dev eth0 root netem delay 100ms 10ms 25%

-Retraso de 100 ms y al azar + -10ms distribución normal (otras opciones de distribución son Pareto y paretonormal):

add dev eth0 root netem delay 100ms 20ms distribution normal

Pérdida de paquetes y corrupción de paquetes

Sin explicar la sintaxis en detalle, ahora presentamos una pérdida de paquetes del 10%:

tc qdisc add dev eth0 root netem loss 10%

Podemos probar esto ejecutando una prueba de ping con 100 paquetes ICMP. Así es como se ven las estadísticas agregadas:

1
2
3
4
5
6
7
8
9
10

$ ping google.com -c 100
PING google.com (216.58.194.174) 56(84) bytes of data.
64 bytes from sfo07s13-in-f174.1e100.net (216.58.194.174): icmp_seq=1 ttl=53 time=10.8 ms
.....
64 bytes from sfo07s13-in-f174.1e100.net (216.58.194.174): icmp_seq=99 ttl=53 time=11.8 ms
64 bytes from sfo07s13-in-f174.1e100.net (216.58.194.174): icmp_seq=100 ttl=53 time=10.5 ms

--- google.com ping statistics ---
100 packets transmitted, 89 received, 11% packet loss, time 99189ms
rtt min/avg/max/mdev = 10.346/12.632/21.102/2.640 ms

Como puede ver, hubo una pérdida de paquetes del 11% que está muy cerca del valor establecido. Tenga en cuenta que si tiene acceso al cuadro de Linux en el que está ejecutando estos comandos, su conexión podría perderse debido a que la pérdida de paquetes fue demasiado alta.

La siguiente regla corrompe el 5% de los paquetes al introducir un error de un solo bit en un desplazamiento aleatorio en el paquete:

tc qdisc change dev eth0 root netem corrupt 5%

Éste duplica el 1% de los paquetes enviados:
tc qdisc change dev eth0 root netem duplicate 1%

Límite de ancho de banda

Para limitar el ancho de banda de salida podemos usar el siguiente comando:

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

tbf: use el filtro de token buffer para manipular la velocidad de tráfico
: velocidad máxima sostenida ráfaga: máxima latencia de ráfaga permitida : los paquetes con mayor latencia se descartan

La mejor manera de demostrar esto es con una prueba iPerf. En mi laboratorio obtengo 95 Mbps de rendimiento antes de aplicar cualquier regla de ancho de banda:

1
2
3
4
5
6
7
8

------------------------------------------------------------
Client connecting to 172.31.0.142, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  3] local 172.31.0.25 port 40233 connected with 172.31.0.142 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   113 MBytes  95.0 Mbits/sec

Y aquí está el rendimiento después de aplicar el límite de 1 Mbps:

1
2
3
4
5
6
7
8

------------------------------------------------------------
Client connecting to 172.31.0.142, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  3] local 172.31.0.25 port 40232 connected with 172.31.0.142 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.0 sec  1.50 MBytes  1.14 Mbits/sec

Como puede ver, el ancho de banda medido de 1.14 Mbps está muy cerca del límite configurado.

El control de tráfico (tc), en combinación con el emulador de red (netem) y los filtros de depósito de tokens (tbf), pueden realizar configuraciones mucho más avanzadas que solo tc solo. Algunos ejemplos de configuraciones avanzadas son maximizar el rendimiento de TCP en un enlace asimétrico, priorizar el tráfico sensible a la latencia o administrar el ancho de banda sobreuscrito. Algunas de estas tareas se pueden realizar de manera efectiva con otras herramientas o servicios, pero tc es una gran utilidad para tener en su arsenal cuando surja la necesidad.