Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Clase de servicio en interfaces de servicios de vínculo

Configuración de colas de programación de CoS en interfaces LSQ lógicas

Para las interfaces IQ (lsq-) de servicios de vínculo, puede especificar una asignación de programador para cada unidad lógica. Una unidad lógica representa un paquete MLPPP o un DLCI configurado en un paquete FRF.16. El programador se aplica al tráfico enviado a un PIC de AS o multiservicios que ejecuta el paquete de servicios de vínculo de capa 2.

Si configura una asignación de programador en un paquete, debe incluir la per-unit-scheduler instrucción en el nivel de [edit interfaces lsq-fpc/pic/port] jerarquía. Si configura una asignación de programador en un DLCI FRF.16, debe incluir la per-unit-scheduler instrucción en el nivel de [edit interfaces lsq-fpc/pic/port:channel] jerarquía. Para obtener más información, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Si necesita garantías de latencia para el tráfico de varias clases o LFI, debe usar PIC IQ canalizadas para los vínculos que lo componen. Con PIC que no son IQ, dado que la cola no se realiza en el nivel de interfaz canalizada en los vínculos que lo componen, es posible que el tráfico sensible a la latencia no reciba el tipo de servicio que debería. Los enlaces de los constituyentes de las siguientes PIC admiten garantías de latencia:

  • PIC IQ E1 canalizada

  • PIC IQ OC3 canalizada

  • PIC IQ OC12 canalizada

  • PIC IQ STM1 canalizada

  • PIC IQ T3 canalizada

Para programar colas en una interfaz lógica, puede configurar las siguientes propiedades de asignación de programador en el nivel de [edit class-of-service schedulers] jerarquía:

Cuando configure MLPPP y FRF.12 en enrutadores serie M y serie T, debe configurar un único programador con velocidades de transmisión de porcentaje distintas de cero y tamaños de búfer para las colas del 0 al 3, y asignar este programador a la interfaz IQ de servicios de vínculo (lsq) y a cada vínculo constituyente.

Cuando configure FRF.16 en enrutadores serie M y serie T, puede asignar una única asignación de programador a la interfaz IQ de servicios de vínculo (lsq) y a cada DLCI IQ de servicios de vínculo, o puede asignar diferentes asignaciones de programador a los distintos DLCI del paquete, como se muestra en Ejemplo: Configuración de una interfaz LSQ como agrupación NxT1 utilizando FRF.16. Para los vínculos constituyentes de un paquete FRF.16, no es necesario configurar un programador personalizado. Dado que LFI y multiclase no son compatibles con FRF.16, el tráfico de cada vínculo constituyente se transmite desde la cola 0. Esto significa que debe permitir que la cola 0 utilice la mayor parte del ancho de banda. La velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas del 0 al 3 son 95, 0, 0 y 5 por ciento, respectivamente. Este programador predeterminado envía todo el tráfico de usuario a la cola 0 y todo el tráfico de control de red a la cola 3 y, por lo tanto, es adecuado para el comportamiento de FRF.16. Puede configurar un programador personalizado que replique explícitamente los comportamientos de cola del 95, 0, 0 y 5 por ciento, y aplicarlo a los vínculos que lo componen.

Nota:

En enrutadores serie T y M320, la velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas del 0 al 7 son 95, 0, 0, 5, 0, 0, 0, 0 y 0 por ciento.

Para las interfaces IQ de servicios de vínculo (lsq), estas propiedades de programación funcionan igual que en otras PIC, excepto como se indica en las secciones siguientes.

Nota:

En enrutadores serie T y M320, lsq las interfaces no admiten puntos de código DiffServ (DSCP) ni marcadores de reescritura DSCP-IPv6.

Configuración del tamaño de búfer del programador

Puede configurar el tamaño de búfer del programador de tres maneras: como un valor temporal, como un porcentaje y como un resto. En una sola interfaz lógica (MLPPP o un DLCI FRF.16), cada cola puede tener un tamaño de búfer diferente.

Si especifica un valor temporal, el algoritmo de cola comienza a dejar caer paquetes cuando pone en cola más de un número calculado de bytes. Este número se calcula multiplicando la velocidad de interfaz lógica por el valor temporal. Para los paquetes MLPPP, la velocidad de interfaz lógica es igual al ancho de banda del paquete, que es la suma de las velocidades de vínculo constituyentes menos la sobrecarga de la capa de vínculo. Para los DLCI MLFR FRF.16, la velocidad de la interfaz lógica es igual al ancho de banda del paquete multiplicado por la velocidad de modelación de DLCI. En todos los casos, el valor temporal máximo se limita a 200 milisegundos.

Los porcentajes de tamaño de búfer se convierten implícitamente en valores temporales multiplicando el porcentaje por 200 milisegundos. Por ejemplo, el tamaño de búfer especificado como buffer-size percent 20 es el mismo que un retraso temporal de 40 milisegundos. La implementación de IQ de servicios de vínculo garantiza 200 milisegundos de retraso de búfer para todas las interfaces con T1 y velocidades superiores. Para interfaces más lentas, garantiza un segundo de retraso del búfer.

El algoritmo de cola distribuye uniformemente el ancho de banda sobrante entre todas las colas configuradas con la buffer-size remainder instrucción. El algoritmo de cola garantiza suficiente espacio en el búfer de transmisión para dos paquetes de tamaño UMT.

Configuración de la prioridad del programador

La prioridad de transmisión de cada cola está determinada por el programador y la clase de reenvío. Cada cola recibe una cantidad garantizada de ancho de banda especificada con la instrucción scheduler transmit-rate .

Configuración de la velocidad de modelación del programador

Utilice la velocidad de modelación para establecer el porcentaje del ancho de banda total del paquete dedicado a un DLCI. Para los DLCI IQ de servicios de vínculo, solo se aceptan porcentajes, lo que permite ajustes en respuesta a cambios dinámicos en el ancho de banda del paquete, por ejemplo, cuando un vínculo sube o baja. Esto significa que las velocidades de modelación absolutas no se admiten en los paquetes FRF.16. Las velocidades de modelación absolutas solo se permiten para los paquetes MLPPP y MLFR.

Para la programación entre DLCI en un paquete MLFR FRF.16, puede configurar una velocidad de modelación para cada DLCI. La velocidad de modelación se expresa como un porcentaje del ancho de banda del paquete agregado. Los porcentajes de velocidad de modelación para todos los DLCI dentro de un paquete pueden sumar hasta el 100 por ciento o menos. El ancho de banda sobrante se distribuye por igual a los DLCI que no tienen la shaping-rate instrucción incluida en el nivel de [edit class-of-service interfaces lsq-fpc/pic/port:channel unit logical-unit-number] jerarquía. Si ninguno de los DLCI de un paquete de MLFR FRF.16 especifica un programador DLCI, el ancho de banda total se divide uniformemente entre todos los DLCI.

Nota:

Para los paquetes FRF.16 en interfaces IQ de servicios de vínculo, solo se admiten las velocidades de modelación basadas en porcentaje.

Configuración de perfiles de caída

Puede configurar la detección temprana aleatoria (RED) en interfaces LSQ como en otros escenarios de CoS. Para configurar RED, incluya uno o varios perfiles de caída y adjúntelos a un programador para una clase de reenvío determinada. Para obtener más información acerca de los perfiles RED, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

La implementación de LSQ realiza tail RED. Admite un máximo de 256 perfiles de caída por PIC. Los perfiles de caída se pueden configurar por cola, por prioridad de pérdida y por bit TCP.

Puede asociar asignaciones de programador con perfiles de caída RED configurados a cualquier interfaz lógica LSQ: un paquete MLPPP, un paquete FRF.15 o un DLCI FRF.16. Diferentes colas (clases de reenvío) en la misma interfaz lógica pueden tener diferentes perfiles de caída asociados.

En el siguiente ejemplo, se muestra cómo configurar un perfil RED en una interfaz LSQ:

Nota:

Los perfiles RED solo se deben aplicar en los paquetes LSQ y no en los vínculos de salida que constituyen el paquete.

Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ

Para las interfaces IQ (lsq-) de servicios de vínculo, puede especificar propiedades de fragmentación para clases de reenvío específicas. El tráfico en cada clase de reenvío puede ser encapsulado de múltiples vínculos (fragmentado y secuenciado) o no encapsulado (con hash sin fragmentación). De forma predeterminada, el tráfico en todas las clases de reenvío está encapsulado multivínculo.

Cuando no se configuran las propiedades de fragmentación para las colas en las interfaces MLPPP, el umbral de fragmentación que se establece en el [edit interfaces interface-name unit logical-unit-number fragment-threshold] nivel de jerarquía es el umbral de fragmentación para todas las clases de reenvío dentro de la interfaz MLPPP. Para las interfaces MLFR FRF.16, el umbral de fragmentación que se establece en el [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] nivel de jerarquía es el umbral de fragmentación para todas las clases de reenvío dentro de la interfaz MLFR FRF.16.

Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se seguirán fragmentando si superan la unidad máxima de transmisión (UMT) o la unidad máxima recibida reconstruida (MRRU) de todos los vínculos del paquete. Un flujo no encapsulado utiliza solo un vínculo. Si el flujo supera un único vínculo, la clase de reenvío debe estar encapsulada con varios vínculos, a menos que el tamaño del paquete supere la UMT/MRRU.

Incluso si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la MRRU incluyendo la mrru instrucción en el [edit interfaces lsq-fpc/pic/port unit logical-unit-number] nivel de jerarquía o [edit interfaces interface-name mlfr-uni-nni-bundle-options] . La MRRU es similar a la UMT, pero es específica para las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1500 bytes y puede configurarlo para que sea de 1500 a 4500 bytes. Para obtener más información, consulte Configurar MRRU en interfaces lógicas de multivínculo y servicios de vínculo.

Para configurar las propiedades de fragmentación en una cola, incluya la fragmentation-maps instrucción en el nivel de [edit class-of-service] jerarquía:

Para establecer un umbral de fragmentación por clase de reenvío, incluya la fragment-threshold instrucción en el mapa de fragmentación. Esta instrucción establece el tamaño máximo de cada fragmento de multivínculo.

Para establecer que el tráfico de una cola sea no encapsulado en lugar de multivínculo, incluya la no-fragmentation instrucción en el mapa de fragmentación. Esta instrucción especifica que no se antepone un encabezado de fragmentación adicional a los paquetes recibidos en esta cola y que se usa el equilibrio de carga de vínculos estáticos para garantizar la entrega de paquetes en orden.

Para una clase de reenvío dada, puede incluir la fragment-threshold instrucción or no-fragmentation ; son mutuamente excluyentes.

Utilice la multilink-class instrucción para asignar una clase de reenvío a una MLPPP multiclase (MCML). Para una clase de reenvío dada, puede incluir la multilink-class instrucción or no-fragmentation ; son mutuamente excluyentes.

Para asociar un mapa de fragmentación con una interfaz PPP multivínculo o un DLCI MLFR FRF.16, incluya la fragmentation-map instrucción en el nivel de [edit class-of-service interfaces interface-name unit logical-unit-number] jerarquía:

Para ver ejemplos de configuración, consulte los temas siguientes:

Para las interfaces de servicios de vínculo PIC de servicios de vínculo (ls-), no se admiten los mapas de fragmentación. En su lugar, se habilita LFI incluyendo la interleave-fragments instrucción en el nivel de [edit interfaces interface-name unit logical-unit-number] jerarquía. Para obtener más información, consulte Configuración de intercalación de paquetes sensibles al retraso en interfaces lógicas de servicios de vínculo.

Exceso de suscripción de ancho de banda de interfaz en interfaces LSQ

El término sobresuscripción de ancho de banda de interfaz significa configurar velocidades de modelación (velocidades máximas de información [PIR]) para que su suma supere el ancho de banda de la interfaz.

En las PIC IQ canalizadas, las PIC IQ de Gigabit Ethernet y las interfaces IQ (lsq-) de servicios de vínculo FRF.16 en PIC de AS y multiservicios, puede sobresuscribir el ancho de banda de la interfaz. Las interfaces lógicas (y DLCI dentro de un paquete FRF.16) pueden estar sobresuscritas cuando hay ancho de banda sobrante. La sobresuscripción se limita al PIR configurado. El ancho de banda no utilizado se distribuye por igual entre las interfaces lógicas o DLCI sobresuscritas.

En el caso de las redes que no son propensas a experimentar congestión, la sobresuscripción del ancho de banda de la interfaz mejora la utilización de la red, lo que permite aprovisionar a más clientes en una sola interfaz. Si el tráfico de datos real no supera el ancho de banda de la interfaz, la sobresuscripción le permite vender más ancho de banda del que la interfaz puede admitir.

Recomendamos evitar el exceso de suscripciones en redes que probablemente experimenten congestión. Tenga cuidado de no suscribirse demasiado a un servicio, ya que esto puede causar degradación en el rendimiento del enrutador durante la congestión. Cuando se configura la sobresuscripción, algunas colas de salida pueden quedar inactivas si el tráfico de datos real supera el ancho de banda de la interfaz física. Puede evitar la degradación mediante la multiplexación estadística para asegurarse de que el tráfico de datos real no supere el ancho de banda de la interfaz.

Nota:

No puede suscribir en exceso el ancho de banda de la interfaz cuando configure la formación de tráfico con el método descrito en Aplicación de asignaciones de programador y velocidad de modelación a DLCI y VLAN.

Cuando configure la sobresuscripción para interfaces de agrupación FRF.16, puede asignar perfiles de control de tráfico que se apliquen a una interfaz física. Cuando se aplican perfiles de control de tráfico a paquetes FRF.16 en el nivel de interfaz lógica , el ancho de banda de la interfaz de vínculo miembro se infrautiliza cuando hay una pequeña proporción de tráfico o no hay tráfico en absoluto en un DLCI individual. La compatibilidad con funciones de control de tráfico en el nivel de interfaz física del paquete FRF.16 aborda esta limitación.

Para configurar la sobresuscripción de una interfaz, realice los siguientes pasos:

  1. Incluya la shaping-rate instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    Nota:

    Cuando configure la sobresuscripción para interfaces de paquete FRF.16 sobre una base de interfaz física, debe especificar shaping-rate como un porcentaje.

    En las interfaces LSQ, puede configurar la velocidad de modelación como un porcentaje.

    En las interfaces IQ y IQ2, puede configurar la velocidad de modelación como una velocidad absoluta de 1000 a 6.400.000.000.000 bits por segundo.

    Como alternativa, puede configurar una velocidad de modelación para una interfaz lógica y suscribir en exceso la interfaz física incluyendo la shaping-rate instrucción en el nivel de [edit class-of-service interfaces interface-name unit logical-unit-number] jerarquía. Sin embargo, con este enfoque de configuración, no puede controlar de forma independiente la velocidad de búfer de retraso, como se describe en el paso 2.

    Nota:

    Para las interfaces IQ canalizadas y Gigabit Ethernet, las shaping-rate instrucciones y guaranteed-rate son mutuamente excluyentes. No puede configurar algunas interfaces lógicas para que usen una velocidad de modelación y otras para que usen una velocidad garantizada. Esto significa que no hay garantías de servicio al configurar una PIR. Para estas interfaces, puede configurar un PIR o una velocidad de información comprometida (CIR), pero no ambas.

    Esta restricción no se aplica a las PIC IQ2 de Gigabit Ethernet ni a las interfaces IQ de servicios de vínculo (LSQ) en PIC de AS o multiservicios. Para las interfaces LSQ y Gigabit Ethernet IQ2, puede configurar un PIR y un CIR en una interfaz. Para obtener más información acerca de los CIR, consulte Configurar una velocidad mínima garantizada en interfaces LSQ.

  2. Opcionalmente, puede basar el cálculo del búfer de retraso en una tasa de búfer de retraso. Para ello, incluya la delay-buffer-rate instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    Nota:

    Cuando configure la sobresuscripción para interfaces de paquete FRF.16 sobre una base de interfaz física, debe especificar delay-buffer-rate como un porcentaje.

    La velocidad de búfer de retraso anula la velocidad de modelación como base para el cálculo del búfer de retraso. En otras palabras, la velocidad de modelación o la velocidad de modelación escalada se utiliza para los cálculos de búfer de retraso solo cuando la velocidad de búfer de retraso no está configurada.

    En el caso de las interfaces LSQ, si no configura una velocidad de búfer de retardo, se utiliza la velocidad garantizada (CIR) para asignar búferes. Si no configura una velocidad garantizada, la velocidad de modelación (PIR) se utiliza en el caso de subsuscripción y la velocidad de modelación escalada se utiliza en el caso de sobresuscripción.

    En las interfaces LSQ, puede configurar la tasa de búfer de retraso como un porcentaje.

    En las interfaces IQ e IQ2, puede configurar la velocidad del búfer de retraso como una velocidad absoluta de 1000 a 6.400.000.000.000 bits por segundo.

    El búfer de retraso real se basa en los cálculos descritos en la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200). Para obtener un ejemplo que muestre cómo se aplican las tasas de búfer de retraso , consulte Ejemplos: Suscripción excesiva a una interfaz LSQ.

    La configuración de búferes grandes en vínculos de velocidad relativamente baja puede provocar la antigüedad de los paquetes. Para ayudar a prevenir este problema, el software requiere que la suma de las tasas de búfer de retraso sea menor o igual que la velocidad del puerto.

    Esta restricción no elimina la posibilidad de antigüedad de paquetes, por lo que debe tener cuidado al usar la delay-buffer-rate instrucción. Aunque puede ser deseable cierta cantidad de almacenamiento en búfer adicional para la absorción de ráfagas, las velocidades de búfer de retardo no deben exceder con creces la velocidad de servicio de la interfaz lógica.

    Si configura velocidades de búfer de retraso de modo que la suma supere la velocidad del puerto, la velocidad de búfer de retraso configurada no se implementa para la última interfaz lógica que configure. En su lugar, esa interfaz lógica recibe una tasa de búfer de retraso de cero y se muestra un mensaje de advertencia en la CLI. Si el ancho de banda está disponible (porque se elimina o desactiva otra interfaz lógica, o porque aumenta la velocidad del puerto), la velocidad de búfer de retardo configurada se reevalúa y, si es posible, se implementa.

    Si no configura una velocidad de búfer de retraso o una velocidad garantizada, la interfaz lógica recibe una velocidad de búfer de retraso proporcional a la velocidad de modelación y la velocidad de búfer de retraso restante disponible. En otras palabras, la velocidad de búfer de retraso para cada interfaz lógica sin una velocidad de búfer de retraso configurada es igual a:

    La tasa restante de amortiguación de retardo es igual a:

  3. Para asignar una asignación de programador a la interfaz lógica, incluya la scheduler-map instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    Para obtener más información acerca de cómo configurar programadores y asignaciones de programadores, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

  4. Opcionalmente, puede habilitar la configuración de tamaños de búfer grandes. Para ello, incluya la q-pic-large-buffer instrucción en el nivel de [edit chassis fpc slot-number pic pic-number] jerarquía:

    Si no incluye esta instrucción, el tamaño del búfer de retraso es más restringido. Recomendamos búferes restringidos para el tráfico sensible al retraso, como el tráfico de voz. Para obtener más información, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

  5. Para habilitar la programación en interfaces lógicas, incluya la per-unit-scheduler instrucción en el nivel de [edit interfaces interface-name] jerarquía:

    Cuando se incluye esta instrucción, la cantidad máxima de VLAN admitidas es 768 en una PIC IQ de Gigabit Ethernet de un solo puerto. En una PIC IQ de Gigabit Ethernet de dos puertos, el número máximo es 384.

  6. Para habilitar la programación de interfaces físicas de paquetes FRF.16, incluya la no-per-unit-scheduler instrucción en el nivel de [edit interfaces interface-name] jerarquía:

  7. Para aplicar el perfil de programación de tráfico a la interfaz lógica, incluya la output-traffic-control-profile instrucción en el nivel de [edit class-of-service interfaces interface-name unit logical-unit-number] jerarquía:

    No puede incluir la output-traffic-control-profile instrucción en la configuración si se incluye alguna de las siguientes instrucciones en la configuración de interfaz lógica: scheduler-map, , shaping-rateadaptive-shaper, o virtual-channel-group.

    Para obtener una tabla que muestre cómo se asignan el ancho de banda y el búfer de retraso en varias configuraciones, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Ejemplos: Suscripción excesiva a una interfaz LSQ

Suscripción excesiva de una interfaz LSQ con programación basada en la interfaz lógica

Aplique un perfil de control de tráfico a una interfaz lógica que represente un DLCI en un paquete FRF.16.

Sobresuscripción de una interfaz LSQ con programación basada en la interfaz física

Aplique un perfil de control de tráfico a la interfaz física que represente un paquete FRF.16:

Configuración de una velocidad mínima garantizada en interfaces LSQ

En las PIC IQ de Gigabit Ethernet, las PIC IQ canalizadas y las interfaces IQ de servicios de vínculo (LSQ) FRF.16 en PIC de AS y multiservicios, puede configurar el ancho de banda garantizado, también conocido como velocidad de información comprometida (CIR). Esto le permite especificar una tasa garantizada para cada interfaz lógica. La tasa garantizada es mínima. Si hay un exceso de ancho de banda de interfaz física disponible para su uso, la interfaz lógica recibe más de la velocidad garantizada aprovisionada para la interfaz.

No puede aprovisionar la suma de las velocidades garantizadas para que sea superior al ancho de banda de la interfaz física o al ancho de banda del paquete para las interfaces LSQ. Si la suma de las velocidades garantizadas supera el ancho de banda de la interfaz o del paquete, no se produce un error en la operación de confirmación, sino que el software disminuye automáticamente las velocidades para que la suma de las velocidades garantizadas sea igual al ancho de banda del paquete disponible.

Para configurar una tasa mínima garantizada, realice los siguientes pasos:

  1. Incluya la guaranteed-rate instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    En las interfaces LSQ, puede configurar la tasa garantizada como un porcentaje.

    En las interfaces IQ e IQ2, puede configurar la velocidad garantizada como una velocidad absoluta de 1000 a 160 000 000 000 bits por segundo.

    Nota:

    Para las interfaces IQ canalizadas y Gigabit Ethernet, las shaping-rate instrucciones y guaranteed-rate son mutuamente excluyentes. No puede configurar algunas interfaces lógicas para que usen una velocidad de modelación y otras para que usen una velocidad garantizada. Esto significa que no hay garantías de servicio al configurar una PIR. Para estas interfaces, puede configurar un PIR o una velocidad de información comprometida (CIR), pero no ambas.

    Esta restricción no se aplica a las PIC IQ2 de Gigabit Ethernet ni a las interfaces IQ de servicios de vínculo (LSQ) en PIC de AS o multiservicios. Para las interfaces LSQ y Gigabit Ethernet IQ2, puede configurar un PIR y un CIR en una interfaz. Para obtener más información acerca de los CIR, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

  2. Opcionalmente, puede basar el cálculo del búfer de retraso en una tasa de búfer de retraso. Para ello, incluya la delay-buffer-rate instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    En las interfaces LSQ, puede configurar la tasa de búfer de retraso como un porcentaje.

    En las interfaces IQ y IQ2, puede configurar la velocidad del búfer de retraso como una velocidad absoluta de 1000 a 160 000 000 000 bits por segundo.

    El búfer de retraso real se basa en los cálculos descritos en las tablas de la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200). Para obtener un ejemplo que muestre cómo se aplican las tasas de búfer de retraso, consulte Ejemplo: Configuración de una velocidad mínima garantizada.

    Si no incluye la delay-buffer-rate instrucción, el cálculo del búfer de retraso se basa en la velocidad garantizada, la velocidad de modelación si no se configura ninguna velocidad garantizada o la velocidad de modelación escalada si la interfaz está sobresuscrita.

    Si no especifica una velocidad de modelación o una velocidad garantizada, la interfaz lógica recibe una velocidad de búfer de retraso mínima y un ancho de banda mínimo igual a 4 paquetes de tamaño UMT.

    Puede configurar una velocidad para el búfer de retraso que sea superior a la velocidad garantizada. Esto puede ser útil cuando el flujo de tráfico puede no requerir mucho ancho de banda en general, pero en algunos casos puede tener ráfagas y, por lo tanto, necesita un búfer grande.

    La configuración de búferes grandes en vínculos de velocidad relativamente baja puede provocar la antigüedad de los paquetes. Para ayudar a prevenir este problema, el software requiere que la suma de las tasas de búfer de retraso sea menor o igual que la velocidad del puerto. Esta restricción no elimina la posibilidad de antigüedad de paquetes, por lo que debe tener cuidado al usar la delay-buffer-rate instrucción. Aunque puede ser deseable cierta cantidad de almacenamiento en búfer adicional para la absorción de ráfagas, las velocidades de búfer de retardo no deben exceder con creces la velocidad de servicio de la interfaz lógica.

    Si configura velocidades de búfer de retraso de modo que la suma supere la velocidad del puerto, la velocidad de búfer de retraso configurada no se implementa para la última interfaz lógica que configure. En su lugar, esa interfaz lógica recibe una tasa de búfer de retraso de 0 y se muestra un mensaje de advertencia en la CLI. Si el ancho de banda está disponible (porque se elimina o desactiva otra interfaz lógica, o porque aumenta la velocidad del puerto), la velocidad de búfer de retardo configurada se reevalúa y, si es posible, se implementa.

    Si no se puede implementar la velocidad garantizada de una interfaz lógica, esa interfaz lógica recibe una velocidad de búfer de retraso de 0, incluso si la velocidad de búfer de retraso configurada está dentro de la velocidad de la interfaz. Si más adelante se puede cumplir la velocidad garantizada de la interfaz lógica, se vuelve a evaluar la velocidad de búfer de retraso configurada y, si la velocidad del búfer de retraso está dentro del ancho de banda restante, se implementa.

    Si alguna interfaz lógica tiene una velocidad garantizada configurada, todas las demás interfaces lógicas en ese puerto que no tengan una velocidad garantizada configurada reciben una tasa de búfer de retraso de 0. Esto se debe a que la ausencia de una configuración de velocidad garantizada corresponde a una velocidad garantizada de 0 y, en consecuencia, a una tasa de búfer de retardo de 0.

  3. Para asignar una asignación de programador a la interfaz lógica, incluya la scheduler-map instrucción en el nivel de [edit class-of-service traffic-control-profiles profile-name] jerarquía:

    Para obtener más información acerca de cómo configurar programadores y asignaciones de programadores, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

  4. Para permitir que se configuren tamaños de búfer grandes, incluya la q-pic-large-buffer instrucción en el nivel de [edit chassis fpc slot-number pic pic-number] jerarquía:

    Si no incluye esta instrucción, el tamaño del búfer de retraso es más restringido. Para obtener más información, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

  5. Para habilitar la programación en interfaces lógicas, incluya la per-unit-scheduler instrucción en el nivel de [edit interfaces interface-name] jerarquía:

    Cuando se incluye esta instrucción, la cantidad máxima de VLAN admitidas es 767 en una PIC IQ de Gigabit Ethernet de un solo puerto. En una PIC IQ de Gigabit Ethernet de dos puertos, el número máximo es 383.

  6. Para aplicar el perfil de programación de tráfico a la interfaz lógica, incluya la instrucción output-traffic-control-profile en el nivel de [edit class-of-service interfaces interface-name unit logical-unit-number] jerarquía:

Ejemplo: Configuración de una tasa mínima garantizada

Dos unidades 0 de interfaz lógica y 1, se aprovisionan con un mínimo garantizado de 750 Kbps y 500 Kbps, respectivamente. Para la unidad 1lógica , el búfer de retraso se basa en la configuración de velocidad garantizada. Para la unidad 0lógica, se especifica una velocidad de búfer de retraso de 500 Kbps. Los búferes de retraso reales asignados a cada interfaz lógica son 2 segundos de 500 Kbps. El valor de 2 segundos se basa en el siguiente cálculo:

Para obtener más información acerca de este cálculo, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).