Control de tráfico y DiffServ en Linux

Introducción

  • tc (Traffic Control) es una herramienta que permite realizar el control de tráfico en Linux.

  • tc utiliza disciplinas de colas, denominadas qdisc (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 dicha qdisc 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.

image

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. image

    • 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).

      image

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 a ffff: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 a 1: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.

    image

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).

image

     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)

    image

```
  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

image

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.

image

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). image

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:

    1. 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)

    2. operación $|$ de bits con el nuevo valor DS que se desee asignar.

    image

  • 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 campo tc_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 campo tc_index almacenaría el valor 2.
  • 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.

    image

  • Ejemplo: Los paquetes clasificados dentro del flowid=:1 llevarán en el campo tc_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.

image

image

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ón Graph 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

    image

Campo DS en una captura de Wireshark

image

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ón Graph 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

    image

results matching ""

    No results matching ""