CoS para interfaces PPP y MLPPP en enrutadores de la serie ACX
Junos CoS le permite dividir el tráfico en clases y ofrecer varios niveles de transferencia de datos y pérdida de paquetes cuando se produce congestión. Esta funcionalidad permite que la pérdida de paquetes ocurra de acuerdo con las reglas que configure. Las funciones de CoS de Junos proporcionan un conjunto de mecanismos que puede usar para proporcionar servicios diferenciados cuando la entrega de tráfico de máximo esfuerzo es insuficiente.
Las funcionalidades de CoS son compatibles con las interfaces PPP y MLPPP. Se admiten hasta cuatro clases de reenvío y cuatro colas por interfaz lógica para paquetes PPP y MLPPP.
CoS para interfaces PPP y MLPPP no es aplicable en enrutadores ACX5048 y ACX5096.
Las funciones CoS de Junos OS proporcionan un conjunto de mecanismos que puede utilizar para proporcionar servicios diferenciados cuando la entrega de tráfico de máximo esfuerzo es insuficiente. Al diseñar aplicaciones de CoS, debe tener muy en cuenta sus necesidades de servicio, y debe planificar y diseñar minuciosamente su configuración de CoS para garantizar la coherencia en todos los dispositivos de enrutamiento en un dominio de CoS. También debe tener en cuenta todos los dispositivos de enrutamiento y otros equipos de red del dominio CoS para garantizar la interoperabilidad entre todos los equipos.
Limitaciones que son comunes para CoS en interfaces PPP y MLPPP
Se aplican las siguientes restricciones para configurar CoS en interfaces PPP y MLPPP en enrutadores de la serie ACX:
Para interfaces con encapsulación PPP, puede configurar interfaces para que admitan las aplicaciones IPv4, Protocolo de control de protocolo de Internet (IPCP), Protocolo de autenticación por desafío mutuo (CHAP) PPP y Protocolo de autenticación de contraseña (PAP).
El tiempo de espera de pérdida, que define un método de recuperación para cualquier paquete descartado por los vínculos miembro en un paquete de servicios de vínculo o multivínculo, no se aplica a los enrutadores ACX.
La pérdida de tráfico se produce durante un cambio de configuración de CoS; No puede modificar los atributos de programación de forma instantánea. El vínculo se mueve al estado descendente para PPP y el protocolo se indica como inactivo para las interfaces MLPPP.
Las capacidades de programación y configuración se basan en el modelo CIR-EIR y no están de acuerdo con el modo de cola justa ponderada. La velocidad de transmisión mínima es de 32 Kbps, y la diferencia mínima que se puede admitir entre la velocidad de transmisión y la velocidad de conformación también es de 32 Kbps.
El tamaño del búfer se calcula en términos de paquetes utilizando 256 bytes como tamaño promedio del paquete. Por ejemplo, si configura un tamaño de búfer del 10 por ciento para interfaces de TI, el búfer se asigna como 1,536 Mbps * (10/100) * (0,1 seg) = 15360 bits. La siguiente fórmula calcula la longitud de la cola configurada:
Longitud de la cola configurada = Tamaño promedio del búfer/paquete = (15360/256)/8 = 7,5 = 8 paquetes.
Dado que no hay búferes compartidos, el uso de los atributos "tamaño de búfer" y "tamaño de búfer exacto" da como resultado el mismo comportamiento.
Solo se admiten dos niveles de prioridad de pérdida, a saber, bajo y alto. El tráfico que llega del motor de reenvío de paquetes con una prioridad media-alta se trata como tráfico de prioridad alta. Aunque puede configurar el tipo de prioridad de pérdida media-alta al configurar la acción para un término de firewall, el sistema lo considera tráfico de prioridad alta.
Se realiza una asignación fija incorporada entre la clase de reenvío y el número de cola de la siguiente manera: el mejor esfuerzo es la cola 0, el reenvío acelerado es la cola 1, el reenvío asegurado es la cola 2 y el control de red es la cola 3
Para las configuraciones WRED, la diferencia entre el nivel de llenado máximo y el nivel de llenado mínimo es un número elevado a la potencia de 2 en términos de número de paquetes (x^2). De lo contrario, el nivel de llenado inferior se ajusta para convertir la diferencia en un valor elevado a la potencia de 2. Por ejemplo, las colas contienen un tamaño de 64 paquetes. Si se realiza la siguiente configuración:
fill-level 50 drop-probability 0; fill-level 100 drop-probability 100;
Para el nivel de llenado inferior, el número mínimo de paquetes es 32. Sin embargo, si especifica que el nivel de llenado sea 45 en lugar de 50, el nivel de llenado inferior es 28. Debido a que 64 - 28, que es igual a 36 no es una potencia de 2, el nivel de llenado inferior se ajusta internamente para convertirlo en un número exponencialmente elevado a 2.
Cuando se configura la asignación de fragmentación, se debe asignar la prioridad más alta a la clase de reenvío que lleva el tráfico de varias clases 0 y a la clase de reenvío que lleva el tráfico de varias clases 3 se le debe asignar la prioridad más baja. Dicha configuración es necesaria debido al diseño de la NPU.
Limitaciones para CoS en interfaces PPP
Se aplican las siguientes restricciones para configurar CoS en interfaces PPP en enrutadores de la serie ACX:
La distribución de la tasa de exceso entre 2 o más colas que contienen la misma prioridad se produce por orden de llegada. Por ejemplo, considere dos colas configuradas de la siguiente manera:
Q1 : Velocidad de transmisión = 10%, Velocidad de formación = 20%
Q2: Velocidad de transmisión = 10%, Velocidad de formación = 30% en la misma prioridad
La tasa de exceso para Q1 = (20 - 10) = 10%
La tasa de exceso para Q2 = (30 - 10) = 20%
La distribución del exceso de velocidad entre Q1 y Q2 no sigue la misma proporción, pero los paquetes en estas colas se sirven por orden de llegada. La tasa de conformación continúa siendo honrada en tal escenario.
Directrices para configurar CoS en interfaces PPP y MLPPP
Tenga en cuenta los siguientes puntos cuando configure CoS en interfaces PPP y MLPPP:
Sólo puede configurar la opción any con la
protocolinstrucción en el nivel de[edit class-of-service schedulers scheduler-name drop-profile-map]jerarquía para especificar el tipo de protocolo para el programador especificado. No puede especificar los tipos de protocolo TCP o no TCP.No se admiten las funcionalidades de CoS para interfaces fraccionarias T1 y E1. CoS solo se admite para interfaces T1 y E1 completas.
No se admite el modelo de configuración y programación de colas justas ponderadas (WFQ). En lugar de WFQ, se admite el modelo CIR-EIR para manejar los requisitos de configuración y programación.
La configuración de velocidad basada en porcentajes no es compatible con las interfaces MLPPP LSQ; Solo se admite la configuración de velocidad absoluta en BPS.
No se admite el ajuste automático de las velocidades de configuración y programación con la adición o eliminación de vínculos T1/E1. Todas las limitaciones aplicables para CoS en enrutadores ACX se aplican a las interfaces PPP.
Todas las limitaciones de la policía en enrutadores ACX para interfaces Gigabit Ethernet son válidas para interfaces PPP. Esta restricción incluye a los aplicadores de entrada y salida. Debido a que estas limitaciones afectan a todo el chasis, también son efectivas para interfaces PPP.
Todas las configuraciones válidas especificadas para las interfaces MLPPP con familias de direcciones inet también son válidas para las interfaces MLPPP con familias de direcciones MPLS. Por ejemplo, el clasificador EXP como clasificador global se admite para la clasificación de entrada y la regla de reescritura EXP se admite para las interfaces lógicas de salida.
La encapsulación PPP se admite en enrutadores ACX1000, ACX2000, ACX2100 y ACX4000.
Se puede admitir un máximo de 1000 interfaces lógicas en un enrutador ACX.
Un máximo de 280 interfaces lógicas PPP o MLPPP pueden admitir perfiles de caída en un sistema. En cada MIC, se admite un máximo de 140 interfaces PPP o MLPPP.
Limitaciones para CoS en interfaces MLPPP
Se aplican las siguientes restricciones para configurar CoS en interfaces MLPPP en enrutadores de la serie ACX:
No se admite la configuración basada en porcentajes para los parámetros de programación y forma; Solo se admite la configuración de velocidad absoluta. Como resultado, la modificación dinámica y rápida de la configuración de configuración y programación no ocurre con la adición o eliminación de enlaces T1/E1.
El tamaño del búfer se calcula en términos de una sola velocidad de enlace T1 o E1. Por lo tanto, se utiliza un valor temporal, en microsegundos, para calcular el tamaño del búfer para un valor mayor del tamaño del búfer. Para la configuración temporal, el algoritmo de cola comienza a descartar paquetes cuando pone en cola más de un número calculado de bytes. Este máximo se calcula multiplicando la velocidad de transmisión de la cola por el valor temporal configurado. El tamaño de cola predeterminado y el tamaño de cola basado en porcentajes no se basan en el ancho de banda actual.
Si configura un mapa de programador sin un mapa de fragmentación, a cualquier configuración de asignación de programador, incluida la configuración predeterminada, se le aplicará el mismo comportamiento que la funcionalidad de velocidad de transmisión exacta. No se respetan las prioridades de tráfico y no se aprovisionan tarifas excesivas. La clase de reenvío sin configuración de velocidad recibe la velocidad fija mínima asignada, que es de 32 Kbps.
La compatibilidad con la sobresuscripción y la prioridad no está disponible, lo que podría provocar una utilización ineficaz del ancho de banda. Por ejemplo, considere un mapa de programador predeterminado, con la cola de mejor esfuerzo configurada con una velocidad que es igual a 16*T1*(.95) exacta de la velocidad de transmisión.
La cola de control de red está configurada con una velocidad de transmisión exacta de 16*T1*(0,05). En tal escenario, se observa el siguiente comportamiento para el paquete MLPPP con un solo vínculo T1:
El tráfico que llega como el único tipo de tráfico de mejor esfuerzo se proporciona con capacidad de ancho de banda completa si no se distribuye tráfico a ninguna otra cola. El tráfico que llega a la única cola de control de red está limitado a un ancho de banda de 1,2288 Mbps, incluso si no hay tráfico presente en ninguna otra cola. Cuando el tráfico llega tanto a las colas de mejor esfuerzo como a las de control de red, se realiza una división equitativa del tráfico en ambas colas porque ambas colas están dentro de su tasa de garantía mínima. Las colas que no sean el mejor esfuerzo y el control de red reciben 32 Kbps de ancho de banda de transmisión exacto.
A las colas que no sean de mejor esfuerzo y control de red se les asignan 32 Kbps de ancho de banda de transmisión exacto.
Considere otro ejemplo de un mapa de programador predeterminado y un paquete MLPPP con dos vínculos T1. En tal escenario, se observa el siguiente comportamiento para el paquete MLPPP con dos vínculos T1:
El tráfico que llega solo a la cola de mejor esfuerzo obtiene toda la capacidad de ancho de banda si no hay tráfico en ninguna otra cola. El tráfico que llega solo a la cola de control de red está limitado a 1,2288 Mbps, incluso cuando ningún tráfico pasa por ninguna otra cola. Cuando el tráfico llega a ambas colas, se marca en 1,2288 Mbps para la cola de control de red y en 1,843200 Mbps para la cola de mejor esfuerzo.
Para un mapa de programador predeterminado con un paquete MLPPP que contiene 16 vínculos T1, el tráfico que llega como solo el tráfico de mejor esfuerzo recibe un ancho de banda igual a (0,95 * 16 * T1) de capacidad si no hay tráfico en ninguna otra cola. El tráfico que llega solo como tráfico de control de red está limitado a 1,2288 Mbps, incluso si no se observa tráfico en ninguna otra cola. Cuando el tráfico llega a ambas colas, se etiqueta como 1,2288 Mbps para el control de red y (0,95 * 16 * T1) Mbps para las colas de mejor esfuerzo. Si configura una asignación de programador con una asignación de fragmentación, dos o más clases, cuando se configuran con la misma prioridad, reciben sólo la velocidad de transmisión que se les sirve y funcionan como el tráfico definido para la funcionalidad exacta de la velocidad de transmisión.
No se admite la sobresuscripción entre dos clases múltiples con la misma prioridad. La cola correspondiente a la que no hay ninguna entrada multiclase se mueve al estado deshabilitado. Solo se admite la asignación uno a uno entre clase de reenvío a multiclase. Una clase de reenvío puede enviar tráfico correspondiente a una sola clase múltiple.
Funcionalidades de CoS para IPv4 a través de interfaces PPP
Las siguientes capacidades de CoS son compatibles con las interfaces PPP para el tráfico IPv4:
La clasificación de entrada se puede especificar como clasificadores fijos o clasificadores de agregado de comportamiento (BA). Los clasificadores fijos asignan todo el tráfico de una interfaz a la clase de reenvío. La clase de reenvío determina la cola de salida. Para configurar un clasificador fijo, incluya la
forwarding-class class-nameinstrucción en el nivel de[edit class-of-service interface interface-name unit logical-unit-number]jerarquía.La clasificación de BA, o clasificación de tráfico del valor CoS, se refiere a un método de clasificación de paquetes que utiliza una configuración de CoS para establecer la clase de reenvío de un paquete en función del valor CoS del encabezado del paquete IP. El valor CoS examinado para fines de clasificación BA puede ser el valor del punto de código de servicios diferenciados (DSCP), el valor de precedencia IP o los bits EXP. El clasificador predeterminado se basa en el valor de prioridad IP.
Para configurar el clasificador EXP global, incluya las siguientes instrucciones en el nivel de [edit class-of-service system-defaults] jerarquía.
[edit class-of-service] { system-defaults { classifiers exp classifier-name } }CoS admite un clasificador predeterminado del sistema global del tipo EXP, como se muestra en el ejemplo siguiente:
[edit class-of-service] { system-defaults { classifiers { exp exp-classf-core; } } }Todos los paquetes que se reciben en una interfaz lógica en la dirección de entrada se pueden clasificar en una sola clase de reenvío mediante clasificación fija.
La clasificación BA basada en los siguientes campos de paquetes se admite en el nivel de interfaz lógica:
IPv4 - inet-precedence
DSCP
La siguiente es la estrofa de configuración para definir clasificadores de BA:
[edit class-of-service] classifiers { (inet-precedence|dscp ) classifier-name { forwarding-class class-name loss-priority [low | high] code-points ([ aliases ] | [ dscp-bits ]); }Las funcionalidades de colas y programación comprenden los siguientes parámetros:
Velocidad de transmisión por cola
Velocidad de conformación por cola
WRED
Clases de reenvío. Se puede definir un máximo de 4 clases de reenvío para interfaces PPP.
Las cuatro prioridades admitidas para las colas a nivel de interfaz lógica son estricta alta, media-alta, media-baja o baja. La velocidad de transmisión por cola (CIR) es la velocidad mínima confirmada que se puede especificar para cada cola. La velocidad de modelación por cola (PIR) es la velocidad de transmisión máxima que se puede especificar para cada cola. Para WRED, el comportamiento predeterminado es habilitar las caídas de cola. La configuración del perfil de caída habilita WRED y permite un comportamiento de caída diferente en función de la prioridad de caída que se va a introducir. La configuración de prioridad de pérdida ayuda a determinar qué paquetes se descartan de la red durante los períodos de congestión. El software admite múltiples designaciones de prioridad de pérdida de paquetes (PLP): baja y alta
El tamaño del búfer puede ser específico en porcentaje y configuración temporal. Este tamaño se convierte en el número de paquetes por cola, con 256 bytes tratados como el tamaño promedio del paquete. En el nivel de cola se pueden configurar los siguientes ajustes:
Velocidad de transmisión garantizada (CIR)
Velocidad de conformación (PIR)
Perfil de caída
Tamaño del búfer
[edit class-of-service] schedulers scheduler_name { transmit-rate (percent number | rate); shaping-rate (percent number | rate); buffer-size (percent | temporal) drop-profile-map map_name; }Solo se admiten 4 clases de reenvío y solo 4 colas por interfaz lógica. Además, no se admite el modelado basado en interfaces lógicas.
Los contadores de paquetes y bytes para paquetes transmitidos y descartados están disponibles por cola. Estos detalles estadísticos se muestran mediante el comando show interfaces queue. El sistema también admite la agregación para proporcionar estadísticas a nivel de puerto, si es necesario. Las estadísticas de nivel de interfaz lógica están disponibles correctamente para la dirección de salida y se muestran en la salida, pero las estadísticas relativas a los paquetes perdidos no se tienen en cuenta debido a limitaciones de hardware. La siguiente estrofa de configuración define las reglas de reescritura:
[edit class-of-service] rewrite-rules { (inet-precedence | dscp | exp) rewrite-name { forwarding-class class-name loss-priority [low | high] code-point value; } }Cada una de las reglas de reescritura se puede adjuntar a una interfaz mediante la siguiente sintaxis de configuración:
[edit class-of-service interfaces interface-name]
rewrite-rules { dscp (rewrite-name | default) protocol (inet-both | inet-outer | mpls); exp (rewrite-name | default) protocol protocol-types; inet-precedence (rewrite-name | default) protocol (inet-both | inet-outer | mpls); }Todas las funciones de firewall admitidas en los enrutadores ACX son aplicables a interfaces PPP para paquetes IPv4.
Para las reglas de reescritura, se admiten las reglas de precedencia IPv4 o inet y EXP. Las reglas de reescritura de EXP solo se aplican a las interfaces lógicas. No puede aplicar reglas de reescritura de EXP a interfaces físicas. No hay reglas de reescritura EXP predeterminadas. Si desea volver a escribir el valor EXP en paquetes MPLS, debe configurar las reglas de reescritura EXP y aplicarlas a las interfaces lógicas. Si no se aplica ninguna regla de reescritura, todas las etiquetas MPLS insertadas tienen un valor de cero (0). El valor EXP permanece sin cambios en las etiquetas MPLS que se intercambian.
Funcionalidades de CoS para IPv4 a través de interfaces MLPPP
Las siguientes capacidades de CoS son compatibles con las interfaces MLPPP para el tráfico IPv4:
La clasificación de entrada se puede especificar como clasificadores fijos o BA.
Se admiten la clasificación fija mediante clases de reenvío y la clasificación BA con el valor de prioridad IPv4.
Se admiten las siguientes propiedades de programación y cola:
Velocidad de transmisión por cola
Velocidad de conformación por cola
WRED
Clases de envío
Tamaño de búfer por cola
Asignación de clase de reenvío a clase de multivínculo. Utilice la
multilink-classinstrucción para asignar una clase de reenvío en un MLPPP multiclase (MCML).Todas las funciones de firewall admitidas en los enrutadores ACX son aplicables a las interfaces MLPPP para paquetes IPv4
Para las reglas de reescritura, se admite la regla de precedencia IPv4.
Las siguientes capacidades de CoS son compatibles con las interfaces MLPPP para paquetes MPLS:
La clasificación de entrada se puede especificar como clasificadores fijos o BA. Se admiten la clasificación fija mediante clases de reenvío y la clasificación BA mediante bits EXP.
Se admiten las siguientes propiedades de programación y cola:
Velocidad de transmisión por cola
Velocidad de conformación por cola
WRED
Clases de envío
Tamaño de búfer por cola
Asignación de clase de reenvío a clase de multivínculo. Utilice la
multilink-classinstrucción para asignar una clase de reenvío en un MLPPP multiclase (MCML).Todas las funciones de firewall admitidas en los enrutadores ACX son aplicables a las interfaces MLPPP para paquetes IPv4
Para las reglas de reescritura, se admite la regla EXP.
En el ejemplo siguiente se ilustra un conjunto de configuración de CoS MLPPP:
[edit]
class-of-service {
classifiers {
inet-precedence all-traffic-inet {
forwarding-class assured-forwarding {
loss-priority low code-points 101;
}
forwarding-class expedited-forwarding {
loss-priority low code-points 000;
}
}
}
drop-profiles {
plp-low-red {
fill-level 50 drop-probability 0;
fill-level 100 drop-probability 100;
}
plp-high-red {
fill-level 25 drop-probability 0;
fill-level 50 drop-probability 100;
}
}
forwarding-classes {
queue 0 best-effort;
queue 1 assured-forwarding;
queue 2 expedited-forwarding;
queue 3 network-control;
}
schedulers {
evdo-mlppp-best-effort {
transmit-rate 1M;
buffer-size percent 80;
priority medium-high;
}
evdo-mlppp-assured-forwarding {
transmit-rate 500000;
buffer-size percent 10;
drop-profile-map loss-priority low protocol any drop-profile plp-low-red;
drop-profile-map loss-priority high protocol any drop-profile plp-high-red;
priority medium-low;
}
evdo-mlppp-expedited-forwarding {
transmit-rate 300000;
buffer-size percent 5;
priority low;
}
evdo-mlppp-network-control {
transmit-rate 200000;
buffer-size percent 5;
priority strict-high;
}
}
scheduler-maps {
evdo-mlppp-cos-map {
forwarding-class best-effort scheduler evdo-mlppp-best-effort;
forwarding-class assured-forwarding scheduler evdo-mlppp-assured-forwarding;
forwarding-class network-control scheduler evdo-mlppp-network-control;
forwarding-class expedited-forwarding scheduler evdo-mlppp-expedited-forwarding;
}
}
fragmentation-maps {
frag-mlppp {
forwarding-class {
assured-forwarding {
multilink-class 2;
}
expedited-forwarding {
multilink-class 3;
}
best-effort {
multilink-class 1;
}
network-control {
multilink-class 0;
}
}
}
}
interfaces {
lsq-0/* {
unit * {
scheduler-map evdo-mlppp-cos-map;
fragmentation-map frag-mlppp;
}
}
}
En los enrutadores de la serie ACX, la clase de reenvío y la asignación de cola son fijas para las interfaces PPP y MLPPP.
En el ejemplo siguiente se muestra un conjunto de configuración de firewall MLPPP:
[edit]
firewall {
filter classify-evdo-traffic-mlppp {
interface-specific;
term signalling {
from {
dscp ef;
}
then {
count signalling-counter;
forwarding-class network-control;
accept;
}
}
term user-speech {
from {
dscp af31;
}
then {
policer user-speech-rate-limit;
count user-speech-counter;
forwarding-class network-control;
accept;
}
}
term ptt-mcs {
from {
dscp af11;
}
then {
count ptt-mcs-counter;
forwarding-class network-control;
accept;
}
}
term user-video {
from {
dscp af21;
}
then {
count user-video-counter;
loss-priority low;
forwarding-class assured-forwarding;
accept;
}
}
term user-cmcs {
from {
dscp af12;
}
then {
count user-cmcs-counter;
loss-priority low;
forwarding-class assured-forwarding;
accept;
}
}
term ran-rlp-retransmission {
from {
dscp af41;
}
then {
count rlp-retransmit-counter;
loss-priority high;
forwarding-class assured-forwarding;
accept;
}
}
term user-best-effort {
then {
count user-be-counter;
forwarding-class best-effort;
accept;
}
}
}
}