QoS – Häufig gestellte Fragen
Inhalt
Einleitung
Dieses Dokument befasst sich mit den am häufigsten gestellten Fragen zu Quality of Service (QoS).
Allgemein
Frage: Was ist Quality of Service (QoS)?
A. QoS bezeichnet die Fähigkeit eines Netzwerks, besseren Service für ausgewählten Netzwerkverkehr über verschiedene zugrunde liegende Technologien bereitzustellen, darunter Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet- und 802.1-Netzwerke, SONET und IP-geroutete Netzwerke.
QoS ist eine Sammlung von Technologien, die es Anwendungen ermöglichen, vorhersehbare Servicelevel in Bezug auf Datendurchsatzkapazität (Bandbreite), Latenzvariationen (Jitter) und Verzögerung anzufordern und zu empfangen. Insbesondere bieten QoS-Funktionen einen besseren und besser vorhersehbaren Netzwerkdienst, indem sie folgende Methoden anwenden:
Unterstützung dedizierter Bandbreite.
Verbesserung der Verlusteigenschaften.
Vermeidung und Management von Netzwerküberlastungen.
Steuerung des Netzwerkverkehrs.
Festlegen von Datenverkehrsprioritäten im gesamten Netzwerk
Die Internet Engineering Task Force (IETF) definiert die folgenden beiden Architekturen für QoS:
Integrierte Services (IntServ)
Differentiated Services (DiffServ)
IntServ verwendet das Resource Reservation Protocol (RSVP), um die QoS-Anforderungen des Datenverkehrs einer Anwendung entlang der Geräte im End-to-End-Pfad durch das Netzwerk explizit zu signalisieren. Wenn jedes Netzwerkgerät entlang des Pfads die erforderliche Bandbreite reservieren kann, kann die ursprüngliche Anwendung mit der Übertragung beginnen. Request for Comments (RFC) 2205 definiert RSVP und RFC 1633 definiert IntServ.
DiffServ konzentriert sich auf die aggregierte und bereitgestellte QoS. Anstatt die QoS-Anforderungen einer Anwendung zu signalisieren, verwendet DiffServ einen DiffServ-Codepunkt (DSCP) im IP-Header, um die erforderlichen QoS-Ebenen anzugeben. Mit der Cisco IOS® Software-Version 12.1(5)T wurde die DiffServ-Kompatibilität auf Cisco Routern eingeführt. Weitere Informationen finden Sie in den folgenden Dokumenten:
F. Was sind Überlastungen, Verzögerungen und Jitter?
A. Eine Schnittstelle ist überlastet, wenn mehr Datenverkehr übertragen wird, als sie verarbeiten kann. Engpässe im Netzwerk sind wichtige Voraussetzungen für Quality of Service (QoS)-Mechanismen. Nachfolgend finden Sie ein Beispiel für typische Überlastungspunkte:
Eine Netzwerküberlastung führt zu Verzögerungen. In einem Netzwerk und seinen Geräten treten verschiedene Arten von Verzögerungen auf, wie unter Understanding Delay in Packet Voice Networks erläutert. Die Variation der Verzögerung wird als Jitter bezeichnet und unter Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms) erläutert. Sowohl Verzögerungen als auch Jitter müssen kontrolliert und minimiert werden, um Echtzeit- und interaktiven Datenverkehr zu unterstützen.
F. Was ist der MQC?
A. MQC steht für Modular Quality of Service (QoS) Command Line Interface (CLI). Es wurde entwickelt, um die Konfiguration der QoS auf Cisco Routern und Switches zu vereinfachen, indem eine gemeinsame Befehlssyntax und das resultierende QoS-Verhalten für alle Plattformen definiert werden. Dieses Modell ersetzt das vorherige Modell zur Definition individueller Syntaxen für jede QoS-Funktion und für jede Plattform.
Der MQC besteht aus den folgenden drei Schritten:
Definieren Sie eine Datenverkehrsklasse mit dem Befehl class-map.
Erstellen Sie eine Datenverkehrsrichtlinie, indem Sie die Datenverkehrsklasse mit einer oder mehreren QoS-Funktionen verknüpfen, indem Sie den Befehl policy-map eingeben.
Verknüpfen Sie die Datenverkehrsrichtlinie mit der Schnittstelle, Subschnittstelle oder Virtual Circuit (VC), indem Sie den Befehl service-policy eingeben.
Hinweis: Sie implementieren die Funktionen zur Konditionierung des Datenverkehrs von DiffServ, z. B. Marking und Shaping, mithilfe der MQC-Syntax.
Weitere Informationen finden Sie unter Modular Quality of Service Command-Line Interface (Modulare QoS-Befehlszeilenschnittstelle).
Frage: Was bedeutet die Service-Policy, die nur auf VIP-Schnittstellen mit DCEF-aktivierter Nachricht unterstützt wird?
A.: Auf VIPs (Versatile Interface Processors) der Cisco Serie 7500 werden ab Cisco IOS 12.1(5)T, 12.1(5)E und 12.0(14)S nur verteilte QoS-Funktionen unterstützt. Durch die Aktivierung von verteiltem Cisco Express Forwarding (dCEF) wird verteilte QoS automatisch aktiviert.
Nicht-VIP-Schnittstellen, auch als Legacy Interface Processors (IPs) bezeichnet, unterstützen zentrale QoS-Funktionen, die auf dem Route Switch Processor (RSP) aktiviert sind. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Wie viele Klassen werden von einer QoS-Richtlinie (Quality of Service) unterstützt?
A.: In Cisco IOS-Versionen vor 12.2 können Sie maximal 256 Klassen definieren. Sie können bis zu 256 Klassen in jeder Richtlinie definieren, wenn dieselben Klassen für verschiedene Richtlinien wiederverwendet werden. Wenn Sie über zwei Richtlinien verfügen, sollte die Gesamtzahl der Klassen beider Richtlinien 256 nicht überschreiten. Wenn eine Richtlinie Class-Based Weighted Fair Queueing (CBWFQ) (d. h. sie enthält eine Bandbreiten- [oder Prioritäts-] Anweisung innerhalb einer der Klassen) umfasst, werden insgesamt 64 Klassen unterstützt.
In den Cisco IOS-Versionen 12.2(12), 12.2(12)T und 12.2(12)S wurde diese Beschränkung auf 256 globale Klassenzuordnungen geändert. Es ist nun möglich, bis zu 1024 globale Klassenzuordnungen zu konfigurieren und 256 Klassenzuordnungen innerhalb derselben Richtlinienzuordnung zu verwenden.
Frage: Wie werden Routing-Updates und Point-to-Point Protocol (PPP)-/High-Level Data Link Control (HDLC)-Keepalives verarbeitet, wenn eine Service-Richtlinie angewendet wird?
A.: Cisco IOS-Router verwenden die folgenden zwei Mechanismen zur Priorisierung von Steuerungspaketen:
IP-Rangfolge
Pak_priority
Beide Mechanismen sollen sicherstellen, dass Schlüsselkontrollpakete nicht verworfen werden oder zuletzt vom Router und dem Warteschlangensystem verworfen werden, wenn eine ausgehende Schnittstelle überlastet ist. Weitere Informationen finden Sie unter Understanding How Routing Updates and Control Packets Are Queued on an Interface with a QoS Service Policy.
Frage: Wird Quality of Service (QoS) auf Schnittstellen unterstützt, die mit Integrated Routing and Bridging (IRB) konfiguriert sind?
A. Nein. Sie können keine QoS-Funktionen konfigurieren, wenn die Schnittstelle für IRB konfiguriert ist.
Klassifizierung und Kennzeichnung
Frage: Was ist die QoS-Vorklassifizierung?
A. Die QoS-Vorklassifizierung ermöglicht Ihnen, den ursprünglichen IP-Header-Inhalt von Paketen, die in Tunnelkapselung und/oder Verschlüsselung verwickelt sind, abzugleichen und zu klassifizieren. Diese Funktion beschreibt nicht den Vorgang, bei dem der ursprüngliche Wert des ToS-Byte (Type of Service) vom ursprünglichen Paket-Header in den Tunnel-Header kopiert wird. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Welche Paketkopfzeilen können markiert werden? Welche Werte stehen zur Verfügung?
A. Mit der klassenbasierten Markierungsfunktion können Sie den Layer-2-, Layer-3- oder Multiprotocol Label Switching (MPLS)-Header Ihrer Pakete festlegen oder markieren. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Kann ich den Datenverkehr auf Basis der URL priorisieren?
A: Ja. Network Based Application Recognition (NBAR) ermöglicht die Klassifizierung von Paketen durch Abgleich in Feldern auf Anwendungsebene. Vor der Einführung von NBAR war die präziseste Klassifizierung die Layer 4 Transmission Control Protocol (TCP)- und User Datagram Protocol (UDP)-Portnummern. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Welche Plattformen und Cisco IOS-Softwareversionen unterstützen Network Based Application Recognition (NBAR)?
A.: Die Unterstützung für NBAR wird in den folgenden Versionen der Cisco IOS-Software eingeführt:
Plattform Mindestversion der Cisco IOS Software 7200 12.1(5)T 7100 12.1(5)T 3660 12.1(5)T 3640 12.1(5)T 3620 12.1(5)T 2600 12.1(5)T 1700 12.2(2)T Hinweis: Zur Verwendung von NBAR muss Cisco Express Forwarding (CEF) aktiviert werden.
Distributed NBAR (DNBAR) ist auf den folgenden Plattformen verfügbar:
Plattform Mindestversion der Cisco IOS Software 7500 12.2(4)T, 12.1(6)E FlexWAN 12.1(6)E Hinweis: NBAR wird von den VLAN-Schnittstellen der Catalyst 6000 Multilayer Switch Feature Card (MSFC), der Cisco Serie 12000 oder dem Route Switch Module (RSM) für die Catalyst Serie 5000 nicht unterstützt. Wenn oben keine bestimmte Plattform aufgeführt ist, wenden Sie sich an Ihren technischen Ansprechpartner bei Cisco.
Warteschlangen- und Überlastungsmanagement
Frage: Wozu dient das Warteschlangenmanagement?
A. Die Warteschlangenverwaltung wurde entwickelt, um vorübergehende Engpässe an der Schnittstelle eines Netzwerkgeräts zu beheben, indem überschüssige Pakete in Puffern gespeichert werden, bis Bandbreite verfügbar ist. Cisco IOS-Router unterstützen verschiedene Warteschlangenmethoden, um die unterschiedlichen Bandbreiten-, Jitter- und Verzögerungsanforderungen verschiedener Anwendungen zu erfüllen.
Der Standardmechanismus für die meisten Schnittstellen ist First In First Out (FIFO). Einige Datenverkehrstypen haben höhere Verzögerungs-/Jitteranforderungen. Daher sollte einer der folgenden alternativen Warteschlangenmechanismen konfiguriert oder standardmäßig aktiviert sein:
Weighted Fair Queueing (WFQ)
Class-Based Weighted Fair Queueing (CBWFQ)
Low Latency Queueing (LLQ), d. h. CBWFQ mit einer Priority Queue (PQ) (bekannt als PQCBWFQ)
Priority Queueing (PQ)
Benutzerdefinierte Warteschlangenverwaltung (CQ)
Die Warteschlangenzuweisung erfolgt in der Regel nur an ausgehenden Schnittstellen. Ein Router ordnet Pakete, die über eine Schnittstelle gesendet werden, einer Warteschlange zu. Sie können den eingehenden Datenverkehr regeln, aber in der Regel können Sie ihn nicht in eine Warteschlange einreihen (eine Ausnahme ist die empfangsseitige Pufferung auf einem Cisco Router der Serie 7500, der verteilte Cisco Express Forwarding (dCEF) verwendet, um Pakete von der Eingangs- an die Ausgangsschnittstelle weiterzuleiten; weitere Informationen finden Sie unter Understanding VIP CPU Running at 99% and Rx-Side Buffering. Auf verteilten High-End-Plattformen wie der Cisco Serie 7500 und der Serie 12000 kann die Schnittstelle für eingehenden Datenverkehr eigene Paketpuffer verwenden, um überschüssigen Datenverkehr zu speichern, der nach der Switching-Entscheidung der Schnittstelle für eingehenden Datenverkehr an eine überlastete Schnittstelle weitergeleitet wird. In seltenen Fällen, in denen die Eingangsschnittstelle eine langsamere Ausgangsschnittstelle versorgt, kann es bei der Eingangsschnittstelle zu inkrementierenden ignorierten Fehlern kommen, wenn ihr der Paketspeicher ausgeht. Übermäßige Überlastung kann dazu führen, dass die Ausgabewarteschlange verworfen wird. Die Ursache für das Verwerfen von Eingabewarteschlangen ist meistens anders. Weitere Informationen zur Fehlerbehebung finden Sie im folgenden Dokument:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Wie funktionieren Weighted Fair Queueing (WFQ) und Class Based Weighted Fair Queueing (CBWFQ)?
A. Fair Queueing versucht, einen fairen Anteil der Bandbreite einer Schnittstelle zwischen aktiven Gesprächen oder IP-Datenflüssen zuzuweisen. Es klassifiziert Pakete mithilfe eines Hash-Algorithmus, der auf mehreren Feldern des IP-Headers und der Paketlänge basiert, in Unterwarteschlangen, die durch eine Konversations-Identifikationsnummer identifiziert werden. Das Gewicht wird wie folgt berechnet:
W=K/(Vorrang +1)
K= 4096 mit Cisco IOS 12.0(4)T und früheren Versionen und 32384 mit 12.0(5)T und späteren Versionen.
Je geringer das Gewicht, desto höher die Priorität und der Anteil der Bandbreite. Neben dem Gewicht wird auch die Länge des Pakets berücksichtigt.
Mit CBWFQ können Sie eine Datenverkehrsklasse definieren und dieser eine garantierte Mindestbandbreite zuweisen. Der diesem Mechanismus zugrunde liegende Algorithmus ist WFQ, der den Namen erklärt. Um CBWFQ zu konfigurieren, definieren Sie bestimmte Klassen in map-class-Anweisungen. Anschließend weisen Sie jeder Klasse in einer Richtlinienzuordnung eine Richtlinie zu. Diese Richtlinienzuweisung wird dann ausgehend an eine Schnittstelle angefügt. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Wenn eine Klasse in CBWFQ (Class Based Weighted Fair Queueing) ihre Bandbreite nicht nutzt, können andere Klassen diese Bandbreite nutzen?
A: Ja. Obwohl die Bandbreitengarantien, die durch die Ausgabe von Bandbreiten- und Prioritätsbefehlen gegeben werden, mit Wörtern wie "reserviert" und "Bandbreite reserviert" beschrieben wurden, implementiert keiner der beiden Befehle eine echte Reservierung. Wenn also eine Datenverkehrsklasse nicht die konfigurierte Bandbreite verwendet, wird die ungenutzte Bandbreite von den anderen Klassen gemeinsam genutzt.
Das Warteschlangensystem erlegt dieser Regel eine wichtige Ausnahme mit einer Prioritätsklasse auf. Wie oben erwähnt, wird die angebotene Last einer Prioritätsklasse durch eine Traffic Policer gemessen. Während einer Überlastung kann eine Prioritätsklasse keine überschüssige Bandbreite verwenden. Weitere Informationen finden Sie unter Comparing the bandwidth and priority Commands of a QoS Service Policy.
Frage: Wird Class Based Weighted Fair Queueing (CBWFQ) auf Subschnittstellen unterstützt?
A.: Logische Cisco IOS-Schnittstellen unterstützen nicht automatisch einen Überlastungszustand und nicht die direkte Anwendung einer Dienstrichtlinie, die eine Warteschlangenmethode anwendet. Stattdessen müssen Sie zunächst entweder Generic Traffic Shaping (GTS) oder das klassenbasierte Shaping auf die Subschnittstelle anwenden. Weitere Informationen finden Sie unter Anwenden von QoS-Funktionen auf Ethernet-Subschnittstellen.
Frage: Was ist der Unterschied zwischen den Prioritäts- und Bandbreitenanweisungen in einer Richtlinienzuordnung?
A. Die Befehle für Priorität und Bandbreite unterscheiden sich sowohl in der Funktionalität als auch in den Anwendungen, die sie normalerweise unterstützen. In der folgenden Tabelle sind diese Unterschiede zusammengefasst:
Funktion Bandbreitenbefehl Prioritätsbefehl Garantierte Mindestbandbreite Ja Ja Garantierte maximale Bandbreite Nein Ja Integrierte Überwachung Nein Ja Geringe Latenz Nein Ja Weitere Informationen finden Sie unter Comparing the bandwidth and priority Commands of a QoS Service Policy.
Frage: Wie wird der Warteschlangengrenzwert für FlexWAN und Versatile Interface Processors (VIP) berechnet?
A. Unter der Annahme eines ausreichenden SRAM für das VIP oder FlexWAN wird die Warteschlangenbeschränkung auf der Grundlage einer maximalen Verzögerung von 500 ms bei einer durchschnittlichen Paketgröße von 250 Byte berechnet. Das folgende Beispiel zeigt eine Klasse mit einer Bandbreite von 1 Mbit/s:
Warteschlangenlimit = 1000000 / (250 x 8 x 2) = 250
Kleinere Warteschlangenbeschränkungen werden mit abnehmendem verfügbarem Paketspeicher und einer größeren Anzahl von virtuellen Schaltungen (Virtual Circuits, VCS) zugewiesen.
Im folgenden Beispiel ist ein PA-A3 auf einer FlexWAN-Karte für die Cisco Serie 7600 installiert. Er unterstützt mehrere Subschnittstellen mit 2 MB Permanent Virtual Circuits (PVCs). Die Service-Richtlinie wird auf alle VCs angewendet.
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048KbpsDie ATM-Schnittstelle (Asynchronous Transfer Mode) erhält eine Warteschlangenbeschränkung für die gesamte Schnittstelle. Der Grenzwert ist eine Funktion der insgesamt verfügbaren Puffer, der Anzahl der physischen Schnittstellen im FlexWAN und der maximal zulässigen Warteschlangenverzögerung für die Schnittstelle. Jeder PVC erhält einen Teil des Grenzwerts für die Schnittstelle, basierend auf der dauerhaften Zellrate (Sustained Cell Rate, SCR) oder der minimalen Zellrate (Minimum Cell Rate, MCR) des PVC, und jede Klasse erhält einen Teil des Grenzwerts für die PVC-Schnittstelle, basierend auf ihrer Bandbreitenzuweisung.
Die folgende Beispielausgabe des Befehls show policy-map interface stammt aus einem FlexWAN mit 3687 globalen Puffern. Geben Sie den Befehl show buffer ein, um diesen Wert anzuzeigen. Jedem PVC mit zwei Mbit/s werden 50 Pakete basierend auf der PVC-Bandbreite von zwei Mbit/s zugewiesen (2047/149760 x 3687 = 50). Jeder Klasse wird dann ein Teil der 50 zugewiesen, wie in der folgenden Ausgabe gezeigt:
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0Wenn Ihre Datenverkehrsströme große Paketgrößen verwenden, kann die Ausgabe des Befehls show policy-map interface einen inkrementierenden Wert für das Feld no buffer drops melden, da Ihnen die Puffer möglicherweise ausgehen, bevor Sie das Warteschlangenlimit erreichen. Versuchen Sie in diesem Fall, die Warteschlangenbegrenzung in Nicht-Prioritätsklassen manuell zu verringern. Weitere Informationen finden Sie unter Understanding the Transmit Queue Limit With IP to ATM CoS.
Frage: Wie überprüfen Sie den Warteschlangengrenzwert?
A. Auf nicht verteilten Plattformen ist der Warteschlangengrenzwert standardmäßig auf 64 Pakete begrenzt. Die folgende Beispielausgabe wurde auf einem Cisco Router der Serie 3600 erfasst:
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (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) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
Frage: Kann ich eine Warteschlangenverwaltung innerhalb eines Kurses aktivieren?
A.: Die Cisco Serie 7500 mit verteilter QoS (Quality of Service) unterstützt eine faire Warteschlangenzuweisung pro Klasse. Andere Plattformen, wie die Cisco Serie 7200 und die Cisco Serien 2600/3600, unterstützen Weighted Fair Queueing (WFQ) in der Standardklasse. Alle Bandbreitenklassen verwenden First In First Out (FIFO).
Frage: Mit welchen Befehlen kann ich Warteschlangen überwachen?
A. Verwenden Sie die folgenden Befehle, um Warteschlangen zu überwachen:
show queue {interface}{interface number} - Auf anderen Cisco IOS-Plattformen als der Cisco Serie 7500 zeigt dieser Befehl die aktiven Warteschlangen oder Kommunikationen an. Wenn die Schnittstelle oder der Virtual Circuit (VC) nicht überlastet ist, werden keine Warteschlangen aufgeführt. Auf der Cisco Serie 7500 wird der Befehl show queue nicht unterstützt.
show queueing interface interface-number [vc [[vpi/] vci] - Zeigt die Warteschlangenstatistiken einer Schnittstelle oder eines VC an. Auch wenn es keine Überlastung gibt, werden Sie hier noch einige Treffer sehen können. Der Grund dafür ist, dass prozessgeschaltete Pakete immer gezählt werden, unabhängig von der vorhandenen Überlastung. Cisco Express Forwarding (CEF) und Fast-Switched-Pakete werden nur bei Überlastungen gezählt. Die älteren Warteschlangenmechanismen wie Priority Queueing (PQ), Custom Queueing (CQ) und Weighted Fair Queueing (WFQ) bieten keine Klassifizierungsstatistiken. Nur modulare MQC-basierte Funktionen (Quality of Service) in Images nach Version 12.0(5)T liefern diese Statistiken.
show policy interface {interface}{interface number} - Der Paketzähler zählt die Anzahl der Pakete, die den Kriterien der Klasse entsprechen. Dieser Zähler erhöht, ob die Schnittstelle überlastet ist oder nicht. Der Zähler für übereinstimmende Pakete gibt die Anzahl der Pakete an, die den Kriterien der Klasse bei Überlastung der Schnittstelle entsprechen. Weitere Informationen zu Paketzählern finden Sie im folgenden Dokument:
Erläuterungen zu Paketzählern in der Ausgabe der Richtlinienzuweisung
Klassenbasierte QoS-Konfigurations- und Statistik-MIB von Cisco - Bietet SNMP-Überwachungsfunktionen (Simple Network Management Protocol).
Frage: RSVP kann in Verbindung mit CBWFQ (Class Based Weighted Fair Queueing) verwendet werden. Wenn sowohl Resource Reservation Protocol (RSVP) als auch CBWFQ für eine Schnittstelle konfiguriert sind, verhalten sich RSVP und CBWFQ unabhängig und verhalten sich genauso, wie wenn beide einzeln ausgeführt würden? RSVP scheint sich so zu verhalten, als ob CBWFQ nicht hinsichtlich der Verfügbarkeit, Bewertung und Zuweisung von Bandbreite konfiguriert wäre.
A. Bei Verwendung von RSVP und CB-WFQ in Version 12.1(5)T der Cisco IOS-Software kann der Router so betrieben werden, dass RSVP-Flows und CBWFQ-Klassen die verfügbare Bandbreite auf einer Schnittstelle oder PVC teilen, ohne dass es zu einer Überbelegung kommt.
Die IOS Software-Version 12.2(1)T und höher ermöglicht es RSVP, die Zugangskontrolle über einen eigenen "ip rsvp bandwidth"-Pool auszuführen, während CBWFQ die Klassifizierung, Festlegung von Richtlinien und Planung von RSVP-Paketen durchführt. Dies setzt vorab markierte Pakete durch den Absender voraus und setzt voraus, dass nicht-RSVP-Pakete anders markiert sind.
Weighted Random Early Detection (WRED) zur Überlastungsvermeidung
Frage: Kann ich Weighted Random Early Detection (WRED) und Low Latency Queueing (LLQ) oder Class Based Weighted Fair Queueing (CBWFQ) gleichzeitig aktivieren?
A: Ja. Die Warteschlange definiert die Reihenfolge der Pakete, die eine Warteschlange verlassen. Das bedeutet, dass ein Paketplanungsmechanismus definiert wird. Sie kann auch verwendet werden, um eine faire Bandbreitenzuweisung und minimale Bandbreitengarantien bereitzustellen. Im Gegensatz dazu definiert Request for Comments (RFC) 2475 das Verwerfen als den "Prozess des Verwerfens von Paketen auf der Grundlage festgelegter Regeln". Der Standard-Dropdown-Mechanismus ist Tail Drop, bei dem die Schnittstelle Pakete verwirft, wenn die Warteschlange voll ist. Ein alternativer Dropdown-Mechanismus ist Random Early Detection (RED) und Cisco WRED, bei dem Pakete nach dem Zufallsprinzip verworfen werden, bevor die Warteschlange voll ist, und bei dem versucht wird, eine konsistente durchschnittliche Warteschlangentiefe beizubehalten. WRED verwendet den IP-Rangfolgewert von Paketen, um eine differenzierte Verwerfungsentscheidung zu treffen. Weitere Informationen finden Sie unter Weighted Random Early Detection (WRED).
F. Wie kann ich Weighted Random Early Detection (WRED) überwachen und feststellen, dass diese tatsächlich wirksam wird?
A. WRED überwacht die durchschnittliche Warteschlangentiefe und beginnt, Pakete zu verwerfen, wenn der berechnete Wert den minimalen Schwellenwert überschreitet. Führen Sie den Befehl show policy-map interface aus, und überwachen Sie den mittleren Wert für die Warteschlangentiefe, wie im folgenden Beispiel gezeigt:
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
Richtlinien und Shaping
F. Was ist der Unterschied zwischen Richtlinienvergabe und Shaping?
A. Das folgende Diagramm veranschaulicht den Hauptunterschied. Beim Traffic Shaping werden überzählige Pakete in einer Warteschlange gehalten, und der überzählige Datenverkehr wird dann über mehrere Zeitabschnitte für die spätere Übertragung eingeplant. Das Ergebnis des Traffic Shaping ist eine geglättete Paketausgangsrate. Datenverkehrsrichtlinien dagegen geben Bursts weiter. Wenn die Datenverkehrsrate die konfigurierte maximale Rate erreicht, wird überschüssiger Datenverkehr verworfen (oder markiert). Das Ergebnis ist eine Produktionsrate, die wie ein Sägezahn mit Kämmen und Trögen erscheint.
Weitere Informationen finden Sie unter Übersicht über Richtlinien und Shaping.
F. Was ist ein Token-Bucket und wie funktioniert der Algorithmus?
A. Ein Token-Bucket selbst hat keine Rückwurf- oder Prioritätsrichtlinie. Im Folgenden finden Sie ein Beispiel für die Funktionsweise der Token-Bucket-Metapher:
Token werden mit einer bestimmten Geschwindigkeit in den Eimer gelegt.
Jedes Token ist die Berechtigung für die Quelle, eine bestimmte Anzahl von Bits zu senden.
Um ein Paket zu senden, muss der Verkehrsregler in der Lage sein, eine Anzahl von Token, die der Paketgröße entspricht, aus dem Bucket zu entfernen.
Wenn sich nicht genügend Token im Bucket befinden, um ein Paket zu senden, wartet das Paket entweder, bis der Bucket genügend Token hat (im Fall eines Shapers), oder das Paket wird verworfen oder markiert (im Fall eines Policers).
Der Eimer selbst hat eine bestimmte Kapazität. Wenn der Bucket voll ist, werden neu ankommende Token verworfen und stehen zukünftigen Paketen nicht zur Verfügung. Somit ist der größte Burst, den eine Quelle in das Netzwerk senden kann, zu jeder Zeit in etwa proportional zur Größe des Buckets. Ein Token-Eimer erlaubt Geschmeidigkeit, aber begrenzt sie.
Frage: Was bedeuten Committed Burst (BC) und Excess Burst (Be) bei einer Datenverkehrsüberwachung wie klassenbasiertes Policing, und wie sollte ich diese Werte auswählen?
Antwort: Eine Datenverkehrsüberwachung puffert keine überschüssigen Pakete und überträgt sie nicht zu einem späteren Zeitpunkt, wie dies bei einem Shaper der Fall ist. Stattdessen führt die Richtlinienvergabe eine einfache Sende- oder Nicht-Sende-Richtlinie ohne Pufferung aus. Da in Überlastungsphasen kein Puffer möglich ist, lassen sich Pakete am besten durch eine ordnungsgemäße Konfiguration erweiterter Bursts weniger aggressiv verwerfen. Daher ist es wichtig, dass die Überwachung die normalen Burst- und erweiterten Burst-Werte verwendet, um sicherzustellen, dass die konfigurierte Committed Information Rate (CIR) erreicht wird.
Die Burst-Parameter basieren lose auf der allgemeinen Pufferungsregel für Router. Die Regel empfiehlt, Pufferung entsprechend der Round-Trip-Zeit-Bitrate zu konfigurieren, um die ausstehenden TCP-Fenster (Transmission Control Protocol) aller Verbindungen in Zeiten von Überlastung unterzubringen.
In der folgenden Tabelle werden der Zweck und die empfohlene Formel für die normalen und erweiterten Burst-Werte beschrieben:
Burst Parameter Zweck Empfohlene Formel normaler Burst
Implementiert einen Standardtokenbucket.
Legt die maximale Größe des Tokenbuckets fest (obwohl Token ausgeliehen werden können, wenn Be größer als BC ist).
Bestimmt, wie groß der Token-Bucket sein kann, da neu eintreffende Token verworfen werden und für zukünftige Pakete nicht verfügbar sind, wenn der Bucket die Kapazität erreicht.
Hinweis: 1,5 Sekunden sind die typische Round-Trip-Zeit.
ausgedehnter Burst
Implementiert einen Token-Bucket mit erweiterter Burst-Funktion.
Deaktiviert durch Einstellung BC = Be.
Wenn BC gleich Be ist, kann der Verkehrsregler keine Token ausleihen und verwirft das Paket einfach, wenn nicht genügend Token zur Verfügung stehen.
Nicht alle Plattformen verwenden oder unterstützen den gleichen Wertebereich für einen Policer. Im folgenden Dokument finden Sie Informationen zu den unterstützten Werten für Ihre jeweilige Plattform:
F. Wie entscheidet die Committed Access Rate (CAR) oder die klassenbasierte Richtlinienvergabe, ob ein Paket die Committed Information Rate (CIR) erfüllt oder übersteigt? Der Router verwirft Pakete und meldet eine Überschreitungsrate, obwohl die konforme Rate geringer ist als die konfigurierte CIR.
A. Eine Datenverkehrsüberwachung verwendet den normalen Burst- und den erweiterten Burst-Wert, um sicherzustellen, dass der konfigurierte CIR erreicht wird. Die Einstellung ausreichend hoher Burst-Werte ist wichtig, um einen guten Durchsatz zu gewährleisten. Wenn die Burst-Werte zu niedrig konfiguriert sind, kann die erreichte Rate viel niedriger als die konfigurierte Rate sein. Das Bestrafen temporärer Bursts kann sich stark auf den Durchsatz des TCP-Datenverkehrs (Transmission Control Protocol) auswirken. Verwenden Sie bei CAR den Befehl show interface rate-limit (Schnittstellenratenlimit anzeigen), um den aktuellen Burst zu überwachen und zu bestimmen, ob der angezeigte Wert konsistent nahe an den Grenzwerten (BC) und erweiterten Grenzwerten (Be) liegt.
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPSWeitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Sind Burst und Warteschlangenlimit unabhängig voneinander?
A. Ja, der Policer-Burst und die Warteschlangenbegrenzung sind voneinander getrennt und unabhängig. Sie können die Richtlinie als ein Gatter anzeigen, das eine bestimmte Anzahl von Paketen (oder Bytes) zulässt, und die Warteschlange als eine Warteschlangengröße, die die zugelassenen Pakete vor der Übertragung im Netzwerk enthält. Im Idealfall sollte Ihr Bucket groß genug sein, um einen Burst von Bytes/Paketen aufzunehmen, die vom Gate zugelassen werden (Policer).
Quality of Service (QoS) Frame-Relay
Frage: Welche Werte sollte ich für Committed Information Rate (CIR), Committed Burst (BC), Excess Burst (Be) und Minimum CIR (MinCIR) auswählen?
A. Das Frame-Relay-Traffic-Shaping, das Sie durch Ausgeben des Frame-Relay-Traffic-Shaping-Befehls aktivieren, unterstützt mehrere konfigurierbare Parameter. Zu diesen Parametern gehören Frame-Relay-CIR, Frame-Relay-Mincir und Frame-Relay-BC. Weitere Informationen zur Auswahl dieser Werte und zum Verständnis der zugehörigen Befehle zum Anzeigen finden Sie in den folgenden Dokumenten:
Frage: Funktioniert Priority Queueing auf der Frame Relay-Hauptschnittstelle in Cisco IOS 12.1?
A. Frame Relay-Schnittstellen unterstützen sowohl Schnittstellen-Warteschlangenmechanismen als auch VC-Warteschlangenmechanismen (Per Virtual Circuit). Ab Cisco IOS 12.0(4)T unterstützt die Schnittstellenwarteschlange First In First Out (FIFO) oder Per Interface Priority Queueing (PIPQ) nur, wenn Sie Frame Relay Traffic Shaping (FRTS) konfigurieren. Daher funktioniert die folgende Konfiguration nicht mehr, wenn Sie ein Upgrade auf Cisco IOS 12.1 durchführen.
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETFWenn FRTS nicht aktiviert ist, können Sie eine alternative Warteschlangenmethode, z. B. CBWFQ (Class Based Weighted Fair Queueing), auf die Hauptschnittstelle anwenden, die wie eine einzelne Bandbreitenleitung funktioniert. Darüber hinaus können Sie ab Cisco IOS 12.1.1(T) Frame Relay Permanent Virtual Circuits (PVC) Priority Interface Queueing (PIPQ) auf einer Frame Relay-Hauptschnittstelle aktivieren. Sie können PVCs mit hoher, mittlerer, normaler oder niedriger Priorität definieren und den Befehl frame-relay interface-queue priority auf der Hauptschnittstelle ausführen, wie im folgenden Beispiel gezeigt:
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
Frage: Funktioniert Frame Relay Traffic Shaping (FRTS) mit Distributed Cisco Express Forwarding (dCEF) und Distributed Class Based Weighted Fair Queueing (dCBWFQ)?
Antwort: Ab Cisco IOS 12.1(5)T werden auf VIPs der Cisco Serie 7500 nur die verteilte Version der QoS-Funktionen unterstützt. Verwenden Sie Distributed Traffic Shaping (DTS), um das Traffic Shaping an Frame-Relay-Schnittstellen zu aktivieren. Weitere Informationen finden Sie in den folgenden Dokumenten:
Quality of Service (QoS) über ATM (Asynchronous Transfer Mode)
Frage: Wo wende ich eine Servicerichtlinie mit CBWFQ (Class Based Weighted Fair Queueing) und LLQ (Low Latency Queueing) auf eine ATM-Schnittstelle (Asynchronous Transfer Mode) an?
A.: Ab Cisco IOS 12.2 unterstützen ATM-Schnittstellen Servicerichtlinien auf drei Ebenen oder logische Schnittstellen: Hauptschnittstelle, Subschnittstelle und Permanent Virtual Circuit (PVC). Wenn Sie die Richtlinie anwenden, hängt dies von der QoS-Funktion ab, die Sie aktivieren. Warteschlangenrichtlinien sollten pro Virtual Circuit (VC) angewendet werden, da die ATM-Schnittstelle den Überlastungsgrad pro VC überwacht und Warteschlangen für überschüssige Pakete pro VC verwaltet. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Welche Bytes werden bei der Warteschlangenzuweisung in die Class of Service (COs) des Asynchronous Transfer Mode (ATM) nach IP gezählt?
A. Die in einer Dienstrichtlinie konfigurierten Befehle für Bandbreite und Priorität, mit denen CBWFQ (Class-Based Weighted Fair Queueing) bzw. LLQ (Low Latency Queueing) aktiviert werden, verwenden einen Kbit/s-Wert, der die gleichen Overhead-Bytes zählt, die von der Ausgabe des Befehls show interface gezählt werden. Insbesondere zählt das Layer-3-Warteschlangensystem Logical Link Control/Subnetwork Access Protocol (LLC/SNAP). Folgendes wird nicht berücksichtigt:
ATM-Adaption Layer 5 (AAL5)-Trailer
Auffüllen, um die letzte Zelle zu einem geraden Vielfachen von 48 Byte zu machen
Fünf-Byte-Zellenkopf
Welche Bytes werden von IP-zu-ATM-COs gezählt, die in Warteschlangen gestellt werden?
Frage: Wie viele Virtual Circuits (VCS) können eine Service-Richtlinie gleichzeitig unterstützen?
A. Das folgende Dokument enthält nützliche Richtlinien zur Anzahl der unterstützten ATM-VCS (Asynchronous Transfer Mode). Etwa 200 bis 300 Permanent Virtual Circuits (PVCs) des Typs VBR-nrt wurden sicher bereitgestellt:
Berücksichtigen Sie außerdem Folgendes:
Verwenden Sie einen leistungsstarken Prozessor. Ein VIP4-80 bietet beispielsweise eine erheblich höhere Leistung als ein VIP2-50.
Verfügbarer Paketspeicher Auf dem NPE-400 werden bis zu 32 MB (in einem System mit 256 MB) für den Paketpuffer reserviert. Bei einem NPE-200 sind bis zu 16 MB für Paketpuffer auf einem System mit 128 MB reserviert.
Konfigurationen mit WRED (Weighted Random Early Detection) pro VC, die gleichzeitig auf bis zu 200 ATM-PVCs betrieben werden, wurden umfassend getestet. Der VIP2-50-Paketspeicher, der für die VC-basierten Warteschlangen verwendet werden kann, ist begrenzt. Ein VIP2-50 mit 8-MB SRAM bietet beispielsweise 1085 Paketpuffer für IP-zu-ATM-COs pro VC-Warteschlange, auf der WRED ausgeführt wird. Wenn 100 ATM-PVCs konfiguriert wurden und alle VCS gleichzeitig überlastet waren (wie dies in Testumgebungen simuliert werden könnte, in denen eine nicht TCP-flussgesteuerte Quelle verwendet wird), dann hätte jeder PVC im Durchschnitt etwa zehn Pakete mit Pufferwert, was für WRED möglicherweise zu kurz ist, um erfolgreich zu funktionieren. VIP2-50-Geräte mit großem SRAM sind daher besonders bei Designs mit einer hohen Anzahl von ATM-PVCs zu empfehlen, die pro VC WRED ausgeführt werden und bei denen gleichzeitig Engpässe auftreten können.
Je höher die Anzahl der konfigurierten aktiven PVCs ist, desto geringer muss die Sustained Cell Rate (SCR, Dauerhafte Zellenrate) sein, und dementsprechend muss die Warteschlange, die WRED für den Betrieb des PVCs benötigt, kürzer sein. Wie bei der Verwendung der standardmäßigen WRED-Profile der Funktion "IP to ATM Class of Service (COs) Phase 1" würde die Konfiguration niedrigerer WRED-Drop-Schwellenwerte bei Aktivierung von WRED pro VC auf einer sehr großen Anzahl von ATM-PVCs mit geringer Übertragungsgeschwindigkeit das Risiko einer Pufferknappheit beim VIP minimieren. Eine Pufferknappheit beim VIP führt zu keiner Störung. Bei einem Puffermangel im VIP wird die IP-To-ATM-COs Phase 1-Funktion während des Puffermangel einfach zu FIFO-Tail-Drop (First In First Out) herabgesetzt (d. h. zu der gleichen Richtlinie, die angewendet würde, wenn die IP-To-ATM-COs-Funktion auf diesem PVC nicht aktiviert würde).
Maximale Anzahl gleichzeitiger VCS, die nach vernünftigem Ermessen unterstützt werden kann.
Frage: Welche ATM-Hardware (Asynchronous Transfer Mode) unterstützt IP-to-ATM-CoS-Funktionen (Class of Service) wie CBWFQ (Class Based Weighted Fair Queueing) und LLQ (Low Latency Queueing)?
A. IP-to-ATM-COs bezeichnet eine Reihe von Funktionen, die pro Virtual Circuit (VC) aktiviert werden. Bei dieser Definition werden IP-zu-ATM-COs auf den ATM Interface Processor (AIP)-, PA-A1- oder 4500-ATM-Netzwerkprozessoren nicht unterstützt. Diese ATM-Hardware unterstützt kein Per-VC Queueing, da sie von den PA-A3 und den meisten Netzwerkmodulen (mit Ausnahme des ATM-25) definiert wird. Weitere Informationen finden Sie im folgenden Dokument:
Sprache und Quality of Service (QoS)
F. Wie funktioniert Link Fragmentation and Interleaving (LFI)?
A. Interaktiver Datenverkehr wie Telnet und Voice over IP ist anfällig für erhöhte Latenz, wenn das Netzwerk große Pakete wie FTP-Übertragungen (File Transfer Protocol) über ein WAN verarbeitet. Die Paketverzögerung für interaktiven Datenverkehr ist erheblich, wenn die FTP-Pakete über langsamere WAN-Verbindungen in die Warteschlange gestellt werden. Es wurde eine Methode entwickelt, um größere Pakete zu fragmentieren und die kleineren Pakete (Sprachpakete) zwischen den Fragmenten der größeren Pakete (FTP-Pakete) in Warteschlangen zu stellen. Cisco IOS-Router unterstützen mehrere Layer-2-Fragmentierungsmechanismen. Weitere Informationen finden Sie in den folgenden Dokumenten:
Frage: Mit welchen Tools kann ich die Voice-over-IP-Leistung überwachen?
A.: Cisco bietet derzeit mehrere Optionen für die Überwachung der Quality of Service (QoS) in Netzwerken mit Cisco Voice-over-IP-Lösungen an. Diese Lösungen messen die Sprachqualität nicht mit Perceptual Speech Quality Measurement (PSQM) oder einigen der neuen vorgeschlagenen Algorithmen zur Sprachqualitätsmessung. Dazu stehen Tools von Agilent (HP) und NetIQ zur Verfügung. Cisco stellt jedoch Tools zur Verfügung, mit denen Sie eine Vorstellung von der Sprachqualität erhalten, indem Verzögerungen, Jitter und Paketverluste gemessen werden. Weitere Informationen finden Sie unter Verwenden von Cisco Service Assurance Agent und Internetwork Performance Monitor zum Verwalten der Quality of Service in Voice-over-IP-Netzwerken.
F. %SW_MGR-3-CM_ERROR_FEATURE_CLASS: Connection Manager Feature Error: Class SSS: (QoS) - Installationsfehler, ignorieren.
A. Der festgestellte Fehler bei der Feature-Installation ist ein erwartetes Verhalten, wenn eine ungültige Konfiguration auf eine Vorlage angewendet wird. Sie gibt an, dass die Dienstrichtlinie aufgrund eines Konflikts nicht angewendet wurde. Generell sollten Sie das Shaping nicht auf Klassenstandard der untergeordneten Richtlinie in hierarchischen Richtlinienzuordnungen konfigurieren, sondern auf der übergeordneten Richtlinie der Schnittstelle. Diese Meldung mit dem Traceback wird als Konsequenz ausgedruckt.
Bei sitzungsbasierten Richtlinien muss das Shaping für die Standardklasse nur auf Subschnittstellen- oder PVC-Ebene erfolgen. Shaping an der physischen Schnittstelle wird nicht unterstützt. Wenn die Konfiguration auf der physischen Schnittstelle erfolgt, ist das Auftreten dieser Fehlermeldung ein erwartetes Verhalten.
Im Fall von LNS kann ein weiterer Grund darin bestehen, dass die Service-Richtlinie beim Starten der Sitzungen über den Radius-Server bereitgestellt werden kann. Führen Sie den Befehl show tech aus, um die Radius-Server-Konfiguration anzuzeigen und um alle illegalen Service-Richtlinien anzuzeigen, die über den Radius-Server installiert werden, wenn die Sitzung gestartet wird oder Flaps auftreten.
Feedback