Class of Service (CoS) permite tratar los tipos de tráfico de manera diferente para asegurar en ancho de banda, retardo o la cantidad de paquetes perdidos adecuada para cada uno. No elimina la congestión, pero nos ayuda a prevenir el daño al tráfico más sensible.
Clasificación de Tráfico
Cuando el tráfico entra al puerto, CoS examina la configuración de la trama o la cabecera. El switch usa esta información para clasificar el tipo de tráfico, se asocia a una "clase de envío" (forwarding class) y a una "prioridad de paquetes" (loss priority) y a la correspondiente cola de salida basándose en estos datos.
Estos valores pueden basarse en Behavior Aggregate (BA), que es el más usado o, en MultiField (MF), que puede usar datos como ip, protocolo,puerto, etc. Ambos pueden configurarse a la vez pero siempre se comprueba primero el BA. Si entran en conflicto se impone el MF.
Nota: cuando el switch aprende la mac por primera vez, esa trama se envía a la cola de salida sin tener en cuenta el "classifier" que está aplicado en la interface de salida.
Hay 3 tipos de "classifiers" en BA para los switches EX:
- DSCP
- IP Precedence
- 802.1p
Podemos configurar un nombre para los códigos fijos de los classifiers:
- set class-of-service code-point-aliases dscp XXX 101110
Clases de Envío
El siguiente paso es asociar esa clase de tráfico con una clase de envío (forwarding class) basándose en esos datos. Si tiene que reescribir algo de la configuración de CoS, lo hace antes de mandarlo a la cola de salida. Los switches EX de Juniper soportan 16 "forwarding class" y 8 colas de salida.
Control de Congestión
Tenemos una serie de mecanismos que podemos usar para evitar que la congestión sea inmanejable.
Drop Profiles
Dependiendo del modelo de EX, pueden soportar WTD o WRED.
- WTD: cuando la cola llega a un límite (por defecto 100%) empieza a descartar paquetes.
- WRED: cuando la cola llega a un límite, gradual y aleatoriamente empieza a descartar paquetes con la opción de "loss priority" (PLP) en "low" (baja) o high (alta). Los que tienen la opción high tienen más probabilidad de ser descartados. Junos soporta dos implementaciones de WRED:
- Segmented
- Interpolated
En los switches que soporten WRED se podrán configurar varios Drop Profiles para notificar a la cola que empiece a descartar.
root@EX> show configuration
class-of-service {
drop-profiles {
limite-75 {
fill-level 75;
}
}
}
Los Drop Profiles se vinculan con colas individuales a través de los "schedulers" que veremos más tarde.
Rate Limiting
Tenemos 2 herramientas para limitar:
- Policing: puede descartar el paquete o modificar el PLP cuando llega a un límite. Solo se puede aplicar al tráfico de entrada. Se configura en la parte de "firewall" y se aplica en la interface.
- Shaping: puede configurar el ancho de banda del puerto para que sea más bajo (port shaping) o, configurar el límite a las colas (queue shaping)
Scheduler
El control de las colas lo hacemos a través de los "schedulers" y los "scheduler maps". Estos contiene parámetros que describen como actúa. Un "scheduler" se vincula con una forwading y una cola en particular.
El orden de los paquetes lo definimos con una priority y un transmission rate para una forwarding class. Se puede configurar un transmission rate (que controla el ancho de banda aplicado) para cada forwarding class.
Por defecto, los EX asignan el 95% del ancho de banda a la cola 0, que está vinculada a la forwarding class "best-effort". Y asigna el 5% restante a la cola 7, que es la forwarding class "network-control". A las demás colas les asigna un transmission rate de 0. Si configuramos estas, deberemos asignarles un %.
Cuando una cola está congestionada y otra no, puede usar el ancho de banda de esta.
Prioridad de Cola
Determina el orden de salida de un interface desde las colas de salida. Ex soporta 2 tipos:
- Low: si el tráfico está dentro de los límites de ancho de banda no hace nada, pero si lo pasa, lo marca como "out-of-profile" y solo transmite si el ancho de banda está disponible, si no, se quedará en el buffer.
- Strict-High: trato preferente sobre lo marcado con "low". Tiene asignado un ancho de banda ilimitado. Dentro de las 7 colas (7-0), en caso de conflicto elegirá la más alta primero.
Por defecto,los puertos de acceso usan el "classifier" ieee8021p-untrust. Lo clasifica como tráfico "best effort".
Los puertos trunk usan el ieee8021p-default, que asigna "best effort" o "network-control" dependiendo de los bits del CoS.
 |
| Con show interface X extensive vemos el % de las colas |
Hay series de Ex como la 8200 que a parte de tener colas del 0 al 7, tienen también una "multicast best effort".
Los Ex, por defecto, no reescriben los bits de CoS.
 |
| Encima de "Classifier" aparecería una regla aplicada |
Junos tiene una regla (rule) que podemos aplicar para reescribir con datos estándares.
- set class-of-service interface X rewrite-rules dscp (default | custom)
Una vez aplicada en la interface la regla default que viene en Junos, vemos la regla en el último comando.
Si queremos cambiar este comportamiento por defecto, tendremos que crear nuestra configuración.
Habilitamos la Clasificación de BA. Elegimos DSCP:
root@EX> show configuration
class-of-service {
classifiers {
dscp Mi-DSCP {
import-default; - para las asignaciones no especificadas
forwarding-class expedited-forwarding {
loss-priority low code-points ef;
}
forwarding-class network-control {
loss-priority low code-points [ cs3 af31 ];
}
forwarding-class assured-forwarding {
loss-priority low code-points af41;
}
}
}
interfaces {
xe-0/0/0 {
unit 0 {
classifiers {
dscp MI-DSCP;
}
}
}
}
Ahora definimos los "schedulers". Uno por cada cola que queramos. Vamos a configurar el más típico, el de 4 niveles:
root@EX> show configuration
class-of-service {
schedulers {
expedited-forwarding {
buffer-size percent 25;
priority strict-high;
}
network-control {
buffer-size percent 5;
priority strict-high;
}
assured-forwarding {
transmit-rate percent 65;
buffer-size percent 30;
priority low;
}
best-effort {
transmit-rate percent 35;
buffer-size percent 40;
priority low;
}
}
}
La razón de los schedulers que no tienen configurado un transmit rate es porque son "strict-high" y estas toman todo el ancho de banda que requieran.
Por último, creamos el "scheduler map" para aplicarlo a la interface.
root@EX> show configuration
class-of-service {
scheduler-map {
MI-SCHEDULER-MAP {
forwarding-class best-effort scheduler best-effort;
forwarding-class expedited-forwarding scheduler expedited forwading
forwarding-class assured-forwarding scheduler assured-forwarding
forwarding-class network-control scheduler network-control
}
}
}
interfaces {
xe-0/0/0 {
scheduler-map MI-SCHEDULER-MAP
classifiers {
dscp MI-DSCP;
}
}
}
}
- show class-of-service forwarding-class
- show class-of-service classifier
No hay comentarios:
Publicar un comentario