Informazioni sulle modalità trasparente e di traduzione con FRF.8

Introduzione

Il Forum Frame Relay (FRF) pubblica accordi di implementazione o standard per le reti Frame Relay al fine di promuovere l'interoperabilità. FRF.8 specifica Frame Relay per l'interoperabilità del servizio ATM. La topologia di rete utilizza tre componenti:

• Endpoint router con interfaccia seriale configurata per l'incapsulamento Frame Relay.

• Endpoint ATM.

• Switch di rete o router Cisco che implementa la funzione di interworking (IWF) per consentire la comunicazione tra due endpoint.

La sezione 5 dell'accordo FRF.8 tratta due modalità di incapsulamento del protocollo di livello superiore. Questo incapsulamento si riferisce all'intestazione che identifica il protocollo trasportato nell'unità PDU (Protocol Data Unit) e consente al ricevitore di elaborare correttamente il pacchetto in arrivo. FRF.8 definisce due modalità: traslazione e trasparente. La selezione di una di queste modalità nella funzione di interworking determina l'incapsulamento da configurare sull'endpoint ATM.

In questo documento vengono illustrate le differenze a livello di pacchetto tra la modalità trasparente e la modalità di traduzione per agevolare la risoluzione dei problemi di connettività end-to-end con le implementazioni FRF.8.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Informazioni sulle intestazioni di livello 2

Frame Relay e ATM sono protocolli di livello 2 per le interfacce di rete. Entrambi i protocolli utilizzano due intestazioni diverse sul layer 2:

• Intestazione di incapsulamento protocollo di livello superiore - Comunica il protocollo incapsulato e trasportato nel fotogramma o nella cella. Definita da RFC (Request for Comments) 1490 e FRF 3.2 per Frame Relay e RFC 1483 e 2684 per ATM.

• Intestazione indirizzo: comunica l'indirizzo di layer 2 (DLCI (Data-Link Connection Identifier) o VCI (Virtual Path Identifier) o VCI (Virtual Channel Identifier) [VPI/VCI]), nonché i valori di priorità perdita e di indicazione congestione. Definito da Q.922 (in genere due byte) per Frame Relay e un'intestazione di cella da cinque byte per ATM.

Nota: le modalità di conversione FRF.8 e trasparente sono relative all'intestazione di incapsulamento.

Il diagramma seguente mostra un pacchetto Frame Relay di esempio con l'intestazione dell'indirizzo Q.922 e i campi NLPID (Control Layer Protocol Identification) dell'intestazione di incapsulamento del protocollo del livello superiore.

Informazioni su Frame Relay IETF e Cisco Encapsulation

Prima di esaminare alcuni comandi di debug per illustrare le modalità FRF.8, è necessario conoscere l'incapsulamento Frame Relay. Le interfacce del router Cisco supportano due incapsulamenti del protocollo, Cisco e Internet Engineering Task Force (IETF), che è possibile selezionare con il comando encapsulation frame-relay [ietf]. Questi incapsulamenti includono due formati IETF e un formato Cisco. Vediamo questi in dettaglio.

IETF Encapsulation

Gli RFC 1490 e 2427 definiscono l'incapsulamento IETF per Frame Relay. Specificano come utilizzare un valore NLPID. Il documento ISO/International Electrotechnical Commission (IEC) TR 9577 definisce i valori NLPID per un numero selezionato di protocolli, tra cui:

I protocolli con un valore NLPID definito utilizzano un'intestazione in formato breve, come illustrato di seguito.

I protocolli senza un valore NLPID definito utilizzano un'intestazione SNAP e lo indicano con un valore NLPID di 0x80, come illustrato di seguito.

Il router sceglie automaticamente il modulo IETF da utilizzare in base alla regola seguente: Se è presente un valore NLPID per il protocollo, utilizzare la forma abbreviata. In caso contrario, utilizzare la forma estesa.

Cisco Encapsulation

L'incapsulamento Cisco utilizza un campo di controllo a due byte con valori EtherType per identificare il protocollo di layer 3. L'incapsulamento Cisco per IP utilizza EtherType a due byte di 0x0800, seguito dal datagramma IP.

Definizione della modalità Traslazione e Trasparenza

L'accordo di implementazione di FRF.8 utilizza la seguente formulazione per descrivere le modalità di traduzione e trasparenza.

• Modalità trasparente (Modalità 1) - Quando i metodi di incapsulamento non sono conformi agli standard indicati in Modalità 2, ma sono compatibili tra terminali, la funzione di interworking (IWF) inoltra gli incapsulamenti senza alterarli. Non esegue alcuna mappatura, frammentazione o riassemblaggio.

• Modalità di traduzione (modalità 2) - I metodi di incapsulamento per il trasporto di più protocolli utente di livello superiore (ad esempio, da LAN a LAN) su un PVC Frame Relay e un PVC ATM sono conformi rispettivamente allo standard FRF 3.2 e RFC 2684. L'IWF esegue il mapping tra i due incapsulamenti a causa delle incompatibilità tra i due metodi. La modalità di traduzione supporta l'interworking dei protocolli di internetworking (routing e/o bridge).

A questo punto, è possibile usare i comandi show ed debug del software Cisco IOS® per capire come vengono applicate queste modalità a un'implementazione effettiva di FRF.8 sui router Cisco.

Configurazione

Esempio di rete

Questa sezione utilizza questa configurazione di rete:

Configurazioni

Questa sezione utilizza le seguenti configurazioni:

• 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: quando si illustrano le due modalità, si apportano due modifiche alla configurazione eseguendo i comandi encapsulation aal5nlpid sull'endpoint ATM e senza la traduzione del servizio sul router IWF.

Comandi debug

Il dispositivo di interworking esegue la sua modalità di interruzione delle funzioni e quindi non è possibile acquisire l'output del pacchetto di debug ATM poiché questi debug funzionano solo con il pacchetto a livello di processo. Per acquisire il formato dei pacchetti, è necessario eseguire il debug sulle due estremità.

Nota: prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• debug frame-relay packet int serial 1/0: acquisisce una decodifica a livello di pacchetto sull'endpoint frame-relay.

• debug atm packet int atm 4/0/0.50 - Acquisisce una decodifica a livello di pacchetto sull'endpoint ATM.

• debug atm error - Acquisisce gli errori di incapsulamento o le mancate corrispondenze.

Illustrata la modalità di conversione

Quando si usa il comando connect per collegare i PVC ATM e Frame Relay, il router IWF usa automaticamente la modalità di conversione. Per verificare questa condizione, utilizzare il comando show connect name.

È possibile avviare il ping tra l'endpoint Frame Relay e l'endpoint ATM con la configurazione seguente:

• Configurare l'endpoint Frame Relay con incapsulamento IETF.

• Configurare il router IWF per la modalità di conversione.

• Configurare l'endpoint ATM con incapsulamento 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

I nostri ping sono riusciti. Esaminiamo le intestazioni dei pacchetti su ciascun endpoint.

debug pacchetto frame relay su endpoint 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

Riferendosi alla nostra discussione sull'incapsulamento IETF, vediamo che il pacchetto ping usa l'intestazione di incapsulamento in formato breve perché al protocollo IP è assegnato il valore NLPID di 0xCC.

debug pacchetto atm su endpoint 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

Per le PDU (Routed Protocol Data Unit), l'incapsulamento AAL5SNAP utilizza un valore OUI di 0x000000 e un valore Ethertype (ad esempio 0x0800 per IP) per il campo type. Per ulteriori informazioni, fare riferimento a Più protocolli di routing su PVC ATM con incapsulamento LLC.

Nei debug di Dell viene illustrata la conversione IWF tra l'intestazione NLPID Frame Relay e l'intestazione ATM AAL5SNAP.

Illustrato in modalità trasparente

Per illustrare la modalità trasparente, modificare solo la modalità sul router IWF. Eseguire il comando no service translation per configurare in modo esplicito la modalità trasparente.

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

Utilizzare il comando show connect name per confermare la modifica.

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

I ping tra i due router ora hanno esito negativo. Utilizzando debug atm packet e debug atm error, viene visualizzata la causa dell'errore di ping - l'intestazione NLPID originale viene trasferita attraverso l'IWF e raggiunge l'endpoint ATM, configurato con AAL5SNAP e non in grado di interpretare i valori 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 l'incapsulamento AAL5SNAP, l'interfaccia ATM cerca i valori DSAP (Service-Access-Point) di destinazione e SSAP (Source Service Access Point) di AA per indicare che segue l'intestazione SNAP. Nella stessa posizione di byte vengono invece ricevuti i valori di controllo (0x03) e NLPID (0xCC per IP) dell'intestazione Frame Relay originale.

Per correggere questa condizione di errore, modificare l'incapsulamento ATM in AAL5NLPID. Ora, entrambi gli endpoint usano lo stesso incapsulamento, quindi i ping hanno successo.

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

Informazioni correlate

• Interoperabilità dei servizi Frame Relay-ATM
• Supporto della tecnologia di interoperabilità ATM - Frame Relay
• Configurazione del Traffic Shaping su Frame Relay per PVC ATM Service Interworking (FRF.8)
• Supporto della tecnologia ATM
• Documentazione e supporto tecnico – Cisco Systems