Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Entendendo os cabeçalhos da Camada 2

Entendendo o Frame Relay IETF e o encapsulamento Cisco

Encapsulamento IETF

Encapsulamento Cisco

Modo de conversão e modo transparente definidos

Configurar

Diagrama de Rede

Configurações

Comandos debug

Modo de conversão ilustrado

Modo transparente ilustrado

Informações Relacionadas

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:

Valor

Descrição

0x00

Camada de rede nula ou conjunto inativo (não é usado com Frame Relay)

0x80

Protocolo de Acesso à Sub-Rede (SNAP - Subnetwork Access Protocol)

0x81

CLNP do ISO

0x82

Sistema Final ISO para Sistema Intermediário (ES-IS)

0x83

Sistema intermediário ISO para sistema intermediário (IS-IS)

0xCC

IP Internet

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

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 bilhões

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

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