Langsame Leistung des ATM-Netzwerks

Einführung

In diesem Dokument werden allgemeine und spezifische Ursachen für eine langsame Leistung in ATM-Netzwerken sowie Verfahren zur Problembehebung beschrieben. Der Schwerpunkt dieses Dokuments liegt auf der Behebung von IP-Leistungsproblemen, insbesondere bei ATM-Netzwerken. In der Regel wird die Leistung mithilfe von Verzögerung und Durchsatz gemessen. Die Leistung wird häufig mithilfe von FTP oder anderen TCP/IP-Anwendungen getestet, um eine Datei zwischen zwei Endgeräten zu übertragen und dann die Zeit zu messen, die für die Übertragung der Datei erforderlich ist. Wenn die bei der Dateiübertragung angezeigte Durchsatzrate nicht der Bandbreite entspricht, die über den ATM-Schaltkreis verfügbar ist, wird dies als Leistungsproblem wahrgenommen. Es gibt viele Faktoren, wie Einstellungen im TCP-Fenster, MTU, Paketverlust und Verzögerung, die den Durchsatz in einem ATM-Schaltkreis bestimmen. Dieses Dokument befasst sich mit Problemen, die sich auf die Performance von gerouteten, permanenten virtuellen Schaltungen (PVCs), Switched Virtual Circuits (SVCs) und LAN Emulation (LANE)-Implementierungen im ATM auswirken. Die Ursache von Leistungsproblemen sind bei Routing-PVC-, SVC- und LANE-Implementierungen häufig anzutreffen.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Hintergrundinformationen

Der erste Schritt bei der Behebung von Leistungsproblemen besteht darin, Single Source- und Destination-Geräte auszuwählen, zwischen denen getestet werden soll. Identifizieren Sie die Bedingungen, unter denen das Problem auftritt, und die Bedingungen, unter denen es nicht auftritt. Wählen Sie Testgeräte aus, um die Komplexität des Problems zu reduzieren. Testen Sie z. B. nicht zwischen Geräten, die sich im Abstand von zehn Router-Hops befinden, wenn das Problem beim Durchlaufen von zwei Routern besteht.

Nachdem die Testgeräte ausgewählt wurden, stellen Sie fest, ob die Leistung mit der Natur der TCP-Anwendungen zusammenhängt oder ob das Problem durch andere Faktoren verursacht wird. Ping zwischen Endgeräten, um festzustellen, ob ein Paketverlust auftritt und die Round-Trip-Verzögerung für Ping-Pakete. Ping-Tests sollten mit unterschiedlichen Paketgrößen durchgeführt werden, um festzustellen, ob die Paketgröße den Paketverlust beeinflusst. Ping-Tests sollten von den getesteten Endgeräten und nicht von Routern durchgeführt werden. Die Round-Trip-Zeit (Round Trip Time, RTT), die Sie beim Pingen von und zu einem Router sehen, ist möglicherweise nicht korrekt. Der Grund hierfür ist, dass der Ping-Prozess ein Prozess mit niedriger Priorität auf dem Router ist und den Ping-Befehl möglicherweise nicht sofort beantwortet.

Häufige Probleme

Natur von TCP/IP

Ein Kunde hat eine ATM-PVC zwischen New York und Los Angeles. Der Virtual Circuit (VC) wird mit einer Sustained Cell Rate (SCR) von 45 Mbit/s konfiguriert. Der Kunde testet diesen Schaltkreis, indem er eine Datei über FTP von einem FTP-Server auf einen Client überträgt, und stellt fest, dass der Durchsatz für die Dateiübertragung etwa 7,3 Mbit/s beträgt. Bei Verwendung von TFTP sinkt der Durchsatz auf 58 Kbit/s. Die Ping-Reaktionszeit zwischen Client und Server beträgt ungefähr 70 ms.

Das erste, was in diesem Beispiel zu verstehen ist, ist, dass TCP einen zuverlässigen Datenaustausch zwischen Geräten ermöglicht. Der Absender sendet Daten in einem Stream, in dem Bytes durch Sequenznummern identifiziert werden. Der Empfänger bestätigt, dass er die Daten empfangen hat, indem er die Sequenznummer (Bestätigungsnummer) des nächsten Bytes von Daten sendet, das er voraussichtlich erhält. Der Empfänger kündigt dem Absender auch seine Window-Größe an, um die Datenmenge anzukündigen, die er akzeptieren kann.

TCP/IP-Endgeräte können in der Regel TCP/IP-Fenstergrößen konfigurieren.

Wenn Geräte über eine zu niedrige TCP-Fenstergröße verfügen, können diese Geräte möglicherweise nicht die gesamte Bandbreite einer ATM-VC nutzen.

Der RTT auf einem ATM VC kann den TCP-Durchsatz erheblich reduzieren, wenn die Fenstergröße zu niedrig ist.

Ein Endgerät sendet Datenverkehr in Byte pro RTT im Wert von etwa einer Window-Größe.

Wenn das RTT beispielsweise 70 ms beträgt, berechnen Sie mithilfe dieser Formel die erforderliche Fenstergröße, um eine gesamte DS3-Bandbreite aufzufüllen:

• 0,07 s * 45 Mbit/s * 1 Byte/8 Bit = 393.750 Byte

Standard TCP erlaubt eine maximale Fenstergröße von 64.000 Byte. Mit der WINScale TCP-Option kann die Fenstergröße wesentlich höher sein, wenn die Geräte an beiden Enden diese Option unterstützen und die FTP-Anwendung diese Option ebenfalls unterstützt.

Verwenden Sie diese Formel, um die Fenstergröße auf 64.000 Byte festzulegen, und verwenden Sie das RTT von 70 ms, um den Durchsatz zu beheben.

• 0,07 x * 1 Byte/8 Bit = 64.000 Byte

  wobei x = 7,31428 Mbit/s

Wenn die FTP-Anwendung nur eine Window-Größe von 32.000 Byte unterstützt, verwenden Sie diese Formel.

• 0,07 x * 1 Byte/8 Bit = 32.000

  wobei x= 3,657142 Mbit/s

Bei TFTP sendet der Sender 512-Byte-Pakete und muss eine Bestätigung für jedes Paket erhalten, bevor er das nächste Paket sendet. Das beste Szenario ist, ein Paket alle 70 ms zu senden. Verwenden Sie diese Durchsatzberechnung.

• 1 Paket /.070 s = 14,28571 Pakete/Sekunde

  512 Byte/Paket * 8 Bit/Byte * 14,28571 Pakete/Sekunde = 58,514 Kbit/s

Diese Durchsatzberechnung zeigt, dass die Verzögerung über eine Verbindung und die TCP-Fenstergröße den Durchsatz über diese Verbindung erheblich beeinflussen kann, wenn sie TCP/IP-Anwendungen zur Messung des Durchsatzes verwendet. Geben Sie den erwarteten Durchsatz für jede TCP-Verbindung an. Wenn FTP zum Testen des Durchsatzes verwendet wird, starten Sie mehrere Dateiübertragungen zwischen verschiedenen Clients und Servern, um festzustellen, ob der Durchsatz durch die TCP/IP-Eigenart begrenzt ist oder ob andere Probleme mit dem ATM-Schaltkreis auftreten. Wenn die TCP-Anwendung den Durchsatz begrenzt, sollten Sie mehrere Server haben, die gleichzeitig und mit ähnlichen Übertragungsraten senden.

Als Nächstes müssen Sie beweisen, dass Sie den Datenverkehr über die Verbindung mit der SCR-Geschwindigkeit des Stromkreises übertragen können. Verwenden Sie dazu eine Datenverkehrsquelle und einen Link, die kein TCP verwenden, und senden Sie einen Datenstrom über den ATM VC. Überprüfen Sie außerdem, ob die Empfangsrate der gesendeten Rate entspricht. Senden Sie erweiterte Ping-Pakete von einem Router mit einem Timeout-Wert von 0, um Datenverkehr in einem ATM-Schaltkreis zu generieren. Dies beweist, dass Sie Datenverkehr über die Verbindung mit der konfigurierten Geschwindigkeit des Stromkreises senden können.

Lösung: Vergrößern Sie das TCP/IP-Fenster.

Wichtig: Mit einem sehr kleinen RTT und einer Fenstergröße, die groß genug ist, um theoretisch die SCR zu füllen, werden Sie nie in der Lage sein, die SCR zu erreichen wegen des ATM-Overhead. Wenn Sie das Beispiel der 512-Byte-Pakete betrachten, die über eine 4-Mbit/s-PVC (SCR=PCR) AAL5SNAP gesendet werden, berechnen Sie den tatsächlichen IP-Durchsatz, der gemessen wird. Es wird davon ausgegangen, dass die TCP-Fenstergröße und die RTT-Größe so sind, dass die Quelle Daten mit 4 Mbit/s senden kann. Zunächst führen ATM Adaptation Layer 5 (AAL5) und SNAP jeweils 8 Byte Overhead ein. Aus diesem Grund kann es notwendig sein, die AAL5-Protokoll-Dateneinheit (PDU) durch 48 zu teilen, um sicherzustellen, dass sie geteilt werden kann. In jeder Zelle werden dann pro Zelle 5 Byte Overhead erzeugt. In diesem Fall bedeutet dies, dass die AAL5-Schicht 512+8+8=528 Byte (kein Padding erforderlich) beträgt. Für diese 528 Byte müssen 11 Zellen übertragen werden. Das bedeutet, dass für jedes zu sendende 512-Byte-Paket 583 Byte über die Leitung gesendet werden (11 x 53). Anders ausgedrückt: 71 Byte Overhead werden eingeführt. Das bedeutet, dass nur 88 % der Bandbreite von den IP-Paketen genutzt werden können. Bei der 4-Mbit/s-PVC bedeutet dies, dass der nutzbare IP-Durchsatz nur etwa 3,5 Mbit/s beträgt.

Je kleiner die Paketgröße, desto größer der Overhead und desto niedriger der Durchsatz.

Paketverlust

Der häufigste Grund für Leistungsprobleme ist der Paketverlust in allen ATM-Schaltkreisen. Jeder Zellverlust in einem ATM-Schaltkreis führt zu Leistungseinbußen. Der Paketverlust bedeutet eine erneute Übertragung sowie eine Reduzierung der TCP-Fenstergröße. Dies führt zu einem geringeren Durchsatz. In der Regel wird mit einem einfachen Ping-Test ermittelt, ob Pakete zwischen den beiden Geräten verloren gehen. CRC-Fehler (Cyclical Redundancy Check) und Funkzellen-/Paketverluste auf ATM-Schaltkreisen führen zur erneuten Übertragung von Daten. Wenn ATM-Zellen durch einen ATM-Switch aufgrund von Richtlinien oder Pufferüberlastung verworfen werden, werden auf dem Endgerät CRC-Fehler angezeigt, wenn die Zellen in Paketen reassembliert werden. ATM-Edge-Geräte können Pakete verwerfen oder verzögern, wenn die ausgehende Paketrate auf einem VC die konfigurierte Traffic Shaping-Rate auf dem VC überschreitet.

Weitere Informationen zur Behebung der häufigsten Ursachen für Paketverluste in ATM-Netzwerken finden Sie in diesen Dokumenten:

• CRC-Fehlerbehebungsleitfaden für ATM-Schnittstellen

• Fehlerbehebung bei Verlusten an ATM-Router-Schnittstellen

• Fehlerbehebung bei Verlusten an ATM-Router-Schnittstellen

• Abgelehnte/Verworfene Zellenzähler auf ATM-Switch-Routern

Lösung: Fehlerbehebung und Vermeidung von Paketverlusten

Verzögerung/Latenz

Die Zeit, die ein Paket benötigt, um von der Quelle zum Ziel zu gelangen und anschließend eine Bestätigung zum Absender zurückzugeben, kann den Durchsatz, der über diesen Schaltkreis zu sehen ist, erheblich beeinflussen. Die Verzögerung über einen ATM-Schaltkreis kann das Ergebnis einer normalen Übertragungsverzögerung sein. Es dauert weniger Zeit, ein Paket von New York nach Washington zu senden, als von New York nach Los Angeles, wenn der ATM-Schaltkreis die gleiche Geschwindigkeit hat. Weitere Verzögerungsquellen sind Warteschlangenverzögerungen über Router und Switches sowie Verzögerungen bei der Verarbeitung über Layer-3-Routing-Geräte. Die mit Routing-Geräten verbundene Verarbeitungsverzögerung hängt stark von der verwendeten Plattform und dem Switching-Pfad ab. Die Einzelheiten der Routing-Verzögerung und der internen Hardware-Verzögerung gehen über den Rahmen dieses Dokuments hinaus. Diese Verzögerung wirkt sich unabhängig vom Schnittstellentyp auf jeden Router aus. Sie ist im Vergleich zur Verzögerung bei der Übertragung von Paketen und der Warteschlangenverwaltung ebenfalls zu vernachlässigen. Wenn ein Router jedoch Switching-Datenverkehr verarbeitet, kann dies zu erheblichen Verzögerungen führen und muss berücksichtigt werden.

Die Verzögerung wird in der Regel mithilfe von Ping-Paketen zwischen Endgeräten gemessen, um die durchschnittliche und maximale Round-Trip-Verzögerung zu ermitteln. Verspätungsmessungen sollten während der Spitzenauslastung sowie bei Inaktivität durchgeführt werden. So kann leichter festgestellt werden, ob die Verzögerung auf Warteschlangenverzögerungen an überlasteten Schnittstellen zurückzuführen ist.

Eine Überlastung der Schnittstellen führt zu einer Warteschlangenverzögerung. Überlastungen resultieren in der Regel aus Bandbreitenungleichgewichten. Wenn Sie beispielsweise einen Schaltkreis über einen ATM-Switch haben, der von einer OC-12-Schnittstelle zu einer DS3 ATM-Schnittstelle wechselt, kann es zu einer Warteschlangenverzögerung kommen. Dies geschieht, wenn Zellen über die OC-12-Schnittstelle schneller eintreffen, als sie über die DS3-Schnittstelle ausgegeben werden können. ATM-Edge-Router, die für Traffic Shaping konfiguriert sind, schränken die Geschwindigkeit ein, mit der sie Datenverkehr an der Schnittstelle ausgeben. Wenn die Ankunftsrate des für den ATM VC bestimmten Datenverkehrs die Traffic Shaping-Raten der Schnittstelle übersteigt, werden die Pakete/Zellen in die Warteschlange der Schnittstelle gestellt. In der Regel ist die Verzögerung, die durch die Warteschlangenverzögerung verursacht wird, die Ursache von Leistungsproblemen.

Lösung: Implementieren Sie IP to ATM Class of Service (CoS)-Funktionen für differenzierten Service. Verwenden Sie Funktionen wie Class Based Weighted Fair Queuing (CBWFQ) und Low Latency Queuing (LLQ), um Warteschlangenverzögerungen für geschäftskritischen Datenverkehr zu reduzieren oder zu beseitigen. Erhöhen Sie die Bandbreite virtueller Schaltungen, um Überlastungen zu vermeiden.

Konfiguration des Traffic Shaping

ATM-PVCs und SVCs verfügen über QoS-Parameter (Quality of Service), die den einzelnen Schaltkreisen zugeordnet sind. Zwischen dem ATM Edge-Gerät und dem Netzwerk wird ein Datenverkehrsvertrag erstellt. Bei Verwendung von PVCs wird dieser Vertrag manuell im ATM-Netzwerk (ATM-Switches) konfiguriert. Bei SVCs wird die ATM-Signalisierung verwendet, um diesen Vertrag aufzustellen. Datenverkehrsformate von ATM-Edge-Geräten bilden die Übereinstimmung mit dem angegebenen Vertrag. ATM-Netzwerkgeräte (ATM-Switches) überwachen den Datenverkehr auf dem Stromkreis auf Übereinstimmung mit dem angegebenen Vertrag und kennzeichnen (markieren) oder verwerfen (überwachen) Datenverkehr, der nicht konform ist.

Wenn auf einem ATM-Edge-Gerät die Peak Cell Rate (PCR)/SCR konfiguriert ist, die die im Netzwerk bereitgestellte Geschwindigkeit übersteigt, ist ein Paketverlust wahrscheinlich. Die auf dem Edge-Gerät konfigurierten Traffic-Shaping-Raten sollten mit den im gesamten Netzwerk konfigurierten Raten übereinstimmen. Überprüfen Sie, ob die Konfiguration für alle konfigurierten Geräte übereinstimmt. Wenn das Edge-Gerät Zellen in das Netzwerk sendet, die nicht mit dem Vertrag übereinstimmen, der im gesamten Netzwerk bereitgestellt wird, werden in der Regel Zellen erkannt, die im Netzwerk verworfen werden. Dies kann in der Regel durch den Empfang von CRC-Fehlern am anderen Ende erkannt werden, wenn der Empfänger versucht, das Paket neu zusammenzubauen.

Ein ATM-Edge-Gerät mit PCR/SCR, das für eine niedrigere Geschwindigkeit konfiguriert ist als im Netzwerk bereitgestellt, führt zu Leistungseinbußen. In dieser Situation ist das Netzwerk so konfiguriert, dass es mehr Bandbreite bereitstellt, als das Edge-Gerät sendet. Diese Bedingung kann zu einer zusätzlichen Warteschlangenverzögerung und sogar zu einem Ausfall der Ausgabewarteschlange an der Ausgangsschnittstelle des ATM-Edge-Routers führen.

SVCs werden auf den Edge-Geräten konfiguriert, aber das Netzwerk kann den SVC-End nicht mit denselben Datenverkehrsparametern erstellen. Die gleichen Konzepte und Probleme gelten für SVCs, die auch für PVCs gelten. Das Netzwerk richtet den SVC möglicherweise nicht mit denselben QoS-Klassen und -Parametern ein. Diese Art von Problem wird in der Regel durch einen Fehler oder Interoperabilitätsprobleme verursacht. Wenn ein SVC signalisiert wird, legt der Anrufer die QoS-Traffic-Shaping-Parameter in die Vor- und Rückwärtsrichtung fest. Es kann vorkommen, dass der Angerufene den SVC nicht mit den richtigen Shaping-Parametern installiert. Die Konfiguration von Strict Traffic Shaping auf Routerschnittstellen kann verhindern, dass SVCs mit anderen als den konfigurierten Shaping-Parametern eingerichtet werden.

Der Benutzer muss den Pfad des SVC durch das Netzwerk nachverfolgen und überprüfen, ob er mithilfe der QoS-Klasse und der Parameter erstellt wird, die auf dem ursprünglichen Gerät konfiguriert sind.

Lösung: Wegfall von Datenverkehrs-Shaping-/Richtlinienkonfigurationsfehlern Wenn SVCs verwendet werden, stellen Sie sicher, dass sie durchgängig mit den richtigen Shaping-/Policing-Parametern eingerichtet sind. Konfigurieren von Strict Traffic Shaping auf ATM-Routerschnittstellen mit dem strengen Befehl ATM sig-traffic-Shaping.

SVCs, die über nicht optimale Pfade weitergeleitet werden

SVCs, die für UBR (Unspecified Bit Rate) konfiguriert sind, können über nicht optimale Pfade eingerichtet werden. Ein UBR VC ist in Bezug auf die Bandbreite auf die Leitungsgeschwindigkeit der Verbindungen beschränkt, die der VC durchquert. Wenn also eine Hochgeschwindigkeitsverbindung ausfällt, können die VCs, die diese Verbindung durchlaufen, über eine langsamere Verbindung wiederhergestellt werden. Selbst wenn die Hochgeschwindigkeitsverbindung wiederhergestellt wird, werden die VCs nicht abgebaut und über die schnellere Verbindung wiederhergestellt. Dies liegt daran, dass der langsamere Pfad die angeforderten (nicht angegebenen) QoS-Parameter erfüllt. Dieses Problem tritt sehr häufig in LANE-Netzwerken auf, die über alternative Pfade im Netzwerk verfügen. Wenn die alternativen Pfade dieselbe Verbindungsgeschwindigkeit aufweisen, werden alle SVCs durch den Ausfall einer der Verbindungen über denselben Pfad geroutet. Diese Situation kann den Durchsatz und die Leistung des Netzwerks erheblich beeinflussen, da die effektive Bandbreite des Netzwerks halbiert wird.

Sogar SVCs mit variabler Bit-Geschwindigkeit (VBR) und konstanter Bit-Rate (CBR) können über nicht optimale Pfade geroutet werden. Endgeräte fordern bestimmte Datenverkehrsparameter an (PCR, SCR, Maximum Burst Size {MBS}). Ziel von PNI (Private Network Network Interface) und ATM-Signalisierung ist es, einen Pfad bereitzustellen, der die QoS-Anforderungen der Anforderung erfüllt. Bei CBR- und VBR-rt-Anrufen umfasst dies auch die maximale Verzögerung bei der Zellübergabe. Ein Pfad kann aus Sicht der Bandbreite die vom Antragsteller angegebenen Anforderungen erfüllen, aber nicht der optimale Pfad. Dieses Problem tritt häufig auf, wenn es Pfade mit längerer Verzögerung gibt, die noch die Bandbreitenanforderungen für VBR- und CBR-VCs erfüllen. Dies kann für Kunden, die jetzt größere Verzögerungsmerkmale im gesamten Netzwerk sehen, als Leistungsproblem wahrgenommen werden.

Lösung: SVCs in einem ATM-Netzwerk werden bei Bedarf eingerichtet und in der Regel nicht über einen anderen Pfad abgeschaltet und umgeleitet, es sei denn, der SVC wird abgeschaltet (aufgrund von Inaktivität oder aus anderen Gründen freigegeben). Die ATM-Switches Cisco LightStream 1010 und Catalyst 8500 bieten die Funktion zur Optimierung von Soft-PVC-Routen. Diese Funktion ermöglicht die dynamische Umleitung einer Soft-PVC, wenn eine bessere Route verfügbar ist. Eine ähnliche Funktionalität ist für SVCs nicht verfügbar, die nicht auf den ATM-Switches terminieren.

Eine mögliche Lösung für dieses Problem ist die Verwendung von PVCs zwischen den ATM-Edge-Geräten und den angeschlossenen ATM-Switches. Weiche PVCs mit zwischen ATM-Switches konfigurierter Routenoptimierung ermöglichen die Umleitung des Datenverkehrs von nicht optimalen Pfaden nach Verbindungsausfall und nachfolgender Wiederherstellung.

Konfigurieren Sie das Leerlaufzeitintervall für SVCs so, dass SVCs abgebaut und häufiger wiederhergestellt werden. Mit dem Befehl Leerlauf-Timeout-Sekunden [Mindest-Rate] können Sie die Zeit- und Datenverkehrsraten ändern, die zum Abbruch des SVC führen. Dies ist möglicherweise nicht besonders effektiv, da der VC inaktiv sein muss, um über den optimalen Pfad umgeleitet zu werden.

Wenn alle anderen Fehler auftreten, stellen Sie sicher, dass der optimale Pfad wiederhergestellt wurde und starten Sie dann eine der ATM-Schnittstellen, die dem redundanten Pfad mit langsamer Geschwindigkeit zugeordnet ist, oder eine der Router-Schnittstellen, die den SVC terminiert.

Hardware-Probleme

Leistungsprobleme bei PA-A1

Die Architektur des PA-A1 ATM-Port-Adapters und der fehlende integrierte Speicher können zu Leistungseinbußen führen. Dieses Problem kann sich in Abbruch-, Überlauf-, Ignorieren- und CRCs auf der Schnittstelle manifestieren. Bei Verwendung eines Cisco 7200-Routers mit NPE-100/175/225/300 kommt das Problem noch verstärkt zum Tragen.

Weitere Informationen finden Sie unter Fehlerbehebung bei Eingabefehlern auf PA-A1-ATM-Port-Adaptern.

Lösung: Ersetzen Sie PA-A1 ATM-Port-Adapter durch PA-A3 (mindestens Version 2) oder PA-A6 ATM-Port-Adapter.

PA-A3 Version 1

Die PA-A3-Hardware-Version 1 assembliert keine Zellen in Paketen, die den integrierten statischen RAM (SRAM) auf dem Port-Adapter verwenden. Der Adapter leitet die Zellen über den PCI-Bus (Periphery Component Interconnect) an den VIP- (Versatile Interface Processor) oder NPE-Host-Speicher (Network Processing Engine) weiter, wo er die Pakete neu zusammensetzt. Dies führt zu ähnlichen Problemen im Zusammenhang mit der Leistung, wie sie bei dem PA-A1 ATM-Port-Adapter beobachtet wurden.

Weitere Informationen finden Sie unter Fehlerbehebung bei Ein- und Ausgangsfehlern bei PA-A3 ATM-Port-Adaptern.

Lösung: Ersetzen Sie PA-A3 Hardware Version 1 ATM-Port-Adapter durch PA-A3 (mindestens Version 2) oder PA-A6 ATM-Port-Adapter.

Zwei PA-A3-PAs in VIP2-50

PA-A3-OC3SMM, PA-A3-OC3SMI und PA-A3-OC3SML sind so konzipiert, dass sie maximale Switching-Leistung bieten, wenn ein Port-Adapter in einem einzigen VIP2-50 installiert wird. Ein einzelner PA-A3-OC3SMM, PA-A3-OC3SMI oder PA-A3-OC3SML in einem VIP2-50 stellt mit 64-Byte-Paketen bis zu 85.000 Pakete pro Sekunde Switching-Kapazität in jeder Richtung bereit. Beachten Sie, dass ein einziger PA-A3-OC3SMM, PA-A3-OC3SMI oder PA-A3-OC3SML allein die gesamte Switching-Kapazität eines einzigen VIP2-50 nutzen kann.

Für Anwendungen, die eine maximale Portdichte oder niedrigere Systemkosten erfordern, werden jetzt Dual-Port-Adapterkonfigurationen mit der OC-3/STM-1-Version des PA-A3 im gleichen VIP2-50 unterstützt. Die beiden Port-Adapter im gleichen VIP2-50 nutzen in jeder Richtung mithilfe von 64-Byte-Paketen ca. 95.000 Pakete pro Sekunde Switching-Kapazität.

Je nach Port-Adapterkombination stellt der VIP-50 eine aggregierte Bandbreite von bis zu 400 Megabit pro Sekunde (Mbit/s) bereit. In den meisten Dual-Port-Adapterkonfigurationen mit PA-A3-OC3SMM, PA-A3-OC3SMI oder PA-A3-OC3SML übersteigt die Kombination von Port-Adaptern diese aggregierte Bandbreitenkapazität.

Folglich wird die von den beiden im selben VIP2-50 installierten Port-Adaptern gemeinsam genutzte Leistung durch die aggregierte Switching-Kapazität (95 Kpps) bei kleinen Paketgrößen und die aggregierte Bandbreite (400 Mbit/s) bei großen Paketgrößen begrenzt.

Diese Leistungseinschränkungen müssen berücksichtigt werden, wenn Sie ATM-Netzwerke mit dem PA-A3-OC3SMM, PA-A3-OC3SMI oder PA-A3-OC3SML bestimmen. Je nach Design ist die Leistung von Dual-Port-Adaptern im selben VIP2-50-Switch möglicherweise nicht akzeptabel.

Weitere Informationen finden Sie unter Unterstützte PA-A1- und PA-A3 VIP2-Konfigurationen.

LANE-Probleme

LANE Broadcast-Domäne

Eine übermäßige Anzahl von Endsystemen in einem einzelnen LANE ELAN kann die Leistung aller Endstationen erheblich beeinträchtigen. Ein ELAN stellt eine Broadcast-Domäne dar. Alle Workstations und Server im ELAN empfangen Broadcast- und möglicherweise Multicast-Datenverkehr von allen anderen Geräten im ELAN. Wenn der Broadcast-Datenverkehr im Verhältnis zur Verarbeitungskapazität der Workstation hoch ist, leidet die Leistung der Workstations.

Lösung: Beschränkung der Anzahl von Endstationen innerhalb eines einzelnen ELAN auf weniger als 500 Überwachen Sie das Netzwerk auf Broadcast-/Multicast-Stürme, die die Server-/Workstation-Leistung beeinträchtigen können.

Weitere Informationen finden Sie unter Empfehlungen zum LANE-Design.

Übermäßige Änderungen an der LLE-ARP-Datenverkehr- und Spanning Tree-Topologie

Andere Probleme, die in einem LANE-Netzwerk zu Leistungseinbußen führen können, sind übermäßige LANE ARP (LE-ARP)-Aktivitäten und Änderungen der Spanning Tree-Topologie. Diese Probleme führen zu ungelösten LE-ARPs, die zu Verkehr über den Bus führen. Dies kann auch zu einer hohen CPU-Auslastung der LECs im Netzwerk führen, was auch Leistungsprobleme verursachen kann. Weitere Informationen zu diesen Problemen finden Sie unter Troubleshooting Spanning-Tree over LANE.

Konfigurieren Sie Spanning Tree PortFast auf den Host-Ports der mit LANE verbundenen Ethernet-Switches, um Änderungen an der Spanning Tree-Topologie zu reduzieren. Konfigurieren der lokalen LE-ARP-erneuten Überprüfung auf Catalyst 5000- und 6000-Switches, die für LAN konfiguriert sind, um den LE-ARP-Datenverkehr zu reduzieren

VBR-nrt Data Direct SVCs

Mithilfe von LANE Version 1 werden SVCs als UBR-Servicekategorie eingerichtet. Die Version 2 von LANE unterstützt die Einrichtung von Data Direct SVCs unter Verwendung anderer Servicekategorien wie VBR-nrt. Ein Drittanbieter hat einen Fehler bei der Implementierung seiner LANE-Clients, der dazu führen kann, dass die für Cisco Geräte eingerichteten Data Direct SVCs mit einer SCR von 4 Kbit/s VBR-nrt sind. Wenn Ihr ATM-Backbone aus OC-3-Trunk-Verbindungen (155 Mbit/s) und OC-12-Trunk-Verbindungen (622 Mbit/s) besteht und Sie SVC über diese Trunks mit einer Sustained Cell Rate von 4 Kbit/s einrichten, leidet Ihre Leistung. Dieses spezielle Problem ist zwar nicht häufig anzutreffen, weist jedoch auf eine wichtige Notwendigkeit hin, wenn Sie Leistungsprobleme bei ATM-Schaltungen beheben. Sie müssen den Pfad verfolgen, über den Ihre SVCs das Netzwerk durchlaufen, und überprüfen, ob der VC mit der gewünschten Servicekategorie und den gewünschten Verkehrsparametern eingerichtet wurde.

Direkte Daten-VCs sind nicht eingerichtet

LANE Data Direct VCs sind bidirektionale Point-to-Point-SVCs, die zwischen zwei LAN Emulation Clients (LECs) eingerichtet werden und für den Datenaustausch zwischen diesen Clients verwendet werden. LANE-Clients senden LE-ARP-Anfragen, um die mit einer MAC-Adresse verknüpften ATM-Adressen zu ermitteln. Anschließend wird versucht, eine Data Direct VC für diese ATM-Adresse einzurichten. Vor der Data Direct VC-Einrichtung überfluten LANE-Clients unbekannte Unicast-Pakete an den Broadcast und Unknown Server (BUS). Ein LANE-Client kann zum Senden von Unicast-Daten an einen anderen LEC möglicherweise keine Data Direct VC einrichten. In diesem Fall kann es zu Leistungseinbußen kommen. Das Problem ist erheblich, wenn das Gerät, das für die Ausführung der BUS-Dienste ausgewählt wurde, nicht voll oder ganz ausgelastet ist. Außerdem können einige Plattformen Grenzwertüberschreitungen bei Unicasts festsetzen, die an den BUS weitergeleitet werden. Das Catalyst 2900XL LANE-Modul ist eine dieser Appliances, die Unicast-Datenverkehr, der an BUS gesendet wird, drosselt, während dies bei Catalyst 5000 und Catalyst 600 der Fall ist.

Der Data Direct SVC kann aus folgenden Gründen nicht eingerichtet oder verwendet werden:

• Der LEC erhält keine Antwort auf die LE-ARP-Anfrage.

• Der SVC kann aufgrund von ATM-Routing- oder Signalisierungsproblemen nicht erstellt werden.

• Fehler beim LANE Flush Message Protocol. Sobald der Data Direct VC eingerichtet ist, sendet der LEC eine Flush-Anfrage an den Multicast Send VC, um sicherzustellen, dass alle über den BUS gesendeten Datenframes ihr Ziel erreicht haben. Wenn das LEC, das die Flush-Anforderung gesendet hat, eine Antwort erhält, beginnt es, Daten über das Data Direct VC zu senden. Der Flush-Mechanismus kann mit dem Befehl no lane client flush deaktiviert werden.

IMA-Probleme

UBR-PVCs auf IMA-Schnittstellen

UBR VCs an IMA-Schnittstellen (Inverse Multiplexing) werden mit einer PCR von 1,5 Mbit/s eingerichtet, anstatt der Summe aller Up/Up-physischen Schnittstellen, die in der IMA-Gruppe konfiguriert sind. Diese Bedingung beeinträchtigt die Leistung, da der VC-Datenverkehr mit einer geringeren Geschwindigkeit als die kombinierte Bandbreite aller Verbindungen in der IMA-Gruppe geformt wird.

Ursprünglich war die Bandbreite einer IMA-Gruppenschnittstelle auf die Mindestanzahl aktiver IMA-Verbindungen beschränkt, die zur Aufrechterhaltung der IMA-Schnittstelle erforderlich waren. Der Befehl zum Definieren dieses Werts lautet IMA active-links-minimum. Wenn z. B. vier physische ATM-Schnittstellen als Mitglieder der IMA-Gruppe 0 konfiguriert sind und der Mindestwert für aktive Verbindungen des IMA auf einen festgelegt ist, entspricht die Bandbreite einer T1- oder 1,5-Mbit/s-Bandbreite nicht 6 Mbit/s.

Cisco Bug ID CSCdr12395 (nur registrierte Kunden) ändert dieses Verhalten. Der PA-A3-8T1IMA-Adapter nutzt jetzt die Bandbreite aller physischen ATM-Schnittstellen, die als IMA-Gruppenmitglieder konfiguriert sind.

Cisco Bug-IDs CSCdt67354 (nur registrierte Kunden) und CSCdv67523 (nur registrierte Kunden) sind nachfolgende Verbesserungsanfragen zur Aktualisierung der IMA-Gruppe VC-Bandbreite, wenn eine Schnittstelle zur IMA-Gruppe hinzugefügt oder aus dieser entfernt wird, "shut" aufgrund eines Verbindungsausfalls oder einer Änderung am Remote-Ende. Die im Cisco Bug IDCSCdr12395 implementierten Änderungen (nur registrierte Kunden) konfigurieren die IMA-Gruppenbandbreite nur dann auf die Gesamtbandbreite ihrer Mitgliedsverbindungen, wenn die IMA-Gruppe aktiv ist. Änderungen an der IMA-Gruppe nach dem Erststatus werden nicht übernommen.

Weitere Informationen finden Sie unter Fehlerbehebung bei ATM-Links auf dem 7x00-IMA-Port-Adapter.

Zugehörige Informationen

• PNI-Routenauswahl (Private Network-to-Network Interface)
• TCP-Fensterskalierung
• Fehlerbehebung bei ATM-Links am 7x00 IMA-Port-Adapter
• Unterstützte PA-A1- und PA-A3 VIP2-Konfigurationen
• Details zur TCP/IP-Implementierung in Microsoft Windows 2000
• Fehlerbehebung: TCP/IP
• Technischer Support - Cisco Systems

Revisionsverlauf