Le Forum Frame Relay (FRF) publie des accords ou des normes de mise en oeuvre pour les réseaux Frame Relay afin de promouvoir l’interopérabilité. FRF.8 spécifie l’interconnexion de services Frame Relay à ATM. Notre topologie réseau utilise trois composants :
Point d’extrémité du routeur avec une interface série configurée pour l’encapsulation Frame Relay.
terminal ATM.
Commutateur réseau ou routeur Cisco qui met en oeuvre la fonction d'interconnexion (IWF) pour permettre aux deux points d'extrémité de communiquer.
La section 5 de l’accord FRF.8 traite de deux modes d’encapsulation de protocole de couche supérieure. Cette encapsulation fait référence à l’en-tête qui identifie le protocole transporté dans l’unité de données de protocole (PDU), permettant au récepteur de traiter correctement le paquet entrant. FRF.8 définit deux modes : la traduction et la transparence. La sélection de l’un de ces modes au niveau de la fonction d’interconnexion détermine l’encapsulation à configurer sur notre terminal ATM.
Ce document illustre les différences au niveau des paquets entre le mode transparent et le mode de traduction pour aider à résoudre les problèmes de connectivité de bout en bout avec les implémentations FRF.8.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Frame Relay et ATM sont des protocoles de couche 2 pour les interfaces réseau. Les deux protocoles utilisent deux en-têtes différents au niveau de la couche 2 :
En-tête d’encapsulation de protocole de couche supérieure : communique le protocole encapsulé et transporté dans la trame ou la cellule. Défini par les normes RFC 1490 et FRF 3.2 pour Frame Relay et RFC 1483 et 2684 pour ATM.
En-tête d'adresse : communique l'adresse de couche 2 (identificateur de connexion de liaison de données [DLCI] ou identificateur de chemin virtuel/identificateur de canal virtuel [VPI/VCI]), ainsi que les valeurs de priorité de perte et d'indication de congestion. Défini par Q.922 (généralement deux octets) pour Frame Relay et par un en-tête de cellule de cinq octets pour ATM.
Remarque : la traduction FRF.8 et les modes transparents concernent l'en-tête d'encapsulation.
Le schéma suivant illustre un exemple de paquet Frame Relay avec l'en-tête d'adresse Q.922 et les champs d'identification de protocole de couche réseau et de contrôle (NLPID) de l'en-tête d'encapsulation de protocole de couche supérieure.
Avant d’examiner certaines commandes de débogage pour illustrer les modes FRF.8, nous devons d’abord comprendre l’encapsulation Frame Relay. Les interfaces de routeur Cisco prennent en charge deux encapsulations de protocole, Cisco et l'IETF (Internet Engineering Task Force), que vous pouvez sélectionner à l'aide de la commande encapsulation frame-relay [ietf]. Ces encapsulations comprennent deux formats IETF et un format Cisco. Regardons ça plus en détail.
Les RFC 1490 et 2427 définissent l’encapsulation IETF pour Frame Relay. Ils indiquent comment utiliser une valeur NLPID. Le document ISO/Commission électrotechnique internationale (CEI) TR 9577 définit les valeurs NLPID pour un certain nombre de protocoles, notamment :
Valeur | Description |
---|---|
0x00 | Couche réseau nulle ou ensemble inactif (non utilisé avec Frame Relay) |
0x80 | SNAP (Subnetwork Access Protocol) |
0x81 | CLNP ISO |
0x82 | Système de bout en bout ISO à système intermédiaire (ES-IS) |
0x83 | ISO IS-IS (Intermediate System-to-Intermediate System) |
0xCC | IP Internet |
Les protocoles dont la valeur NLPID est définie utilisent un en-tête court, comme indiqué ci-dessous.
Les protocoles sans valeur NLPID définie utilisent un en-tête SNAP et l'indique avec une valeur NLPID de 0x80, comme indiqué ci-dessous.
Le routeur choisit automatiquement le formulaire IETF à utiliser selon la règle suivante : S'il existe une valeur NLPID pour le protocole, utilisez la forme abrégée. Sinon, utilisez le formulaire long.
L’encapsulation Cisco utilise un champ de contrôle à deux octets avec des valeurs EtherType pour identifier le protocole de couche 3. L’encapsulation Cisco pour IP utilise l’EtherType à deux octets de 0x0800, suivi du datagramme IP.
L'accord de mise en oeuvre FRF.8 utilise le libellé suivant pour décrire les modes de traduction et de transparence.
Mode transparent (Mode 1) : lorsque les méthodes d’encapsulation ne sont pas conformes aux normes citées dans le Mode 2 mais qu’elles sont compatibles entre les équipements de terminal, la fonction d’interconnexion (IWF) transmet les encapsulations sans modification. Il n'effectue aucun mappage, fragmentation ou réassemblage.
Mode de traduction (Mode 2) - Méthodes d’encapsulation pour le transport de plusieurs protocoles utilisateur de couche supérieure (par exemple, LAN à LAN) sur un circuit virtuel permanent Frame Relay et un circuit virtuel permanent ATM conformes aux normes FRF 3.2 et RFC 2684, respectivement. L’IWF effectue le mappage entre les deux encapsulations en raison des incompatibilités des deux méthodes. Le mode de traduction prend en charge l’interconnexion de protocoles d’interconnexion de réseaux (routés et/ou pontés).
Maintenant, émettons les commandes show et debug du logiciel Cisco IOS® pour comprendre comment nous appliquons ces modes à une implémentation réelle de FRF.8 sur les routeurs Cisco.
Cette section utilise cette configuration du réseau :
Cette section utilise ces configurations :
3620-1 |
---|
interface Serial1/0 ip address 10.10.10.1 255.255.255.0 encapsulation frame-relay IETF frame-relay map ip 10.10.10.2 25 frame-relay interface-dlci 25 frame-relay lmi-type ansi |
7 206 B |
---|
frame-relay switching ! interface Serial4/3 no ip address encapsulation frame-relay IETF frame-relay interface-dlci 50 switched frame-relay lmi-type ansi frame-relay intf-type dce ! interface ATM5/0 no ip address atm clock INTERNAL no atm ilmi-keepalive pvc 5/50 vbr-nrt 100 75 oam-pvc manage encapsulation aal5mux fr-atm-srv ! connect SIVA Serial4/3 50 ATM5/0 5/50 service-interworking |
7500-A |
---|
interface atm 4/0/0.50 multi ip address 10.10.10.2 255.255.255.0 pvc 5/50 vbr-nrt 100 75 30 protocol ip 10.10.10.1 |
Remarque : Pour illustrer les deux modes, nous effectuons deux modifications de configuration en émettant les commandes encapsulation aal5nlpid sur le point de terminaison ATM et aucune traduction de service sur le routeur IWF.
Le périphérique d'interfonctionnement exécute son mode d'interruption de fonction et donc nous ne pouvons pas capturer la sortie de paquet debug atm, car ces débogages fonctionnent uniquement avec le paquet de niveau processus. Nous devons exécuter des débogages aux deux extrémités pour capturer le format des paquets.
Remarque : avant d'émettre des commandes debug, reportez-vous à Informations importantes sur les commandes de débogage.
debug frame-relay packet int serial 1/0 - Capture un décodage de niveau paquet sur le point de terminaison frame-relay.
debug atm packet int atm 4/0/0.50 - Capture un décodage de niveau paquet sur le point d'extrémité ATM.
debug atm error - Capture les erreurs d'encapsulation ou les incohérences.
Lorsque nous utilisons la commande connect pour relier les circuits virtuels permanents ATM et Frame Relay, le routeur IWF utilise automatiquement le mode de traduction. Utilisez la commande show connect name pour confirmer cela.
Nous pouvons lancer une requête ping du point d’extrémité Frame Relay au point d’extrémité ATM en utilisant la configuration suivante :
Configurez le point de terminaison Frame Relay avec l’encapsulation IETF.
Configurez le routeur IWF pour le mode de traduction.
Configurez le point de terminaison ATM avec l’encapsulation AAL5SNAP.
3620-1.9# ping 10.10.10.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Nos requêtes ping aboutissent. Examinons les en-têtes de paquet sur chaque point d'extrémité.
debug frame-relay packet sur Frame Relay Endpoint
3620-1.9# *Apr 4 11:13:20.978: Serial1/0(o): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.014: Serial1/0(i): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.014: Serial1/0(o): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.050: Serial1/0(i): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.050: Serial1/0(o): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.086: Serial1/0(i): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.090: Serial1/0(o): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.122: Serial1/0(i): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.126: Serial1/0(o): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104 *Apr 4 11:13:21.162: Serial1/0(i): dlci 50(0xC21), NLPID 0x3CC(IP), datagramsize 104
Revenons à notre discussion sur l’encapsulation IETF. Nous voyons que le paquet ping utilise l’en-tête d’encapsulation de forme courte puisque le protocole IP se voit attribuer la valeur NLPID de 0xCC.
debug atm packet sur ATM Endpoint
7500-1.5# 1w3d: ATM4/0/0.50(I): VCD:0xD VPI:0x5 VCI:0x32 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70 1w3d: 4500 0064 004B 0000 FE01 9437 0A0A 0A01 0A0A 0A02 0800 0C14 08FE 246F 0000 1w3d: 0000 B1E8 92E0 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD 1w3d: 1w3d: ATM4/0/0.50(O): VCD:0xD VPI:0x5 VCI:0x32 DM:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70 1w3d: 4500 0064 004B 0000 FF01 9337 0A0A 0A02 0A0A 0A01 0000 1414 08FE 246F 0000 1w3d: 0000 B1E8 92E0 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD
Pour les unités de données de protocole routées (PDU), l'encapsulation AAL5SNAP utilise une valeur OUI de 0x000000 et une valeur Ethertype (telle que 0x0800 pour IP) pour le champ de type. Référez-vous à Protocoles routés multiples sur des circuits virtuels permanents ATM utilisant l'encapsulation LLC pour plus d'informations.
Nos débogages illustrent la façon dont IWF traduit entre l’en-tête NLPID Frame Relay et l’en-tête ATM AAL5SNAP.
Pour illustrer le mode transparent, changeons uniquement le mode sur le routeur IWF. Émettez la commande no service translation pour configurer explicitement le mode transparent.
7200-2.4(config)# connect SIVA 7200-2.4(config-frf8)# no service translation
Exécutez la commande show connect name pour confirmer votre modification.
7200-2.4# show connect name SIVA FR/ATM Service Interworking Connection: SIVA Status - UP Segment 1 - Serial4/3 DLCI 50 Segment 2 - ATM5/0 VPI 5 VCI 50 Interworking Parameters - no service translation efci-bit 0 de-bit map-clp clp-bit map-de
Nos requêtes ping entre les deux routeurs échouent maintenant. En utilisant debug atm packet et debug atm error, nous voyons la raison de l'échec de la requête ping : l'en-tête NLPID d'origine est transporté directement par le IWF et atteint le point de terminaison ATM, qui est configuré avec AAL5SNAP et ne comprend pas les valeurs NLPID.
7500-1.5# 1w3d: ATM4/0/0.50(I): VCD:0xD VPI:0x5 VCI:0x32 Type:0x0 SAP:03CC CTL:45 Length:0x6A 1w3d: 0000 6400 4A00 00FF 0193 380A 0A0A 010A 0A0A 0208 0058 3603 6F10 EA00 0000 1w3d: 00B1 8E60 2CAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB 1w3d: CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB 1w3d: CDAB CDAB CDAB CDAB CD43 1w3d: 1w3d: ATM(ATM4/0/0.50): VC(13) Bad SAP received 03CC
Avec l’encapsulation AAL5SNAP, l’interface ATM recherche les valeurs AA de point d’accès au service de destination (DSAP) et de point d’accès au service source (SSAP) pour indiquer que l’en-tête SNAP suit. Au lieu de cela, dans le même octet, nous recevons les valeurs de contrôle (0x03) et NLPID (0xCC pour IP) de l’en-tête Frame Relay d’origine.
Nous pouvons corriger cette condition d'erreur en remplaçant l'encapsulation ATM par AAL5NLPID. Maintenant, les deux terminaux utilisent la même encapsulation, donc nos requêtes ping aboutissent.
7500-1.5(config)# interface atm 4/0/0.50 7500-1.5(config-subif)# pvc 5/50 7500-1.5(config-if-atm-vc)# encapsulation ? aal5ciscoppp Cisco PPP over AAL5 Encapsulation aal5mux AAL5+MUX Encapsulation aal5nlpid AAL5+NLPID Encapsulation aal5snap AAL5+LLC/SNAP Encapsulation 1w3d: %SYS-5-CONFIG_I: Configured from console by console 7500-1.5# show debug Generic ATM: ATM packets debugging is on ATM errors debugging is on 7500-1.5# 1w3d: ATM4/0/0.50(I): VCD:0xD VPI:0x5 VCI:0x32 Type:0x2 NLPID:0x03CC Length:0x6A 1w3d: 4500 0064 0054 0000 FE01 942E 0A0A 0A01 0A0A 0A02 0800 F9A6 1C05 2248 0000 1w3d: 0000 B1F5 9460 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD 1w3d: 1w3d: ATM4/0/0.50(O): VCD:0xD VPI:0x5 VCI:0x32 DM:0x0 NLPID:0x03CC Length:0x6A 1w3d: 4500 0064 0054 0000 FF01 932E 0A0A 0A02 0A0A 0A01 0000 01A7 1C05 2248 0000 1w3d: 0000 B1F5 9460 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1w3d: ABCD ABCD ABCD ABCD ABCD