Problemen met RPD DOCSIS-doorvoerprestaties oplossen

Inleiding

Dit document beschrijft hoe u prestatieproblemen met Cisco Remote PHY-apparaat (RPD) kunt oplossen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• RPD
• Cisco geconvergeerde breedbandrouter (cBR)-8
• Data-over-Cable Service Interface Specificatie (DOCSIS)

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Het scenario dat in dit artikel wordt overwogen, omvat een RPD die door Cisco cBR-8 is geleverd als Converged Cable Access Platform (CCAP). Precision Time Protocol (PTP) wordt gebruikt om een externe primaire kloktijd te synchroniseren met cBR-8 en RPD die als secundair fungeren. Voor meer informatie over hoe het ontwerp van PTP in deze omgeving, kunt u verwijzen naar PTP Design Recommendations for R-PHY Networks.

Dit is geen uitgebreide lijst van stappen om problemen met de prestaties van RPD op te lossen, hoewel het een goede start is om het probleem te isoleren.

Problemen oplossen

Als u een verslechtering van de prestaties met RPD plaatsing waarneemt, en u wenst een eerste probleemoplossing uit te voeren, is het niet duidelijk waar te beginnen.

In dit deel worden enkele veelvoorkomende problemen beschreven die de mogelijke oorzaak kunnen zijn van de prestatieproblemen van RPD's.

Late MAP-berichten

Een late upstream-bandbreedtetoewijzingskaart (MAP)-berichtvoorwaarde treedt op wanneer een modem een MAP-bericht ontvangt op een bepaald tijdstip, nadat de in het bericht beschreven tijdsleuven al zijn opgetreden.  De modem kan dit MAP-bericht niet gebruiken en kan dus geen verkeer versturen met de toegewezen subsidies.

Een paar late MAPs kan lagere upstream verkeerstarieven veroorzaken, evenals verlaagde downstream TCP verkeerstarieven als upstream ACKs worden vertraagd. Als er genoeg late MAP's zijn, kunnen modems geen stationsonderhoud uitvoeren en offline gaan.

Een ander symptoom kan pakketdalingen zijn wanneer u een ping-docs <MAC_ADDR> doet van cBR-8 naar een modem die is aangesloten op een RPD.

Met Remote PHY (R-PHY) stuurt de cBR-8 MAP-berichten naar de modems in een Downstream Externe PHY-interfacetunnel (DEPI) en naar de RPD in een Upstream Externe PHY-interfacetunnel (UEPI). Deze berichten hebben een hogere Quality of Service (QoS)-markering met een DSCP-waarde (Differentiated Services Code Point) van 46 (Express Forwarding - EF).

Als een MAP bericht bestemd voor de RPD wordt gedropt in de CIN, kan de RPD deze minislots niet gebruiken en telt ze als "unmapped". Als het MAP bericht laat op de RPD aankomt, telt het eerst de minislots als unmapped en daarna ontvangt het de late MAP, het verhoogt de late minislots telling.

Vroege MAP's zijn ook mogelijk, maar meestal alleen wanneer de PTP kloktijd is uitgeschakeld in cBR-8 of RPD.

Overlap MAPs kan gebeuren wanneer MAP berichten uit volgorde komen maar met slechts 2 ms frequentie, is dit meestal geen probleem. Het werkelijke aantal minislots in een MAP-bericht is gebaseerd op de minislot-configuratie voor elk stroomopwaarts kanaal. Als een stroomopwaarts gebruik maakt van twee ticks per minislot (populair voor 6,4 MHz SC-QAM), heeft een 2 ms MAP 160 minislots.

Om te controleren of op de RPD je laat MAP-berichten ontvangt, voer deze opdrachten uit om toegang te krijgen tot de RPD-console. Voer vervolgens de opdracht show upstream map teller <rf port> <channel> meerdere malen en controleer of de teller "Discarded minislots (late maps)" verhoogt:

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

Opmerking: elke keer dat u de opdracht tonen upstream map teller, alle tellers zijn teruggezet op 0, maar laatste in kaart gebracht minislot

Tip: vanuit RPD versie 6.x kunt u de opdracht show tech-support uitvoeren, die meerdere voorvallen van upstream map teller en andere opdrachten verzamelt, daarom nuttig voor tellers vergelijking.

Als u RPD softwareversie 5.x of lager in werking stelt, kunt u de opdracht show tech uitvoeren met behulp van het script dat hier beschikbaar is: Capture show tech op rpd of limited commando op zowel RPD, supervisor.

De gekoppelde pagina bevat instructies voor het installeren van het script en gebruiksvoorbeelden, aan het einde waarvan u het bestand Script-Readme.tar kunt vinden dat kan worden gedownload. Dit bestand bevat het script sh_tech_rpd.tcl en het bestand sh_tech_rpd-README.txt met de instructies en gebruiksvoorbeelden.

Het script heeft een optie (-c) om een extra set opdrachten in een tekstbestand te verzamelen, worden beide opdrachten die op de RPD zelf en op de cBR-8 supervisor worden uitgegeven geaccepteerd (alle procedures worden uitgelegd in de eerder genoemde link en het leesmij-bestand).

Deze eigenschap maakt het gebruik van dit script, interessant, ook in RPD versies die de show tech-support opdracht omvatten.

Mogelijke oorzaak 1. CIN Delay, Latency, Jitter

Het Converged Interconnect Network (CIN) dat de CCAP-kern en RPD's verbindt, kan vertragingen introduceren die moeten worden verwerkt in de MAP-geavanceerde timer. Als er een wijziging in de CIN is, zoals bijvoorbeeld een andere router is toegevoegd, hebt u mogelijk een hogere vertraging geïntroduceerd.

De MAP voorsprong timer wordt gebruikt door de CCAP om late MAP berichten te voorkomen. Deze timer is gebaseerd in microseconden (μs), en kan statisch per kabelinterface worden geconfigureerd door de operator, of dynamisch berekend door cBR-8.

De dynamische waarde, is de som van het downstream-tijdsinterleaf (680 μ s met SC-QAM met 256-QAM), modem MAP-verwerkingsvertraging (600 μ s), CCAP interne netwerkvertraging (300 μ s), MAP-geavanceerde veiligheidswaarde (1000 μ s standaard) en maximale modemtijdoffset (gebaseerd op meest verafgelegen modem).

Bij R-PHY wordt de interne CCAP-vertraging nu vervangen door een netwerkvertraging, die standaard 500 μ s bedraagt. Met het oog op het CIN ontwerp, kan deze waarde groter zijn dan de standaardparameter en kan in tijd veranderen.

De MAP-voorbeeldwaarden voor een upstream kunnen met deze opdracht worden weergegeven:

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>

MAPforward = map_adv_safety (1000) + cm_map_proc (600) + intlv_dela(680) + network_delaff (500) + max_tmoff (119) = 2899 μ s.

Als de afstand tussen cBR-8 en RPD gecombineerd met de CIN-apparaten vertragingen de standaardwaarde van de netwerkvertraging van 500 μ s overtreft, zijn late MAP-berichten mogelijk.

Er zijn twee methoden om de standaardparameter voor netwerkvertraging aan te pakken wanneer dit een probleem vertegenwoordigt, en beide worden ingesteld per RPD op cBR-8:

• Configureer de vertraging automatisch.
• Stel de cBR-8 in om de vertraging periodiek te meten en aan te passen.

De netwerkvertraging kan statisch per RPD op cBR-8 worden geconfigureerd zoals hier wordt getoond:

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>

Voor dynamische netwerkvertraging is de cBR-8 gebaseerd op een latency metingsfunctie genaamd DEPI Latency Measurement (DLM), die de unidirectionele vertraging in het downstream pad bepaalt.

De cBR-8 stuurt een DLM-pakket met zijn tijdstempel, dan markeert de RPD zijn tijdstempel op het DLM-pakket wanneer het ontvangen is, en stuurt het terug naar de cBR-8.

Merk op dat Cisco de gewenste optie ondersteunt waarbij de RPD het pakket het dichtst bij de ingangsinterface markeert, en niet bij de uitgang.

cBR-8 neemt het gemiddelde van de laatste 10 DLM-waarden en gebruikt het als de waarde van de netwerkvertraging in de MAP-voorberekening. De tijdstempels van zowel cBR-8 als RPD zijn gebaseerd op de PTP referentieklokken.

Waarschuwing: Als PTP onstabiel is, zijn de DLM-waarden en uiteindelijk de MAP-voorsprongtimer dat ook.

Standaard is DLM uitgeschakeld en kan deze worden ingeschakeld met de opdracht DLM <seconden>netwerkvertraging zoals aangegeven in de afbeelding. Als deze optie is ingeschakeld, wordt er periodiek een DLM-pakket naar de RPD verzonden in overeenstemming met de ingestelde waarde.

Er is ook een optie alleen-metingen die kan worden toegevoegd, die alleen de CIN-vertraging meet zonder de waarde van de netwerkvertraging aan te passen.

Aanbevolen wordt DLM minimaal in de parameter alleen voor metingen in te schakelen om de CIN-vertraging te bewaken.

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

Meer informatie over deze functie kunt u hier vinden; DEPI Latency Measurement

De MAP-voorbeveiliging kan ook handmatig worden gewijzigd in de kabelinterfaceconfiguratie (de standaardwaarden zijn 1000 μ s voor de veiligheidsfactor en 18000 μs voor de max map-voorsprong):

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

Waarschuwing: zeer korte CIN vertragingen kunnen ook leiden tot late MAP berichten

Er zijn problemen waargenomen met het gelaten vallen upstream DOCSIS verkeer wanneer de MAP geavanceerde timer is onder 2500 μ s.

Sommige modems kunnen langer duren om MAP-berichten te verwerken en die extra vertraging kan leiden tot late MAP-berichten voor die modems (de RPD toont mogelijk geen late MAP tellingen als het in staat was om het bericht op tijd te krijgen).

Een lage MAP-geavanceerde timer is mogelijk met zeer lage DLM-waarden, of met een lage handmatige netwerkvertraging of MAP-geavanceerde veiligheidsconfiguratie. De waarden van de netwerkvertraging in de de voorberekening van de KAART kunnen zo laag zijn zoals 30 μs (zelfs als het gemiddelde van DLM lager is).

Het wordt aanbevolen om DLM "alleen meten" optie te gebruiken of de veiligheidsfactor voor de dynamische MAP-vooruitgang te verhogen tot de MAP-vooruitgangstimer meer dan 2500 μ s bedraagt.

Mogelijke oorzaak 2. Software bug

Om te controleren of een softwarebug een synchronisatiefout veroorzaakt, wordt aanbevolen om een serviceaanvraag te openen bij Cisco om het specifieke geval nader te onderzoeken.

De oplossing in het geval dat u een softwaredefect raakt is meestal een software-upgrade naar een van de releases die de oplossing bevat. Aangezien er een compatibiliteitscorrelatie is tussen cBR-8 en RPD softwarereleases, is het belangrijk om voor beide apparaten de juiste versie te kiezen.

Om te helpen de juiste Cisco IOS® XE voor elke RPD-software te kiezen, kunt u de compatibiliteit van de softwareversie tussen cBR-8 en RPD vinden in de installatiehandleidingen en upgradehandleidingen voor Cisco Remote PHY.

In deze tabel vindt u een overzicht van de compatibiliteit van de softwareversie tussen cBR-8 en RPD, met de beschikbare softwareversies op het moment van schrijven:

Compatibiliteit met versies tussen Cisco cBR-8 en Cisco RPD
Cisco cBR-8 release versie	Compatibele RPD release versie
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 latency

Zoals besproken in de vorige sectie, kunnen de lange vertragingen CIN de berichtkwesties van de late MAP veroorzaken, en kunnen met de verhoging van de de voortijdopnemer van de MAP worden behandeld. Dit leidt op zijn beurt tot een langere aanvraag-subsidie vertraging, die tot verhoogde stroomopwaartse latentie leidt.

Aangezien de stabiele stroomopwaartse verkeersstromen piggy-back verzoeken gebruiken, kan de stroomopwaartse verkeerssnelheidstest normaal lijken, en ook worden de stemstromen met de Ongevraagde Dienst van de Grant (UGS) niet beïnvloed, aangezien geen verzoeken nodig zijn.

Echter, downstream TCP verkeerssnelheden kunnen worden gereduceerd door gebrek aan tijdige upstream ACKs. Hoewel het mogelijk is om verwerkings- en wachttijden op de CIN aan te pakken, is het niet waarschijnlijk dat de signalen sneller over een bepaalde afstand worden verzonden.

Cisco heeft DOCSIS Predictive Scheduling (DPS) ontwikkeld om vertragingen in de aanvraag-subsidie van R-PHY-toepassingen met langere CIN-vertragingen te verminderen. DPS verleent op proactieve wijze subsidies aan modems op basis van historisch gebruik, om vertraging van de aanvraag-subsidie te minimaliseren.

DPS is een pre-standaard planningsmethode, vergelijkbaar met Proactive Grant Service (PGS) die wordt beschreven in de recente Low Latency DOCSIS (LLD)-specificatie.  DPS kan echter per interface worden ingeschakeld en wordt toegepast op alle best mogelijke upstream servicestromen. PGS wordt toegepast op verkeer als een type servicestroom, zodat het wijzigingen in het modemconfiguratiebestand vereist.

DPS kan worden ingeschakeld met de interfaceopdracht: cbr8 (config-if)#cable upstream dps

Hoewel DPS beschikbaar is sinds R-PHY ondersteuning werd toegevoegd aan de cBR-8, is het op dit moment geen officieel ondersteunde functie. Desalniettemin kan DPS effectief zijn om langzame TCP downstream doorvoersnelheid te verhelpen die is geassocieerd met vertraagde ACKs.

Layer 2 Tunneling Protocol (L2TP)-pakketten buiten bedrijf

Typ op de RPD-console deze opdracht meerdere malen om te controleren of de tellers "SeqErr-pkts" en "SeqErr-sum-pkts" positief zijn en toenemen, wat een indicatie is van L2TP uit de bestelling pakketten:

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      

Mogelijke oorzaak 1. Taakverdeling

In sommige bijzondere omstandigheden, zoals verbindingen congestie in de CIN bijvoorbeeld, kan de lastbalans bijdragen aan het probleem van pakketten die niet op orde bij de bestemming worden ontvangen.

Als u de mogelijkheid hebt om te controleren of de taakverdeling dit probleem veroorzaakt, kunt u testen om één pad af te dwingen waar de taakverdeling is ingesteld. Als dit het probleem van de out-of-order pakketten oplost, hebt u de bevestiging van de trigger, en kan verder de oorzaak van de wortel in uw netwerk onderzoeken.

Mogelijke oorzaak 2. PacketDrops

1. Controleer op verhoogde fouten en vallen op de cBR-8 tellers op de DPIC-kaartinterface waar de RPD is aangesloten met behulp van de opdracht show interface zoals hier getoond.

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. Controleer aan de RPD-kant of er fouten, gevallen en out-of-order pakketten op de interfaces en downstream tellers zijn.

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. Controleer de InterLaken tellers meerdere malen stroomafwaarts om te zien of er fouten zijn en of de tellers toenemen. Om dat te doen, moet u de lijnkaartconsoleinterface invoeren zoals hier getoond.

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. Neem een modem aan die aan deze RPD (DS-kanalen alleen gebonden) is aangesloten en verstuur pakketten (bijvoorbeeld, pings) naar deze RPD, om te controleren of verzonden pakketten overeenkomen met de geïnjecteerde stroomafwaartse stroom op de JIB-moduletellers. Zorg ervoor dat DS JIB alle DS-datapakketten voor DEPI-frame op de lijnkaartconsole heeft verzonden. In deze uitvoer kunt u zien hoe u het pakketvolgnummer kunt zien van een modemservicestroomuitvoer. Dit volgnummer wordt verhoogd voor elk gegevenspakket dat wordt verzonden.

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

Verzend enkele pings naar deze modem vanuit de opdrachtregel cBR-8 in een ander venster:

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#

Controleer de delta na de 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

Bereken de delta na de test: de teller is 16 bit niet ondertekend, dus als de teller rolt, moet de delta met deze formule worden berekend:

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

Voorbeeld:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




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

Als gevolg van de aard van de druppels, kan het probleem in het CIN (bijvoorbeeld knelpuntverbindingen, botsingen, CRC fouten) die verder moeten worden onderzocht in het CIN-netwerk tussen cBR-8 en RPD. Als er in plaats daarvan in de punten 3 en 4 druppels worden waargenomen, wordt aanbevolen Cisco in te schakelen voor verder onderzoek van de cBR-8.

PTP-verlies of -ontgrendeling periodiek

Zoals u waarschijnlijk weet, is PTP essentieel voor normale RPD-operaties. Daarom moeten PTP-pakketten hoge prioriteit hebben in QoS en zijn PTP-pakketdruppels geen goed teken.

Voor de RPD console, kunt u de PTP statistieken tonen, en verifiëren dat de tellers "VERZOEK VAN DE VERTRAGING"en "REACTIE VAN DE VERTRAGING"nauw worden aangepast. Als u in plaats daarvan een grote kloof ziet, kan het een indicator van PTP dalingen in het netwerk zijn:

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

Opmerking: op cBR-8 heeft PTP de hoogste prioriteit voor kloktijd, wat betekent dat wanneer het eenmaal is geconfigureerd het zelfs wordt gebruikt voor RF-lijnkaarten. Daarom zou een onbetrouwbare bron problemen veroorzaken over het gehele chassis.

Voor meer informatie over de PTP-klokconfiguratie en probleemoplossing kunt u het artikel PTP Design Recommendations for R-PHY Networks lezen.

Congested CIN

De CIN kan worden gezien als een uitbreiding van het besturingsplane van de CCAP-kern, dus als er 1000 Mbps DOCSIS- en videoverkeer in de downstream is voor een gegeven RPD, dan moet die veel capaciteit worden toegewezen in de CIN, plus enige extra capaciteit voor de L2TPv3-overhead die wordt gebruikt door de DEPI-tunnels.

Als er congestie in de CIN is, dan kunnen sommige pakketten worden vertraagd of verloren.

Mogelijke oorzaak 1. QoS

Standaard markeren cBR-8 en RPD's pakketten die gekoppeld zijn aan PTP-verkeer en MAP-berichten met DSCP 46 (EF).  Andere DOCSIS-controleberichten zoals upstream channel descriptors (UCD), modembandbreedteverzoek en bereikrespons maken ook gebruik van DSCP 46:

Artikel	Per-hop-gedrag (PHB)	DSCP-waarde
DOCSIS-gegevens (L2TP)	Beste poging	0
PTP	EF	46
GCP	Beste poging	0
MAP/UCD (L2TP-, DOCSIS-controle)	EF	46
BWR en RNG-REG	EF	46
Video	UCS4	32
MDD (L2TP, DOCSIS-controle), spraak	CS5	40

Bron: Software voor Cisco Remote PHY-apparaat, configuratiehandleiding voor Cisco 1x2 / Compact shelf RPD-software 5.x

De CIN moet zich bewust zijn van QoS, zodat deze pakketten met hoge prioriteit een minimale vertraging ervaren.

De congestie die tot gelaten vallen pakketten of lange rijvertragingen leidt heeft tot PTP kwesties, de late berichten van de KAART en verminderde productie geleid. Dit soort problemen kan worden gezien door observatie van interfacewachtrijen op de cBR-8, RPD en CIN apparaten.

Als PTP- of MAP-berichten worden verbroken of vertraagd, zoals duidelijk is bij klokinstabiliteit of late MAP-berichten, dan moet de CIN-capaciteit of het QoS-ontwerp worden aangepakt, aangezien deze met hoge prioriteit worden verzonden.

DLM is niet bedoeld om korte duur van jitter te behandelen omdat de minimale opiniepeilingscyclus één seconde is, zodat het niet in staat is om late MAP-berichten in dit geval te elimineren.

Mogelijke oorzaak 2. Vertraagd verkeer met de beste inspanning

Op dit moment zijn DLM-pakketmarkeringen niet configureerbaar en gebruiken ze de beste inspanning (DSCP 0). Er zijn gevallen geweest waarin de CIN congestie ervaart die leidt tot lange wachtrijvertraging beperkt tot het beste inspanningsverkeer.

Dit is typisch getoond als de verminderde stroomafwaartse verkeerstarieven van TCP, aangezien de vertragingen van CIN tot vrij grote snelheidsdalingen kunnen leiden toe te schrijven aan gemist of vertraagd stroomopwaarts ACKs.

In dit geval worden geen late MAP-berichten of PTP-problemen waargenomen, omdat deze pakketten met hoge prioriteit geen vertraging oplopen.

Aangezien DLM-pakketten worden gemarkeerd als verkeer met de beste inspanning, kan dit type CIN-jitter pieken veroorzaken in de DLM-waarden. Als DLM wordt gebruikt om de netwerkvertraging dynamisch aan te passen, kan deze jitter een onnodige verhoging van de MAP-voorsprongtimer veroorzaken, wat leidt tot verhoogde upstream-aanvraag-subsidie-vertragingen.

In dit geval wordt aanbevolen een statische vertragingswaarde voor het netwerk te gebruiken. Cisco kijkt ook naar opties om DSCP-waarden in toekomstige releases buiten gewoon de best mogelijke inspanning op DLM in te schakelen. Dit kan helpen de upstream vertraging van de aanvraag-subsidie te verminderen, maar mogelijk worden TCP-doorvoerproblemen niet aangepakt als ACK’s over de CIN worden vertraagd.

Gerelateerde informatie

• DEPI-Latentiemeting
• PTP-ontwerpaanbevelingen voor R-PHY-netwerken
• Technische ondersteuning en documentatie – Cisco Systems