Inhalt

Einführung

Bevor Sie beginnen

Konventionen

Voraussetzungen

Verwendete Komponenten

Hintergrundtheorie

Konfigurieren des grundlegenden Frame-Relays

Netzwerkdiagramm

Konfigurationen

Befehle debuggen und anzeigen

Konfigurieren von Hub-and-Spoke-Frame-Relay

Netzwerkdiagramm

Konfigurationen

Befehle anzeigen

Verbindung zwischen Spoke und Spoke

Konfigurationen

Befehle anzeigen

Konfigurieren von Frame-Relay-Subschnittstellen

Point-to-Point-Subschnittstellen

Befehle anzeigen

Hub-and-Spoke-Subschnittstellen

Befehle anzeigen

Konfigurieren der dynamischen und statischen Zuordnung für Multipoint-Subschnittstellen

Netzwerkdiagramm

Konfigurationen

Befehle debuggen und anzeigen

Konfigurieren von IP Unnumbered Frame Relay

Netzwerkdiagramm

Konfigurationen

Befehle anzeigen

Konfigurieren von Frame-Relay-Backup

Frame Relay Backup über ISDN

Konfiguration pro DCLI-Backup

Hub-and-Spoke mit Dialer-Profilen

Konfigurieren von Frame-Relay-Switching

Netzwerkdiagramm

Konfigurationen

Befehle anzeigen

Konfigurieren der Frame-Relay-DLCI-Priorisierung

Überlegungen zur Implementierung

Netzwerkdiagramm

Konfigurationen

Befehle debuggen und anzeigen

Frame Relay Broadcast-Warteschlange

Traffic Shaping

Parameter für die Verkehrssteuerung

Generisches Traffic Shaping

Frame-Relay-Traffic-Shaping

Häufig verwendete Frame-Relay-Befehle

show frame-relais pvc

Frame-Relay-Karte anzeigen

Frame-Relay und Bridging

Frame-Relay und Arbeitsspeicher

Problembehandlung bei Frame Relay

"Serial0 ist ausgefallen, Leitungsprotokoll ist ausgefallen."

"Serial0 is up, line protocol is down" (Serial0 ist aktiv, Leitungsprotokoll ist ausgefallen)

"Serial0 is up, line protocol is up" (Serial0 ist aktiv, Leitungsprotokoll ist aktiv)

Eigenschaften von Frame-Relay

IP Split Horizon Checks

Pingen Sie Ihre eigene IP-Adresse auf einem Multipoint-Frame-Relay.

Die Schlüsselwortübertragung

Neukonfigurieren einer Subschnittstelle

DLCI-Einschränkungen

IP/IPX/AT-Adresse

RIP und IGRP

Keepalive

Serielle Schnittstellen

OSPF und Multipoint

Quellen

Zugehörige Informationen

Einführung

Frame Relay ist ein auf Branchenstandards basierendes Switched Data Link Layer-Protokoll, das mehrere virtuelle Schaltungen mithilfe der High-Level Data Link Control (HDLC)-Kapselung zwischen angeschlossenen Geräten verarbeitet. In vielen Fällen ist Frame Relay effizienter als X.25, das Protokoll, für das es im Allgemeinen als Ersatz gilt. Die folgende Abbildung zeigt einen Frame-Relay-Frame (ANSI T1.618).

In der obigen Abbildung sind Q.922-Adressen, wie derzeit definiert, zwei Oktette und enthalten eine 10-Bit-DLCI (Data-Link Connection Identifier). In einigen Netzwerken können Q.922-Adressen optional auf drei oder vier Oktette erhöht werden.

Die Felder "Flag" definieren den Anfang und das Ende des Frames. Das nachfolgende Feld mit dem führenden "Flag" enthält zwei Byte Adressinformationen. Zehn Bit dieser beiden Bytes bilden die tatsächliche Circuit-ID (DLCI, für die Verbindungskennung der Datenverbindung).

Der 10-Bit-DLCI-Wert ist das Herz des Frame-Relay-Headers. Identifiziert die logische Verbindung, die in den physischen Kanal Multiplex-Modus geschaltet wird. Im einfachen Adressierungsmodus (d. h. nicht erweitert durch die Local Management Interface [LMI]) haben DLCIs lokale Bedeutung. d. h. die Endgeräte an zwei verschiedenen Enden einer Verbindung können einen anderen DLCI verwenden, um auf dieselbe Verbindung zu verweisen.

Bevor Sie beginnen

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Voraussetzungen

Weitere Informationen und Definitionen der in diesem Dokument verwendeten Begriffe finden Sie im Frame Relay Glossar.

Verwendete Komponenten

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

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Hintergrundtheorie

Frame Relay wurde ursprünglich als Protokoll zur Verwendung über ISDN-Schnittstellen konzipiert. Erste diesbezügliche Vorschläge wurden 1984 dem Bereich für die Normung von Telekommunikationsnetzen der Internationalen Fernmeldeunion (ITU-T) (ehemals Beratender Ausschuss für internationale Telegrafie- und Telefondienste [CCITT]) vorgelegt. Die Arbeiten an Frame Relay wurden auch im ANSI-akkreditierten "T1S1 Standard Committee" in den Vereinigten Staaten durchgeführt.

1990 gründeten Cisco Systems, StrataCom, Northern Telecom und Digital Equipment Corporation ein Konsortium, das sich auf die Entwicklung von Frame-Relay-Technologien konzentrierte und die Einführung interoperabler Frame-Relay-Produkte beschleunigen sollte. Sie entwickelten eine Spezifikation, die dem unter T1S1 und ITU-T diskutierten grundlegenden Frame-Relay-Protokoll entspricht, erweiterten diese jedoch um Funktionen, die zusätzliche Funktionen für komplexe Internetworking-Umgebungen bieten. Diese Frame-Relay-Erweiterungen werden zusammen als LMI bezeichnet. Dabei handelt es sich um die "cisco" LMI im Router im Gegensatz zu "ansi" oder "q933a" LMI.

Frame Relay bietet eine Datenkommunikationsfunktion für das Paket-Switching, die über die Schnittstelle zwischen Benutzergeräten (z. B. Routern, Bridges, Hostsystemen) und Netzwerkgeräten (z. B. Switching-Knoten) verwendet wird. Benutzergeräte werden häufig als Datenendgeräte (Data Terminal Equipment, DTE) bezeichnet, während Netzwerkgeräte, die Schnittstellen zu DTE bilden, häufig als Data Circuit Terminating Equipment (DCE) bezeichnet werden. Das Netzwerk, das die Frame Relay-Schnittstelle bereitstellt, kann entweder ein öffentliches Carrier-basiertes Netzwerk oder ein Netzwerk aus privaten Geräten sein, die für ein einzelnes Unternehmen eingesetzt werden.

Frame Relay unterscheidet sich in Funktionalität und Format deutlich von X.25. Insbesondere Frame Relay ist ein optimiertes Protokoll, das eine höhere Leistung und Effizienz ermöglicht.

Frame Relay ist eine Schnittstelle zwischen Benutzer- und Netzwerkgeräten und bietet die Möglichkeit, viele logische Datengespräche (auch als virtuelle Schaltungen bezeichnet) statistisch über eine einzelne physische Übertragungsverbindung zu multiplizieren. Dies steht im Gegensatz zu Systemen, die nur Time-Division-Multiplexing (TDM)-Techniken zur Unterstützung mehrerer Datenströme verwenden. Das statistische Multiplexing von Frame Relay ermöglicht eine flexiblere und effizientere Nutzung der verfügbaren Bandbreite. Er kann ohne TDM-Verfahren oder zusätzlich zu den von TDM-Systemen bereitgestellten Kanälen verwendet werden.

Ein weiteres wichtiges Merkmal von Frame Relay ist die Ausnutzung der neuesten Fortschritte in der WAN-Übertragungstechnologie (Wide Area Network). Frühere WAN-Protokolle wie X.25 wurden entwickelt, wenn analoge Übertragungssysteme und Kupfermedien vorherrschten. Diese Verbindungen sind wesentlich weniger zuverlässig als die derzeit verfügbaren Glasfaser-Media-/Digital-Transmission-Verbindungen. Bei Verbindungen wie diesen können Link-Layer-Protokolle auf zeitaufwendige Fehlerkorrekturalgorithmen verzichten, sodass diese auf höheren Protokollschichten ausgeführt werden können. Eine höhere Leistung und Effizienz ist daher ohne Beeinträchtigung der Datenintegrität möglich. Frame Relay wurde mit diesem Ansatz entwickelt. Es enthält einen CRC-Algorithmus (zyklische Redundanzprüfung) zum Erkennen beschädigter Bits (sodass die Daten verworfen werden können), jedoch keine Protokollmechanismen zum Korrigieren fehlerhafter Daten (z. B. durch Neuübertragung auf dieser Protokollebene).

Ein weiterer Unterschied zwischen Frame Relay und X.25 besteht darin, dass in Frame Relay keine explizite, pro virtuellem Schaltkreis stattfindende Flusssteuerung vorhanden ist. Da viele Protokolle der oberen Schicht ihre eigenen Flow-Control-Algorithmen effektiv ausführen, ist die Notwendigkeit dieser Funktionalität auf der Link-Layer zurückgegangen. Frame Relay enthält daher keine expliziten Flusssteuerungsverfahren, die die in höheren Schichten duplizieren. Stattdessen werden sehr einfache Überlastungsbenachrichtigungsmechanismen bereitgestellt, mit denen ein Netzwerk einem Benutzergerät mitteilen kann, dass sich die Netzwerkressourcen in der Nähe eines überlasteten Zustands befinden. Durch diese Benachrichtigung können Protokolle höherer Schichten benachrichtigt werden, die eine Flusskontrolle benötigen.

Konfigurieren des grundlegenden Frame-Relays

Wenn Sie an beiden Enden der permanenten Virtual Circuit (PVC) über zuverlässige Verbindungen zum lokalen Frame Relay-Switch verfügen, ist es an der Zeit, mit der Planung der Frame Relay-Konfiguration zu beginnen. In diesem ersten Beispiel lautet die Standardeinstellung für den Typ Local Management Interface (LMI) "cisco" LMI auf Spicey. Eine Schnittstelle ist standardmäßig eine "Multipoint"-Schnittstelle, sodass Frame-Relay inverse-arp aktiviert ist (für Point-to-Point gibt es kein Inverse ARP). Die IP Split Horizon-Überprüfung ist standardmäßig für Frame Relay-Kapselung deaktiviert, sodass Routing-Updates über dieselbe Schnittstelle eingehen und aus dieser heraus kommen. Die Router erhalten die DLCIs (Data-Link Connection Identifiers), die sie vom Frame-Relay-Switch über LMI-Updates verwenden müssen. Die Router führen dann Inverse ARP für die Remote-IP-Adresse aus und erstellen eine Zuordnung der lokalen DLCIs und der zugehörigen Remote-IP-Adressen.

Netzwerkdiagramm

Konfigurationen

- scharf

- Pracht

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1705 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle debuggen und anzeigen

Bevor Sie Debugbefehle ausgeben, beachten Sie bitte Wichtige Informationen über Debug-Befehle.

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

- show frame-relais-LMI

- ping <Gerätename>

- show ip route

scharf

Spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 83            output pkts 87           in bytes 8144

out bytes 8408           dropped pkts 0           in FECN pkts0

in BECN pkts 0           out FECN pkts 0          out BECN pkts0

in DE pkts 0             out DE pkts 0

out bcast pkts 41         out bcast bytes 3652

pvc create time 01:31:50, last time pvc status changed 01:28:28

Spicey#show frame-relay lmi

LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 550              Num Status msgs Rcvd 552

Num Update Status Rcvd 0              Num Status Timeouts 0

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial0

124.0.0.0/24 is subnetted, 1 subnets

C       124.124.124.0 is directly connected, Ethernet0

R    123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0

Pracht

Prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 87            output pkts 83           in bytes 8408

out bytes 8144           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 38         out bcast bytes 3464

pvc create time 01:34:29, last time pvc status changed 01:28:05

Prasit#show frame-relay lmi

LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 569              Num Status msgs Rcvd 570

Num Update Status Rcvd 0              Num Status Timeouts 0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial1

R    124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1

123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Ethernet0

Konfigurieren von Hub-and-Spoke-Frame-Relay

In diesem Beispiel erfährt der Router vom Frame Relay-Switch, welche DLCIs (Data Link Connection Identifiers) verwendet werden, und weist sie der Hauptschnittstelle zu. Anschließend kehrt der Router ARP für die Remote-IP-Adresse um.

Hinweis: Sie können die serielle IP-Adresse von Aton nur dann pingen, wenn Sie Frame-Relay-Karten an jedem Ende explizit hinzufügen. Wenn das Routing richtig konfiguriert ist, sollte der Datenverkehr, der von den LANs ausgeht, kein Problem darstellen. Sie können einen Ping senden, wenn Sie die Ethernet-IP-Adresse als Quelladresse in einem erweiterten Ping verwenden.

Wenn Frame-Relay inverse-arp aktiviert ist, wird standardmäßig Broadcast IP-Datenverkehr über die Verbindung übertragen.

Netzwerkdiagramm

Konfigurationen

- scharf

- Pracht

- Aton

scharf

spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname spicey

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 130

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname aton

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router rip

network 3.0.0.0

network 122.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

- ping <Gerätename>

scharf

spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,

broadcast,, status defined, active

spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 32            output pkts 40           in bytes 3370

out bytes 3928           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 30         out bcast bytes 2888

pvc create time 00:15:46, last time pvc status changed 00:10:42

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 282           output pkts 291          in bytes 25070

out bytes 27876          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 223        out bcast bytes 20884

pvc create time 02:28:36, last time pvc status changed 02:25:14

spicey#

spicey#ping 3.1.3.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

spicey#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Pracht

prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 311           output pkts 233          in bytes 28562

out bytes 22648          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 162        out bcast bytes 15748

pvc create time 02:31:39, last time pvc status changed 02:25:14

prasit#ping 3.1.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

prasit#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Aton

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 35            output pkts 32           in bytes 3758

out bytes 3366           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 27         out bcast bytes 2846

pvc create time 00:10:53, last time pvc status changed 00:10:53

aton#ping 3.1.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

aton#ping 3.1.3.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Verbindung zwischen Spoke und Spoke

In einer Hub-and-Spoke-Konfiguration können mithilfe von Multipoint-Schnittstellen keine Ping-Signale von einem Spoke-zu-einem-Spoke-System gesendet werden, da keine Zuordnung für die IP-Adressen der anderen Spokes vorhanden ist. Nur die Adresse des Hubs wird über das Inverse Address Resolution Protocol (IARP) erfasst. Wenn Sie eine statische Karte mit dem Befehl Frame-Relay Map (Frame-Relay-Zuordnung) für die IP-Adresse eines Remote-Spokes konfigurieren, um die lokale Data Link Connection Identifier (DLCI) zu verwenden, können Sie die Adressen anderer Stationen pingen.

Konfigurationen

Pracht

prasit#show running-config

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay map ip 3.1.3.3 150

frame-relay interface-dlci 150

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- ping <Gerätename>

- show running-config

Pracht

prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,

CISCO, status defined, active

prasit#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms

prasit#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms

Aton

aton#show running-config

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay interface-dlci 160

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

aton#ping 3.1.3.2

Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

aton#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms

Konfigurieren von Frame-Relay-Subschnittstellen

Frame Relay-Subschnittstellen bieten einen Mechanismus zur Unterstützung von teilweise vernetzten Frame-Relay-Netzwerken. Die meisten Protokolle gehen von einer Überganglichkeit in einem logischen Netzwerk aus. Wenn Station A mit Station B sprechen kann und Station B mit Station C sprechen kann, sollte Station A direkt mit Station C sprechen können. Transitivität gilt für LANs, aber nicht für Frame-Relay-Netzwerke, es sei denn, A ist direkt mit C verbunden.

Darüber hinaus können bestimmte Protokolle, wie AppleTalk und transparente Bridging, nicht in teilweise vernetzten Netzwerken unterstützt werden, da sie "Split Horizon" erfordern, bei dem ein über eine Schnittstelle empfangenes Paket nicht über dieselbe Schnittstelle übertragen werden kann, selbst wenn das Paket auf verschiedenen virtuellen Schaltkreisen empfangen und übertragen wird.

Durch die Konfiguration von Frame-Relay-Subschnittstellen wird sichergestellt, dass eine einzige physische Schnittstelle als mehrere virtuelle Schnittstellen behandelt wird. Diese Funktion ermöglicht es uns, Split Horizon-Regeln zu überwinden. Pakete, die auf einer virtuellen Schnittstelle empfangen werden, können nun auch über dieselbe physische Schnittstelle an eine andere virtuelle Schnittstelle weitergeleitet werden.

Subschnittstellen adressieren die Einschränkungen von Frame-Relay-Netzwerken, indem sie eine Möglichkeit bieten, ein teilweise vernetztes Frame-Relay-Netzwerk in eine Reihe kleinerer, vollständig vernetzter (oder Point-to-Point-)Subnetzwerke zu unterteilen. Jedem Subnetz wird eine eigene Netzwerknummer zugewiesen, die den Protokollen so angezeigt wird, als ob es über eine separate Schnittstelle erreichbar wäre. (Beachten Sie, dass Point-to-Point-Subschnittstellen für die Verwendung mit IP nicht nummeriert werden können, wodurch die Adressierungslast verringert wird, die andernfalls entstehen könnte.)

Point-to-Point-Subschnittstellen

Netzwerkdiagramm

Konfigurationen

- scharf

- Pracht

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1338 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

enable password ww

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 140

!

!

router igrp 2

network 3.0.0.0

network 124.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1234 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 3.1.3.2 255.255.255.0

frame-relay interface-dlci 150

!

router igrp 2

network 3.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

scharf

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 193              output pkts 175          in bytes 20450

out bytes 16340             dropped pkts 0           in FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 50         out    bcast bytes 3786

pvc create time 01:11:27, last time pvc status changed 00:42:32

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Pracht

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 74               output pkts 89           in    bytes 7210

out bytes 10963             dropped pkts 0           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 24           out bcast bytes 4203

pvc create time 00:12:25, last time pvc status changed 00:12:25

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Hub-and-Spoke-Subschnittstellen

Die folgende Hub-and-Spoke-Beispielkonfiguration zeigt zwei Punkt-zu-Punkt-Subschnittstellen und verwendet eine dynamische Adressauflösung an einem Remote-Standort. Jede Subschnittstelle wird mit einer individuellen Protokolladresse und Subnetzmaske bereitgestellt, und der Befehl interface-dlci ordnet die Subschnittstelle einer angegebenen Data-Link Connection Identifier (DLCI) zu. Die Adressen von Remote-Zielen für jede Point-to-Point-Subschnittstelle werden nicht aufgelöst, da es sich um Point-to-Point-Adressen handelt und der Datenverkehr an den Peer am anderen Ende gesendet werden muss. Das Remote-Ende (Aton) verwendet Inverse ARP für seine Zuordnung, und der Haupt-Hub antwortet dementsprechend mit der IP-Adresse der Subschnittstelle. Dies liegt daran, dass Frame Relay Inverse ARP standardmäßig für Multipoint-Schnittstellen aktiviert ist.

Netzwerkdiagramm

Konfigurationen

- scharf

- Pracht

- Aton

scharf

Spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface Serial0.2 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 130

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

!

hostname Aton

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router igrp 2

network 3.0.0.0

network 122.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

scharf

Spicey#show frame-relay map

Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, active

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2

input pkts 11            output pkts 22           in bytes 1080

out bytes 5128           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 17         out bcast bytes 4608

pvc create time 00:06:36, last time pvc status changed 00:06:36

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 33            output pkts 28           in bytes 3967

out bytes 5445           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 17        out bcast bytes 4608

pvc create time 00:06:38, last time pvc status changed 00:06:38

Spicey#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Pracht

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 45            output pkts 48           in bytes 8632

out bytes 6661           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 31         out bcast bytes 5573

pvc create time 00:12:16, last time pvc status changed 00:06:23

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Aton

Aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 699           output pkts 634          in bytes 81290

out bytes 67008          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 528        out bcast bytes 56074

pvc create time 05:46:14, last time pvc status changed 00:05:57

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Konfigurieren der dynamischen und statischen Zuordnung für Multipoint-Subschnittstellen

Bei der dynamischen Adressenzuordnung wird Frame Relay Inverse ARP verwendet, um die nächste Hop-Protokolladresse für eine bestimmte Verbindung anzufordern, wobei eine Data Link Connection Identifier (DLCI) angegeben wird. Antworten auf inverse ARP-Anfragen werden in eine Adressenzuordnungstabelle für das DLCI auf dem Router oder Access Server eingegeben. Die Tabelle wird dann verwendet, um die Adresse des nächsten Hop-Protokolls oder das DLCI für ausgehenden Datenverkehr bereitzustellen.

Da die physische Schnittstelle jetzt als mehrere Subschnittstellen konfiguriert ist, müssen Sie Informationen bereitstellen, die eine Subschnittstelle von der physischen Schnittstelle unterscheiden und eine bestimmte Subschnittstelle einem bestimmten DLCI zuordnen.

Inverse ARP ist standardmäßig für alle von ihm unterstützten Protokolle aktiviert, kann jedoch für bestimmte Protokoll-DLCI-Paare deaktiviert werden. Als Ergebnis können Sie dynamische Zuordnungen für einige Protokolle und statische Zuordnungen für andere Protokolle im gleichen DLCI verwenden. Sie können Inverse ARP für ein Protokoll-DLCI-Paar explizit deaktivieren, wenn Sie wissen, dass das Protokoll am anderen Ende der Verbindung nicht unterstützt wird. Da Inverse ARP standardmäßig für alle unterstützten Protokolle aktiviert ist, ist kein zusätzlicher Befehl erforderlich, um die dynamische Adresszuordnung auf einer Subschnittstelle zu konfigurieren. Eine statische Zuordnung verbindet eine angegebene Next-Hop-Protokolladresse mit einem angegebenen DLCI. Durch die statische Zuordnung entfallen inverse ARP-Anfragen. Wenn Sie eine statische Zuordnung angeben, wird Inverse ARP für das angegebene Protokoll im angegebenen DLCI automatisch deaktiviert. Sie müssen statische Zuordnung verwenden, wenn der Router am anderen Ende Inverse ARP überhaupt nicht unterstützt oder Inverse ARP für ein bestimmtes Protokoll, das Sie über Frame Relay verwenden möchten, nicht unterstützt.

Netzwerkdiagramm

Wir haben bereits gesehen, wie ein Cisco Router für Inverse ARP konfiguriert wird. Im folgenden Beispiel wird veranschaulicht, wie statische Karten konfiguriert werden, falls Sie sie für Multipoint-Schnittstellen oder Subschnittstellen benötigen:

Konfigurationen

- Aton

- scharf

- Pracht

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 multipoint

ip address 4.0.1.3 255.255.255.0

frame-relay map ip 4.0.1.1 160 broadcast

!

router igrp 2

network 4.0.0.0

network 122.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

scharf

Spicey#show running-config

Building configuration...Current configuration : 1652 bytes!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 4.0.1.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 4.0.1.2 140 broadcast

frame-relay map ip 4.0.1.3 130 broadcast

!

router igrp 2

network 4.0.0.0

network 124.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1162 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 multipoint

ip address 4.0.1.2 255.255.255.0

frame-relay map ip 4.0.1.1 150 broadcast

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle debuggen und anzeigen

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

Aton

Aton#show frame-relay map

Serial1.1 (up): ip 4.0.1.1 dlci 160(0xA0,0x2800), static, broadcast,

CISCO, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 16            output pkts 9            in bytes 3342

out bytes 450            dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 9          out bcast bytes 450

pvc create time 00:10:02, last time pvc status changed 00:10:02

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

scharf

Spicey#show frame-relay map

Serial0 (up): ip 4.0.1.2 dlci 140(0x8C,0x20C0), static, broadcast,

CISCO, status defined, active

Serial0 (up): ip 4.0.1.3 dlci 130(0x82,0x2020), static, broadcast,

CISCO, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 9              output pkts 48           in bytes 434

out bytes 11045           dropped pkts 0           in FECN pkts 0

in BECN pkts 0            out FECN pkts 0          out BECN pkts 0

in DE pkts 0              out DE pkts 0

out bcast pkts 48         out bcast bytes 11045

pvc create time 00:36:25, last time pvc status changed 00:36:15

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 17             output pkts 26           in bytes 1390

out bytes 4195            dropped pkts 0           in FECN pkts 0

in BECN pkts 0            out FECN pkts 0          out BECN pkts 0

in DE pkts 0              out DE pkts 0

out bcast pkts 16         out bcast bytes 3155

pvc create time 00:08:39, last time pvc status changed 00:08:39

Spicey#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36

Pracht

Prasit#show frame-relay map

Serial1.1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), static,

broadcast,

CISCO, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1

input pkts 28            output pkts 19           in bytes 4753

out bytes 1490           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 9         out bcast bytes 450

pvc create time 00:11:00, last time pvc status changed 00:11:00

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Weitere Informationen zu diesen Befehlen finden Sie unter Frame-Relay-Befehle.

Konfigurieren von IP Unnumbered Frame Relay

Wenn Sie nicht über den IP-Adressbereich verfügen, um viele Subschnittstellen zu verwenden, können Sie auf jeder Subschnittstelle IP-Unnumbered (nicht nummerierte IP) verwenden. In diesem Fall müssen Sie statische Routen oder dynamisches Routing verwenden, damit der Datenverkehr wie gewohnt weitergeleitet wird, und Sie müssen Punkt-zu-Punkt-Subschnittstellen verwenden.

Netzwerkdiagramm

Das folgende Beispiel veranschaulicht dies:

Konfigurationen

- scharf

- Pracht

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1674 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip unnumbered Ethernet0

frame-relay interface-dlci 140

!

router igrp 2

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1188 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip unnumbered Ethernet0

frame-relay interface-dlci 150

!

router igrp 2

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

scharf

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial0.1

input pkts 23            output pkts 24           in bytes 3391

out bytes 4952           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 14         out bcast bytes 3912

pvc create time 00:04:47, last time pvc status changed 00:04:47

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

124.0.0.0/24 is subnetted, 1 subnets

C       124.124.124.0 is directly connected, Ethernet0

123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

I       123.0.0.0/8 [100/8576] via 123.123.123.1, 00:01:11, Serial0.1

I       123.123.123.0/32 [100/8576] via 123.123.123.1, 00:01:11,

Serial0.1

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Pracht

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 24            output pkts 52           in bytes 4952

out bytes 10892          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 41         out bcast bytes 9788

pvc create time 00:10:54, last time pvc status changed 00:03:51

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

I       124.0.0.0/8 [100/8576] via 124.124.124.1, 00:00:18, Serial1.1

I       124.124.124.0/32 [100/8576] via 124.124.124.1, 00:00:18,

Serial1.1

123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/120/436 ms

Konfigurieren von Frame-Relay-Backup

Frame Relay Backup über ISDN

Sie können Frame-Relay-Schaltungen mithilfe von ISDN sichern. Dafür gibt es mehrere Möglichkeiten. Die erste und wahrscheinlich beste Möglichkeit besteht darin, Floating-statische Routen zu verwenden, die den Datenverkehr an eine BRI-IP-Adresse (Basic Rate Interface) weiterleiten und eine entsprechende Routing-Metrik verwenden. Sie können auch eine Backup-Schnittstelle an der Hauptschnittstelle oder eine DLCI-Basis (Data-Link Connection Identifier) verwenden. Die Sicherung der Hauptschnittstelle ist möglicherweise nicht besonders hilfreich, da permanente virtuelle Schaltungen (PVCs) verloren gehen können, ohne dass die Hauptschnittstelle ausfällt. Denken Sie daran, dass das Protokoll mit dem lokalen Frame-Relay-Switch und nicht mit dem Remote-Router ausgetauscht wird.

Konfigurationen

- Router 1

- Router 2

Router 1

ROUTER1#

!

hostname ROUTER1

!

username ROUTER2 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.1 255.255.255.248

!

interface serial 0

ip address 172.16.24.129 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description Backup ISDN for frame-relay

ip address 172.16.12.1 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer wait-for-carrier-time 60

dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706

ppp authentication chap

dialer-group 1

isdn spid1 0127280320 2728032

isdn spid2 0127295120 2729512

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.16 255.255.255.248 172.16.12.2 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 LIST 101

!

Router 2

ROUTER2#

!

hostname ROUTER2

!

username ROUTER1 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.17 255.255.255.248

!

interface Serial 0

ip address 172.16.24.130 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description ISDN backup interface for frame-relay

ip address 172.16.12.2 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer map IP 172.16.12.1 name ROUTER1 broadcast

ppp authentication chap

pulse-time 1

dialer-group 1

isdn spid1 0191933333 4445555

isdn spid2 0191933334 4445556

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.0 255.255.255.248 172.16.12.1 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255

dialer-list 1 LIST 101

!

Befehle anzeigen

Verwenden Sie die folgenden Debug-Befehle, um zu überprüfen, ob die ISDN funktioniert. Bevor Sie Debugbefehle ausgeben, beachten Sie bitte Wichtige Informationen über Debug-Befehle.

- debug isdn q931

- Debug-ppp-Neg

- Debug-ppp-Authentifizierung

Versuchen Sie, ohne Backup-Befehle von der Anruferseite zur Zentrale einen ISDN-Anruf zu tätigen. Wenn dies erfolgreich ist, fügen Sie die Sicherungsbefehle zur aufrufenden Seite hinzu.

Hinweis: Verwenden Sie zum Testen der Sicherung nicht den Befehl shutdown auf der seriellen Schnittstelle, sondern emulieren Sie ein echtes Problem mit der seriellen Leitung, indem Sie das Kabel aus der seriellen Leitung ziehen.

Konfiguration pro DCLI-Backup

Nehmen wir nun an, dass Spicey die zentrale Seite ist und dass Prasit die Seite ist, die Verbindungen zur zentralen Seite (Spicey) herstellt. Achten Sie darauf, dass Sie die Sicherungsbefehle nur der Seite hinzufügen, die die zentrale Seite aufruft.

Hinweis: Sicherungslast wird auf Subschnittstellen nicht unterstützt. Da die Datenverkehrsstufen an Subschnittstellen nicht nachverfolgt werden, wird keine Last berechnet.

Netzwerkdiagramm

Konfigurationen

- scharf

- Pracht

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1438 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

username Prasit password 0 cisco

!

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface BRI0

ip address 3.1.6.1 255.255.255.0

encapsulation ppp

dialer map ip 3.1.6.2 name Prasit broadcast

dialer-group 1

isdn switch-type basic-net3

no peer default ip address

no cdp enable

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

!

ip classless

ip route 123.123.123.0 255.255.255.0 3.1.6.2 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1245 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

username Spicey password 0 cisco

!

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

backup delay 5 10

backup interface BRI0

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

interface BRI0

ip address 3.1.6.2 255.255.255.0

encapsulation ppp

dialer map ip 3.1.6.1 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 123.0.0.0

!

ip route 124.124.124.0 255.255.255.0 3.1.6.1 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show ip route

- show isdn verlauf

- show isdn status

- show interface bri 0

- show isdn active

scharf

Spicey#show frame-relay map

Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, active

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 2 subnets C

3.1.3.0 is directly connected, Serial0.2 C

3.1.6.0 is directly connected, BRI0

4.0.0.0/24 is subnetted, 1 subnets C

4.0.1.0 is directly connected, Serial0.1

124.0.0.0/24 is subnetted, 1 subnets C

124.124.124.0 is directly connected, Ethernet0

123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks I

123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:00, Serial0.1 S

123.123.123.0/24 [250/0] via 3.1.6.2 I

122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:37, Serial0.2

Spicey#

*Mar  1 00:59:12.527: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

*Mar  1 00:59:13.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 00:59:18.547: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6105 Prasit

Spicey#show isdn history

--------------------------------------------------------------------------------

ISDN CALL HISTORY

--------------------------------------------------------------------------------

Call History contains all active calls, and a maximum of 100 inactive calls.

Inactive call data will be retained for a maximum of 15 minutes.

--------------------------------------------------------------------------------

Call    Calling      Called          Remote  Seconds Seconds Seconds

Charges

Type    Number       Number          Name    Used    Left    Idle  Units/Currency

--------------------------------------------------------------------------------

In         6105           6106       Prasit          31      90     29

--------------------------------------------------------------------------------

Spicey#

*Mar  1 01:01:14.547: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected

from 6105 Prasit, call lasted 122 seconds

*Mar  1 01:01:14.663: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:01:15.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to down

Pracht

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

I    3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:55, Serial1.1

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial1.1

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S    124.124.124.0/24 [250/0] via 3.1.6.1

I    124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:55, Serial1.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

I    122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:55, Serial1.1

Die serielle Leitung wird deaktiviert.

Prasit#

*Mar  1 01:23:50.531: %LINK-3-UPDOWN: Interface Serial1, changed state to down

*Mar  1 01:23:51.531: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to down

*Mar  1 01:23:53.775: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:23:53.791: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

*Mar  1 01:23:53.827: %LINK-3-UPDOWN: Interface BRI0, changed state to up

*Mar  1 01:23:57.931: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.6.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 3.1.6.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0x80000003

Total Allocated ISDN CCBs = 0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!

*Mar  1 01:25:47.383: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms

Prasit#

*Mar  1 01:25:48.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

Prasit#

*Mar  1 01:25:53.407: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6106 Spicey

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

1 Active Layer 3 Call(s)

CCB:callid=8003, sapi=0, ces=1, B-chan=1, calltype=DATA

Active dsl 0 CCBs = 1

The Free Channel Mask: 0x80000002

Total Allocated ISDN CCBs = 1

Prasit#show isdn active

--------------------------------------------------------------------------------

ISDN ACTIVE CALLS

--------------------------------------------------------------------------------

Call    Calling      Called          Remote  Seconds Seconds Seconds Charges

Type    Number       Number          Name    Used    Left    Idle    Units/Currency

--------------------------------------------------------------------------------

Out                   6106         Spicey      21     100      19       0

--------------------------------------------------------------------------------

Prasit#

*Mar  1 01:27:49.027: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected

from 6106 Spicey, call lasted 121 seconds

*Mar  1 01:27:49.131: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:27:50.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to down

*Mar  1 01:28:09.215: %LINK-3-UPDOWN: Interface Serial1, changed state to up

*Mar  1 01:28:10.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to up

*Mar  1 01:28:30.043: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,

TEI 64 changed to down

*Mar  1 01:28:30.047: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI

64 changed to down

*Mar  1 01:28:30.371: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

*Mar  1 01:28:30.387: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:28:30.403: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

Prasit#

Die serielle Verbindung ist wieder hergestellt.

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface    ISDN Switchtype = basic-net3

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 2 NOT Activated

Layer 3 Status:

0 Active Layer    3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0x80000003

Total Allocated ISDN CCBs = 0

Prasit#show interface bri 0

BRI0 is standby mode, line protocol is down

Hardware is BRI

Internet address is 3.1.6.2/24

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Last input 00:01:00, output 00:01:00, output hang never

Last clearing of "show interface" counters 01:28:16

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations  0/1/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

128 packets input, 601 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

132 packets output, 687 bytes, 0 underruns

0 output errors, 0 collisions, 10 interface resets

0 output buffer failures, 0 output buffers swapped out

14 carrier transitions

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Hub-and-Spoke mit Dialer-Profilen

Im Folgenden sehen Sie ein Beispiel für eine "Hub and Spoke"-Sicherungskonfiguration pro DLCI. Die Spoke-Router rufen den Hub-Router an. Wie Sie sehen können, erlauben wir nur einen B-Kanal pro Seite, indem wir die Option max-link im Dialer-Pool auf der Hub-Seite verwenden.

Hinweis: Sicherungslast wird auf Subschnittstellen nicht unterstützt. Da die Datenverkehrsstufen an Subschnittstellen nicht nachverfolgt werden, wird keine Last berechnet.

Netzwerkdiagramm

Konfigurationen

- Aton

- scharf

- Pracht

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 3.1.3.3 255.255.255.0

backup delay 5 10

backup interface BRI0

frame-relay interface-dlci 160

!

interface BRI0

ip address 155.155.155.3 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer map ip 155.155.155.2 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 122.0.0.0

network 155.155.0.0

!

ip route 124.124.124.0 255.255.255.0 155.155.155.2 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1887 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

username Prasit password 0 cisco

username Aton password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface Serial0.2 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 130

!

interface BRI0

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool-member 2 max-link 1

dialer pool-member 1 max-link 1

isdn switch-type basic-net3

no peer default ip address

no cdp enable

ppp authentication chap

!

interface Dialer1

ip address 160.160.160.1 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 1

dialer remote-name Prasit

dialer-group 1

ppp authentication chap

!

interface Dialer2

ip address 155.155.155.2 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 2

dialer remote-name Aton

dialer-group 1

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

network 155.155.0.0

network 160.160.0.0

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1267 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

backup delay 5 10

backup interface BRI0

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

interface BRI0

ip address 160.160.160.2 255.255.255.0

encapsulation ppp

dialer map ip 160.160.160.1 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

network 160.160.0.0

!

ip route 124.124.124.0 255.255.255.0 160.160.160.1 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle anzeigen

- Frame-Relay-Karte anzeigen

- show ip route

- Bilderrahmen

- show frame-relais pvc

Aton

Aton#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Aton#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR, P - periodic downloaded static route

T - traffic engineered route

Gateway of last resort is not set

I    155.155.0.0/16 [100/182571] via 3.1.3.1, Serial1.1

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial1.1

I    4.0.0.0/8 [100/10476] via 3.1.3.1, Serial1.1

I    160.160.0.0/16 [100/182571] via 3.1.3.1, Serial1.1

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S    124.124.124.0/24 [250/0] via 155.155.155.2

I    124.0.0.0/8 [100/8576] via 3.1.3.1, Serial1.1

I    123.0.0.0/8 [100/10576] via 3.1.3.1, Serial1.1

122.0.0.0/24 is subnetted, 1 subnets

C    122.122.122.0 is directly connected, Ethernet0

Aton#

Die serielle 1 wird heruntergefahren.

Aton#

01:16:33: %LINK-3-UPDOWN: Interface Serial1, changed state to down

01:16:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,

changed state to down

01:16:37: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

01:16:37: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

01:16:37: %LINK-3-UPDOWN: Interface BRI0, changed state to up

01:16:41: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up

Aton#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR, P - periodic downloaded static route

T - traffic engineered route

Gateway of last resort is not set

155.155.0.0/24 is subnetted, 1 subnets

C    155.155.155.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 155.155.155.2

122.0.0.0/24 is subnetted, 1 subnets

C    122.122.122.0 is directly connected, Ethernet0

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

01:21:33: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms

Aton#

01:21:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,

changed state to up

01:21:39: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6106

Spicey

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/123/296 ms

Aton#

Serial 1 wird wieder aktiviert

Aton#

01:24:02: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected from 6106

Spicey, call lasted 149 seconds

01:24:02: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

01:24:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,

changed state to down

Aton#show frame map

Serial1.1 (down): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status deleted

Aton#

01:26:35: %LINK-3-UPDOWN: Interface Serial1, changed state to up

01:26:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,

changed state to up

01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0, TEI 64 changed

to down

01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 64 changed

to down

01:26:56: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

01:26:56: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

01:26:56: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

Aton#show frame map

Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Aton#ping 124.124.124.1

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 60               output pkts 69           in    bytes 9694

out bytes 10811             dropped pkts 0           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 44         out    bcast bytes 7565

pvc create time 01:28:35, last time pvc status changed 00:02:19

scharf

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, active

Spicey#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

155.155.0.0/24 is subnetted, 1 subnets

C    155.155.155.0 is directly connected, Dialer2

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial0.2

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial0.1

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, Dialer1

124.0.0.0/24 is subnetted, 1 subnets

C    124.124.124.0 is directly connected, Ethernet0

I    123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:55, Serial0.1

I    122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:35, Serial0.2

Beide seriellen Leitungen von den Anruferseiten gehen nach unten.

Spicey#

*Mar  1 01:21:30.171: %LINK-3-UPDOWN: Interface BRI0:1, changed state toup

*Mar  1 01:21:30.627: %DIALER-6-BIND: Interface BR0:1 bound to profile Di2

*Mar  1 01:21:31.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 01:21:36.191: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6104 Aton

*Mar  1 01:21:40.923: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up

*Mar  1 01:21:41.359: %DIALER-6-BIND: Interface BR0:2 bound to profile Di1

*Mar  1 01:21:42.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:2, changed state to up

*Mar  1 01:21:46.943: %ISDN-6-CONNECT: Interface BRI0:2 is now connected

to 6105 Prasit

*Mar  1 01:23:59.819: %DIALER-6-UNBIND: Interface BR0:1 unbound from

profile Di2

*Mar  1 01:23:59.831: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected

from 6104 Aton, call lasted 149 seconds

*Mar  1 01:23:59.927: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:24:00.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to down

*Mar  1 01:24:03.015: %DIALER-6-UNBIND: Interface BR0:2 unbound from

profile Di1

*Mar  1 01:24:03.023: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected

from 6105 Prasit, call lasted 142 seconds

*Mar  1 01:24:03.107: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

*Mar  1 01:24:04.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:2, changed state to down

Spicey#show frame map

Serial0.1 (down): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, inactive

Serial0.2 (down): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, inactive

Spicey#

Beide seriellen Leitungen sind wieder verfügbar.

Spicey#show frame pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          2               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial0.2

input pkts 54               output pkts 61           in    bytes 7014

out bytes 9975              dropped pkts 3           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 40         out    bcast bytes 7803

pvc create time 01:28:14, last time pvc status changed 00:02:38

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial0.1

input pkts 56               output pkts 60           in    bytes 7604

out bytes 10114             dropped pkts 2           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 39           out    bcast bytes 7928

pvc create time 01:28:15, last time pvc status changed 00:02:29

Pracht

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

I    155.155.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1

I    3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:41, Serial1.1

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial1.1

I    160.160.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S    124.124.124.0/24 [250/0] via 160.160.160.1

I    124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:41, Serial1.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

I    122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:42, Serial1.1

Prasit#

Serial 1 fällt aus.

Prasit#

*Mar  1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down

*Mar  1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to down

*Mar  1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

*Mar  1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up

*Mar  1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI

64 changed to up

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 160.160.160.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

*Mar  1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to

up.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms

Prasit#

*Mar  1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6106 Spicey

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit#

Serial 1 wird wieder aktiviert.

Prasit#

*Mar  1 01:26:40.579: %LINK-3-UPDOWN: Interface Serial1, changed state to up

*Mar  1 01:26:41.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to up

*Mar  1 01:27:01.051: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,

TEI 64 changed to down

*Mar  1 01:27:01.055: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI

64 changed to down

*Mar  1 01:27:01.363: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

*Mar  1 01:27:01.379: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:27:01.395: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

Prasit#show frame map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/116/432 ms

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =

Serial1.1

input pkts 58               output pkts 66           in    bytes 9727

out bytes 10022             dropped pkts 0           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 46         out    bcast bytes 7942

pvc create time 01:27:37, last time pvc status changed 00:01:59

Konfigurieren von Frame-Relay-Switching

Frame Relay Switching ist ein Mittel zum Switching von Paketen, die auf der Data-Link Connection Identifier (DLCI) basieren. Wir können dies als Frame Relay-Äquivalent einer MAC-Adresse (Media Access Control) betrachten. Sie führen Switching durch, indem Sie Ihren Cisco Router oder Access Server in einem Frame Relay-Netzwerk konfigurieren. Ein Frame-Relay-Netzwerk besteht aus zwei Teilen:

- Frame Relay Data Terminal Equipment (DTE) - der Router oder Access Server.

- Frame Relay Data Circuit Terminating Equipment (DCE)-Switch

Hinweis: In der Cisco IOS Software Version 12.1(2)T und höher wurde der Befehl frame route durch den Befehl connect ersetzt.

Sehen wir uns eine Beispielkonfiguration an. In der unten stehenden Konfiguration wird der Router America als Frame Relay-Switch verwendet. Wir verwenden Spicey als Hub-Router und Prasit und Aton als Spoke-Router. Sie wurden wie folgt verbunden:

- Prasit serial 1 (s1) DTE ist an America serial 1/4 (s1/4) DCE angeschlossen.

- Die Spicey Serial 0 (s0) DTE ist mit dem Serial 1/5 (s1/5) DCE der USA verbunden.

- Die serielle 1 (s1) DTE von Aton ist mit dem seriellen 3/4-DCE (s3/4) der USA verbunden.

Netzwerkdiagramm

Dieses Dokument basiert auf der folgenden Konfiguration:

Konfigurationen

- scharf

- Pracht

- Aton

- Amerika

scharf

Spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 130

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

!

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router rip

network 3.0.0.0

network 122.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Amerika

america#show running-config

Building configuration...

Current configuration:

!

!

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname america

!

frame-relay switching

!

!

interface Serial1/4

description *** static DCE connection to s1 Prasit

no ip address

encapsulation frame-relay

clockrate 2000000

frame-relay intf-type dce

frame-relay route 150 interface Serial1/5 140

!

interface Serial1/5

description *** static DCE connection to s0 spicy

no ip address

encapsulation frame-relay

bandwidth 1000000

tx-queue-limit 100

frame-relay intf-type dce

frame-relay route 130 interface Serial3/4 160

frame-relay route 140 interface Serial1/4 150

transmitter-delay 10

!

interface Serial3/4

description *** static DCE connection to s1 Aton

encapsulation frame-relay

no ip mroute-cache

clockrate 2000000

frame-relay intf-type dce

frame-relay route 160 interface Serial1/5 130

!

Befehle anzeigen

Verwenden Sie die folgenden Befehle, um zu testen, ob Ihr Netzwerk ordnungsgemäß funktioniert:

- Frame-Relay-Karte anzeigen

- show frame-relais pvc

Die unten dargestellte Ausgabe ist das Ergebnis der Eingabe dieser Befehle auf den Geräten, die wir in dieser Beispielkonfiguration verwenden.

scharf

Spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          2                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 32                 output pkts 40                in bytes 3370

out bytes 3928                dropped pkts 0                in FECN pkts 0

in BECN pkts 0                out FECN pkts 0               out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 30             out bcast bytes 2888

pvc create time 00:15:46, last time pvc status changed 00:10:42

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 282                output pkts 291          in bytes 25070

out bytes 27876               dropped pkts 0           in FECN pkts 0

in BECN pkts 0                out FECN pkts 0          out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 223            out bcast bytes 20884

pvc create time 02:28:36, last time pvc status changed 02:25:14

Pracht

Prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 311                output pkts 233          in bytes 28562

out bytes 22648               dropped pkts 0           in FECN pkts 0

in BECN pkts 0                out FECN pkts 0          out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 162            out bcast bytes 15748

pvc create time 02:31:39, last time pvc status changed 02:25:14

Aton

Aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic, broadcast, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial

input pkts 35                 output pkts 32                in bytes 3758

out bytes 3366                dropped pkts 0                in FECN pkt 0

in BECN pkts 0                out FECN pkts 0               out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 27 out bcast bytes 2846

pvc create time 00:10:53, last time pvc status changed 00:10:53

Konfigurieren der Frame-Relay-DLCI-Priorisierung

Die DLCI-Priorisierung (Data-Link Connection Identifier) ist der Prozess, bei dem verschiedene Datenverkehrstypen auf separaten DLCIs platziert werden, sodass ein Frame-Relay-Netzwerk für jeden Datenverkehrstyp eine andere Committed Information Rate bereitstellen kann. Sie kann in Verbindung mit benutzerdefinierter Warteschlangenverwaltung oder Prioritätswarteschlange verwendet werden, um die Bandbreitenverwaltung über die Zugriffsverbindung zum Frame Relay-Netzwerk zu steuern. Darüber hinaus bieten einige Frame-Relay-Service Provider und Frame-Relay-Switches (z. B. die Switches Stratacom Internetwork Packet Exchange [IPX], IGX- und BPX- oder AXIS-Switches) die Priorisierung innerhalb der Frame-Relay-Cloud basierend auf dieser Prioritätseinstellung.

Überlegungen zur Implementierung

Beachten Sie bei der Implementierung der DLCI-Priorisierung die folgenden Punkte:

- Wenn ein sekundäres DLCI ausfällt, verlieren Sie Datenverkehr, der nur für diese Warteschlange bestimmt ist.

- Wenn Sie den primären DLCI verlieren, wird die Subschnittstelle deaktiviert, und Sie verlieren den gesamten Datenverkehr.

Netzwerkdiagramm

Um diese Konfiguration verwenden zu können, benötigen Sie vier DLCIs für die Seite, die die DLCI-Priorisierung verwenden. In diesem Beispiel haben wir Spicey für Prioritätswarteschlangen wie folgt konfiguriert:

- Ping befindet sich in der Warteschlange mit hoher Priorität.

- Telnet befindet sich in der Warteschlange mit mittlerer Priorität.

- File Transfer Protocol (FTP) befindet sich in der normalen Prioritätswarteschlange.

- Der gesamte andere IP-Datenverkehr befindet sich in der Warteschlange mit niedriger Priorität.

Hinweis: Stellen Sie sicher, dass die DLCIs der Prioritätsliste entsprechen, oder das System verwendet nicht die richtige Warteschlange.

Konfigurationen

- scharf

- Pracht

scharf

Spicey#show running-config

Building configuration...

Current configuration : 1955 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname Spicey

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

priority-group 1

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay priority-dlci-group 1 140 180 190 200

frame-relay interface-dlci 140

!

router igrp 2

network 4.0.0.0

network 124.0.0.0

!

access-list 102 permit icmp any any

priority-list 1 protocol ip high list 102

priority-list 1 protocol ip medium tcp telnet

priority-list 1 protocol ip normal tcp ftp

priority-list 1 protocol ip low

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Pracht

Prasit#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 4.0.1.2 255.255.255.0

encapsulation frame-relay

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Befehle debuggen und anzeigen

Verwenden Sie die folgenden Befehle zum Anzeigen und Debuggen, um zu testen, ob das Netzwerk ordnungsgemäß funktioniert. Bevor Sie Debugbefehle ausgeben, beachten Sie bitte Wichtige Informationen über Debug-Befehle.

- show frame-relais pvc

- Frame-Relay-Karte anzeigen

- Show Queuing Priority

- Debug-Priorität

Die unten dargestellte Ausgabe ist das Ergebnis der Eingabe dieser Befehle auf den Geräten, die wir in dieser Beispielkonfiguration verwenden.

scharf

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          4            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 106           output pkts 15           in bytes 6801

out bytes 1560           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

pvc create time 00:29:22, last time pvc status changed 00:20:37

Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)

DLCI 190 (NORMAL), DLCI 200 (LOW)

DLCI = 180, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 0             output pkts 51           in bytes 0

out bytes 2434           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

pvc create time 00:29:23, last time pvc status changed 00:14:48

DLCI = 190, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 0             output pkts 13           in bytes 0

out bytes 3653           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 13        out bcast bytes 3653

pvc create time 00:29:23, last time pvc status changed 00:14:28

DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 0             output pkts 42           in bytes 0

out bytes 2554           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 10        out bcast bytes 500

pvc create time 00:29:24, last time pvc status changed 00:14:09

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)

DLCI 190 (NORMAL), DLCI 200 (LOW)

Spicey#show queueing priority

Current priority queue configuration:

List   Queue  Args

1      high   protocol ip          list 102

1      medium protocol ip          tcp port telnet

1      normal protocol ip          tcp port ftp

1      low    protocol ip

Um die Prioritätswarteschlange zu überprüfen, verwenden Sie den Befehl debug priority.

Spicey#debug priority

Priority output queueing debugging is on

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms

Spicey#

*Mar  1 00:32:30.391: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.395: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.399: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:32:30.439: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.443: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.447: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:32:30.487: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.491: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.495: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:32:30.535: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.539: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.543: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:32:30.583: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.587: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.587: PQ: Serial0 output (Pk size/Q 104/0)Spicey#

Spicey#telnet 123.123.123.1

Trying 123.123.123.1 ... Open

User Access Verification

Password:

*Mar  1 00:32:59.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.451: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.451: PQ: Serial0 output (Pk size/Q 48/1)

*Mar  1 00:32:59.475: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.479: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.483: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.491: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:32:59.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.499: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.515: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.523: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.531: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:32:59.539: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.547: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.751: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.755: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.755: PQ: Serial0 output (Pk size/Q 44/1)

Password:

Andere IP-Datenverkehr durchläuft die Warteschlange.

Spicey#

*Mar  1 00:53:57.079: PQ: Serial0 output (Pk size/Q 13/0)

*Mar  1 00:53:58.851: PQ: Serial0: ip -> low

*Mar  1 00:53:58.907: PQ: Serial0: ip -> low

*Mar  1 00:53:58.907: PQ: Serial0 output (Pk size/Q 36/3)

*Mar  1 00:53:59.459: PQ: Serial0: ip -> low

*Mar  1 00:53:59.463: PQ: Serial0: ip -> low

*Mar  1 00:53:59.463: PQ: Serial0 output (Pk size/Q 50/3)

Spicey#

Pracht

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

input pkts 134           output pkts 119          in bytes 12029

out bytes 7801           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 18         out bcast bytes 1260

pvc create time 00:21:15, last time pvc status changed 00:21:15

Prasit#show frame-relay map

Serial1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), dynamic,

broadcast, status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48

Here is the debug output shown on Spicey when you use the command above to ping to Spicey from Prasit.

Spicey#

*Mar  1 00:33:26.755: PQ: Serial0 output (Pk size/Q 13/0)

*Mar  1 00:33:28.535: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.539: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.543: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.583: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.587: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.587: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.631: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.635: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.635: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.679: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.683: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.683: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.723: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.727: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.731: PQ: Serial0 output (Pk size/Q 104/0)

Prasit#telnet 124.124.124.1

Trying 124.124.124.1 ... Open

User Access Verification

Password:

Spicey>exit

[Connection to 124.124.124.1 closed by foreign host]

Prasit#

Hier ist die Debug-Ausgabe, die auf Spicey angezeigt wird, wenn Sie den oben angegebenen Befehl für telnet bis Spicey von Prasit verwenden.

Spicey#

*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.503: PQ: Serial0 output (Pk size/Q 48/1)

*Mar  1 00:33:54.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.531: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.531: PQ: Serial0 output (Pk size/Q 56/1)

*Mar  1 00:33:54.547: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.551: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.555: PQ: Serial0 output (Pk size/Q 86/1)

*Mar  1 00:33:54.559: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.563: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.563: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:33:54.571: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.575: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.575: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:33:54.779: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.783: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.783: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:33:56.755: PQ: Serial0 output (Pk size/Q 13/0)

*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.147: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.451: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.903: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:33:59.491: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.495: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:33:59.711: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.715: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.715: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.955: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.127: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.331: PQ: Serial0 output (Pk size/Q 46/1)

*Mar  1 00:34:00.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.499: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.547: PQ: Serial0 output (Pk size/Q 44/1)

Frame Relay Broadcast-Warteschlange

Broadcast Queue ist eine wichtige Funktion, die in mittelgroßen bis großen IP- oder IPX-Netzwerken verwendet wird, in denen Routing- und Service Access Point (SAP)-Broadcasts über das Frame Relay-Netzwerk übertragen werden müssen. Die Broadcast-Warteschlange wird unabhängig von der normalen Schnittstellenwarteschlange verwaltet, verfügt über eigene Puffer und hat eine konfigurierbare Größe und eine konfigurierbare Service-Rate. Diese Broadcast-Warteschlange wird wegen der Timing-Empfindlichkeiten nicht zum Bridging von Spanning-Tree-Updates (BPDUs) verwendet. Diese Pakete durchlaufen die normalen Warteschlangen. Der Schnittstellenbefehl zum Aktivieren der Broadcast-Warteschlange lautet wie folgt:

Frame-Relay Broadcast-Queue Größe Byte-Rate Paketrate

Eine Broadcast-Warteschlange erhält einen Grenzwert für die maximale Übertragungsrate (Durchsatz), der in Byte pro Sekunde und in Paketen pro Sekunde gemessen wird. Die Warteschlange wird gewartet, um sicherzustellen, dass nur diese maximale Anzahl bereitgestellt wird. Die Broadcast-Warteschlange hat Priorität bei der Übertragung mit einer Geschwindigkeit, die unter dem konfigurierten Höchstwert liegt, und verfügt daher über eine garantierte Mindestbandbreitenzuweisung. Die beiden Übertragungsratenbeschränkungen sollen eine Überflutung der Schnittstelle mit Sendungen verhindern. Der tatsächliche Grenzwert in einer Sekunde ist der erste Grenzwert, der erreicht wird. Aufgrund der Beschränkung der Übertragungsrate ist eine zusätzliche Pufferung zum Speichern von Broadcast-Paketen erforderlich. Die Broadcast-Warteschlange kann so konfiguriert werden, dass eine große Anzahl von Broadcast-Paketen gespeichert werden kann. Die Warteschlangengröße sollte so festgelegt werden, dass ein Verlust von Broadcast-Routing-Update-Paketen vermieden wird. Die genaue Größe hängt vom verwendeten Protokoll und der Anzahl der für jede Aktualisierung erforderlichen Pakete ab. Um sicher zu sein, muss die Warteschlangengröße so festgelegt werden, dass ein vollständiges Routing-Update jedes Protokolls und für jede Datenverbindung-Verbindungskennung (Data-Link Connection Identifier, DLCI) gespeichert werden kann. In der Regel beginnen Sie mit 20 Paketen pro DLCI. Die Byterate muss kleiner als die beiden folgenden Werte sein:

- N/4-fache minimale Remote-Zugriffsrate (gemessen in Byte pro Sekunde), wobei N die Anzahl der DLCIs ist, auf die der Broadcast repliziert werden muss

- 1/4 der lokalen Zugriffsrate (gemessen in Byte pro Sekunde)

Die Paketrate ist nicht kritisch, wenn die Byterate konservativ festgelegt wird. Im Allgemeinen sollte die Paketrate unter der Annahme von 250-Byte-Paketen festgelegt werden. Die Standardwerte für die seriellen Schnittstellen sind 64 Warteschlangengrößen, 256.000 Byte pro Sekunde (2.048.000 Bit/s) und 36 pps. Die Standardwerte für die High Speed Serial Interfaces (HSSI) sind 256 Warteschlangengrößen, 1.024.000 Byte pro Sekunde (8.192.000 Bit/s) und 144 pps.

Traffic Shaping

Traffic Shaping verwendet einen Mechanismus zur Ratenkontrolle, der als Token-Bucket-Filter bezeichnet wird. Dieser Token-Bucket-Filter ist wie folgt eingestellt:

Exzessiver Burst plus Committed Burst (Bc + Be) = Höchstgeschwindigkeit für den Virtual Circuit (VC)

Datenverkehr oberhalb der Höchstgeschwindigkeit wird in einer Traffic Shaping-Warteschlange gepuffert, die der Größe der gewichteten Fair Queue (WFQ) entspricht. Der Token-Bucket-Filter filtert keinen Datenverkehr, sondern steuert die Geschwindigkeit, mit der der Datenverkehr an die ausgehende Schnittstelle gesendet wird. Weitere Informationen zu Token-Bucket-Filtern finden Sie unter Übersicht über das Policing und Shaping.

Dieses Dokument bietet einen Überblick über das allgemeine Traffic Shaping und Frame Relay Traffic Shaping.

Parameter für die Verkehrssteuerung

Folgende Traffic Shaping-Parameter können verwendet werden:

- CIR = Committed Information Rate (= mittlere Zeit)

- EIR = Überinformationsrate

- TB = Tokenbucket (= Bc + Be)

- Bc = bestätigte Burst-Größe (= anhaltende Burst-Größe)

- BE = übermäßige Burst-Größe

- DE = Berechtigung für Verwerfen

- Tc = Messintervall

- AR = Zugriffsrate entsprechend der Geschwindigkeit der physischen Schnittstelle (bei Verwendung eines T1 beträgt die AR-Rate also ungefähr 1,5 Mbit/s).

Sehen wir uns einige dieser Parameter genauer an:

Zugriffsrate (AR)

Die maximale Anzahl von Bits pro Sekunde, die eine Endstation in das Netzwerk übertragen kann, wird durch die Zugriffsrate der Benutzernetzwerkschnittstelle begrenzt. Die Leitungsgeschwindigkeit der Benutzernetzwerkverbindung schränkt die Zugriffsrate ein. Sie können dies in Ihrem Abonnement beim Service Provider feststellen.

Committed Burst Size (Bc)

Die maximal zugesicherte Datenmenge, die Sie dem Netzwerk anbieten können, ist als Bc definiert. Bc ist ein Maß für die Datenmenge, für die das Netzwerk unter normalen Bedingungen die Nachrichtenübermittlung garantiert. Sie wird während der Committed Rate Tc gemessen.

Überschreitung der Burst-Größe (BE)

Die Anzahl nicht verpflichtender Bits (außerhalb von CIR), die noch vom Frame-Relay-Switch akzeptiert werden, aber als verworfen gekennzeichnet sind (DE).

Die Token-Bucket ist ein "virtueller" Puffer. Es enthält eine Reihe von Token, mit denen Sie eine begrenzte Anzahl von Daten pro Zeitintervall senden können. Die Token-Eimer ist mit Bc-Bits pro Tc gefüllt. Die maximale Größe des Eckels ist Bc + Be. Wenn die Be sehr groß ist und bei T0 der Eimer mit Bc + Be Token gefüllt ist, können Sie Bc + Be Bits mit der Zugriffsrate senden. Dies ist nicht durch Tc beschränkt, sondern durch die Zeit, die es dauert, die Be zu senden. Dies hängt von der Zugriffsrate ab.

Committed Information Rate (CIR)

Die CIR ist die zulässige Datenmenge, die das Netzwerk unter normalen Bedingungen übertragen muss. Die Rate wird über eine Zeitspanne von Tc gemittelt. Der CIR wird auch als Mindestdurchsatz bezeichnet. Bc und Be werden in Bits, Tc in Sekunden und die Zugriffsrate und CIR in Bits pro Sekunde ausgedrückt.

Bc, Be, Tc und CIR werden pro DLCI (Data-Link Connection Identifier) definiert. Aus diesem Grund steuert der Token-Bucket-Filter die Rate pro DLCI. Die Zugriffsrate gilt für jede Benutzerschnittstelle. Für Bc können die Ein- und Ausgangswerte Be und CIR unterschieden werden. Wenn die Verbindung symmetrisch ist, sind die Werte in beide Richtungen identisch. Für permanente virtuelle Verbindungen definieren wir zur Abonnementzeit eingehende und ausgehende Bc, Be und CIR.

- Peak = maximale Geschwindigkeit von DLCI. Die Bandbreite für diesen speziellen DLCI.

- Tc = Bc/CIR

- Peak = CIR + BE/Tc = CIR (1 + BE/Bc)

Wenn das Tc eine Sekunde beträgt, dann:

- Peak = CIR + BE = Bc + Be

- EIR = BE

Im Beispiel, das wir hier verwenden, sendet der Router Datenverkehr zwischen 48 Kbit/s und 32 Kbit/s, abhängig von der Überlastung im Netzwerk. Netzwerke können Frames über Bc mit DE markieren, verfügen aber über genügend freie Kapazität, um den Frame zu transportieren. Umgekehrt ist auch möglich: sie können eine begrenzte Kapazität haben, aber übermäßige Frames sofort verwerfen. Netzwerke können Frames oberhalb von Bc + Be mit DE markieren und sie möglicherweise transportieren oder die Frames gemäß der Spezifikation ITU-T I.370 der International Telecommunication Union Telecommunication Standardization Sector verwerfen. Traffic Shaping markiert den Datenverkehr basierend auf getaggten BECN-Paketen (Backward Explicit Congestion Notification) aus dem Switch-Netzwerk. Wenn Sie 50 % BECN erhalten, reduziert der Router den Datenverkehr um ein Achtel der aktuell übertragenen Bandbreite für diesen DLCI.

Beispiel

Die Übertragungsgeschwindigkeit beträgt 42 KB. Der Router senkt die Geschwindigkeit auf 42 minus 42 dividiert durch 8 (42 - 42/8) und macht 36,75 KB. Wenn die Überlastung nach der Änderung abnimmt, reduziert der Router den Datenverkehr weiter, wodurch auf ein Achtel der aktuell übertragenen Bandbreite gesunken ist. Der Datenverkehr wird reduziert, bis er den konfigurierten CIR-Wert erreicht. Die Geschwindigkeit kann jedoch unter die CIR fallen, wenn noch BECNs angezeigt werden. Sie können eine untere Grenze angeben, z. B. CIR/2. Das Netzwerk ist nicht mehr überlastet, wenn alle aus dem Netzwerk empfangenen Frames für einen bestimmten Zeitraum kein BECN-Bit mehr haben. 200 ms ist der Standardwert für dieses Intervall.

Generisches Traffic Shaping

Die Generic Traffic Shaping-Funktion ist ein medien- und kapselungsunabhängiges Traffic Shaping-Tool, das bei Überlastungen in der Cloud, auf der Verbindung oder am empfangenden Endpunkt-Router den ausgehenden Datenverkehr reduziert. Sie können auf Schnittstellen oder Subschnittstellen innerhalb eines Routers festgelegt werden.

Generisches Traffic Shaping ist in folgenden Situationen hilfreich:

- Wenn Sie eine Netzwerktopologie haben, die aus einer Hochgeschwindigkeitsverbindung (T1-Leitungsgeschwindigkeit) in der Zentrale und aus Verbindungen mit niedriger Geschwindigkeit (weniger als 56 Kbit/s) in der Zweigstelle oder an den Telearbeiterstandorten besteht. Aufgrund der Geschwindigkeitsungleichheit besteht häufig ein Engpass für den Datenverkehr in Zweigstellen oder Telearbeitern, wenn der zentrale Standort Daten mit einer höheren Geschwindigkeit sendet, als die Remote-Standorte empfangen können. Dies führt zu Engpässen im letzten Switch vor dem Remote-Point-Router.

- Wenn Sie ein Service Provider sind, der Dienste mit untergeordneten Raten anbietet, können Sie mit dieser Funktion beispielsweise T1- oder T3-Verbindungen über den Router in kleinere Kanäle partitionieren. Sie können jede Subschnittstelle mit einer Tokenfilterbuchse konfigurieren, die dem von einem Kunden bestellten Service entspricht.

Bei Ihrer Frame Relay-Verbindung sollte der Router möglicherweise den Datenverkehr drosseln, anstatt ihn in das Netzwerk zu senden. Eine Drosselung des Datenverkehrs würde den Paketverlust in der Cloud des Service Providers begrenzen. Die BECN-basierte Drosselung (Throttling), die mit dieser Funktion bereitgestellt wird, ermöglicht es dem Router, den Datenverkehr dynamisch zu drosseln, indem er BECN-markierte Pakete aus dem Netzwerk empfängt. Diese Drosselung enthält Pakete in den Puffern des Routers, um den Datenfluss vom Router zum Frame-Relay-Netzwerk zu reduzieren. Der Router wirft den Datenverkehr auf Subschnittstellenbasis ab, und die Rate wird ebenfalls erhöht, wenn weniger Pakete mit BECN-Tags empfangen werden.

Befehle für generisches Traffic Shaping

Verwenden Sie den folgenden Befehl, um die Ratenkontrolle zu definieren:

Bitrate für Datenverkehrsform [Burst-Größe [übermäßige Burst-Größe] [Gruppenzugriffsliste]

Um BECNs auf einer Frame-Relay-Schnittstelle zu drosseln, verwenden Sie den folgenden Befehl:

Datenverkehrsformat-adaptiv [Bitrate]

Um eine Frame-Relay-Subschnittstelle zu konfigurieren, um die verfügbare Bandbreite beim Empfang von BECNs zu schätzen, verwenden Sie den Traffic-Shape-adaptiven Befehl.

Hinweis: Sie müssen Traffic Shaping auf der Schnittstelle mit dem Befehl Traffic-Shape Rate aktivieren, bevor Sie den Befehl Traffic-shape Adaptive verwenden können.

Die für den Befehl zur Datenverkehrsformate angegebene Bitrate ist die obere Grenze, und die Bitrate, die für den Befehl zur Anpassung der Datenverkehrsform angegeben wird, ist die untere Grenze (in der Regel der CIR-Wert), bei der der Datenverkehr bei Erhalt von BECNs durch die Schnittstelle geformt wird. Die tatsächlich verwendete Rate liegt normalerweise zwischen diesen beiden Raten. Sie sollten den Traffic-Shape Adaptive Befehl an beiden Enden der Verbindung konfigurieren, da das Gerät auch am Datenflussende konfiguriert wird, um FECN-Signale (Forward Explicit Congestion Notification) als BECNs wiederzugeben. Auf diese Weise kann der Router im Highspeed-Bereich Engpässe erkennen und sich an diese anpassen, selbst wenn der Datenverkehr in erster Linie in eine Richtung fließt.

Beispiel

Im folgenden Beispiel wird das Traffic-Shaping für die Schnittstelle 0.1 mit einer Obergrenze (normalerweise Bc + Be) von 128 Kbit/s und einer Untergrenze von 64 Kbit/s konfiguriert. Auf diese Weise kann die Verbindung je nach Überlastungsstufe zwischen 64 und 128 Kbit/s ausgeführt werden. Wenn die mittlere Seite eine Obergrenze von 256 Kbit/s hat, sollten Sie den niedrigsten oberen Grenzwert verwenden.

Auf diesen Routern haben wir Folgendes konfiguriert:

Central#

interface serial 0

encapsulation-frame-relay

interface serial 0.1

traffic-shape rate 128000

traffic-shape adaptive 64000

Client#

interface serial 0

encapsulation-frame-relay

interface serial 0.1

traffic-shape rate 128000

traffic-shape adaptive 64000

Frame-Relay-Traffic-Shaping

Mit generischem Traffic Shaping können Sie pro physischer Schnittstelle nur eine Peakrate (obere Grenze) und pro Subschnittstelle einen CIR-Wert (untere Grenze) angeben. Mit Frame Relay Traffic Shaping starten Sie einen Token-Bucket-Filter pro Virtual Circuit.

Die Traffic Shaping over Frame Relay-Funktion bietet folgende Funktionen:

- Durchsetzungsrate auf VC-Basis: Sie können eine Peakrate konfigurieren, um den ausgehenden Datenverkehr entweder auf die CIR oder einen anderen definierten Wert wie die Überinformationsrate (EIR) zu beschränken.

- Generalisierte BECN-Unterstützung pro VC: Der Router kann BECNs überwachen und Datenverkehr basierend auf BECN-markiertem Paketfeedback aus dem Frame Relay-Netzwerk drosseln.

- Priority Queuing (PQ), Custom Queuing (CQ) oder WFQ-Unterstützung auf VC-Ebene. Dies ermöglicht eine feinstufige Priorisierung und Warteschlangenverwaltung des Datenverkehrs und bietet Ihnen so mehr Kontrolle über den Datenverkehrsfluss auf einem einzelnen VC. Die Traffic Shaping over Frame Relay-Funktion gilt für PVCs (Frame Relay Permanent Virtual Circuits) und SVCs (Switched Virtual Circuits).

Beispiel

Interface Serial 0

no ip address

encapsulation frame-relay

frame-relay traffic-shaping

!

interface Serial0.100

ip address 1.1.1.1 255.255.255.252

frame-relay interface-dlci 100

frame-relay class fast

!

interface Serial0.200

ip address 1.1.1.5 255.255.255.252

frame-relay interface-dlci 200

frame-relay class slow

!

map-class frame-relay slow

frame-relay traffic-rate 64000 128000

!

map-class

frame-relay fast

frame-relay traffic-rate 16000 64000

!

In diesem Beispiel fügt der Router zwei Token-Buckets hinzu.

- Eine läuft zwischen 64.000 (CIR) und 12.8000 (Bc + Be).

- Die anderen liegen zwischen 16.000 (CIR) und 64.000 (Bc + Be).

Wenn eingehender Datenverkehr von Ethernet größer als der Token-Bucket-Filter ist, wird der Datenverkehr in der Frame-Relay-Datenverkehrswarteschlange gepuffert.

Ein Flussdiagramm, das den Paketfluss bei der Implementierung von Frame-Relay-Traffic-Shaping anzeigt, finden Sie im Flussdiagramm Frame-Relay-Traffic-Shaping. Um ein Flussdiagramm speziell mithilfe eines Token-Bucket-Filters anzuzeigen, lesen Sie Frame Relay Traffic Shaping - Token Bucket Flowchart.

Häufig verwendete Frame-Relay-Befehle

In diesem Abschnitt werden zwei Cisco IOS®-Befehle beschrieben, die besonders beim Konfigurieren von Frame-Relay hilfreich sind.

show frame-relais pvc

Dieser Befehl zeigt den Status des permanenten virtuellen Circuits (PVC), der Pakete ein- und ausgehend, der blockierten Pakete, wenn eine Überlastung auf der Leitung besteht, über FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification) usw. an. Eine detaillierte Beschreibung der Felder, die mit dem Befehl show frame-relais pvc verwendet werden, finden Sie hier.

Wenn Sie den Befehl show frame-relais pvc von Ihrem Cisco Gerät ausgeben, können Sie Output Interpreter (nur registrierte Kunden) zur Anzeige potenzieller Probleme und Fehlerbehebungen verwenden.

Sie können Output Interpreter (nur registrierte Kunden) zur Anzeige potenzieller Probleme und Fehlerbehebungen verwenden.

Nachfolgend finden Sie eine Beispielausgabe:

RouterA#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 666, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0

input pkts 0             output pkts 0            in bytes 0

out bytes 0              dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

pvc create time 0:03:18  last time pvc status changed 0:02:27

Num Pkts Switched 0

DLCI = 980, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 19            output pkts 87           in bytes 2787

out bytes 21005          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

pvc create time 1:17:47  last time pvc status changed 0:58:27

Das Feld DLCI-NUTZUNG enthält einen der folgenden Einträge:

- SWITCHED - Der Router oder der Zugriffsserver wird als Switch verwendet.

- LOCAL: Der Router oder der Zugriffsserver wird als Datenendgerät (Data Terminal Equipment, DTE) verwendet.

- UNUSED (Nicht VERWENDET): Auf die Data Link Connection Identifier (DLCI) wird nicht durch vom Benutzer eingegebene Konfigurationsbefehle auf dem Router verwiesen.

Die PVC kann vier Zustände haben. Diese werden im Feld PVC-STATUS wie folgt angezeigt:

- AKTIV - PVC ist betriebsbereit und funktioniert normal.

- INAKTIV - PVC ist nicht vollständig. Dies kann daran liegen, dass entweder keine Zuordnung (oder falsche Zuordnung) für den lokalen DLCI in der Frame-Relay-Cloud vorhanden ist oder das Remote-Ende der PVC gelöscht wird.

- DELETED - Entweder wird die Local Management Interface (LMI) nicht zwischen dem Router und dem lokalen Switch ausgetauscht, oder auf dem lokalen Switch ist kein DLCI konfiguriert.

- STATIC - Auf der Frame-Relay-Schnittstelle des Routers ist kein Keepalive konfiguriert.

Frame-Relay-Karte anzeigen

Verwenden Sie diesen Befehl, um festzustellen, ob Frame-Relay inverse-arp eine Remote-IP-Adresse zu einem lokalen DLCI aufgelöst hat. Dieser Befehl ist für Punkt-zu-Punkt-Subschnittstellen nicht aktiviert. Sie ist nur für Multipoint-Schnittstellen und -Subschnittstellen nützlich. Nachfolgend finden Sie eine Beispielausgabe:

RouterA#show frame-relay map

Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,

broadcast,, status defined, active

Eine detaillierte Beschreibung der Felder, die mit dem Befehl show frame-relais map verwendet werden, finden Sie in der Dokumentation zu Frame Relay Commands.

Wenn Sie von Ihrem Cisco Gerät die Ausgabe eines Befehls zur show frame-relais-Zuordnung erhalten, können Sie Output Interpreter (nur registrierte Kunden) zur Anzeige potenzieller Probleme und Fehlerbehebungen verwenden.

Sie können Output Interpreter (nur registrierte Kunden) zur Anzeige potenzieller Probleme und Fehlerbehebungen verwenden.

Frame-Relay und Bridging

In den Spanning-Tree-Protokollen, die von Cisco Bridges und Routern unterstützt werden, werden Konfigurationsmeldungen, die als Bridge Protocol Data Units (BPDUs) bezeichnet werden, verwendet. Diese Datenströme erfolgen in regelmäßigen Abständen zwischen den Brücken und stellen aufgrund ihrer häufigen Verwendung eine beträchtliche Menge an Datenverkehr dar. Es gibt zwei Arten von Spanning-Tree-Protokollen in transparentem Bridging. Der Algorithmus wurde erstmals von der Digital Equipment Corporation (DEC) eingeführt und anschließend vom IEEE 802 Committee überarbeitet und in der Spezifikation IEEE 802.1d veröffentlicht. Das DEC Spanning-Tree-Protokoll gibt BPDUs in Abständen von einer Sekunde aus, während das IEEE in Intervallen von zwei Sekunden BPDUs ausgibt. Jedes Paket umfasst 41 Byte, darunter eine BPDU-Nachricht mit 35 Byte Konfiguration, einen 2-Byte-Frame-Relay-Header, einen 2-Byte-Ethertype und einen 2-Byte-FCS.

Frame-Relay und Arbeitsspeicher

Der Speicherverbrauch für Frame-Relay-Ressourcen liegt in vier Bereichen:

1. Jede Data Link Connection Identifier (DLCI): 216 Byte

2. Jede Map-Anweisung: 96 Byte (oder dynamisch erstellte Zuordnung)

3. Jeder IDB (Hardware-Schnittstelle + Encap Frame Relay): 5040 + 8346 = 13.386 Byte

4. Jede IDB (Software-Subschnittstelle): 2260 Byte

Beispielsweise benötigt ein Cisco 2501 mit zwei Frame-Relay-Schnittstellen, jede mit vier Subschnittstellen, insgesamt acht DLCIs und zugehörigen Karten, Folgendes:

- Hardware-IDB mit 2 Schnittstellen x 13.386 = 26.772

- IDB mit 8 Subschnittstellen x 2260 = 18.080 Subschnittstellen

- 8 DLCIs x 216 = 1728 DLCIs

- 8 Kartenauszüge x 96 = 768 Kartenauszüge oder -dynamik

Die Gesamtanzahl beträgt 47.348 Byte RAM.

Hinweis: Die hier verwendeten Werte gelten für die Software Cisco IOS 11.1, 12.0 und 12.1.

Problembehandlung bei Frame Relay

Dieser Abschnitt enthält Teile einer möglichen Ausgabe der show interface-Befehle, die Sie bei der Fehlerbehebung möglicherweise erhalten. Auch die Ausgabe wird erläutert.

"Serial0 ist ausgefallen, Leitungsprotokoll ist ausgefallen."

Diese Ausgabe bedeutet, dass Sie ein Problem mit dem Kabel, der Kanal-Service-Einheit/Datendiensteinheit (CSU/DSU) oder der seriellen Leitung haben. Sie müssen das Problem mit einem Loopback-Test beheben. Führen Sie zum Durchführen eines Loopback-Tests die folgenden Schritte aus:

1. Legen Sie die Kapselung der seriellen Leitung auf HDLC und Keepalive auf 10 Sekunden fest. Führen Sie dazu die Befehle encapsulation hdlc und keepalive 10 unter der seriellen Schnittstelle aus.

2. Stellen Sie das CSU/DSU- oder Modem im Modus für die lokale Schleife auf. Wenn das Leitungsprotokoll verfügbar ist, wenn sich die CSU, DSU oder das Modem im lokalen Loopback-Modus befinden (dies wird durch die Meldung "line protocol is up (looped)" angezeigt), deutet dies darauf hin, dass das Problem außerhalb der lokalen CSU/DSU auftritt. Wenn die Statuszeile den Status nicht ändert, besteht möglicherweise ein Problem mit dem Router, dem Anschlusskabel, der CSU/DSU oder dem Modem. In den meisten Fällen liegt das Problem beim CSU/DSU oder Modem.

3. Pingen Sie Ihre eigene IP-Adresse mit dem Looped CSU/DSU oder Modem. Es darf keine Missstände geben. Ein erweiterter Ping von 0x0000 ist hilfreich bei der Lösung von Leitungsproblemen, da ein T1 oder E1 die Uhr von Daten ableitet und alle 8 Bit übergeben werden muss. B8ZS stellt dies sicher. Mithilfe eines Datenmusters mit hohem Nullwert kann ermittelt werden, ob die Übergänge auf den Trunk angemessen gezwungen werden. Ein Muster mit Schwerpunkten wird verwendet, um eine hohe Nulllast zu simulieren, falls ein Paar Dateninverter im Pfad vorhanden ist. Das abwechselnde Muster (0x555) stellt ein "typisches" Datenmuster dar. Wenn Ihre Pings fehlschlagen oder CRC-Fehler (zyklische Redundanzprüfungen) auftreten, wird ein Bitfehlerrate Tester (BERT) mit einem geeigneten Analyzer aus dem Telco benötigt.

4. Wenn Sie die Tests abgeschlossen haben, stellen Sie sicher, dass Sie die Kapselung wieder in Frame Relay zurücksetzen.

"Serial0 is up, line protocol is down" (Serial0 ist aktiv, Leitungsprotokoll ist ausgefallen)

Diese Leitung in der Ausgabe bedeutet, dass der Router ein Trägersignal von der CSU/DSU oder dem Modem erhält. Stellen Sie sicher, dass der Frame Relay-Provider den Port aktiviert hat und dass Ihre LMI-Einstellungen (Local Management Interface) übereinstimmen. Im Allgemeinen ignoriert der Frame-Relay-Switch die Datenendgeräte (DTE), es sei denn, er erkennt den richtigen LMI (verwenden Sie den Standardwert von Cisco für "cisco" LMI). Stellen Sie sicher, dass der Cisco Router Daten überträgt. Wahrscheinlich müssen Sie die Leitungsintegrität mithilfe von Schleifentests an verschiedenen Standorten überprüfen, beginnend mit der lokalen CSU und bis zum Wechsel zum Frame Relay des Providers. Weitere Informationen zum Durchführen eines Loopback-Tests finden Sie im vorherigen Abschnitt.

"Serial0 is up, line protocol is up" (Serial0 ist aktiv, Leitungsprotokoll ist aktiv)

Wenn Sie die Keepalives nicht deaktiviert haben, bedeutet diese Ausgabezeile, dass der Router mit dem Switch des Frame Relay-Anbieters spricht. Es sollte ein erfolgreicher Austausch von bidirektionalem Datenverkehr an der seriellen Schnittstelle ohne CRC-Fehler auftreten. Keepalives sind in Frame Relay erforderlich, da sie der Mechanismus sind, den der Router verwendet, um zu "erlernen", welche Datenverbindungs-Verbindungskennungen (Data-Link Connection Identifiers, DLCIs) der Anbieter bereitgestellt hat. Um den Austausch zu beobachten, können Sie Debug Frame-Relay lmi sicher in fast allen Situationen verwenden. Der Befehl debug frame-relais lmi generiert nur sehr wenige Nachrichten und kann Antworten auf Fragen wie folgende bereitstellen:

1. Spricht der Cisco Router mit dem lokalen Frame Relay-Switch?

2. Erhält der Router vom Frame Relay Provider vollständige LMI-Statusmeldungen für die abonnierten permanenten virtuellen Schaltungen (PVCs)?

3. Sind die DLCIs korrekt?

Hier sehen Sie einige Beispiele für Debug Frame-Relay-LMI-Ausgaben einer erfolgreichen Verbindung:

*Mar  1 01:17:58.763: Serial0(out): StEnq, myseq 92, yourseen 64, DTE up

*Mar  1 01:17:58.763:  datagramstart = 0x20007C, datagramsize = 14

*Mar  1 01:17:58.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5C 40

*Mar  1 01:17:58.767:

*Mar  1 01:17:58.815: Serial0(in): Status, myseq 92

*Mar  1 01:17:58.815: RT IE 1, length 1, type 1

*Mar  1 01:17:58.815: KA IE 3, length 2, yourseq 65, myseq 92

*Mar  1 01:18:08.763: Serial0(out): StEnq, myseq 93, yourseen 65, DTE up

*Mar  1 01:18:08.763:  datagramstart = 0x20007C, datagramsize = 14

*Mar  1 01:18:08.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5D 41

*Mar  1 01:18:08.767:

*Mar  1 01:18:08.815: Serial0(in): Status, myseq 93

*Mar  1 01:18:08.815: RT IE 1, length 1, type 1

*Mar  1 01:18:08.815: KA IE 3, length 2, yourseq 66, myseq 93

*Mar  1 01:18:18.763: Serial0(out): StEnq, myseq 94, yourseen 66, DTE up

*Mar  1 01:18:18.763:  datagramstart = 0x20007C, datagramsize = 14

*Mar  1 01:18:18.763:  FR encap = 0x0001030800 75 95 01 01 00 03 02 5E 42

*Mar  1 01:18:18.767:

*Mar  1 01:18:18.815: Serial0(in): Status, myseq 94

*Mar  1 01:18:18.815: RT IE 1, length 1, type 0

*Mar  1 01:18:18.819: KA IE 3, length 2, yourseq 67, myseq 94

*Mar  1 01:18:18.819: PVC IE 0x7 , length 0x3 , dlci 980, status 0x2

Beachten Sie den Status von "DLCI 980" in der obigen Ausgabe. Die möglichen Werte des Statusfelds werden nachfolgend erläutert:

1. 0x0-Added/Inaktiv bedeutet, dass der Switch über dieses DLCI programmiert ist, das DLCI jedoch aus irgendeinem Grund (z. B. wenn das andere Ende dieses PVC ausgefallen ist) nicht verwendet werden kann.

2. 0x2-Added/active bedeutet, dass der Frame Relay-Switch über das DLCI verfügt und alles betriebsbereit ist. Sie können den Datenverkehr mit diesem DLCI im Header senden.

3. 0x3-0x3 ist eine Kombination aus einem aktiven Status (0x2) und dem festgelegten RNR (oder r-bit) (0x1). Dies bedeutet, dass der Switch - oder eine bestimmte Warteschlange am Switch - für diese PVC gesichert wird und Sie die Übertragung beenden, falls Frames verschüttet werden.

4. 0x4-Deleted bedeutet, dass auf dem Frame-Relay-Switch dieses DLCI nicht für den Router programmiert ist. Aber es wurde irgendwann in der Vergangenheit programmiert. Dies kann auch darauf zurückzuführen sein, dass die DLCIs auf dem Router umgekehrt werden oder dass die PVC in der Frame Relay-Cloud vom Telco gelöscht wird. Die Konfiguration eines DLCI (den der Switch nicht hat) wird als 0x4 angezeigt.

5. 0x8 - Neu/inaktiv

6. 0x0a-Neu/aktiv

Eigenschaften von Frame-Relay

In diesem Abschnitt werden verschiedene Frame-Relay-Merkmale erläutert, die Sie beachten sollten.

IP Split Horizon Checks

Die IP Split Horizon-Überprüfung ist standardmäßig für Frame Relay-Kapselung deaktiviert, sodass Routing-Updates von derselben Schnittstelle an- und ausgehen. Die Router erhalten die DLCIs (Data-Link Connection Identifiers), die sie vom Frame-Relay-Switch über LMI-Updates (Local Management Interface) verwenden müssen. Die Router verwenden dann Inverse ARP für die Remote-IP-Adresse und erstellen eine Zuordnung der lokalen DLCIs und der zugehörigen Remote-IP-Adressen. Darüber hinaus können bestimmte Protokolle wie AppleTalk, transparente Bridging und IPX in teilweise vernetzten Netzwerken nicht unterstützt werden, da sie "Split Horizon" erfordern, bei dem ein über eine Schnittstelle empfangenes Paket nicht über dieselbe Schnittstelle übertragen werden kann, selbst wenn das Paket auf verschiedenen virtuellen Schaltkreisen empfangen und übertragen wird. Durch die Konfiguration von Frame-Relay-Subschnittstellen wird sichergestellt, dass eine einzige physische Schnittstelle als mehrere virtuelle Schnittstellen behandelt wird. Diese Funktion ermöglicht es uns, Split Horizon-Regeln zu überwinden. Pakete, die auf einer virtuellen Schnittstelle empfangen werden, können nun auch über dieselbe physische Schnittstelle an eine andere virtuelle Schnittstelle weitergeleitet werden.

Pingen Sie Ihre eigene IP-Adresse auf einem Multipoint-Frame-Relay.

Sie können Ihre eigene IP-Adresse nicht an eine Multipoint Frame Relay-Schnittstelle senden. Dies liegt daran, dass Frame-Relay-Multipoint-Schnittstellen (Sub-Schnittstellen) keine Broadcast-Schnittstellen sind (im Gegensatz zu Ethernet- und Point-to-Point-Schnittstellen High-Level Data Link Control [HDLC]) und Frame-Relay-Point-to-Point-Subschnittstellen.

Darüber hinaus können Sie in einer Hub-and-Spoke-Konfiguration keine Ping-Verbindungen zwischen mehreren Spokes herstellen. Dies liegt daran, dass es keine Zuordnung für Ihre eigene IP-Adresse gibt (und keine davon über Inverse ARP gelernt wurde). Wenn Sie jedoch eine statische Karte (mit dem Befehl Frame-Relay Map) für Ihre eigene IP-Adresse (oder eine für das Remote-Spoke) konfigurieren, um den lokalen DLCI zu verwenden, können Sie dann Ping an Ihre Geräte senden.

aton#ping  3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

aton#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

aton(config)#interface serial 1

aton(config-if)#frame-relay map ip 3.1.3.3 160

aton(config-if)#

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

Serial1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

aton#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms

aton#

aton#show running-config

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay map ip 3.1.3.3 160

frame-relay interface-dlci 160

!

Die Schlüsselwortübertragung

Das Broadcast-Schlüsselwort bietet zwei Funktionen: Es leitet Broadcasts weiter, wenn Multicasting nicht aktiviert ist, und vereinfacht die Konfiguration von Open Shortest Path First (OSPF) für Nicht-Broadcast-Netzwerke, die Frame Relay verwenden.

Das Broadcast-Schlüsselwort ist möglicherweise auch für einige Routing-Protokolle erforderlich, z. B. AppleTalk, die von regelmäßigen Aktualisierungen der Routing-Tabellen abhängen, insbesondere dann, wenn der Router am Remote-Ende darauf wartet, dass ein Routing-Update-Paket eingeht, bevor die Route hinzugefügt wird.

OSPF erfordert die Auswahl eines designierten Routers und behandelt ein Multizugriffsnetzwerk (z. B. Frame Relay) ohne Broadcast-Funktion wie ein Broadcast-Netzwerk. In früheren Versionen war hierfür eine manuelle Zuweisung in der OSPF-Konfiguration mithilfe des Befehls Nachbarschnittstellen-Router erforderlich. Wenn der Befehl Frame-Relay Map in der Konfiguration mit dem Broadcast-Schlüsselwort enthalten ist und der Befehl ip ospf network (mit dem Broadcast-Schlüsselwort) konfiguriert ist, müssen keine Nachbarn manuell konfiguriert werden. OSPF wird nun automatisch als Broadcast-Netzwerk über das Frame Relay-Netzwerk ausgeführt. (Weitere Informationen finden Sie im Befehl ip ospf für die Netzwerkschnittstelle.)

Hinweis: Der OSPF-Broadcast-Mechanismus geht davon aus, dass IP-Class-D-Adressen niemals für regulären Datenverkehr über Frame Relay verwendet werden.

Beispiel

Im folgenden Beispiel wird die Ziel-IP-Adresse 172.16.123.1 DLCI 100 zugeordnet:

interface serial 0

frame-relay map IP 172.16.123.1 100 broadcast

OSPF verwendet DLCI 100 zum Senden von Updates.

Neukonfigurieren einer Subschnittstelle

Nachdem Sie einen bestimmten Subschnittstellentyp erstellt haben, können Sie ihn nur noch mit einem erneuten Laden ändern. Beispielsweise können Sie keine Multipoint-Subschnittstelle serial0.2 erstellen und dann auf Point-to-Point ändern. Um sie zu ändern, müssen Sie den Router entweder neu laden oder eine andere Subschnittstelle erstellen. So funktioniert der Frame-Relay-Code in der Cisco IOS®-Software.

DLCI-Einschränkungen

DLCI-Adressbereich

Etwa 1000 DLCIs können auf einer physischen Verbindung konfiguriert werden, wenn eine 10-Bit-Adresse angegeben wird. Da bestimmte DLCIs reserviert sind (anbieterabhängig), beträgt der Höchstwert etwa 1000. Der Bereich für ein Cisco LMI liegt zwischen 16 und 1007. Der angegebene Bereich für ANSI/ITU liegt zwischen 16 und 992. Dies sind die DLCIs, die Benutzerdaten übertragen.

Bei der Konfiguration von Frame-Relay-VCs auf Subschnittstellen müssen Sie jedoch eine praktische Grenze berücksichtigen, die als IDB-Grenzwert bezeichnet wird. Die Gesamtzahl der Schnittstellen und Subschnittstellen pro System ist durch die Anzahl der von Ihrer Cisco IOS-Version unterstützten IDBs (Interface Descriptor Blocks) begrenzt. Ein IDB ist ein Teil des Speichers, der Informationen über die Schnittstelle enthält, z. B. Zähler, Status der Schnittstelle usw. IOS unterhält eine IDB für jede auf einer Plattform vorhandene Schnittstelle und pflegt eine IDB für jede Subschnittstelle. Schnittstellen mit höherer Geschwindigkeit benötigen mehr Arbeitsspeicher als Schnittstellen mit geringerer Geschwindigkeit. Jede Plattform enthält unterschiedliche Mengen von maximalen IDBs, und diese Grenzwerte können sich mit jeder Cisco IOS-Version ändern.

Weitere Informationen finden Sie unter Maximale Anzahl von Schnittstellen und Subschnittstellen für Cisco IOS-Softwareplattformen: IDB-Grenzwerte.

LMI-Statusaktualisierung

Für das LMI-Protokoll ist es erforderlich, dass alle Statusberichte für permanente virtuelle Schaltungen (PVC) in ein einzelnes Paket passen und die Anzahl der DLCIs in der Regel auf weniger als 800 begrenzen, je nach Größe der maximalen Übertragungseinheit (Maximum Transmission Unit, MTU).

Die Standard-MTU für serielle Schnittstellen beträgt 1.500 Byte, sodass pro Schnittstelle maximal 296 DLCIs bereitgestellt werden. Sie können die MTU erhöhen, um eine größere Statusaktualisierung vom Frame Relay-Switch zu unterstützen. Wenn die Meldung für die vollständige Statusaktualisierung größer ist als die MTU der Schnittstelle, wird das Paket verworfen und der Zähler für den Schnittstellengiganten erhöht. Wenn Sie die MTU ändern, stellen Sie sicher, dass der gleiche Wert auf dem Remote-Router konfiguriert ist und in Netzwerkgeräte eingreift.

Bitte beachten Sie, dass diese Zahlen je nach LMI-Typ leicht variieren. Die maximale Anzahl von DLCIs pro Router (ohne Schnittstelle)-Plattformrichtlinie, die auf der Extrapolation empirischer Daten auf einer Cisco 7000 Router-Plattform basiert, ist nachfolgend aufgeführt:

- Cisco Serie 2500: 1 X T1/E1-Verbindung bei 60 DLCIs pro Schnittstelle = insgesamt 60

- Cisco Serie 4000: 1 X T1/E1-Verbindung bei 120 DLCIs pro Schnittstelle = insgesamt 120

- Cisco Serie 4500: 3 X T1/E1-Verbindungen bei 120 DLCIs pro Schnittstelle = 360 insgesamt

- Cisco Serie 4700: 4 X T1/E1-Verbindungen bei 120 DLCIs pro Schnittstelle = 480 insgesamt

- Cisco 7000: 4 X T1/E1/T3/E3-Verbindungen bei 120 DLCIs pro Schnittstelle = 480 insgesamt

- Cisco 7200: 5 X T1/E1/T3/E3-Verbindungen bei 120 DLCIs pro Schnittstelle = 600 insgesamt

- Cisco 7500: 6 X T1/E1/T3/E3-Verbindungen bei 120 DLCIs pro Schnittstelle = insgesamt 720

Hinweis: Diese Zahlen stellen lediglich Richtlinien dar und gehen davon aus, dass der gesamte Datenverkehr schnell umgeschaltet wird.

Weitere Überlegungen

Ein praktisches DLCI-Limit hängt auch davon ab, ob auf den VCs ein dynamisches oder statisches Routing-Protokoll ausgeführt wird. Dynamische Routing-Protokolle und andere Protokolle wie IPX SAP, die Datenbanktabellen austauschen, Hellos senden und Informationsmeldungen weiterleiten, die von der CPU gesehen und verarbeitet werden müssen. In der Regel können Sie mit statischen Routen eine größere Anzahl von VCs auf einer einzigen Frame-Relay-Schnittstelle konfigurieren.

IP/IPX/AT-Adresse

Wenn Sie Subschnittstellen verwenden, legen Sie keine IP-, IPX- oder AT-Adresse auf die Hauptschnittstelle. Weisen Sie den Subschnittstellen DLCIs zu, bevor Sie die Hauptoberfläche aktivieren, um sicherzustellen, dass das Frame-Relay in der Umkehrarp-Funktion ordnungsgemäß funktioniert. Falls eine Fehlfunktion auftritt, gehen Sie wie folgt vor:

1. Deaktivieren Sie das Inverse Address Resolution Protocol (ARP) für diesen DLCI, indem Sie die Befehle no frame-relay inverse-arp ip 16 und clear frame-relais-inarp verwenden.

2. Korrigieren Sie Ihre Konfiguration.

3. Schalten Sie den Befehl frame-relais inverse-arp erneut ein.

RIP und IGRP

Routing Information Protocol (RIP)-Aktualisierungen werden alle 30 Sekunden aktualisiert. Jedes RIP-Paket kann bis zu 25 Routingeinträge mit einer Gesamtgröße von 536 Byte enthalten. 36 Byte dieser Summe sind Headerinformationen, und jeder Routeneintrag beträgt 20 Byte. Wenn Sie also 1000 Routen über eine Frame-Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, ergibt sich aus 1 MB Routing-Update-Daten alle 30 Sekunden bzw. 285 Kbit/s an Bandbreite. Bei einer T1-Verbindung stellt diese Bandbreite 18,7 % der Bandbreite dar, wobei jede Aktualisierungsdauer 5,6 Sekunden beträgt. Dieser Overhead ist beträchtlich und grenzenlos akzeptabel, aber die zugesicherte Informationsrate (CIR) müsste sich in der Region der Zugriffsgeschwindigkeit befinden. Offensichtlich würde alles, was weniger als ein T1 wäre, zu viel Gemeinkosten verursachen. Beispiel:

- 1000/25 = 40 Pakete X 36 = 1440 Header-Byte

- 1000 x 20 Byte = 20.000 Byte Routeneinträge

- Insgesamt 21.440 Byte X 50 DLCIs = 1.072 MB RIP-Updates alle 30 Sekunden

- 1.072.000 Byte/30 Sek. x 8 Bit = 285 Kbit/s

Interior Gateway Routing Protocol (IGRP) aktualisiert den Fluss alle 90 Sekunden (dieses Intervall ist konfigurierbar). Jedes IGRP-Paket kann 104 Routeneinträge enthalten, d. h. insgesamt 1.492 Byte, davon 38 Headerinformationen, und jeder Routeneintrag beträgt 14 Byte. Wenn Sie 1000 Routen über eine Frame-Relay-Verbindung ankündigen, die mit 50 DLCIs konfiguriert wurde, beträgt die Anforderung ungefähr 720 KB Routing-Update-Daten alle 90 Sekunden oder 64 Kbit/s an Bandbreite. Bei einer T1-Verbindung würde diese Bandbreite 4,2 % der Bandbreite ausmachen, wobei jede Aktualisierungsdauer 3,7 Sekunden beträgt. Dieser Overhead ist ein akzeptabler Betrag:

- 1000/104 = 9 Pakete X 38 = 342 Header-Byte

- 1000 x 14 = 14.000 Byte Routeneinträge

- Gesamt = 14.342 Byte x 50 DLCIs = 717 KB IGRP-Aktualisierungen alle 90 Sekunden

- 717.000 Byte/90 x 8 Bit = 63,7 Kbit/s

Routing Table Maintenance Protocol (RTMP)-Routing-Updates erfolgen alle 10 Sekunden (dieses Intervall ist konfigurierbar). Jedes RTMP-Paket kann bis zu 94 erweiterte Routeneinträge enthalten, d. h. insgesamt 564 Byte, 23 Byte Headerinformationen und jeder Routeneintrag 6 Byte. Wenn Sie 1.000 AppleTalk-Netzwerke über eine Frame Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, ergibt sich ein RTMP-Update von ca. 313 KB alle 10 Sekunden oder ein Bandbreitenbedarf von 250 Kbit/s. Um einen akzeptablen Overhead von maximal 15 % zu erzielen, ist eine T1-Rate erforderlich. Beispiel:

- 1000/94 = 11 Pakete X 23 Byte = 253 Header Byte

- 1000 x 6 = 6000 Byte Routeneinträge

- Gesamt = 6253 X 50 DLCIs = 313 KB RTMP-Updates alle 10 Sekunden

- 313.000 / 10 Sek. X 8 Bit = 250 Kbit/s

IPX-RIP-Paketaktualisierungen erfolgen alle 60 Sekunden (dieses Intervall ist konfigurierbar). Jedes IPX-RIP-Paket kann bis zu 50 Routingeinträge für insgesamt 536 Byte, 38 Byte Headerinformationen und jeden Routeneintrag 8 Byte enthalten. Wenn Sie 1.000 IPX-Routen über eine Frame-Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, ergibt sich eine IPX-Aktualisierung von 536 KB alle 60 Sekunden oder eine Bandbreitennutzung von 58,4 Kbit/s. Um einen akzeptablen Overhead (maximal 15 Prozent) zu erzielen, ist eine Rate von 512 Kbit/s erforderlich. Beispiel:

- 1000/50 = 20 Pakete X 38 Byte = 760 Byte Header

- 1000 x 8 = 8000 Byte Routeneinträge

- Gesamt = 8760 X 50 DLCIs = 438.000 Byte IPX-Updates alle 60 Sekunden

- 438.000 / 60 Sek. x 8 Bit = 58,4 Kbit/s

IPX Service Access Point (SAP)-Paketaktualisierungen erfolgen alle 60 Sekunden (dieses Intervall ist konfigurierbar). Jedes IPX-SAP-Paket kann bis zu sieben Anzeigeneinträge für insgesamt 536 Byte, 38 Byte Header-Informationen und jeder Anzeigeneintrag 64 Byte enthalten. Wenn Sie 1000 IPX-Werbebotschaften über eine Frame Relay-Verbindung senden, die für 50 DLCIs konfiguriert ist, erhalten Sie am Ende 536 KB IPX-Updates alle 60 Sekunden oder 58,4 Kbit/s an Bandbreite. Um einen akzeptablen Overhead (maximal 15 %) zu erzielen, ist eine Rate von mehr als 2 Mbit/s erforderlich. Natürlich ist in diesem Szenario eine SAP-Filterung erforderlich. Im Vergleich zu allen anderen Protokollen, die in diesem Abschnitt erwähnt werden, benötigen IPX-SAP-Updates die meiste Bandbreite:

- 1000/7 = 143 Pakete X 38 Byte = 5434 Byte Header

- 1000 x 64 = 64.000 Byte Routeneinträge

- Gesamt = 69.434 X 50 DLCIs = 3.471.700 Byte IPX-Service-Werbung alle 60 Sekunden

- 3.471.700 / 60 Sek. x 8 Bit = 462 Kbit/s

Keepalive

In einigen Fällen muss der Keepalive auf dem Cisco Gerät etwas kürzer (etwa 8 Sekunden) eingestellt werden als der Keepalive auf dem Switch. Sie werden sehen, dass dies notwendig ist, wenn die Schnittstelle immer wieder hochfährt.

Serielle Schnittstellen

Serielle Schnittstellen, die standardmäßig Multipoint sind, sind Nicht-Broadcast-Medien, während Point-to-Point-Subschnittstellen übertragen werden. Wenn Sie statische Routen verwenden, können Sie entweder auf den nächsten Hop oder die serielle Subschnittstelle zeigen. Für Multipoint müssen Sie auf den nächsten Hop zeigen. Dieses Konzept ist bei OSPF over Frame Relay sehr wichtig. Der Router muss wissen, dass es sich um eine Broadcast-Schnittstelle für OSPF handelt.

OSPF und Multipoint

OSPF und Multipoint können sehr mühsam sein. Für OSPF ist ein designierter Router (DR) erforderlich. Wenn Sie PVCs verlieren, verlieren einige Router möglicherweise die Konnektivität und versuchen, ein DR zu werden, obwohl andere Router noch den alten DR sehen. Dies führt zu einer Fehlfunktion des OSPF-Prozesses.

Der mit OSPF verbundene Overhead ist nicht so offensichtlich und vorhersehbar wie bei herkömmlichen Distanzvektor-Routing-Protokollen. Die Unvorhersehbarkeit ergibt sich aus der Stabilität der OSPF-Netzwerkverbindungen. Wenn alle Adjacencies für einen Frame-Relay-Router stabil sind, fließen nur Nachbarhello-Pakete (Keepalives), was vergleichsweise viel weniger Overhead bedeutet als die Pakete, die mit einem Distanzvektorprotokoll (wie RIP und IGRP) verbunden sind. Wenn jedoch Routen (Adjacencies) instabil sind, kommt es zu Überflutungen im Verbindungsstatus und die Bandbreitennutzung kann schnell erfolgen. OSPF ist außerdem sehr prozessorintensiv, wenn der Dijkstra-Algorithmus ausgeführt wird, der für die Verarbeitung von Routen verwendet wird.

In früheren Versionen der Cisco IOS-Software musste bei der Konfiguration von OSPF über Multiaccess Non-Broadcast-Medien wie Frame Relay, X.25 und ATM besondere Vorsicht walten gelassen werden. Das OSPF-Protokoll betrachtet diese Medien wie alle anderen Übertragungsmedien wie Ethernet. Nonbroadcast Multiaccess (NBMA) Clouds sind in der Regel in einer Hub-and-Spoke-Topologie integriert. PVCs oder SVCs (Switched Virtual Circuits) sind in einem partiellen Mesh angeordnet, und die physische Topologie bietet nicht den Multizugriff, den OSPF für möglich hält. Bei seriellen Point-to-Point-Schnittstellen bildet OSPF immer eine Adjacency zwischen den Nachbarn. OSPF-Adjacencies tauschen Datenbankinformationen aus. Um die Anzahl der in einem bestimmten Segment ausgetauschten Informationen zu minimieren, wählt OSPF einen Router als DR und einen Router als Backup-designierten Router (BDR) für jedes Multizugriffssegment. Der BDR wird als Backup-Mechanismus für den Fall eines Ausfalls des DR gewählt.

Bei dieser Konfiguration wird davon ausgegangen, dass Router über einen zentralen Ansprechpartner für den Informationsaustausch verfügen. Die Wahl des DR stellte sich als Problem heraus, da der DR und der BDR eine vollständige physische Verbindung mit allen in der Cloud vorhandenen Routern benötigten. Aufgrund fehlender Broadcast-Funktionen mussten außerdem DR und BDR eine statische Liste aller anderen Router erstellen, die an die Cloud angeschlossen waren. Diese Konfiguration wird mit dem Befehl neighbor durchgeführt:

neighbor ip-address [Prioritätsnummer] [Polling-Intervallsekunden]

In späteren Versionen der Cisco IOS-Software können verschiedene Methoden eingesetzt werden, um die Komplikationen bei der Konfiguration von statischen Nachbarn zu vermeiden und zu verhindern, dass bestimmte Router in der Nicht-Broadcast-Cloud zu DRs oder BDRs werden. Welche Methode verwendet werden soll, hängt davon ab, ob es sich um ein neues Netzwerk oder ein vorhandenes Design handelt, das geändert werden muss.

Eine Subschnittstelle ist eine logische Methode zum Definieren einer Schnittstelle. Dieselbe physische Schnittstelle kann in mehrere logische Schnittstellen aufgeteilt werden, wobei jede Subschnittstelle als Punkt-zu-Punkt definiert wird. Dieses Szenario wurde ursprünglich erstellt, um Probleme, die durch Split Horizon über NBMA und vektorbasierte Routing-Protokolle verursacht werden, besser zu behandeln.

Eine Point-to-Point-Subschnittstelle verfügt über die Eigenschaften jeder physischen Point-to-Point-Schnittstelle. Was OSPF angeht, so wird immer eine Adjacency über eine Point-to-Point-Subschnittstelle gebildet, ohne dass DR oder BDR gewählt werden. OSPF betrachtet die Cloud als eine Reihe von Point-to-Point-Verbindungen und nicht als ein Multiaccess-Netzwerk. Der einzige Nachteil für Point-to-Point ist, dass jedes Segment zu einem anderen Subnetz gehört. Dieses Szenario ist möglicherweise nicht akzeptabel, da einige Administratoren bereits ein IP-Subnetz für die gesamte Cloud zugewiesen haben. Eine weitere Problemumgehung besteht in der Verwendung nicht nummerierter IP-Schnittstellen in der Cloud. Dieses Szenario kann auch für einige Administratoren, die das WAN anhand der IP-Adressen der seriellen Leitungen verwalten, ein Problem darstellen.

Quellen

1. International Telegraph and Telefone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT-Empfehlung Q.922, 19. April 1991.

2. American National Standard for Telecommunications - Integrated Services Digital Network - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18. Juni 1991.

3. Informationstechnologie - Telekommunikation und Informationsaustausch zwischen Systemen - Protokollerkennung im Netzwerkbereich, ISO/IEC TR 9577: 1990 (E) 1990-10-15.

4. International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std. 802.2-1989, 12-31.1989.

5. Internetworking Technology Overview, Oktober 1994, Cisco Systems

6. Finlayson, R. Mann, R., Mogul, J. und M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, Juni 1984.

7. Postel, J. und Reynolds, J., "Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, Februar 1988.

8. RFC 1490-Multiprotocol-Kapselung

9. RFC 1315-Frame Relay MIB

10. RFC 1293-Frame Relay Inverse ARP

11. RFC 1144-TCP/IP-Header-Komprimierung

12. Frame Relay Forum (FRF) 1.1-User-Network Interface (UNI)

13. FRF 2.1-Frame Relay Network-to-Network Interface (NNI)

14. FRF 3.1-Multiprotocol-Kapselung

15. FRF 4-SVCs

16. FRF 6-Frame Relay Service Customer Network Management (MIB)

17. Gang von vier LMI

18. Q.922 Anhang A

19. ANSI T1.617 Anhang D

20. ANSI T1.618, T1.606

21. ITU-T Q.933, Q.922

22. OSPF-Designleitfaden

23. Konfigurationshinweise für die erweiterte Implementierung von Enhanced IGRP

Zugehörige Informationen

- Weitere Informationen zu Frame-Relay-Befehlen

- Weitere Informationen zur Konfiguration von Frame Relay

- Weitere Informationen zu Befehlen zur Wählsicherung

- Weitere Informationen zu ISDN-Debug-Befehlen

- Weitere Informationen zu PPP-Debug-Befehlen

- Weitere Informationen zu ISDN-Switch-Typen, -Codes und -Werten

- Technischer Support und Dokumentation - Cisco Systems