QoS - Options de Qualité de Service sur des Interfaces Tunnels GRE ccnp_cch ccnp_cch

Sommaire • Introduction • Présentation de GRE - Composants utilisés • Présentation de GRE • Qos Cisco pour des tunnels GRE - Lissage de trafic - Application de politique - Evitement de congestion - Commande qos pre-classify • Caractérisation du trafic pour des politiques de QoS • Où est-ce que j'applique la politique de service? • Interfaces tunnel Multipoint • Problèmes connus ccnp_cch

Introduction Présentation de GRE ccnp_cch Ce document passe en revue quelles sont les fonctionnalités de QoS (Quality of Service) qui peuvent être configurées sur des interfaces tunnel utilisant GRE (Generic Routing Encapsulation). Les tunnels configurés avec IPSec ne sont pas traités dans ce document. Composants utilisés Ce document n'est restreint à aucune version logicielle ou matérielle. Présentation de GRE Avant de parler de la QoS sur les tunnels GRE, vous devez d'abord comprendre le format d'un paquet "tunnélisé". Une interface tunnel est une interface logique ou virtuelle sur un routeur opérant avec l'IOS Cisco. une liaison virtuelle point à point est crée entre deux routeurs Cisco aux extrémités d'un réseau IP. GRE est un protocole d'encapsulation supporté par l'IOS Cisco et défini par l'IETF dans le RFC1702. Les protocoles d'encapsulation encapsulent les paquets dans un protocole de transporteur. Une interface tunnel supporte un en-tête pour : ● Un protocole transporté tel que IP, AppleTalk, DECnet ou IPX. ● Un protocole de transporteur (GRE dans ce cas). ● Un protocol de couche réseau (IP dans ce cas). Le format d'un paquet tunnélisé est le suivant : 802.3 802.2 CLNP VT TP4 Ethernet IP GRE CLNP TP4 VT Protocol transporté Protocol transporteur Protocol de couche réseau ccnp_cch

QoS Cisco pour des tunnels GRE Une interface tunnel supporte plusieurs fonctionnalités de QoS identiques à celles sup- portées par une interface physique. Les sections suivantes décrivent les fonctionnalités de QoS supportées. Lissage L'IOS 12.0(7)T a introduit le support pour l'amélioration du GTS (Generic Traffic Sha- ping) directement sur une interface tunnel. L'exemple de configuration suivant fait un lissage avec un débit de sortie global de 500 Kb/s sur l'interface tunnel. 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 L'IOS 12.1(2)T a ajouté le support pour le lissage basé sur la classe en utilisant MQC (Modular QoS Command-line interface). L'exemple de configuration suivant montre comment appliquer la même politique de lissage à l'interface tunnel avec les comman- des MQC. policy−map tunnel class class−default shape average 500000 125000 125000 interface Tunnel0 service−policy output tunnel tunnel source 130.1.35.1 tunnel destination 130.1.35.2 Application de politique Quand une interface devient congestionnée et que les paquets commencent à être mis en file d'attente, vous pouvez appliquer une méthode de gestion de file d'attente aux pa- quets en attente de transmission. Les interfaces logiques de l'IOS Cisco n'héritent pas de l'état de congestion et ne supportent pas l'application directe d'une politique de ser- vice qui s'applique à une méthode de gestion de file d'attente. Au lieu de cela vous devez appliquer une politique hiérarchique comme suit: 1. Créer une politique enfant ou de niveau inférieur qui configure un mécanisme de file d'attente tel que la gestion de file d'attente ave faible latence avec la commande priority et CBWFQ (Class Based Weighted Fair Queueing) avec la commande band- width. policy−map child class voice priority 512 ccnp_cch

2. Créer une politique parent ou de niveau supérieur qui s'applique au lissage basé sur la classe. appliquer la politique enfant comme une commande dans la politique parent car le contrôle d'admission pour la classe enfant est fait sur le débit de lissa- ge de la classe parent. policy−map tunnel class class−default shape average 2000000 service−policy child 3. Appliquer la politique parent à l'interface Tunnel interface tunnel0 service−policy tunnel Le routeur affiche le message log suivant quand une interface tunnel est configurée avec une politique de service qui s'applique à une méthode de file d'attente sans lissage. router(config)# interface tunnel1 router(config−if)# service−policy output child Class Based Weighted Fair Queueing not supported on this interface Les interfaces Tunnel supportent également l'application de politique basée sur la clas- se mais ne supportent pas CAR (Committed Access Rate). Note : Les politiques de service ne sont pas supportées sur les interfaces tunnel d'un routeur Cisco 7500. Evitement de congestion L'IOS 11.3T a introduit la Precedence IP pour les tunnels GRE qui configure un routeur pour qu'il copie les bits de Precedence IP du champ ToS vers le tunnel ou l'en-tête GRE IP qui encapsule le paquet original. Avant cela ces bits étaient remis à zéro. Les rou- teurs intermédiaires entre les extrémités du tunnel peuvent utiliser les valeurs de Pre- cedence IP pour classifier les paquets pour des fonctionnalités telles que la politique de routage, WFQ (Weighted Fair Queue) et WRED (Weighted Random Early Detection). Commande qos pre-classify Quand les paquets sont encapsulés par tunnel ou par des en-têtes de cryptage, les fonctionnalités de QoS sont incapables d'examiner les en-têtes du paquet original pour classifier correctement les paquets. Les paquets passant dans le même tunnel ont les mêmes en-têtes tunnel ainsi les paquets sont traités de manière identique si l'interface physique est congestionnée. Avec l'introduction de la Qualité de service (QoS) pour les VPN (Virtual Private Network) les paquets peuvent être maintenant classifiés avant que la "tunnellisation" ou le cryptage soient faits. Dans l'exemple suivant, tunnel 0 est le nom du tunnel. la commande qos pre-classify valide la QoS pour la fonctionnalité VPN sur le tunnel 0. ccnp_cch

Router(config)# interface tunnel0 Router(config−if)# qos pre−classify Caractérisation du trafic pour les politiques de QoS Quand vous configurez une politique de service, vous devez d'abord caractériser le tra- fic qui traverse le tunnel. L'IOS Cisco supporte Netflow et l'accounting CEF (Cisco Ex- press Forwarding) sur les interfaces logiques telles que les tunnels. Où est-ce que j'applique la politique de service? Vous pouvez appliquer une politique de service soit à l'interface tunnel soit à l'interface physique sous-jacente. Le choix de l'endroit où appliquer la politique dépend des objec- tifs de QoS. Cela dépend également de l'en-tête que vous utilisez pour la classification. ● Appliquez la QoS à l'interface tunnel sans la commande qos pre-classify quand vous voulez classifier les paquets sur la base de l'en-tête avant le tunnel. ● Appliquez la politique à l'interface physique sans la commande qos pre-classify quand vous voulez classifier les paquets sur la base des en-têtes après tunnel. De plus, appliquez la politique à l'interface physique quand vous voulez lisser ou policer le trafic appartenant à un tunnel et que l'interface physique supporte plusieurs tun- nels. ● Appliquez la politique à l'interface physique et validez la commande qos pre-classify quand vous vous voulez classifier les paquets sur la base de l'en-tête avant tunnel. Interfaces tunnel multicast CBWFQ dans le lissage basé sur la classe n'est pas supporté sur une interface multi- point. Cisco bug ID CSCds87191 configure le routeur pour qu'il affiche un message d'erreur quand la politique est rejetée. Problèmes connus Dans de rares conditions, appliquer une "service-policy" avec la commande shape amè- ne une utilisation intensive de la CPU et des erreurs d'alignement. La charge CPU est causée par le logging des messages d'erreur d'alignement qui à leur tour sont causés par CEF qui paramètre mal l'interface de sortie et les informations de reécriture des adjacences. Ce problème affecte uniquement les plateformes sans RSP (routeurs de faible capacité) et les plateformes utilisant la commutation CEF basé sur la particule. Ce problème est résolu via Cisco bug CSCdu45504 et CSCuk30302. Vous pouvez aussi considérer les contournements possibles : ● Remplacer l'encapsulation GRE par tunnel mode ipip. ● Remplacer la commande shape par la commande police. ● Configurer le lissage sur l'interface physique supportant le tunnel. ccnp_cch