Présentation des modes transparent et de traduction avec FRF.8

Introduction

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.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Présentation des en-têtes de couche 2

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.

Présentation de Frame Relay IETF et de l’encapsulation Cisco

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.

Encapsulation IETF

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 :

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.

Encapsulation Cisco

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.

Mode de traduction et de transparence défini

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.

Configuration

Diagramme du réseau

Cette section utilise cette configuration du réseau :

Configurations

Cette section utilise ces configurations :

• 3620-1

• 7 206 B

• 7500-A

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

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

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.

Commandes de débogage

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.

Mode de traduction illustré

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.

Mode transparent illustré

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

Informations connexes

• Interopérabilité des services Frame Relay-ATM
• Prise en charge de la technologie d’interconnexion ATM-Frame Relay
• Configuration du formatage du trafic sur des circuits virtuels permanents (FRF.8) avec interopérabilité de services Frame Relay à ATM
• Support technologique ATM
• Support et documentation techniques - Cisco Systems