VoIP over Frame Relay mit Quality of Service (Fragmentierung, Traffic Shaping, LLQ/IP RTP-Priorität)

Einführung

Dieses Dokument zeigt eine Beispielkonfiguration für eine VoIP-Verbindung (Voice over IP) über ein Frame Relay-Netzwerk mit Quality of Service (QoS). Dieses Dokument enthält technische Hintergrundinformationen zu den konfigurierten Funktionen, Designrichtlinien sowie grundlegende Verifizierungs- und Fehlerbehebungsstrategien.

Beachten Sie, dass die Konfiguration in diesem Dokument über zwei Sprach-Router verfügt, die mit dem Frame Relay-Netzwerk verbunden sind. In vielen Topologien können die sprachfähigen Router jedoch überall vorhanden sein. In der Regel verwenden die Sprach-Router LAN-Verbindungen zu anderen Routern, die mit dem WAN verbunden sind. Dies ist wichtig, da alle WAN-Konfigurationsbefehle auf den mit dem WAN verbundenen Routern und nicht auf den Sprach-Routern konfiguriert werden müssen, wenn die Sprach-Router nicht direkt mit dem Frame-Relay-Netzwerk verbunden sind, wie in den Konfigurationen in diesem Dokument gezeigt.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

• Cisco 3640 Router mit Cisco IOS® Softwareversion 12.2.6a (Enterprise Plus)

• Cisco 2621 Router mit Cisco IOS Software Release 12.2.6a (Enterprise Plus)

• Low Latency Queueing (LLQ) auf PVCs (Frame Relay Permanent Virtual Circuits). Diese Version wurde in der Cisco IOS Software, Version 12.1.(2)T, eingeführt.

• Frame Relay IP Real-Time Transport Protocol (RTP) Priority, die in der Cisco IOS Software, Version 12.0(7)T, eingeführt wurde.

• Frame Relay Forum (FRF).12 Fragmentation (Fragmentation), die in Cisco IOS Software, Version 12.0(4)T, eingeführt wird.

• Cisco IOS Software Releases nach 12.0.5T enthalten erhebliche Leistungsverbesserungen für komprimiertes RTP (cRTP).

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 in den Cisco Technical Tips Conventions.

QoS-Designrichtlinien für VoIP over Frame Relay

Es gibt zwei grundlegende Voraussetzungen für eine gute Sprachqualität:

• Minimale End-to-End-Verzögerung und Jittervermeidung (Verzögerungsschwankungen)

• Optimierte und korrekt konstruierte Anforderungen an die Verbindungsbandbreite

Verwenden Sie folgende Richtlinien, um die oben genannten Anforderungen zu gewährleisten:

• Strict Priority für Voice Traffic LLQ oder IP RTP Priority

• Frame Relay Traffic Shaping (FRTS) für Sprache

• Fragmentierung FRF.12

• Bandbreitenreduzierung

Strict Priority für Sprachverkehr (LLQ- oder IP RTP-Priorität)

Es gibt zwei primäre Methoden für die strikte Priorisierung von Sprachdatenverkehr:

• IP RTP Priority (auch Prioritätswarteschlange/Weighted Fair Queuing (PQ/WFQ) genannt)

• LLQ (auch als PQ/Class Based Weighted Fair Queuing (PQ/CBWFQ) bezeichnet)

IP RTP-Priorität

Frame Relay IP RTP Priority erstellt eine Warteschlange mit strikter Priorität auf Frame Relay PVC für eine Reihe von RTP-Paketflüssen, die zu einem Bereich von UDP-Zielports (User Datagram Protocol) gehören. Während die tatsächlich verwendeten Ports dynamisch zwischen Endgeräten oder Gateways ausgehandelt werden, nutzen alle Cisco VoIP-Produkte denselben UDP-Portbereich (16384 bis 32767). Sobald der Router den VoIP-Datenverkehr erkennt, platziert er ihn in den strikten PQ. Wenn der PQ leer ist, werden die anderen Warteschlangen basierend auf dem Standard-WFQ verarbeitet. Die IP RTP-Priorität wird erst aktiviert, wenn eine Überlastung der Schnittstelle vorliegt. Dieses Bild veranschaulicht den Betrieb der IP-RTP-Priorität:

Hinweis: Die IP RTP-Priorität ermöglicht das Bursting des PQ, wenn in der Standardwarteschlange (WFQ) Bandbreite verfügbar ist. Sie überwacht jedoch streng den PQ-Inhalt, wenn eine Überlastung der Schnittstelle vorliegt.

LLQ

LLQ ist eine Funktion, die CBWFQ einen strikten PQ bereitstellt. LLQ aktiviert einen einzigen strengen PQ innerhalb der CBWFQ auf Klassenebene. Bei LLQ werden verzögerungsempfindliche Daten (im PQ) zunächst in die Warteschlange gestellt und gesendet. In einem VoIP mit LLQ-Implementierung wird Sprachdatenverkehr in den strikten PQ gesetzt.

Der PQ wird so geregelt, dass sichergestellt wird, dass den fairen Warteschlangen keine Bandbreite fehlt. Wenn Sie die Telefonzentrale konfigurieren, geben Sie in Kbit/s die maximale Bandbreite an, die für die Telefonzentrale verfügbar ist. Wenn die Schnittstelle überlastet ist, wird der PQ so lange gewartet, bis die Last den konfigurierten Kbit/s-Wert in der Prioritätsanweisung erreicht. Der übermäßige Datenverkehr wird dann fallen gelassen, um das Problem zu vermeiden, dass die unteren Hauptquartiere der Prioritätsgruppe von Cisco verliert werden.

Hinweis: Bei LLQ für Frame Relay werden Warteschlangen auf PVC-Basis eingerichtet. Jede PVC verfügt über einen PQ und eine zugewiesene Anzahl an Warteschlangen.

Diese Methode ist komplexer und flexibler als IP RTP Priority. Die Wahl zwischen den Methoden muss auf den Datenverkehrsmustern in Ihrem Netzwerk und Ihren Anforderungen basieren.

LLQ und IP RTP-Priorität

In dieser Tabelle sind die Hauptunterschiede zwischen LLQ und IP RTP Priority zusammengefasst und Richtlinien zur Verwendung der einzelnen Methoden aufgeführt.

FRTS für Sprache

FRTS stellt Parameter bereit, die zur Verwaltung von Netzwerkverkehrsengpässen nützlich sind. FRTS beseitigt Engpässe in Frame-Relay-Netzwerken durch Hochgeschwindigkeitsverbindungen zum zentralen Standort und langsame Verbindungen zu den Außenstellen. Sie können Durchsetzungswerte für die Durchsatzrate konfigurieren, um die Geschwindigkeit zu begrenzen, mit der Daten von der virtuellen Leitung (VC) in der Zentrale gesendet werden.

Diese Definitionen beziehen sich auf FRTS:

• Committed Information Rate (CIR) - Rate (Bits pro Sekunde), die der Frame-Relay-Provider für die Datenübertragung garantiert. Die CIR-Werte werden vom Frame Relay-Service Provider festgelegt und vom Benutzer auf dem Router konfiguriert.

  Hinweis: Die Port-/Schnittstellenzugriffsrate kann höher als die CIR sein. Die Rate wird über einen Zeitraum des Committed Rate Measurement Interval (Tc) gemittelt.

• Committed Burst (Bc) - Die maximale Anzahl von Bits, die das Frame Relay-Netzwerk über einen Computer übertragen möchte. Tc = Bc/CIR

• Exzess Burst (Be) - Die maximale Anzahl nicht bestätigter Bits, die der Frame-Relay-Switch über den CIR über den Tc übertragen versucht.

• Committed Rate Measurement Interval (Tc) - Zeitintervall, über das bc- oder (Bc+ Be)-Bits übertragen werden. Tc wird berechnet als Tc = Bc/CIR. Der Tc-Wert wird nicht direkt auf Cisco Routern konfiguriert. Sie wird nach der Konfiguration der Bc- und CIR-Werte berechnet. Tc darf 125 ms nicht überschreiten.

• Backwards Explicit Congestion Notification (BECN) - Ein Bit im Frame-Relay-Frame-Header, das auf eine Überlastung im Netzwerk hinweist. Wenn ein Frame-Relay-Switch Überlastungen erkennt, legt er das BECN-Bit für Frames fest, die für den Quellrouter bestimmt sind, und weist den Router an, die Übertragungsrate zu reduzieren.

Die Konfiguration von FRTS für Sprachdatenverkehr unterscheidet sich von der Konfiguration von Traffic Shaping nur für Daten. Bei der Konfiguration von FRTS für Sprachqualität werden Kompromisse mit den Datenverkehrsparametern eingegangen. Weitere Informationen zu diesen Einschränkungen finden Sie im Abschnitt Fragmentation (FRF.12) in diesem Dokument.

Fragmentierung (FRF.12)

Eine große Herausforderung bei der Integration von Sprachdaten besteht darin, die maximale End-to-End-Verzögerung bei verzögerungsempfindlichem Datenverkehr wie Sprache zu kontrollieren. Für eine gute Sprachqualität muss diese Verzögerung weniger als 150 ms betragen. Ein wichtiger Teil dieser Verzögerung ist die Serialisierungsverzögerung für die Schnittstelle. Cisco empfiehlt, dass der Wert 10 ms beträgt und 20 ms nicht überschreiten sollte. Die Serialisierungsverzögerung ist die Zeit, die erforderlich ist, um die Bits auf einer Schnittstelle zu platzieren.

Serialization Delay = frame size (bits) / link bandwidth (bps)

Ein 1500-Byte-Paket beispielsweise benötigt 214 ms, um den Router über eine 56-Kbit/s-Verbindung zu verlassen. Wenn ein nicht-Echtzeit-Datenpaket von 1.500 Byte gesendet wird, werden Echtzeit-Datenpakete (Sprache) in die Warteschlange gestellt, bis das große Datenpaket übertragen wird. Diese Verzögerung ist für Sprachdatenverkehr inakzeptabel. Wenn Datenpakete, die nicht in Echtzeit vorliegen, in kleinere Frames fragmentiert werden, werden sie mit Echtzeit-Frames (Sprache) verschachtelt. Auf diese Weise können Sprach- und Daten-Frames auf Low-Speed-Verbindungen übertragen werden, ohne dass der Echtzeit-Sprachdatenverkehr übermäßig verzögert wird.

Weitere Informationen zur Fragmentierung finden Sie unter Frame Relay Fragmentation for Voice.

Hinweis: Wenn Sie über eine dedizierte halbe T1-Verbindung (768 Kbit/s) verfügen, benötigen Sie wahrscheinlich keine Fragmentierungsfunktion. Sie benötigen jedoch weiterhin einen QoS-Mechanismus (in diesem Fall IP RTP Priority oder LLQ). Die halbe T1-Geschwindigkeit oder höhere Geschwindigkeit bieten genügend Bandbreite, um Sprachpakete innerhalb des empfohlenen Serialisierungsverzögerungsbereichs (10 ms, nicht später als 20 ms) in die Warteschlange einspeisen und diese verlassen zu können. Außerdem benötigen Sie wahrscheinlich kein cRTP, das bei einem vollständigen T1-Header die IP-RTP-Header komprimiert, um Bandbreite zu sparen.

Bandbreitenreduzierung

cRTP

Basierend auf RFC 2508 komprimiert die cRTP-Funktion den IP/UDP/RTP-Paket-Header von 40 Byte auf 2 oder 4 Byte. Dadurch wird die unnötige Bandbreitennutzung reduziert. Es ist ein Hop-by-Hop-Komprimierungsschema. Daher muss cRTP auf beiden Seiten der Verbindung konfiguriert werden, es sei denn, die passive Option ist konfiguriert.

Hinweis: cRTP ist nicht erforderlich, um eine gute Sprachqualität sicherzustellen. Diese Funktion reduziert die Bandbreitennutzung. Konfigurieren Sie cRTP, nachdem alle anderen Bedingungen erfüllt sind und die Sprachqualität gut ist. Dieses Verfahren spart Zeit bei der Fehlerbehebung, da potenzielle cRTP-Probleme isoliert werden.

Überwachen Sie die CPU-Auslastung des Routers. Deaktivieren Sie cRTP, wenn es über 75 % liegt. Bei höheren Verbindungsraten können die Bandbreiteneinsparungen durch cRTP möglicherweise durch die zusätzliche CPU-Last aufgewogen werden. Cisco empfiehlt die Verwendung von cRTP mit Verbindungen unter 768 Kbit/s, es sei denn, der Router wird mit einer niedrigen CPU-Auslastung ausgeführt.

Hinweis: Da kein Standard vorhanden ist, wurde cRTP für Frame Relay auf der proprietären Kapselung von Cisco entwickelt. Daher funktioniert es nicht mit der IETF-Kapselung (Internet Engineering Task Force) von Frame Relay. Kürzlich wurde FRF.20 fertig gestellt, um eine RTP-Header-Komprimierung auf der IETF-Kapselung zu ermöglichen. Seit der letzten Aktualisierung dieses Dokuments (Mai 2002) wird FRF.20 jedoch nicht unterstützt.

Weitere Informationen finden Sie unter Komprimiertes Echtzeit-Transportprotokoll.

Auswahl von Coder/Decoder (Codec)

Verwenden Sie Codecs mit niedriger Bitrate für die VoIP-Anrufabschnitte. G.729 (8 Kbit/s) ist der Standardcodec für den VoIP-Dial-Peer.

Hinweis: Obwohl Dual-Tone-Mehrfrequenzwahlverfahren (DTMF) normalerweise bei Verwendung von Sprachcodecs mit hoher Bitrate (z. B. G.711) akkurat übertragen werden, sind Codecs mit niedriger Bitrate (z. B. G.729 und G.723.1) für Sprachmuster hochoptimiert und neigen dazu, DTMF-Töne zu verzerren. Dieser Ansatz kann zu Problemen beim Zugriff auf interaktive Sprachdialogsysteme (IVR) führen. Der Befehl dtmf relais löst das Problem der DTMF-Verzerrung. Es transportiert DTMF-Töne Out-of-Band oder separat vom kodierten Sprachstream. Wenn Sie Codecs mit niedriger Bitrate (G.729, G.723) verwenden, aktivieren Sie den Befehl dtmf relais unter dem VoIP-Dial-Peer.

Voice Activity Detection (VAD) aktivieren

Ein typisches Gespräch kann 35 bis 50 Prozent Schweigen beinhalten. Pausenpakete werden bei Verwendung von VAD unterdrückt. Bei der Planung der VoIP-Bandbreite sollten Sie davon ausgehen, dass VAD die Bandbreite um 35 Prozent reduziert. VAD wird standardmäßig unter den VoIP-DFÜ-Peers konfiguriert.

Konfigurieren

In diesem Abschnitt erhalten Sie Informationen zum Konfigurieren der in diesem Dokument beschriebenen Funktionen.

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

LLQ

Verwenden Sie dieses Verfahren, um LLQ zu konfigurieren:

1. Erstellen Sie eine Klassenzuordnung für VoIP-Datenverkehr, und definieren Sie Anpassungskriterien.

   In diesen Befehlen wird erklärt, wie diese Aufgabe ausgeführt wird:

   maui-voip-sj(config)#class-map ?
          WORD 		class-map name
          match-all 	Logical-AND all matching statements under this classmap
          match-any 	Logical-OR all matching statements under this classmap
   maui-voip-sj(config)#class-map match-all voice-traffic 
   
   !--- Choose a descriptive class_name. 
   
   
   maui-voip-sj(config-cmap)#match ?
     access-group         Access group
     any                  Any packets
     class-map            Class map
     cos                  IEEE 802.1Q/ISL class of service/user priority values
     destination-address  Destination address
     input-interface      Select an input interface to match
     ip                   IP specific values
     mpls                 Multi Protocol Label Switching specific values
     not                  Negate this match result
     protocol             Protocol
     qos-group            Qos-group
     source-address       Source address
   
   !--- In this example the access-group matching !--- option is used for its flexibility (it uses an access-list).
   
   
   maui-voip-sj(config-cmap)#match access-group ?
     <1-2699>  Access list index
     name      Named Access List
   maui-voip-sj(config-cmap)#match access-group 102 
   
   
   !--- Create the access-list to match the class-map access-group:
   
   
   maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
   
   !--- The safest and easiest way is to match with UDP port range 16384-32767. !--- This is the port range Cisco IOS H.323 products utilize to transmit !--- VoIP packets.
   
   

   Diese Zugriffslisten werden auch verwendet, um Sprachdatenverkehr mit dem Befehl match access-group abzustimmen:

   access-list 102 permit udp any any precedence critical
   
   !--- This list filters traffic based on the IP packet TOS: Precedence field. !--- Note: Ensure that the other non-voice traffic does not use the !--- same precedence value.
   
   
   access-list 102 permit udp any any dscp ef
   
   !--- In order for this list to work, ensure that VoIP packets are tagged !--- with the dscp ef code before they exit on the LLQ WAN interface. !--- For more information on DSCP, refer to !--- Implementing Quality of Service Policies with DSCP. !--- Note: If endpoints are not trusted on their packet marking, !--- mark incoming traffic by applying an inbound service policy on an !--- inbound interface. This procedure is out of the scope !--- of this document. 
   
   
   access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
   
   !--- This access-list can be used in cases where the VoIP !--- devices cannot do precedence or DSCP marking and you !--- cannot determine the VoIP UDP port range.
    

   Hierbei handelt es sich um andere Zuordnungsmethoden, die anstelle von Zugriffsgruppenbefehlen verwendet werden können:

   • Mit der Cisco IOS Software Release 12.1.2.T und höher wird die IP RTP Priority-Funktionalität für LLQ implementiert. Diese Funktion entspricht dem Inhalt der Prioritätsklasse, der die konfigurierten UDP-Ports betrachtet. Es unterliegt der Einschränkung, dass nur Ports im PQ bedient werden.

     class-map voice
       match ip rtp 16384 16383
     

   • Bei diesen beiden Methoden wird davon ausgegangen, dass VoIP-Pakete vor Anwendung des ausgehenden LLQ-Vorgangs am ursprünglichen Host markiert oder im Router abgeglichen und markiert werden:

     class-map voice 
        match ip precedence 5
     

     ODER

     class-map voice
        match ip dscp ef
     

     Hinweis: In der Cisco IOS-Softwareversion 12.2.2T und höher können VoIP-Dial-Peers Sprachpakete und Signalisierungspakete vor dem LLQ-Vorgang markieren. Dies ermöglicht eine skalierbare Möglichkeit, VoIP-Pakete über DSCP-Codewerte für LLQ zu kennzeichnen und zuzuordnen. Weitere Informationen finden Sie unter Klassifizieren von VoIP-Signalisierung und Medien mit DSCP für QoS.

     Router(config-dial-peer)#ip qos dscp ?
     

2. Erstellen Sie eine Klassenzuordnung für die VoIP-Signalisierung, und definieren Sie Anpassungskriterien (optional).

   Verwenden Sie die folgenden Befehle, um diese Aufgabe durchzuführen:

   class-map voice-signaling
     match access-group 103
   !
   access-list 103 permit tcp any eq 1720 any
   access-list 103 permit tcp any any eq 1720
   

   Hinweis: VoIP-Anrufe können über H.323, Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP) oder Skinny Call Control Protocol (SCCP) - ein proprietäres Protokoll, das von Cisco Call Manager verwendet wird, eingerichtet werden. Im vorherigen Beispiel wird von H.323 Fast Connect ausgegangen. Diese Liste dient als Referenz für die Ports, die von VoIP-Signalisierungs- und Steuerungskanälen verwendet werden:

   • H.323/H.225 = TCP 1720

   • H.323/H.245 = TCP 11xxx (Standard-Connect)

   • H.323/H.245 = TCP 1720 (Fast Connect)

   • H.323/H.225 RAS = UDP 1718 (zu GateKeeper)

   • SCCP = TCP 2000-2002 (CM-Encore)

   • ICCP = TCP 8001-8002 (CM-Encore)

   • MGCP = UDP 2427, TCP 2428 (CM-Encore)

   • SIP= UDP 5060, TCP 5060 (konfigurierbar)

3. Erstellen Sie eine Richtlinienzuordnung, und ordnen Sie sie den VoIP-Klassenzuordnungen zu.

   Der Zweck der Richtlinienzuordnung besteht darin, festzulegen, wie die Link-Ressourcen für die verschiedenen Zuordnungsklassen freigegeben oder zugewiesen werden. Verwenden Sie die folgenden Befehle, um diese Aufgabe durchzuführen:

   maui-voip-sj(config)#policy-map VOICE-POLICY
   
   !--- Choose a descriptive policy_map_name.
   
   
   maui-voip-sj(config-pmap)#class voice-traffic
   maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
   
   !--- Configure the voice-traffic class to the strict PQ !--- (priority command) and assign the bandwidth.
   
   
   maui-voip-sj(config-pmap)#class voice-signaling
   maui-voip-sj(config-pmap-c)#bandwidth 8
   
   !--- Assign 8 Kbps to the voice-signaling class.
   
   
   maui-voip-sj(config-pmap)#class class-default
   maui-voip-sj(config-pmap-c)#fair-queue 
   
   !--- The remaining data traffic is treated as WFQ.
   
   

   Hinweis: Obwohl es möglich ist, verschiedene Arten von Echtzeit-Datenverkehr an den PQ anzuhängen, empfiehlt Cisco, nur Sprachdatenverkehr an diesen weiterzuleiten. Datenverkehr in Echtzeit, z. B. Videodaten, kann zu Schwankungen bei der Verzögerung führen (der PQ ist eine FIFO-Warteschlange (First In First Out)). Sprachdatenverkehr erfordert, dass die Verzögerung nicht variabel ist, um Jitter zu vermeiden.

   Hinweis: Die Summe der Werte für Prioritäts- und Bandbreitenanweisungen muss kleiner/gleich minCIR für die PVC sein. Andernfalls kann der Link nicht mit dem Befehl service-policy zugewiesen werden. minCIR ist standardmäßig die Hälfte der CIR. Um Fehlermeldungen anzuzeigen, stellen Sie sicher, dass der Befehl logging console für den Konsolenzugriff aktiviert ist und der Befehl terminal monitor für den Telnet-Zugriff aktiviert ist.

   Weitere Informationen zu Bandbreite und Prioritätsbefehlen finden Sie unter Vergleichen der Bandbreite und der Prioritätsbefehle einer QoS-Dienstrichtlinie.

4. Aktivieren Sie LLQ, indem Sie die Richtlinienzuordnung auf die ausgehende WAN-Schnittstelle anwenden.

   Verwenden Sie die folgenden Befehle, um LLQ zu aktivieren:

   maui-voip-sj(config)#map-class frame-relay VoIPovFR
   maui-voip-sj(config-if)#service-policy output VOICE-POLICY
   
   !--- The service-policy is applied to the PVC !--- indirectly by configuring !--- it under the map-class associated to the PVC.
   
   

IP RTP-Priorität

Wenn Sie LLQ nicht verwenden, verwenden Sie die folgenden Richtlinien:

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port  
port-range  bandwidth 

• start-rtp-port: Die Start-UDP-Portnummer. Die niedrigste Portnummer, an die die Pakete gesendet werden. Legen Sie für VoIP diesen Wert auf 16384 fest.

• port-range - Der Bereich der UDP-Zielports. Die dem Start-RTP-Port hinzugefügte Zahl ergibt die höchste UDP-Portnummer. Legen Sie für VoIP diesen Wert auf 16383 fest.

• bandwidth - Maximal zulässige Bandbreite in Kbit/s für die Prioritätswarteschlange. Legen Sie diese Nummer basierend auf der Anzahl der gleichzeitigen Anrufe fest, indem Sie die Bandbreite jedes Anrufs pro Anruf hinzufügen, den das System unterstützt.

Beispielkonfiguration:

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Traffic Shaping für Sprache

Verwenden Sie diese Richtlinien, wenn Sie Traffic Shaping für Sprache konfigurieren:

• Die CIR der PVC nicht überschreiten.

• Deaktivieren Sie Frame Relay Adaptive Shaping.

• Legen Sie den Bc-Wert niedrig so fest, dass Tc (Shaping-Intervall) 10 ms (Tc = Bc/CIR) beträgt. Konfigurieren Sie den Bc-Wert so, dass der gewünschte Tc-Wert erzwungen wird.

• Legen Sie den Wert Be auf 0 fest.

Weitere Informationen zu diesen Richtlinien finden Sie unter Frame Relay Traffic Shaping für VoIP und VoFR.

Hinweis: Einige Kunden verwenden separate PVCs für Daten und Sprache. Wenn Sie zwei separate PVCs haben und bei der Sprach-PVC unter oder unter der CIR platzieren möchten, leidet die Sprachqualität weiterhin, da diese PVCs dieselbe physische Schnittstelle verwenden. In solchen Fällen müssen sowohl der Frame-Relay-Anbieter als auch der Router die Sprach-PVC priorisieren. Letzteres kann über PVC Interface Priority Queueing (PIPQ) erfolgen, das ab Version 12.1(1)T der Cisco IOS-Software verfügbar ist.

Fragmentierung (FRF.12)

Aktivieren Sie die Fragmentierung für Verbindungen mit niedriger Geschwindigkeit (weniger als 768 Kbit/s). Legen Sie die Fragmentgröße so fest, dass Sprachpakete nicht fragmentiert werden und keine Serialisierungsverzögerung von mehr als 20 ms auftreten. Legen Sie die Fragmentierungsgröße basierend auf der niedrigsten Portgeschwindigkeit zwischen den Routern fest. Wenn es z. B. eine Hub-and-Spoke-Frame-Relay-Topologie gibt, bei der der Hub eine T1-Geschwindigkeit hat und die Remote-Router eine Portgeschwindigkeit von 64.000 aufweisen, muss die Fragmentierungsgröße für die 64.000-Geschwindigkeit auf beiden Routern festgelegt werden. Alle anderen PVCs, die dieselbe physische Schnittstelle verwenden, müssen die Fragmentierung in der von der Sprach-PVC verwendeten Größe konfigurieren. Verwenden Sie dieses Diagramm, um die Werte für die Fragmentierungsgröße zu bestimmen.

Beispielkonfiguration:

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Hinweis: Für 1536 Kbit/s ist keine Fragmentierung technisch erforderlich. Um das duale FIFO-Warteschlangensystem zu aktivieren, ist jedoch eine Fragmentierung erforderlich, um die Sprachqualität sicherzustellen. Bei einer Fragmentgröße von 1600 Byte wird die doppelte FIFO aktiviert. Da jedoch 1600 Byte über der MTU (Maximum Transmission Unit) der typischen seriellen Schnittstelle liegen, werden große Datenpakete nicht fragmentiert.

Netzwerkdiagramm

In diesem Dokument wird die in diesem Diagramm dargestellte Netzwerkeinrichtung verwendet:

Konfigurationen

In diesem Dokument werden die folgenden Konfigurationen verwendet:

• maui-voip-sj (Cisco 3640)

• maui-voip-austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- Definition of the voice signaling and traffic class maps. !--- "voice-traffic" class uses access-list 102 for its matching criteria. !--- "voice-signaling" class uses access-list 103 for its matching criteria.

class-map match-all voice-signaling
 match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!--- The policy map defines how the link resources are assigned !--- to the different map classes. In this configuration, strict PQ !--- is assigned to the voice-traffic class !--- with a maximum bandwidth of 45 Kbps.
 

policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  class voice-signaling
  bandwidth 8


!--- Assigns a queue for voice-signaling traffic that ensures 8 Kbps. !--- Note that this is optional and has nothing to do with good voice !--- quality. Instead, it is a way to secure signaling.


  class class-default
  fair-queue


!--- The class-default class is used to classify traffic that does !--- not fall into one of the defined classes. !--- The fair-queue command associates the default class WFQ queueing.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not !--- enabled, then map-class does not start and FRF.12 and LLQ does !--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class. !--- See the map-class frame-relay VoIPovFR command here: !--- Note: The word VoIPovFR is selected by the user. !

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal !--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although adaptive shaping is disabled, make CIR equal minCIR !--- as a double safety. By default minCIR is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes. !--- This value is based on the port speed of the slowest path link. !--- This command also enables dual-FIFO.

!
access-list 102 permit udp any any range 16384  32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!

!--- access-list 102 matches VoIP traffic !--- based on the UDP port range. !--- Both odd and even ports are put into the PQ. !--- access-list 103 matches VoIP signaling protocol. In this !--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
ip subnet-zero
!
class-map match-all voice-signaling
match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache 
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Überprüfung und Fehlerbehebung

Dieser Abschnitt enthält Informationen zur Bestätigung, dass Ihre Konfiguration ordnungsgemäß funktioniert.

Bestimmte show-Befehle werden vom Output Interpreter Tool unterstützt (nur registrierte Kunden). Dadurch können Sie eine Analyse der Ausgabe des Befehls show anzeigen.

LLQ/IP RTP-Prioritätsbefehle

Diese Befehle zum Anzeigen und Debuggen helfen Ihnen, die Konfigurationen der LLQ- und IP-RTP-Priorität zu überprüfen.

• show policy-map interface Serial interface#: Dieser Befehl ist hilfreich, um den LLQ-Vorgang und alle Drops im PQ anzuzeigen. Weitere Informationen zu den verschiedenen Feldern dieses Befehls finden Sie unter Understanding Packet Counters in show policy-map interface Output.

• show policy-map policy_map_name: Zeigt Informationen über die Richtlinienzuordnungskonfiguration an.

• show queue interface-type interface-number: Führt die fair queueing-Konfiguration und Statistiken für eine bestimmte Schnittstelle auf.

• debug priority (Debug-Priorität): Zeigt PQ-Ereignisse an und zeigt an, ob diese Warteschlange verworfen wird. Weitere Informationen finden Sie unter Fehlerbehebung bei Ausgabeverlusten mit Prioritätswarteschlange.

• show class-map class_name: Zeigt Informationen über die Klassenzuordnungskonfiguration an.

• show call active voice - Überprüft auf DSP-Ebene, ob Pakete verloren gehen.

• show frame-relais ip rtp header-Komprimierung - Zeigt Statistiken zur RTP-Header-Komprimierung an.

Fragmentierungsbefehle

Verwenden Sie diese Debug- und Anzeige-Befehle, um Fragmentierungskonfigurationen zu überprüfen und Fehler zu beheben.

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

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

Frame-Relay-/Schnittstellenbefehle

Verwenden Sie diese show-Befehle, um die Frame-Relay-/Schnittstellenkonfigurationen zu überprüfen und Fehler zu beheben.

• show traffic-form queue interface (Datenverkehrsformwarteschlangenschnittstelle anzeigen): Zeigt Informationen zu den Elementen an, die auf der Ebene der VC Data-Link Connection Identifier (DLCI) in die Warteschlange gestellt wurden. Wird verwendet, um den Betrieb von IP RTP Priority over Frame Relay zu überprüfen. Wenn die Verbindung überlastet ist, werden Sprachströme mit einem Gewicht von Null identifiziert. Dies weist darauf hin, dass der Sprachfluss den PQ verwendet. Die Beispielausgabe finden Sie hier.

• show traffic-shape: Zeigt Informationen wie für Tc, Bc, Be und CIR konfigurierte Werte an. Siehe Beispielausgabe.

• show frame-relais pvc dlci-#: Zeigt Informationen wie Traffic Shaping-Parameter, Fragmentierungswerte und verlorene Pakete an. Siehe Beispielausgabe. Weitere Informationen finden Sie unter Problembehandlung bei Frame Relay.

Bekannte Probleme

Für jede VC LLQ wurde ein Fehler identifiziert, bei dem die PQ streng überwacht wurde, auch wenn die Schnittstelle nicht überlastet wurde. Dieser Fehler wurde behoben, und jetzt werden nicht konforme Sprachpakete nur verworfen, wenn auf dem VC eine Überlastung auftritt. Dadurch entspricht das Verhalten der VC LLQ dem anderer Schnittstellen, die LLQ verwenden. Dieses Verhalten wurde mit der Cisco IOS Software Version 12.2(3) und höher geändert.

Beispielausgabe für Befehle zum Anzeigen und Debuggen

Dies ist eine Beispielausgabe für das Anzeigen und Debuggen von Befehlen, die für die Überprüfung und Fehlerbehebung verwendet wird.

!--- To capture sections of this output, the LLQ PQ bandwidth !--- is lowered and large data traffic is placed !--- on the link to force packets drops. !--- Priority queue bandwidth is lowered to 10 Kbps to force drops from the PQ. !--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0
    
   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0

      

!--- These commands are useful to verify the LLQ configuration.
 
      
maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
   Class voice-signaling
        Weighted Fair Queueing
           Bandwidth 8 (kbps) Max Threshold 64 (packets)
   Class voice-traffic
        Weighted Fair Queueing
         Strict Priority
             Bandwidth 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
         Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic (id 3)
         Match access-group 102


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 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 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/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
 frags 13 bytes 962 frags delayed 8 bytes delayed 642
 
 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command !--- output, the PQ bandwidth is lowered and heavy traffic !--- is placed on the interface to force drops. 

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 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 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         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
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms, !--- CIR equals 64000 BPS, and BC equals 640. 

     
maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where !--- the routers are configured with IP RTP Priority instead of LLQ.
 

maui-voip-austin#show frame-relay PVC 100

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          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 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:   
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0 
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


!--- This command displays information of the VoIP dial-peers.
 
      
maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated: 
     type = voip, session-target = `ipv4:192.168.10.2',  
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort, 
         acc-qos = best-effort, 
     dtmf-relay = cisco-rtp, 
        fax-rate = voice,   payload size =  20 bytes
     codec = g729r8,    payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
     VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

Zugehörige Informationen

• Low Latency Queuing für Frame-Relay
• Klassifizierung von VoIP-Signalisierung und Medien mit DSCP für QoS
• Befehle für Frame-Relay-Traffic-Shaping anzeigen
• Frame Relay IP RTP-Priorität
• Konfigurieren von Frame-Relay- und Frame-Relay-Traffic-Shaping
• Konfiguration und Fehlerbehebung von Frame Relay
• Verbesserte Sprachübertragung über Frame-Relay-Warteschlangen
• Unterstützung von Sprachtechnologie
• Produkt-Support für Sprach- und IP-Kommunikation
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support - Cisco Systems