VoIP over Frame Relay mit Multipoint-PVCs und Priorisierung

Download-Optionen

  • PDF     (221.8 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (127.8 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (121.6 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:6. Juli 2007
Dokument-ID:12162

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

In diesem Dokument werden Traffic Shaping und die Priorisierung für ein VoIP (Voice over IP)-over-Frame-Relay-Netzwerk mit Hub-and-Spoke-Topologie behandelt. Die Hub-Konfiguration ist so ausgelegt, dass es zwei permanente virtuelle Schaltungen (PVCs) gibt, eine für jede Remote-Spoke, und sowohl Daten als auch Sprache über dieselben PVCs gesendet werden. Dabei ist zu beachten, dass die in diesem Dokument besprochene Priorisierung und Fragmentierung nicht nur auf dieses Szenario zutrifft, sondern auch auf ein Szenario, in dem eine PVC mit Sprache und Daten und eine andere nur mit Daten vorliegen kann. Die Daten-PVCs müssen ebenso datenverkehrsförmig sein wie Sprach- und Daten-PVCs. Dies liegt daran, dass die Serialisierungsverzögerung alle Daten beeinflusst, wenn eine einzelne physische Leitung gemeinsam genutzt wird (in diesem Fall am Hub).

In der Topologie unten stellt New York den zentralen Hub-Router dar. Raleigh und San Jose sind Remote-Router, die über ein Frame Relay-Netzwerk mit dem Hub verbunden sind. Es gibt zwei PVCs, die mit dem New Yorker Router verbunden sind. In diesem Fall sollte New York niemals mehr als 64 Kbit/s nach Raleigh senden. Ebenso sollte es nie mehr als 192 Kbit/s nach San Jose senden, da dies die konfigurierte Committed Information Rate (CIR) auf der Frame Relay-Mapclass übersteigt.

In der in diesem Dokument gezeigten Topologie sind die Router mit VoIP-Konfigurationen direkt mit einer Frame-Relay-Cloud verbunden. In einigen Topologien können die sprachfähigen Router jedoch überall im Netzwerk vorhanden sein, mit Ausnahme des Cisco AS5300. Weitere Informationen hierzu finden Sie in der Mitteilung. Die Sprach-Router können über LAN-Verbindungen mit anderen Routern verbunden werden, die mit dem WAN verbunden sind. Dies ist wichtig, da alle Konfigurationsbefehle für die WAN-Konnektivität auf den mit dem WAN verbundenen Routern und nicht auf den Sprach-Routern konfiguriert werden, wenn die Sprach-Router nicht direkt mit einem Frame-Relay-Dienst verbunden sind.

Hinweis: Cisco Router der Serie AS5300 mit seriellen Hochgeschwindigkeitsschnittstellen unterstützen keine Datenverbindung mit einem WAN. Sie müssen Ihre Cisco AS5300 als zwischengeschaltete LAN-Router mit der Hauptfunktion für die Verarbeitung von Sprachanrufen verwenden. Sie benötigen dedizierte Router, die als direkte Verbindungen zum WAN fungieren.

Voraussetzungen

Anforderungen

Stellen Sie vor dem Versuch dieser Konfiguration sicher, dass Sie die folgenden Voraussetzungen erfüllen:

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

  • Drei Cisco 3640 Router mit Cisco IOS® Software Release 12.3(5) Enterprise Plus

  • Vier analoge Telefone, die an FXS-Ports (Foreign Exchange Station) in Stationen angeschlossen sind

  • Ein PBX-System ist mit einem T1-Controller am Hub-Router verbunden.

Die Stationen können auch eine Cisco 2600- oder eine 1750-Plattform sein. Bei dem Hub kann es sich um eine Cisco 2600- oder 3600-Plattform bei digitaler Sprachübertragung handeln, aber auch um eine Cisco 1750-Plattform, wenn nur am Hub analoge Sprachfunktionen vorhanden sind. Traffic Shaping und Konfigurationen gelten auch für andere Plattformen.

Hinweis: Obwohl dieses Dokument nicht auf bestimmte Software beschränkt ist, sind einige der hier verwendeten Befehle nicht bei allen Versionen der Cisco IOS Software verfügbar. Der Befehl Frame-Relay Fragment wird beispielsweise mit IP Plus unterstützt, jedoch nicht mit einem IP-Image.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

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

Konfigurieren von Traffic Shaping und Priorisierung für einen VoIP over Frame Relay

Beim Ausführen von VoIP über Frame Relay ist es wichtig, dass der über den Frame gesendete Datenverkehr auf einer Ebene verbleibt, die kleiner oder gleich der CIR für Frame-Relay ist. Der Router sendet keinen Datenverkehr, der die CIR überschreitet, wenn er wie gezeigt mit Frame Relay Traffic Shaping (FRTS) konfiguriert ist. Wenn Sie den Router so konfigurieren, dass er mit einer höheren Geschwindigkeit als die CIR ausgeführt wird, kann es zu Problemen mit der Sprachqualität kommen, und die Sprachqualität wird nicht garantiert, wenn PVCs über der garantierten CIR ausgeführt werden.

Hinweis: Es ist möglich, adaptives Shaping so zu konfigurieren, dass ein Router die Übertragungsrate auf einen bestimmten Wert drosselt, wenn Frame-Relay-Pakete mit dem BECN-Bitsatz (Backward Explicit Congestion Notification) empfangen werden. Es wird jedoch darauf hingewiesen, dass die Datenverkehrsraten die CIR des Frame Relay-Service bei der Übertragung von Sprachpaketen nicht überschreiten dürfen. Auf diese Weise wird eine angemessene Qualität und Übermittlung sichergestellt, wenn Sprachpakete in Echtzeit über das Netzwerk gesendet werden. Die Konfiguration, in der die CIR überschritten wird, wird nur für Daten-PVCs empfohlen, die keinen Sprachdatenverkehr übertragen.

Hinweis: Bevor Sie Ihren Router für die Verwendung von VoIP konfigurieren können, sollten Sie die Quality of Service (QoS)-Funktionen der Cisco IOS-Software besser kennen. Weitere Informationen zu QoS-Funktionen finden Sie unter Warteschlangenverwaltung, Traffic Shaping, Filterung und Fragmentierung für Sprache.

Hinweis: Verwenden Sie das Command Lookup Tool (nur registrierte Kunden), um weitere Informationen zu den in diesem Dokument verwendeten Befehlen zu erhalten.

Netzwerkdiagramm

In diesem Dokument wird die Netzwerkeinrichtung verwendet, die im Diagramm hier gezeigt wird:

voip_fr_mp_1.gif

Konfigurationen

In diesem Dokument werden folgende Konfigurationen verwendet:

Hub-Router in New York 
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname newyork
!
logging buffered 50000 debugging
enable secret < password > [Choose a strong password with 
at least one capital letter, one number, and one special character.]
!
controller T1 2/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-4 type e&m-wink-start
!
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay traffic-shaping

!--- This CLI command enables traffic shaping for both PVCs.

!
interface Serial2/0.1 point-to-point
description Connection to Raleigh PVC
ip address 172.16.120.2 255.255.255.0
  frame-relay interface-dlci 100
  class class-raleigh
!
interface Serial2/0.2 point-to-point
description Connection to San Jose PVC
ip address 172.16.130.2 255.255.255.0
frame-relay interface-dlci 200
  class class-sanjose
!
ip classless
!
map-class frame-relay class-raleigh
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80

!--- Recommended fragment size for 10ms delay when carrying voice !--- traffic based on the configured CIR 64000. !--- based on the configured CIR 64000 
 frame-relay ip rtp priority 16384 16383 48

!--- Two calls with g729, no CRTP, at 24 kbps/each. 
 !
map-class frame-relay class-sanjose
 frame-relay cir 192000
 frame-relay bc 1920
 frame-relay be 0
 frame-relay mincir 192000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 240

!--- This is the recommended fragment size for 10ms delay when carrying voice traffic !--- based on the configured CIR 192000.

frame-relay ip rtp priority 16384 16383 48 

!--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach. 
!
!
voice-port 2/0:1
!
dial-peer cor custom
!
dial-peer voice 100 pots

!--- Calls to the Public Switched Telephone Network (PSTN). 
 destination-pattern 212.......
prefix 212
port 2/0:1
!
dial-peer voice 200 pots

!--- Calls to the corporate network-four digit extension forwarded. 
destination-pattern 567....
 port 2/0:1
!
dial-peer voice 110 voip

!--- Calls to Raleigh.

destination-pattern 919392....
session target ipv4:172.16.120.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
dial-peer voice 210 voip    
!--- Calls to San Jose. 
destination-pattern 408527....
session target ipv4:172.16.130.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Der Befehl ip qos dscp wurde in IOS Version 12.2(2)T eingeführt, um den Befehl ip-peer (dial-peer) zu ersetzen.

Der Befehl frame-relais ip rtp priority reserviert eine strikte Prioritätswarteschlange für eine Reihe von RTP-Paketflüssen, die zu einem Bereich von UDP-Zielports (User Datagram Protocol) gehören.

Hinweis: Da der Befehl frame-relais ip rtp priority (Frame-Relay-IP-RTP-Priorität) absolute Priorität gegenüber anderem Datenverkehr bietet, verwenden Sie diesen Befehl mit Vorsicht. Wenn der Datenverkehr im Fall einer Überlastung die konfigurierte Bandbreite überschreitet, wird der gesamte überschüssige Datenverkehr verworfen.

Cisco 3640 Raleigh 
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname raleigh3640a
!

logging buffered 50000 debugging
enable secret < password > [Choose a strong password with at 
least one capital letter, one number, and one special character.]
!
no ip subnet-zero
!
!
!
!
voice-port 1/0/0
!
voice-port 1/0/1
dial-peer voice 1 pots
 destination-pattern 9193924100
port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 2126789001
  ip qos dscp cs5 media
 dtmf-relay h245-alphanumeric
 session target ipv4: 172.16.120.2 
!

interface Loopback0
 ip address 172.16.125.1 255.255.255.255
 no ip directed-broadcast
!

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.1 point-to-point
description Connection to New York
 ip address 172.16.120.1 255.255.255.0

 frame-relay interface-dlci 100
  class fr_class_voip  
!
!
ip classless
no ip http server
!
!
map-class frame-relay fr_class_voip
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment  80


!--- The recommended fragment size for 10ms delay when carrying voice traffic.


!--- based on the configured CIR 64000. 

  frame-relay ip rtp priority 16384 16383 48
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Überprüfen

Dieser Abschnitt enthält Informationen, mit denen Sie bestätigen können, dass Ihre Konfiguration funktioniert.

Bestimmte show-Befehle werden vom Output Interpreter Tool unterstützt (nur registrierte Kunden), mit dem Sie eine Analyse der show-Befehlsausgabe anzeigen können.

  • show frame-relais fragment: Zeigt Informationen über die Frame-Relay-Fragmentierung an, die auf dem Cisco Router stattfindet.

  • show traffic-shape queue: Zeigt Informationen über die Elemente an, die auf der Ebene der Data-Link Connection Identifier (DLCI) für den virtuellen Circuit (VC) in die Warteschlange gestellt werden. Mit diesem Befehl wird der Betrieb der IP-RTP-Priorität gegenüber Frame Relay überprüft. Wenn die Verbindung überlastet ist, werden Sprachströme mit einem Gewicht von Null identifiziert. Dies weist darauf hin, dass der Sprachfluss die Prioritätswarteschlange verwendet. Siehe mitgelieferte Beispielausgabe.

  • show frame-relais pvc [dlci#]: Zeigt Informationen wie Traffic Shaping-Parameter, Fragmentierungswerte und verlorene Pakete an. Weitere Informationen finden Sie in der hier bereitgestellten Beispielausgabe sowie im umfassenden Leitfaden zur Konfiguration und Fehlerbehebung von Frame Relay.

newyork#show frame-relay fragment

interface   dlci   frag-type   frag-size   in-frag   out-frag   dropped-frag
 
Serial1/0.1 100    end-to-end    80          16        20           0 

Serial1/0.2 200    end-to-end    240         12        10           0 

newyork#show traffic-shape  serial 2/0.1
Interface Se2/0.1

     Access    Target   Byte   Sustain   Excess   Interval    Increment    Adapt
VC   List      Rate     Limit  bits/int  bits/int (ms)        (bytes)      Active

100            64000    80     640       0         10          80          -
  
newyork#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0.1 dlci 100
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
     Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 16 kilobits/sec

Traffic queued in shaping queue on Serial2/0.2 dlci 200
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
    Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 144 kilobits/sec

newyork#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1


input pkts 1078          output pkts 1078         in bytes 157792
out bytes 172284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 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 28        out bcast bytes 8498
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:27:48, last time pvc status changed 00:27:48
Queueing strategy: weighted fair
Current fair queue configuration:
	Discard     Dynamic      Reserved
	threshold   queue count  queue count
		64          16           0
Output queue size 0/max total 600/drops 0
fragment type end-to-end        fragment size 80
cir 64000     bc   640       be 0         limit 80     interval 10
mincir 64000     byte increment 80    BECN response no  IF_CONG no
frags 2707      bytes 172284    frags delayed 2707      bytes delayed 172284
shaping inactive
traffic shaping drops 0
ip rtp priority parameters 16384 32767 48000

Fehlerbehebung

Dieser Abschnitt enthält Informationen zur Fehlerbehebung in Ihrer Konfiguration.

Fehlerbehebungsverfahren

Hier finden Sie Informationen und Anweisungen zur Fehlerbehebung, die für diese Konfiguration relevant sind:

  1. Führen Sie eine Fehlerbehebung für Frame Relay und QoS durch, die für Sprache implementiert sind, und stellen Sie sicher, dass der Frame richtig funktioniert.

  2. Fahren Sie ggf. mit der Fehlerbehebung bei Sprachanrufen fort.

    Hinweis: Weitere Informationen zur Fehlerbehebung finden Sie unter VoIP over Frame Relay mit QoS (Fragmentation, Traffic Shaping, LLQ/IP RTP Priority).

Befehle zur Fehlerbehebung

Das Output Interpreter Tool (nur registrierte Kunden) (OIT) unterstützt bestimmte show-Befehle. Verwenden Sie das OIT, um eine Analyse der Ausgabe des Befehls show anzuzeigen.

Hinweis: Beachten Sie vor der Verwendung von Debug-Befehlen die Informationen zu Debug-Befehlen.

  • debug priority (Debug-Priorität): Zeigt PQ-Ereignisse (Priority Queueing) an und zeigt an, ob ein Drop in dieser Warteschlange auftritt. Weitere Informationen finden Sie unter Fehlerbehebung bei Ausgabeverlusten mit Prioritätswarteschlange.

  • debug frame-relais fragment: Zeigt Ereignis- oder Fehlermeldungen bezüglich der Frame-Relay-Fragmentierung an. Dieser Befehl ist nur auf PVC-Ebene auf der ausgewählten Schnittstelle aktiviert.

    newyork#debug priority 
Priority output queueing debugging is on
newyork#ping 172.16.120.1
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
newyork# 
*Mar  1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2)
*Mar  1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2)
*Mar  1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) 

newyork#debug frame-relay fragment interface serial 2/0 100
This may severely impact network performance.
You are advised to enable no logging console debug. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial2/0 dlci 100 only

*Mar  1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, 
B bit set, frag_hdr 03 B1 9C 3D
*Mar  1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, 
E bit set, frag_hdr 03 B1 5C 3E
*Mar  1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, 
exp_seq-num 17,B bit set,
	 frag_hdr 03 B1 80 11
*Mar  1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, 
exp_seq-num 18,E bit set,
	 frag_hdr 03 B1 40 12

Zugehörige Informationen

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
06-Jul-2007
Erstveröffentlichung

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren