Konfigurieren von Link-Services-Schnittstellen
Geräte von Juniper Networks unterstützen Link-Services auf der lsq-0/0/0 Link-Services-Warteschlangenschnittstelle, die Multilink-Services wie MLPP, MLFR und CRTP umfasst. In den folgenden Themen werden die Übersicht über Verbindungsdienste, Konfigurationsdetails und die Überprüfung der Verbindungsdienste erläutert.
Link Services Interfaces – Übersicht
Zu den Link-Services gehören die Multilink-Services Multilink Point-to-Point Protocol (MLPPP), Multilink Frame Relay (MLFR) und Compressed Real-Time Transport Protocol (CRTP). Geräte von Juniper Networks unterstützen Link Services auf der lsq-0/0/0 Link Services Queuing Interface.
Sie konfigurieren die Link Services Queuing Interface (lsq-0/0/0) auf einem Gerät von Juniper Networks für die Unterstützung von Multilink Services und CRTP.
Die Warteschlangenschnittstelle für Verbindungsdienste besteht aus Diensten, die von den folgenden Schnittstellen bereitgestellt werden: Multilink Services Interface (ml-fpc/pic/port ), Link Services Interface (ls-fpc/pic/port ) und Link Services Intelligent Queuing Interface (lsq-fpc/pic/port ). Obwohl die Multilink-Services, Link-Services und Link-Services-IQ-Schnittstellen (Intelligent Queuing) auf physischen Schnittstellenkarten (PICs) installiert sind, ist die Link-Services-Queuing-Schnittstelle nur eine interne Schnittstelle und nicht mit einem physischen Medium oder einem Physical Interface Module (PIM) verknüpft.
(ls-fpc/pic/port ) wird nicht unterstützt.
Dieser Abschnitt enthält die folgenden Themen.
- Auf einer Link Services-Schnittstelle verfügbare Services
- Ausnahmen für Link-Services
- Konfiguration von MLPPP mit mehreren Klassen
- Warteschlangen mit LFI
- Komprimiertes Echtzeit-Transportprotokoll – Übersicht
- Konfigurieren der Fragmentierung nach Weiterleitungsklasse
- Konfigurieren des Link-Layer-Overheads
Auf einer Link Services-Schnittstelle verfügbare Services
Die Link-Services-Schnittstelle ist eine logische Schnittstelle , die standardmäßig verfügbar ist. Tabelle 1 fasst die auf der Schnittstelle verfügbaren Services zusammen.
| Dienste |
Zweck |
Weitere Informationen |
|---|---|---|
| Multilink-Bundles mittels MLPPP- und MLFR-Kapselung |
Fasst mehrere Komponentenverbindungen zu einem größeren logischen Bündel zusammen, um zusätzliche Bandbreite, Load Balancing und Redundanz bereitzustellen.
Anmerkung:
DCAC-Konfigurationen (Dynamic Call Admission Control) werden auf Link Services-Schnittstellen nicht unterstützt. |
|
| Link Fragmentierung und Interleave (LFI) |
Reduziert Verzögerungen und Jitter auf Verbindungen, indem große Datenpakete aufgebrochen und verzögerungsempfindliche Sprachpakete mit den daraus resultierenden kleineren Paketen verschachtelt werden. |
|
| Komprimiertes Echtzeit-Transportprotokoll (CRTP) |
Reduziert den durch das Real-Time Transport Protocol (RTP) verursachten Overhead für Sprach- und Videopakete. |
|
| Class-of-Service (CoS)-Klassifizierer, Weiterleitungsklassen, Scheduler und Scheduler-Maps sowie Shaping-Raten |
Bietet verzögerungsempfindlichen Paketen eine höhere Priorität – durch Konfiguration von CoS, wie z. B. der folgenden:
|
Ausnahmen für Link-Services
Die Implementierung von Link- und Multilink-Services ähnelt der Implementierung auf anderen Routing-Plattformen, mit folgenden Ausnahmen:
-
Die Unterstützung für Link- und Multilink-Services erfolgt auf der
lsq-0/0/0Schnittstelle anstelle derml-fpc/pic/portSchnittstellen ,lsq-fpc/pic/portundls-fpc/pic/port. -
Wenn LFI aktiviert ist, werden fragmentierte Pakete im Rundlaufverfahren auf den konstituierenden Links in die Warteschlange gestellt, um ein Load Balancing pro Paket und pro Fragment zu ermöglichen. Siehe Warteschlangen mit LFI.
-
Die Unterstützung für die Planung pro Einheit erfolgt für alle Arten von Komponentenverbindungen (auf allen Arten von Schnittstellen).
-
Das Compressed Real-Time Transport Protocol (CRTP) wird sowohl für MLPPP als auch für PPP unterstützt.
Konfiguration von MLPPP mit mehreren Klassen
Für lsq-0/0/0 Juniper Networks Geräte mit MLPPP-Kapselung können Sie MLPPP mit mehreren Klassen konfigurieren. Wenn Sie MLPPP mit mehreren Klassen nicht konfigurieren, können Fragmente aus verschiedenen Klassen nicht verschachtelt werden. Alle Fragmente für ein einzelnes Paket müssen gesendet werden, bevor die Fragmente eines anderen Pakets gesendet werden. Nicht fragmentierte Pakete können zwischen Fragmenten eines anderen Pakets verschachtelt werden, um die Latenz bei nicht fragmentierten Paketen zu verringern. Tatsächlich wird latenzempfindlicher Datenverkehr als regulärer PPP-Datenverkehr und Massenverkehr als Multilink-Datenverkehr gekapselt. Dieses Modell funktioniert, solange es eine einzige Klasse von latenzempfindlichem Datenverkehr gibt und es keinen Datenverkehr mit hoher Priorität gibt, der Vorrang vor latenzempfindlichem Datenverkehr hat. Dieser Ansatz für LFI, der auf dem Link Services PIC verwendet wird, unterstützt nur zwei Ebenen der Datenverkehrspriorität, was nicht ausreicht, um die vier bis acht Weiterleitungsklassen zu tragen.
Multiclass MLPPP ermöglicht es, mehrere Klassen von latenzempfindlichem Datenverkehr zu haben, die über ein einziges Multilink-Bündel mit Massenverkehr übertragen werden. MLPPP mit mehreren Klassen ermöglicht verschiedene Datenverkehrsklassen mit unterschiedlichen Latenzgarantien. Mit Multiclass-MLPPP können Sie jede Weiterleitungsklasse einer separaten Multilink-Klasse zuordnen, wodurch Prioritäts- und Latenzgarantien erhalten bleiben.
Die Konfiguration von LFI und Multiclass-MLPPP im selben Bundle ist nicht erforderlich und wird auch nicht unterstützt, da Multiclass-MLPPP eine Obermenge von Funktionen darstellt. Wenn Sie MLPPP mit mehreren Klassen konfigurieren, wird LFI automatisch aktiviert.
Die PPP-Implementierung von Junos OS unterstützt nicht die Aushandlung von PPP-NCP-Optionen für Adressfeldkomprimierung und Protokollfeldkomprimierung, was bedeutet, dass die Software immer einen vollständigen 4-Byte-PPP-Header sendet.
Die Junos OS-Implementierung von Multiclass-MLPPP unterstützt keine Komprimierung von gemeinsamen Headerbytes.
Multiclass-MLPPP vereinfacht Probleme bei der Paketreihenfolge erheblich, die auftreten, wenn mehrere Links verwendet werden. Ohne Multiklassen-MLPPP wird der gesamte Sprachverkehr, der zu einem einzigen Datenstrom gehört, an eine einzige Verbindung gehasht, um Probleme bei der Paketreihenfolge zu vermeiden. Mit Multiclass MLPPP können Sie Sprachverkehr einer Klasse mit hoher Priorität zuweisen und mehrere Links verwenden.
Um Multiclass-MLPPP auf einer Link-Services-IQ-Schnittstelle zu konfigurieren, müssen Sie angeben, wie viele Multilink-Klassen ausgehandelt werden sollen, wenn ein Link dem Bundle beitritt, und Sie müssen die Zuordnung einer Weiterleitungsklasse zu einer Multiclass-MLPPP-Klasse angeben.
Um anzugeben, wie viele Multilink-Klassen ausgehandelt werden sollen, wenn ein Link dem Bundle beitritt, fügen Sie die multilink-max-classes folgende Anweisung ein:
multilink-max-classes number;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
-
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]
Die Anzahl der Multilink-Klassen kann 1 bis 8 betragen. Die Anzahl der Multilink-Klassen für jede Weiterleitungsklasse darf die Anzahl der auszuhandelnden Multilink-Klassen nicht überschreiten.
Um die Zuordnung einer Weiterleitungsklasse in eine MLPPP-Klasse mit mehreren Klassen festzulegen, fügen Sie die multilink-class Anweisung auf der [edit class-of-service fragmentation-maps forwarding-class class-name] Hierarchieebene ein:
edit class-of-service fragmentation-maps forwarding-classclass-namemultilink-class number
Die Indexnummer der Multilink-Klasse kann zwischen 0 und 7 liegen. Die multilink-class Aussage und die no-fragmentation Aussage schließen sich gegenseitig aus.
Um die Anzahl der ausgehandelten Multilink-Klassen anzuzeigen, geben Sie den show interfaces lsq-0/0/0.logical-unit-number detail Befehl ein.
Warteschlangen mit LFI
LFI- oder Nicht-LFI-Pakete werden auf der Grundlage der Warteschlangen, in denen sie ankommen, auf konstituierenden Links in Warteschlangen gestellt. Während die fragmentierten, nicht fragmentierten oder LFI-Pakete in die Warteschlange gestellt werden, treten keine Änderungen an der Warteschlangennummer auf.
Angenommen, Warteschlange Q0 ist mit dem Fragmentierungsschwellenwert 128, Q1 ohne Fragmentierung und Q2 mit dem Fragmentierungsschwellenwert 512 konfiguriert. Q0 empfängt Datenverkehr mit der Paketgröße 512. Q1 empfängt Sprachdatenverkehr mit 64 Byte und Q2 Datenstrom mit 128-Byte-Paketen. Als nächstes wird der Stream auf Q0 fragmentiert und in Q0 einer konstituierenden Verbindung eingereiht. Außerdem werden alle Pakete auf Q2 auf Q0 auf der konstituierenden Verbindung in die Warteschlange gestellt. Der Stream auf Q1 wird als LFI betrachtet, da keine Fragmentierung konfiguriert ist. Alle Pakete von Q0 und Q2 werden auf Q0 der konstituierenden Verbindung in die Warteschlange gestellt. Alle Pakete von Q1 werden auf Q2 der konstituierenden Verbindung in die Warteschlange gestellt.
Mit lsq-0/0/0kann CRTP auf LFI- und Nicht-LFI-Pakete angewendet werden. Aufgrund von CRTP wird es keine Änderungen an ihren Warteschlangennummern geben.
Warteschlangen für Q2s von Bürgerlinks
Bei Verwendung von Class-of-Service für ein Multilink-Bundle wird der gesamte Q2-Datenverkehr aus dem Multilink-Bundle in die Warteschlange zu Q2 der konstituierenden Links gestellt, basierend auf einem Hash, der aus der Quelladresse, der Zieladresse und dem IP-Protokoll des Pakets berechnet wird. Wenn es sich bei der IP-Nutzlast um TCP- oder UDP-Datenverkehr handelt, enthält der Hash auch den Quellport und den Zielport. Als Ergebnis dieses Hash-Algorithmus wird der gesamte Datenverkehr, der zu einem Datenstrom gehört, in Q2 einer konstituierenden Verbindung in die Warteschlange gestellt. Diese Methode der Datenverkehrsübermittlung an die konstituierende Verbindung wird jederzeit angewendet, auch wenn das Bundle nicht mit LFI eingerichtet wurde.
Komprimiertes Echtzeit-Transportprotokoll – Übersicht
Mit dem Real-Time Transport Protocol (RTP) kann die Interoperabilität zwischen verschiedenen Implementierungen von Audio- und Videoanwendungen im Netzwerk erreicht werden. In einigen Fällen kann der Header, der die IP-, UDP- und RTP-Header enthält, jedoch in Netzwerken mit langsamen Leitungen wie DFÜ-Modems zu groß sein (ca. 40 Byte). Das Compressed Real-Time Transport Protocol (CRTP) kann konfiguriert werden, um den Netzwerk-Overhead bei langsamen Verbindungen zu reduzieren. CRTP ersetzt die IP-, UDP- und RTP-Header durch eine 2-Byte-Kontext-ID (CID), wodurch der Header-Overhead erheblich reduziert wird.
Abbildung 1 zeigt, wie CRTP den RTP-Header in einem Sprachpaket komprimiert, indem ein 40-Byte-Header auf einen 2-Byte-Header reduziert wird.
Sie können CRTP mit logischer MLPPP- oder PPP-Schnittstellenkapselung auf Link-Services-Schnittstellen konfigurieren. Siehe Beispiel: MLPPP-Bundle konfigurieren.
Echtzeit- und Nicht-Echtzeit-Datenrahmen werden auf langsameren Verbindungen zusammengeführt, ohne dass es zu übermäßigen Verzögerungen im Echtzeitverkehr kommt. Weitere Informationen finden Sie unter Link-Fragmentierung und Interleave-Konfiguration.
Konfigurieren der Fragmentierung nach Weiterleitungsklasse
Für lsq-0/0/0 können Sie Fragmentierungseigenschaften für bestimmte Weiterleitungsklassen angeben. Der Datenverkehr in jeder Weiterleitungsklasse kann entweder Multilink-gekapselt (fragmentiert und sequenziert) oder nicht gekapselt (gehasht ohne Fragmentierung) sein. Standardmäßig ist der Datenverkehr in allen Weiterleitungsklassen Multilink-gekapselt.
Wenn Sie keine Fragmentierungseigenschaften für die Warteschlangen auf MLPPP-Schnittstellen konfigurieren, ist der auf Hierarchieebene [edit interfaces interface-name unit logical-unit-number fragment-threshold] festgelegte Schwellenwert für die Fragmentierung der Fragmentierungsschwellenwert für alle Weiterleitungsklassen innerhalb der MLPPP-Schnittstelle. Für MLFR FRF.16-Schnittstellen ist der auf der [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] Hierarchieebene festgelegte Schwellenwert für die Fragmentierung der Fragmentierungsschwellenwert für alle Weiterleitungsklassen innerhalb der MLFR FRF.16-Schnittstelle.
Wenn Sie an keiner Stelle in der Konfiguration eine maximale Fragmentgröße festlegen, werden Pakete dennoch fragmentiert, wenn sie die kleinste maximale Übertragungseinheit (MTU) oder die maximale empfangene rekonstruierte Einheit (MRRU) aller Verbindungen im Bündel überschreiten. Ein nicht gekapselter Flow verwendet nur eine Verbindung. Wenn der Datenstrom eine einzelne Verbindung überschreitet, muss die Weiterleitungsklasse Multilink gekapselt sein, es sei denn, die Paketgröße überschreitet die MTU/MRRU.
Auch wenn Sie an keiner Stelle in der Konfiguration eine maximale Fragmentgröße festlegen, können Sie die MRRU konfigurieren, indem Sie die mrru-Anweisung auf der [edit interfaces lsq-0/0/0 unit logical-unit-number] ODER-Hierarchieebene [edit interfaces interface-name mlfr-uni-nni-bundle-options] einschließen. Die MRRU ähnelt der MTU, ist jedoch spezifisch für Link-Services-Schnittstellen. Standardmäßig beträgt die MRRU-Größe 1504 Byte, und Sie können sie auf 1500 bis 4500 Byte konfigurieren.
Um Fragmentierungseigenschaften in einer Warteschlange zu konfigurieren, schließen Sie die Fragmentierung-maps-Anweisung auf Hierarchieebene [edit class-of-service] ein:
[edit class-of-service]
fragmentation-maps {
map-name {
forwarding-class class-name {
fragment-threshold bytes;
multilink-class number;
no-fragmentation;
}
}
}
Um einen Schwellenwert für die Fragmentierung pro Weiterleitungsklasse festzulegen, schließen Sie die fragment-threshold Anweisung in die Fragmentierungszuordnung ein. Diese Anweisung legt die maximale Größe jedes Multilink-Fragments fest.
Um festzulegen, dass der Datenverkehr in einer Warteschlange nicht gekapselt und nicht Multilink-gekapselt ist, schließen Sie die no-fragmentation Anweisung in die Fragmentierung Map ein. Diese Anweisung gibt an, dass den in dieser Warteschlange empfangenen Paketen kein zusätzlicher Fragmentierungs-Header vorangestellt wird und dass statisches Link-Load Balancing verwendet wird, um die ordnungsgemäße Paketzustellung sicherzustellen.
Für eine bestimmte Weiterleitungsklasse können Sie entweder die fragment-threshold oder-Anweisung no-fragmentation einschließen; sie schließen sich gegenseitig aus.
Sie verwenden die multilink-class Anweisung, um eine Weiterleitungsklasse in ein MLPPP mit mehreren Klassen abzubilden. Für eine bestimmte Weiterleitungsklasse können Sie entweder die multilink-class oder-Anweisung no-fragmentation einschließen; sie schließen sich gegenseitig aus.
Um eine Fragmentierungs-Map einer Multilink-PPP-Schnittstelle oder einem MLFR FRF.16-DLCI zuzuordnen, fügen Sie die fragmentation-map Anweisung auf der [edit class-of-service interfaces interface-name unit logical-unit-number] Hierarchieebene ein:
[edit class-of-service interfaces]
lsq-0/0/0 {
unit logical-unit-number { # Multilink PPP
fragmentation-map map-name;
}
}
lsq-0/0/0:channel { # MLFR FRF.16
unit logical-unit-number
fragmentation-map map-name;
}
}
Konfigurieren des Link-Layer-Overheads
Link-Layer-Overhead kann aufgrund von Bit Stuffing auf seriellen Links zu Paketverlusten bei konstituierenden Links führen. Bit Stuffing wird verwendet, um zu verhindern, dass Daten als Steuerinformationen interpretiert werden.
Standardmäßig sind 4 Prozent der gesamten Bundle-Bandbreite für den Link-Layer-Overhead reserviert. In den meisten Netzwerkumgebungen beträgt der durchschnittliche Link-Layer-Overhead 1,6 Prozent. Daher empfehlen wir 4 Prozent als Absicherung.
Für lsq-0/0/0 ein Gerät von Juniper Networks können Sie den Prozentsatz der Bundle-Bandbreite konfigurieren, der für den Link-Layer-Overhead reserviert werden soll. Fügen Sie dazu die link-layer-overhead-Anweisung ein:
link-layer-overhead percent;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
-
[edit interfaces interface-name mlfr-uni-nni-bundle-options] -
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]
Sie können den Wert so konfigurieren, dass er zwischen 0 Prozent und 50 Prozent liegt.
Konfigurationsübersicht für Link-Services
Bevor Sie beginnen:
Installieren Sie Gerätehardware.
Grundlegende Konnektivität herstellen. Weitere Informationen finden Sie im Handbuch "Erste Schritte" für Ihr Gerät.
Grundlegendes Verständnis der physischen und logischen Schnittstellen sowie der Schnittstellenkonventionen von Juniper Networks haben. Siehe Schnittstellen verstehen
Planen Sie, wie Sie die Link Services-Schnittstelle in Ihrem Netzwerk verwenden werden. Siehe Übersicht über Verbindungsdienstschnittstellen.
Führen Sie die folgenden Aufgaben aus, um Link-Services auf einer Schnittstelle zu konfigurieren:
- Konfigurieren Sie die Link-Fragmentierung und -Verschachtelung (LFI). Siehe Beispiel: Konfiguration der Linkfragmentierung und Verschachtelung.
- Konfigurieren Sie Klassifizierer und Weiterleitungsklassen. Siehe Beispiel: Klassifikatoren und Weiterleitungsklassen definieren.
- Konfigurieren Sie Scheduler-Zuordnungen. Weitere Informationen finden Sie unter Grundlegendes zum Definieren und Anwenden von Scheduler-Zuordnungen.
- Konfigurieren Sie die Schnittstellen-Shaping-Raten. Siehe Beispiel: Konfigurieren von Schnittstellen-Shaping-Raten
- Konfigurieren Sie ein MLPPP-Bundle. Siehe Beispiel: MLPPP-Bundle konfigurieren.
- Informationen zum Konfigurieren von CRTP finden Sie unter Beispiel: Konfigurieren des komprimierten Echtzeit-Transportprotokolls
Überprüfen der Link Services-Schnittstelle
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Statistiken der Link-Services-Schnittstelle
- Überprüfen der CoS-Konfiguration von Link Services
Überprüfen der Statistiken der Link-Services-Schnittstelle
Zweck
Überprüfen Sie die Statistiken der Link-Services-Schnittstelle.
Aktion
Die in diesem Abschnitt bereitgestellte Beispielausgabe basiert auf den Konfigurationen, die in Beispiel: Konfigurieren eines MLPPP-Pakets bereitgestellt werden. Gehen Sie wie folgt vor, um zu überprüfen, ob die konstituierenden Links korrekt zum Bundle hinzugefügt wurden und die Pakete fragmentiert und korrekt übertragen werden:
Konfigurieren Sie auf Gerät R0 und Gerät R1, den beiden in diesem Beispiel verwendeten Geräten, MLPPP und LFI wie unter Beispiel: Konfigurieren eines MLPPP-Pakets beschrieben.
Geben Sie in der CLI den Befehl ein, um zu
pingüberprüfen, ob eine Verbindung zwischen R0 und R1 hergestellt wird.Übertragen Sie 10 Datenpakete à 200 Byte von R0 nach R1.
Geben Sie auf R0 über die CLI den
show interfaces interface-name statisticsBefehl ein.
user@R0> show interfaces lsq-0/0/0 statistics detail
Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Interface index: 134, SNMP ifIndex: 29, Generation: 135
Link-level type: LinkService, MTU: 1504
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Last flapped : 2006-06-23 11:36:23 PDT (03:38:43 ago)
Statistics last cleared: 2006-06-23 15:13:12 PDT (00:01:54 ago)
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 1820 0 bps
Input packets: 0 0 pps
Output packets: 10 0 pps
...
Egress queues: 8 supported, 8 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 DATA 10 10 0
1 expedited-fo 0 0 0
2 VOICE 0 0 0
3 NC 0 0 0
Logical interface lsq-0/0/0.0 (Index 67) (SNMP ifIndex 41) (Generation 133)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP
Bandwidth: 16mbps
Bundle options:
...
Drop timer period 0
Sequence number format long (24 bits)
Fragmentation threshold 128
Links needed to sustain bundle 1
Interleave fragments Enabled
Bundle errors:
Packet drops 0 (0 bytes)
Fragment drops 0 (0 bytes)
...
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 0 0 0 0
Output: 20 0 1920 0
Packets:
Input : 0 0 0 0
Output: 10 0 1820 0
Link:
se-1/0/0.0
Input : 0 0 0 0
Output: 10 0 1320 0
se-1/0/1.0
Input : 0 0 0 0
Output: 10 0 600 0
...
Destination: 10.0.0.9/24, Local: 10.0.0.10, Broadcast: Unspecified, Generation:144
Diese Ausgabe zeigt eine Zusammenfassung der Schnittstelleninformationen. Überprüfen Sie die folgenden Informationen:
Physical interface– Die physische Schnittstelle istEnabled. Wenn die Schnittstelle alsDisabledangezeigt wird, führen Sie einen der folgenden Schritte aus:Löschen Sie im CLI-Konfigurationseditor die
disableAnweisung auf der[edit interfaces interface-name]Ebene der Konfigurationshierarchie.Deaktivieren Sie im J-Web-Konfigurationseditor das
DisableKontrollkästchen auf derInterfaces>interface-nameSeite.
Physical link– Die physische Verbindung istUp. Der Verbindungsstatus vonDownweist auf ein Problem mit dem Schnittstellen-Modul, dem Schnittstellenport oder der physischen Verbindung hin (Link-Layer-Fehler).Last flapped– DieLast FlappedZeit ist ein Erwartungswert. DieLast FlappedUhrzeit gibt an, wann die physische Schnittstelle das letzte Mal nicht mehr verfügbar und dann wieder verfügbar war. Unerwartetes Flattern weist auf wahrscheinliche Link-Layer-Fehler hin.Traffic statistics– Anzahl und Rate der auf der Schnittstelle empfangenen und übertragenen Bytes und Pakete. Stellen Sie sicher, dass die Anzahl der eingehenden und ausgehenden Bytes und Pakete dem erwarteten Durchsatz für die physische Schnittstelle entspricht. Um die Statistiken zu löschen und nur neue Änderungen anzuzeigen, verwenden Sie denclear interfaces statistics interface-nameBefehl.Queue counters– Name und Anzahl der Warteschlangen sind wie konfiguriert. Diese Beispielausgabe zeigt, dass 10 Datenpakete übertragen und keine Pakete verworfen wurden.Logical interface—Name des Multilink-Pakets, das Sie konfiguriert haben—lsq-0/0/0.0.Bundle options– Der Fragmentierungsschwellenwert ist korrekt konfiguriert, und die Fragmentverschachtelung ist aktiviert.Bundle errors– Alle Pakete und Fragmente, die vom Bundle verworfen wurden.Statistics– Die Fragmente und Pakete werden vom Gerät korrekt empfangen und übertragen. Alle Verweise auf die Datenverkehrsrichtung (Ein- oder Ausgabe) werden in Bezug auf das Gerät definiert. Vom Gerät empfangene Eingabefragmente werden zu Eingabepaketen zusammengesetzt. Ausgabepakete werden für die Übertragung aus dem Gerät in Ausgabefragmente segmentiert.In diesem Beispiel wurden 10 Datenpakete à 200 Byte übertragen. Da der Schwellenwert für die Fragmentierung auf 128 Byte festgelegt ist, wurden alle Datenpakete in zwei Fragmente fragmentiert. Die Beispielausgabe zeigt, dass 10 Pakete und 20 Fragmente korrekt übertragen wurden.
Link– Die konstituierenden Links werden zu diesem Bündel hinzugefügt und empfangen und übertragen Fragmente und Pakete korrekt. Die kombinierte Anzahl der Fragmente, die über die konstituierenden Links übertragen werden, muss der Anzahl der vom Bündel übertragenen Fragmente entsprechen. Diese Beispielausgabe zeigt, dass das Bündel 20 Fragmente und die beiden konstituierenden Linksse-1/0/0.0undse-1/0/1.0.0korrekt übertragenen10+10=20Fragmente übertragen hat.DestinationundLocal—IP-Adresse der Remote-Seite des Multilink-Bundles und der lokalen Seite des Multilink-Bundles. Diese Beispielausgabe zeigt, dass die Zieladresse die Adresse auf R1 und die lokale Adresse die Adresse auf R0 ist.
Überprüfen der CoS-Konfiguration von Link Services
Zweck
Überprüfen Sie die CoS-Konfigurationen auf der Link Services-Schnittstelle.
Aktion
Geben Sie in der CLI die folgenden Befehle ein:
show class-of-service interface interface-nameshow class-of-service classifier name classifier-nameshow class-of-service scheduler-map scheduler-map-name
Die in diesem Abschnitt bereitgestellte Beispielausgabe basiert auf den Konfigurationen, die inBeispiel: Konfigurieren eines MLPPP-Pakets bereitgestellt werden.
user@R0> show class-of-service interface lsq-0/0/0
Physical interface: lsq-0/0/0, Index: 136
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Chassis scheduler map: [default-chassis], Index: 4
Logical interface: lsq-0/0/0.0, Index: 69
Object Name Type Index
Scheduler-map s_map Output 16206
Classifier ipprec-compatibility ip 12
user@R0> show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 140
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Logical interface: ge-0/0/1.0, Index: 68
Object Name Type Index
Classifier classfy_input ip 4330
user@R0> show class-of-service classifier name classify_input
Classifier: classfy_input, Code point type: inet-precedence, Index: 4330
Code point Forwarding class Loss priority
000 DATA low
010 VOICE low
user@R0> show class-of-service scheduler-map s_map
Scheduler map: s_map, Index: 16206
Scheduler: DATA, Forwarding class: DATA, Index: 3810
Transmit rate: 49 percent, Rate Limit: none, Buffer size: 49 percent, Priority:low
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: VOICE, Forwarding class: VOICE, Index: 43363
Transmit rate: 50 percent, Rate Limit: none, Buffer size: 5 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: NC, Forwarding class: NC, Index: 2435
Transmit rate: 1 percent, Rate Limit: none, Buffer size: 1 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Diese Ausgabebeispiele zeigen eine Zusammenfassung der konfigurierten CoS-Komponenten. Überprüfen Sie die folgenden Informationen:
Logical Interface– Name des Multilink-Bundles und der auf das Bundle angewendeten CoS-Komponenten. Die Beispielausgabe zeigt, dass das Multilink-Bundle istlsq-0/0/0.0und die CoS-Scheduler-Maps_mapdarauf angewendet wird.Classifier– Codepunkte, Weiterleitungsklassen und Verlustprioritäten, die dem Klassifikator zugewiesen sind. Die Beispielausgabe zeigt, dass ein Standardklassifizierer,ipprec-compatibility, auf dielsq-0/0/0Schnittstelle und der Klassifiziererclassify_inputauf diege-0/0/1Schnittstelle angewendet wurde.Scheduler– Übertragungsrate, Puffergröße, Priorität und Verlustpriorität, die jedem Scheduler zugewiesen sind. Die Beispielausgabe zeigt die Daten-, Sprach- und Netzwerksteuerungs-Scheduler mit allen konfigurierten Werten an.
Grundlegendes zur Konfiguration der internen Schnittstelle LSQ-0/0/0
Die Link-Services-Schnittstelle ist nur eine interne Schnittstelle. Sie ist nicht mit einem physischen Medium oder PIM verknüpft. Pakete werden zur Link-Bündelung oder -Komprimierung an diese Schnittstelle weitergeleitet.
Möglicherweise müssen Sie Ihre Konfiguration aktualisieren, um die interne Schnittstelle lsq-0/0/0 als Warteschlangenschnittstelle für Verbindungsdienste anstelle von ls-0/0/0 zu verwenden, die veraltet ist. Sie können auch ein Rollback der geänderten Konfiguration durchführen, um ls-0/0/0 zu verwenden.
Beispiel: Upgrade von ls-0/0/0 auf lsq-0/0/0 für Multilink Services
In diesem Beispiel wird gezeigt, wie Sie ein Upgrade von ls-0/0/0 auf lsq-0/0/0 durchführen (oder die Änderung rückgängig machen) für Multilink-Services.
Anforderungen
Dieses Verfahren ist nur erforderlich, wenn Sie weiterhin ls-0/0/0 anstelle von lsq-/0/0/0 verwenden oder wenn Sie zur alten Schnittstelle zurückkehren müssen.
Überblick
In diesem Beispiel benennen Sie die interne Schnittstelle der Verbindungsdienste von ls-0/0/0 in lsq-0/0/0 oder umgekehrt um. Sie benennen alle Vorkommen von ls-0/0/0 in der Konfiguration in lsq-0/0/0 um und konfigurieren die Fragmentierung, indem Sie keine Fragmentierung hinzufügen. Sie geben keine Fragmentierung nach dem Namen von Warteschlange 2 an, wenn Warteschlange 2 konfiguriert ist, oder nach einer gesicherten Weiterleitung. Anschließend fügen Sie die im vorherigen Schritt konfigurierte Fragmentierungszuordnung an lsq-0/0/0 an und geben die Einheitennummer als 6 des Multilink-Pakets an, für das Interleave-Fragmente konfiguriert sind.
Dann führen Sie ein Rollback der Konfiguration von lsq-0/0/0 auf ls-0/0/0 durch. Sie benennen alle Vorkommen in der Konfiguration von lsq-0/0/0 in ls-0/0/0 um. Sie löschen die Fragmentierungszuordnung, wenn sie unter der Hierarchie [class-of-service] konfiguriert ist, und löschen die Fragmentierungszuordnung, wenn sie lsq-0/0/0 zugewiesen ist. Sie können multilink-max-classes löschen, wenn es für lsq-0/0/0 unter der Hierarchie [interfaces] konfiguriert ist. Anschließend löschen Sie Link-Layer-Overhead, wenn es für lsq-0/0/0 unter der Hierarchie [Schnittstellen] konfiguriert ist.
Wenn für keine Weiterleitungsklasse eine Fragmentierung konfiguriert ist und die Fragmentierungszuordnung lsq-0/0/0 zugewiesen ist, konfigurieren Sie Interleave-Fragmente für die ls-0/0/0-Schnittstelle. Schließlich konfigurieren Sie den Klassifizierer für LFI-Pakete so, dass er auf Warteschlange 2 verweist. (Die ls-0/0/0-Schnittstelle behandelt Warteschlange 2 als LFI-Warteschlange.)
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um schnell ein Upgrade von ls-0/0/0 auf lsq-0/0/0 durchzuführen (oder die Änderung rückgängig zu machen), kopieren Sie die folgenden Befehle, und fügen Sie sie in die CLI ein:
For interfaces ls-0/0/0 to lsq-0/0/0 [edit] rename interfaces ls-0/0/0 to lsq-0/0/0 set class-of-service fragmentation-maps map6 forwarding-class assured-forwarding no-fragmentation set class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6
For interfaces lsq-0/0/0 to ls-0/0/0 [edit] rename interfaces lsq-0/0/0 to ls-0/0/0 delete class-of-service fragmentation-maps map6 delete class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6 delete interfaces lsq-0/0/0 unit 6 link-layer-overhead delete interfaces lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead set interfaces ls-0/0/0 unit 6 interleave-fragments
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So führen Sie ein Upgrade von ls-0/0/0 auf lsq-0/0/0 durch oder um diese Änderung rückgängig zu machen:
Benennen Sie alle Vorkommen von ls-0/0/0 in der Konfiguration um.
[edit] user@host# rename interfaces ls-0/0/0 to lsq-0/0/0
Konfigurieren Sie die Fragmentierungskarte.
[edit class-of-service fragmentation-maps] user@host# set map6 forwarding-class assured-forwarding no-fragmentation
Geben Sie die Einheitennummer des Multilink-Bundles an.
[edit class-of-service ] user@host# set interfaces lsq-0/0/0 unit 6 fragmentation-map map6
Rollback der Konfiguration für alle Vorkommen in der Konfiguration.
[edit] user@host# rename interfaces lsq-0/0/0 to ls-0/0/0
Löschen Sie die Fragmentierung Map unter Class of Service.
[edit] user@host# delete class-of-service fragmentation-maps map6
Löschen Sie die Fragmentierungszuordnung, wenn sie der lsq-0/0/0-Schnittstelle zugewiesen ist.
[edit class-of-service interfaces] user@host# delete lsq-0/0/0 unit 6 fragmentation-map map6
Löschen Sie die maximalen Multilink-Klassen, wenn sie für lsq-0/0/0 konfiguriert ist.
Anmerkung:Multilink-max-classes wird nicht unterstützt und ist höchstwahrscheinlich nicht konfiguriert.
Löschen Sie Link-Layer-Overhead, wenn es für lsq-0/0/0 konfiguriert ist.
[edit interfaces] user@host# delete lsq-0/0/0 unit 6 link-layer-overhead
Löschen Sie Link-Layer-Overhead, wenn es für lsq-0/0/0:0 konfiguriert ist.
[edit interfaces] user@host# delete lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead
Konfigurieren Sie Interleave-Fragmente für die ls-0/0/0-Schnittstelle.
[edit interfaces] user@host# set ls-0/0/0 unit 6 interleave-fragments
Befund
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe des show class-of-service Befehls. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit]
user@host# show class-of-service
interfaces {
lsq-0/0/0 {
unit 6 {
fragmentation-map map6;
}
}
}
fragmentation-maps {
map6 {
forwarding-class {
assured-forwarding {
no-fragmentation;
}
}
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Fehlerbehebung bei der Link Services-Schnittstelle
So lösen Sie Konfigurationsprobleme auf einer Link Services-Schnittstelle:
- Bestimmen, welche CoS-Komponenten auf die konstituierenden Verbindungen angewendet werden
- Ermitteln der Ursachen für Jitter und Latenz im Multilink-Bundle
- Ermitteln Sie, ob LFI und Load Balancing ordnungsgemäß funktionieren
- Ermitteln Sie, warum Pakete auf einer PVC zwischen einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters abgelegt werden.
Bestimmen, welche CoS-Komponenten auf die konstituierenden Verbindungen angewendet werden
Problem
Beschreibung
Sie konfigurieren ein Multilink-Bundle, aber es wird auch Datenverkehr ohne MLPPP-Kapselung durch die konstituierenden Links des Multilink-Bundles geleitet. Wenden Sie alle CoS-Komponenten auf die konstituierenden Links an, oder reicht es aus, sie auf das Multilink-Bundle anzuwenden?
Lösung
Sie können eine Scheduler-Zuordnung auf das Multilink-Bundle und seine konstituierenden Links anwenden. Obwohl Sie mehrere CoS-Komponenten mit der Scheduler-Zuordnung anwenden können, konfigurieren Sie nur die erforderlichen Komponenten. Es wird empfohlen, die Konfiguration der Komponentenverbindungen einfach zu halten, um unnötige Verzögerungen bei der Übertragung zu vermeiden.
Tabelle 2 zeigt die CoS-Komponenten, die auf ein Multilink-Bundle angewendet werden sollen, und seine konstituierenden Links.
Cos-Komponente |
Multilink-Bundle |
Konstituierende Links |
Erklärung |
|---|---|---|---|
Klassifikator |
Ja |
Nein |
Die CoS-Klassifizierung erfolgt auf der eingehenden Seite der Schnittstelle, nicht auf der sendenden Seite, sodass keine Klassifizierer für die konstituierenden Verbindungen erforderlich sind. |
Weiterleitungsklasse |
Ja |
Nein |
Die Weiterleitungsklasse ist einer Warteschlange zugeordnet, und die Warteschlange wird durch eine Schedulerzuordnung auf die Schnittstelle angewendet. Die Zuweisung der Warteschlange wird auf den konstituierenden Links vorgegeben. Alle Pakete aus Q2 des Multilink-Bündels werden Q2 der konstituierenden Verbindung zugewiesen, und Pakete aus allen anderen Warteschlangen werden Q0 der konstituierenden Verbindung in die Warteschlange gestellt. |
Scheduler-Map |
Ja |
Ja |
Wenden Sie Scheduler-Zuordnungen wie folgt auf das Multilink-Bundle und den Komponentenlink an:
|
Shaping-Rate für einen Pro-Unit-Scheduler oder einen Scheduler auf Schnittstellenebene |
Nein |
Ja |
Da die Planung pro Einheit nur am Endpunkt angewendet wird, wenden Sie diese Formgebungsrate nur auf die konstituierenden Verbindungen an. Jede zuvor angewendete Konfiguration wird durch die konstituierende Verbindungskonfiguration überschrieben. |
Exakte Übertragungsrate oder Warteschlangen-Level-Shaping |
Ja |
Nein |
Das auf die konstituierenden Links angewendete Shaping auf Schnittstellenebene überschreibt jegliches Shaping in der Warteschlange. Wenden Sie daher die exakte Übertragung der Übertragungsrate nur auf das Multilink-Bündel an. |
Regeln umschreiben |
Ja |
Nein |
Rewrite-Bits werden während der Fragmentierung automatisch aus dem Paket in die Fragmente kopiert. Daher wird das, was Sie im Multilink-Bundle konfigurieren, auf den Fragmenten zu den konstituierenden Links übertragen. |
Virtuelle Channel-Gruppe |
Ja |
Nein |
Virtuelle Kanalgruppen werden durch Firewall-Filterregeln identifiziert, die nur vor dem Multilink-Bundle auf Pakete angewendet werden. Daher müssen Sie die Konfiguration der virtuellen Kanalgruppe nicht auf die konstituierenden Links anwenden. |
Siehe auch
Ermitteln der Ursachen für Jitter und Latenz im Multilink-Bundle
Problem
Beschreibung
Um Jitter und Latenz zu testen, senden Sie drei Ströme von IP-Paketen. Alle Pakete haben die gleichen IP-Prioritätseinstellungen. Nach der Konfiguration von LFI und CRTP erhöhte sich die Latenz selbst über eine nicht überlastete Verbindung. Wie können Sie Jitter und Latenzzeiten reduzieren?
Lösung
Gehen Sie wie folgt vor, um Jitter und Latenz zu reduzieren:
Stellen Sie sicher, dass Sie für jede konstituierende Verbindung eine Shaping-Rate konfiguriert haben.
Stellen Sie sicher, dass Sie keine Shaping-Rate auf der Link-Services-Schnittstelle konfiguriert haben.
Stellen Sie sicher, dass der konfigurierte Wert für die Shaping-Rate gleich der Bandbreite der physischen Schnittstelle ist.
Wenn die Shaping-Raten korrekt konfiguriert sind und der Jitter weiterhin besteht, wenden Sie sich an das Technical Assistance Center (JTAC) von Juniper Networks.
Ermitteln Sie, ob LFI und Load Balancing ordnungsgemäß funktionieren
Problem
Beschreibung
In diesem Fall haben Sie ein einzelnes Netzwerk, das mehrere Services unterstützt. Das Netzwerk überträgt Daten und verzögerungsempfindlichen Sprachverkehr. Stellen Sie nach der Konfiguration von MLPPP und LFI sicher, dass Sprachpakete mit sehr wenig Verzögerung und Jitter über das Netzwerk übertragen werden. Wie können Sie herausfinden, ob Sprachpakete als LFI-Pakete behandelt werden und das Load Balancing korrekt durchgeführt wird?
Lösung
Wenn LFI aktiviert ist, werden Datenpakete (Nicht-LFI) mit einem MLPPP-Header gekapselt und in Pakete einer bestimmten Größe fragmentiert. Die verzögerungsempfindlichen Sprachpakete (LFI) sind PPP-gekapselt und zwischen Datenpaketfragmenten verschachtelt. Warteschlangen und Load Balancing werden für LFI- und Nicht-LFI-Pakete unterschiedlich ausgeführt.
Um zu überprüfen, ob LFI korrekt ausgeführt wird, stellen Sie sicher, dass die Pakete fragmentiert und wie konfiguriert gekapselt sind. Nachdem Sie wissen, ob ein Paket als LFI-Paket oder als Nicht-LFI-Paket behandelt wird, können Sie überprüfen, ob das Load Balancing ordnungsgemäß durchgeführt wird.
Solution Scenario– Angenommen, zwei Geräte von Juniper Networks, R0 und R1, sind durch ein Multilink-Bündel lsq-0/0/0.0 verbunden, das zwei serielle Verbindungen se-1/0/0 aggregiert, und se-1/0/1. Auf R0 und R1 sind MLPPP und LFI auf der Link-Services-Schnittstelle aktiviert, und der Schwellenwert für die Fragmentierung ist auf 128 Byte festgelegt.
In diesem Beispiel haben wir einen Paketgenerator verwendet, um Sprach- und Datenströme zu erzeugen. Sie können die Paketerfassungsfunktion verwenden, um die Pakete auf der eingehenden Schnittstelle zu erfassen und zu analysieren.
Die folgenden zwei Datenströme wurden über das Multilink-Bundle gesendet:
100 Datenpakete à 200 Byte (größer als der Schwellenwert für die Fragmentierung)
500 Datenpakete à 60 Byte (kleiner als der Schwellenwert für die Fragmentierung)
Die folgenden zwei Sprachströme wurden über das Multilink-Bundle gesendet:
100 Sprachpakete à 200 Byte vom Quellport 100
300 Sprachpakete à 200 Byte vom Quellport 200
So bestätigen Sie, dass LFI und Load Balancing ordnungsgemäß ausgeführt werden:
In diesem Beispiel werden nur die wesentlichen Teile der Befehlsausgabe angezeigt und beschrieben.
Überprüfen Sie die Paket-Fragmentierung. Geben Sie im Betriebsmodus den
show interfaces lsq-0/0/0Befehl ein, um zu überprüfen, ob große Pakete korrekt fragmentiert sind.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning– Die Ausgabe zeigt eine Zusammenfassung der Pakete, die das Gerät im Multilink-Bundle durchlaufen. Überprüfen Sie die folgenden Informationen auf dem Multilink-Bundle:Die Gesamtzahl der transitierenden Pakete = 1000
Die Gesamtzahl der transitierenden Fragmente = 1100
Die Anzahl der fragmentierten Datenpakete = 100
Die Gesamtzahl der im Multilink-Bundle gesendeten Pakete (600 + 400) stimmt mit der Anzahl der Transitpakete (1000) überein, was bedeutet, dass keine Pakete verworfen wurden.
Die Anzahl der transitierenden Fragmente übersteigt die Anzahl der transitierenden Pakete um 100, was darauf hinweist, dass 100 große Datenpakete korrekt fragmentiert wurden.
Corrective Action– Wenn die Pakete nicht korrekt fragmentiert sind, überprüfen Sie die Konfiguration des Fragmentierungsschwellenwerts. Pakete, die kleiner als der angegebene Schwellenwert für die Fragmentierung sind, werden nicht fragmentiert.Überprüfen Sie die Paketkapselung. Um herauszufinden, ob ein Paket als LFI- oder Nicht-LFI-Paket behandelt wird, bestimmen Sie seinen Verkapselungstyp. LFI-Pakete sind PPP-gekapselt, und Nicht-LFI-Pakete werden sowohl mit PPP als auch mit MLPPP eingekapselt. PPP- und MLPPP-Verkapselungen haben unterschiedliche Overheads, was zu unterschiedlich großen Paketen führt. Sie können Paketgrößen vergleichen, um den Kapselungstyp zu bestimmen.
Ein kleines, unfragmentiertes Datenpaket enthält einen PPP-Header und einen einzelnen MLPPP-Header. In einem großen fragmentierten Datenpaket enthält das erste Fragment einen PPP-Header und einen MLPPP-Header, die aufeinanderfolgenden Fragmente jedoch nur einen MLPPP-Header.
PPP- und MLPPP-Kapselungen fügen einem Paket die folgende Anzahl von Bytes hinzu:
PPP-Kapselung fügt 7 Byte hinzu:
4 Byte Header + 2 Byte Frame-Check-Sequenz (FCS) + 1 Byte, das sich im Leerlauf befindet oder ein Flag enthält
Bei der MLPPP-Kapselung werden zwischen 6 und 8 Byte hinzugefügt:
4 Byte PPP-Header + 2 bis 4 Byte Multilink-Header
Abbildung 2 zeigt den Mehraufwand, der den PPP- und MLPPP-Headern hinzugefügt wurde.
Abbildung 2: PPP- und MLPPP-Header
Bei CRTP-Paketen sind der Kapselungs-Overhead und die Paketgröße sogar kleiner als bei einem LFI-Paket. Weitere Informationen finden Sie unter Beispiel: Konfigurieren des komprimierten Echtzeittransportprotokolls.
Tabelle 3 zeigt den Kapselungsaufwand für ein Datenpaket und ein Sprachpaket mit jeweils 70 Byte. Nach der Kapselung ist die Größe des Datenpakets größer als die Größe des Sprachpakets.
Tabelle 3: PPP- und MLPPP-Verkapselungs-Overhead Pakettyp
Verkapselung
Anfängliche Paketgröße
Overhead für die Kapselung
Paketgröße nach der Verkapselung
Sprachpaket (LFI)
KAUFKRAFTPARITÄT
70 Byte
4 + 2 + 1 = 7 Byte
77 Byte
Datenfragment (Nicht-LFI) mit kurzer Sequenz
MLPPP
70 Byte
4 + 2 + 1 + 4 + 2 = 13 Byte
83 Byte
Datenfragment (Nicht-LFI) mit langer Sequenz
MLPPP
70 Byte
4 + 2 + 1 + 4 + 4 = 15 Byte
85 Byte
Geben Sie im Betriebsmodus den
show interfaces queueBefehl ein, um die Größe des übertragenen Pakets in jeder Warteschlange anzuzeigen. Teilen Sie die Anzahl der übertragenen Bytes durch die Anzahl der Pakete, um die Größe der Pakete zu ermitteln und den Kapselungstyp zu bestimmen.Überprüfen Sie das Load Balancing. Geben Sie im Betriebsmodus den Befehl für das Multilink-Bundle und die zugehörigen Links ein, um zu
show interfaces queuebestätigen, ob das Load Balancing für die Pakete entsprechend ausgeführt wird.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning– Die Ausgabe dieser Befehle zeigt die Pakete, die in jeder Warteschlange der Verbindungsserviceschnittstelle und den zugehörigen Verbindungen übertragen und in die Warteschlange gestellt werden. Tabelle 4 zeigt eine Zusammenfassung dieser Werte. (Da die Anzahl der übertragenen Pakete der Anzahl der Pakete in der Warteschlange auf allen Verbindungen entsprach, werden in dieser Tabelle nur die Pakete in der Warteschlange angezeigt.)Tabelle 4: Anzahl der in einer Warteschlange übertragenen Pakete Pakete in der Warteschlange
Bundle lsq-0/0/0.0
Konstituierender Link se-1/0/0
Konstituierender Link se-1/0/1
Erklärung
Pakete auf Q0
600
350
350
Die Gesamtzahl der Pakete, die die konstituierenden Links durchlaufen (350+350 = 700), übersteigt die Anzahl der Pakete (600), die im Multilink-Bundle in der Warteschlange stehen.
Pakete auf Q2
400
100
300
Die Gesamtzahl der Pakete, die die konstituierenden Links durchlaufen, entsprach der Anzahl der Pakete im Bündel.
Pakete auf Q3
0
19
18
Die Pakete, die Q3 der konstituierenden Links durchlaufen, sind für Keepalive-Nachrichten vorgesehen, die zwischen konstituierenden Links ausgetauscht werden. Somit wurden in Q3 des Bundles keine Pakete gezählt.
Überprüfen Sie im Multilink-Bundle Folgendes:
Die Anzahl der Pakete in der Warteschlange entspricht der Anzahl der übertragenen Pakete. Wenn die Zahlen übereinstimmen, wurden keine Pakete verworfen. Wenn mehr Pakete in die Warteschlange gestellt als übertragen wurden, wurden Pakete verworfen, da der Puffer zu klein war. Die Puffergröße auf den Komponentenverbindungen steuert die Überlastung in der Ausgabephase. Um dieses Problem zu beheben, erhöhen Sie die Puffergröße auf den Komponentenverbindungen.
Die Anzahl der Pakete, die Q0 übertragen (600), entspricht der Anzahl der großen und kleinen Datenpakete, die im Multilink-Bundle empfangen wurden (100+500). Wenn die Zahlen übereinstimmen, haben alle Datenpakete Q0 korrekt durchlaufen.
Die Anzahl der Pakete, die Q2 im Multilink-Bundle durchlaufen (400), entspricht der Anzahl der Sprachpakete, die im Multilink-Bundle empfangen wurden. Wenn die Zahlen übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt durchlaufen.
Überprüfen Sie auf den Komponenten-Links Folgendes:
Die Gesamtzahl der Pakete, die Q0 übertragen (350+350), entspricht der Anzahl der Datenpakete und Datenfragmente (500+200). Wenn die Zahlen übereinstimmen, haben alle Datenpakete nach der Fragmentierung Q0 der konstituierenden Links korrekt durchlaufen.
Die Pakete durchliefen beide Komponentenverbindungen, was darauf hindeutet, dass das Load Balancing für Nicht-LFI-Pakete korrekt durchgeführt wurde.
Die Gesamtzahl der Pakete, die Q2 (300+100) über konstituierende Links übertragen, entspricht der Anzahl der empfangenen Sprachpakete (400) im Multilink-Bundle. Wenn die Zahlen übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt durchlaufen.
LFI-Pakete vom Quellport
100transitiertse-1/0/0und LFI-Pakete vom Quellport200transitiertse-1/0/1. Somit wurden alle LFI (Q2)-Pakete basierend auf dem Quellport gehasht und korrekt über beide Verbindungen weitergeleitet.
Corrective Action– Wenn die Pakete nur eine Verbindung durchlaufen haben, führen Sie die folgenden Schritte aus, um das Problem zu beheben:Bestimmen Sie, ob die physische Verbindung (betrieblich) oder
down(nicht verfügbar) istup. Eine nicht verfügbare Verbindung weist auf ein Problem mit dem PIM, dem Schnittstellenport oder der physischen Verbindung hin (Link-Layer-Fehler). Wenn die Verbindung funktioniert, fahren Sie mit dem nächsten Schritt fort.Stellen Sie sicher, dass die Klassifizierer für Nicht-LFI-Pakete korrekt definiert sind. Stellen Sie sicher, dass Nicht-LFI-Pakete nicht so konfiguriert sind, dass sie in Q2 in die Warteschlange gestellt werden. Alle Pakete, die in Q2 eingereiht werden, werden als LFI-Pakete behandelt.
Stellen Sie sicher, dass sich mindestens einer der folgenden Werte in den LFI-Paketen unterscheidet: Quelladresse, Zieladresse, IP-Protokoll, Quellport oder Zielport. Wenn für alle LFI-Pakete dieselben Werte konfiguriert sind, werden die Pakete alle auf denselben Datenstrom gehasht und durchlaufen dieselbe Verbindung.
Verwenden Sie die Ergebnisse, um das Load Balancing zu überprüfen.
Ermitteln Sie, warum Pakete auf einer PVC zwischen einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters abgelegt werden.
Problem
Beschreibung
Sie konfigurieren einen permanenten virtuellen Circuit (PVC) zwischen T1-, E1-, T3- oder E3-Schnittstellen auf einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters, und Pakete werden verworfen und der Ping schlägt fehl.
Lösung
Wenn das Gerät eines Drittanbieters nicht die gleiche FRF.12-Unterstützung wie das Gerät von Juniper Networks hat oder FRF.12 auf andere Weise unterstützt, verwirft die Geräteschnittstelle von Juniper Networks auf der PVC möglicherweise ein fragmentiertes Paket, das FRF.12-Header enthält, und zählt es als "Policed Discard".
Um dieses Problem zu umgehen, konfigurieren Sie Multilink-Bundles auf beiden Peers und konfigurieren Sie Schwellenwerte für die Fragmentierung auf den Multilink-Bundles.