Este documento proporciona una configuración de ejemplo para las funciones de calidad de servicio (QoS) en el switch Nexus de Cisco serie 7000 para simplificar la forma en que se logra la clasificación y la colocación en cola.
Asegúrese de cumplir estos requisitos antes de intentar esta configuración:
Conozca la configuración básica de los switches Nexus serie 7000
Tener un conocimiento básico de QoS
La información de este documento se basa en el switch Nexus serie 7000.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones sobre documentos.
Los parámetros de QoS predeterminados en el switch Nexus 7000 son suficientes para la mayoría de las implementaciones. Sin embargo, debe comprender las restricciones y los detalles de configuración necesarios para crear políticas personalizadas.
Hay dos aspectos que debe tener en cuenta para QoS en tarjetas de línea Nexus serie 7000 M:
políticas de colocación en cola
Políticas de QoS
La cola se realiza en el hardware y se configura con el uso de políticas de cola de CLI de QoS modular (MQC). Las políticas de QoS, que se utilizan para marcar o supervisar el tráfico, se utilizan a través de una política de MQC en el formato exacto como política de QoS estándar en otras plataformas de Cisco. Por ejemplo, una lista de acceso utilizada para clasificar el tráfico en un class-map con un policy-map correspondiente para establecer/vigilar el tráfico.
Actualmente, los módulos de la serie M realizan colas basadas estrictamente en el valor de Clase de servicio (CoS). Por lo tanto, primero debe comprender cómo se deriva el valor de CoS. Después de saber qué valor de CoS entra/sale del switch, puede centrarse en la configuración de cola para obtener la QoS deseada para los diferentes tipos de tráfico.
Para el tráfico de unidifusión enrutado, el valor de CoS se deriva de los 3 bits más significativos del valor de punto de código de servicios diferenciados (DSCP). Para el tráfico de unidifusión puenteado, el valor de CoS se copia del valor de CoS recibido en el encabezado 802.1q. Tenga en cuenta que en los links de acceso L2 no hay encabezado troncal. Por lo tanto, si el tráfico se recibe en un puerto de acceso y se puentea, egresará el switch con CoS 0. El valor DSCP no se cambia, pero es posible que el paquete no obtenga la prioridad deseada. Puede establecer manualmente el valor CoS en un policy-map a través de cualquier política de QoS que establezca manualmente el valor CoS o DSCP.
También es importante comprender el comportamiento de la multidifusión. El tráfico multicast enrutado deriva su valor CoS de la misma manera que el tráfico unicast ruteado. Para el tráfico multicast puenteado, el comportamiento depende del estado L3. Si no hay estado L3 para el grupo multicast, el CoS se deriva de la misma manera que el tráfico unidifusión puenteado. Si hay un estado L3 para el grupo multicast, el CoS se deriva de la misma manera que el tráfico unicast ruteado. Tenga en cuenta que cuando habilita la multidifusión independiente del protocolo (PIM) en modo disperso en la interfaz virtual del switch (SVI) para la VLAN en la que se recibe el tráfico, se crea una entrada S,G cuando se ve la multidifusión.
En resumen, el comportamiento de CoS para un tipo de tráfico se muestra aquí:
‘Tipo de tráfico’ | Comportamiento de CoS |
unidifusión enrutada | copiado de 3-MSB de ToS |
unidifusión en puente | sin cambios |
ruteado multicast | copiado de 3-MSB de ToS |
bridge multicast con estado L3 para el grupo | copiado de 3-MSB de ToS |
bridge multicast sin estado L3 para el grupo | sin cambios |
Considere un ejemplo en el que se recibe tráfico en el puerto de acceso (Eth8/1) y se puentea en la VLAN. De forma predeterminada, el valor CoS del tráfico de unidifusión puenteado no cambia. Si el tráfico llega a un puerto de acceso, se asigna el valor predeterminado de CoS de 0. En este ejemplo, el tráfico de prioridad (DSCP 46) se recibe en un puerto de acceso y se dirige al switch sin cambios con el valor DSCP y un valor CoS de 0. Por lo tanto, el paquete no obtiene la prioridad adecuada.
Una solución alternativa potencial es crear una política de QoS para establecer manualmente el valor de CoS en el puerto de ingreso.
En el ejemplo, sólo los paquetes con DSCP 46 tienen sus valores CoS actualizados. Si hubiera varios valores DSCP requeridos para asegurar un valor CoS adecuado, se necesitarían definir mapas de clase adicionales y acciones en el policy-map.
Una opción alternativa es utilizar un mapa de tabla con la acción 'copia predeterminada'. El mapa de tabla le permite restablecer el DSCP en función del valor DSCP actual. Por ejemplo, si el tráfico se recibió con un valor DSCP de 40 y necesita asegurarse de que se remarque a un valor DSCP de 46, puede utilizar un mapa de tabla con la acción 'de 40 a 46'.
Un mapa de tabla también contiene una acción de 'copia predeterminada' que establece el valor DSCP en su valor original. Esto es similar a crear un policy-map con la clasificación de 'match dscp ef' y la acción de 'set dscp ef'. Lógicamente, el valor DSCP no cambia, pero la acción 'set dscp' establece de forma implícita el valor CoS en el 3-MSB del nuevo valor DSCP.
Por lo tanto, si necesita asegurarse de que el valor de CoS siempre se actualice a 3-MSB del valor DSCP, utilice un mapa de tabla con una única acción de 'copia predeterminada'.
Una vez que se deriva el valor CoS, puede manipular los mapas de clase de cola globales para afectar a las asignaciones de CoS a cola. Estos mapas de clase son globales y afectan a todos los módulos en todos los contextos de dispositivos virtuales (VDC) para ese tipo de cola concreto. Por ejemplo, considere estos mapas de clase de cola predeterminados para los módulos M108 y M132 (1p7q4t):
class-map type queuing match-any 1p7q4t-out-pq1
Description: Classifier for egress priority queue of type 1p7q4t
match cos 5-7
class-map type queuing match-any 1p7q4t-out-q2
Description: Classifier for egress queue 2 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q3
Description: Classifier for egress queue 3 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q4
Description: Classifier for egress queue 4 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q5
Description: Classifier for egress queue 5 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q6
Description: Classifier for egress queue 6 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q7
Description: Classifier for egress queue 7 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q-default
Description: Classifier for egress default queue of type 1p7q4t
match cos 0-4
De forma predeterminada, cos 0-4 se mapea a la cola predeterminada y cos 5-7 se mapea a la cola de prioridad. Éstos van de la mano con la política de colocación en cola predeterminada para el mismo tipo de colocación en cola:
policy-map type queuing default-out-policy
class type queuing out-pq1
priority level 1
queue-limit percent 16
class type queuing out-q2
queue-limit percent 1
class type queuing out-q3
queue-limit percent 1
class type queuing out-q-default
queue-limit percent 82
bandwidth remaining percent 25
La cola de prioridad es 'priority' con un límite de cola del 16%. La cola predeterminada tiene un límite de cola del 82% con un peso restante de ancho de banda predeterminado. A las otras colas, que no están en uso, se les asigna un límite de cola del 1%. Tenga en cuenta que q4, q5 y q6 no están representados en la política de colocación en cola predeterminada y, por lo tanto, tendrán un límite de cola aún menor y un peso de ancho de banda programado en hardware.
Para crear una política de cola personalizada, complete estos pasos:
Considere un ejemplo para los módulos M132 que tienen una arquitectura de cola 1p7q4t donde todos los valores de 8 CoS se mapean a una cola separada. El resultado muestra la política de colocación en cola personalizada junto con los cambios en los mapas de clase de envío a cola globales:
policy-map type queuing 10G_POLICY
class type queuing 1p7q4t-out-pq1
priority level 1
queue-limit percent 10
class type queuing 1p7q4t-out-q2
queue-limit percent 10
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q3
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q4
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q5
queue-limit percent 10
bandwidth remaining percent 20
class type queuing 1p7q4t-out-q6
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q7
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q-default
queue-limit percent 50
bandwidth remaining percent 40
! voice
class-map type queuing match-any 1p7q4t-out-pq1
match cos 5
! scavenger
class-map type queuing match-any 1p7q4t-out-q2
match cos 1
! transactional
class-map type queuing match-any 1p7q4t-out-q3
match cos 2
! call signaling
class-map type queuing match-any 1p7q4t-out-q4
match cos 3
! video
class-map type queuing match-any 1p7q4t-out-q5
match cos 4
! routing
class-map type queuing match-any 1p7q4t-out-q6
match cos 6
! management
class-map type queuing match-any 1p7q4t-out-q7
match cos 7
! best effort
class-map type queuing match-any 1p7q4t-out-q-default
match cos 0
El paso final es aplicar la política de colocación en cola personalizada a cada interfaz 1p7q4t:
interface Ethernet8/1
service-policy type queuing output 10G_POLICY
La política de colocación en cola predeterminada asume que la CoS 0-4 está asignada a la cola predeterminada y que la CoS 5-7 está asignada a la cola de prioridad. Por lo tanto, los límites de cola para las colas q3, q4, q5, q6 y q7 son extremadamente pequeños. Puede ingresar el comando show queuing interface para validar el tamaño de cola y el ancho de banda actuales configurados y aplicados en el hardware.
Considere la política de ejemplo de la sección anterior donde cada valor de CoS se mapeó a una cola específica. Al final del ejemplo, la política de colocación en cola personalizada se aplicó a Eth8/1. Además, supongamos que hay otra interfaz 1p7q4t (Eth6/1) que se dejó con la política de colocación en cola predeterminada:
N7k# show queuing interface e6/1
<some output omitted>
Configured queue-limit ratios
queue-limit ratios: 78[1p7q4t-out-q-default] 1[1p7q4t-out-q2] 1[1p7q4t-out-q3]
*1[1p7q4t-out-q4] *1[1p7q4t-out-q5] *1[1p7q4t-out-q6] *1[1p7q4t-out-q7] 16[1p7q4t-out-pq1]
* means unused queue with mandatory minimum queue-limit
Thresholds:
COS Queue Threshold Type Min Max
______________________________________________________________
0 1p7q4t-out-q-default DT 100 100
1 1p7q4t-out-q2 DT 100 100
2 1p7q4t-out-q3 DT 100 100
3 1p7q4t-out-q4 DT 100 100
4 1p7q4t-out-q5 DT 100 100
5 1p7q4t-out-pq1 DT 100 100
6 1p7q4t-out-q6 DT 100 100
7 1p7q4t-out-q7 DT 100 100
A partir del resultado anterior, puede ver que las colas q2 y q3 tienen un límite de cola del 1%, mientras que q4, q5, q6 y q7 tienen *1%, que es el límite de cola obligatorio mínimo (en otras palabras, significativamente inferior al 1%). Además, puede ver que los valores de CoS 1-4 y 6-7 utilizan estas colas muy pequeñas. Los pequeños tamaños de cola provocan rápidamente descartes de salida y pueden degradar el rendimiento de la red. Esto se exacerba aún más si el tráfico predeterminado CoS 0 se mapea a una de estas colas pequeñas.
En resumen, si crea una política de colocación en cola personalizada y cambia los class-maps globales, es fundamental aplicar la política de colocación en cola personalizada a todas las interfaces del chasis que comparten el mismo tipo de colocación en cola.
Además, a continuación se enumeran algunos comandos drop útiles:
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
29-May-2013 |
Versión inicial |