Entendendo os modos transparente e de tradução com FRF.8

Introduction

O Frame Relay Forum (FRF) publica contratos ou padrões de implementação para redes Frame Relay para promover a interoperabilidade. O FRF.8 especifica o entrelaçamento de serviço do Frame Relay com ATM. Nossa topologia de rede usa três componentes:

• Ponto de extremidade do roteador com uma interface serial configurada para o encapsulamento do Frame Relay.

• Ponto final de ATM.

• Switch de rede ou roteador Cisco que implementa a função de interfuncionamento (IWF) para permitir que os dois endpoints se comuniquem.

A seção 5 do contrato FRF.8 discute dois modos do encapsulamento do protocolo da camada superior. Esse encapsulamento se refere ao cabeçalho que identifica o protocolo transportado na unidade de dados do protocolo (PDU), permitindo que o receptor processe corretamente o pacote recebido. O FRF.8 define dois modos - tradução e transparente. A seleção de um desses modos na função de interfuncionamento determina o encapsulamento que precisamos configurar em nosso endpoint ATM.

Este documento ilustra as diferenças de nível de pacote entre os modos transparente e de tradução para ajudar na solução de problemas de conectividade fim-a-fim com implementações FRF.8.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

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

Entendendo os cabeçalhos da Camada 2

Frame Relay e ATM são protocolos de camada 2 para interfaces de rede. Ambos os protocolos usam dois cabeçalhos diferentes na camada 2:

• Cabeçalho de encapsulamento do protocolo de camada superior —Comunica o protocolo encapsulado e transportado no quadro ou célula. Definido por Request for Comments (RFC) 1490 e FRF 3.2 para Frame Relay, e RFCs 1483 e 2684 para ATM.

• Cabeçalho do endereço —Comunica o endereço da camada 2 (Data-link connection identifier [DLCI] ou virtual path identifier/virtual channel identifier [VPI/VCI]), bem como os valores de prioridade de perda e indicação de congestionamento. Definido por Q.922 (geralmente dois bytes) para Frame Relay e um cabeçalho de célula de cinco bytes para ATM.

Observação: a tradução FRF.8 e os modos transparentes dizem respeito ao cabeçalho de encapsulamento.

O diagrama a seguir ilustra um pacote Frame Relay de exemplo com o cabeçalho do endereço Q.922 e os campos de identificação do protocolo da camada de controle e rede (NLPID - Control Layer Protocol Identification) do cabeçalho de encapsulamento do protocolo da camada superior.

Entendendo o Frame Relay IETF e o encapsulamento Cisco

Antes de examinar alguns comandos debug para ilustrar os modos FRF.8, primeiro precisamos entender o encapsulamento do Frame Relay. As interfaces do roteador Cisco suportam dois encapsulamentos de protocolo, a Cisco e a Internet Engineering Task Force (IETF), que você pode selecionar com o comando encapsulation frame-relay [ietf]. Esses encapsulamentos incluem dois formatos IETF e um formato Cisco. Vejamos isso com mais detalhes.

Encapsulamento IETF

Os RFCs 1490 e 2427 definem o encapsulamento IETF para Frame Relay. Eles especificam como usar um valor NLPID. O documento ISO/International Eletrotechnical Commission (IEC) TR 9577 define valores de NLPID para um número selecionado de protocolos, incluindo:

Os protocolos com um valor NLPID definido usam um cabeçalho de forma curta, como mostrado abaixo.

Os protocolos sem um valor NLPID definido usam um cabeçalho SNAP e o indicam com um valor NLPID de 0x80, como mostrado abaixo.

O roteador escolhe automaticamente qual formulário IETF deve ser usado pela seguinte regra: Se houver um valor NLPID para o protocolo, use a forma curta. Caso contrário, use a forma longa.

Encapsulamento Cisco

O encapsulamento Cisco usa um campo de controle de dois bytes com valores EtherType para identificar o protocolo da camada 3. O encapsulamento Cisco para IP usa o EtherType de dois bytes de 0x0800, seguido pelo datagrama IP.

Modo de conversão e modo transparente definidos

O acordo de implementação FRF.8 usa a seguinte redação para descrever os modos de tradução e transparente.

• Modo Transparente (Modo 1) — Quando os métodos de encapsulamento não estão em conformidade com os padrões citados no Modo 2, mas são compatíveis entre o equipamento terminal, a função de interfuncionamento (IWF) encaminha os encapsulamentos inalterados. Ele não executa nenhum mapeamento, fragmentação ou remontagem.

• Modo de tradução (Modo 2)—Os métodos de encapsulamento para transportar vários protocolos de usuário de camada superior (por exemplo, LAN para LAN) sobre um PVC de Frame Relay e um PVC ATM estão em conformidade com o FRF 3.2 e RFC 2684 padrão, respectivamente. O IWF executa o mapeamento entre os dois encapsulamentos devido às incompatibilidades dos dois métodos. O modo de tradução suporta o entrelaçamento de protocolos de internetworking (roteados e/ou interligados).

Agora, vamos emitir os comandos show e debug do software Cisco IOS® para entender como aplicamos esses modos a uma implementação real de FRF.8 nos roteadores Cisco.

Configurar

Diagrama de Rede

Essa seção utiliza esta configuração de rede:

Configurações

Esta seção utiliza as seguintes configurações:

• 3620-1

• 7.206 bilhões

• 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

Observação: ao ilustrar os dois modos, fazemos duas alterações de configuração emitindo os comandos encapsulation aal5nlpid no ponto final ATM e nenhuma tradução de serviço no roteador IWF.

Comandos debug

O dispositivo de entrelaçamento executa seu modo de interrupção de função e, portanto, não podemos capturar a saída debug atm packet, pois essas depurações funcionam somente com pacote de nível de processo. Precisamos executar depurações nas duas extremidades para capturar o formato dos pacotes.

Observação: antes de inserir o comando debug, consulte Informações importantes sobre os comandos debug.

• debug frame-relay packet int serial 1/0 - Captura um decodificador de nível de pacote no ponto de extremidade frame-relay.

• debug atm packet int atm 4/0/0.50 - Captura um decodificador de nível de pacote no endpoint ATM.

• debug atm error - Captura erros ou incompatibilidades de encapsulamento.

Modo de conversão ilustrado

Quando usamos o comando connect para conectar os PVCs ATM e Frame Relay, o roteador IWF usa automaticamente o modo de conversão. Use o comando show connect name para confirmar isso.

Podemos iniciar um ping do ponto final do Frame Relay para o ponto final ATM usando a seguinte configuração:

• Configure o endpoint do Frame Relay com encapsulamento IETF.

• Configure o roteador IWF para o modo de tradução.

• Configure o endpoint ATM com encapsulamento 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

Nossos pings são bem-sucedidos. Vamos examinar os cabeçalhos dos pacotes em cada endpoint.

debug frame-relay packet no endpoint do 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

Voltando à nossa discussão sobre o encapsulamento IETF, vemos que o pacote de ping usa o cabeçalho de encapsulamento de forma curta, já que o protocolo IP recebe o valor NLPID de 0xCC.

debug atm packet em 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

Para PDUs (Routed Protocol Data Units, unidades de dados de protocolo roteadas), o encapsulamento AAL5SNAP usa um valor OUI de 0x000000 e um valor Ethertype (como 0x0800 para IP) para o campo de tipo. Consulte Vários Protocolos Roteados sobre PVCs ATM Usando Encapsulamento LLC para obter mais informações.

Nossas depurações ilustram como o IWF converte entre o cabeçalho NLPID do Frame Relay e o cabeçalho ATM do AAL5SNAP.

Modo transparente ilustrado

Para ilustrar o modo transparente, vamos alterar somente o modo no roteador IWF. Emita o comando no service translation para configurar explicitamente o modo transparente.

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

Emita o comando show connect name para confirmar sua alteração.

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

Nossos pings entre os dois roteadores agora falham. Usando debug atm packet e debug atm error, vemos a razão da falha de ping - o cabeçalho NLPID original é transportado através do IWF e alcança o ponto final ATM, que é configurado com AAL5SNAP e não entende os 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

Com o encapsulamento AAL5SNAP, a interface ATM procura valores de ponto de acesso de serviço (DSAP) de destino e ponto de acesso de serviço de origem (SSAP) de AA para indicar que o cabeçalho SNAP segue. Em vez disso, no mesmo local de bytes, recebemos os valores de controle (0x03) e NLPID (0xCC para IP) do cabeçalho original do Frame Relay.

Podemos corrigir essa condição de erro alterando o encapsulamento ATM para AAL5NLPID. Agora, ambos os endpoints estão usando o mesmo encapsulamento, portanto, nossos pings são bem-sucedidos.

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

Informações Relacionadas

• Interfuncionamento entre serviços Frame Relay e ATM
• Suporte à tecnologia de interfuncionamento ATM para Frame Relay
• Configurando a modelagem de tráfego em frame relay para PVCs de entrelaçamento de serviço ATM (FRF.8)
• Suporte à tecnologia ATM
• Suporte Técnico e Documentação - Cisco Systems