Konfiguration und Verifizierung verteilter Funktionen auf Cisco Routern der Serien 75xx und 76xx

Einführung

Dieses Dokument hilft Ihnen, die folgenden Funktionen zu verstehen, zu konfigurieren und zu überprüfen:

• Distributed Multilink Point to Point Protocol (dMLP)

• Distributed Link Fragmentation and Interleaving (LFI)

• Verteilte LFI über Mietleitung (dLFIoLL)

• Distributed LFI over Frame Relay (dLFIoFR)

• Verteilter LFI over ATM (dLFIoATM)

• Unterschiede zwischen verteiltem MLP (dMLP) und dLFIoLL

• Distributed Multilink Frame Relay (dMLFR)

• Distributed Dial on Demand Routing (DDR)

Voraussetzungen

Anforderungen

Leser dieses Dokuments sollten über Kenntnisse über verteilte Funktionen für Cisco 7500/7600/6500 verfügen.

Verwendete Komponenten

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

• Alle Cisco 7500- und 7600-Plattformen

  Hinweis: Die Informationen in diesem Dokument gelten auch für 6500-Plattformen.

• Relevante Cisco IOS® Softwareversionen, die in dieser Tabelle aufgeführt sind:

Unterstützung verteilter Funktionen für jede Zweigstelle und Plattform

Funktion	Unterstützte Port-Adapter (PAs)1	7500 Plattformen		7600-Plattformen
		Wichtigste Cisco IOS Software-Versionen	Cisco IOS-Versionen (Interim)	Wichtigste Cisco IOS Software-Versionen	Cisco IOS Software Releases (Interim)
dMLP	Chan-PA-4T+ PA-8T	12,0T 12,0S 12,1 12,1T 12,2 12,2T 12,3 12,3T 12,2S 12,1E2	12.0(3)T und spätere 12.0(9)S und spätere Version	12.2SX 12.1E2	—
dLFIoLL	Chan-PA-4T+ PA-8T	12,2 T 12,3 12,3 T 12,3 T 12,0 S	12.2(8)T und spätere 12.0(24)S und spätere Version	12.2SX	12.2(17)SXB und höher
dLFIoFR	Chan-PA-4T+ PA-8T	12,2 T 12,3 12,3 T	12.2(4)T3 und höher	12.2SX	12.2(17)SXB und höher
dLFIoATM	PA-A3 PA-A6	12,2 T 12,3 12,3 T	12.2(4)T3 und höher	12.2SX	12.2(17)SXB und höher
dMLFR	Chan-PA-4T+ PA-8T	12,0 S 12,3 T	12.0(24)S und spätere 12.3(4)T und spätere Version	12.2SX	12.2(17)SXB und höher
QoS auf dMLP	Chan-PA-4T+ PA-8T	12,0 S 12,2 T 12,3 12,3 T	12.0(24)S und spätere 12.2(8)T und spätere Version	12.2SX	12.2(17)SXB und höher
MPLS in dMLP MPLS bei dLFIoLL	Chan-PA-4T+ PA-8T	12,2 T 12,3	12.2(15)T11 und höher 12.3(5a) und höher	12.2SX	12.2(17)SXB und höher
Verteilte DDR	PA-MC-xT1 PA-MC-xE1 PA-MC-xTE1 PA-MCX-xTE1	12,3 Bio.	12.3(7)T und spätere Version	—	—

Hinweis: Beachten Sie diese Informationen:

1. Diese PAs unterstützen verteilte Funktionen:

   • CT3IP

   • PA-MC-T3

   • PA-MC-2T3+

   • PA-MC-E3

   • PA-MC-2E1

   • PA-MC-2T1

   • PA-MC-4T1

   • PA-MC-8T1

   • PA-MC-8E1

   • PA-MC-8TE1+

   • PA-MC-STM-1

2. Cisco IOS Software Release 12.1E unterstützt diese Funktionen auf den Plattformen 7500 und 7600.

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.

Verteilte Funktionen

Diese Funktionen werden in diesem Dokument erläutert:

• Verteiltes MLP

• Verteiltes LFI

• Verteiltes LFI über Mietleitung

• Verteiltes LFI über Frame Relay

• Verteiltes LFI über ATM

• Unterschiede zwischen dMLP und dLFIoLL

• Verteilte MLFR

• Distributed Dialer

• Plattformen und Line Cards, die verteilte Funktionen unterstützen

Verteiltes MLPPP

Mit der Funktion Distributed Multilink Point to Point Protocol (dMLP) können Sie T1/E1-Leitungen in einer Linecard (VIP, FlexWAN) auf einem Cisco Router der Serie 7500 oder 7600 ganz oder teilweise in einem Paket kombinieren, das die kombinierte Bandbreite mehrerer Verbindungen bietet. Hierzu verwenden Sie ein verteiltes MLP-Paket. Ein Benutzer kann die Anzahl der Pakete in einem Router und die Anzahl der Links pro Paket auswählen. So kann der Benutzer die Bandbreite der Netzwerkverbindungen über die einer einzelnen T1/E1-Leitung hinaus erhöhen, ohne dass eine T3-Leitung erworben werden muss. Bei Nicht-dMLP werden alle Pakete vom Route Processor (RP) geswitcht. Daher wirkt sich diese Implementierung auf die Leistung des RP aus, wobei eine hohe CPU-Auslastung nur für einige wenige T1/E1-Leitungen mit MLP ausgeführt wird. Mit dMLP wird die Gesamtzahl der Pakete, die auf dem Router verarbeitet werden können, erhöht, da der Datenpfad behandelt wird und durch Linecard-CPU und -Speicher begrenzt wird. Mit dMLP können Sie fraktioniertes T1/E1 von DS0 (64 Kbit/s) an bündeln.

Verteiltes LFI

Die dLFI-Funktion unterstützt die Übertragung von Echtzeit-Datenverkehr (z. B. Sprache) und Nicht-Echtzeit-Datenverkehr (z. B. Daten) auf Virtual Circuits (VCs) mit niedrigerer Geschwindigkeit und auf Mietleitungen, ohne dass der Echtzeit-Datenverkehr übermäßig verzögert wird.

Diese Funktion wird über Multilink PPP (MLP) über Frame Relay, ATM und Mietleitungen implementiert. Die Funktion fragmentiert ein großes Datenpaket in eine Folge kleinerer Fragmente, sodass verzögerungsempfindliche Echtzeit-Pakete und Pakete, die nicht in Echtzeit sind, dieselbe Verbindung gemeinsam nutzen können. Die Fragmente werden dann mit den Echtzeit-Paketen verschachtelt. Auf der Empfängerseite der Verbindung werden die Fragmente wieder zusammengesetzt und das Paket rekonstruiert.

Die dLFI-Funktion ist häufig in Netzwerken nützlich, die Echtzeitdatenverkehr über Distributed Low Latency Queuing (z. B. Sprache) senden, jedoch Bandbreitenprobleme haben. Dies verzögert den Echtzeit-Datenverkehr aufgrund der Übertragung großer, weniger zeitkritischer Datenpakete. Sie können die dLFI-Funktion in diesen Netzwerken verwenden, um die großen Datenpakete in mehrere Segmente zu zerlegen. Die Echtzeit-Datenverkehrspakete können dann zwischen diesen Segmenten der Datenpakete gesendet werden. In diesem Szenario tritt für den Echtzeit-Datenverkehr keine langwierige Verzögerung ein, während er darauf wartet, dass Datenpakete mit niedriger Priorität das Netzwerk durchlaufen. Die Datenpakete werden auf der Empfängerseite der Verbindung reassembliert, sodass die Daten intakt übertragen werden.

Die Fragmentgröße der Verbindung wird basierend auf der Fragmentverzögerung im Multilink-Bündel berechnet, das mit dem Befehl ppp multilink fragment-delay n konfiguriert wurde, wobei:

fragment size = bandwidth × fragment-delay / 8

Diese Fragmentgröße stellt nur die IP-Nutzlast dar. Sie enthält nicht die Kapselungsbyte (Fragmentgröße = Gewicht - Kapselungsbyte). Die Begriffe "Gewicht" und "Fragmentgröße" sind in der Ausgabe des Befehls show ppp multilink auf dem RP zu sehen. Wenn die Fragmentverzögerung nicht konfiguriert wird, wird die standardmäßige Fragmentgröße für eine maximale Fragmentverzögerung von 30 berechnet.

Hinweis: Bei Verbindungen unterschiedlicher Bandbreite basiert die ausgewählte Fragmentgröße auf der Verbindung mit der geringsten Bandbreite.

Verteiltes LFI über Mietleitung

Die dLFIoLL-Funktion erweitert die verteilte Link-Fragmentierung und die Interleaving-Funktion auf Mietleitungen. Verteiltes LFI wird mit dem Befehl ppp multilink interleave auf der Multilink-Gruppenschnittstelle konfiguriert. Es wird empfohlen, verteiltes LFI auf Multilink-Schnittstellen mit einer Bandbreite von weniger als 768 Kbit/s zu verwenden. Dies liegt daran, dass die Serialisierungsverzögerung für 1500-Byte-Pakete mit einer Bandbreite von mehr als 768 Kbit/s innerhalb akzeptabler Verzögerungs-Grenzen liegt und nicht fragmentiert werden muss.

Verteiltes LFI über Frame Relay

Die dLFIoFR-Funktion ist eine Erweiterung der MLPoFR-Funktion (Multilink PPP over Frame Relay). Für die Fragmentierung wird MLP verwendet. Diese Funktion ähnelt FRF.12, die Fragmentierung unterstützt und Pakete mit hoher Priorität über Low Latency Queuing (Low Latency Queuing) interagieren kann.

Der Befehl ppp multilink interleave in der virtuellen Vorlage ist erforderlich, um die Verknüpfung in der zugehörigen Virtual-Access-Schnittstelle zu aktivieren. Neben der Aktivierung von verteiltem CEF-Switching auf der seriellen Schnittstelle ist dieser Befehl eine Voraussetzung für die Arbeit verteilter LFI.

Hinweis: Es wird empfohlen, FRF.12 anstelle von dLFIoFR zu verwenden, es sei denn, Sie verwenden Frame Relay zum ATM Internetworking, da die Bandbreitennutzung mit FRF besser ist.12

Verteiltes LFI über ATM

Die dLFIoATM-Funktion ist eine Erweiterung der MLPoATM-Funktion (Multilink PPP over ATM). Für die Fragmentierung wird MLP verwendet.

Der Befehl ppp multilink interleave in der virtuellen Vorlage ist erforderlich, um die Verknüpfung in der zugehörigen Virtual-Access-Schnittstelle zu aktivieren. Neben der Aktivierung von verteiltem CEF-Switching auf der seriellen Schnittstelle ist dieser Befehl eine Voraussetzung für die Arbeit verteilter LFI.

Bei dLFIoATM ist es sehr wichtig, dass Sie eine Fragmentgröße auswählen, durch die die Pakete so in ATM-Zellen passen, dass sie nicht zu unnötigem Padding in den ATM-Zellen führen. Wenn die ausgewählte Fragmentgröße beispielsweise 124 Byte beträgt, bedeutet dies, dass eine IP-Nutzlast von 124 Byte endlich 124 + 10 (MLP-Header) + 8 (SNAP-Header) = 142 Byte beträgt. Es ist wichtig zu beachten, dass das erste Fragment mit 124 + 10 + 2 (PID-Header-Größe des ersten Fragment) + 8 = 144 Byte ausgehen würde. Das bedeutet, dass dieses Paket drei ATM-Zellen für die Übertragung der Nutzlast verwendet und daher die gepackte Zelle am effizientesten nutzen würde.

Unterschiede zwischen dMLP und dLFIoLL

dMLP unterstützt keine Fragmentierung auf der Übertragungsseite, dLFIoLL hingegen nicht.

Hinweis: Interleaving und Fragmentierung, die mit mehr als einer Verbindung im Multi-Link-Paket für Sprachdatenverkehr verwendet werden, gewährleisten nicht, dass der Sprachdatenverkehr, der über mehrere Links im Paket empfangen wird, in der richtigen Reihenfolge empfangen wird. Die korrekte Reihenfolge der Sprachdaten wird auf den oberen Ebenen festgelegt.

Verteilte MLFR

Die verteilte MLFR-Funktion bietet Funktionen, die auf dem Frame Relay Forum Multilink Frame Relay UNI/NNI Implementation Agreement (FRF.16) für Line Card-fähige Cisco Router der Serien 7500 und 7600 basieren. Die verteilte MLFR-Funktion bietet eine kosteneffiziente Möglichkeit, die Bandbreite für bestimmte Anwendungen zu erhöhen, da mehrere serielle Verbindungen in einem einzigen Bandbreitenpaket zusammengefasst werden können. MLFR wird in Frame-Relay-Netzwerken auf User-to-Network-Schnittstellen (UNI) und Network-to-Network-Schnittstellen (NNI) unterstützt.

Das Paket besteht aus mehreren seriellen Verbindungen, die als Paketlinks bezeichnet werden. Jede Paketverbindung innerhalb eines Pakets entspricht einer physischen Schnittstelle. Paketlinks sind für die Frame-Relay-Sicherungsschicht nicht sichtbar, sodass Frame-Relay-Funktionen auf diesen Schnittstellen nicht konfiguriert werden können. Die reguläre Frame-Relay-Funktion, die Sie auf diese Links anwenden möchten, muss auf der Paketschnittstelle konfiguriert werden. Paketverbindungen sind für Peer-Geräte sichtbar.

Verteilte DDR

Die verteilte DDR-Funktion ermöglicht verteiltes Switching auf Dialer-Schnittstellen. Ohne diese Funktion muss der gesamte Einwahldatenverkehr für das Switching an den Host geleitet werden. Dabei werden nur Steuerungspakete an den RP gesendet, während die Switching-Entscheidung für die VIPs selbst nach Herstellung einer Verbindung erfolgt.

Sowohl die Legacy Dialer-Konfiguration als auch die Dialer Profile-Konfiguration werden nur mit PPP-Kapselung unterstützt. MLP auf Dialer-Schnittstellen wird ebenfalls unterstützt. QoS wird bei verteiltem Switching auf Dialer-Schnittstellen nicht unterstützt.

Voraussetzungen und Einschränkungen für verteilte Funktionen

Voraussetzungen

Dies sind allgemeine Voraussetzungen für all diese verteilten Funktionen:

• Distributed Cisco Express Forwarding (dCEF)-Switching muss global aktiviert werden.

• dCEF-Switching muss an der seriellen Schnittstelle des Mitglieds aktiviert werden, die Teil des MLP-Pakets ist.

• dCEF-Switching muss auf der physischen Verbindung der dLFIoFR- und dLFIoATM-Schnittstellen aktiviert werden.

• Für die Verteilung von LFIoFR und LFIoATM ist eine Konfiguration für den Hinterlassen erforderlich.

• Konfigurieren Sie die erforderliche Bandbreite auf der Virtual-Template-Schnittstelle für dLFIoFR- und dLFIoATM-Schnittstellen.

• Wenn PPP-Debugger auf dem RP aktiviert sind, können Sie das MLP beobachten: Route Switch Processor (RSP) wurde an falsche Schnittstellenmeldung weitergeleitet. Da diese Nachricht verwirrend und unerwünscht ist - insbesondere wenn es sich um Cisco Discovery Protocol (CDP)-Pakete handelt - müssen Sie keine cdp enable für die Mitgliedsverbindungen des Pakets konfigurieren.

• Bei allen Mitgliedsverbindungen des Pakets sollte die Keepalive-Funktion aktiviert sein.

Einschränkungen

Dies sind allgemeine Einschränkungen für alle diese verteilten Funktionen:

• T1- und E1-Leitungen können nicht in einem Paket gemischt werden.

• Die maximal unterstützte Differenzialverzögerung beträgt 30 ms.

• Alle Posten in einem Paket müssen sich auf demselben Port-Adapter (PA) befinden.

• Hardwarekomprimierung wird nicht unterstützt.

• VIP oder FlexWAN CEF ist auf IP beschränkt. alle anderen Protokolle werden an den RSP gesendet.

• Die Fragmentierung wird auf der Transmit-Seite für dMLP und dMLFR nicht unterstützt.

• Viele der älteren Warteschlangenmechanismen werden von dLFI nicht unterstützt. Diese Mechanismen umfassen:

  • Fair Queuing auf einer virtuellen Vorlagenschnittstelle

  • Random Detection auf einer virtuellen Vorlagenschnittstelle

  • Benutzerdefinierte Warteschlange

  • Prioritätswarteschlange

• Fair Queuing, Randerkennung (dWRED) und Priority Queuing können in einer Datenverkehrsrichtlinie mit der Modular QoS CLI konfiguriert werden.

• Pro MLP-Paket wird nur eine Verbindung unterstützt, wenn Sie dLFIoFR oder dLFIoATM verwenden. Wenn bei Verwendung von dLFIoFR oder dLFIoATM mehr als eine Verbindung in einem MLP-Paket verwendet wird, wird dLFI automatisch deaktiviert. Bei der Verwendung von dLFI über Mietleitungen können mehrere Verbindungen mit dLFI im MLP-Paket konfiguriert werden.

• Mit dLFIoATM werden nur aal5nap und aal5mux unterstützt. Kapselung aal5nlpid und aal5ciscopp werden nicht unterstützt.

• Nur Voice-over-IP wird unterstützt. Voice over Frame Relay und Voice over ATM werden von der dLFI-Funktion nicht unterstützt.

• Die Konfiguration des komprimierten Real-Time Protocol (CRTP) sollte nicht auf der Multilink-Schnittstelle konfiguriert werden, wenn Sie diese Funktionskombination verwenden:

  • Multilink-Schnittstelle mit LFI-Funktion

  • Multilink-Bündel enthält mehr als eine Mitgliedsverbindung.

  • QoS-Richtlinie mit Prioritätsfunktion ist an der Multilink-Schnittstelle aktiviert.

Bei der dMLP- und dLFI-Konfiguration enthalten Prioritätspakete keine MLP-Header und -Sequenznummern, und MLP verteilt die Prioritätspakete über alle Member-Links. Daher können von CRTP komprimierte Pakete beim empfangenden Router in der Out-of-Order-Konfiguration eintreffen. Dies verhindert, dass CRTP den Paket-Header dekomprimiert, und zwingt CRTP, die Pakete zu verwerfen.

Empfehlungen

Es wird empfohlen, dass Mitgliedslinks in einem Paket die gleiche Bandbreite haben. Wenn Sie dem Paket ungleiche Bandbreitenlinks hinzufügen, führt dies zu einer großen Anzahl neu sortierter Pakete, wodurch der Gesamtdurchsatz des Pakets verringert wird.

Für diese verteilten Funktionen wird die Verwendung von VIP2-50 (mit 8 MB SRAM) oder höher empfohlen.

Anzahl der Pakete und Links und Speicheranforderungen

Informationen zu Cisco Routern der Serie 7500 finden Sie unter Distributed Multilink Point-to-Point Protocol.

Hardware- und Software-MLPPP oder MLFR auf 7600 SIP-Linecards

MLP und MLFR können softwarebasiert oder hardwarebasiert sein. In hardwarebasiertem MLP oder MLFR stellt Freedm die Multilink-Funktionalität bereit, und die MLP-Header werden von Freedm Chip hinzugefügt. In softwarebasiertem MLP oder MLFR stellt die SIP Line Card CPU die Multilink-Funktionalität bereit (die der VIP- und FlexWAN-Implementierung ähnelt).

Dies sind die Einschränkungen und Bedingungen für die Ausführung von hardwarebasiertem MLP oder MLFR.

• Pro Line Card sind maximal 336 Pakete und 168 Pakete pro Security Posture Assessment (SPA) (Freedm) möglich.

• Pro Paket können maximal 12 DS1/E1 verwendet werden.

• Alle Links sollten demselben SPA (Freedm) angehören.

• Alle Links im Paket sollten mit derselben Geschwindigkeit betrieben werden.

• Die TX-Fragment-Größe kann 128, 256 oder 512 sein. Eine für die CLI konfigurierte Fragmentgröße wird der nächstgelegenen unterstützten Fragmentgröße zugeordnet.

  IF (0 < cli_fragment_size – 6 < 256)
  configured_fragment_size = 128
  Else IF (cli_fragment_size < 512)
  	configured_fragment_size = 256
  Else
  	configured_fragment_size = 512

• Die RX-Fragmentgröße kann 1 bis 9,6 KB betragen.

• Das proprietäre Format von Cisco kann nicht unterstützt werden (MLFR).

Wenn bei Hardware-LFI nur eine Verbindung im Paket vorhanden ist und es sich um DS1/E1 handelt, werden Fragmentierung und Interleaving von Freedm vorgenommen.

Die Ausgabe von show ppp multilink zeigt, ob die Hardware-Implementierung ausgeführt wird.

Multilink1, bundle name is M1
  Bundle up for 00:14:51
  Bundle is Distributed

  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
   Member links: 1 active, 0 inactive (max not set, min not set)
   Se6/1/0/1:0, since 00:14:51, no frags rcvd
  Distributed fragmentation on. Fragment size 512.  Multilink in Hardware.

Wenn Multilink softwarebasiert ist, wird die show ppp multilink-Ausgabe keine Multilink in Hardware in der Ausgabe enthalten.

Lebensdauer eines Pakets

Rx-Datenpfad

1. Paket wird vom Treiber empfangen.

2. Kapselung wird überprüft: wie folgt

   1. Grundlegende Kapselung:

      1. In dMLP lautet der Kapselungstyp für die Eingangs-Schnittstelle ET_PPP.

      2. In dMLFR lautet der Kapselungstyp für die Eingangsoberfläche ET_FRAME_RELAY.

      3. In dLFIoLL lautet der Kapselungstyp für die Eingangs-Schnittstelle ET_PPP.

      4. In dLFIoFR lautet der Kapselungstyp für die Eingangsschnittstelle ET_FRAME_RELAY.

      5. In dLFIoATM lautet der Kapselungstyp für die Eingangs-Schnittstelle ET_ATM.

      6. In dDialer lautet der Kapselungstyp ET_PPP.

   2. Zusätzliche Kapselungsverarbeitung:

      Für ET_PPP wird die NLPID ausgeschnitten.

      • Für dMLP ist die NLPID MULTILINK.

      • Für dLFIoL sind zwei Punkte zu beachten:

        1. VoIP-Pakete - Diese Pakete haben keinen MLP-Header und eine NLPID, die auf IP hinweist.

        2. Datenpakete - Die NLPID ist MULTILINK.

      • Bei dDialer haben die Pakete keinen MLP-Header und eine NLPID, die die IP-Adresse angibt.

        Hinweis: In diesem Fall können Sie dCRTP (verteiltes komprimiertes Echtzeit-Protokoll) konfigurieren. In diesem Fall wird der Header vor der weiteren Verarbeitung dekomprimiert.

3. Wenn für ET_FRAME_RELAY die Verbindung, auf der das Paket empfangen wird, für dMLFR konfiguriert ist, wird das Paket für dMLFR verarbeitet.

4. Für dLFIoFR und dLFIoATM lautet der Kapselungstyp ET_FRAME_RELAY bzw. ET_ATM. aber innerhalb dieser befindet sich ein PPP-Header. Der PPP-Header gibt wie bei dLFIoLL an, ob es sich bei dem Paket um ein Sprachpaket oder ein Datenpaket handelt. Wenn dCRTP konfiguriert ist, wird der Header vor der weiteren Verarbeitung dekomprimiert. Sprachpakete werden sofort geswitcht.

   Ein fragmentiertes Datenpaket muss vor dem Switching reassembliert werden.

   Bei ET_PPP können PPP-Link-Pakete auftreten. und mit ET_FRAME_RELAY treffen Sie möglicherweise auf MLFR-Steuerungspakete. Alle diese Kontrollpakete werden zur Verarbeitung an RP gesendet.

5. Abhängig von der oben genannten Dekodierung wird das Paket auf den Switching-Typ überprüft, den es benötigt. Der Verbindungstyp bestimmt, ob das Paket IP-Switching oder MPLS-Switching verwendet werden soll. Die Pakete werden dann an die jeweiligen Switching-Funktionen übergeben.

6. Durch die Bündelung in Verbindung mit verteilten Funktionen wird der IP-Turbo-Fast-Switching-Vektor gestohlen. Dies geschieht, weil das Paket auf der Memberverbindung empfangen wird. Sie muss jedoch so behandelt werden, dass sie auf dem Paket empfangen wird.

   Sie müssen auch nach Steuerungspaketen suchen, die auf den Host beschränkt sind. Hauptsächlich in dMLFR gibt es LMI-Pakete (Local Management Interface), die keine MLFR-Steuerungspakete sind. Hierfür wird ein anderer Teil des dLCI-Nummernbereichs verwendet. Wenn das dLCI dekodiert wird, um in diesen Bereich zu fallen, wird das Paket bis zum Host gestrafft, da es als LMI-Paket erkannt wird.

   VoIP-Pakete (in der Warteschlange mit niedriger Latenz) werden ohne Hinzufügen des MLP-Headers einfach ausgetauscht. Die verteilten Funktionen können Pakete empfangen und wieder zusammenfügen, wenn fragmentierte Datenpakete empfangen werden. Der Reassemblierungsprozess wird in einem späteren Abschnitt erläutert.

   Wenn das Paket tag-Switched sein muss, wird es an die Tag-Switching-Routine in dMLP übergeben. Andernfalls wird die IP-Switching-Routine an die IP-Switching-Routine übergeben.

   Hinweis: Alle Nicht-IP-Pakete werden in dMLFR an den Host geleitet.

7. IP: Die IP-Switching-Funktion ist für alle Pakete gleich. Dabei geht es vor allem um drei Aspekte:

   • Verarbeiten Sie die Pakete entsprechend, falls Funktionen konfiguriert sind. Wenn ein Distributed Dialer verwendet wird, wird der Inaktivitäts-Timer ebenfalls aktualisiert, wenn ein "interessantes Paket" empfangen wird. Weitere Informationen zum Konfigurationsparameter für den Inaktivitäts-Timer finden Sie unter Leerlaufzeitüberschreitung (Schnittstelle), Schnellwahlnummern (Schnittstelle) und Konfigurieren eines Wählprofils.

   Auf 75xx-Routern gibt die Adjacency den Befehl tx_acc_ptr für die Ausgangsschnittstelle an. Wenn es sich bei der Ausgangsschnittstelle um eine virtuelle Zugriffsschnittstelle handelt, ist tx_acc_ptr NULL. Beheben Sie in diesem Fall die Kapselung, und holen Sie tx_acc_ptr aus dem fib-Widb. Diese Suche und Verkapselung ist in dLFIoFR und dLFIoATM erforderlich. In dLFIoLL wird die Verbindung als Teil eines Multilink-Pakets behandelt.

   Hinweis: TTL für das Paket wird hier angepasst, und die IP-Fragmentierung wird überprüft. Der mci_status ist für alle Pakete auf RXTYPE_DODIP festgelegt.

8. Wenn die Switching-Entscheidung getroffen wurde, kann das Paket von der Schnittstelle ausgeliefert werden. Die Schnittstelle wird überprüft, um festzustellen, ob sie lokales Switching unterstützt. Ist dies der Fall, wird es direkt per FastSende verschickt. Andernfalls wird versucht, einen Routing-Cache-Switch herzustellen.

   Falls QoS für die Schnittstelle konfiguriert ist, wird der lokale Switching-Vektor durch QoS gestohlen. HQF ordnet das Paket in eine Warteschlange ein und verarbeitet das Paket weiter, bevor es schließlich über die Schnittstelle gesendet wird. Dies ist bei dLFI der Fall. Für dLFI werden Fragmentierung und Interleaving festgelegt. QoS verarbeitet den Aufruf unserer Fragmentierungsroutine und überträgt die fragmentierten Pakete mit den Sprachpaketen, die in die Prioritätswarteschlange gestellt werden (wenn LLQ konfiguriert ist). Dadurch wird sichergestellt, dass VoIP-Pakete nicht unter der Verzögerung leiden, die zum Versenden großer Datenpakete über die Verbindung erforderlich ist.

Tx-Datenpfad

Der vip_dtq_consumer ruft das Paket ab und erhält die Schnittstellennummer, von der es die idb abruft. Die Schnellsenderroutine, die dem idb entspricht, wird wie folgt bezeichnet:

i) Schnellsendet

1. In dMFR wird die fr_info-Struktur aus der Tabelle abgerufen, die den if_index mit fr_info vergleicht. Steuerungspakete werden einfach versendet. Der Frame-Header gibt das dLCI an, das Ihnen dabei hilft festzustellen, ob es sich um ein LMI-Paket oder ein Datenpaket handelt. Das dlci-Feld im Frame-Header wird mit der dmfr-Sequenznummer überschrieben. Für LMI- und Datenpakete werden separate Sequenznummern verwendet.

   Hinweis: Für separate dLCIs werden separate Sequenznummern verwendet.

2. In dMLP werden Steuerungspakete gesendet, deren Priorität auf hoch gesetzt ist. Bei Datenpaketen wird der Header komprimiert, wenn dCRTP konfiguriert ist. Der VIP-MLP-Header, der die Sequenzinformationen enthält, wird hinzugefügt und über die Mitgliedslinks gesendet.

3. In dLFI fängt HQF die Pakete ab, die über die Schnittstelle gesendet werden sollen. Wenn es sich um ein Sprachpaket handelt, wird das Sprachpaket in die Prioritätswarteschlange gestellt (wenn LLQ konfiguriert ist) und ohne MLP-Kapselung über die Schnittstelle gesendet. Bei Datenpaketen wird der dLFI-Fragmentierungscode aufgerufen, der Fragmente an den QoS-Code zurückgibt, die dann mit dem Prioritätsverkehr verbunden werden, sodass die Verzögerungsanforderungen des Sprachdatenverkehrs erfüllt werden. Wenn dCRTP konfiguriert ist, wird auch nur der Header für das Sprachpaket komprimiert. Datenpaket-Header bleiben unverändert.

4. In dDialer wird das Paket klassifiziert, um den Inaktivitäts-Timer der Ausgangsverbindung zurückzusetzen, bevor das Paket versendet wird. Dies erfolgt nach Auswahl der Ausgabeverbindung, falls mehrere Links an den gleichen Wähler gebunden sind. Dialer-Pakete werden keine Header hinzugefügt. Die Sequenzierung und das Reassemblieren von Paketen wird daher auf Dialer-Schnittstellen nicht unterstützt.

Hinweis: Bei dMLP, dDialer, dMLFR und dLFI mit mehreren Verbindungen hängt die physische Verbindung, über die der Datenverkehr weitergeleitet wird, von der Überlastung der Verbindung ab. Wenn die Verbindung überlastet ist, fahren Sie mit dem nächsten Link fort usw. (dMLFR, dMLP ohne QoS und dDialer-Funktionen wählen auch Links basierend auf der Anzahl der Byte, die auf der Verbindung gesetzt werden. Sie wählt die nächste Verbindung, wenn die aktuelle Verbindung bereits ihre Bytequote auf Round-Robin-Basis übertragen hat. Dieses Kontingent wird durch die Funktion "frag_bytes" für die Verbindung festgelegt. Für Dialer-Mitgliedsschnittstellen ist frag_bytes auf den Standardwert der Schnittstellenbandbreite festgelegt.)

Hinweis: In HQF-Konfigurationen an den Schnittstellen des Ausgangs-VIP stiehlt HQF den dtq_consumer-Vektor. Die Paket-DMAd zum Ausgangs-VIP durchläuft zunächst die HQF-Prüfung. Wenn QoS auf der Ausgangsschnittstelle konfiguriert ist, greift HQF ein, um das Paket zu verarbeiten, bevor das Paket schnell aus der Schnittstelle heraus gesendet wird.

Reassemblierung

Plain dDialer-Schnittstellen unterstützen keine Reassemblierung und Sequenzierung. Um dies auf Dialer-Schnittstellen zu aktivieren, muss MLP over Dialer-Schnittstellen konfiguriert werden. Ist dies der Fall, sind der Rx- und der Tx-Pfad mit den dMLP-Pfaden identisch. Wenn Pakete empfangen werden, wird die Sequenznummer mit der erwarteten Sequenznummer abgeglichen.

• Wenn die Sequenznummern übereinstimmen:

  1. Wenn es sich bei dem Paket um ein nicht fragmentiertes Paket handelt, ist keine Reassemblierung erforderlich. Fahren Sie mit weiteren Switching-Schritten fort.

  2. Wenn es sich bei dem Paket um ein Fragment handelt, überprüfen Sie die Start- und Endbits, und erstellen Sie das Paket, sobald die Fragmente empfangen werden.

• Wenn die Sequenznummern nicht übereinstimmen:

  1. Befindet sich die Sequenznummer im erwarteten Fenster mit Sequenznummern, fügen Sie sie in die sortierte Liste "nicht zugewiesene Fragmente" ein. Wenn später keine erwartete Sequenznummer empfangen wird, wird diese Liste überprüft, falls das Paket hier gespeichert wurde.

  2. Wenn sich die Sequenznummer nicht im Fenster befindet, verwerfen Sie sie und melden Sie "empfangenes verlorenes Fragment". Tritt später während des Wartens auf dieses Paket eine Zeitüberschreitung auf, wird der Empfänger erneut synchronisiert und beginnt erneut mit dem nächsten empfangenen Paket.

In allen diesen Fällen wird über diese Schnittstelle ein korrekt sortierter Paket-Stream gesendet. Wenn Fragmente empfangen werden, wird ein vollständiges Paket gebildet und dann gesendet.

Konfigurieren, Überprüfen und Debuggen von verteilten Features

In diesem Abschnitt werden die Befehle zum Anzeigen und Debuggen behandelt, die zum Überprüfen und Debuggen der verteilten Features verfügbar sind.

Konfigurieren und Überprüfen von dMFR

MFR-Beispielkonfiguration

interface MFR1
 no ip address

interface MFR1.1 point-to-point
 ip address 181.0.0.2 255.255.0.0
 frame-relay interface-dlci 16

Hinweis: Die MFR-Schnittstelle ist wie eine andere FR-Schnittstelle und unterstützt daher den Großteil der FR-Konfiguration.

interface Serial5/0/0/1:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/2:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/3:0
 no ip address
 encapsulation frame-relay MFR1

Überprüfen Sie den MFR-Paketstatus auf dem RP.

show frame-relay multilink

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
 Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
 Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0

Dies weist darauf hin, dass zwei Schnittstellen korrekt hinzugefügt wurden und dass eine Schnittstelle die MLFR-LIP-Meldungen noch nicht ausgehandelt hat.

Um weitere Informationen zum MFR-Paket und zu den Links für Programmteilnehmer zu erhalten, führen Sie den folgenden Befehl aus:

show frame-relay multilink mfr1 detailed

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
No. of bundle links = 3, Peer's bundle-id = MFR1
Rx buffer size = 36144, Lost frag timeout = 1000
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = , RTT = 0 ms
   Statistics:
   Add_link sent = 35, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 0, Hello rcv'd = 0,
   Hello_ack sent = 0, Hello_ack rcv'd = 0,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/2:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/1:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0

MFR-Debug-Befehle

Diese Debug-Tools sind nützlich, um Probleme zu beheben, bei denen dem Paket kein Link hinzugefügt wird.

debug frame-relay multilink control

Hinweis: Wenn keine bestimmte MFR-Schnittstelle oder serielle Schnittstelle angegeben ist, können alle MFR-Links debuggt werden. Wenn der Router über eine große Anzahl von MFR-Links verfügt, kann dies eine große Belastung sein.

Zum Debuggen von MFR-Paketen, die am RP empfangen werden, sowie zum Debuggen der MFR-Steuerungsaktivitäten ist dieses Debuggen hilfreich:

debug frame-relay multilink

Hinweis: Bei starkem Datenverkehr kann dies die CPU überlasten.

Überprüfen Sie den dMLFR-Paketstatus auf dem LC.

show frame-Relay-Multilink

Hinweis: Derzeit ist dies auf dem LC nicht verfügbar, wird aber bald hinzugefügt. Bis dahin können Sie show ppp multilink verwenden.

Bundle MFR1, 2 members
  bundle 0x62DBDD20, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6019271C
  idb MFR1, vc 0, RSP vc 0
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x200
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial0/0:1, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x58E sent sequence
 DLCI: 16
  769719 lost fragments, 22338227 reordered, 
                                0 unassigned
  27664 discarded, 27664 lost received
  0xF58 received sequence, 0x8DE sent sequence
 timer count 767176
  Member Link: 2 active
   Serial0/0:0, id 0x1, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0
   Serial0/0:1, id 0x2, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0

Konfigurieren und Überprüfen von dMLP/dLFIoLL

Multilink PPP-Konfiguration

interface Multilink1
 ip address 151.0.0.2 255.255.0.0
 no cdp enable
 ppp chap hostname M1
 ppp multilink
!

Beispielkonfiguration unter der seriellen Schnittstelle:

interface Serial5/0/0/4:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!
interface Serial5/0/0/5:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!

Hinweis: Der Befehl ppp chap hostname M1 bedeutet nicht, dass die CHAP-Authentifizierung aktiviert ist. Die Zeichenfolge M1 in diesem Befehl dient als Differenzierungsmerkmal für Endpunkte und ist nur erforderlich, wenn zwischen den beiden Routern mehrere Bündel für Mehrfachverbindungen vorhanden sind. In einem solchen Fall sollten alle Links, die zu einem Paket gehören, denselben Endpunkt-Diskriminator haben, und keine zwei Links, die zu einem anderen Bündel gehören, sollten denselben Endpunkt-Diskriminator aufweisen.

Optionale Konfigurationsparameter

[no] ppp Multilink Interleave

Dadurch wird das Verschachteln auf das Multilink-Paket ermöglicht. Dies funktioniert in Verbindung mit der modularen QoS-CLI. Pakete mit hoher Priorität werden ohne Hinzufügen der MLP-Sequenz und des Headers übertragen, während andere Pakete fragmentiert und mit der MLP-Sequenz und dem Header übertragen werden.

Hinweis: Wenn die Verschachtelung mit mehr als einer Verbindung aktiviert ist, kann es sein, dass der Datenverkehr mit hoher Priorität erneut bestellt wird. Wenn Interleaving aktiviert oder deaktiviert ist, muss das Paket zurückgesetzt werden, damit es in der Linecard aktiviert werden kann.

ppp multilink mrru local value

Gibt die maximale Empfangseinheit auf der Multilink-Verbindung an. Pakete bis zu dieser Größe werden von der Multilink-Schnittstelle akzeptiert. Die Größe hier schließt den MLP-Header aus.

ppp multilink mrru remote value

Dadurch wird die MRRU festgelegt, die vom Remote-Ende unterstützt werden soll. Wenn die Remote-End-MRRU kleiner als dieser Wert ist, schlägt die Paketverhandlung fehl.

ppp multilink fragment delay seconds

Gibt die zulässige Verzögerung in Millisekunden (ms) an, die durch ein Datenfragment verursacht wird. Mit anderen Worten, der Wert der Verzögerung wird zur Berechnung der maximal zulässigen Fragmentgröße verwendet. Die verteilte Implementierung unterscheidet sich in folgenden Punkten von der Cisco IOS-Implementierung:

1. Die Fragmentierung wird nur ausgeführt, wenn die Verknüpfung aktiviert ist.

2. Bei Verbindungen unterschiedlicher Bandbreite basiert die gewählte Fragmentgröße auf der Schnittstelle mit der geringsten Bandbreite.

ppp multilink fragment disable

Dieser Befehl fügt der verteilten Implementierung keine Funktionen hinzu. Fragmentierung tritt nur auf, wenn Interleaving aktiviert ist; und bei aktiviertem Verschachteln wird der Befehl ppp multilink fragment disable ignoriert.

Überprüfen Sie den dMLP-Paketstatus auf dem RP.

show ppp multilink

Multilink1, bundle name is M1
Endpoint discriminator is M1
Bundle up for 00:09:09, 1/255 load
Receive buffer limit 24000 bytes, frag timeout 1000 ms
Bundle is Distributed
  0/0 fragments/bytes in reassembly list
  0 lost fragments, 0 reordered
  0/0 discarded fragments/bytes, 0 lost received
  0x9 received sequence, 0x0 sent sequence
dLFI statistics:
          DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
            Fragmented          0          0          0          0
          UnFragmented          9       3150          0          0
           Reassembled          9       3150          0          0
      Reassembly Drops          0
   Fragmentation Drops          0
      Out of Seq Frags          0
Member links: 2 active, 0 inactive (max not set, min not set)
  Se5/0/0/4:0, since 00:09:09, 768 weight, 760 frag size
  Se5/0/0/5:0, since 00:09:09, 768 weight, 760 frag size

1. Wenn sich das Paket im verteilten Modus befindet, wird dies in der Ausgabe von show ppp multilink angezeigt:

   Paket ist verteilt

   Ist dies nicht der Fall, wird das Paket aus irgendeinem Grund nicht verteilt.

2. Wenn ppp-Multilink-Interleave auf der Linecard konfiguriert und aktiviert ist, enthält die Ausgabe show ppp multilink die dLFI-Statistiken, bei denen:

   • Fragmentiert - gibt die Anzahl der gesendeten und empfangenen Fragmente an.

   • Unfragmentiert - Zeigt die Anzahl der Pakete an, die ohne Fragmentierung übertragen oder empfangen wurden.

   • Reassembliert - Zeigt die Anzahl der vollständigen Pakete an, die reassembliert wurden. Wenn Interleaving nicht aktiviert ist, sieht die Ausgabe wie folgt aus:

     Multilink1, bundle name is M1
       Endpoint discriminator is M1
       Bundle up for 00:00:00, 0/255 load
       Receive buffer limit 24000 bytes, frag timeout 1000 ms
       Bundle is Distributed
         0/0 fragments/bytes in reassembly list
         0 lost fragments, 0 reordered
         0/0 discarded fragments/bytes, 0 lost received
         0x0 received sequence, 0x2 sent sequence
       Member links: 2 active, 0 inactive (max not set, min not set)
         Se5/0/0/5:0, since 00:00:00, 768 weight, 760 frag size
         Se5/0/0/4:0, since 00:00:03, 768 weight, 760 frag size
     

Die Fragmentgröße im vorherigen Beispiel beträgt 760 Byte.

Überprüfen Sie den dMLP-Paketstatus auf dem LC.

show ppp multilink

dmlp_ipc_config_count 24
dmlp_bundle_count 2
dmlp_ipc_fault_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x615960E0, bundle 0x622AA060, 0x60579290, 0x6057A29C
1, store 0, hwidb 0x615985C0, bundle 0x622AA060, 0x60579290, 0x6057A29C
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Multilink1, 2 members
  bundle 0x622AA060, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6057B198
  idb Multilink1, vc 4, RSP vc 4
  QoS disabled, fastsend (qos_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 1, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 1
  next_xmit_link Serial0/0:3, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0xC3 received sequence, 0x0 sent sequence
  Member Link: 2 active
   Serial0/0:4, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0
   Serial0/0:3, id 0x2, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

Bei dMFR werden die Sequenznummern pro dLCI beibehalten, wobei die Sequenznummer im Paket für LMI dLCI verwendet wird.

Feld	Beschreibung
dmlp_ipc_config_count	Anzahl der vom LC empfangenen IPC-Nachrichten für Multi-Link- oder MLFR-Konfiguration
dmlp_paket_count	Anzahl der MLP- und MLFR-Pakete im LC
dmlp_ipc_fehleranzahl	Anzahl der Konfigurationsmeldungen, die zum Ausfall des LC geführt haben Muss 0 sein; Wenn es sich um eine Nicht-Null-Kategorie handelt, könnte ein Problem vorliegen.
Tagvektor	Gibt den idb to tag_optimalfs und den idb to ip2tag_optimalfs vectors an, die beim Tag-Switching verwendet werden.
Platine	Gibt den board_encap-Vektor an, der zum Hinzufügen von 2 Byte Board-Kapselung verwendet wird, wenn in einer 7500-Plattform kanalisierte Verbindungen vorhanden sind. Sollte NULL sein, wenn die Verbindung nicht kanalisierte Schnittstellen enthält.
max_teilchen	Maximale Anzahl von Partikeln, die im Reassemblierungspuffer gehalten werden können
Mrru	Die maximale Paketgröße, die akzeptiert wird, ohne die MLP-Kapselung zu berücksichtigen. Nicht verfügbar für MLFR-Schnittstelle.
seq_window_size	Die maximale Fenstergröße für Sequenznummern
working_pak	Gibt das aktuelle Paket an, das sich unter Reassemblierung befindet. NULL, wenn keine.
working_pak_cache	Zeigen Sie auf das statische Paket, das für die Reassemblierung verwendet wird. Diese wird zugewiesen, wenn das erste nicht vollständige Paket vom Paket empfangen wird.
una_frag_list	Erster Eintrag in der Reassemblierungswarteschlange. Wenn der Eintrag nicht NULL ist und sich nicht ändert, zeigt er an, dass auf dem Timer kein Softwareproblem ausgeführt wird.
una_frag_end	Letzter Eintrag in der Reassemblierungswarteschlange
rcved_end_bit	Gibt an, dass das Paket ein End-Bit erhalten hat, sodass es nach einem Start-Bit sucht.
is_lost_frag	Ist true, wenn ein Fragment als verloren deklariert wird. Dies wird gelöscht, wenn ein Fragment mit der erwarteten Sequenz empfangen wird.
Resync_Anzahl	Gibt an, wie oft der Empfänger nicht mit dem Sender synchronisiert war und erneut synchronisiert werden musste, indem er mit dem letzten empfangenen sequenzierten Fragment begann.
Zeitüberschreitung	Gibt an, dass der Reassemblierungs-Timeout aufgetreten ist und Pakete aus der Reassemblierungswarteschlange verarbeitet werden.
Timer-Start	Anzahl der gestarteten Reassemblierungs-Timer
Timer wird ausgeführt	Gibt an, ob der Reassemblierungs-Timer ausgeführt wird oder nicht.
Timer-Zähler	Gibt an, wie oft der Wiedereinrichtungs-Timer abgelaufen ist.
next_xmit_link	Der Link, über den das nächste Paket übertragen wird
Mitglied	Bit-Feld, das die vorhandenen Member angibt.
Überlastung	Feld wird nicht in allen Zweigstellen verwendet. Gibt an, welche Member-Links nicht überlastet sind.
dmlp_orig_pak_to_host	Der Vektor, der verwendet wurde, um Pakete an den RP zu senden.
dmlp_orig_fastsend	Der ursprüngliche Treiber sendet schnell, bevor MLP oder MLFR die Schnellübertragung des Treibers modifiziert hat.
verlorene Fragmente	Anzahl der verlorenen Fragmente (der Empfänger hat diese Fragmente nicht erhalten). Dies wird regelmäßig gelöscht, wenn ein Update an den Host gesendet wird.
neu geordnet	Anzahl der Fragmente, die aus der erwarteten Reihenfolge empfangen wurden Dies wird regelmäßig gelöscht, wenn ein Update an den Host gesendet wird.
Verworfen	Anzahl der verworfenen Fragmente, da kein vollständiges Paket erstellt werden konnte
verloren gegangen	Anzahl der empfangenen Fragmente, die als verloren angesehen wurden. Dies weist darauf hin, dass die Verzögerung der Inter-Link-Reassemblierung größer ist als das Timeout der dMLP-Reassemblierung von 30 ms.

Konfigurieren und Überprüfen von dLFIoFR und dLFIoATM

class-map voip
 match ip precedence 3

policy-map llq
 class voip
  priority

int virtual-template1
 service-policy output llq
 bandwidth 78 
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment-delay 8


int serial5/0/0/6:0
encapsulation frame-relay
frame-relay interface-dlci 16 ppp virtual-template1

!--- Or 

int ATM4/0/0
  no ip address
int ATM4/0/0.1 point-to-point
  pvc 5/100
  protocol ppp virtual-template 1

Überprüfen Sie den dLFIoFR/ATM-Paketstatus auf dem RP.

show ppp multilink

Virtual-Access3, bundle name is dLFI
  Endpoint discriminator is dLFI
  Bundle up for 00:01:11, 1/255 load
  Receive buffer limit 12192 bytes, frag timeout 1524 ms
  Bundle is Distributed
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x0 received sequence, 0x0 sent sequence
  dLFI statistics:
            DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
              Fragmented          0          0          0          0
            UnFragmented          0          0          0          0
             Reassembled          0          0          0          0
        Reassembly Drops          0
     Fragmentation Drops          0
        Out of Seq Frags          0
  Member links: 1 (max not set, min not set)
    Vi2, since 00:01:11, 240 weight, 230 frag size

Hinweis: Das Paket wird nur verteilt, wenn ppp-Multilink-Interleave unter der virtuellen Vorlage konfiguriert ist. Ohne diesen Befehl wird das Paket nicht verteilt.

Überprüfen Sie den dLFIoFR/ATM-Paketstatus auf dem LC.

Führen Sie folgenden Befehl aus, um zu überprüfen, ob das dLFI am LC ordnungsgemäß funktioniert:

show hqf interface

Interface Number 6 (type 22) Serial0/0:5

   blt (0x62D622E8, index 0, hwidb->fast_if_number=35) layer PHYSICAL
   scheduling policy: FIFO
   classification policy: NONE
   drop policy: TAIL
   blt flags: 0x0

   qsize 0 txcount 3 drops 0 qdrops 0 nobuffers 0
   aggregate limit 16 individual limit 4 availbuffers 16
   weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
   visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
   quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     next layer HQFLAYER_FRAMEDLCI_IFC (max entries 1024)

     blt (0x62D620E8, index 0, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: FIFO
     classification policy: NONE
     drop policy: TAIL
     blt flags: 0x0
  
     qsize 0 txcount 1 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     blt (0x62D621E8, index 16, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: WFQ
     classification policy: PRIORITY_BASED
     drop policy: TAIL
     frag policy: root
     blt flags: 0x0
  
     qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       next layer HQFLAYER_PRIORITY (max entries 256)

       blt (0x62D61FE8, index 0, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       frag policy: leaf
       blt flags: 0x0
    
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 0 perc 0.99 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       blt (0x62D61CE8, index 1, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       blt flags: 0x0
       Priority Conditioning enabled
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 0 individual limit 0 availbuffers 0
       weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 0 allocated_bw 0 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       PRIORITY: bandwidth 32 (50%)
                 last 0 tokens 1500 token_limit 1500

       blt (0x62D61EE8, index 255, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: WFQ
       classification policy: CLASS_BASED
       drop policy: TAIL
       frag policy: MLPPP (1)
         frag size: 240, vc encap: 0, handle: 0x612E1320
       blt flags: 0x0
    
       qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 1 perc 0.01 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 1 credit 0 backpressure_policy 0 nothingoncalQ 1

           next layer HQFLAYER_CLASS_HIER0 (max entries 256)

           blt (0x62D61DE8, index 0, hwidb->fast_if_number=35) layer CLASS_HIER0
           scheduling policy: FIFO
           classification policy: NONE
           drop policy: TAIL
           frag policy: leaf
           blt flags: 0x0
        
           qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
           aggregate limit 8 individual limit 2 availbuffers 8
           weight 1 perc 50.00 ready 1 shape_ready 1 wfq_clitype 0
           visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
           quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

Es sollte eine Prioritätsschicht und eine WFQ-Schicht geben. Die Fragmentierung erfolgt auf der Leaf-Layer-Blt des WFQ.

Konfigurieren und Überprüfen von dDDR

Verteilter DDR wird aktiviert, wenn Sie IP cef aktivieren, der in der globalen Konfiguration verteilt wird, und ip route-cache, der auf den Dialer-Schnittstellen verteilt ist.

!--- Global configuration that enables distributed CEF switching.

ip cef distributed

--- Enable distributed switching on the dialer interface (on the D-channel interface).

int serial 3/1/0:23
	ip route-cache distributed

!--- Or, enable it on the dialer interface.

int Dialer1
	ip route-cache distributed

Es gibt keine anderen speziellen Konfigurationen für verteilten DDR. Die weitere Konfiguration erfolgt nach der normalen DDR-Konfiguration.

Verteilt Dial-on-Demand-Routing verifizieren

BOX2002# show isdn status

Global ISDN Switchtype = primary-net5
ISDN Serial3/1/0:23 interface

--- Network side configuration.

        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED


The ISDN status should be MULTIPLE_FRAME_ESTABLISHED. This means that the physical layer is ready for ISDN connectivity.


    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Number of L2 Discards = 0, L2 Session ID = 6

EDGE# show dialer

Serial6/0:0 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Time until disconnect 119 secs
Current call connected never
Connected to 54321

Serial6/0:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is idle

Der Dialer-Typ teilt uns mit, welcher Dialer verwendet wird. ISDN impliziert Legacy Dialer-Konfiguration und PROFILE impliziert die Konfiguration des Wählprofils. Der Dialer-Status gibt den aktuellen Status des Dialers an. Der Status einer nicht verbundenen Dialer-Schnittstelle ist inaktiv. Der Leerlauf-Timer wird immer dann zurückgesetzt, wenn interessanter Datenverkehr angezeigt wird. Wenn dieser Timer jemals abläuft, wird die Verbindung zur Schnittstelle sofort getrennt. Der Leerlauf-Timer ist ein konfigurierbarer Parameter. Weitere Informationen finden Sie unter Konfigurieren von Peer-to-Peer-DDR mit Dialer-Profilen.

show ppp multilink

!--- From LC for dialer profile.

dmlp_ipc_config_count 2
dmlp_bundle_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x0, bundle 0x0,
1, store 0, hwidb 0x0, bundle 0x0,
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Dialer1, 1 member
  bundle 0x62677220, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x0
  idb Dialer1, vc 22, RSP vc 22
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 56
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 200, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial1/0:22, member 0x1, congestion 0x1
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x60381298
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x0 sent sequence
  Member Link: 1 active
   Serial1/0:22, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

Die angezeigten Variablen sind dieselben wie die für dMLP.

Debuggen von dMLP und dDDR

Debugger verfügbar auf dem RP

dDDR

debug dialer [events | packets | forwarding | map]

Geben Sie diesen Befehl ein, um Funktionen für Steuerungspfad wie die Anrufeinrichtung usw. zu debuggen. Weitere Informationen finden Sie unter Debug Dialer-Ereignisse.

debug ip cef dialer

Geben Sie diesen Befehl ein, um CEF-bezogene Dialer-Ereignisse zu debuggen. Weitere Informationen finden Sie unter Dialer CEF.

Debugger im LC verfügbar

dMLP

Debuggen von Steuerpfad: Debug-Multilink-Ereignis

Datenpfad-Debuggen: Debuggen von Multilink-Fragmenten

Fehlerdebugging für Datenpfad und Steuerungspfad: Multilink-Fehler debuggen

Debuggen von dMLP auf SIP-Linecards

Dumping von Paketen basierend auf dem Wirtschaftszweig der Gemeinschaft: Datenpakete und Steuerungspakete können auf Linecards basierend auf der Steuerungs-CI und der Sequenz ci abgelegt werden.

Test hw-module subslot_num dump ci CI-NUM [rx|tx] num_packages_to_dump

Die CIs können wie folgt bezogen werden:

!--- Issue show controller serial interface  for CTE1.

SIP-200-6# show controller serial 6/0/0:0

SPA 6/0 base address 0xB8000000 efc 1

Interface Serial6/0/0:0 is administratively down
Type 0xD Map 0x7FFFFFFF, Subrate 0xFF, mapped 0x1, maxmtu 0x5DC
Mtu 1500, max_buffer_size 1524, max_pak_size 1608 enc 84
ROM rev: 0, FW OS rev: 0x00000000 Firmware rev: 0x00000000
  idb=0x42663A30, pa=0x427BF6E0, vip_fci_type=0, port_per_spa=0
  SPA port type is set
  Host SPI4 in sync 
  SPA=0x427BF6E0 status=00010407, host=00000101, fpga=0x427EDF98
  cmd_head=113, cmd_tail=113, ev_head=184, ev_tail=184
  ev_dropped=0, cmd_dropped=0

!--- Start Link Record Information.

 tag 0, id 0, anyphy 0, anyphy_flags 3, state 0
 crc 0, idle 0, subrate 0, invert 0, priority 0
 encap hdlc
 corrupt_ci 65535, transparent_ci 1

!--- End Link Record Information.

Interface Serial6/0/0:0 is administratively down
Channel Stats:
  in_throttle=0, throttled=0, unthrottled=0, started=1
  rx_packets=0, rx_bytes=0, rx_frame_aborts=0,  rx_crc_errors=0
  rx_giants=0, rx_non_aligned_frames=0, rx_runts=0,  rx_overruns=0
  tx_packets=0, tx_bytes=0, tx_frame_aborts=0
  is_congested=0, mapped=1, is_isdn_d=0, tx_limited=1
  fast_if_number=15, fastsend=0x403339E4
  map=0x7FFFFFFF, turbo_vector_name=Copperhead to Draco switching
  lc_ip_turbo_fs=403A9EEC, lc_ip_mdfs=403A9EEC

Für CT3 müssen Sie die vc num abrufen, die aus der Ausgabe von show interface serial CT3_interface_name abgerufen werden kann.

Die CI-Informationen können jetzt über die SPA-Konsole abgerufen werden. Führen Sie die Ausgabe der SPA-Konsolenbefehle zuerst mit dem Befehl spa_redirect rp ct3_Freedm336 an den RP um.

Der Befehl spa_ct3_test Freedm show linkrec vc zeigt die erforderlichen CI-Informationen an.

dMFR

Debuggen von Steuerpfad: debug dmfr-Ereignis

Datenpfad-Debuggen: dmfr-Pakete debug

Fehlerdebugging für Datenpfad und Steuerungspfad: debug dmffehler

Dumping von Paketen basierend auf dem Wirtschaftszweig der Gemeinschaft: Siehe dMLP.

dLFI

Debuggen von Steuerpfad: debug dlfi-Ereignis

Datenpfad-Debuggen: debug dlfi-Fragmente

Fehlerdebugging für Datenpfad und Steuerungspfad: debug dlfi-Fehler

dDDR

Es gibt keine speziellen Debugbefehle. Sie sollten dMLP-Debug verwenden.

Im Fall von dLFIoLL müssen möglicherweise sowohl dMLP- als auch dLFI-Debugger verwendet werden. Diese Debuggen sind nicht bedingt und werden daher für alle Pakete ausgelöst.

Häufig gestellte Fragen

1. Was ist dMLP?

   dMLP ist die Kurzbezeichnung für Distributed Multilink PPP (wie in RFC 1990 angegeben). Diese Funktion wird von verteilten Plattformen wie der Cisco Serie 7500 und 7600 unterstützt. Mit dMLP können Sie T1/E1-Leitungen - in einem VIP auf einem Router der Cisco 7500-Serie oder einem FlexWAN auf einem Router der 7600-Serie - in einem Paket kombinieren, das die kombinierte Bandbreite mehrerer T1/E1-Leitungen bietet. So können Kunden die Bandbreite über T1/E1 hinaus erhöhen, ohne eine T3/E3-Leitung erwerben zu müssen.

2. Was wird in dMLP "verteilt"?

   Der Begriff "verteilt" impliziert, dass das Paket-Switching vom VIP und nicht vom RSP erfolgt. Warum? Die RSP-Switching-Funktionen sind eher begrenzt und haben viele weitere wichtige Aufgaben zu erledigen. Das VIP, das Pakete verteilen kann, entlastet diese Aktivität vom RSP. Die Links werden weiterhin über das RSP-basierte Cisco IOS verwaltet. Die Erstellung und Entfernung von Paketen erfolgt durch den RSP. Darüber hinaus wird die PPP-Kontrollebene weiterhin vom RSP verarbeitet, einschließlich der Verarbeitung aller PPP-Kontrollpakete (LCP, Authentifizierung und NCP). Sobald jedoch ein Paket erstellt wurde, wird die Verarbeitung von MLP-Paketen für das Switching durch die integrierte CPU an das VIP übergeben. Das dMLP-Modul (auf dem VIP) übernimmt alle MLP-Prozeduren, einschließlich Fragmentierung, Verschachtelung, Kapselung, Lastenausgleich zwischen mehreren Links sowie Sortierung und Reassemblierung eingehender Fragmente. Die vom VIP in einem 7500-System ausgeführten Funktionen werden vom FlexWAN/Enhanced-FlexWAN in einem 7600-basierten System ausgeführt.

3. Woher weiß ich, ob das Paket verteilt ist oder nicht?

   Führen Sie den Befehl show ppp multilink in der Router-Konsole aus:

   Router# show ppp multilink
   
   Multilink1, bundle name is udho2
     Bundle up for 00:22:46
     Bundle is Distributed
     174466 lost fragments, 95613607 reordered, 129 unassigned
     37803885 discarded, 37803879 lost received, 208/255 load
     0x4D987C received sequence, 0x9A7504 sent sequence
     Member links: 28 active, 0 inactive (max not set, min not set)
       Se11/1/0/27:0, since 00:22:46, no frags rcvd
       Se11/1/0/25:0, since 00:22:46, no frags rcvd
   
    !--- Output suppressed.
   
   

4. Ist meine dMLP-Leistung bei einem Upgrade auf RSP16 oder SUP720 besser?

   Nein. Die Switching-Leistung von dMLP (oder einer verteilten Funktion) ist vom jeweiligen VIP oder FlexWAN abhängig. Beispielsweise ist die Leistung eines VIP6-80 besser als die des VIP2-50.

5. Welche PAs kann ich mit dieser Funktion verwenden?

   • PA-MC-T3

   • PA-MC-2T3+

   • PA-MC-E3

   • PA-MC-2E1

   • PA-MC-2T1

   • PA-MC-4T1

   • PA-MC-8T1

   • PA-MC-8E1

   • PA-MC-STM-1

   • PA-MC-8TE1+

   • PA-4T+

   • PA-8T

   • CT3IP-50 (nur 7500)

6. Wie viele Verbindungen können in einem einzigen Paket konfiguriert werden?

   Diese Antwort hat viele Facetten. Der primäre Engpass ist die CPU-Leistung der Linecard (VIP/FlexWAN/Enhanced-FlexWAN2). Die feste Grenze beträgt 56 Verbindungen pro Bündel, aber oft können Sie diese vielen (und haben so viel Datenverkehr-Switching) nicht konfigurieren, entweder aufgrund der CPU-Leistung oder begrenzter Puffer. Diese Zahlen basieren auf dieser Leitlinie (basierend auf der CPU und dem Speicher auf dem VIP/FlexWAN/Enahced-FlexWAN2):

   VIP2-50 (mit 4 MB SRAM) max. T1 s = 12

   VIP2-50 (mit 8 MB SRAM) max. T1s = 16

   VIP4-80 max. T1 = 40

   VIP6-80 max. T1 = 40

   FlexWAN max. T1 = wird in Kürze aktualisiert

   Enhanced-FlexWAN max. E1 s = 21 E1 pro Schacht (aggregiert 42 E1 pro Linecard)

7. Wird die Leistung geändert, wenn ich drei Pakete mit jeweils 3 T1 oder ein Paket mit 9 T1 konfiguriere?

   Die Leistung ändert sich nicht, wie in Labortests gezeigt wurde. Da jedoch eine große Anzahl von T1 in einem einzigen Paket enthalten ist (z. B. 24 oder 28 T1 in einem einzigen Paket), gibt es Probleme mit dem Ausschöpfen von Puffern. Es wird dringend empfohlen, in einem Paket nicht mehr als 8 Teilnehmer-Verbindungen (T1/E1) zu verwenden.

8. Wie wird die Bandbreite eines Pakets bestimmt?

   Die Bandbreite eines Pakets ist nicht zu konfigurieren. Dabei handelt es sich um die aggregierte Bandbreite aller Mitgliedsverbindungen. Wenn das Paket vier T1 umfasst, beträgt die Bandbreite des Pakets 6,144 Mbit/s.

9. Was ist besser? CEF-Lastenausgleich oder dMLP?

   Darauf gibt es keine einfache Antwort. Ihre Bedürfnisse entscheiden, welche besser ist.

   PRO MLP:

   • CEF-Lastenausgleich ist nur für IP-Datenverkehr anwendbar. MLP gleicht den gesamten über ein Paket gesendeten Datenverkehr aus.

   • MLP behält die Reihenfolge der Pakete bei. IP selbst ist für eine Neuordnung tolerant, sodass dies für Sie nicht relevant sein kann. Die zusätzlichen Kosten für die Aufrechterhaltung der Sequenzierung können ein Grund sein, MLP zu vermeiden. IP ist für Netzwerke bestimmt, die Datagramme außer Betrieb setzen können, und alles, was IP verwendet, soll in der Lage sein, eine Neuordnung vorzunehmen. Doch trotz dieser Tatsache ist die Realität, dass Neuordnung immer noch ein echtes Problem darstellen kann.

   • MLP stellt eine einzige logische Verbindung zum Peer-System bereit.

   • QoS wird auf Multilink-Paketen unterstützt.

   • MLP stellt dynamische Bandbreitenfunktionen bereit, da der Benutzer auf Basis der aktuellen Anforderungen Mitgliedsverbindungen hinzufügen oder entfernen kann.

   • MLP kann eine größere Anzahl von Verbindungen bündeln, während der CEF-Lastenausgleich auf 6 parallele IP-Pfade beschränkt ist.

   • Der Pro-Flow-CEF-Lastenausgleich begrenzt die maximale Bandbreite eines beliebigen Datenflusses auf ein T1. Kunden, die Sprach-Gateways verwenden, können beispielsweise viele Anrufe mit derselben Quelle und demselben Ziel führen und daher nur einen Pfad verwenden.

   CONS von MLP:

   • MLP fügt jedem Paket oder Frame zusätzlichen Overhead hinzu.

   • MLP ist CPU-intensiv. dMLP ist CPU-intensiv für Linecards.

10. Wie kann ich mehrere Pakete zwischen zwei Routern konfigurieren?

    Multilink bestimmt anhand des Peernamen und des Endpunkt-Diskriminators, zu welchem Paket eine Verbindung hinzugefügt wird. Um mehrere getrennte Pakete zwischen zwei Systemen zu erstellen, müssen einige Links standardmäßig dazu gezwungen werden, sich anders zu identifizieren. Empfohlene Methode ist die Verwendung des Befehls ppp chap hostname name.

11. Kann ich Mitgliederlinks von verschiedenen PAs haben?

    Nein. Wenn Sie dMLP ausführen möchten, wird es nicht unterstützt. Wenn jedoch Mitgliedlinks von verschiedenen PAs hinzugefügt werden, wird das Steuerelement dem RSP und seinem nicht mehr dMLP übergeben. MLP funktioniert noch, aber die Vorteile von dMLP sind hinfällig.

12. Kann ich die Links der Mitglieder beider Seiten kombinieren?

    Nein. Wenn Sie dMLP ausführen möchten, wird es nicht unterstützt. Wenn jedoch Mitgliedlinks von verschiedenen PAs hinzugefügt werden, wird das Steuerelement an den RSP übergeben, und es ist nicht mehr dMLP. MLP funktioniert noch, aber die Vorteile von dMLP sind hinfällig.

13. Kann ich Mitgliedverbindungen über verschiedene VIPs oder FlexWANs haben?

    Nein. Wenn Sie dMLP ausführen möchten, wird es nicht unterstützt. Wenn jedoch Mitgliedlinks von verschiedenen PAs hinzugefügt werden, wird das Steuerelement dem RSP und seinem nicht mehr dMLP übergeben. MLP funktioniert noch, aber die Vorteile von dMLP sind hinfällig.

14. Kann ich Mitgliedverbindungen über verschiedene Ports eines einzigen PAs haben?

    (Beispiel: ein Memberlink von jedem CT3-Port eines PA-MC-2T3+.)

    Ja. Solange sie von derselben Palästinensischen Behörde stammt, gibt es keine Probleme.

15. Kann ich T3- oder E3-Ports bündeln?

    Nein. Nur Geschwindigkeiten von DS0, n*DS0, T1 und E1 sind mit dMLP für 7500/VIP, 7600/FlexWAN und 7600/FlexWAN2 zulässig.

    Hinweis: Verteiltes MLPPP wird nur für Teilnehmerverbindungen unterstützt, die mit T1/E1- oder T1/E1-Subraten-Geschwindigkeiten konfiguriert wurden. Die Channelized STM-1/T3/T1-Schnittstellen unterstützen auch dMLPPP bei T1/E1- oder T1/E1-Übertragungsgeschwindigkeiten mit Subrate. Verteiltes MLPPP wird nicht für Mitgliedverbindungen unterstützt, die mit Clear-Channel T3/E3 oder höheren Schnittstellengeschwindigkeiten konfiguriert wurden.

16. Was sind "neu sortierte" Fragmente?

    Wenn das empfangene Fragment oder Paket nicht mit der erwarteten Sequenznummer übereinstimmt, wird der neu sortierte Zähler erhöht. Bei unterschiedlichen Paketgrößen ist dies zwangsläufig der Fall. Bei Paketen mit fester Größe kann dies auch passieren, weil der PA-Treiber die Pakete verarbeitet, die über eine Verbindung empfangen wurden, und nicht auf Round-Robin-Basis (wie dies bei dMLP bei der Übertragung der Pakete der Fall ist). Umbestellt bedeutet keinen Paketverlust.

17. Was sind "verlorene" Fragmente?

    Wenn das Fragment oder das Paket in der falschen Reihenfolge empfangen wird und Sie feststellen, dass aus der Bestellung Fragmente oder Pakete auf allen Links empfangen werden, wird der Zähler verlorener Fragmente erhöht. Ein anderer Fall ist, wenn die Fragmente aus der Bestellung in der Liste gespeichert werden und ein Limit erreicht wird (entschieden auf Basis des SRAM auf dem VIP und was auch immer für das Paket zugewiesen ist), der Zähler für verlorene Fragmente inkrementiert wird und die nächste Sequenznummer in der Liste zur Verarbeitung übernommen wird.

18. Wie erkennt dMLP verlorene Fragmente?

    1. Sequenznummern: Wenn Sie darauf warten, dass ein Fragment mit der Sequenznummer N eingeht und alle Links ein Fragment mit einer Sequenznummer größer als N empfangen, wissen Sie, dass das Fragment N verloren gehen muss, da es nicht legal hinter Fragmenten mit höherer Nummer auf derselben Verbindung ankommen kann.

    2. Timeout: Wenn Sie zu lange auf ein Fragment warten, werden Sie es schließlich als verloren deklarieren und fortfahren.

    3. Überlauf des Reassemblierungspuffers: Wenn Sie auf das Eintreffen des Fragments N warten und in der Zwischenzeit andere Fragmente (mit Sequenznummern größer als N) auf einigen der Links eintreffen, müssen Sie diese Fragmente in einem Reassemblierungspuffer parken, bis das Fragment N angezeigt wird. Es gibt eine Grenze für die Pufferung. Wenn der Puffer überläuft, deklarieren Sie das Fragment N erneut als verloren, und setzen Sie die Verarbeitung mit dem Inhalt des Puffers fort.

19. Was sind "verlorene Empfänger"?

    Es gibt zwei mögliche Gründe für verlorene empfangene Fragmente oder Pakete:

    1. Wenn das empfangene Fragment oder Paket aus dem Fenster für den erwarteten Sequenzbereich entfernt wird, wird das Paket verworfen, indem es als verloren empfunden gekennzeichnet wird.

    2. Wenn das empfangene Fragment oder Paket innerhalb des erwarteten Sequenzbereichs-Fensters liegt, Sie jedoch keinen Paket-Header zuweisen können, um dieses Paket erneut zu übergehen, wird das Paket verworfen und als verloren gekennzeichnet.

20. Wird die Verschlüsselung mit dMLP unterstützt?

    Nein.

21. Unterstützen wir die PFC-Header-Komprimierung?

    Nein, nicht im verteilten Pfad. Der Router am anderen Ende wird nicht empfohlen, die PFC-Header-Komprimierung zu konfigurieren, da der nicht verteilte Modus aktiviert wird, wenn komprimierte Header-Frames oder -Pakete empfangen werden. Wenn Sie dMLP weiterhin ausführen möchten, muss die PFC-Header-Komprimierung an beiden Enden deaktiviert sein.

22. Wird die Softwarekomprimierung mit dMLP unterstützt?

    Nein, da die Softwarekomprimierung im verteilten Pfad nicht funktioniert.

23. Wird Fragmentierung auf der Übertragungsseite unterstützt?

    Nicht mit Vanilla dMLP. Beim Empfang von Fragmenten mit Vanilla dMLP gibt es keine Probleme, aber auf der Übertragungsseite findet keine Fragmentierung statt. Die Transmit-Side-Fragmentierung wird unterstützt, wenn die ppp-Multilink-Verbindung auf der dMLP-Schnittstelle konfiguriert wird.

24. Können wir die Mitgliedsverbindungen eines MLP-Pakets pingen?

    Nein, Sie können keine IP-Adresse für die Mitgliedslinks konfigurieren.

25. Gibt es Abhängigkeiten von der MTU- und MLP-Fragmentgröße der Verbindung?

    Nein. Die MTU-Größe hat nichts mit der MLP-Fragmentgröße zu tun, außer mit der offensichtlichen Einschränkung, dass ein MLP-Fragment wie jeder andere Frame die MTU-Größe der seriellen Verbindungen nicht überschreiten kann.

26. Können zwei MLP-Pakete zwischen einem Router-Paar konfiguriert werden?

    Ja, es ist möglich. Dies kann jedoch zu einer Beeinträchtigung des Lastenausgleichs führen. Bei Testbetten kann es hilfreich sein, mehr als zwei Router mit nur zwei Routern zu simulieren, aber es hat keinen offensichtlichen realen Wert.

    Alle Links, die zu einem gemeinsamen Peer führen, müssen im gleichen Paket enthalten sein. Ein Bündel ist definitionsgemäß der Satz von Links, die zu einem bestimmten Peer gehen.

    Ein "Peer" wird durch die Werte für den Benutzernamen und den Endpunkt-Diskriminator identifiziert, die er während der LCP- und Authentifizierungsphasen anbietet. Wenn Sie versuchen, mehrere Bündel zwischen zwei Routern zu erstellen, bedeutet dies, dass Sie versuchen, jeden Router als mehr als einen Peer zu seinem Gegenstück zu tarnen. Sie müssen sich entsprechend identifizieren.

27. Können Memberlinks unterschiedliche Warteschlangenalgorithmen haben?

    Alle Warteschlangenmechanismen für ein Paket müssen auf Paketebene und nicht auf der Ebene der Mitglieds-Verbindung angewendet werden. Die Konfiguration eines Warteschlangenalgorithmus sollte sich jedoch nicht darauf auswirken, wie die Pakete aus dem Paket ausgeschaltet werden.

28. Warum wird der tx-quque-Grenzwert für Mitgliedslinks für ein Multilink-Paket auf 26 festgelegt, wenn dMLP auf einem Cisco 7500 aktiviert ist?

    Für jede serielle Schnittstelle der Bandbreite T1/E1 beträgt der Grenzwert für die TX-Warteschlange etwa 4 oder 5. Wenn Sie T1s/E1 in Multi-Link-Einheiten bündeln, würde sich die Bandbreite für das Paket erhöhen. Da das Switching basierend auf der Bandbreite der MLP-Schnittstelle stattfinden würde, müssen Sie die Grenze für die Tx-Queue der Member-Links erhöhen. Für das Switching wird nur eine der Memberlinks, die als primäre Verbindung bezeichnet wird, verwendet. Aus diesem Grund muss der Grenzwert für "tx-queue" erhöht werden.

    Außerdem ist dieser Wert ein empirischer Wert, der nach dem Testen ausgewählt und anschließend auf diesen Wert eingestellt wird. Im Allgemeinen verfügen die Bereitstellungen über nicht mehr als 4 bis 6 T1/E1-Verbindungen in einem Paket. Ein Wert von 26 kann 6 bis 8 T1/E1-Verbindungen perfekt aufnehmen, sodass dieser Wert ausgewählt wurde.

29. Was sind Differenzialverzögerungen und ihr Wert bei der dMLP-Implementierung?

    dMLP unterstützt eine Differenzialverzögerung von 30 ms. Das würde bedeuten, dass ein Fragment zu einem Zeitpunkt T empfangen wird und es nicht in der Reihenfolge ist (mit einer Sequenznummer 100, aber wir erhalten 101). Wenn die Sequenznummer 100 erst empfangen wird, wenn T+30 ms, 100 als verloren erklärt wurde und Sie mit der Verarbeitung von 101 beginnen können, würden Sie dies tun. Falls Sie nicht mit 101 beginnen können (wenn es sich um ein mittleres Fragment handelt), suchen Sie das Fragment, das das Anfangsfragment enthält (z. B. 104) und beginnen Sie von dort.

30. Was passiert, wenn Pakete auf IP-Ebene mit Multilink auf 7500 fragmentiert werden?

    Wenn Pakete auf IP-Ebene fragmentiert werden, werden sie ohne Reassemblierung an den zwischengeschalteten Hops transportiert, aber am Zielrouter reassembliert.

31. Was geschieht, wenn Pakete auf MLP-Ebene des 7500 fragmentiert werden?

    Wenn die Pakete auf MLP-Ebene fragmentiert werden und die reassemblierten Pakete größer als MRRU sind, werden die Pakete auf der Multilink-Ebene verworfen. Die Transmit-Side-Fragmentierung wird auf dMLP nur mit dLFI unterstützt. Pakete werden auf MLP-Ebene nur fragmentiert, wenn die Paketgröße größer als die Größe "frag_size" und kleiner als die MRRU ist. Wenn Pakete gesendet werden, die mehr als die MRRU sind, und wenn sie auf IP-Ebene nicht fragmentiert sind, verwirft das andere Ende alle Pakete, deren Größe auf MLP-Ebene nicht fragmentiert ist, da die Pakete mehr als MRRU sind.

32. Wie wird MRRU berechnet?

    MRRU wird anhand der folgenden Voreinstellungen berechnet:

    1. Für die neu hinzugekommenen Mitglieds-Verbindungen wird die MRRU wieder auf der LCP-Ebene gemäß der für die Mitglieds-Verbindungen konfigurierten MRRU ausgehandelt.

    2. Der Wert, der auf der Verbindungsschnittstelle mit dem Befehl ppp multilink mru interface konfiguriert wurde.

    3. Wenn der Wert nicht konfiguriert wurde, wurde er von der Konfiguration des Befehls ppp multilink mru auf der übergeordneten Schnittstelle übernommen.

    4. Wenn beide Werte vorhanden sind, hat der Wert der Verbindungsschnittstelle Vorrang.

    5. Die Standard-MRRU ist 1524.

Debug-Verbesserungen

Diese Erweiterungen werden in Zukunft übernommen. Die Planung ist noch nicht abgeschlossen.

• Aktivieren Sie den Befehl debug frame-relais multilink auf dem LC.

• Verbesserung der aktuellen Debug-CLIs pro Schnittstelle und der angegebenen Anzahl von Paketen.

• Für dDDR wird die QoS-Funktionalität noch nicht unterstützt. Dies kann nur mit einem geeigneten Geschäftsszenario in Anspruch genommen werden.

Zugehörige Informationen

• Dialer-CEF
• Konfigurieren von Peer-to-Peer-DDR mit Dialer-Profilen
• MPLS = Multilink PPP-Unterstützung
• Verteiltes Multilink Point-to-Point-Protokoll für Cisco Router der Serie 7500
• Distributed Multilink Frame Relay (FRF.16)
• Fragmentierung und Verschachtelung von verteilten Verbindungen über Mietleitungen
• VoIP über PPP-Links mit Quality of Service (LLQ/IP RTP-Priorität, LFI, cRTP)
• Fehlerbehebung in technischenHinweisen - Cisco Router der Serie 7500
• Support-Seite für Router-Produkte - Cisco Systems
• Technischer Support und Dokumentation - Cisco Systems