Modo de transferencia asíncrona (ATM) : ATM a interacción de Frame Relay

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

8 Abril 2009 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (15 Noviembre 2007) | Comentarios

Contenidos

Introducción
Prerrequisitos
      Requisitos
      Componentes Utilizados
      Convenciones
Comprensión de los Encabezados de Capa 2
Cómo Comprender Frame Relay IETF y la Encapsulación Cisco
      Encapsulación IETF
      Encapsulación Cisco
Definición de los Modos Traducción y Transparente
Configuración
      Diagrama de Red
      Configuraciones
Comandos debug
Ilustración del Modo Traducción
Ilustración del Modo Transparente
Discusiones relacionadas de la comunidad de soporte de Cisco

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:

  • Router extremo con una interfaz serial configurada para la encapsulación Frame Relay.

  • Extremo 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.

traff_shape_fr2.gif

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 extremo 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.

Prerrequisitos

Requisitos

No existen requisitos específicos para este documento.

Componentes Utilizados

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

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Comprensión de los 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: Indica el protocolo encapsulado y transportado en la trama o celda. Definido por la Solicitud de Comentarios (Request for Comments - 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 enlace de datos [Data-link connection identifier - DLCI] o identificador de trayecto virtual/identificador de canal virtual [virtual path identifier/virtual channel identifier - VPI/VCI]) además de la prioridad de pérdida y los valores de indicación de congestión. Definido por Q.922 (en general dos bytes) para Frame Relay y por un encabezado de celda de cinco bytes 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.

frf8modes1.gif

Cómo Comprender Frame Relay IETF y la Encapsulación Cisco

Antes de conocer algunos comandos debug para ilustrar los modos FRF.8 primero debemos comprender la encapsulación Frame Relay. Las interfaces del router Cisco soportan dos encapsulaciones de protocolo, Cisco y el Grupo de Trabajo en Ingeniería de Internet (Internet Engineering Task Force - 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. Observemos esto con mayor profundidad.

Encapsulación IETF

Los RFCs 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:

Valor

Descripción

0x00

Capa de red nula o conjunto inactivo (no se utiliza con Frame Relay)

0x80

Protocolo de Acceso de Subred (SNAP)

0x81

ISO CLNP

0x82

Sistema Final a Sistema Intermedio ISO (ES-IS)

0x83

Sistema Intermedio a Sistema Intermedio ISO (IS-IS)

0xCC

IP Internet

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

frf8modes2.gif

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.

frf8modes3.gif

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 Cisco usa un campo de control de dos bytes con los valores EtherType para identificar el protocolo de capa 3. La encapsulación Cisco para IP usa el EtherType de dos bytes de 0x0800, seguido de un datagrama IP.

frf8modes4.gif

Definición de los Modos Traducción y Transparente

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 reensamblado.

  • 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.

Configure

Diagrama de Red

Esta sección utiliza la siguiente configuración de red:

frf8modes5.gif

Configuraciones

Esta sección usa estas configuraciones:

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

7206B

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
 sin 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

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

Comandos debug

El dispositivo de interconexión ejecuta su modo de interrupción de función y, por lo tanto, no podemos capturar el output debug atm packet ya que estos debugs funcionan sólo con el nivel de proceso por paquete. 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 una decodificación a nivel del paquete en el extremo frame-relay.

  • debug frame-relay packet int serial 4/0: captura una decodificación a nivel del paquete en el extremo ATM.

  • debug atm error: captura los errores o las discordancias de encapsulación.

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 extremo Frame Relay al extremo ATM con la siguiente configuración:

  • Configure el extremo Frame relay con la encapsulación IETF.

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

  • Configure el extremo 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 exitosos. Observemos los encabezados del paquete en cada extremo.

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 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 Type: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 (protocol data units - PDUs) 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 el IWF 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 extremo 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 (destination service-access-point - DSAP) y punto de acceso al servicio de origen (source service access point - 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 extremos usan la misma encapsulación, por lo que los pings son exitosos.

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

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 10442