Comprensión del Modo Traducción y el Modo Transparente con FRF.8

Introducción

El Foro de Frame Relay (FRF) publica acuerdos o normas de implementación para las redes Frame Relay con el fin de promover la interoperatividad. FRF.8 especifica la interconexión de servicio de Frame Relay a ATM. Nuestra topología de red usa tres componentes:

• Punto final del router con una interfaz serial configurada para la encapsulación de Frame Relay.

• Punto final ATM.

• Switch de red o router Cisco que implementa la función de interconexión (IWF) para permitir la comunicación entre los dos puntos finales.

La sección 5 del acuerdo FRF.8 analiza dos modos de encapsulación de protocolo de capa superior. Esta encapsulación hace referencia al encabezado que identifica el protocolo transportado en la unidad de datos de protocolo (PDU), lo que le permite al receptor procesar correctamente el paquete entrante. FRF.8 define dos modos: traducción y transparente. La selección de uno de estos modos en la función de interconexión determina la encapsulación que se necesita para configurar el punto final ATM.

Este documento ilustra las diferencias en el nivel del paquete entre el modo traducción y transparente para ayudarlo a resolver problemas relacionados con la conectividad de extremo a extremo con implementaciones FRF.8.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

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

Información sobre encabezados de capa 2

Frame Relay y ATM son protocolos de capa 2 para las interfaces de red. Ambos protocolos usan dos encabezados distintos en la capa 2:

• Encabezado de encapsulación de protocolo de capa superior: comunica el protocolo encapsulado y transportado en la trama o la celda. Definido por la Solicitud de Comentarios (RFC) 1490 y FRF 3.2 para Frame Relay, y RFC 1483 y 2684 para ATM.

• Encabezado de dirección— comunica la dirección de capa 2 (Identificador de conexión de link de datos [DLCI] o identificador de trayecto virtual/identificador de canal virtual [VPI/VCI]) además de la prioridad de pérdida y los valores de indicación de congestión. Definida por Q.922 (en general dos bytes) para Frame Relay y por una celda de cinco bytes de encabezado para ATM.

Nota: Los modos traducción y transparente FRF.8 están relacionados con el encabezado de encapsulación.

El siguiente diagrama ilustra un paquete Frame Relay de muestra con el encabezado de dirección Q.922 y los campos de identificación del protocolo de capa de red (NLPID) y de control del encabezado de encapsulación del protocolo de capa superior.

Compresión de Frame Relay IETF y Encapsulación de Cisco

Antes de conocer algunos comandos debug para ilustrar los modos FRF.8 primero debemos comprender la encapsulación de Frame Relay. Las interfaces del router Cisco admiten dos encapsulaciones de protocolo, Cisco y el Grupo de Trabajo en Ingeniería de Internet (IETF), que puede seleccionar con el comando encapsulation frame-relay [ietf]. Estas encapsulaciones incluyen dos formatos IETF y un formato Cisco. Observemos esto con mayor profundidad.

Encapsulación de IETF

Las RFC 1490 y 2427 definen la encapsulación de IETF para Frame Relay. Especifican cómo se debe usar un valor NLPID. El documento de la Comisión Electrotécnica Internacional (IEC)/ISO TR 9577 define los valores NLPID para una cantidad seleccionada de protocolos, que incluyen:

Los protocolos con un valor NLPID definido usan una versión corta del encabezado, como se muestra a continuación.

Los protocolos sin un valor NLPID definido usan un encabezado SNAP y lo indican con un valor NLPID de 0x80, como se muestra a continuación.

El router selecciona automáticamente la forma de IETF que debe usar mediante la siguiente regla: Si hay un valor NLPID para el protocolo, use la versión corta. En caso contrario, la versión larga.

Encapsulación Cisco

La encapsulación de Cisco usa un campo de control de dos bytes con los valores EtherType para identificar el protocolo de capa 3. La encapsulación de Cisco para IP usa el EtherType de dos bytes de 0x0800, seguido de un datagrama IP.

Traducción y modo transparente definido

El acuerdo de implementación FRF.8 usa los siguientes términos para describir los modos traducción y transparente.

• Modo transparente (Modo 1): cuando los métodos de encapsulación no cumplen con las normas mencionadas en el Modo 2 pero son compatibles entre los equipos terminales, la función de interconexión (IWF) reenvía las encapsulaciones sin ninguna alteración. No realiza mapeo, fragmentación ni reagrupación.

• Modo traducción (Modo 2): los métodos de encapsulación para transportar varios protocolos de usuario de capa superior (por ejemplo, LAN a LAN) en un PVC Frame Relay y un PVC ATM cumplen con las normas FRF 3.2 y RFC 2684, respectivamente. La IWF realiza el mapeo entre las dos encapsulaciones debido a las incompatibilidades de los dos métodos. El Modo Traducción admite la interconexión de los protocolos de conexión entre redes (con router o puente).

Ahora ejecutemos los comandos show y debug del software Cisco IOS® para comprender de qué manera se aplican estos modos a una implementación real de FRF.8 en los routers Cisco.

Configurar

Diagrama de la red

Esta sección utiliza esta configuración de red:

Configuraciones

Esta sección usa estas configuraciones:

• 3620-1

• 7206B

• 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

Nota: Al ilustrar los dos modos, se realizan dos cambios de configuración al ejecutar los comandos encapsulation aal5nlpid en el punto final ATM y no service translation en el router IWF.

Comandos de Debug

El dispositivo de interconexión ejecuta su modo de interrupción de función y, por lo tanto, no podemos capturar la salida debug atm packet ya que estos debugs funcionan sólo con el paquete a nivel del proceso. Debemos ejecutar los debugs en los dos extremos para capturar el formato de los paquetes.

Nota: Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

• debug frame-relay packet int serial 1/0 - Captura un descódigo de nivel de paquete en el extremo de frame-relay.

• debug atm packet int atm 4/0/0.50 - Captura un descódigo de nivel de paquete en el punto final ATM.

• debug atm error - Captura errores de encapsulación o discordancias.

Ilustración del modo traducción

Cuando usamos el comando connect para vincular los PVC de ATM y Frame Relay, el router IWF usa automáticamente el modo traducción. Use el comando show connect name para confirmar esto.

Podemos iniciar un ping desde el punto final de Frame Relay al punto final ATM con la siguiente configuración:

• Configure el punto final de Frame relay con la encapsulación de IETF.

• Configure el router IWF para el modo traducción.

• Configure el punto final ATM con la encapsulación 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

Los ping son correctos. Observemos los encabezados del paquete en cada punto final.

debug frame-relay packet en el Punto Final de Frame Relay

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

Si volvemos al tema de la encapsulación de IETF, podemos observar que el paquete ping usa la versión corta del encabezado de encapsulación ya que al protocolo IP se le asigna un valor NLPID de 0xCC.

debug atm packet en el Punto Final ATM

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

Para las unidades de datos de protocolo (PDU) ruteadas, la encapsulación AAL5SNAP usa un valor OUI de 0x000000 y un valor Ethertype (como 0x0800 para IP) para el campo tipo. Consulte Protocolos Múltiples Ruteados en PVC ATM con Encapsulación LLC para obtener más información.

Los debugs ilustran cómo la IWF se traduce entre el encabezado Frame Relay NLPID y el encabezado AAL5SNAP ATM.

Ilustración del modo transparente

Para ilustrar el modo transparente, cambiemos solamente el modo en el router IWF. Ejecute el comando no service translation para configurar de forma explícita el modo transparente.

7200-2.4(config)# connect SIVA 
7200-2.4(config-frf8)# no service translation

Ejecute el comando show connect name para confirmar el cambio.

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

Los pings entre los dos routers fallaron. Con debug atm packet y debug atm error, podemos ver el motivo del fallo del ping; el encabezado NLPID original se transporta a través de la IWF y alcanza el punto final ATM, que es configurado con AAL5SNAP y no comprende los valores 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

Con la encapsulación AAL5SNAP, la interfaz ATM busca los valores de punto de acceso al servicio de destino (DSAP) y punto de acceso al servicio de origen (SSAP) de AA para indicar que el encabezado SNAP es el siguiente. En su lugar, en la misma ubicación del byte, recibimos los valores control (0x03) y NLPID (0xCC para IP) del encabezado original de Frame Relay.

Podemos corregir esta condición de error mediante un cambio de la encapsulación ATM a AAL5NLPID. Ahora, ambos puntos finales usan la misma encapsulación, por lo que los pings son correctos.

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

Información Relacionada

• Interconexión de servicio de Frame Relay a ATM
• Soporte de Tecnología de Interconexión ATM a Frame Relay
• Configuración del modelado del tráfico en Frame Relay para la interconexión del servicio ATM (FRF.8) de PVC
• Soporte de Tecnología ATM
• Soporte Técnico y Documentación - Cisco Systems