Umfassende Anleitung zur Konfiguration und Fehlerbehebung von Frame Relay
Inhalt
Einleitung
Frame Relay ist ein dem Industriestandard entsprechendes Protokoll auf Switched Data Link Layer, das mehrere virtuelle Schaltungen unter Verwendung einer High-Level Data Link Control (HDLC)-Kapselung zwischen verbundenen 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 sie derzeit definiert sind, zwei Oktetts und enthalten einen 10-Bit-DLCI (Data Link Connection Identifier). In manchen Netzwerken können Q.922-Adressen optional auf drei oder vier Oktetts erhöht werden.
Die "Flag"-Felder begrenzen den Anfang und das Ende des Frames. Dem führenden Feld "Flag" folgen zwei Byte Adressinformationen. Zehn Bit dieser beiden Bytes bilden die tatsächliche Schaltkreis-ID (als DLCI bezeichnet, für Data Link Connection Identifier).
Der 10-Bit-DLCI-Wert ist das Herzstück des Frame-Relay-Headers. Identifiziert die logische Verbindung, die in den physischen Kanal gemultiplext wird. Im grundlegenden Adressierungsmodus (d. h., er wird nicht durch die Local Management Interface [LMI] erweitert) haben DLCIs eine 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.
Vorbereitungen
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Voraussetzungen
Weitere Informationen und Definitionen zu den in diesem Dokument verwendeten Begriffen finden Sie im Frame Relay Glossary.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.
Hintergrundtheorie
Frame Relay wurde ursprünglich als Protokoll für den Einsatz über ISDN-Schnittstellen konzipiert. Erste diesbezügliche Vorschläge wurden 1984 der International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (ehemals dem Beratenden Ausschuss für internationale Telegrafen und Telefone [CCITT]) vorgelegt. Die Arbeit an Frame Relay wurde auch im ANSI-akkreditierten T1S1-Normungsausschuss in den USA durchgeführt.
1990 gründeten Cisco Systems, StrataCom, Northern Telecom und Digital Equipment Corporation ein Konsortium, um die Entwicklung der Frame Relay-Technologie zu fokussieren und die Einführung von interoperablen Frame Relay-Produkten zu beschleunigen. Sie entwickelten eine Spezifikation, die mit dem grundlegenden Frame-Relay-Protokoll konform war, das in T1S1 und ITU-T besprochen wird, erweiterten diese jedoch um Funktionen, die zusätzliche Funktionen für komplexe Internetworking-Umgebungen bieten. Diese Frame Relay-Erweiterungen werden zusammen als LMI bezeichnet. Hierbei handelt es sich um die "cisco" LMI im Router im Gegensatz zu der "ansi" oder "q933a" LMI.
Frame Relay bietet eine Funktion zum Datenaustausch per Paketvermittlung, die über die Schnittstelle zwischen Benutzergeräten (wie Routern, Brücken, Host-Systemen) und Netzwerkgeräten (wie Switching-Knoten) verwendet wird. Benutzergeräte werden häufig als Datenendgeräte (DTE) bezeichnet, während Netzwerkgeräte, die mit DTE verbunden sind, häufig als Datenleitungs-Terminierungsgeräte (DCE) bezeichnet werden. Bei dem Netzwerk, das die Frame Relay-Schnittstelle bereitstellt, kann es sich entweder um ein von einem Betreiber bereitgestelltes öffentliches Netzwerk oder um ein Netzwerk aus privaten Geräten handeln, die für ein einzelnes Unternehmen bestimmt sind.
Frame Relay unterscheidet sich in Funktionalität und Format erheblich von X.25. Frame Relay ist ein Protokoll, das eine höhere Leistung und Effizienz ermöglicht.
Als Schnittstelle zwischen Benutzer- und Netzwerkgeräten ermöglicht Frame Relay das statistische Multiplexing vieler logischer Datenübertragungen (so genannter virtueller Schaltungen) über eine einzige physische Übertragungsverbindung. Im Gegensatz dazu verwenden Systeme nur TDM-Techniken (Time-Division-Multiplexing) zur Unterstützung mehrerer Datenströme. Das statistische Multiplexing von Frame Relay ermöglicht eine flexiblere und effizientere Nutzung der verfügbaren Bandbreite. Es kann ohne TDM-Techniken oder zusätzlich zu den von TDM-Systemen bereitgestellten Kanälen verwendet werden.
Ein weiteres wichtiges Merkmal von Frame Relay besteht darin, dass es die jüngsten Fortschritte bei der WAN-Übertragungstechnologie nutzt. Frühere WAN-Protokolle, z. B. X.25, wurden entwickelt, als analoge Übertragungssysteme und Kupfermedien vorherrschten. Diese Verbindungen sind wesentlich unzuverlässiger als die heute verfügbaren Glasfasermedien-/digitalen Übertragungsverbindungen. Über solche Verbindungen können Link-Layer-Protokolle auf zeitaufwendige Fehlerkorrekturalgorithmen verzichten, die dann auf höheren Protokollschichten ausgeführt werden müssen. Eine höhere Leistung und Effizienz ist daher ohne Einbußen bei der Datenintegrität möglich. Frame Relay wurde im Hinblick auf diesen Ansatz entwickelt. Er enthält einen CRC-Algorithmus (Cyclic Redundancy Check) zur Erkennung beschädigter Bits (damit die Daten verworfen werden können), jedoch keine Protokollmechanismen zur Korrektur fehlerhafter Daten (z. B. durch erneute Übertragung auf dieser Protokollebene).
Ein weiterer Unterschied zwischen Frame Relay und X.25 besteht darin, dass in Frame Relay keine explizite Flusssteuerung pro virtuellem Schaltkreis vorhanden ist. Da viele Protokolle höherer Layer ihre eigenen Flow Control-Algorithmen effektiv ausführen, ist der Bedarf an dieser Funktionalität auf der Verbindungsschicht gesunken. Frame Relay enthält daher keine expliziten Flusssteuerungsverfahren, die die auf höheren Ebenen duplizieren. Stattdessen werden einfache Überlastungsbenachrichtigungsmechanismen bereitgestellt, damit ein Netzwerk ein Benutzergerät darüber informieren kann, dass die Netzwerkressourcen sich in einem Überlastungszustand befinden. Diese Benachrichtigung kann Protokolle höherer Layer darüber informieren, dass eine Flusskontrolle erforderlich ist.
Konfigurieren von einfachem Frame-Relay
Sobald Sie zuverlässige Verbindungen zum lokalen Frame-Relay-Switch an beiden Enden des Permanent Virtual Circuit (PVC) hergestellt haben, ist es an der Zeit, mit der Planung der Frame-Relay-Konfiguration zu beginnen. In diesem ersten Beispiel ist der LMI-Typ (Local Management Interface) standardmäßig "cisco" LMI on 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-Prüfung ist für die Frame-Relay-Kapselung standardmäßig deaktiviert, sodass Routing-Updates über dieselbe Schnittstelle ein- und ausgehen. Die Router erfassen die erforderlichen DLCIs (Data Link Connection Identifiers) über LMI-Updates vom Frame Relay-Switch. Anschließend invertieren die Router ARP für die Remote-IP-Adresse und erstellen eine Zuordnung der lokalen DLCIs und der zugehörigen Remote-IP-Adressen.
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 "debug" und "show"
Bevor Sie Debug-Befehle ausgeben, lesen Sie bitte Wichtige Informationen zu Debug-Befehlen.
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
-
Frame-Relay-LMI anzeigen
-
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
Prasit
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 des Hub-and-Spoke-Frame-Relays
In diesem Beispiel ermittelt der Router, welche DLCIs (Data Link Connection Identifiers) vom Frame Relay-Switch verwendet werden, und weist sie der Hauptschnittstelle zu. Anschließend invertiert der Router ARP für die Remote-IP-Adresse.
Hinweis: Sie können Prasits serielle IP-Adresse von Aton aus nur pingen, wenn Sie Frame Relay-Zuordnungen an jedem Ende explizit hinzufügen. Wenn das Routing richtig konfiguriert ist, sollte der von den LANs ausgehende Datenverkehr kein Problem haben. 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 der Broadcast-IP-Datenverkehr standardmäßig über die Verbindung geleitet.
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
-
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
Prasit
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
Sie können keinen Ping von einer Station an eine andere Station in einer Hub-and-Spoke-Konfiguration unter Verwendung von Multipoint-Schnittstellen senden, da es keine Zuordnung der IP-Adressen der anderen Stationen gibt. Über das Inverse Address Resolution Protocol (IARP) wird nur die Adresse des Hubs abgerufen. Wenn Sie eine statische Zuordnung mithilfe des Befehls frame-relay map für die IP-Adresse einer Remote-Spoke konfigurieren, um den Local Data Link Connection Identifier (DLCI) zu verwenden, können Sie die Adressen anderer Spokes anpingen.
Konfigurationen
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
ping <Gerätename>
-
show running-config
Prasit
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 nehmen eine Transitivität in einem logischen Netzwerk an, d. h. wenn Station A mit Station B und Station B mit Station C kommunizieren kann, dann sollte Station A in der Lage sein, direkt mit Station C zu kommunizieren. Die Transitivität gilt für LANs, jedoch 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 transparentes Bridging, in teilweise vernetzten Netzwerken nicht unterstützt werden, da sie "Split Horizon" erfordern, bei dem ein auf einer Schnittstelle empfangenes Paket nicht über dieselbe Schnittstelle gesendet werden kann, selbst wenn das Paket empfangen und auf verschiedenen virtuellen Verbindungen übertragen wird.
Durch die Konfiguration von Frame Relay-Subschnittstellen wird sichergestellt, dass eine einzelne physische Schnittstelle als mehrere virtuelle Schnittstellen behandelt wird. Auf diese Weise können wir Split-Horizon-Regeln umgehen. Pakete, die auf einer virtuellen Schnittstelle empfangen werden, können nun von einer anderen virtuellen Schnittstelle weitergeleitet werden, selbst wenn sie auf derselben physischen Schnittstelle konfiguriert sind.
Subschnittstellen beheben 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 Punkt-zu-Punkt-)Subnetzwerke zu unterteilen. Jedem Subnetz wird eine eigene Netznummer zugewiesen und den Protokollen wird so angezeigt, als wäre es über eine separate Schnittstelle erreichbar. (Beachten Sie, dass Point-to-Point-Subschnittstellen für die Verwendung mit IP nicht nummeriert werden können, wodurch sich die Adressierungslast, die andernfalls entstehen könnte, verringert.)
Point-to-Point-Unterschnittstellen
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
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
Prasit
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 die dynamische Adressenauflösung an einem Remote-Standort. Jede Subschnittstelle wird mit einer individuellen Protokolladresse und Subnetzmaske versehen, und der Befehl interface-dlci ordnet der Subschnittstelle einen angegebenen Data-Link Connection Identifier (DLCI) zu. Adressen von Remote-Zielen für jede Punkt-zu-Punkt-Subschnittstelle werden nicht aufgelöst, da es sich um Punkt-zu-Punkt-Adressen handelt und Datenverkehr an den Peer am anderen Ende gesendet werden muss. Das Remote-Ende (Aton) verwendet für seine Zuordnung Inverse ARP, und der Haupt-Hub antwortet entsprechend mit der IP-Adresse der Subschnittstelle. Dies liegt daran, dass Frame Relay Inverse ARP für Multipoint-Schnittstellen standardmäßig aktiviert ist.
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
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
Prasit
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 von dynamischer und statischer Zuordnung für Multipoint-Subschnittstellen
Bei der dynamischen Adresszuordnung wird Frame Relay Inverse ARP verwendet, um die nächste Hop-Protokolladresse für eine bestimmte Verbindung anzufordern, wenn ein DLCI (Data Link Connection Identifier) angegeben ist. Antworten auf Inverse ARP-Anforderungen werden in eine AdressenDLCI-Zuordnungstabelle auf dem Router oder Zugriffsserver eingegeben; die Tabelle wird dann verwendet, um die Adresse des nächsten Hop-Protokolls oder den 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 unterstützten Protokolle aktiviert, kann jedoch für bestimmte Protokoll-DLCI-Paare deaktiviert werden. Daher können Sie für einige Protokolle eine dynamische Zuordnung und für andere Protokolle desselben DLCI eine statische Zuordnung 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 verknüpft eine angegebene Next-Hop-Protokolladresse mit einem angegebenen DLCI. Durch die statische Zuordnung sind keine inversen ARP-Anforderungen mehr erforderlich. Wenn Sie eine statische Zuordnung bereitstellen, wird inverses ARP für das angegebene Protokoll im angegebenen DLCI automatisch deaktiviert. Sie müssen die statische Zuordnung verwenden, wenn der Router am anderen Ende entweder kein inverses ARP oder kein inverses ARP für ein bestimmtes Protokoll unterstützt, das Sie über Frame Relay verwenden möchten.
Netzwerkdiagramm
Es wurde bereits erläutert, wie ein Cisco Router für Inverse-ARP konfiguriert wird. Das folgende Beispiel zeigt, wie Sie statische Zuordnungen konfigurieren, falls Sie sie für Mehrpunktschnittstellen oder Subschnittstellen benötigen:
Konfigurationen
| 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 |
| Prasit |
|---|
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 "debug" und "show"
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
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
Prasit
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 Commands (Frame-Relay-Befehle).
Konfigurieren von IP Unnumbered Frame Relay
Wenn Sie nicht über den IP-Adressbereich für eine Vielzahl von Subschnittstellen verfügen, können Sie für jede Subschnittstelle die Option IP unnumbered (nicht nummerierte IP) verwenden. In diesem Fall müssen Sie statische Routen oder dynamisches Routing verwenden, damit der Datenverkehr wie gewohnt geroutet wird, und Sie müssen Punkt-zu-Punkt-Subschnittstellen verwenden.
Netzwerkdiagramm
Das folgende Beispiel veranschaulicht dies:
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
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
Prasit
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 des Frame-Relay-Backups
Frame-Relay-Backup über ISDN
Sie können Frame Relay-Schaltungen mithilfe von ISDN sichern. Es gibt mehrere Möglichkeiten, dies zu tun. Die erste und wahrscheinlich beste Lösung besteht darin, variable statische Routen zu verwenden, die den Datenverkehr an eine BRI-IP-Adresse (Basic Rate Interface) weiterleiten und eine geeignete Routing-Metrik verwenden. Sie können eine Backup-Schnittstelle auch auf der Hauptschnittstelle oder auf der Basis eines Data Link Connection Identifier (DLCI) verwenden. Die Sicherung der Hauptschnittstelle ist nicht unbedingt hilfreich, da permanente virtuelle Schaltkreise (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 |
|---|
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 ! |
show-Befehle
Verwenden Sie die folgenden debug-Befehle, um zu überprüfen, ob ISDN funktioniert. Bevor Sie Debug-Befehle ausgeben, lesen Sie bitte Wichtige Informationen zu Debug-Befehlen.
-
debug isdn q931
-
debug ppp neg
-
debug ppp auth
Versuchen Sie, einen ISDN-Anruf von der anrufenden zur zentralen Seite ohne die Sicherungsbefehle zu tätigen. Wenn dies erfolgreich ist, fügen Sie die Sicherungsbefehle der aufrufenden Seite hinzu.
Hinweis: Verwenden Sie zum Testen der Sicherung nicht den Befehl shutdown an der seriellen Schnittstelle, sondern emulieren Sie ein echtes Problem mit einer seriellen Leitung, indem Sie das Kabel aus der seriellen Leitung ziehen.
Konfiguration pro DCLI-Sicherung
Nehmen wir nun an, dass Spicey die zentrale Seite ist und dass Prasit die Seite ist, die Verbindungen zur zentralen Seite herstellt (Spicey). Achten Sie darauf, dass Sie die Sicherungsbefehle nur der Seite hinzufügen, die die zentrale Seite aufruft.
Hinweis: Die Backup-Last wird auf Subschnittstellen nicht unterstützt. Da der Datenverkehr an Subschnittstellen nicht nachverfolgt wird, wird keine Last berechnet.
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
show ip route
-
ISDN-Verlauf anzeigen
-
ISDN-Status anzeigen
-
Schnittstelle bri 0 anzeigen
-
ISDN aktiv anzeigen
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
Prasit
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 fällt aus.
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 da.
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 Wählprofilen
Das folgende Beispiel zeigt eine DLCI-Backup-Konfiguration für Hub and Spoke. Die Spoke-Router rufen den Hub-Router an. Wie Sie sehen, erlauben wir nur einen B-Kanal pro Seite, indem wir die Option "max-link" im Dialer-Pool auf der Hub-Seite verwenden.
Hinweis: Backup-Last wird nicht auf Subschnittstellen unterstützt. Da der Datenverkehr an Subschnittstellen nicht nachverfolgt wird, wird keine Last berechnet.
Netzwerkdiagramm
Konfigurationen
| 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 |
| Prasit |
|---|
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 |
show-Befehle
-
Frame-Relay-Map anzeigen
-
show ip route
-
Rahmenübersicht anzeigen
-
Frame-Relay-PVC anzeigen
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#
Seriell 1 fällt aus.
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#
Seriell 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 der anrufenden Seite 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
Prasit
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#
Seriell 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#
Seriell 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 des Frame-Relay-Switching
Frame-Relay-Switching ist ein Mittel zum Vermitteln von Paketen auf der Grundlage des Data-Link Connection Identifier (DLCI). Wir können dies als Frame-Relay betrachten, das einer MAC-Adresse (Media Access Control) entspricht. Für das Switching konfigurieren Sie Ihren Cisco Router oder Zugriffsserver in einem Frame Relay-Netzwerk. Ein Frame-Relay-Netzwerk besteht aus zwei Teilen:
-
Frame Relay Data Terminal Equipment (DTE) - der Router oder der Zugriffsserver.
-
DCE-Switch (Frame Relay Data Circuit-Terminating Equipment)
Hinweis: In Cisco IOS Software, Version 12.1(2)T und höher, wurde der Frame-Route-Befehl 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. Wir haben sie wie folgt verbunden:
-
Prasit seriell 1 (s1) DTE ist mit Amerika seriell 1/4 (s1/4) DCE verbunden.
-
Spicey Serial 0 (s0) DTE ist mit Amerika Serial 1/5 (s1/5) DCE verbunden.
-
Aton seriell 1 (s1) DTE ist mit Amerika seriell 3/4 (s3/4) DCE verbunden.
Netzwerkdiagramm
Dieses Dokument basiert auf der folgenden Konfiguration:
Konfigurationen
| 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 |
| Prasit |
|---|
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 ! |
show-Befehle
Verwenden Sie die folgenden show-Befehle, um zu testen, ob Ihr Netzwerk ordnungsgemäß funktioniert:
-
Frame-Relay-Map anzeigen
-
Frame-Relay-PVC anzeigen
Die unten gezeigte 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
Prasit
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 DLCI-Priorisierung für Frame-Relay
Bei der Priorisierung der Data Link Connection Identifier (DLCI) werden unterschiedliche Datenverkehrstypen auf separaten DLCIs platziert, sodass ein Frame-Relay-Netzwerk für jeden Datenverkehrstyp eine unterschiedliche Datenverkehrsrate bereitstellen kann. Er kann zusammen mit benutzerdefinierten Warteschlangen oder Prioritätswarteschlangen 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 (wie die Stratacom Internetwork Packet Exchange [IPX]-, IGX- und BPX- oder AXIS-Switches) tatsächlich eine 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ärer DLCI ausfällt, geht der Datenverkehr verloren, der nur für diese Warteschlange bestimmt ist.
-
Wenn der primäre DLCI ausfällt, fällt die Subschnittstelle aus, und der gesamte Datenverkehr geht verloren.
Netzwerkdiagramm
Für diese Konfiguration sind vier DLCIs für die Seite erforderlich, für die die DLCI-Priorisierung verwendet wird. In diesem Beispiel haben wir Spicey wie folgt für die Prioritätswarteschlange konfiguriert:
-
Der Ping befindet sich in der Warteschlange mit hoher Priorität.
-
Telnet befindet sich in der Warteschlange mit mittlerer Priorität.
-
Das File Transfer Protocol (FTP) befindet sich in der Warteschlange mit normaler Priorität.
-
Der gesamte andere IP-Datenverkehr befindet sich in der Warteschlange mit niedriger Priorität.
Hinweis: Stellen Sie sicher, dass die DLCIs entsprechend der Prioritätsliste konfiguriert sind, da das System andernfalls nicht die richtige Warteschlange verwendet.
Konfigurationen
| 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 |
| Prasit |
|---|
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 "debug" und "show"
Verwenden Sie die folgenden Befehle zum Anzeigen und Debuggen, um zu testen, ob das Netzwerk ordnungsgemäß funktioniert. Bevor Sie Debug-Befehle ausgeben, lesen Sie bitte Wichtige Informationen zu Debug-Befehlen.
-
Frame-Relay-PVC anzeigen
-
Frame-Relay-Map anzeigen
-
Warteschlangenpriorität anzeigen
-
Debug-Priorität
Die unten gezeigte 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
Verwenden Sie den Befehl debug priority, um die Prioritätswarteschlange zu überprüfen.
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:
Der restliche IP-Datenverkehr durchläuft die niedrige 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#
Prasit
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 obigen Befehl verwenden, um telnet zu Spicey von Prasit.
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
Eine Broadcast-Warteschlange 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 sowie über eine konfigurierbare Größe und Dienstrate. Diese Broadcast-Warteschlange wird aufgrund von Timing-Empfindlichkeiten nicht zum Bridging Spanning-Tree-Updates (BPDUs) verwendet. Diese Pakete durchlaufen die normalen Warteschlangen. Der Schnittstellenbefehl zum Aktivieren der Broadcast-Warteschlange lautet wie folgt:
Frame-Relay Broadcast-Warteschlangengröße Byte-Rate Paketrate
Eine Broadcast-Warteschlange erhält einen maximalen Grenzwert für die Übertragungsrate (Durchsatz), gemessen in Byte pro Sekunde und Paketen pro Sekunde. Die Warteschlange wird bedient, um sicherzustellen, dass nur dieses Maximum bereitgestellt wird. Die Broadcast-Warteschlange hat bei der Übertragung Priorität mit einer Rate, die unter dem konfigurierten Maximum liegt, und verfügt daher über eine garantierte minimale Bandbreitenzuweisung. Die beiden Übertragungsratengrenzwerte sollen eine Überflutung der Schnittstelle mit Broadcasts verhindern. Die tatsächliche Grenze in jeder Sekunde ist die erste Rate Grenze, die erreicht wird. Aufgrund der Beschränkung der Übertragungsrate ist eine zusätzliche Pufferung erforderlich, um Broadcast-Pakete zu speichern. Die Broadcast-Warteschlange kann so konfiguriert werden, dass sie eine große Anzahl an Broadcast-Paketen speichert. Die Warteschlangengröße sollte so eingestellt werden, dass keine Broadcast-Routing-Update-Pakete verloren gehen. Die genaue Größe hängt vom verwendeten Protokoll und der Anzahl der für jede Aktualisierung erforderlichen Pakete ab. Aus Sicherheitsgründen sollte die Warteschlangengröße so festgelegt werden, dass ein vollständiges Routing-Update für jedes Protokoll und jeden Data Link Connection Identifier (DLCI) gespeichert werden kann. Beginnen Sie in der Regel mit 20 Paketen pro DLCI. Die Byte-Rate muss kleiner als die beiden folgenden Werte sein:
-
Das N/4-Fache der minimalen 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 (in Byte pro Sekunde)
Die Paketrate ist nicht kritisch, wenn die Byte-Rate konservativ eingestellt wird. Im Allgemeinen sollte die Paketrate unter der Annahme von 250-Byte-Paketen festgelegt werden. Die Standardwerte für die seriellen Schnittstellen sind 64 Warteschlangen, 256.000 Byte pro Sekunde (2.048.000 Bit/s) und 36 pps. Die Standardwerte für die seriellen Hochgeschwindigkeitsschnittstellen (HSSI) sind 256 Warteschlangen, 1.024.000 Byte pro Sekunde (8.192.000 Bit/s) und 144 pps.
Traffic Shaping
Das Traffic-Shaping verwendet einen Durchsatzsteuerungsmechanismus, der als Token-Bucket-Filter bezeichnet wird. Dieser Token-Bucket-Filter wird wie folgt festgelegt:
überschüssiger Burst plus Committed Burst (Bc + Be) = maximale Geschwindigkeit für den Virtual Circuit (VC)
Datenverkehr, der die maximale Geschwindigkeit überschreitet, wird in einer Traffic Shaping-Warteschlange gepuffert, die der Größe der Weighted Fair Queue (WFQ) entspricht. Der Token-Bucket-Filter filtert keinen Datenverkehr, sondern steuert die Rate, mit der Datenverkehr über die ausgehende Schnittstelle gesendet wird. Weitere Informationen zu Token-Bucket-Filtern finden Sie unter Übersicht über Richtlinien und Shaping.
Dieses Dokument bietet eine Übersicht über generisches Traffic-Shaping und Frame-Relay-Traffic-Shaping.
Parameter für das Traffic Shaping
Wir können die folgenden Traffic Shaping-Parameter verwenden:
-
CIR = Committed Information Rate (= mittlere Zeit)
-
EIR = Informationsüberschuss
-
TB = Token Bucket (= BC + BE)
-
Bc = Committed Burst Size (= Sustained Burst Size)
-
BE = übermäßige Burst-Größe
-
DE = Rückwurfberechtigung
-
Tc = Messintervall
-
AR = Zugriffsrate, die der Rate der physischen Schnittstelle entspricht (bei Verwendung eines T1 beträgt der AR ca. 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 Benutzer-Netzwerkschnittstelle begrenzt. Die Leitungsgeschwindigkeit der Benutzer-Netzwerkverbindung begrenzt die Zugriffsrate. Sie können dies in Ihrem Abonnement des Dienstanbieters festlegen.
Committed Burst Size (BC)
Die maximale bereitgestellte Datenmenge, die Sie dem Netzwerk anbieten können, wird als Bc definiert. Bc ist ein Maß für die Datenmenge, für die das Netz die Nachrichtenübermittlung unter normalen Bedingungen gewährleistet. Sie wird während der Committed Rate Tc gemessen.
Übermäßige Burst-Größe (BE)
Die Anzahl der nicht zugesicherten Bits (außerhalb von CIR), die weiterhin vom Frame-Relay-Switch akzeptiert werden, aber als verworfen (DE) gekennzeichnet sind.
Der Token-Bucket ist ein virtueller Puffer. Es enthält eine Reihe von Token, sodass Sie eine begrenzte Datenmenge pro Zeitintervall senden können. Der Token-Eimer wird mit Bc-Bits pro Tc gefüllt. Die maximale Größe des Eimers ist Bc + Be. Wenn das 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 wird nicht durch Tc begrenzt, sondern durch die Zeit, die es braucht, um das Be zu senden. Dies ist eine Funktion der Zugriffsrate.
Committed Information Rate, CIR
Der CIR ist die zulässige Datenmenge, die das Netzwerk unter normalen Bedingungen übertragen darf. Die Rate wird über ein Zeitinkrement Tc gemittelt. Der CIR wird auch als akzeptabler 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 Data-Link Connection Identifier (DLCI) definiert. Aus diesem Grund steuert der Token-Bucket-Filter die Rate pro DLCI. Die Zugriffsrate gilt pro Benutzer-Netzwerkschnittstelle. Für Bc können Be- und CIR-Eingangs- und -Ausgangswerte unterschieden werden. Wenn die Verbindung symmetrisch ist, sind die Werte in beiden Richtungen gleich. Für permanente virtuelle Schaltungen definieren wir eingehende und ausgehende Bc, Be und CIR zur Abonnementzeit.
-
Peak = maximale DLCI-Geschwindigkeit. Die Bandbreite für diesen DLCI.
-
TC = BC/CIR
-
Spitze = CIR + BE/TC = CIR (1 + BE/BC)
Wenn die Tc-Zeit eine Sekunde beträgt:
-
Spitze = CIR + BE = BC + BE
-
EIR = BE
In diesem Beispiel sendet der Router je nach Netzwerküberlastung Datenverkehr zwischen 48 Kbit/s und 32 Kbit/s. Netzwerke können Frames oberhalb von Bc mit DE markieren, haben aber eine Menge Reservekapazität, um den Frame zu transportieren. Das Gegenteil ist auch möglich: Sie können eine begrenzte Kapazität haben, aber übermäßige Bilder sofort verwerfen. Netzwerke können Frames oberhalb von Bc + Be mit DE markieren und möglicherweise transportieren oder einfach die Frames, wie von der International Telecommunication Union Telecommunication Standardization Sector Specification ITU-T I.370 vorgeschlagen, verwerfen. Traffic Shaping drosselt den Datenverkehr auf Basis von BECN-markierten Paketen (Backward-Explicit Congestion Notification) aus dem Switch-Netzwerk. Wenn Sie 50 Prozent BECN empfangen, reduziert der Router den Datenverkehr um ein Achtel der aktuell übertragenen Bandbreite für den jeweiligen DLCI.
Beispiel
Die übertragene Geschwindigkeit beträgt 42 Kb. Der Router verringert die Geschwindigkeit auf 42 minus 42 dividiert durch 8 (42 - 42/8), was 36,75 KB entspricht. Wenn die Überlastung nach der Änderung abnimmt, reduziert der Router den Datenverkehr weiter und fällt auf ein Achtel der aktuell übertragenen Bandbreite. Der Datenverkehr wird reduziert, bis er den konfigurierten CIR-Wert erreicht. Die Geschwindigkeit kann jedoch unter CIR sinken, wenn wir immer noch BECNs sehen können. Sie können eine Untergrenze angeben, z. B. CIR/2. Das Netzwerk ist nicht mehr überlastet, wenn alle vom Netzwerk empfangenen Frames für ein bestimmtes Zeitintervall kein BECN-Bit mehr aufweisen. 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, mit dem der Fluss des ausgehenden Datenverkehrs reduziert werden kann, wenn es innerhalb der Cloud, auf der Verbindung oder am empfangenden Endpunkt-Router zu einer Überlastung kommt. Wir können sie an Schnittstellen oder Subschnittstellen innerhalb eines Routers einrichten.
Generisches Traffic Shaping ist in den folgenden Situationen nützlich:
-
Wenn Sie eine Netzwerktopologie haben, die aus einer Hochgeschwindigkeitsverbindung (T1-Leitungsgeschwindigkeit) in der Zentrale und aus langsamen Verbindungen (weniger als 56 Kbit/s) in der Außenstelle oder an den Telearbeiterstandorten besteht. Aufgrund der Geschwindigkeitsunterschiede kommt es häufig zu Engpässen beim Datenverkehr in der Außenstelle oder an Telearbeiterstandorten, wenn die Zentrale Daten schneller sendet, als die Außenstellen empfangen können. Dies führt zu einem Engpass beim letzten Switch vor dem Remote-Point-Router.
-
Wenn Sie ein Service Provider sind, der Subdatendienste anbietet, können Sie mit dieser Funktion den Router verwenden, um Ihre T1- oder T3-Verbindungen z. B. in kleinere Kanäle aufzuteilen. Sie können jede Subschnittstelle mit einem Tokenfilter-Bucket konfigurieren, der mit dem von einem Kunden bestellten Service übereinstimmt.
Bei Ihrer Frame-Relay-Verbindung sollte der Router den Datenverkehr ggf. drosseln, anstatt ihn an das Netzwerk zu senden. Eine Drosselung des Datenverkehrs würde den Paketverlust in der Cloud des Service Providers begrenzen. Die mit dieser Funktion bereitgestellte BECN-basierte Drosselungsfunktion ermöglicht Ihnen, den Datenverkehr auf Basis des Empfangs von mit BECN gekennzeichneten Paketen aus dem Netzwerk dynamisch zu drosseln. Diese Drosselung enthält Pakete in den Puffern des Routers, um den Datenfluss vom Router in das Frame-Relay-Netzwerk zu reduzieren. Der Router drosselt den Datenverkehr auf Subschnittstellenbasis, und die Rate wird ebenfalls erhöht, wenn weniger mit BECN markierte Pakete empfangen werden.
Befehle für generisches Traffic Shaping
Verwenden Sie den folgenden Befehl, um eine Ratensteuerung zu definieren:
traffic-shape rate bit-rate [Burstgröße [Übergröße des Burst-Bursts]] [Gruppenzugriffsliste]
Verwenden Sie den folgenden Befehl, um BECNs auf einer Frame Relay-Schnittstelle zu drosseln:
Verkehrsform adaptiv [Bitrate]
Um eine Frame Relay-Subschnittstelle zu konfigurieren, um die verfügbare Bandbreite beim Empfang von BECNs zu schätzen, verwenden Sie den adaptiven Befehl traffic-shape.
Hinweis: Sie müssen das Traffic-Shaping an der Schnittstelle mit dem Befehl traffic-shape rate aktivieren, bevor Sie den adaptiven Befehl traffic-shape verwenden können.
Die für den Befehl traffic-shape rate angegebene Bitrate ist die obere Grenze, und die für den adaptiven Befehl traffic-shape angegebene Bitrate ist die untere Grenze (in der Regel der CIR-Wert), an der der Datenverkehr geformt wird, wenn die Schnittstelle BECNs empfängt. Die tatsächliche Rate liegt normalerweise zwischen diesen beiden Raten. Sie sollten den adaptiven Befehl für die Datenverkehrsform an beiden Enden der Verbindung konfigurieren, da er das Gerät am Flow-Ende so konfiguriert, dass die FECN-Signale (Forward Explicit Congestion Notification) als BECNs angezeigt werden. So kann der Router mit hoher Geschwindigkeit Engpässe erkennen und sich daran anpassen, auch wenn der Datenverkehr in erster Linie in eine Richtung fließt.
Beispiel
Im folgenden Beispiel wird Traffic Shaping an Schnittstelle 0.1 konfiguriert. Die Obergrenze (in der Regel Bc + Be) liegt bei 128 Kbit/s, die Untergrenze bei 64 Kbit/s. Dadurch kann die Verbindung je nach Überlastungsgrad zwischen 64 und 128 Kbit/s verlaufen. Wenn die mittlere Seite eine Obergrenze von 256 Kbit/s hat, sollten Sie den niedrigsten oberen Grenzwert verwenden.
Für diese Router 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 nur eine Spitzengeschwindigkeit (Obergrenze) pro physischer Schnittstelle und einen CIR-Wert (Untergrenze) pro Subschnittstelle angeben. Mit Frame Relay Traffic Shaping starten Sie einen Token-Bucket-Filter pro Virtual Circuit.
Das Traffic-Shaping über Frame Relay bietet die folgenden Funktionen:
-
Durchsetzung der Übertragungsrate pro VC: Sie können eine Spitzengeschwindigkeit konfigurieren, um den ausgehenden Datenverkehr auf CIR oder einen anderen definierten Wert, z. B. die Überschussinformationsrate (EIR), zu begrenzen.
-
Generalisierte BECN-Unterstützung auf VC-Basis: Der Router kann BECNs überwachen und den Datenverkehr drosseln, basierend auf BECN-markiertem Paket-Feedback aus dem Frame-Relay-Netzwerk.
-
Priority Queuing (PQ), Custom Queuing (CQ) oder WFQ-Unterstützung auf VC-Ebene. Dadurch wird eine feinere Granularität bei der Priorisierung und Warteschlangenzuweisung des Datenverkehrs ermöglicht, sodass Sie den Datenverkehrsfluss auf einer einzelnen VC besser kontrollieren können. Das Traffic-Shaping über Frame-Relay gilt für permanente virtuelle Frame-Relay-Schaltungen (PVCs) und Switched Virtual Circuits (SVCs).
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 Strecke verläuft zwischen 64000 (CIR) und 128000(Bc + Be).
-
Die andere verläuft zwischen 16000 (CIR) und 64000 (Bc + Be).
Wenn der eingehende Datenverkehr von Ethernet größer ist als der Token-Bucket-Filter, wird der Datenverkehr in der Warteschlange für den Frame-Relay-Datenverkehr gepuffert.
Ein Flussdiagramm mit dem Paketfluss bei der Implementierung von Frame Relay-Traffic-Shaping finden Sie unter Frame Relay-Traffic-Shaping-Flussdiagramm. Informationen zum Anzeigen eines Flussdiagramms mithilfe eines Token-Bucket-Filters finden Sie unter Frame Relay Traffic Shaping - Token Bucket Flowchart.
Häufig verwendete Frame-Relay-Befehle
In diesem Abschnitt werden zwei Cisco IOS®-Befehle beschrieben, die besonders bei der Konfiguration von Frame Relay nützlich sind.
Frame-Relay-PVC anzeigen
Dieser Befehl zeigt den Status des Permanent Virtual Circuit (PVC), ein- und ausgehende Pakete, verworfene Pakete bei einer Überlastung in der Leitung mittels Forward Explicit Congestion Notification (FECN) und Backward Explicit Congestion Notification (BECN) usw. an. Klicken Sie hier, um eine detaillierte Beschreibung der Felder zu erhalten, die mit dem Befehl show frame-relay pvc verwendet werden.
Wenn Sie den Befehl show frame-relay pvc von Ihrem Cisco Gerät ausgegeben haben, können Sie Output Interpreter (nur für registrierte Kunden) verwenden, um potenzielle Probleme und Korrekturen anzuzeigen.
Die Beispielausgabe ist unten dargestellt:
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 USAGE" enthält einen der folgenden Einträge:
-
SWITCHED (SWITCHED): Der Router oder Zugriffsserver wird als Switch verwendet.
-
LOKAL - der Router oder Zugriffsserver wird als Datenendgerät (DTE) verwendet.
-
UNGENUTZT - Der Data Link Connection Identifier (DLCI) wird nicht durch vom Benutzer eingegebene Konfigurationsbefehle auf dem Router referenziert.
Das PVC kann vier mögliche Zustände haben. Diese werden im Feld PVC STATUS (PVC-STATUS) wie folgt angezeigt:
-
AKTIV - PVC ist in Betrieb und funktioniert normal.
-
INAKTIV - PVC ist nicht durchgängig. 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 des PVC gelöscht wird.
-
DELETED - Entweder wird die lokale Verwaltungsschnittstelle (LMI) nicht zwischen dem Router und dem lokalen Switch ausgetauscht, oder auf dem Switch ist keine DLCI auf dem lokalen Switch konfiguriert.
-
STATIC - auf der Frame-Relay-Schnittstelle des Routers ist kein Keepalive konfiguriert.
Frame-Relay-Map anzeigen
Mit diesem Befehl können Sie ermitteln, ob Frame-Relay Inverse-ARP eine Remote-IP-Adresse in einen lokalen DLCI aufgelöst hat. Dieser Befehl ist für Punkt-zu-Punkt-Subschnittstellen nicht aktiviert. Es ist nur für Multipoint-Schnittstellen und Subschnittstellen nützlich. Die Beispielausgabe ist unten dargestellt:
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-relay map verwendet werden, finden Sie unter Documentation on frame relay Commands.
Wenn Sie den Befehl show frame-relay map von Ihrem Cisco Gerät ausgegeben haben, können Sie Output Interpreter (nur für registrierte Kunden) verwenden, um potenzielle Probleme und Korrekturen anzuzeigen.
Frame-Relay und Bridging
Konfigurationsnachrichten, die als Bridge Protocol Data Units (BPDUs) bezeichnet werden, werden in den Spanning-Tree-Protokollen verwendet, die von Cisco Bridges und Routern unterstützt werden. Diese verlaufen in regelmäßigen Abständen zwischen den Brücken und stellen aufgrund ihres häufigen Auftretens ein erhebliches Verkehrsaufkommen dar. Es gibt zwei Arten von Spanning-Tree-Protokollen im transparenten Bridging. Zuerst von der Digital Equipment Corporation (DEC) eingeführt, wurde der Algorithmus anschließend vom IEEE 802-Ausschuss überarbeitet und in der IEEE 802.1d-Spezifikation veröffentlicht. Das DEC Spanning-Tree Protocol gibt in Abständen von einer Sekunde BPDUs aus, während das IEEE in Intervallen von zwei Sekunden BPDUs ausgibt. Jedes Paket hat 41 Byte und umfasst eine 35-Byte-BPDU-Nachricht, einen 2-Byte-Frame-Relay-Header, einen 2-Byte-Ethertype und einen 2-Byte-FCS.
Frame-Relay und -Speicher
Die Speicherbelegung für Frame-Relay-Ressourcen erfolgt in vier Bereichen:
-
Jeder Data Link Connection Identifier (DLCI): 216 Byte
-
Jede Map-Anweisung: 96 Byte (oder dynamisch erstellte Map)
-
Jeder IDB (Hardwareschnittstelle + Encap Frame Relay): 5.040 + 8.346 = 13.386 Byte
-
Jeder IDB (Software-Subschnittstelle): 2.260 Byte
Beispiel: Ein Cisco 2501 benötigt bei Verwendung von zwei Frame-Relay-Schnittstellen mit jeweils vier Subschnittstellen mit insgesamt acht DLCIs und zugehörigen Zuordnungen Folgendes:
-
2-Schnittstellen-Hardware IDB x 13.386 = 26.772
-
8 Subschnittstellen IDB x 2260 = 18.080 Subschnittstellen
-
8 DLCIs x 216 = 1728 DLCIs
-
8 Kartenanweisungen x 96 = 768 Kartenanweisungen oder Dynamik
Die Gesamtzahl entspricht 47.348 Byte verwendetem RAM.
Hinweis: Die hier angegebenen Werte gelten für die Cisco IOS-Software der Versionen 11.1, 12.0 und 12.1.
Fehlerbehebung Frame Relay
Dieser Abschnitt enthält Teile der möglichen Ausgabe des Befehls show interface, die bei der Fehlerbehebung auftreten kann. Erläuterungen zur Ausgabe sind ebenfalls enthalten.
"Serial0 is down, line protocol is down"
Diese Ausgabe bedeutet, dass Sie ein Problem mit dem Kabel, der Kanaldiensteinheit/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:
-
Setzen Sie die Kapselung der seriellen Leitung auf HDLC und Keepalive auf 10 Sekunden. Geben Sie dazu die Befehle encapsulation hdlc und keepalive 10 unter der seriellen Schnittstelle ein.
-
Versetzen Sie die CSU/DSU oder das Modem in den Local-Loop-Modus. Wenn sich das Leitungsprotokoll im lokalen Loopback-Modus befindet (durch die Meldung "Line Protocol is up (looped)" angezeigt), deutet dies darauf hin, dass das Problem auch außerhalb der lokalen CSU/DSU auftritt. Wenn die Statuszeile den Status nicht ändert, liegt möglicherweise ein Problem mit dem Router, dem Verbindungskabel, der CSU/DSU oder dem Modem vor. In den meisten Fällen liegt das Problem bei der CSU/DSU oder dem Modem.
-
Senden Sie einen Ping an Ihre eigene IP-Adresse, wenn die CSU-/DSU- oder Modemschleife verwendet wird. Es darf keine Missgeschicke geben. Ein erweiterter Ping von 0x0000 ist hilfreich bei der Lösung von Verbindungsproblemen, da ein T1 oder E1 die Uhr aus den Daten ableitet und alle 8 Bit einen Übergang erfordert. B8ZS stellt sicher, dass. Anhand eines Datenmusters mit starker Null kann festgestellt werden, ob die Übergänge auf den Trunk entsprechend erzwungen werden. Ein Heavy-One-Muster wird verwendet, um eine hohe Null-Last angemessen zu simulieren, falls sich ein Paar von Dateninvertern im Pfad befindet. Das alternierende Muster (0x555) stellt ein "typisches" Datenmuster dar. Wenn Ihre Pings ausfallen oder Sie zyklische Redundanzprüfungsfehler (CRC) erhalten, ist ein Bitfehlerraten-Tester (BERT) mit einem entsprechenden Analysator des Telekommunikationsanbieters erforderlich.
-
Wenn Sie den Test abgeschlossen haben, stellen Sie sicher, dass Sie die Kapselung auf Frame Relay zurücksetzen.
"Serial0 is up, line protocol is down"
Diese Leitung in der Ausgabe bedeutet, dass der Router ein Trägersignal von der CSU/DSU oder dem Modem erhält. Überprüfen Sie, ob der Frame Relay-Anbieter seinen Port aktiviert hat und ob die Einstellungen der lokalen Verwaltungsschnittstelle (LMI) übereinstimmen. Im Allgemeinen ignoriert der Frame Relay-Switch das Datenendgerät (DTE), es sei denn, er erkennt das richtige LMI (verwenden Sie die Cisco Standardeinstellung für "cisco" LMI). Überprüfen Sie, ob der Cisco Router Daten überträgt. Sie müssen höchstwahrscheinlich die Leitungsintegrität mithilfe von Loop-Tests an verschiedenen Standorten überprüfen, beginnend mit der lokalen CSU und bis zum Frame Relay-Switch des Anbieters. Im vorherigen Abschnitt erfahren Sie, wie Sie einen Loopback-Test durchführen.
"Serial0 is up, line protocol is up"
Wenn Sie Keepalives nicht deaktiviert haben, bedeutet diese Ausgabezeile, dass der Router mit dem Switch des Frame Relay-Anbieters kommuniziert. Auf der seriellen Schnittstelle sollte ein erfolgreicher Austausch von bidirektionalem Datenverkehr ohne CRC-Fehler möglich sein. Keepalives sind in Frame Relay erforderlich, da sie den Mechanismus darstellen, mit dem der Router "lernt", welche DLCIs (Data Link Connection Identifiers) der Anbieter bereitgestellt hat. Um den Austausch zu beobachten, können Sie sicher debug frame-relay lmi in fast allen Situationen verwenden. Der Befehl debug frame-relay lmi generiert nur sehr wenige Meldungen und kann Antworten auf Fragen wie die folgenden geben:
-
Spricht der Cisco Router mit dem lokalen Frame Relay-Switch?
-
Erhält der Router vollständige LMI-Statusmeldungen für die abonnierten permanenten virtuellen Schaltungen (PVCs) vom Frame Relay-Anbieter?
-
Sind die DLCIs korrekt?
Hier sind einige Beispiele für debug frame-relay lmi, die von einer erfolgreichen Verbindung ausgegeben werden:
*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 im Folgenden erläutert:
-
0x0-Added/inactive bedeutet, dass der DLCI für den Switch programmiert ist, er aber aus irgendeinem Grund (z. B. wenn das andere Ende dieses PVCs ausfällt) nicht verwendet werden kann.
-
0x2-Added/active bedeutet, dass der Frame Relay-Switch über das DLCI verfügt und alles betriebsbereit ist. Sie können mit diesem DLCI im Header beginnen, Datenverkehr zu senden.
-
0x3-0x3 ist eine Kombination aus einem aktiven Status (0x2) und dem festgelegten RNR (oder r-Bit) (0x1). Das bedeutet, dass der Switch - oder eine bestimmte Warteschlange auf dem Switch - für diese PVC-Lösung gesichert wird und Sie die Übertragung unterbrechen, falls Frames überschritten werden.
-
0x4-Deleted bedeutet, dass für den Frame-Relay-Switch dieser DLCI nicht für den Router programmiert ist. Aber es wurde irgendwann in der Vergangenheit programmiert. Dies kann auch dadurch verursacht werden, dass die DLCIs auf dem Router umgekehrt werden, oder dadurch, dass das PVC vom Telekommunikationssystem in der Frame-Relay-Cloud gelöscht wird. Die Konfiguration eines DLCI (über den der Switch nicht verfügt) wird als 0x4 angezeigt.
-
0x8-Neu/Inaktiv
-
0x0a-Neu/Aktiv
Frame-Relayeigenschaften
In diesem Abschnitt werden verschiedene Frame Relay-Merkmale erläutert, die Sie beachten sollten.
IP-Split-Horizon-Prüfung
Die IP-Split-Horizon-Prüfung ist für die Frame-Relay-Kapselung standardmäßig deaktiviert, sodass Routing-Updates über dieselbe Schnittstelle ein- und ausgehen. Die Router beziehen die benötigten DLCIs (Data Link Connection Identifiers) über LMI-Updates (Local Management Interface) vom Frame Relay-Switch. Die Router verwenden dann Inverse ARP als 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, transparentes Bridging und IPX in teilweise vernetzten Netzwerken nicht unterstützt werden, da sie "Split Horizon" erfordern, bei dem ein auf einer Schnittstelle empfangenes Paket nicht über dieselbe Schnittstelle gesendet werden kann, selbst wenn das Paket empfangen und auf verschiedenen virtuellen Verbindungen übertragen wird. Durch die Konfiguration von Frame Relay-Subschnittstellen wird sichergestellt, dass eine einzelne physische Schnittstelle als mehrere virtuelle Schnittstellen behandelt wird. Auf diese Weise können wir Split-Horizon-Regeln umgehen. Pakete, die auf einer virtuellen Schnittstelle empfangen werden, können nun von einer anderen virtuellen Schnittstelle weitergeleitet werden, selbst wenn sie auf derselben physischen Schnittstelle konfiguriert sind.
Senden Sie einen Ping an Ihre eigene IP-Adresse in einem Multipoint-Frame-Relay.
Es ist nicht möglich, einen Ping an Ihre eigene IP-Adresse über eine Frame Relay-Schnittstelle mit mehreren Punkten zu senden. Dies liegt daran, dass Frame Relay-Multipoint-Schnittstellen (Sub-Schnittstellen) nicht Broadcast sind (im Gegensatz zu Ethernet- und Point-to-Point-Schnittstellen HDLC [High-Level Data Link Control]) und Frame Relay-Point-to-Point-Subschnittstellen.
Darüber hinaus können Sie in einer Hub-and-Spoke-Konfiguration keinen Ping von einer Speiche an eine andere Speiche senden. Dies liegt daran, dass es keine Zuordnung für Ihre eigene IP-Adresse gibt (und dass keine Zuordnung über Inverse ARP erfolgt ist). Wenn Sie jedoch eine statische Karte (mithilfe des Befehls frame-relay map) für Ihre eigene IP-Adresse (oder eine für die Remote-Spoke) konfigurieren, um den lokalen DLCI zu verwenden, können Sie dann einen 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 Keyword-Ü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 kann auch für einige Routing-Protokolle (z. B. AppleTalk) erforderlich sein, die von regelmäßigen Updates der Routing-Tabelle abhängen, insbesondere wenn der Router am Remote-Ende auf den Eingang eines Routing-Update-Pakets wartet, bevor die Route hinzugefügt wird.
Da ein designierter Router ausgewählt werden muss, behandelt OSPF ein Nicht-Broadcast-Multi-Access-Netzwerk wie Frame Relay in etwa gleich wie ein Broadcast-Netzwerk. In früheren Versionen war hierzu eine manuelle Zuweisung in der OSPF-Konfiguration mit dem Befehl neighbor interface 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 network interface.)
Hinweis: Der OSPF-Broadcast-Mechanismus geht davon aus, dass IP-Klasse-D-Adressen nie für den 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.
Subschnittstelle neu konfigurieren
Nachdem Sie einen bestimmten Subschnittstellentyp erstellt haben, können Sie diesen ohne erneutes Laden nicht mehr ändern. Sie können beispielsweise keine serielle Multipoint-Subschnittstelle0.2 erstellen und sie dann in Punkt-zu-Punkt ändern. Um sie zu ändern, müssen Sie entweder den Router neu laden oder eine andere Subschnittstelle erstellen. So funktioniert der Frame-Relay-Code in der Cisco IOS®-Software.
DLCI-Einschränkungen
DLCI-Adressraum
Bei einer 10-Bit-Adresse können etwa 1.000 DLCIs auf einer einzigen physischen Verbindung konfiguriert werden. Da bestimmte DLCIs reserviert sind (anbieterabhängig), liegt der Höchstwert bei etwa 1.000. Der gültige Bereich für einen Cisco LMI liegt zwischen 16 und 1007. Der angegebene Bereich für ANSI/ITU liegt zwischen 16 und 992. Dabei handelt es sich um die DLCIs mit Benutzerdaten.
Bei der Konfiguration von Frame-Relay-VCs an Subschnittstellen müssen Sie jedoch einen praktischen Grenzwert berücksichtigen, der als IDB-Grenzwert bezeichnet wird. Die Gesamtzahl der Schnittstellen und Subschnittstellen pro System wird durch die Anzahl der IDBs (Interface Descriptor Blocks) begrenzt, die von Ihrer Version von Cisco IOS unterstützt werden. Ein IDB ist ein Teil des Speichers, der Informationen über die Schnittstelle wie Zähler, den Status der Schnittstelle usw. enthält. IOS verwaltet eine IDB für jede auf einer Plattform vorhandene Schnittstelle und eine IDB für jede Subschnittstelle. Schnittstellen mit höherer Geschwindigkeit benötigen mehr Speicher als Schnittstellen mit geringerer Geschwindigkeit. Jede Plattform enthält eine unterschiedliche Anzahl von IDBs (Maximum IDBs). Diese Beschränkungen können sich mit jeder Cisco IOS-Version ändern.
Weitere Informationen finden Sie unter Maximum Number of Interfaces and Subinterfaces for Cisco IOS Software Platforms: IDB Limits.
LMI-Statusaktualisierung
Das LMI-Protokoll setzt voraus, dass alle PVC-Statusberichte (Permanent Virtual Circuit) in ein einzelnes Paket passen und die Anzahl der DLCIs in Abhängigkeit von der maximalen MTU-Größe (Transmission Unit) in der Regel auf weniger als 800 begrenzen.
Der Standard-MTU-Wert für serielle Schnittstellen beträgt 1.500 Byte, was maximal 296 DLCIs pro Schnittstelle ergibt. Sie können den MTU-Wert erhöhen, um vom Frame-Relay-Switch aus eine umfassendere Statusaktualisierungsmeldung zu unterstützen. Wenn die vollständige Statusaktualisierungsmeldung größer als die MTU der Schnittstelle ist, wird das Paket verworfen, und der Schnittstellen-Gigantzähler wird inkrementiert. Wenn Sie die MTU ändern, stellen Sie sicher, dass der gleiche Wert auf dem Remote-Router und den zwischengeschalteten Netzwerkgeräten konfiguriert ist.
Bitte beachten Sie, dass diese Zahlen je nach LMI-Typ leicht variieren. Die Richtlinie für die maximale Anzahl von DLCIs pro Router (nicht Schnittstelle) auf Basis der Extrapolation von empirischen Daten aus einer Cisco 7000-Router-Plattform ist im Folgenden aufgeführt:
-
Cisco 2500: 1 X T1/E1-Verbindung bei 60 DLCIs pro Schnittstelle = 60 insgesamt
-
Cisco 4000: 1 X T1/E1-Verbindung bei 120 DLCIs pro Schnittstelle = 120 insgesamt
-
Cisco 4500: 3 x T1/E1-Verbindungen bei 120 DLCIs pro Schnittstelle = 360 insgesamt
-
Cisco 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 = 720 insgesamt
Hinweis: Diese Zahlen dienen lediglich als Richtwerte und setzen voraus, dass der gesamte Datenverkehr über Fast Switching abgewickelt wird.
Weitere Überlegungen
Ein praktischer DLCI-Grenzwert hängt auch davon ab, ob auf den VCs ein dynamisches oder ein 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 eingesehen und verarbeitet werden müssen. In der Regel können Sie mit statischen Routen eine größere Anzahl von VCs auf einer einzelnen 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 Hauptschnittstelle aktivieren, um sicherzustellen, dass Frame-Relay Inverse-ARP ordnungsgemäß funktioniert. Falls eine Störung auftritt, gehen Sie wie folgt vor:
-
Deaktivieren Sie das Inverse Address Resolution Protocol (ARP) für diesen DLCI mithilfe der Befehle no frame-relay inverse-arp ip 16 und clear frame-relay-inarp.
-
Korrigieren Sie die Konfiguration.
-
Schalten Sie den Befehl frame-relay inverse-arp wieder ein.
RIP und IGRP
RIP-Updates (Routing Information Protocol) erfolgen alle 30 Sekunden. Jedes RIP-Paket kann bis zu 25 Routeneinträge enthalten, d. h. insgesamt 536 Byte. 36 Byte davon sind Header-Informationen, und jeder Routeneintrag umfasst 20 Byte. Wenn Sie also 1.000 Routen über eine Frame-Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, beträgt das Ergebnis 1 MB an Routing-Aktualisierungsdaten alle 30 Sekunden bzw. 285 Kbit/s an Bandbreite. Auf einer T1-Verbindung stellt diese Bandbreite 18,7 Prozent der Bandbreite dar, wobei jede Aktualisierungsdauer 5,6 Sekunden beträgt. Dieser Overhead ist beträchtlich und grenzenlos akzeptabel, aber die Committed Information Rate (CIR) müsste sich in der Region der Zugriffsgeschwindigkeit befinden. Offensichtlich würde alles, was kleiner als ein T1 ist, zu viel Gemeinkosten verursachen. Beispiele:
-
1000/25 = 40 Pakete X 36 = 1440 Header-Bytes
-
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
IGRP-Updates (Interior Gateway Routing Protocol) werden alle 90 Sekunden aktualisiert (dieses Intervall ist konfigurierbar). Jedes IGRP-Paket kann 104 Routeneinträge enthalten, insgesamt 1.492 Byte, von denen 38 Header-Informationen sind, und jeder Routeneintrag beträgt 14 Byte. Wenn Sie 1.000 Routen über eine Frame-Relay-Verbindung ankündigen, die mit 50 DLCIs konfiguriert wurde, beträgt die Anforderung ca. 720 KB an Routing-Aktualisierungsdaten alle 90 Sekunden oder 64 Kbit/s an Bandbreite. Auf einer T1-Verbindung entspricht diese Bandbreite 4,2 Prozent der Bandbreite, wobei jede Aktualisierungsdauer 3,7 Sekunden beträgt. Diese Gemeinkosten sind akzeptabel:
-
1000/104 = 9 Pakete X 38 = 342 Header-Bytes
-
1000 x 14 = 14.000 Byte Routeneinträge
-
Gesamt = 14.342 Byte X 50 DLCIs = 717 KB IGRP-Updates alle 90 Sekunden
-
717.000 Byte / 90 x 8 Bit = 63,7 Kbit/s
Routingtabellen-Wartungsprotokoll (RTMP)-Routingaktualisierungen erfolgen alle 10 Sekunden (dieses Intervall ist konfigurierbar). Jedes RTMP-Paket kann bis zu 94 erweiterte Routeneinträge enthalten, was einer Gesamtzahl von 564 Byte und 23 Byte an Header-Informationen entspricht. Jeder Routeneintrag umfasst 6 Byte. Wenn Sie 1.000 AppleTalk-Netzwerke über eine Frame-Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, beträgt das Ergebnis ca. 313 KB an RTMP-Updates alle 10 Sekunden bzw. 250 Kbit/s an Bandbreite. Um innerhalb eines akzeptablen Overhead (15 Prozent oder weniger) zu bleiben, ist eine T1-Rate erforderlich. Beispiele:
-
1000/94 = 11 Pakete X 23 Bytes = 253 Header-Bytes
-
1000 X 6 = 6000 Byte Routeneinträge
-
Gesamt = 6.253 x 50 DLCIs = 313 KB RTMP-Updates alle 10 Sekunden
-
313.000/10 Sek. x 8 Bits = 250 Kbit/s
IPX RIP-Paketaktualisierungen erfolgen alle 60 Sekunden (dieses Intervall ist konfigurierbar). Jedes IPX-RIP-Paket kann bis zu 50 Routeneinträge enthalten, d. h. insgesamt 536 Byte, 38 Byte an Header-Informationen, und jeder Routeneintrag umfasst 8 Byte. Wenn Sie 1.000 IPX-Routen über eine Frame Relay-Verbindung ankündigen, die für 50 DLCIs konfiguriert wurde, beträgt das Ergebnis 536 KB IPX-Updates alle 60 Sekunden bzw. 58,4 Kbit/s an Bandbreite. Um innerhalb eines akzeptablen Overhead-Bereichs (15 Prozent oder weniger) zu bleiben, ist eine Rate von 512 Kbit/s erforderlich. Beispiele:
-
1000/50 = 20 Pakete X 38 Bytes = 760 Bytes Header
-
1000 X 8 = 8.000 Byte Routeneinträge
-
Gesamt = 8760 x 50 DLCIs = 438.000 Byte IPX-Updates alle 60 Sekunden
-
438.000/60 Sek. x 8 Bits = 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 Advertisement-Einträge enthalten, sodass insgesamt 536 Byte, 38 Byte Header-Informationen und jeder Advertisement-Eintrag 64 Byte umfasst. Wenn Sie 1.000 IPX-Meldungen über eine Frame-Relay-Verbindung senden, die für 50 DLCIs konfiguriert ist, würden Sie am Ende 536 KB IPX-Updates alle 60 Sekunden erhalten, d. h. 58,4 Kbit/s an Bandbreite. Um innerhalb eines akzeptablen Overhead-Bereichs (15 Prozent oder weniger) zu bleiben, ist eine Rate von mehr als 2 Mbit/s erforderlich. In diesem Szenario ist offensichtlich eine SAP-Filterung erforderlich. Im Vergleich zu allen anderen in diesem Abschnitt erwähnten Protokollen benötigen IPX-SAP-Updates die größte Bandbreite:
-
1000/7 = 143 Pakete X 38 Bytes = 5434 Bytes Header
-
1000 X 64 = 64.000 Byte Routeneinträge
-
Insgesamt = 69.434 x 50 DLCIs = 3.471.700 Byte IPX-Service-Meldungen alle 60 Sekunden
-
3.471.700/60 Sek. x 8 Bits = 462 Kbit/s
Keepalive
In einigen Fällen muss der Keepalive auf dem Cisco Gerät etwas kürzer (etwa 8 Sekunden) als der Keepalive auf dem Switch eingestellt werden. Sie werden sehen, die Notwendigkeit für diese, wenn die Schnittstelle immer wieder kommt auf und ab.
Serielle Schnittstellen
Serielle Schnittstellen, bei denen es sich standardmäßig um Multipoint-Schnittstellen handelt, sind Nicht-Broadcast-Medien, während Punkt-zu-Punkt-Subschnittstellen Broadcast sind. Wenn Sie statische Routen verwenden, können Sie entweder auf den nächsten Hop oder die serielle Subschnittstelle zeigen. Bei Multipoint müssen Sie auf den nächsten Hop zeigen. Dieses Konzept ist sehr wichtig, wenn OSPF über Frame-Relay ausgeführt wird. Der Router muss wissen, dass dies eine Broadcast-Schnittstelle ist, damit OSPF funktioniert.
OSPF und Multipoint
OSPF und Multipoint können sehr problematisch sein. Für OSPF ist ein designierter Router (DR) erforderlich. Wenn Sie PVCs verlieren, verlieren einige Router möglicherweise die Verbindung 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 weniger offensichtlich und vorhersehbar als der mit herkömmlichen Distanzvektor-Routing-Protokollen. Die Unvorhersehbarkeit hängt davon ab, ob die OSPF-Netzwerkverbindungen stabil sind. Wenn alle Adjacencies zu einem Frame-Relay-Router stabil sind, werden nur benachbarte Hello-Pakete (Keepalives) übertragen, was vergleichsweise viel weniger Overhead verursacht als bei einem Distanzvektorprotokoll (wie RIP und IGRP). Wenn Routen (Adjacencies) jedoch instabil sind, führt dies zu Link-State-Flooding, sodass Bandbreite schnell belegt werden kann. OSPF ist außerdem sehr prozessorintensiv, wenn der Dijkstra-Algorithmus ausgeführt wird, der zum Berechnen von Routen verwendet wird.
In früheren Versionen der Cisco IOS-Software musste bei der Konfiguration von OSPF über Multiaccess-Nonbroadcast-Medien wie Frame Relay, X.25 und ATM besondere Sorgfalt angewendet werden. Das OSPF-Protokoll betrachtet diese Medien wie alle anderen Broadcast-Medien, z. B. Ethernet. NBMA-Clouds (Nonbroadcast Multiaccess) werden in der Regel in einer Hub-and-Spoke-Topologie implementiert. PVCs oder Switched Virtual Circuits (SVCs) sind in einem Teilnetz angeordnet, und die physische Topologie bietet nicht den von OSPF erwarteten Multiaccess. Bei seriellen Point-to-Point-Schnittstellen bildet OSPF immer eine Nachbarschaft. OSPF-Nachbarschaften tauschen Datenbankinformationen aus. Um die Menge an Informationen zu minimieren, die in einem bestimmten Segment ausgetauscht werden, wählt OSPF einen Router als DR und einen Router als Backup-designierten Router (BDR) in jedem Multizugriffssegment. Der BDR dient als Backup-Mechanismus für den Fall, dass der DR ausfällt.
Die Idee hinter dieser Konfiguration ist, dass Router einen zentralen Ansprechpartner für den Informationsaustausch haben. Die Auswahl des DR wurde zu einem Problem, da der DR und der BDR über vollständige physische Verbindungen mit allen in der Cloud vorhandenen Routern verfügen mussten. Aufgrund der fehlenden Broadcast-Funktionen mussten für den DR und den BDR außerdem eine statische Liste aller anderen Router erstellt werden, die mit der Cloud verbunden sind. Diese Konfiguration wird mit dem Befehl neighbor durchgeführt:
neighbor ip-address [Prioritätsnummer] [Abfrageintervall in Sekunden]
In späteren Versionen der Cisco IOS-Software können verschiedene Methoden verwendet werden, um die Komplikationen bei der Konfiguration statischer Nachbarn und der Umwandlung bestimmter Router in DRs oder BDRs in der Nonbroadcast-Cloud zu vermeiden. Welche Methode verwendet wird, hängt davon ab, ob es sich um ein neues oder ein vorhandenes Design handelt, das geändert werden muss.
Eine Unterschnittstelle ist eine logische Möglichkeit, eine Schnittstelle zu definieren. Die gleiche physische Schnittstelle kann in mehrere logische Schnittstellen aufgeteilt werden, wobei jede Unterschnittstelle als Point-to-Point-Schnittstelle definiert wird. Dieses Szenario wurde ursprünglich entwickelt, um Probleme besser zu behandeln, die durch Split Horizon über NBMA und vektorbasierte Routing-Protokolle verursacht werden.
Eine Point-to-Point-Unterschnittstelle hat die gleichen Eigenschaften wie eine physische Point-to-Point-Schnittstelle. Bei OSPF wird eine Adjacency immer über eine Point-to-Point-Unterschnittstelle ohne DR- oder BDR-Wahl gebildet. OSPF betrachtet die Cloud als eine Reihe von Point-to-Point-Verbindungen und nicht als ein Multiaccess-Netzwerk. Der einzige Nachteil von 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 ist die Verwendung nicht nummerierter IP-Schnittstellen in der Cloud. Dieses Szenario kann auch für einige Administratoren problematisch sein, die das WAN anhand der IP-Adressen der seriellen Leitungen verwalten.
Quellen
-
International Telegraph and Telefone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT Recommendation Q.922, 19. April 1991.
-
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.
-
Informationstechnologie - Telekommunikation und Informationsaustausch zwischen Systemen - Protokollidentifikation in der Netzwerkschicht, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
-
International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.
-
Internetworking Technology Overview, Oktober 1994, Cisco Systems
-
Finlayson, R., Mann, R., Mogul, J. und M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, Juni 1984.
-
Postel, J. and Reynolds, J., "Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, Februar 1988.
-
Frame Relay Forum (FRF) 1.1 User Network Interface (UNI)
-
FRF 2.1-Frame Relay Network-to-Network Interface (NNI)
-
FRF 3.1-Multiprotocol-Kapselung
-
FRF 4-SVCs
-
FRF 6-Frame Relay Service Customer Network Management (MIB)
-
Viererbande LMI
-
Q.922 Anhang A
-
ANSI T1.617 Annex D
-
ANSI T1 618, T1 606
-
ITU-T Q.933, Q.922
-
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 Dial-Backup-Befehlen
- Weitere Informationen zu ISDN-Debugbefehlen
- Weitere Informationen zu PPP Debug Commands
- Weitere Informationen zu ISDN-Switch-Typen, -Codes und -Werten
- Technischer Support und Dokumentation für Cisco Systeme
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)