Ce document fournit un exemple de configuration pour le formatage du trafic Frame Relay.
Aucune condition préalable spécifique n'est requise pour ce document.
Le formatage du trafic Frame Relay est pris en charge depuis la version 11.2 du logiciel Cisco IOS®.
Il est pris en charge sur les routeurs Cisco 7200 et les plates-formes inférieures. Le formatage du trafic distribué est pris en charge sur les routeurs Cisco 7500, 7600 et le module FlexWAN.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
Les mises en oeuvre courantes du formatage du trafic Frame Relay sont les suivantes :
Non-concordance des circuits haute vitesse à basse vitesse : Deux possibilités s'offrent à vous :
Le site concentrateur possède une ligne T1 dans le cloud, tandis que le site distant a une vitesse inférieure (56 Kbits/s). Dans ce cas, vous devez limiter la vitesse du site concentrateur afin qu'elle ne dépasse pas le débit d'accès latéral distant.
Le site concentrateur dispose d'une ligne T1 unique dans le cloud, tandis que les sites distants disposent également d'une ligne T1 complète dans le cloud, se connectant au même site concentrateur. Dans ce cas, vous devez limiter la vitesse des sites distants afin de ne pas surcharger le concentrateur.
Surabonnement : Par exemple, si le débit garanti sur un circuit virtuel permanent (PVC) est de 64 Kbits/s et que le débit d’accès est de 128 Kbits/s aux deux extrémités, il est possible de déborder au-dessus du débit garanti en l’absence de congestion et de revenir au débit garanti en cas d’encombrement.
Qualité de service: Pour mettre en oeuvre des fonctions de fragmentation FRF.12 ou de mise en file d'attente à faible latence afin d'obtenir une meilleure qualité de service, consultez VoIP sur Frame Relay avec qualité de service.
Remarque : le débit d'accès correspond à la vitesse de ligne physique de l'interface connectée au relais de trames. Le taux garanti correspond au débit de données garanti (CIR) que la compagnie de téléphone a donné pour le circuit virtuel permanent. Il est préférable d'éviter de définir le débit de données garanti ou le débit minimal garanti au débit d'accès, car cela peut entraîner des pertes de sortie, entraînant une limitation du trafic. La raison en est que le taux de forme ne prend pas en compte les octets de surcharge des champs Indicateur et Contrôle de redondance cyclique (CRC). Ainsi, le formatage au débit de ligne est en fait en sursouscription, et provoquera un encombrement de l'interface. Il n'est pas recommandé d'effectuer une mise en forme au débit d'accès. Vous devez toujours modeler le trafic à 95 % du débit d'accès. Plus généralement, le taux en forme d'agrégat ne doit pas dépasser 95 % du taux d'accès.
Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.
Remarque : Pour obtenir des informations supplémentaires sur les commandes utilisées dans ce document, utilisez l'outil de recherche de commandes IOS
Ce document utilise la configuration réseau suivante :
Dans l'exemple ci-dessus, nous avons les valeurs suivantes :
HUB : débit d'accès = 192 Kbits/s, débit garanti = 32 Kbits/s
DISTANT - débit d'accès = 64 Kbits/s, débit garanti = 32 Kbits/s
Ici, nous mettons en oeuvre le formatage du trafic aux deux extrémités de sorte que le débit moyen de transmission soit de 64 Kbits/s. Si nécessaire, le concentrateur peut éclater au-dessus de ceci. En cas d'encombrement, il peut descendre jusqu'à 32 Kbits/s au minimum. La notification d'encombrement à partir du cloud s'effectue via la notification explicite d'encombrement (BECN) en amont. Par conséquent, le formatage est configuré pour s'adapter au BECN.
Remarque : le formatage du trafic Frame Relay est activé sur l'interface principale et s'applique à tous les identificateurs de connexion de liaison de données (DLCI) sous cette interface. Nous ne pouvons pas activer le formatage du trafic uniquement pour un DLCI ou une sous-interface spécifique sous l'interface principale. Si un DLCI donné n'a pas de classe de mappage qui lui est associée et que le formatage du trafic est activé sur l'interface principale, le DLCI se voit attribuer une classe de mappage par défaut avec CIR = 56000.
Ce document utilise les configurations suivantes :
Concentrateur
À distance
Concentrateur |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping !--- Apply traffic shaping to main interface (step 3). interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco !--- Apply map class to the DLCI / subinterface (step 2). ! ! !--- Configure map class parameters (step 1). map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 frame-relay be 16000 ! |
À distance |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.1.1.2 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco ! map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 ! |
Ce schéma montre le trafic envoyé par le routeur HUB :
En supposant que le trafic est envoyé avec une rafale de 80000 bits, ceci est envoyé hors du circuit virtuel permanent en 8 intervalles de Tc (125 ms chacun). Nous pouvons y parvenir car, dans le premier intervalle, le crédit disponible est Bc + Be = 8000 + 16000 = 24000 bits. Cela signifie que le débit est de 24 000 bits / 125 ms = 192 Kbits/s.
Au cours des sept prochains intervalles, il est seulement Bc = 8000 bits. Le débit est donc de 8000 / 125 ms = 64 Kbits/s.
Par exemple, si nous recevons une rafale de 88 000 bits, nous ne pouvons pas envoyer tout ce trafic à des intervalles de 8 Tc. Les 8 000 derniers bits seront envoyés dans l’intervalle 9e Tc. Ainsi, ce trafic est retardé par le mécanisme de formatage du trafic.
Cette section présente des informations que vous pouvez utiliser pour vous assurer que votre configuration fonctionne correctement.
Certaines commandes show sont prises en charge par l'Output Interpreter Tool (clients enregistrés uniquement), qui vous permet de voir une analyse de la sortie de la commande show.
Utilisez la commande show frame relay pvc <dlci> pour afficher les détails de configuration :
Hub#show frame relay pvc 16 PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1 input pkts 8743 output pkts 5 in bytes 2548330 out bytes 520 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Shaping adapts to BECN pvc create time 6d01h, last time pvc status changed 6d01h cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 mincir 56000 byte increment 1000 Adaptive Shaping BECN pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued
Ceci indique, en temps réel, si le mécanisme de formatage du trafic a été activé ou non. Le formatage du trafic est actif dans les scénarios suivants :
Les BECN sont reçus et DLCI a été configuré pour former les BECN.
Le nombre d'octets de données à transmettre à partir d'une interface est supérieur au crédit disponible (limite d'octets) dans un intervalle donné (Tc).
La fragmentation FRF.12 a été configurée et les paquets attendent d'être fragmentés.
Indique le nombre de paquets et d'octets qui ont été retardés en raison de l'activation du mécanisme de formatage du trafic. Cela s'applique principalement si le nombre d'octets à transmettre dépasse le crédit disponible par intervalle, ou si les paquets doivent être fragmentés (FRF.12). Ces paquets et octets sont stockés dans la file d'attente de mise en forme (allouée par circuit virtuel), puis transmis à intervalles ultérieurs lorsqu'il y a suffisamment de crédit disponible.
Indique le nombre de pertes dans la file d'attente de mise en forme. Les octets sont d'abord retardés par le mécanisme de mise en forme et stockés dans cette file d'attente. Si la file d'attente est remplie, les paquets sont abandonnés. Par défaut, le type de file d'attente est FCFS (First Come First Serve) ou FIFO, mais peut être modifié en WFQ, PQ, CQ, CBWFQ ou LLQ. Voir les informations connexes
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
31-May-2005 |
Première publication |