Control de tráfico y DiffServ en Linux
- Introducción
- Elementos del control de tráfico
- Configuración de una disciplina de cola a la entrada/salida de un router
- Control de admisión para el tráfico de entrada (policing)
Introducción
tc
(Traffic Control) es una herramienta que permite realizar el control de tráfico en Linux.tc
utiliza disciplinas de colas, denominadasqdisc
(queueing discipline).Cada vez que el kernel tiene que enviar un paquete a una interfaz, se encola en la
qdisc
configurada en dicha interfaz. El kernel trata de sacar el máximo número de paquetes de dichaqdisc
para entregárselos al driver de la tarjeta de red.El tipo de
qdisc
más simple es FIFO (First In First Out). Si el driver de la tarjeta de red está ocupado, el paquete se quedará guardado en la cola.
Elementos del control de tráfico
Interfaces de entrada/salida de un router
El control de tráfico se puede aplicar en la interfaz de entrada de un router o en la interfaz de salida del router.
Cada interfaz de red de un router puede actuar como entrada de paquetes, para los paquetes que se reciben en dicha interfaz, y como interfaz de salida, para los paquetes que se envían a través de dicha interfaz.
Qdisc/Class/Filter
Qdisc (Disciplina de cola): determina qué paquetes se reenviarán antes que otros. Las hay de 2 tipos:
Disciplina de colas sin clases de tráfico: ejemplo FIFO.
Disciplina de colas con clases de tráfico: ejemplo PRIO
Class (Clase de tráfico): especifica las diferentes categorías de tráfico. Una clase de tráfico está asociada a una disciplina de cola (qdisc).
Filter (Filtro de tráfico): identifica el tráfico que se corresponde con cada clase (class).
Configuración de una disciplina de cola a la entrada/salida de un router
Creación de disciplinas de cola a la entrada y a la salida de un router
En una determinada interfaz se pueden definir:
Disciplinas de cola de entrada: para los paquetes que entran a través de dicha interfaz.
tc qdisc add dev <interfaz> ... ingress
Disciplinas de cola de salida: para los paquetes que salen a través de dicha interfaz.
tc qdisc add dev <interfaz> root ...
Por defecto, si no se modifican las disciplinas de cola a la entrada y a la salida de un router, el router aplicará una variante de FIFO (
pfifo_fast
, FIFO mejorado).
Descriptor (handle) de una disciplina de cola
Cuando se define una disciplina de cola se le asocia un descriptor (handle) para poder referenciarla.
El handle está formado por 2 números separados por el caracter “:”, es decir, X:Y
X : es el número mayor.
Y : es el número menor.
Típicamente el handle de la disciplina de la cola de entrada (ingress) es
ffff:
lo que equivale affff:0
.tc qdisc add dev <interfaz> ingress handle ffff:
Típicamente el handle de la disciplina de la cola de salida (root) es
1:
lo que equivale a1:0
.tc qdisc add dev <interfaz> root handle 1: ...
Borrado de disciplinas de cola
El borrado de disciplinas de cola en la entrada y en la salida de un router se hace de la siguiente forma:
Borrado de la disciplina de la cola de entrada:
tc qdisc del dev <interfaz> ingress
Borrado de la disciplina de la cola de salida:
tc qdisc del dev <interfaz> root
Control de admisión para el tráfico de entrada (policing)
El control de admisión para el tráfico de entrada se utiliza para garantizar que el router sólo procesa para un determinado flujo de paquetes de entrada un máximo de ancho de banda.
Para garantizar que se cumple el control de admisión el router debe definir una disciplina de colas en la interfaz de red asociada a la entrada de paquetes. Ejemplo, si los paquetes se reciben en la interfaz
eth0
:tc qdisc add dev eth0 handle ffff: ingress
Se definen filtros para cada uno de los flujos de entrada que van a pertenecer a esa cola de entrada en la interfaz
eth0
(handle ffff:) indicando el ancho de banda máximo y el tamaño de la cubeta. El control de admisión se basa en el modelo TBF. Si el tráfico de entrada supera esa especificación se descarta o se le pasa al siguiente filtro.
Ejemplo:
Se define
qdisc
para la entrada.Se definen filtros para clasificar el tráfico: los paquetes que cumplen una condición se les aplica un TBF y quedan clasificados dentro de un determinado flujo ():
Condición: utilizaremos el que comprueba campos de la cabecera IP de los paquetes.
Perfil de tráfico: se configura con . El tráfico que supere la especificación puede reclasificarse (continue) o descartarse (drop).
Los filtros se aplican siguiendo el orden dado por el parámetro prioridad: primero los filtros cuyo valor de prioridad sea menor (números de prioridad bajos equivale a mayor prioridad).
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: \
protocol ip prio 4 u32 \
match ip src 11.0.0.100/32 \
police rate 1mbit burst 10k continue flowid :1
tc filter add dev eth0 parent ffff: \
protocol ip prio 5 u32 \
match ip src 11.0.0.100/32 \
police rate 512kbit burst 10k continue flowid :2
tc filter add dev eth0 parent ffff: \
protocol ip prio 6 blue u32 \
match ip src 11.0.0.100/32 \
police rate 256kbit burst 50k drop flowid :3
tc filter add dev eth0 parent ffff: \
protocol ip prio 6 u32 \
match ip src 0.0.0.0/0 \
police rate 128kbit burst 5k drop flowid :4
Control del tráfico de salida
PFIFO para el tráfico de salida
FIFO con tamaño de cola dado por el valor
limit
en número de paquetes:tc qdisc add dev eth0 root pfifo limit 5
Es una disciplina de colas muy sencilla que requiere poco tiempo de computación.
Si hay congestión, FIFO perjudica a TCP debido a que una pérdida de un paquete en TCP activa los mecanismos de control de congestión que provocan una disminución de la tasa de envío para la conexión TCP. Una pérdida de un paquete UDP no tiene ningún impacto en la tasa de envío para esta comunicación.
Una ráfaga de uno de los flujos que atraviese una cola FIFO puede llenar la cola y perjudicar al resto de los flujos.
PRIO para el tráfico de salida
PRIO es una disciplina de cola de prioridades que realiza algunas acciones automáticamente. El siguiente comando crea la disciplina de cola 1:0 y automáticamente crea las clases 1:1, 1:2 y 1:3 de tipo PFIFO.
tc qdisc add dev eth0 root handle 1: prio
![image](./tc/figs/qos-14.png)
- Si se desea crear un número diferente de prioridades se puede usar
el parámetro:
bands <núm_prio>
.
Es necesario especificar los filtros para clasificar el tráfico dentro de las clases 1:1, 1:2 y 1:3 del ejemplo. Esta clasificación puede hacerse a través del filtro u32 utilizando la dirección IP origen:
tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip src 11.0.0.1/32 flowid 1:1 tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 \ match ip src 11.0.0.2/32 flowid 1:2 tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 \ match ip src 11.0.0.3/32 flowid 1:3
La disciplina de colas de prioridad puede provocar retrasos y pérdidas de paquetes en la clase menos prioritaria 1:3 si hay mucho tráfico en 1:1 y 1:2.
Para solventar que TCP se vea perjudicado con PFIFO, se podría clasificar tráfico TCP en 1:1 y el UDP en 1:2. Sin embargo, si hubiera muchos datos para TCP, los mecanismos de control de congestión de TCP provocarían que la tasa de envío fuera aumentando cada vez más mientras no se perdieran paquetes, viéndose en este caso UDP perjudicado ya que mientras hubiera tráfico en 1:1 no se cursaría el resto de tráfico.
Token Bucket Filter (TBF) para el tráfico de salida
TBF limita la velocidad del tráfico de salida de una determinada interfaz de un router a través de los parámetros:
ancho de banda: velocidad de generación tokens
tamaño de la cubeta: para almacenar tokens que permitirán enviar ráfagas que superen el ancho de banda.
latencia: tiempo máximo de espera de un paquete por un token.
Ejemplo: Aplicar TBF en la interfaz de salida eth1 de un router. Ancho de banda 7Mbps , tamaño de cubeta 10k (en bytes), latencia 50 ms:
tc qdisc add dev eth1 handle 1: root tbf rate 7Mbit \ burst 10k latency 50ms
TBF y PRIO
TBF limita la velocidad del tráfico de salida de una determinada interfaz para todos los flujos que lo atraviesan.
Se puede definir una disciplina de cola PRIO hija de TBF para que el tráfico además de estar limitado por TBF los paquetes se cursen atendiendo a las prioridades definidas en PRIO:
tc qdisc add dev eth1 handle 1: root tbf rate 7Mbit \ burst 10k latency 50 ms tc qdisc add dev eth1 parent 1:0 handle 10:0 prio tc filter add dev eth1 parent 10:0 prio 1 protocol ip u32 \ match ip src 101.0.0.10/32 flowid 10:1 tc filter add dev eth1 parent 10:0 prio 2 protocol ip u32 \ match ip src 102.0.0.20/32 flowid 10:2 tc filter add dev eth1 parent 10:0 prio 3 protocol ip u32 \ match ip src 103.0.0.30/32 flowid 10:3
Hierarchical Token Bucket (HTB) para el tráfico de salida
TBF se utiliza cuando se desea que todo el tráfico que sale por una determinada interfaz tenga unas características determinadas en cuanto a ancho de banda, tamaño de cubeta y latencia.
HTB es necesario cuando se quiere clasificar el tráfico que sale por una determinada interfaz en varias clases, cada uno de ellas con unas características diferentes de ancho de banda.
Si alguna clase no utiliza todo el ancho de banda que se le ha definido, dependiendo de la configuración, se podría utilizar dicho ancho de banda para algún otra clase que lo necesite.
Ejemplo:
Definición de HTB con ancho de banda máximo de salida de 10Mbps de la interfaz eth0. Se quiere repartir este ancho de banda:
usuarioA (4Mbps): lo usará para tráfico HTTP (3Mbps) y tráfico de correo (1Mbps)
el usuarioB (6Mbps)
```
tc qdisc add dev eth0 root handle 1:0 htb
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 4Mbit ceil 10Mbit
tc class add dev eth0 parent 1:2 classid 1:10 htb rate 3Mbit ceil 10Mbit
tc class add dev eth0 parent 1:2 classid 1:11 htb rate 1Mbit ceil 10Mbit
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 6Mbit ceil 10Mbit
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \
match ip src 1.1.1.1 \
match ip dport 80 0xffff \
flowid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \
match ip src 1.1.1.1 \
match ip dport 25 0xffff \
flowid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \
match ip src 2.2.2.2 \
flowid 1:12
```
Unidades para tc
Ancho de banda
Abreviatura | Unidades ------------|--------------------- kbps | Kilobytes per second mbps | Megabytes per second kbit | Kilobits per second mbit | Megabits per second bps | Bytes per second
Cantidad de datos
Abreviatura | Unidades ------------|--------------------- kb o k | Kilobytes mb o m | Megabytes kbit | Kilobits mbit | Megabits b | Bytes
Tiempo
Abreviatura | Unidades -----------------|--------------------- s, sec o secs | Segundos ms, msec o msecs | Milisegundos us, usec, usecs | Microsegundos
DiffServ
Marcado del tráfico DiffServ en la cabecera IPv4
- Los paquetes se marcan en el campo de 8 bits Type of Service (ToS) de IPv4
Marcado del tráfico DiffServ: campo DSCP
Se usan 6 bits para identificar Differentiated Service Code Point (DSCP) que determinan el comportamiento por salto (PHB, Per-Hop Behavior) que recibirá el paquete en los routers de la red DiffServ.
Quedan los 2 bits menos significativos del campo ToS que no se usan para DiffServ, sino para la notificación de congestión (Explicit Congestion Notification, ECN). ECN es utilizado conjuntamente por los extremos de una conexión TCP y los routers intermedios que usan la disciplina de cola RED, Random Early Detection.
Comportamiento por salto (PHB)
Cada clase de tráfico (DSCP) está asociado a un comportamiento por salto (PHB, Per Hop Behavior). El PHB determina el tipo de tratamiento que se le va a dar al paquete en el reenvío:
Reserva de recursos: buffer y ancho de banda.
Características del tráfico: retardo y pérdidas.
DiffServ no especifica las características concretas del tráfico en cada una de las clases, sólo proporciona la clasificación con diferentes códigos DSCP.
Existen los siguientes grupos de PHB asociados al campo DSCP:
EF (Expedited Forwarding): DSCP=
- Bajas pérdidas, baja latencia, bajo jitter, simiar a una línea de datos alquilada.
VA (Voice Admit): DSCP=
- Similar a EF que añade un mecanismo de control de admisión de llamadas.
AF (Assured Forwarding): 4 clases (AF1, AF2, AF3, AF4)
Se proporciona cierta garantía de entrega siempre y cuando se cumpla el acuerdo entre cliente y proveedor sobre el tráfico enviado.
Define 4 clases. Prioridad AF4 $>$ Prioridad AF3 $>$ Prioridad AF2 $>$ Prioridad AF1.
DF (Default Group): DSCP=
- IP Best Effort (compatible con tráfico que no es DiffServ)
CS (Class Selector): usa los 3 primeros bits DSCP=000 para definir prioridades (compatible con el antiguo ToS).
- Menor prioridad = 000 a mayor prioridad = 000
Marcas en los paquetes: Valores DS y DSCP
- El valor DS son 8 bits que viajan en el campo Tipo de Servicio de la cabecera IP. Estos 8 bits son en realidad DSCP (6 bits) + ECN (2 bits).
Disciplina de cola DSMARK
DSMARK es una qdisc que se utiliza para la clasificación de paquetes según la arquitectura de DiffServ y el marcado del campo DS.
Probaremos la función de marcado del campo DS:
- Routers frontera de DiffServ: es necesario clasificar los paquetes atendiendo a valores de su cabecera IP y marcar el campo DS.
Probaremos la función de clasificación según el campo DS:
- Routers del núcleo de DiffServ: Los paquetes se clasifican atendiendo al contenido de DS que traen los paquetes IP para posteriormente realizar su tratamiento según diferentes disciplinas de cola.
Clases de tráfico
Una qdisc DSMARK crea automáticamente un conjunto de clases para asignar en cada una de ellas un valor diferente en el campo DSCP.
Al crear la qdisc DSMARK es necesario especificar la cantidad máxima de valores DSCP que se van a usar para clasificar los paquetes. Este valor debe ser una potencia de 2.
Por ejemplo, la siguiente qdisc con número de clases igual a $2^3=8$ podrá definir como máximo 7 valores DSCP diferentes, uno para cada una de sus clases:
tc qdisc add dev eth1 handle 1:0 root dsmark indices 8
Una vez creada una qdisc DSMARK se habrán creado automáticamente sus clases asociadas. Cada clase tiene un descriptor X:Y, donde:
X es el valor del número mayor de la clase qdisc a la que pertenece
Y es el número menor que distingue a cada una de las clases
Por ejemplo, para definir como máximo 7 clases de tráfico dentro de una qdisc se usarán los siguientes descriptores: 1:1, 1:2, 1:3, 1:4, 1:5, 1:6, 1:7. El número mayor coincide en todas ellas, ya que todas pertenecen a la qdisc .
Uso del filtro tcindex
en el Router Frontera
Para configurar un valor DS en un paquete IP se utiliza una clase DSMARK en la que se van a realizar las siguientes operaciones:
operación $\&$ de bits con una máscara para mantener aquellos bits del campo DS que se deseen (0x03, mantiene los 2 bits menos significativos donde viaja ECN)
operación $|$ de bits con el nuevo valor DS que se desee asignar.
Por ejemplo: si la clase 1:3 marca con DS=0x68 (AF31) conservando los bits ECN:
tc class change dev eth1 classid 1:3 dsmark mask 0x3 value 0x68
Al recibirse un paquete IP en un router, se almacena en un buffer.
Cuando un paquete atraviesa la disciplina de cola de entrada
qdisc ingress
, el buffer que almacena el paquete IP dentro del kernel del router Linux tiene un campotc_index
en el que se almacena el identificador de flujo en el que fue clasificado dicho paquete cuando ingresó en la cola qdisc ingress:- si un paquete queda clasificado en
flowid :2
, el campotc_index
almacenaría el valor 2.
- si un paquete queda clasificado en
Esta información es la que utiliza posteriormente el filtro tcindex dentro de otras qdisc de dicho router para dar tratamiento diferenciado a los paquetes.
```
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: \
protocol ip prio 4 u32 \
match ip src 11.0.0.100/32 \
police rate 1mbit burst 10k continue flowid :1
tc filter add dev eth0 parent ffff: \
protocol ip prio 5 u32 \
match ip src 11.0.0.100/32 \
police rate 512kbit burst 10k continue flowid :2
tc filter add dev eth0 parent ffff: \
protocol ip prio 6 u32 \
match ip src 11.0.0.100/32 \
police rate 256kbit burst 10k drop flowid :3
tc filter add dev eth0 parent ffff: \
protocol ip prio 6 u32 \
match ip src 0.0.0.0/0 \
police rate 128kbit burst 10k drop flowid :4
```
Cuando un paquete atraviesa la disciplina de cola de entrada, el buffer que contiene el paquete tiene un campo donde se ha almacenado el descriptor del flujo al que pertenece:
tc_index
.Ejemplo: Los paquetes clasificados dentro del
flowid=:1
llevarán en el campotc_index=1
EL filtro utiliza el valor almacenado en
tc_index
del buffer que contiene un paquete IP para clasificarlo dentro de una clase en la disciplina de cola de salida, en este caso DSMARK.Ejemplo:
qdisc DSMARK con 3 diferentes valores de marcado
tc qdisc add dev eth1 handle 1:0 root dsmark indices 8 tc class change dev eth1 classid 1:1 dsmark mask 0x3 value 0x28 tc class change dev eth1 classid 1:2 dsmark mask 0x3 value 0x48 tc class change dev eth1 classid 1:3 dsmark mask 0x3 value 0x68 tc class change dev eth1 classid 1:4 dsmark mask 0x3 value 0x88 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 1 tcindex classid 1:1 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 2 tcindex classid 1:2 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 3 tcindex classid 1:3 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 4 tcindex classid 1:4
Los paquetes entran en el router y atraviesan la cola ingress, donde se rellena el campo
tc_index
.Dentro de la cola DSMARK en la interfaz de salida, se comprueba el valor de
tc_index
y se clasifica el tráfico en las clases de DSMARK, que marcarán los paquetes con un determinado valor de DS.
Uso del filtro tcindex
en el Router de Núcleo
En el router del núcleo, el paquete llega con DS relleno.
Si el router no tiene configurada una disciplina de cola ingress, inicialmente no se rellena el campo
tc_index
del buffer del kernel del Linux que contiene el paquete.La propia qdisc DSMARK puede copiar el campo DS que lleva la cabecera IP del paquete en el campo
tc_index
de la estructura de datos del kernel del Linux que almacena el paquete utilizando el siguiente parámetro:tc qdisc add dev eth1 handle 1:0 root dsmark indices 8 set_tc_index
Como se copia el campo DS, el filtro deberá utilizar sólo los 6 bits más significativos del campo DS, es decir, DSCP para clasificar los paquetes. Es necesario extraer esos 6 bits (operación & con y desplazamiento a la derecha 2 bits) del campo DSCP:
tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ tcindex mask 0xfc shift 2
A continuación se puede usar otra disciplina de cola encadenada con DSMARK para realizar la planificación de paquetes que se desee, por ejemplo HTB:
tc qdisc add dev eth1 parent 1:0 handle 2:0 htb tc class add dev eth1 parent 2:0 classid 2:1 htb rate 1Mbit tc class add dev eth1 parent 2:1 classid 2:10 htb rate 800kbit ceil 1Mbit # Tráfico AF11=> DS=0x28 =00101000 => DSCP=001010=0x0a tc filter add dev eth1 parent 2:0 protocol ip prio 1 \ handle 0x0a tcindex classid 2:10
- Ejemplo completo:
tc qdisc add dev eth1 handle 1:0 root dsmark indices 8 set_tc_index
tc filter add dev eth1 parent 1:0 protocol ip prio 1 \
tcindex mask 0xfc shift 2
tc qdisc add dev eth1 parent 1:0 handle 2:0 htb
tc class add dev eth1 parent 2:0 classid 2:1 htb rate 1Mbit
tc class add dev eth1 parent 2:1 classid 2:10 htb rate 800kbit ceil 1Mbit
# Tráfico AF11=> DS=0x28 =00101000 => DSCP=001010=0x0a
tc filter add dev eth1 parent 2:0 protocol ip prio 1 \
handle 0x0a tcindex classid 2:10
Iperf: Generador de tráfico
Iperf es una aplicación que permite generar tráfico TCP o UDP y medir el ancho de banda que se está utilizando entre dos máquinas finales.
Iperf funciona en modo cliente/servidor.
Utilizaremos Iperf para generar tráfico UDP desde el cliente al servidor durante 10 segundos a una determinada velocidad y medir el ancho de banda que en realidad se ha utilizado.
Arrancaremos Iperf de la siguiente forma:
Servidor
iperf -u -s
- Cliente
iperf -u -c <dirIPServidor> -b <anchoDeBanda>
Resultado de la ejecución de Iperf
Resultado de ejecución de Iperf en 12.0.0.30, en modo servidor:
iperf -s -u --------------------------------------------------- Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 108 KByte (default) --------------------------------------------------- [3] local 12.0.0.30 port 5001 connected with 11.0.0.10 port 32768 [3] 0.0- 9.7 sec 25.2 MBytes 21.8 Mbits/sec 0.289 ms 4940/22916 (22\%) [3] 0.0- 9.7 sec 1 datagrams received out-of-order
Resultado de ejecución de Iperf en 11.0.0.10, en modo cliente:
iperf -u -c 12.0.0.30 -b 100M --------------------------------------------------- Client connecting to 12.0.0.30, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 108 KByte (default) --------------------------------------------------- [3] local 11.0.0.10 port 32768 connected with 12.0.0.30 port 5001 [3] 0.0- 10.0 sec 32.1 MBytes 26.9 Mbits/sec [3] Sent 22917 datagrams [3] Server Report: [3] 0.0- 9.7 sec 25.2 MBytes 21.8 Mbits/sec 0.289 ms 4940/22916 (22\%) [3] 0.0- 9.7 sec 1 datagrams received out-of-order
Wireshark
Gráficas de ancho de banda (I)
Seleccionar en el menú de Wireshark
Statistics
$->$IO Graphs
.Especificar en la casilla
Filter
, el filtro de Wireshark que selecciona los paquetes según los criterios que se deseen. Ejemplo en Filter1:ip.src==11.0.0.1
. Pulsar sobre el botónGraph 1
para visualizar la gráfica.Para distinguir el tráfico de varias fuentes la condición de filtrado puede completarse con la comprobación de la dirección IP y puerto TCP/UDP. Ejemplo:
ip.src==11.0.0.1 and udp.dstport==5001
Si no se escribe nada en la condición de filtrado, se muestra la gráfica de todo el tráfico capturado.
Es importante seleccionar adecuadamente las unidades que muestra la gráfica. Para las pruebas que vamos a realizar en las prácticas se recomienda:
X Axis -> Tick interval: 1 sec
X Axis -> Pixels per tic: 10
Y Axis -> Unit: Bits/Tic
Y Axis -> Scale: Auto
Campo DS en una captura de Wireshark
Gráficas de ancho de banda en diferentes clases DiffServ
Seleccionar en el menú de Wireshark
Statistics
$->$IO Graphs
.Especificar en la casilla
Filter
, el filtro de Wireshark que selecciona los paquetes marcados con diferentes DSCP. Ejemplo en Filter1: ip.dscp==0x28. Pulsar sobre el botónGraph 1
para visualizar la gráfica.Para distinguir el tráfico de varias fuentes la condición de filtrado puede completarse con la comprobación de la dirección IP. Ejemplo: ip.dscp==0x28 and ip.src==11.0.0.1
Si no se escribe nada en la condición de filtrado, se muestra la gráfica de todo el tráfico capturado.
Es importante seleccionar adecuadamente las unidades que muestra la gráfica. Para las pruebas que vamos a realizar en las prácticas se recomienda:
X Axis $\rightarrow$ Tick interval: 1 sec
X Axis $\rightarrow$ Pixels per tic: 10
Y Axis $\rightarrow$ Unit: Bits/Tic
Y Axis $\rightarrow$ Scale: Auto