Contenu
Introduction
Le Frame Relay est un protocole WAN hautes performances qui fonctionne au niveau de la couche physique et de la couche liaison de données du modèle de référence ouvert System Interconnection (OSI). Il est décrit comme une version simplifiée de X.25 et est utilisé généralement au-dessus des connexions WAN fiables. Ce document répond à certaines des questions fréquemment posées au sujet du Frame Relay.
Généralités
Q. Pourquoi ne puis-je pas envoyer de requête ping à ma propre adresse d’interface ?
A. Vous ne pouvez pas envoyer de requête ping à votre propre adresse IP sur une interface Frame Relay multipoint. Pour qu’une requête ping réussisse sur une interface série, un paquet de requête d’écho ICMP (Internet Control Message Protocol) doit être envoyé et un paquet de réponse d’écho ICMP doit être reçu. Les requêtes ping vers votre propre adresse d’interface aboutissent sur des sous-interfaces point à point ou des liaisons HDLC (High-Level Data Link Control), car le routeur de l’autre côté de la liaison retourne les paquets de réponse d’écho et d’écho ICMP.
Le même principe s’applique également aux interfaces multipoints (sous-points). Pour envoyer une requête ping à votre propre adresse d’interface, un autre routeur doit renvoyer la requête d’écho ICMP et les paquets de réponse d’écho. Comme les interfaces multipoints peuvent avoir plusieurs destinations, le routeur doit avoir un mappage de couche 2 (L2) à couche 3 (L3) pour chaque destination. Comme le mappage n'est pas configuré pour notre propre adresse d'interface, le routeur ne dispose d'aucun mappage de couche 2 à couche 3 pour sa propre adresse et ne sait pas comment encapsuler le paquet. Autrement dit, le routeur ne sait pas quel identificateur de connexion de liaison de données (DLCI) utiliser pour envoyer des paquets de requête d’écho à sa propre adresse IP, ce qui entraîne une défaillance d’encapsulation. Pour pouvoir envoyer une requête ping à sa propre adresse d’interface, un mappage statique doit être configuré pointant vers un autre routeur via la liaison Frame Relay qui peut renvoyer les paquets de requête d’écho et de réponse ICMP.
Q. Pourquoi est-ce que je ne parviens pas à envoyer une requête ping d'un rayon à un autre dans une configuration de concentrateur et de rayon à l'aide d'interfaces multipoints (sous) ?
A. Vous ne pouvez pas envoyer de requête ping d'un rayon à un autre dans une configuration Hub and Spoke à l'aide d'interfaces multipoints, car le mappage de l'adresse IP de l'autre rayon n'est pas effectué automatiquement. Seule l'adresse du concentrateur est automatiquement apprise au moyen du protocole INARP (Inverse Address Resolution Protocol). Si vous configurez une carte statique à l'aide de la commande frame-relay map pour l'adresse IP d'un autre rayon pour utiliser l'identificateur de connexion de liaison de données locale (DLCI), vous pouvez envoyer une requête ping à l'adresse de l'autre rayon.
Q. Qu’est-ce que la file d’attente de diffusion Frame Relay ?
A. La file d’attente de diffusion Frame Relay est une fonctionnalité majeure utilisée dans les réseaux IP ou IPX (Internet Package Exchange) de taille moyenne à grande dans lesquels les diffusions de protocole SAP (Service Advertising Protocol) et de routage doivent circuler sur le réseau Frame Relay. La file d'attente de diffusion est gérée indépendamment de la file d'attente d'interface normale, dispose de ses propres tampons et d'une taille et d'un débit de service configurables. En raison des sensibilités de synchronisation, les unités BPDU (Bridge Protocol Data Units) STP (Spanning Tree Protocol) ne sont pas transmises à l'aide de la file d'attente de diffusion.
Q. Combien d’identificateurs de connexion de liaison de données (DLCI) une interface peut-elle prendre en charge ?
A. Cette question est similaire à la question du nombre de PC que vous pouvez mettre sur un réseau Ethernet. En général, vous pouvez en mettre beaucoup plus que vous ne le devriez, compte tenu des contraintes de performances et de disponibilité. Lors du dimensionnement d’un routeur dans un grand réseau, tenez compte des points suivants :
Espace d’adressage DLCI : Avec une adresse 10 bits, environ 1 000 DLCI peuvent être configurés sur une seule liaison physique. Étant donné que certains DLCI sont réservés (dépendant de l'implémentation du fournisseur), le maximum est d'environ 1 000. La plage de l'interface de gestion locale (LMI) de Cisco est comprise entre 16 et 1007. L'intervalle entre l'American National Standards Institute et le secteur de normalisation des télécommunications de l'Union internationale des télécommunications (ANSI/ITU-T) est de 16 à 992. Ces DLCI transportent les données des utilisateurs.
Mise à jour de l'état LMI : Le protocole LMI exige que tous les rapports d’état du circuit virtuel permanent (PVC) entrent dans un seul paquet et limite généralement le nombre de DLCI à moins de 800, selon la taille de l’unité de transmission maximale (MTU). Ceci donne les résultats suivants pour une MTU d'interface configurée de 4000 octets :
Remarque : La MTU par défaut sur les interfaces série est de 1 500 octets, ce qui donne un maximum de 296 DLCI par interface.
Réplication de diffusion : Lorsque le routeur envoie, il doit répliquer le paquet sur chaque DLCI, ce qui entraîne une congestion sur la liaison d’accès. La file d'attente de diffusion réduit ce problème. En général, le réseau doit être conçu pour maintenir la charge de mise à jour de routage en dessous de 20 % de la vitesse de la ligne d'accès. Il est également important de tenir compte des besoins en mémoire de la file d'attente de diffusion. Une bonne technique pour réduire cette restriction consiste à utiliser la route par défaut ou à étendre les temporisateurs de mise à jour.
Trafic de données utilisateur : Le nombre de DLCI dépend du trafic sur chaque DLCI et des exigences de performances. En général, les accès Frame Relay doivent fonctionner à des charges inférieures aux liaisons de routeur à routeur, car les capacités de hiérarchisation ne sont généralement pas aussi fortes. En général, le coût marginal d'augmentation de la vitesse de liaison d'accès est inférieur à celui des lignes dédiées.
Pour obtenir des estimations sur le nombre pratique d'identificateurs DLCI pris en charge sur les plates-formes de routeurs Cisco, reportez-vous à la section Limitations DLCI du Guide complet de configuration et de dépannage de Frame Relay.
Q. Puis-je utiliser IP non numéroté avec Frame Relay ?
A. Si vous ne disposez pas de l’espace d’adressage IP suffisant pour utiliser de nombreuses sous-interfaces, vous pouvez toujours utiliser l’adresse IP non numérotée sur chaque sous-interface. Vous devez utiliser des routes statiques ou du routage dynamique pour acheminer votre trafic. Et vous devez utiliser des sous-interfaces point à point. Pour plus d'informations, référez-vous à la section IP non numérotée sur une sous-interface point à point Exemple de configuration de Frame Relay.
Q. Puis-je configurer un routeur Cisco pour qu’il agisse en tant que commutateur Frame Relay ?
A. Oui. Vous pouvez configurer les routeurs Cisco pour qu'ils fonctionnent comme des équipements de communication de données Frame Relay (DCE) ou des périphériques d'interface réseau à réseau (NNI) (commutateurs Frame Relay). Un routeur peut également être configuré pour prendre en charge les équipements de terminal de données hybrides/équipements de communication de données/commutation de circuit virtuel permanent (ETTD/DCE/PVC). . Pour plus d'informations, référez-vous à la section Configuration de Frame Relay du Guide de configuration de réseau étendu Cisco IOS, version 12.1.
Q. Puis-je ponter le trafic sur une liaison Frame Relay ?
A. Oui. Sur les interfaces multipoints, les instructions de mappage Frame Relay doivent être configurées à l'aide de la commande frame-relay map bridge pour identifier les circuits virtuels permanents (PVC) pour le trafic ponté. Les unités BPDU (Bridge Protocol) Spanning(remove hyphen)Tree Protocol (STP) sont transmises à intervalles réguliers, selon le protocole de pontage configuré.
Q. Une configuration spéciale est-elle nécessaire pour connecter des routeurs Cisco à d’autres périphériques fournisseurs via Frame Relay ?
A. Par défaut, les routeurs Cisco utilisent l’encapsulation Frame Relay propriétaire. Le format d'encapsulation IETF (Internet Engineering Task Force) doit être spécifié pour interagir avec d'autres périphériques fournisseurs. L'encapsulation IETF peut être spécifiée sur une interface ou par identificateur de connexion de liaison de données (DLCI). Pour plus d'informations, reportez-vous à la section Exemples de configuration Frame Relay de Configuration de Frame Relay, dans le Guide de configuration de réseau étendu Cisco IOS, version 12.1.
Q. Qu’est-ce que l’installation automatique Frame Relay et comment fonctionne-t-elle ? Une configuration supplémentaire est-elle requise ?
A. AutoInstall vous permet de configurer un nouveau routeur automatiquement et dynamiquement. La procédure d'installation automatique consiste à connecter un nouveau routeur à un réseau dans lequel un routeur existant est préconfiguré, à activer le nouveau routeur et à l'activer avec un fichier de configuration téléchargé à partir d'un serveur TFTP. Pour plus d'informations, reportez-vous à Utilisation des outils de configuration.
Pour prendre en charge l'installation automatique sur une liaison sur laquelle le routeur existant est configuré avec une sous-interface point à point, la commande frame-relay interface-dlci nécessite des ajouts. Les informations supplémentaires fournies avec la commande frame-relay interface-dlci sont utilisées pour répondre à la requête BOOTP (Bootstrap Protocol) du routeur distant. L’ajout de protocole ipip-address à la commande indique l’adresse IP de l’interface principale d’un nouveau routeur ou serveur d’accès sur lequel un fichier de configuration de routeur doit être installé sur un réseau Frame Relay. Utilisez cette option uniquement lorsque le périphérique agit en tant que serveur BOOTP pour une installation automatique sur Frame Relay.
Pour prendre en charge l'installation automatique sur une liaison sur laquelle le routeur existant est configuré avec une interface multipoint (sub), la commande frame-relay map doit être configurée sur le routeur existant, en mappant l'adresse IP du nouveau routeur à l'identificateur de connexion de liaison de données local (DLCI) utilisé pour la connexion au nouveau routeur.
En outre, l’interface Frame Relay (sous-interface) du routeur existant doit être configurée avec la commande ip helper-address pointant vers l’adresse IP du serveur TFTP.
Q. Est le protocole IARP (Inverse Address Resolution Protocol) de relais de trames activé par défaut ? La commande inverse-arp ne s'affiche pas dans la configuration.
A. Oui.
Q. Le protocole IARP (Inverse Address Resolution Protocol) Frame Relay peut-il fonctionner sans interface de gestion locale (LMI) ?
A. Non. Il utilise LMI pour déterminer les circuits virtuels permanents (PVC) à mapper.
Q. Dans quelles conditions LMI (Local Management Interface) un routeur Cisco n’envoie-t-il pas de paquets via l’identificateur de connexion de liaison de données (DLCI) ?
A. Lorsque le circuit virtuel permanent (PVC) est répertorié comme inactif ou supprimé.
Q. Un routeur Cisco traitera-t-il et mappera-t-il un protocole IARP (Inverse Address Resolution Protocol) s'il est détecté alors qu'un identificateur de connexion de liaison de données (DLCI) est arrêté ?
A. Oui, mais le routeur ne l’utilisera pas tant que le DLCI n’est pas actif.
Q. Lors de la mise en oeuvre d'une commande show frame map, les identificateurs de connexion de liaison de données (DLCI) sont définis et actifs. Cela peut se produire lorsque les DLCI ne fonctionnent pas. Qu'est-ce que définir et signifier actif ?
A. Le message défini et actif vous indique que le DLCI peut transporter des données et que le routeur à l'extrémité distante est actif.
Q. Puis-je changer les sous-interfaces de point à point en multipoint ou inversement ?
A. Non, après la création d'un type spécifique de sous-interface, il ne peut pas être modifié sans rechargement. Par exemple, vous ne pouvez pas créer une sous-interface multipoint Serial0.2 et la remplacer par point à point. Pour le modifier, supprimez la sous-interface existante et rechargez le routeur ou créez une autre sous-interface. Lorsqu'une sous-interface est configurée, un bloc de descripteurs d'interface (IDB) est défini par le logiciel Cisco IOS®. Les BID définis pour les sous-interfaces ne peuvent pas être modifiés sans rechargement. Les sous-interfaces qui sont supprimées avec la commande no interface sont affichées comme supprimées en exécutant la commande show ip interface brief.
Q. Que signifie le type de ligne série xxx illégal ?
A. Ce message s’affiche si l’encapsulation de l’interface est Frame Relay (ou High-Level Data Link Control [HDLC]) et que le routeur tente d’envoyer un paquet contenant un type de paquet inconnu.
Performances
Q. Que sont les paquets FECN (Forward Explicit Congestion Notification) et BECN (Backward Explicit Congestion Notification) ? Comment affectent-ils les performances ?
A. Cette notification d’encombrement est effectuée en modifiant un bit dans le champ d’adresse d’une trame lorsqu’elle traverse le réseau Frame Relay. Les périphériques DCE réseau (commutateurs) remplacent la valeur du bit FECN par une valeur sur les paquets circulant dans la même direction que le flux de données. Ceci avertit un périphérique d’interface (ETTD) que les procédures d’évitement de congestion doivent être initiées par le périphérique récepteur. Les bits BECN sont définis dans des trames qui parcourent la direction opposée du flux de données pour informer le périphérique ETTD émetteur de la congestion du réseau.
Les périphériques ETTD Frame Relay peuvent choisir d’ignorer les informations FECN et BECN ou de modifier leurs débits de trafic en fonction des paquets FECN et BECN reçus. La commande frame-relay adaptive-formatage est utilisée lorsque le formatage du trafic Frame Relay est configuré pour permettre au routeur de réagir aux paquets BECN. Pour plus d'informations sur la façon dont le routeur ajuste les débits de trafic en réponse aux BECN, référez-vous à Formatage du trafic.
Q. Comment améliorer les performances sur une liaison Frame Relay lente ?
A. Les performances médiocres sur une liaison Frame Relay sont généralement causées par une congestion sur le réseau Frame Relay et par des paquets rejetés lors du transit. De nombreux fournisseurs de services ne fournissent que le meilleur effort sur le trafic qui dépasse le débit garanti. Cela signifie que lorsque le réseau devient encombré, il rejette le trafic sur le débit garanti. Cette action peut entraîner des performances médiocres.
Le formatage du trafic Frame Relay permet de modeler le trafic sur la bande passante disponible. Le formatage du trafic est fréquemment utilisé pour éviter la dégradation des performances causée par la perte de paquets de congestion. Pour obtenir une description des exemples de formatage et de configuration du trafic Frame Relay, reportez-vous à Frame Relay Traffic Shaping ou à la section Frame Relay Traffic Shaping du Guide complet de configuration et de dépannage de Frame Relay.
Pour améliorer les performances, reportez-vous aux sections Configuration de la compression de charge utile ou Configuration de la compression d'en-tête TCP/IP du Guide complet de configuration et de dépannage de Frame Relay.
Q. Qu'est-ce que l'interface ELMI (Enhanced Local Management Interface) et comment est-elle utilisée pour le formatage dynamique du trafic ?
A. ELMI permet un échange automatisé des informations de paramètres de qualité de service (QoS) Frame Relay entre le routeur Cisco et le commutateur Cisco. Les routeurs peuvent baser la gestion de la congestion et les décisions de hiérarchisation sur des valeurs QoS connues telles que le débit de données garanti (CIR), le débit garanti en rafale (Bc) et le débit garanti en rafale (Be). Le routeur lit les valeurs QoS du commutateur et peut être configuré pour utiliser ces valeurs dans le formatage du trafic. Cette amélioration fonctionne entre les routeurs Cisco et les commutateurs Cisco (plates-formes BPX/MGX et IGX). Activez la prise en charge ELMI sur le routeur en exécutant la commande frame-relay qos-autosense. Pour obtenir des informations et des exemples de configuration, reportez-vous à la section Activation de l'interface de gestion locale améliorée de Configuration de la mise en forme du trafic Frame Relay et Frame Relay.
Q. Puis-je réserver de la bande passante pour certaines applications ?
A. Une fonctionnalité Cisco récemment développée appelée CBWFQ (Class-Based Weighted Fair Queuing) permet de réserver de la bande passante pour différentes applications de flux selon la liste de contrôle d'accès (ACL) ou les interfaces entrantes. Pour plus d'informations sur la configuration, reportez-vous à Configuration de la mise en file d'attente pondérée équitable.
Q. Puis-je utiliser la mise en file d’attente prioritaire avec la compression d’en-tête TCP (Transmission Control Protocol) sur Frame Relay ?
A. Pour que l'algorithme de compression d'en-tête TCP fonctionne, les paquets doivent arriver dans l'ordre. Si les paquets arrivent dans le désordre, la reconstruction semble créer des paquets TCP/IP ordinaires, mais les paquets ne correspondent pas à l'original. Comme la mise en file d’attente par priorité modifie l’ordre dans lequel les paquets sont transmis, il n’est pas recommandé d’activer la mise en file d’attente par priorité sur l’interface.
Q. Frame Relay peut-il hiérarchiser le trafic vocal transporté dans des paquets IP sur des paquets non vocaux ?
A. Oui. La fonctionnalité Frame Relay IP RTP Priority fournit un schéma de mise en file d'attente de priorité stricte sur un circuit virtuel privé (PVC) Frame Relay pour les données sensibles au délai, telles que la voix, qui est identifié par ses numéros de port RTP (Real-Time Transport Protocol). Cette fonctionnalité garantit que le trafic vocal est prioritaire sur les autres trafics non vocaux.
Q. Qu’est-ce que la mise en file d’attente par priorité d’interface PIPQ (Private Virtual Circuit) Frame Relay ?
A. La fonction PIPQ (Frame Relay PVC Interface Priority Queueing) fournit une hiérarchisation au niveau de l'interface en donnant la priorité à un circuit virtuel permanent sur un autre circuit virtuel permanent sur la même interface. Cette fonctionnalité peut également être utilisée pour hiérarchiser le trafic voix sur le trafic non voix lorsqu'il est transporté sur des circuits virtuels permanents distincts sur la même interface.
Routage
Q. Comment le découpage d’horizon IP est-il géré sur les interfaces Frame Relay ?
A. La vérification de l’horizon partagé IP est désactivée par défaut pour l’encapsulation Frame Relay afin de permettre aux mises à jour de routage d’entrer et de sortir de la même interface. Une exception est le protocole EIGRP (Enhanced Interior Gateway Routing Protocol) pour lequel le découpage d'horizon doit être explicitement désactivé.
Certains protocoles tels qu’AppleTalk, le pontage transparent et IPX (Internetwork Packet Exchange) ne peuvent pas être pris en charge sur les réseaux à maillage partiel car ils nécessitent l’activation du découpage d’horizon (un paquet reçu sur une interface ne peut pas être transmis sur la même interface, même si le paquet est reçu et transmis sur différents circuits virtuels).
La configuration des sous-interfaces de relayage de trames garantit qu’une seule interface physique est traitée comme plusieurs interfaces virtuelles. Cette fonctionnalité vous permet de surmonter les règles de découpage d'horizon afin que les paquets reçus sur une interface virtuelle puissent être transférés vers une autre interface virtuelle, même s'ils sont configurés sur la même interface physique.
Q. Le protocole OSPF (Open Shortest Path First) nécessite-t-il une configuration supplémentaire pour s’exécuter sur Frame Relay ?
A. Par défaut, OSPF traite les interfaces Frame Relay multipoints comme NON_BROADCAST. Cela nécessite que les voisins soient explicitement configurés. Il existe différentes méthodes pour gérer OSPF sur Frame Relay. Celle qui est mise en oeuvre dépend de la maillage complet du réseau. Pour plus d'informations, référez-vous aux documents suivants :
Q. Comment calculer la bande passante consommée par les mises à jour de routage sur Frame Relay ?
A. Des estimations fiables peuvent uniquement être calculées pour les protocoles à vecteur de distance qui envoient des mises à jour périodiques. Cela inclut les protocoles RIP (Routing Information Protocol) et IGRP (Interior Gateway Routing Protocol) pour IP, RIP pour IPX (Internetwork Packet Exchange) et RTMP (Routing Table Maintenance Protocol) pour AppleTalk. Une discussion sur la bande passante consommée par ces protocoles sur Frame Relay se trouve dans la section RIP et IGRP de Configuration et dépannage de Frame Relay.
Protocole de gestion de réseau simple (SNMP)
Q. Je peux envoyer une requête ping SNMP (Simple Network Management Protocol) au routeur pour lui demander d'envoyer une requête ping à tous les partenaires DLCI (Data-Link Connection Identifier), ce qui a abouti. Qu'est-ce que cela indique?
A. Ceci confirme que le protocole est configuré et que le mappage protocole-DLCI est correct aux deux extrémités.
Q. Des variables SNMP (Simple Network Management Protocol) sont-elles disponibles pour fournir un état précis sur les identificateurs de connexion de liaison de données (DLCI) ?
A. Oui. Les variables sont trouvées dans RFC1315
et dans la base d'informations de gestion Frame Relay Data Terminal Ready (DTR).
La variable SNMP pour l'état d'un circuit est pour CircuitState. Sa forme OID (Abstract Syntax Notation One) (ASN.1) est 1.3.6.1.2.1.10.32.2.1.3. Il se trouve dans le frCircuitTable. Pour obtenir la valeur (l'état dans ce cas), l'index et le DLCI sont respectivement les première et deuxième instances. En exécutant les commandes SNMP Get ou Getnext, vous pouvez connaître l'état du circuit interne du système. Le tableau suivant répertorie les valeurs valides :
Valeur Province 1 non valide 2 actif 3 inactif Pour Cisco, vous verriez 2 ou 3.