Comprensión de cómo se envían a cola las actualizaciones de ruteo y los paquetes de control de Capa 2 en una interfaz con una política de servicio de QoS.

Introducción

Este documento explica cómo los mensajes del protocolo de ruteo, como los saludos y descriptores de base de datos, así como otro tráfico de control importante se ponen en cola cuando una interfaz de router saliente se configura con una política de servicio usando los comandos de la interfaz de línea de comandos de calidad de servicio modular (MQC).

Específicamente, este documento revisa estos dos mecanismos utilizados por los routers Cisco IOS^® para priorizar los paquetes de control:

Campo	Ubicación	Donde se considera la prioridad
Bits de precedencia IP	Byte de tipo de servicio (TOS) en el encabezado IP	Provee prioridad a través de la red
pak_priority	Etiqueta de paquete interna dentro del router, asignada por el controlador de interfaz	Proporciona prioridad a través del router (por salto)

Ambos mecanismos están diseñados para garantizar que ni el router ni el sistema de colocación en cola interrumpan los paquetes de control clave o los interrumpan en último lugar cuando una interfaz de salida está congestionada.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en la versión de software 12.2 del IOS de Cisco.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Etiquetas para dar prioridad a paquetes externos

Request for Comments (RFC) 791 define el byte TOS en el encabezado de un paquete IP. Aunque RFC 2474 y RFC 2475 redefinen este byte como valores de punto de código de servicios diferenciados (DSCP), un router Cisco IOS todavía utiliza los bits de precedencia IP originales del byte TOS, según RFC 791. Observe cómo RFC define el byte TOS:

"El Tipo de servicio proporciona una indicación de los parámetros abstractos de la calidad del servicio deseado. Estos parámetros se deben utilizar para guiar la selección de los parámetros de servicio reales durante la transmisión de un datagrama a través de una red determinada. Varias redes ofrecen precedencia de servicio, que de alguna manera trata el tráfico de alta precedencia como más importante que otro tráfico (generalmente aceptando sólo el tráfico por encima de una determinada precedencia en el momento de la carga alta)".

Como se ilustra en el diagrama, el campo de precedencia IP ocupa los tres bits más significativos del byte TOS. Únicamente los tres bits de precedencia IP reflejan la prioridad o importancia del paquete, no el valor completo del byte TOS.

Esta tabla enumera los valores de los bits de precedencia:

Número	Valor de bit	Nombre
0	000	Rutina
1	001	Prioridad
2	010	Immediate
3	011	Flash
4	100	Sustitución de Flash
5	101	CRITIC/ECP
6	110	Control entre redes
7	111	Control de red

Cisco IOS asigna una precedencia IP de 6 a los paquetes de protocolo de ruteo en el plano de control. Como lo señala RFC 791, "La designación de Control de Internetwork está pensada para que la usen solamente los originadores de control de gateway". Específicamente, Cisco IOS marca estos paquetes de control basados en IP: Abrir el trayecto más corto primero (OSPF), Protocolo de información de ruteo (RIP), saludos del Protocolo de ruteo de gateway interior mejorado (EIGRP) y señales de mantenimiento. Los paquetes Telnet que ingresan y salen del router también reciben una precedencia IP de valor 6. El valor asignado permanece junto a los paquetes cuando la interfaz de salida los transmite dentro de la red.

Etiquetas para priorización de paquetes internos

Mientras que el valor de precedencia IP especifica el tratamiento de un datagrama dentro de su transmisión a través de la red, el mecanismo pak_priority especifica el tratamiento de un paquete durante su transmisión dentro del router.

Además del núcleo de una CPU del router, cada interfaz utiliza un controlador de red o una CPU local, que ejecuta un software especial llamado driver. El código del controlador proporciona instrucciones específicas de la interfaz.

Cuando recibe un paquete, el controlador de interfaz copia el paquete de un búfer pequeño primero en entrar, primero en salir (FIFO) a un búfer de datos en la memoria de entrada/salida (E/S). Luego, conecta un encabezado de paquete pequeño al búfer. El encabezado del paquete, llamado en la terminología de IOS de Cisco como estructura paktype, contiene información clave sobre el bloque de datos en el búfer. Según el contenido del paquete, el encabezado del paquete puede señalar la dirección en la memoria donde se inicia el encabezado de encapsulación Ethernet, el encabezado de protocolo de Internet (IP) y el encabezado de protocolo de control de transmisión (TCP).

El software de Cisco IOS utiliza los campos en el encabezado del paquete para controlar el manejo del paquete en colas de interfaz. El encabezado del paquete incluye el indicador pak_priority, que señala la importancia relativa de los paquetes marcados para el sistema de cola.

Los procesos de ruteo RIP y OSPF que se ejecutan en la CPU del núcleo de un router marcan todo el tráfico que originan con precedencia IP 6 y pak_priority. Por el contrario, el protocolo de gateway fronterizo (BGP) indica a TCP que marque su tráfico con precedencia IP 6, pero no establece pak_priority.

Cisco IOS también debe garantizar una baja probabilidad de caída para varios tipos de paquetes de control no IP. Estos tipos de paquetes incluyen:

• Mensajes de protocolo de routing de sistema intermedio a sistema intermedio (IS-IS)

• Mensajes de protocolo de routing de gateway interior mejorado (EIGRP)

• Señales de mantenimiento de High-Level Data Link Control (HDLC) y Point-to-Point Protocol (PPP) en interfaces de Packet Over SONET (POS) y seriales

• Celdas de Operaciones, administración y mantenimiento (OAM) y mensajes del Protocolo de resolución de direcciones (ARP) en interfaces ATM

Debido a que este tráfico no es IP, el IOS de Cisco no puede coincidir en el valor de precedencia IP para otorgar prioridad. En su lugar, utiliza solamente el valor de pak_priority interno en el encabezado del buffer de paquetes.

Nota: Los switches Catalyst de Cisco serie 6000 / 7600 inicialmente admitieron el mecanismo pak_priority sólo en FlexWAN. Posteriormente se implementaron mejoras en la priorización de los paquetes de control IP y no IP.

Almacenamiento en cola y etiquetas de priorización de paquetes

Los routers como Cisco 7500 Route/Switch Processor (RSP) y los routers de menor capacidad (como Cisco 7200 y 3600 Series) utilizan un mecanismo diferente para rutear y controlar el tráfico que Cisco 7500 Versatile Interface Processor (VIP). Esta tabla resume los dos enfoques y asume que una política de servicio configurada con el MQC se aplica a la interfaz saliente.

Platform	Mensajes de cola de prioridad pak
Cisco serie 7500 (con QoS y VIP distribuidos)	Ubica el tráfico pak_priority en la cola de clase predeterminada o en una cola (separada) configurada específicamente. Cuando se coloca en cola a class-default, los paquetes van al extremo final de la cola. El indicador pak_priority se usa para evitar la caída de los paquetes de alta prioridad.
QoS basada en RSP y otras plataformas, que incluyen las series 7200, 3600 y 2600 de Cisco	Coloca el tráfico pak_priority en otro conjunto de colas que no sea class-default (clase predeterminada). (Consulte la sección Comprensión de las Colas Especiales con Plataformas No RSP.) Marca dichos mensajes con un valor de peso especial (actualmente 1024).

En otras palabras, en la serie 7500 de Cisco, si se adjunta una política de servicio de salida a la interfaz, los paquetes se clasifican con respecto a las clases de esa política y el paquete pak_priority se coloca al final de la cola de clase elegida. Si el paquete pak_priority no coincide con ninguna clase definida por el usuario, se coloca en la cola de la cola class-default.

Nota: Con los métodos de colocación en cola heredados como la colocación en cola prioritaria y la colocación en cola personalizada o con una cola FIFO de interfaz predeterminada, los mensajes de prioridad_pak de los routers no RSP enqueue al jefe de la cola para garantizar una latencia mínima y una probabilidad de caída mínima.

Comprender las colas especiales con la plataforma que no es RSP

Como se indica en la tabla Etiquetas y colas de priorización de paquetes, las plataformas de router de Cisco como las series 7200, 3600 y 2600 de Cisco colocan los mensajes pak_priority en un conjunto separado de colas y no en el conjunto de colas predeterminado de clase.

Hay tres conjuntos de colas en una interfaz:

• 2^n conjunto de colas basadas en flujo que tienen en cuenta valores de encabezado como las direcciones IP de origen y de destino. El número real de colas se basa en el ancho de banda de una interfaz o circuito virtual. Consulte la descripción del comando fair-queue en la Referencia de Comandos de Cisco IOS.

• Colas para clases creadas por los usuarios.

• Colas a las que se accede en función de un hash del tipo de link. Por ejemplo, los microflujos IP son clasificados por el sistema de cola justa en colas basándose en un hash de las direcciones de origen y destino y los puertos, los bits TOS y el número de protocolo IP. Los mensajes de la interfaz de administración local (LMI) de Frame Relay se ponen en cola basándose en un hash del número mágico que indica que el mensaje es LMI. Los mensajes con el indicador pak_priority entran en estas colas de tipo de link independientes.

Esta tabla enumera las diversas colas y sus ID de conversación (como se ve en el resultado de los comandos show policy-map interface o show queue) para una interfaz con más de 512 Kbps de ancho de banda.

Número de conversación/cola	‘Tipo de tráfico’
1 - 256	Colas de tráfico generales basadas en flujo. El tráfico que no coincide con una clase creada por el usuario coincide con la clase predeterminada y una de las colas basadas en flujo.
257 - 263	Reservado para Cisco Discovery Protocol y para paquetes marcados con un indicador interno de alta prioridad.
264	Cola reservada para la clase de prioridad (clases configuradas con el comando priority). Busque el valor "Strict Priority" para la clase en el resultado show policy-map interface. La cola de prioridad utiliza un ID de conversación igual al número de colas dinámicas más 8.
265 y superior	Colas para clases creadas por los usuarios.

Nota: Los valores de esta tabla dependen de la implementación y están sujetos a cambios.

Priorizar paquetes IS-IS

Los paquetes de control de ruteo del sistema intermedio al sistema intermedio (IS-IS) son un caso especial con respecto a la colocación en cola y la priorización de paquetes.

El IS-IS es el protocolo de routing para el protocolo de red sin conexión (CLNP) de la Organización Internacional de Normalización (ISO). Los desarrolladores de CLNP veían al TCP/IP como un conjunto de protocolos interinos que finalmente serían reemplazados por el Open System Interconnection (OSI). Para admitir esta transición prevista, se creó Integrated IS-IS (o IS-IS dual) como extensión de IS-IS para proporcionar un único protocolo de routing capaz de rutear tanto el servicio de red en modo de conexión (CLNS) como la IP. El protocolo se diseñó para funcionar en un entorno CLNS puro, un entorno IP puro o un entorno CLNS/IP dual.

Incluso cuando IS-IS se utiliza para rutear solamente TCP/IP, IS-IS sigue siendo un protocolo ISO CLNP. Los paquetes por los que IS-IS se comunica con sus pares son las unidades de datos del protocolo CLNS (PDU), lo que a su vez significa que incluso en un entorno solo IP, el sistema de colocación en cola y Cisco IOS no pueden utilizar la precedencia IP para priorizar los mensajes de control CLNS. En su lugar, los paquetes IS-IS reciben prioridad a través del mecanismo pak_priority dentro del router.

Configuración de una Estrategia de Colocación en Cola para Paquetes de Ruteo

Esta sección considera los tres enfoques generales para diseñar una estrategia de colocación en cola específicamente para minimizar las posibilidades de paquetes de control caídos bajo condiciones de congestión pesada en los Cisco 7500 Series y VIP. (Recuerde que las plataformas que no son RSP colocan los paquetes de control en colas separadas de forma predeterminada).

Estrategia	Cuándo se debe utilizar	Descripción de Cómo Configurar
Coincidir con una cola separada.	La estrategia más conservadora. Asegura pocas caídas o ninguna.	Utilice el QoS CLI modular para configurar una clase separada y utilice el comando bandwidth para atribuir una asignación de ancho de banda mínima al tráfico coincidente durante los períodos de congestión. Una clase configurada con el comando bandwidth utiliza un "peso" de planificación basado en el ancho de banda y no en la precedencia IP. Consulte Introducción a Class Based Weighted Fair Queuing en ATM.
Coincida con class-default con cola justa.	Suficiente para la mayoría de las configuraciones. Algunos paquetes de control se pueden descartar en presencia de congestión.	Utilice la precedencia IP 6 automáticamente asignada por Cisco IOS al paquete, a fin de influir en su peso y, así, su cuota de ancho de banda. Consulte la Introducción del envío a Cola equilibrada ponderada en ATM.
Coincida con la clase predeterminada con la cola FIFO.	No se recomienda para links congestionados. Algunos paquetes de control se pueden descartar en presencia de congestión.	Este enfoque no considera la precedencia de IP. Con la QoS basada en VIP, los mensajes pak_priority son colocados en el final de la cola FIFO.

Este es un ejemplo de cómo crear una cola separada para los paquetes de control RIP.

 class-map match-all rp 
   match access-group 104 
! 
 access-list 104 permit udp any eq rip any eq rip 

!--- Create a class-map that matches an ACL permitting RIP. 

! 
 policy-map bandwidth 
   class voip 
     priority 64 
   class bus 
    bandwidth 184 
   class RP 
    bandwidth 8 

!--- Create a policy-map (named "bandwidth") and specify !--- class RP. 
! 
interface Serial1/0:0.1 point-to-point 
  bandwidth 256 
  ip unnumbered Loopback0 
  ip accounting precedence input 
  no cdp enable 
  frame-relay class sample 
  frame-relay interface-dlci 100 IETF 

!--- Apply the map-class named "sample" to the PVC. 

! 
map-class frame-relay sample 
  frame-relay cir 256000 
  frame-relay bc 2560 
  frame-relay mincir 256000 
  no frame-relay adaptive-shaping 
  service-policy output bandwidth 
  frame-relay fragment 160 

!--- Create a frame relay map-class and apply the service !--- policy inside the map-class.

Tenga en cuenta estos factores al elegir uno de estos enfoques:

• El protocolo de ruteo particular utilizado y los valores del temporizador configurados para los saludos y la actualización de la base de datos

• El tamaño de la base de datos que debe intercambiarse y si sólo se actualizan periódicamente las actualizaciones/cambios o las tablas completas

• La cantidad de congestión esperada en la interfaz o en el circuito virtual

En otras palabras, considere las posibilidades de poner en cola paquetes de alta prioridad en presencia de congestión.

QoS y paquetes generados localmente

El tráfico generado por el router representa un caso especial para las políticas de servicio QoS internas. Algunos tráfico generado localmente deben tratarse como cualquier otro tráfico de usuario, y el sistema QoS debe aplicar los mecanismos de QoS configurados a este tráfico. Un ejemplo de este tráfico son las sondas de rendimiento que están diseñadas para medir el comportamiento incurrido por los paquetes de una clase determinada. El resto del tráfico generado localmente, particularmente los mensajes de keepalives de Capa 2 y del protocolo de ruteo, son vitales para el funcionamiento básico del router y no deben estar sujetos a algunas funciones de QoS. Por ejemplo, la detección temprana aleatoria ponderada (WRED) no debe descartar señales de mantenimiento de capa 2 cuando la profundidad media de la cola alcanza una marca de agua alta

Además, los paquetes destinados al router deben manejarse con cuidado. Por ejemplo, recuerde que una política de servicio que aplica regulación basada en clase no debe aplicarse a los paquetes destinados al router para evitar que se descarten mensajes de control importantes.

Nota: Según el diseño, los paquetes generados por RP no se contabilizan en los contadores modulares de QoS CLI, aunque esos paquetes se clasifican/ponen en cola correctamente. Esos paquetes no se contabilizan en el resultado del comando show policy-map interface.

Esta tabla enumera cómo los paquetes destinados al router y desde él interactúan actualmente con las funciones clave de QoS.

Función QoS	Descripción
Marcación basada en la clase	Originalmente, funcionaba sólo en paquetes conmutados de Cisco Express Forwarding (CEF). El soporte para los métodos process switching y fast switching se presenta en Cisco IOS Software Release 12.2(5) (CSCdt74738).
Control de tráfico	Entrante: se puede aplicar la limitación de velocidad. La interfaz entrante se debe configurar con CEF si se utiliza la Velocidad de acceso comprometida (CAR) (y no la regulación basada en clases). En un Cisco 7500 Series Router, la regulación del tráfico puede monitorear solamente las trayectorias de conmutación CEF. Saliente: limitación de velocidad con CAR o funcionamiento de regulación basado en clases.

Priorizar paquetes en Catalyst 6000

Cuando ejecuta Cisco IOS tanto en el supervisor como en la Tarjeta de función de switch de capas múltiples (MSFC) en el Catalyst 6000, el RP marca los paquetes de control de ruteo con precedencia IP 6. Se puede usar este valor remarcado con una planificación de resultado para asignar los paquetes de control de ruteo a la cola grande, el umbral grande en el sistema de ordenamiento cíclico ponderado (WRR). Tal mapeo de los paquetes de control de ruteo originados por la MSFC se realiza automáticamente siempre y cuando la QoS esté habilitada globalmente con el comando mls qos. Si habilita QoS, hace que el sistema configure todos los parámetros de cola, como umbrales de caída WRED, anchos de banda WRR y límites de cola. Con QoS inhabilitada globalmente, todos los paquetes se asignan a la cola baja, umbral bajo para la programación de salida, de WRR.

Como se indica en el capítulo Configuración de QoS de la Guía de Configuración de Catalyst 6000, QoS admite la clasificación, marcado, programación y prevención de congestión mediante los valores de clase de servicio (CoS) de capa 2 en los puertos de ingreso Ethernet. La clasificación, marcado, programación y prevención de congestión en los puertos de ingreso Ethernet no utilizan ni establecen valores de precedencia IP o DSCP de Capa 3. Además, con cualquier motor de conmutación, QoS admite la programación de puertos de salida Ethernet y la prevención de congestión con valores CoS de capa 2. Como resultado, los paquetes cruciales de IP y no IP se deben mapear a un valor de CoS, incluso si tales valores se utilizan solamente internamente como parte del encabezado del bus de datos. Los paquetes IP cruciales tienen su valor de precedencia IP de 6 asignado a un valor CoS equivalente de 6. Los paquetes cruciales que no son de IP, que incluyen paquetes IS-IS que se originan en la MSFC, se marcan con el indicador pak_priority y luego dichos paquetes marcados se asignan a un valor CoS de 6. Este mapeo se produce automáticamente en las versiones actuales del IOS de Cisco.

Ni los reguladores de tráfico de entrada ni los reguladores de egreso marcan los paquetes originados por la MSFC y destinados a la transmisión a través de una interfaz Ethernet física.

La configuración de la calidad de servicio (QoS) del Catalyst 6000 se encuentra fuera del alcance de este documento. Para obtener más información, consulte la Configuración de Calidad de servicio (QoS) y la página de soporte de los switches Catalyst de ATM y LAN.

Información Relacionada

• Páginas de soporte de Qos (calidad de servicio)
• Soporte Técnico y Documentación - Cisco Systems