Verständnis von transparenten und Übersetzungsmodi mit FRF.8

Einführung

Das Frame Relay Forum (FRF) veröffentlicht Implementierungsvereinbarungen oder Standards für Frame Relay-Netzwerke, um die Interoperabilität zu fördern. FRF.8 gibt das Interworking zwischen Frame-Relay und ATM-Dienst an. Unsere Netzwerktopologie verwendet drei Komponenten:

• Router-Endpunkt mit einer seriellen Schnittstelle, die für Frame-Relay-Kapselung konfiguriert ist.

• ATM-Endgerät.

• Netzwerk-Switch oder Cisco Router, der die Interworking-Funktion (IWF) implementiert, um die Kommunikation zwischen den beiden Endpunkten zu ermöglichen.

In Abschnitt 5 der Vereinbarung FRF.8 werden zwei Modi der Kapselung von Protokollen der oberen Schicht erläutert. Diese Kapselung bezieht sich auf den Header, der das in der Protokolldateneinheit (Protocol Data Unit, PDU) übertragene Protokoll identifiziert, sodass der Empfänger das eingehende Paket ordnungsgemäß verarbeiten kann. FRF.8 definiert zwei Modi: Übersetzung und Transparenz. Durch die Auswahl eines dieser Modi bei der Interworking-Funktion wird die Kapselung bestimmt, die auf unserem ATM-Endpunkt konfiguriert werden muss.

In diesem Dokument werden die Unterschiede zwischen dem transparenten und dem Übersetzungsmodus auf Paketebene dargestellt, um bei der Behebung von End-to-End-Verbindungsproblemen bei FRF.8-Implementierungen behilflich zu sein.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Layer-2-Header

Frame Relay und ATM sind Layer-2-Protokolle für Netzwerkschnittstellen. Beide Protokolle verwenden auf Layer 2 zwei verschiedene Header:

• Kapselungsheader für Protokolle der obersten Ebene - Übergibt das im Frame oder in der Zelle gekapselte und transportierte Protokoll. Definiert durch Request for Comments (RFC) 1490 und FRF 3.2 für Frame Relay und RFC 1483 und 2684 für ATM.

• Adress-Header - Übergibt die Layer-2-Adresse (Data-Link Connection Identifier [DLCI] oder Virtual Path Identifier/Virtual Channel Identifier [VPI/VCI]) sowie Werte für Verlustpriorität und Überlastungsanzeige. Definiert in Q.922 (in der Regel zwei Byte) für Frame Relay und in einem 5-Byte-Zell-Header für ATM.

Hinweis: FRF.8-Übersetzung und transparente Modi betreffen den Kapselungs-Header.

Das folgende Diagramm zeigt ein Beispiel-Frame-Relay-Paket mit dem Q.922-Adressheader und den NLPID-Feldern (Control Layer Protocol Identification) des oberen Layer-Protokollkapselungs-Headers.

Verständnis von Frame-Relay IETF und Cisco Kapselung

Bevor wir uns einige Debugbefehle ansehen, um die FRF.8-Modi zu veranschaulichen, müssen wir zunächst die Frame-Relay-Kapselung verstehen. Cisco Router-Schnittstellen unterstützen zwei Protokollkapselungen: Cisco und die Internet Engineering Task Force (IETF), die Sie mit dem Befehl encapsulation frame-relais [ietf] auswählen können. Diese Kapselungen umfassen zwei IETF-Formate und ein Cisco Format. Schauen wir uns diese genauer an.

IETF-Kapselung

Die RFCs 1490 und 2427 definieren die IETF-Kapselung für Frame Relay. Sie geben an, wie ein NLPID-Wert verwendet wird. Das Dokument der ISO/International Electrotechnical Commission (IEC) TR 9577 definiert NLPID-Werte für eine ausgewählte Anzahl von Protokollen, darunter:

Protokolle mit einem definierten NLPID-Wert verwenden einen Kurzform-Header, wie unten gezeigt.

Protokolle ohne einen definierten NLPID-Wert verwenden einen SNAP-Header und geben dies mit einem NLPID-Wert von 0x80 an (siehe unten).

Der Router wählt automatisch das IETF-Formular aus, das von der folgenden Regel verwendet werden soll: Wenn ein NLPID-Wert für das Protokoll vorhanden ist, verwenden Sie die Kurzform. Falls nicht, verwenden Sie die lange Form.

Cisco Kapselung

Bei der Cisco Kapselung wird das Layer-3-Protokoll mithilfe eines 2-Byte-Steuerfelds mit EtherType-Werten identifiziert. Bei der Cisco Kapselung für IP wird der 2-Byte-EtherType von 0x0800, gefolgt vom IP-Datagramm, verwendet.

Definition von Übersetzung und transparentem Modus

Die FRF.8-Implementierungsvereinbarung verwendet den folgenden Wortlaut, um Übersetzungen und transparente Modi zu beschreiben.

• Transparent Mode (Modus 1) - Wenn Kapselungsmethoden nicht den in Modus 2 genannten Standards entsprechen, aber zwischen Endgeräten kompatibel sind, leitet die Interworking-Funktion (IWF) die Kapselungen unverändert weiter. Es werden keine Zuordnungen, Fragmentierungen oder Reassemblierungen durchgeführt.

• Translation Mode (Mode 2) - Kapselungsmethoden für die Übertragung mehrerer Benutzerprotokolle höherer Schichten (z. B. LAN zu LAN) über Frame Relay PVC und ATM PVC entsprechen jeweils den Standards FRF 3.2 bzw. RFC 2684. Die IWF führt aufgrund der Inkompatibilitäten der beiden Methoden eine Zuordnung zwischen den beiden Kapselungen durch. Der Übersetzungsmodus unterstützt das Interworking von Internetprotokollen (geroutet und/oder überbrückt).

Lassen Sie uns nun Cisco IOS® Software-Befehle anzeigen und debuggen, um zu verstehen, wie wir diese Modi auf eine tatsächliche Implementierung von FRF.8 auf Cisco Routern anwenden.

Konfigurieren

Netzwerkdiagramm

In diesem Abschnitt wird diese Netzwerkeinrichtung verwendet:

Konfigurationen

In diesem Abschnitt werden folgende Konfigurationen verwendet:

• 3620-1

• 7206 Mrd.

• 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

Hinweis: Bei der Veranschaulichung der beiden Modi nehmen wir zwei Konfigurationsänderungen vor, indem wir die Befehle encapsulation aal5nlpid auf dem ATM-Endpunkt und keine Serviceübersetzung auf dem IWF-Router ausgeben.

Debug-Befehle

Das Interworking-Gerät führt seinen Funktionsunterbrechungsmodus aus. Daher können wir die Debug-ATM-Paketausgabe nicht erfassen, da diese Debugger nur mit Paketen auf Prozessebene arbeiten. Wir müssen auf beiden Seiten Debugging ausführen, um das Format der Pakete zu erfassen.

Hinweis: Bevor Sie Debugbefehle ausgeben, lesen Sie Wichtige Informationen über Debug-Befehle.

• debug frame-Relay Packet int Serial 1/0 - Erfasst einen Decode auf Paketebene auf dem Frame-Relay-Endpunkt.

• debug atm packet int atm 4/0/0.50 - Erfasst einen Decode auf Paketebene auf dem ATM-Endpunkt.

• debug atm error - Erfasst Kapselungsfehler oder Diskrepanzen.

Übersetzungsmodus dargestellt

Wenn der ATM- und Frame-Relay-PVCs mithilfe des Befehls connect verbunden werden, verwendet der IWF-Router automatisch den Übersetzungsmodus. Bestätigen Sie dies mit dem Befehl show connect name.

Mithilfe der folgenden Konfiguration können wir einen Ping vom Frame Relay-Endpunkt zum ATM-Endpunkt initiieren:

• Konfigurieren Sie den Frame-Relay-Endpunkt mit IETF-Kapselung.

• Konfigurieren Sie den IWF-Router für den Übersetzungsmodus.

• Konfigurieren Sie den ATM-Endpunkt mit AAL5SNAP-Kapselung.

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

Unsere Pings sind erfolgreich. Betrachten wir nun die Paket-Header auf den einzelnen Endpunkten.

Debug-Frame-Relay-Paket auf Frame Relay Endpoint

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

Wenn wir auf die IETF-Kapselung zurückgreifen, sehen wir, dass das Ping-Paket den Kapselungsheader in Kurzform verwendet, da dem IP-Protokoll der NLPID-Wert 0xCC zugewiesen wurde.

Debuggen von ATM-Paketen auf ATM-Endpunkten

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

Für geroutete Protokolldateneinheiten (PDUs) verwendet die AAL5SNAP-Kapselung einen OUI-Wert von 0x00000 und einen Ethertype-Wert (z. B. 0x0800 für IP) für das Typfeld. Weitere Informationen finden Sie unter Mehrere Routed Protocols Over ATM PVCs Using LLC Encapsulation.

Unser Debug zeigt, wie die IWF zwischen dem Frame Relay NLPID-Header und dem AAL5SNAP ATM-Header übersetzt.

Transparenter Modus dargestellt

Um den transparenten Modus zu veranschaulichen, ändern wir nur den Modus des IWF-Routers. Geben Sie den Befehl no service translation ein, um den transparenten Modus explizit zu konfigurieren.

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

Geben Sie den Befehl show connect name ein, um die Änderung zu bestätigen.

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

Unsere Pings zwischen den beiden Routern schlagen jetzt fehl. Mit debug atm packet und debug atm error sehen wir den Grund für den Ping-Fehler. Der ursprüngliche NLPID-Header wird direkt über die IWF übertragen und erreicht den ATM-Endpunkt, der mit AAL5SNAP konfiguriert ist und die NLPID-Werte nicht versteht.

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

Bei der AAL5SNAP-Kapselung sucht die ATM-Schnittstelle nach den Werten für den Ziel-Service-Access-Point (DSAP) und den Source Service Access Point (SSAP) der AA, um anzugeben, dass der SNAP-Header folgt. Stattdessen erhalten wir am gleichen Byte-Standort die Steuerungs- (0x03) und NLPID- (0xCC für IP)-Werte des ursprünglichen Frame-Relay-Headers.

Wir können diesen Fehler korrigieren, indem wir die ATM-Kapselung in AAL5NLPID ändern. Beide Endpunkte verwenden nun die gleiche Kapselung, sodass unsere Pings erfolgreich sind.

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

Zugehörige Informationen

• Frame Relay-to-ATM Service Interworking
• Technologische Unterstützung von ATM zu Frame Relay
• Konfigurieren von Traffic Shaping auf Frame Relay für ATM Service Interworking (FRF.8)-PVCs
• ATM-Technologieunterstützung
• Technischer Support und Dokumentation - Cisco Systems