Este documento revisa qué funciones de calidad de servicio (QoS) se pueden configurar en interfaces de túnel mediante la encapsulación de routing genérico (GRE). Los túneles configurados con la seguridad IP (IPSec) quedan fuera del ámbito de este documento.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
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.
Antes de saber de la QoS sobre los túneles GRE, primero necesita comprender el formato de un paquete tunelizado.
Una interfaz de túnel es una interfaz virtual o lógica en un router que está ejecutando el software del IOS® de Cisco. Crea un link virtual punto a punto entre dos routers Cisco en puntos remotos, en una operación entre redes IP.
GRE es un protocolo de encapsulación compatible con IOS y definido en RFC 1702. Los protocolos de tunelización encapsulan los paquetes dentro de un protocolo de transporte.
Una interfaz de túnel admite un encabezado para cada uno de estos:
Un protocolo pasajero o un protocolo encapsulado, como por ejemplo IP, Apple Talk, DECnet o IPX.
Un protocolo de portadora (GRE en este caso).
Un protocolo de transporte (IP sólo en este caso).
Aquí se ilustra el formato de un paquete de túnel:
Consulte Configuración de Interfaces Lógicas para obtener más información sobre la configuración de túneles GRE.
Una interfaz de túnel admite muchas de las mismas funciones de Calidad de servicio (QoS) que una interfaz física. Estas secciones describen las funciones de QoS admitidas.
Cisco IOS Software Release12.0(7)T introdujo la compatibilidad para aplicar el modelado de tráfico genérico (GTS) directamente en la interfaz de túnel. El siguiente ejemplo de configuración le da forma a la interfaz de túnel a una velocidad general de salida de 500 kbps. Refiérase a Configuración del Modelado Genérico del Tráfico para obtener más información.
interface Tunnel0 ip address 130.1.2.1 255.255.255.0 traffic-shape rate 500000 125000 125000 1000 tunnel source 10.1.1.1 tunnel destination 10.2.2.2
La versión 12.1(2)T del software Cisco IOS añadió compatibilidad para el modelado basado en clases mediante la interfaz de línea de comandos (MQC) de QoS modular. El siguiente ejemplo de configuración muestra cómo aplicar la misma política de modelado a la interfaz de túnel con los comandos MQC. Refiérase a Configuración del Modelado Basado en la Clase para obtener más información.
policy-map tunnel class class-default shape average 500000 125000 125000 interface Tunnel0 ip address 130.1.2.1 255.255.255.0 service-policy output tunnel tunnel source 130.1.35.1 tunnel destination 130.1.35.2
Cuando se congestiona una interfaz y los paquetes comienzan a acumularse, puede aplicar un método de colocación en cola a los paquetes que esperan ser transmitidos. Las interfaces lógicas del IOS de Cisco no soportan de forma inherente un estado de congestión y no soportan la aplicación directa de una política de servicios que se aplica a un método de colocación en cola. En su lugar, debe aplicar una política jerárquica como sigue:
Cree una política "hija" o de menor nivel que configure un mecanismo de colocación en cola, como colocación en cola de latencia baja y colocación en cola equilibrada ponderada calculada en función de la clase (CBWFQ) con el comando bandwidth. Refiérase a Administración de Congestión para obtener más información.
policy-map child class voice priority 512
Cree una política "controlante" o de nivel superior que aplique un modelado basado en clase. Aplique la política secundaria como un comando bajo la política primaria, ya que el control de admisión para la clase secundaria se realiza en función de la velocidad de modelado para la clase primaria.
policy-map tunnel class class-default shape average 2000000 service-policy child
Aplique la política primaria a la interfaz de túnel.
interface tunnel0 service-policy tunnel
El router imprime este mensaje de registro cuando se configura una interfaz de túnel con una política de servicio que aplica la colocación en cola sin modelado.
router(config)# interface tunnel1 router(config-if)# service-policy output child Class Based Weighted Fair Queueing not supported on this interface
Las interfaces de túnel también admiten políticas basadas en clases, pero no admiten velocidad de acceso comprometida (CAR).
Nota: Las políticas de servicio no se soportan en las interfaces de túnel en 7500.
La versión 11.3T del software Cisco IOS introdujo Marcado de Túnel GRE y Valores de Precedencia IP o DSCP, que configura el router para que copie los valores de bit de precedencia IP del byte ToS al túnel o al encabezado IP GRE que encapsula el paquete interno. Anteriormente, esos bits estaban configurados en cero. Los routers intermedios entre los puntos finales del túnel pueden usar valores de precedencia IP para clasificar los paquetes para las funciones de calidad de servicio (QoS), tales como política de ruteo, WFQ y detección temprana aleatoria ponderada (WRED).
Cuando los paquetes son encapsulados por encabezados de túnel o encripción, las funciones QoS no pueden examinar los encabezados originales de los paquetes y clasificar correctamente los paquetes. Los paquetes que se transmiten a través del mismo túnel tienen los mismos encabezados de túnel. Por lo tanto, los paquetes son tratados de manera similar cuando la interfaz física está congestionada. Con la introducción de la función de calidad de servicio para las redes privadas de servicio virtual (VPN), ahora se pueden clasificar los paquetes antes de que ocurra la tunelización o encriptación.
En este ejemplo, tunnel0 es el nombre del túnel. El comando qos pre-classify habilita la QoS para la función VPNs en tunnel0.
Router(config)# interface tunnel0 Router(config-if)# qos pre-classify
Nota: El comando qos pre-classify se puede utilizar para clasificar el tráfico en base a valores que no sean precedencia IP o DSCP. Por ejemplo, es posible que desee clasificar los paquetes según el flujo IP o la información de la Capa 3, como la dirección IP de origen y destino para la que se puede utilizar este comando. El comando qos pre-classify sólo se requiere si clasifica el tráfico en IP, protocolo o puerto. Si la clasificación se basa en el código DSCP, no se requiere la clasificación previa de qos.
Al configurar una política de servicio, es posible que primero deba caracterizar el tráfico que atraviesa el túnel. El IOS de Cisco, admite Netflow y contabilidad IP de Cisco Express Forwarding (CEF) en interfaces lógicas como túneles. Refiérase a la Guía de Soluciones de Servicios de NetFlow para obtener más información.
Puede aplicar una política de servicio a la interfaz de túnel o a la interfaz física subyacente. La decisión de dónde aplicar la política depende de los objetivos de QoS. También depende de qué encabezado necesita utilizar para clasificación.
Aplique la política a la interfaz de túnel sin qos-preclassify cuando quiera clasificar paquetes según el encabezado anterior al túnel.
Aplique la política a la interfaz física sin qos-preclassify cuando desee clasificar paquetes según el encabezado posterior al túnel. Asimismo, aplique la política a la interfaz física cuando desee modelar o vigilar todo el tráfico perteneciente a un túnel, y la interfaz física admita varios túneles.
Aplique la política a una interfaz física y habilite qos-preclassify en una interfaz de túnel cuando desee clasificar paquetes según el encabezado previo al túnel.
CBWFQ dentro del modelado basado en clases no se soporta en una interfaz multipunto. El ID de falla de funcionamiento de Cisco CSCds87191 configura al router para que imprima un mensaje de error al rechazar la política.
En condiciones poco comunes, la aplicación de una política de servicio configurada con el comando shape conduce a un uso excesivo de la CPU y a errores de alineación. La carga de la CPU es causada por el registro de los errores de alineación, que a su vez son causados por CEF que configura incorrectamente la interfaz de salida y la información de reescritura de adyacencia. Este problema afecta solamente a las plataformas sin RSP (poco sofisticadas) y a las plataformas que utilizan conmutación CEF basada en partículas. La resolución del problema se lleva a cabo con los ID de errores de funcionamiento de Cisco CSCdu45504 y CSCuk30302. También puede considerar estas soluciones alternativas:
Reemplace la encapsulación GRE con el modo de túnel ipip.
Reemplace el comando shape por el comando police.
Configure el modelado en la interfaz física que soporta el túnel.