Fehlerbehebung bei Leistungsproblemen mit RPD DOCSIS-Durchsatz

Einleitung

In diesem Dokument wird die Fehlerbehebung bei Leistungsproblemen mit Cisco Remote PHY-Geräten (RPD, Remote PHY Device) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• RPD
• Cisco Converged Broadband Router (cBR)-8
• DOCSIS-Spezifikation (Data Over Cable Service Interface Specification)

Verwendete Komponenten

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Das in diesem Artikel behandelte Szenario beinhaltet eine RPD, die von Cisco cBR-8 als Converged Cable Access Platform (CCAP) bereitgestellt wird. Das Precision Time Protocol (PTP) dient zur Synchronisierung einer externen primären Uhr mit cBR-8 und RPD, die als sekundäre Uhr fungieren. Weitere Informationen zum PTP-Design in dieser Umgebung finden Sie unter PTP-Designempfehlungen für R-PHY-Netzwerke.

Dies ist keine umfassende Liste von Schritten, um Leistungsprobleme mit RPD zu beheben, obwohl es ein guter Anfang ist, um das Problem zu isolieren.

Fehlerbehebung

Wenn Sie bei der RPD-Bereitstellung eine Leistungsminderung feststellen und eine erste Fehlerbehebung durchführen möchten, ist nicht klar, wo Sie anfangen sollen.

In diesem Abschnitt werden einige häufige Probleme beschrieben, die die mögliche Ursache für die Leistungsprobleme der RPD sein können.

Verspätete MAP-Nachrichten

Eine MAP-Meldung (Spät Upstream Bandwidth Allocation Map) (MAP) tritt auf, wenn ein Modem zu einem bestimmten Zeitpunkt eine MAP-Meldung empfängt, nachdem die in der Meldung beschriebenen Zeitschlitze bereits eingetreten sind.  Das Modem kann diese MAP-Nachricht nicht verwenden und kann daher keinen Datenverkehr mit den zugewiesenen Berechtigungen senden.

Verspätete MAPs können zu einer Verringerung der Upstream-Datenverkehrsraten sowie der Downstream-TCP-Datenverkehrsraten führen, da Upstream-ACKs verzögert werden. Wenn es genügend verspätete MAPs gibt, können Modems keine Wartungsarbeiten an der Station durchführen und offline gehen.

Ein weiteres Symptom können Paketverluste sein, wenn Sie eine Ping-Doku <MAC_ADDR> von der cBR-8 an ein Modem senden, das an eine Remotedesktop-Verbindungsrichtlinie angeschlossen ist.

Mit Remote PHY (R-PHY) sendet der cBR-8 MAP-Nachrichten an die Modems in einem Downstream External PHY Interface (DEPI)-Tunnel und an die RPD in einem Upstream External PHY Interface (UEPI)-Tunnel. Diese Nachrichten weisen ein höheres QoS-Zeichen (Quality of Service) mit einem DSCP-Wert (Differentiated Services Code Point) von 46 (Express Forwarding - EF) auf.

Wenn eine MAP-Nachricht, die für die RPD bestimmt ist, im CIN verworfen wird, kann die RPD diese Minislots nicht verwenden und zählt sie als "unmapped" (nicht zugeordnet). Wenn die MAP-Nachricht zu spät bei der RPD ankommt, zählt sie zunächst die Minislots als nicht zugeordnet und erhöht dann, nachdem sie die späte MAP empfangen hat, die Anzahl der späten Minislots.

Frühe MAPs sind ebenfalls möglich, treten aber in der Regel nur auf, wenn die PTP-Uhr entweder im cBR-8 oder im RPD ausgeschaltet ist.

Überlappende MAPs können auftreten, wenn MAP-Nachrichten aus der Sequenz herauskommen, aber mit nur 2 ms Frequenz ist dies in der Regel kein Problem. Die tatsächliche Anzahl der Minislots in einer MAP-Nachricht basiert auf der Minislot-Konfiguration für jeden Upstream-Kanal. Wenn ein Upstream zwei Ticks pro Minislot verwendet (beliebt bei 6,4 MHz SC-QAM), hat ein 2 ms MAP 160 Minislots.

Um zu überprüfen, ob Sie verspätete MAP-Meldungen auf der RPD erhalten, führen Sie diese Befehle aus, um auf die RPD-Konsole zuzugreifen. Führen Sie dann den Befehl show upstream map counter <rf port> <channel> mehrmals aus, und überprüfen Sie, ob der Zähler "Discarded minislots (late maps)" ansteigt:

cbr8# ssh <RPD_IP_ADDR> -l admin
R-PHY>enable
R-PHY#show upstream map counter 0 0
Map Processor Counters
==============================================
Mapped minislots                  :     553309
Discarded minislots (chan disable):          0
Discarded minislots (overlap maps):          0
Discarded minislots (early maps)  :          0
Discarded minislots (late maps)   :          0 <= check if the counter increases
Unmapped minislots                :          0
Last mapped minislot              :   21900956

Hinweis: Jedes Mal, wenn Sie den Befehl show upstream map counter ausführen, werden alle Zähler auf 0, aber Last mapped minislot zurückgesetzt

Tipp: Ab RPD Version 6.x können Sie den Befehl show tech-support ausführen, der mehrere Vorkommen von show upstream map counter und anderen Befehlen erfasst und somit für den Vergleich von Zählern nützlich ist.

Wenn Sie RPD Software Version 5.x oder niedriger ausführen, können Sie den Befehl show tech mit dem hier verfügbaren Skript ausführen: Capture show tech on rpd oder eingeschränkter Befehl auf beiden RPD, Supervisor.

Die verlinkte Seite enthält Anleitungen zur Installation des Skripts und Verwendungsbeispiele, an deren Ende die Datei Script-Readme.tar zum Download verfügbar ist. Diese Datei enthält das Skript sh_tech_rpd.tcl und die Datei sh_tech_rpd-README.txt mit den Anweisungen und Verwendungsbeispielen.

Das Skript verfügt über eine Option (-c), um einen zusätzlichen Satz von Befehlen zu sammeln, die in einer Textdatei aufgelistet sind. Beide Befehle, die auf der RPD selbst und auf dem cBR-8 Supervisor ausgegeben werden, werden akzeptiert (alle Verfahren, die in dem zuvor erwähnten Link und der Readme-Datei erläutert werden).

Diese Funktion verwendet dieses Skript interessanterweise auch in RPD-Versionen, die den Befehl show tech-support enthalten.

Mögliche Ursache 1. CIN-Verzögerung, Latenz, Jitter

Das Converged Interconnect Network (CIN), das den CCAP-Core mit RPDs verbindet, kann zu Verzögerungen führen, die im MAP-Timer berücksichtigt werden müssen. Bei einer Änderung des CIN, z. B. durch Hinzufügen eines weiteren Routers, haben Sie möglicherweise eine höhere Verzögerung eingeführt.

Der MAP Advance Timer wird vom CCAP verwendet, um späte MAP-Nachrichten zu vermeiden. Dieser Timer basiert auf Mikrosekunden (µs) und kann vom Bediener statisch pro Kabelschnittstelle konfiguriert oder dynamisch vom cBR-8 berechnet werden.

Der dynamische Wert ist die Summe der Downstream-Zeit-Interleaf (680 µs mit SC-QAM mit 256-QAM), Modem MAP Verarbeitungsverzögerung (600 µs), CCAP interne Netzwerk-Verzögerung (300 µs), MAP Advance Safety Value (standardmäßig 1000 µs) und maximale Modem-Zeit-Offset (basierend auf den meisten entfernten Modem).

Bei R-PHY wird die interne CCAP-Verzögerung nun durch eine Netzwerk-Verzögerung ersetzt, die standardmäßig 500 µs beträgt. Unter Berücksichtigung des CIN-Designs kann dieser Wert größer als der Standardparameter sein und sich im Laufe der Zeit ändern.

Die MAP-Weiterleitungswerte für einen Upstream können mit dem folgenden Befehl angezeigt werden:

cbr8#show controllers upstream-Cable 2/0/5 us-channel 0 cdm-ump
<output omitted>
nom_map_adv_usecs 2899, max_map_adv_usecs 4080 mtn_map_adv 8080
map_adv_alg 1 dyn_map_adv_safety 1000 max_plant_delay 1800
cm_map_proc 600 intlv_delay 680 network_delay 500 max_tmoff 119
<output omitted>

MAPadvance = map_adv_safety (1000) + cm_map_proc (600) + intlv_delay (680) + network_delay (500) + max_tmoff (119) = 2899 μ s.

Wenn der Abstand zwischen cBR-8 und RPD in Kombination mit den CIN-Geräten den Standardwert von 500 µs überschreitet, sind späte MAP-Meldungen möglich.

Es gibt zwei Methoden, mit dem Standardparameter für die Netzwerkverzögerung umzugehen, wenn dies ein Problem darstellt. Beide Methoden werden nach RPD auf dem cBR-8 festgelegt:

• Konfigurieren Sie die Verzögerung statisch.
• Stellen Sie die cBR-8 so ein, dass die Verzögerung regelmäßig gemessen und angepasst wird.

Die Netzwerkverzögerung kann auf dem cBR-8 statisch gemäß RPD konfiguriert werden, wie hier gezeigt:

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay static <CIN_delay_in_us>

Für dynamische Netzwerkverzögerungen stützt sich cBR-8 auf eine Latenzmessfunktion namens DEPI Latency Measurement (DLM), die die unidirektionale Verzögerung im Downstream-Pfad bestimmt.

Der cBR-8 sendet ein DLM-Paket mit seinem Zeitstempel aus, dann markiert die RPD seinen Zeitstempel auf dem DLM-Paket, wenn es empfangen wird, und leitet es zurück an den cBR-8.

Beachten Sie, dass Cisco die erforderliche Option unterstützt, bei der die RPD das Paket kennzeichnet, das der Eingangsschnittstelle am nächsten ist, nicht aber den Ausgang.

Der cBR-8 nimmt den Durchschnitt der letzten 10 DLM-Werte und verwendet ihn als Netzwerk-Verzögerungswert in der MAP-Vorausberechnung. Die Zeitstempel sowohl des cBR-8 als auch der RPD basieren auf den PTP-Referenztakten.

Warnung: Wenn PTP instabil ist, sind es auch die DLM-Werte und letztendlich der MAP-Timer für den Vorlauf.

DLM ist standardmäßig deaktiviert und kann mit dem Befehl network-delay dlm <seconds> aktiviert werden. Nach der Aktivierung wird ein DLM-Paket entsprechend dem konfigurierten Wert regelmäßig an die RPD gesendet.

Es gibt auch eine Nur-Maß-Option, die hinzugefügt werden kann, die lediglich die CIN-Verzögerung ohne Anpassung des Netzwerk-Verzögerungswertes misst.

Es wird empfohlen, DLM mindestens im Parameter für die Nur-Messung zu aktivieren, um die CIN-Verzögerung zu überwachen.

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay dlm <interval_in_seconds> [measure-only]

Usage:

cbr8#show cable rpd a0f8.496f.eee2 dlm
DEPI Latency Measurement (ticks) for a0f8.496f.eee2
  Last Average DLM:              481
  Average DLM (last 10 samples): 452
  Max DLM since system on:       2436
  Min DLM since system on:       342
  Sample #     Latency (usecs)
  x------------x------------
  0            52
  1            41
  2            48
  3            41
  4            41
  5            44
  6            40
  7            45
  8            44
  9            41

Weitere Informationen zu dieser Funktion finden Sie hier: DEPI-Latenzmessung

Die MAP Advance Safety kann auch manuell in der Kabelschnittstellenkonfiguration geändert werden (Standardwerte sind 1000 µs für den Sicherheitsfaktor und 18000 µs für den Max Map Advance):

cbr8#conf t
cbr8(config)#interface Cable1/0/0
cbr8(config-if)# cable map-advance dynamic 1000 18000

OR (if a mac-domain profile is used)

cbr8#conf t
cbr8(config)# cable profile mac-domain RPD
cbr8(config-profile-md)# cable map-advance dynamic 1000 18000

Vorsicht: Sehr kurze CIN-Verzögerungen können auch zu verspäteten MAP-Nachrichten führen.

Beim Upstream-DOCSIS-Datenverkehr wurden Probleme beobachtet, wenn der MAP-Timer für den Vorlauf unter 2500 µs liegt.

Einige Modems können länger dauern, um MAP-Nachrichten zu verarbeiten, und diese zusätzliche Verzögerung kann zu verspäteten MAP-Nachrichten für diese Modems führen (die RPD zeigt möglicherweise keine verspäteten MAP-Zählungen an, wenn sie die Nachricht rechtzeitig erhalten konnte).

Ein niedriger MAP-Advance-Timer ist mit sehr niedrigen DLM-Werten oder mit einer geringen manuellen Netzwerkverzögerung oder einer erweiterten MAP-Sicherheitskonfiguration möglich. Die Werte für die Netzwerkverzögerung in der MAP-Vorausberechnung können bis zu 30 µs betragen (auch wenn der DLM-Durchschnitt niedriger ist).

Es wird empfohlen, entweder die DLM-Option "Measure-only" zu verwenden oder den Sicherheitsfaktor für den dynamischen MAP-Vorschub zu erhöhen, bis der MAP-Vorschub-Timer mehr als 2500 µs beträgt.

Mögliche Ursache 2. Softwarefehler

Um zu überprüfen, ob ein Softwarefehler einen Synchronisierungsfehler verursacht, wird empfohlen, eine Serviceanfrage bei Cisco zu stellen, um den spezifischen Fall weiter zu untersuchen.

Die Lösung für den Fall, dass Sie einen Software-Defekt haben, ist normalerweise ein Software-Upgrade auf eine der Versionen, die den Fix enthält. Da ein Kompatibilitätsbezug zwischen cBR-8 und RPD-Softwareversionen besteht, ist es wichtig, für beide Geräte die richtige Version zu wählen.

Um Ihnen bei der Auswahl des richtigen Cisco IOS® XE für jede RPD-Software zu helfen, finden Sie die Kompatibilitäten der Softwareversionen zwischen cBR-8 und RPD in den Cisco Remote PHY-Installations- und Upgrade-Anleitungen.

In dieser Tabelle finden Sie eine Zusammenfassung der Softwareversionskompatibilität zwischen cBR-8 und RPD, mit den zum Zeitpunkt der Erstellung verfügbaren Softwareversionen:

Versionskompatibilität zwischen Cisco cBR-8 und Cisco RPD
Cisco cBR-8 Version	Kompatible RPD-Version
Cisco IOS® XE Everest 16.6.x	Cisco 1x2 RPD-Software 2.x
Cisco IOS® XE Fuji 16.7.x	Cisco 1x2 RPD-Software 3.x
Cisco IOS® XE Fuji 16.8.x	Cisco 1x2 RPD-Software 4.x
Cisco IOS® XE Fuji 16.9.x	Cisco 1x2 RPD-Software 5.x
Cisco IOS® XE Gibraltar 16.10.1c	Cisco 1x2 RPD-Software 6.1, 6.2, 6.3
Cisco IOS® XE Gibraltar 16.10.1d	Cisco 1x2 RPD-Software 6.4, 6.5, 6.7
Cisco IOS® XE Gibraltar 16.10.1f	Cisco 1x2 RPD-Software 6.6, 6.7
Cisco IOS® XE Gibraltar 16.10.1g	Cisco 1x2 RPD-Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1	Cisco 1x2 RPD-Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1w	Cisco 1x2 RPD-Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1x	Cisco 1x2 RPD-Software 7.6, 7.7
Cisco IOS® XE Gibraltar 16.12.1y	Cisco 1x2 RPD-Software 7.8, 7.8.1, 8.2
Cisco IOS® XE Gibraltar 16.12.1z	Cisco 1x2 RPD-Software 8.3, 8.4, 8.5
Cisco IOS® XE Gibraltar 17.2.1	Cisco 1x2 RPD-Software 8.1, 8.2, 8.3, 8.4, 8.5

Upstream-Latenz

Wie im vorherigen Abschnitt erläutert, können lange CIN-Verzögerungen zu verspäteten MAP-Nachrichten führen und mit der Verlängerung des MAP-Zeitgebers behoben werden. Dies führt wiederum zu einer längeren Anfrageverzögerung, was zu einer höheren Upstream-Latenz führt.

Da stetige Upstream-Datenverkehrsflüsse "piggy-back"-Anforderungen verwenden, kann der Upstream-Datenverkehrsgeschwindigkeitstest normal aussehen, und auch Sprachdatenflüsse mit Unsolicited Grant Service (UGS) werden nicht beeinträchtigt, da keine Anforderungen erforderlich sind.

Jedoch können die Geschwindigkeiten des TCP-Downstream-Datenverkehrs reduziert werden, da keine zeitnahen ACKs für den Upstream vorhanden sind. Verzögerungen bei der Verarbeitung und Warteschlangenzuweisung lassen sich zwar auf dem CIN beheben, es ist jedoch unwahrscheinlich, dass die Signale über eine bestimmte Entfernung schneller übertragen werden.

Cisco hat DOCSIS Predictive Scheduling (DPS) entwickelt, um die Verzögerung bei der Anforderung von R-PHY-Anwendungen durch längere CIN-Verzögerungen zu verringern. DPS gewährt Modems proaktiv Gewährungen auf Basis der bisherigen Nutzung, um Verzögerungen bei der Anforderung zu minimieren.

DPS ist eine Prestandard-Planungsmethode, ähnlich dem Proactive Grant Service (PGS), der in der kürzlich veröffentlichten Low Latency DOCSIS (LLD)-Spezifikation beschrieben wird.  DPS kann jedoch pro Schnittstelle aktiviert werden und wird auf alle bestmöglichen Upstream-Service-Flows angewendet. PGS wird als Service-Flow-Typ auf den Datenverkehr angewendet, sodass Änderungen an der Modem-Konfigurationsdatei erforderlich sind.

DPS kann mit dem folgenden Schnittstellenbefehl aktiviert werden: cbr8(config-if)#cable upstream dps

Obwohl DPS verfügbar ist, seitdem die R-PHY-Unterstützung dem cBR-8 hinzugefügt wurde, ist dies derzeit keine offiziell unterstützte Funktion. DPS kann jedoch einen langsamen TCP-Downstream-Durchsatz im Zusammenhang mit verzögerten ACKs effektiv beheben.

Out-of-Order Layer 2 Tunneling Protocol (L2TP)-Pakete

Geben Sie an der RPD-Konsole diesen Befehl mehrmals ein, um zu überprüfen, ob die Zähler "SeqErr-pkts" und "SeqErr-sum-pkts" positiv sind und zunehmen. Dies ist ein Hinweis auf L2TP-Pakete außerhalb der Reihenfolge:

R-PHY# show downstream channel counter dpmi
Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 00430000   328        22770      0           1         
0    1       4390912    / 00430000   25074      1179672    0           1         
0    2       4390912    / 00430000   6022168    271459412  0           1         
0    3       4390912    / 00430000   0          0          0           0      

Mögliche Ursache 1. Lastausgleich

Unter bestimmten Bedingungen, wie z. B. einer Überlastung der Verbindungen im CIN, kann der Lastenausgleich zum Problem von Paketen beitragen, die am Ziel in einer ungeordneten Reihenfolge empfangen werden.

Wenn Sie die Möglichkeit haben, zu überprüfen, ob der Lastenausgleich dieses Problem auslöst, können Sie testen, ob ein einzelner Pfad durchgesetzt wird, in dem der Lastenausgleich konfiguriert ist. Wenn dies das Problem mit nicht in Ordnung befindlichen Paketen löst, erhalten Sie die Bestätigung des Auslösers und können die Ursache in Ihrem Netzwerk weiter untersuchen.

Mögliche Ursache 2. Paketverlust

1. Überprüfen Sie mithilfe des Befehls show interface (siehe unten) die cBR-8-Zähler der DPIC-Kartenschnittstelle, an der die RPD angeschlossen ist, auf größere Fehler und Auslassungen.

cbr8#sh run | s cable rpd SHELF-RPD0
cable rpd SHELF-RPD0
 description SHELF-RPD0
 identifier a0f8.496f.eee2
[…]
 core-interface Te6/1/2
[…]
cbr8#show interface Te6/1/2
TenGigabitEthernet6/1/2 is up, line protocol is up
  Hardware is CBR-DPIC-8X10G, address is cc8e.7168.a27e (bia cc8e.7168.a27e)
  Internet address is 10.27.62.1/24
  MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 90/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 10000Mbps, link type is force-up, media type is SFP_PLUS_10G_SR
  output flow-control is on, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:05, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/375/0/22 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1002000 bits/sec, 410 packets/sec
  5 minute output rate 3535163000 bits/sec, 507528 packets/sec
     88132313 packets input, 26831201592 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 229326 multicast, 0 pause input
     179791508347 packets output, 164674615424484 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     13896 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

2. Prüfen Sie auf der RPD-Seite, ob an den Schnittstellen und Downstream-Zählern Fehler, verworfene und fehlerhafte Pakete vorhanden sind.

R-PHY#show interface info
eth0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E4
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:44034 (43.0 KiB)
          Memory:1ae2000-1ae2fff
vbh0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E2
          inet addr:10.7.62.7  Bcast:10.7.62.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1174200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:593404 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90888838 (86.6 MiB)  TX bytes:52749774 (50.3 MiB)
vbh1      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E3
          inet6 addr: fe80::a2f8:49ff:fe6f:eee3/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2438 (2.3 KiB)

R-PHY#show downstream channel counter

------------------- Packets counter in TPMI -------------------

Level     Rx-pkts    Rx-sum-pkts
Node Rcv  4673022    2108792873
Depi Pkt  1696       774495

Port Chan SessionId(dec/hex)    Rx-pkts    Rx-sum-pkts
DS_0 0    4390912    /0x00430000 49032      22125274
DS_0 1    4390913    /0x00430001 49025      22116541
[…]
US_0 0    13893632   /0x00D40000 12193      5502543
US_0 1    13893633   /0x00D40001 12193      5501739
[…]

Port      Rx-pkts    Rx-sum-pkts Drop-pkts  Drop-sum-pkts
DS_0      3095440    1396529318  0          0
US_0      49215      22207507    0          0
US_1      0          4679        0          0

------------------- Packets counter in DPMI -------------------

Field        Pkts       Sum-pkts
Dpmi Ingress 12275995   1231753344
Pkt Delete   0          0
Data Len Err 0          0

Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 0x00430000   75         130496     0           1
0    1       4390912    / 0x00430000   15657      7208826    0           1
0    2       4390912    / 0x00430000   3181212    1431951867 0           1
0    3       4390912    / 0x00430000   0          0          0           0
[…]

------------------- Packets counter in DPS -------------------

Chan Tx-packets Tx-octets  Drop-pkts  Tx-sum-pkts Tx-sum-octs Drop-sum-pkts
0    50316      3273636    0          22126173    1439340721  0
1    50311      3272896    0          22117442    1438506648  0
2    50311      3272640    0          22121500    1438772715  0
3    50309      3272640    0          22122038    1438807607  0
[…]

3. Überprüfen Sie die Downstream-InterLaken-Zähler mehrmals, um festzustellen, ob Fehler vorliegen und ob die Zähler ansteigen. Um dies zu tun, müssen Sie die Line Card-Konsolenschnittstelle wie hier gezeigt eingeben.

cbr8#request platform software console attach 6/0
#
# Connecting to the CLC console on 6/0.
# Enter Control-C to exit the console connection.
#
Slot-6-0>enable
Slot-6-0#
Slot-6-0#test jib4ds show ilkstat ?
  <0-3>  ILK Link (0-BaseStar0, 1-BaseStar1, 2-Cpu0, 3-Cpu1)

Slot-6-0#test jib4ds show ilkstat 0
Send Show-ilkstat IPC to CDMAN...Wait for output

Slot-6-0#
Jib4DS InterLaken Stats for BaseStar 0:
                    RX-Packets             RX-Bytes            TX-Packets             TX-Bytes
HUB Stats:         10425879607       14415939325556              75237425           8249683443
Chan    0:             4714787            360160866                109750             36594720
Chan    1:         10254597081       14397444921888                     0                    0
Chan    3:               63828             17214818                     0                    0
Chan    5:           166503829          18117169182              75127675           8213088761
PRBS  Err:                   0                    0                     0                    0
CRC32 Err:                   0                    0                     0                    0
CRC24 Err:                          0
Test-pattern-err:                   0

ILK Error log: ptr 0
Idx      Err1     Err2      Rst     Gtx0     Gtx1     Gtx2     Gtx3

Slot-6-0#

4. Nehmen Sie ein mit dieser RPD verbundenes Modem (nur DS-Kanäle verbunden), und senden Sie Pakete (z. B. Pings) an diese RPD, um zu überprüfen, ob gesendete Pakete mit dem eingekoppelten Downstream-Fluss auf den Zählern des JIB-Moduls übereinstimmen. Stellen Sie sicher, dass DS JIB alle DS-Datenpakete für den DEPI-Frame auf der Linecard-Konsole gesendet hat. In dieser Ausgabe sehen Sie, wie die Paketsequenznummer einer Modem-Service-Flow-Ausgabe angezeigt wird. Diese Sequenznummer wird für jedes gesendete Datenpaket erhöht.

Slot-6-0#show cable modem 2cab.a40c.5ac0 service-flow verbose | i DS HW Flow
DS HW Flow Index			: 12473
Slot-6-0#test jib4ds show flow 12473
Send Show-FLOW IPC to CDMAN flow 12473 seg 6...Wait for output

Slot-6-0#
Jib4DS Show Flow: [Bufsz 4400]: HW Flow id:12473 [0x30b9] for segment 0
Valid        : TRUE
DSID         :            3 [       0x3]
Priority     :            0
Bonding Group:           62 [      0x3e]
Channel      :        65535 [    0xffff]
DS-EH        :            3 [       0x3]
Data Prof 1  :            0 [         0]
Data Prof 2  :            0 [         0]
No Sniff Enabled.

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 8

Senden Sie einige Pings von der cBR-8-Befehlszeile an dieses Modem. Dies geschieht in einem anderen Fenster:

cbr8#ping 10.0.0.3 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/27 ms
cbr8#

Überprüfen Sie das Delta nach dem Test:

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 108

Berechnen Sie das Delta nach dem Test: Der Zähler ist 16 Bit vorzeichenlos. Wenn der Zähler sich also bewegt, muss das Delta mit der folgenden Formel berechnet werden:

(Initial Sequence Number + Number of Packets Sent) % 65536

Beispiel:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




(50967+1000000)%65536 = 2391 <== Good, no packet was dropped before DEPI frame.

Als Folge der Art der Drops kann das Problem im CIN (z.B. Bottleneck Links, Kollisionen, CRC Fehler) liegen, die im CIN-Netz zwischen cBR-8 und RPD weiter untersucht werden müssen. Wenn in den Nummern 3 und 4 stattdessen Versäumnisse festgestellt werden, wird empfohlen, Cisco zur weiteren Untersuchung des cBR-8 hinzuzuziehen.

PTP-Verlust oder regelmäßige Freigabe

Wie Sie wahrscheinlich wissen, ist PTP für den normalen RPD-Betrieb unerlässlich. Aus diesem Grund müssen PTP-Pakete in QoS eine hohe Priorität haben, und PTP-Paketverluste sind kein gutes Vorzeichen.

Auf der RPD-Konsole können Sie die PTP-Statistiken anzeigen und überprüfen, ob die Zähler "DELAY REQUEST" und "DELAY RESPONSE" genau übereinstimmen. Wenn Sie stattdessen eine große Lücke sehen, kann dies ein Indikator für PTP-Ausfälle im Netzwerk sein:

R-PHY#show ptp clock 0 statistics
 AprState    4  :
           2@0-00:06:25.877          1@0-00:06:16.234          0@0-00:03:42.629
           4@0-00:03:23.428
ClockState  5  :
           5@0-00:07:02.932          4@0-00:06:59.145          3@0-00:06:55.657
           2@0-00:06:26.657          1@0-00:06:25.834
BstPktStrm  1  :
           0@0-00:03:21.014
SetTime     1  :
  1000000000@0-00:03:24.776
StepTime    1  :
  -560112697@0-00:05:39.401
AdjustTime  44 :
          -8@0-00:52:03.776         -5@0-00:51:02.776          4@0-00:50:01.776
          -6@0-00:49:00.776         11@0-00:47:59.776          1@0-00:45:57.776
           5@0-00:44:56.776         -7@0-00:43:55.776        -22@0-00:42:54.776
streamId  msgType           rx          rxProcessed     lost        tx
0        SYNC              47479       47473           0           0
0        DELAY REQUEST     0           0               0           47473
0        P-DELAY REQUEST   0           0               0           0
0        P-DELAY RESPONSE  0           0               0           0
0        FOLLOW UP         0           0               0           0
0        DELAY RESPONSE    47473       47473           0           0
0        P-DELAY FOLLOWUP  0           0               0           0
0        ANNOUNCE          2974        2974            0           0
0        SIGNALING         34          34              0           32
0        MANAGEMENT        0           0               0           0
  TOTAL                    97960       97954           0           47505

Hinweis: Auf cBR-8 hat PTP die höchste Priorität für die Uhr, d. h., dass es nach der Konfiguration auch für RF-Line Cards verwendet wird. Daher würde eine unzuverlässige Quelle zu Problemen im gesamten Chassis führen.

Weitere Informationen zur Konfiguration der PTP-Uhr und zur Fehlerbehebung finden Sie im Artikel PTP Design Recommendations For R-PHY Networks (PTP-Designempfehlungen für R-PHY-Netzwerke).

Überlastetes CIN

Das CIN kann als Erweiterung der Kontrollebene des CCAP-Kerns angesehen werden. Wenn also 1000 Mbit/s DOCSIS- und Videodatenverkehr im Downstream für eine bestimmte RPD vorhanden sind, muss im CIN ein so großer Teil der Kapazität zugewiesen werden, zuzüglich einer zusätzlichen Kapazität für den von den DEPI-Tunneln verwendeten L2TPv3-Overhead.

Bei einer Überlastung im CIN können einige Pakete verzögert oder verloren gehen.

Mögliche Ursache 1. QoS

Standardmäßig markieren der cBR-8 und die RPDs Pakete, die mit PTP-Datenverkehr und MAP-Nachrichten verknüpft sind, mit DSCP 46 (EF).  Andere DOCSIS-Kontrollmeldungen wie Upstream-Kanaldeskriptoren (UCD), Modem-Bandbreitenanforderung und Bereichsantwort verwenden ebenfalls DSCP 46:

Posten	Per-Hop Behaviour (PHB)	DSCP-Wert
DOCSIS-Daten (L2TP)	Bestmöglicher Aufwand	0
PTP	EF	46
GCP	Bestmöglicher Aufwand	0
MAP/UCD (L2TP, DOCSIS-Steuerung)	EF	46
BWR und RNG-REG	EF	46
Video	CS4	32
MDD (L2TP, DOCSIS-Steuerung), Sprache	CS5	40

Quelle: Cisco Remote PHY Device Software Configuration Guide for Cisco 1x2 / Compact Shelf RPD Software 5.x

Das CIN muss QoS-fähig sein, damit diese Pakete mit hoher Priorität eine minimale Verzögerung erfahren.

Eine Überlastung, die verlorene Pakete oder lange Warteschlangenverzögerungen verursacht, hat zu PTP-Problemen, verspäteten MAP-Nachrichten und einem reduzierten Durchsatz geführt. Diese Art von Problemen kann durch die Beobachtung von Schnittstellenwarteschlangen auf den cBR-8-, RPD- und CIN-Geräten erkannt werden.

Wenn PTP- oder MAP-Nachrichten verworfen oder verzögert werden, wie dies bei Instabilität der Uhr oder späten MAP-Nachrichten deutlich wird, muss die CIN-Kapazität bzw. das QoS-Design berücksichtigt werden, da diese mit hoher Priorität gesendet werden.

DLM soll keine kurzen Jitter-Zeiträume verarbeiten, da der Abfragezyklus mindestens eine Sekunde beträgt. Daher können späte MAP-Nachrichten in diesem Fall nicht eliminiert werden.

Mögliche Ursache 2. Datenverkehr mit verzögertem Best-Effort

Derzeit sind DLM-Paketmarken nicht konfigurierbar und verwenden Best Effort (DSCP 0). Es gab Fälle, in denen das CIN eine Überlastung aufweist, die zu langen Warteschlangenverzögerungen führt, die auf den bestmöglichen Datenverkehr beschränkt sind.

Dies hat sich in der Regel als reduzierter TCP-Downstream-Datenverkehr erwiesen, da CIN-Verzögerungen aufgrund verpasster oder verzögerter Upstream-ACKs zu relativ großen Geschwindigkeitsverlusten führen können.

In diesem Fall werden keine verspäteten MAP-Nachrichten oder PTP-Probleme beobachtet, da diese Pakete mit hoher Priorität nicht verzögert werden.

Da DLM-Pakete als bestmöglicher Datenverkehr markiert sind, kann dieser Typ von CIN-Jitter Spitzen in den DLM-Werten verursachen. Wenn die Netzwerkverzögerung mithilfe von DLM dynamisch angepasst wird, kann dieser Jitter zu einer unnötigen Erhöhung des MAP-Timers für den Vorlauf führen, was zu höheren Verzögerungen bei der Übertragung von Anfragen führt.

In diesem Fall wird empfohlen, einen statischen Wert für die Netzwerkverzögerung zu verwenden. Cisco prüft außerdem Optionen, mit denen in zukünftigen Versionen DSCP-Werte aktiviert werden können, die über das reine Beste für DLM hinausgehen. Dies kann dazu beitragen, die Upstream-Anforderungsverzögerung zu reduzieren, behebt jedoch möglicherweise keine Probleme mit dem TCP-Durchsatz, wenn ACKs über das CIN verzögert werden.

Zugehörige Informationen

• DEPI-Latenzmessung
• PTP-Designempfehlungen für R-PHY-Netzwerke
• Technischer Support und Dokumentation für Cisco Systeme