CoS se ha vuelto fundamental en las redes de hoy gracias al desarrollo e implementación especialmente de la VoIP en las redes de hoy, aunque ya se venía usando para "limitar" el tráfico de datos. La VoIP es muy sensible al delay y al jitter, pudiendo afectar seriamente al servicio.
Los componentes que se integran en CoS son:
- Traffic Classification
- Policing
- Queuing
- Scheduling
- Rewrite Rules
Cuando un paquete entra en una interface que tiene confiugrado CoS, el equipo examina los campos en la cabecera del paquete. CoS es capaz de usar estos campos para diferenciar los tipos de de tráfico y asignarles una clase de tráfico. Este proceso es el llamado "Traffic Classification".
Hay muchas maneras de clasificar el tráfico pero el más usado es DSCP, que está basado en los 6 bit del campos ToS (type of service) de la cabercera. Los 3 primeros bits tienen la información de Ip Precedence, que en realidad es otra forma de clasificar el tráfico al igual que DSCP pero menos completa si la usamos sola, y los 3 siguientes tendría la información de la ip origien, destino y puertos a usar.
Una vez clasificados los paquetes, estos son asignados a una "forwarding class" (clase de envío), que a su vez se asgina a una cola de salida (output queue). Recordad que na interface física puede tener varias colas de salida.
La clasificación del tráfico se basa en políticas (policing). Si la cantidad total de tráfico es mayor de lo que puede gestionar la interface, algunos paquetes se descartarán. Si tenemos CoS aplicado en la interface, los descartes de paquetes no serán aleatorios, sino basados en la configuración que hayamos hecho, especialmente para que no descarte el tráfico más sensible como la VoIP.
Una vez que los paquetes son clasificados en base a las políticas, entonces se les asigna la cola de salida (queuing). Cada cola de salida tiene asignado un "ratio de transmision" (transmision rate) que define como la cantidad de paquetes que se van a transmitir en un intervalo concreto de tiempo. A esto se le llama "scheduling". Normalmente este ratio se define en "ancho de banda" o en un "tanto por ciento" del ancho de banda de la interface que puede usar. Las colas de salida también tienen asignada un porcentaje de memoria física de la interface para mantener los paquetes hasta que les toca salir. Este espacio de memoria se llama "buffer".
El siguiente paso es la reescritura de los bits del ToS. Las reglas para la manipulación de estos bits (rewrite rules) ayuda a mantener la estabilidad de la clasificación del tráfico según se va transportando por la red.
Un ejemplo de configuración de CoS por defectO
Nota: he intentado por todos los medios emular esta práctica pero ni con los equipos virtuales ni con SRX reales me ofrecen todos los comando, así que directamente publico lo que Juniper explica, pero no es real.
Nos reportan que están fallando los teléfonos. El tráfico VoIP de los clientes se está marcando como Expedited Forwarding (EF de DSCP).
Creamos un filtro y lo aplicamos a la interface para comprobar que los paquetes nos están entrando marcados con EF:
- set firewall filter ef term 1 from dscp ef
- set firewall filter ef term 1 then count ef
- set interfaces ge-0/0/1 unit 0 family inet filter input ef
 |
| show firewall filter ef |
Aunque el filtro muestra el impacto de los paquetes en EF, si miramos los contadores de la interface, los vemos en la clase de Network-Control:
 |
| show interfaces ge-0/0/1 extensive | find "Queue counters" |
Vamos a configurar el "classifier" para que el tráfico EF impacté en la clase apropiada. Para ello, importamos la configuración del classifier Behavior Aggregate (BA) que Junos trae por defecto para el marcado de DSCP y la aplicamos a la interface por donde entra el tráfico. Esto habría que hacerlo también en SRX-2
- set class-of-service classifiers dscp VoIP import default
- set interfaces ge-0/0/1.0 classifiers dscp VoIP
Si metiéramos el comando para ver los contadores, los impactos deberían verse en EF:
- show interfaces ge-0/0/1 extensive | find "Queue counters"
 |
| show interfaces ge-0/0/1 extensive | find "CoS information" |
Vemos la reserva de % que hace la configuración por defecto del CoS aplicado. Tendríamos que estar viendo descartes de tráfico ya que no tiene reservado nada para la clase EF.
Estas reservas se hacen con los "schedulers". Configuramos uno para ajustar esto (también en SRX-2):
root@BOLSA# show | compare
[edit class-of-service]
schedulers {
expedited-forwarding {
priority high;
}
best-effort {
transmit-rate percent 80;
priority low;
}
network-control {
transmit-rate percent 8;
priority low;
}
}
Le hemos subido la prioridad y ahora debería aparecernos con una reserva del 12% para EF.
Para asegurarnos que el tráfico de VoIP con EF no nos deja sin poder procesar otras clases, tendremos que limitar la cantidad de tráfico que permitimos. Esto lo hacemos con un Policer. Vamos a hacer que cualquier tráfico que supere los 2 Mbps se clasifique como Best-Effort:
root@BOLSA# show | compare
[edit interfaces ge-0/0/1 unit 0 family inet filter]
- input ef;
+ input VoIP-excesivo;
[edit firewall]
+ policer VoIp-excesivo {
+ if-exceeding {
+ bandwidth-limit 2m;
+ burst-size-limit 25k;
+ }
+ then forwarding-class best-effort;
+ }
[edit firewall]
filter ef { ... }
+ filter VoIP-excesivo {
+ term ef {
+ from {
+ dscp ef;
+ }
+ then policer VoIp-excesivo;
+ }
+ }
Cómo procesa el CoS en equipos de capa 3 se divide en dos etapas: la de entrada y la de salida del tráfico.
Procesamiento CoS del tráfico en entrada:
- BA Classification: en este paso se asigna la "forwarding-class" y el "packet loss priority" usando Ip Precedence, DSCP, 802.1p, etc.
- Multifield Classification: busca si hay un filtro creado para asignar el forwarding class y el packet loss priority. Machacaría la configuración anterior.
- Ingress Policing: con otro filtro podemos limitar el tráfico para descartar, reclasificar, o marcar el exceso de tráfico con una loss priority. Ya sabemos que en caso de congestión se puede usar RED (randomly early detection) que es una manera más agresiva que loss priority (PLP)
- Forwarding policy: puede alterar la configuración de la forwarding class o la PLP. Podemos usarla también para seleccionar el next hop basándonos en la forwarding class con CBF (class-of-service based forwarding).
 |
| Las opciones que tenemos |
Procesamiento CoS del tráfico en salida:
- Egress policing: después del "lookup", se aplica la política de salida. Aquí se marca el tráfico en exceso para descartarlo o marcarlo con PLP para descartarlo posteriormente.
- Queuing and scheduling: se mete al paquete en la cola correspondiente en base a la prioridad asignada
- WRED/RED/Congestion Control: se toman las decisiones de descarte basadas en protocolo, loss priority, etc
- Rewrite Marker: aquí es donde podemos reescribir las marcas del paquete cuando se retransmite a otros equipos. Normalmente se suele configurar para que coincida con la configuración de CoS del equipo al que se lo enviamos (Best Effort, Network-Control, Expedited Forwarding, etc)
Configuración de un BA y aplicación a una interface
root@router# show | compare
[edit]
class-of-service {
classifiers {
inet-precedence PRUEBA {
forwarding-class best-effort {
loss-priority low code-points 001;
}
}
}
interfaces {
ge-0/0/1 {
unit 0 {
classifiers {
inet-precedence PRUEBA;
}
}
}
}
}
Configuración de Multifield Classification
Se implementa a través de un "Firewall Filter". El BA se procesa primero, pero podemos aplicar el multifield classification en combinación con BA. Sin embargo, en caso de conflicto, la forwarding class que se aplicará será la del Multifield Classification.
root@router# show | compare
[edit interfaces ge-0/0/0 unit 0 family inet]
filter {
input MF;
}
[edit]
firewall {
filter MF {
term 1 {
from {
protocol udp;
destination-port 20000;
}
then {
loss-priority low;
forwarding-class assured-forwarding;
}
}
}
}
Configuración de Rewrite Marker
El marcado se suele hacer al final de nuestra red, cuando el tráfico sale de nuestra red. Al igual que el BA, podemos importar una configuración por defecto.
 |
| show class-of-service rewrite-rules |
root@router# show | compare
[edit class-of-service interfaces ge-0/0/1 unit 0]
+ rewrite-rules {
+ dscp PRUEBA;
+ }
[edit class-of-service]
+ rewrite-rules {
+ dscp PRUEBA {
+ import default;
+ forwarding-class best-effort {
+ loss-priority low code-point 000001;
+ }
+ }
+ }
Configuración de Scheduling y Queuing
Por defecto, el Scheduler se aplica a nivel de interface física. Esto se ajusta perfectamente excepto si tenemos más de una unidad lógica en esa interface (subinterfaces). Si nos sucede esto, tendremos que usar la opción "per-unit-scheduler".
root@router# show | compare
[edit class-of-service interfaces ge-0/0/1]
scheduler-map PRUEBA-MAP;
[edit class-of-service]
scheduler-maps {
PRUEBA-MAP {
forwarding-class expedited-forwarding scheduler PRUEBA;
}
}
schedulers {
PRUEBA {
transmit-rate percent 60;
buffer-size percent 35;
priority high;
drop-profile-map loss-priority low protocol any drop-profile ALTO;
}
}
La prioridad para enviar el tráfico de mejor a peor es:
- strict-high, high, medium-high, medium-low, low
El Transmit-Rate nos da varias opciones. Podemos decirle que use lo que queda de ancho de banda a una clase (remainder) o que fuerce a un porcentaje exacto (exact). Ojo, que las dos juntas no se pueden combinar. También se puede configurar en bits-per-seconds (rate):
El buffer-size se puede configurar en porcentaje o en tiempo (1 - 200.000 microsegundos). Significa el retardo de la cola (queue) para acomodar las ráfagas de tráfico (burst), es decir, lo usamos para controlar la congestión a la hora de sacar el tráfico. Tenemos también la opción de "remainder" y otra más, la "temporal".
El control de la congestión lo hacemos con WRED, que básicamente se usa para evitar el descarte indiscriminado de paquetes. Le decimos al equipo que, en caso de tener que descartar, lo haga de una maneta concreta. Para ello, se configuran perfiles de descarte (drop profiles). Si no configuramos estos perfiles, Junos, por defecto, descarta todo cuando se llega al 100% de la capacidad de envío.
Junos soporta has 4 perfiles y pueden ser para TCP, UDP o para ambos:
Tomando como referencia el ejemplo anterior del Scheduling configuraríamos:
[edit class-of-service]
drop-profiles {
ALTO {
fill-level 35 drop-probability 0;
fill-level 50 drop-probability 10;
fill-level 70 drop-probability 20;
}
}
Políticas para limitar la entrada de tráfico
Estas políticas están basadas en lo que Junos llama Tokens y en paquetes IP. Limitamos por tanto el ancho de banda y las ráfagas que nos llegan. Se establece un tamaño de las ráfagas y, con ello, se establece un número de tokens. Cada vez que se manda un paquete, se quita un token. Cuando el equipo se queda sin tokens, entonces se aplica la política para ajustar el ancho de banda. Las acciones de esta política pueden ser o el descarte del paquete, marcarlo con un loss priority diferente (PLP) o asignarles una forwarding class diferente.
Un ejemplo práctico
Con esta topología debemos cumplir:
- Descartar tráfico con destino al puerto 80 si supera los 50Mbps
- Establecer el loss-priority en high y clasificarlo en la cola Best Effort si la clase de EF supera los 100Mbps
- El resto del tráfico debe ser enviado a la cola Best-Effort y establecer un loss-priority a high si supera los 150Mbps.
Para cumplir el primer objetivo:
root# show | compare
[edit]
+ firewall {
+ policer HTTP {
+ if-exceeding {
+ bandwidth-limit 50m;
+ burst-size-limit 625k;
+ }
+ then discard;
+ }
+ }
root# show | compare
[edit firewall]
+ family inet {
+ filter INTERNET {
+ interface-specific;
+ term HTTP-PUERTO-80 {
+ from {
+ destination-port http;
+ }
+ then policer HTTP;
+ }
+ }
+ }
Para cumplir el segundo objetivo:
root# show | compare
[edit firewall]
+ policer VoIP {
+ if-exceeding {
+ bandwidth-limit 100m;
+ burst-size-limit 625k;
+ }
+ then {
+ loss-priority high;
+ forwarding-class best-effort;
+ }
+ }
root# show | compare
[edit firewall family inet filter INTERNET]
+ term VoIP {
+ from {
+ dscp ef;
+ }
+ then policer VoIP;
+ }
Para cumplir el tercer objetivo:
root# show | compare
[edit firewall]
+ policer TODOS {
+ if-exceeding {
+ bandwidth-limit 150m;
+ burst-size-limit 625k;
+ }
+ then {
+ loss-priority high;
+ forwarding-class best-effort;
+ }
+ }
root# show | compare
[edit firewall]
policer VoIP { ... }
+ policer TODOS {
+ if-exceeding {
+ bandwidth-limit 150m;
+ burst-size-limit 625k;
+ }
+ then {
+ loss-priority high;
+ forwarding-class best-effort;
+ }
+ }
Al final nos quedaría así:
Por último, nos faltaría aplicarlo a las interfaces:
- set interfaces ge-0/0/X.0 family inet filter input INTERNET
Y para comprobar: show firewall
No hay comentarios:
Publicar un comentario