Este documento revisa qué funciones de Calidad de servicio (QoS) se pueden configurar en las 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.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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 paquetes dentro de un protocolo de transporte.
Una interfaz de túnel admite un encabezado para cada uno de estos elementos:
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).
El formato de un paquete de túnel se ilustra aquí:
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. En estas secciones se describen las funciones de QoS admitidas.
La versión 12.0(7)T del software del IOS de Cisco introdujo el soporte 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. Consulte Configuración del Modelado de Tráfico Genérico 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 del IOS de Cisco añadió soporte para modelado basado en clase 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 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 se indica a continuación:
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. Consulte 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 directiva secundaria como un comando en la directiva 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 principal 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 clase, pero no admiten la 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 del IOS de Cisco introdujo el marcado de túnel GRE y los valores de precedencia DSCP o IP, que configura el router para copiar los valores de bit de precedencia IP del byte ToS en el túnel o 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 basado en valores distintos de la precedencia IP o DSCP. Por ejemplo, es posible que desee clasificar los paquetes en función del flujo IP o de la información de la capa 3, como la dirección IP de origen y de destino para la que se puede utilizar este comando. El comando qos pre-classify se requiere solamente si clasifica el tráfico en IP, protocolo o puerto. Si la clasificación se basa en el código DSCP, qos pre-classify no es necesario.
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. Consulte la Guía de Soluciones de Servicios 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 basados en el encabezado post-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 basados en el encabezado anterior al túnel.
El modelado basado en clases internas de CBWFQ no se admite 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 alto uso 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 el CEF que configura incorrectamente la interfaz de salida y la información de reescritura de adyacencia. Este problema afecta solamente a las plataformas que no son RSP (de gama baja) y a las plataformas que usan switching CEF basado en partículas, y se resuelve a través de los ID de bug de Cisco CSCdu4504 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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
27-Nov-2001
|
Versión inicial |