Problemen met RPD DOCSIS-doorvoerprestaties oplossen

Inleiding

In dit document wordt beschreven hoe u problemen met de prestaties van Cisco Remote PHY Device (RPD) kunt oplossen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• RPD
• Cisco Converged Broadband Router (cBR)-8
• Specificatie van de Data over Cable Service Interface (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 de Cisco cBR-8 wordt geleverd als Converged Cable Access Platform (CCAP). Precision Time Protocol (PTP) wordt gebruikt om een externe primaire klok te synchroniseren met de cBR-8 en RPD die als secundair fungeren. Voor meer informatie over hoe het PTP-ontwerp in deze omgeving werkt, kunt u verwijzen naar PTP-ontwerpaanbevelingen voor R-PHY-netwerken.

Dit is geen uitgebreide lijst met stappen om prestatieproblemen met RPD op te lossen, hoewel het een goed begin is om het probleem te isoleren.

Problemen oplossen

Als u een verslechtering van de prestaties met RPD-implementatie waarneemt en u een eerste probleemoplossing wilt uitvoeren, is het niet duidelijk waar u moet beginnen.

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

Late MAP-berichten

Een late upstream bandwidth allocation map (MAP)-berichtvoorwaarde treedt op wanneer een modem een MAP-bericht ontvangt op een bepaald moment, nadat de in het bericht beschreven tijdsleuven al zijn opgetreden.  De modem kan dit MAP-bericht niet gebruiken en kan dus geen verkeer verzenden voor de toegewezen subsidies.

Een paar late MAP's kunnen lagere upstream-verkeerstarieven veroorzaken, evenals lagere downstream TCP-verkeerstarieven omdat upstream ACK's worden vertraagd. Als er voldoende late MAP's zijn, kunnen modems geen stationsonderhoud uitvoeren en offline gaan.

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

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

Als een MAP-bericht dat is bestemd voor de RPD wordt weggelaten in de CIN, kan de RPD die minislots niet gebruiken en telt ze als "unmapped". Als het MAP-bericht te laat aankomt bij de RPD, telt het in eerste instantie de minislots als niet-toegewezen en vervolgens nadat het de late MAP heeft ontvangen, verhoogt het het aantal late minislots.

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

Overlappende MAP's kunnen gebeuren wanneer MAP-berichten uit de reeks komen, maar met slechts 2 ms frequentie is dit meestal geen probleem. Het werkelijke aantal minislots in een MAP-bericht is gebaseerd op de configuratie van de minislot voor elk upstream-kanaal. Als een upstream twee tikken per minislot gebruikt (populair voor 6,4 MHz SC-QAM), heeft een 2 ms MAP 160 minislots.

Om te controleren of u op de RPD late MAP-berichten ontvangt, voert u deze opdrachten uit om toegang te krijgen tot de RPD-console. Voer vervolgens de opdracht upstream map counter <rf port> <channel> meerdere keren tonen uit en controleer of de teller "Afgedankte minislots (late maps)" toeneemt:

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 upstream kaartenteller weergeven uitvoert, worden alle tellers gereset naar 0 maar Laatste toegewezen minislot

Tip: vanaf RPD versie 6.x kunt u de show tech-support opdracht uitvoeren, die meerdere keren show upstream kaartteller en andere opdrachten verzamelt, daarom handig voor tellers vergelijking.

Als u RPD-softwareversie 5.x of lager uitvoert, kunt u de opdracht show tech uitvoeren met behulp van het script dat hier beschikbaar is: show tech vastleggen op rpd of beperkte opdracht op beide RPD, supervisor.

De gekoppelde pagina bevat instructies over het installeren van het script en gebruiksvoorbeelden, aan het einde waarvan u het bestand Script-Readme.tar kunt vinden dat beschikbaar is om te downloaden. Dit bestand bevat het sh_tech_rpd.tcl script en het sh_tech_rpd-README.txt bestand met de instructies en gebruiksvoorbeelden.

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

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

Mogelijke oorzaak 1. CIN-vertraging, latentie, jitter

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

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

De dynamische waarde is de som van de downstream-tijdinterleaf (680 μs met SC-QAM met 256-QAM), de verwerkingsvertraging van de MAP van de modem (600 μs), de interne netwerkvertraging van de CCAP (300 μs), de vooraf ingestelde veiligheidswaarde van de MAP (standaard 1000 μs) en de maximale tijdoffset van de modem (op basis van de meest verre modem).

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

De MAP-waarden 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>

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

Als de afstand tussen de cBR-8 en RPD in combinatie met de CIN-apparaten de standaardwaarde voor netwerkvertraging van 500 μs overschrijdt, zijn late MAP-berichten mogelijk.

Er zijn twee methoden om met de standaardparameter netwerkvertraging om te gaan wanneer dit een probleem vormt, en beide zijn ingesteld per RPD op de cBR-8:

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

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

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 vertrouwt de cBR-8 op een latentiemetingsfunctie genaamd DEPI Latency Measurement (DLM), die de eenrichtingsvertraging in het stroomafwaartse pad bepaalt.

De cBR-8 verzendt een DLM-pakket met zijn tijdstempel, waarna de RPD zijn tijdstempel op het DLM-pakket markeert wanneer deze wordt ontvangen en doorstuurt naar de cBR-8.

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

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

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

DLM is standaard uitgeschakeld en kan worden ingeschakeld met de opdracht network-delay dlm <seconds> zoals wordt weergegeven. Eenmaal ingeschakeld, wordt een DLM-pakket periodiek naar de RPD verzonden in overeenstemming met de geconfigureerde waarde.

Er is ook een maatregel-only optie die kan worden toegevoegd, die alleen de CIN-vertraging meet zonder aanpassing van de netwerkvertragingswaarde.

Het wordt aanbevolen om DLM ten minste in te schakelen in de parameter alleen voor metingen, 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 vindt u hier; DEPI Latency Measurement

De MAP-veiligheid vooraf kan ook handmatig worden gewijzigd in de configuratie van de kabelinterface (standaardwaarden zijn 1000 μs voor de veiligheidsfactor en 18000 μs voor de maximale kaartvooruitgang):

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

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

Er zijn problemen waargenomen met gevallen upstream DOCSIS-verkeer wanneer de MAP-timer minder dan 2500 μs is.

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

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

Het wordt aanbevolen om ofwel de DLM "measure-only" optie te gebruiken of de veiligheidsfactor voor dynamische MAP vooraf te verhogen totdat de MAP-timer meer dan 2500 μs is.

Mogelijke oorzaak 2. Softwarefout

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

De oplossing voor het geval 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 de juiste versie voor beide apparaten te kiezen.

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

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:

stroomopwaartse latentie

Zoals besproken in de vorige sectie, kunnen lange CIN-vertragingen late MAP-berichtproblemen veroorzaken en kunnen worden aangepakt met de MAP-timerverhoging vooraf. Dit leidt op zijn beurt tot een langere aanvraag-subsidievertraging, wat leidt tot een hogere stroomopwaartse latentie.

Omdat stabiele upstream verkeersstromen gebruik maken van piggy-back verzoeken, kan upstream verkeerssnelheidstest normaal lijken en ook spraakstromen met Unsolicited Grant Service (UGS) worden niet beïnvloed, omdat er geen verzoeken nodig zijn.

Downstream TCP-verkeerssnelheden kunnen echter worden verlaagd vanwege een gebrek aan tijdige upstream ACK's. Hoewel het mogelijk is om vertragingen in verwerking en wachtrijen aan te pakken op de CIN, is het niet waarschijnlijk dat signalen sneller over een bepaalde afstand reizen.

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

DPS is een pre-standaard planningsmethode, vergelijkbaar met Proactive Grant Service (PGS) 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 servicestroomtype, dus het vereist wijzigingen in het configuratiebestand van de modem.

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

Hoewel DPS beschikbaar is sinds R-PHY-ondersteuning is toegevoegd aan de cBR-8, is het op dit moment geen officieel ondersteunde functie. Desalniettemin kan DPS effectief zijn om trage TCP downstream doorvoer geassocieerd met vertraagde ACK's op te lossen.

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

Op de RPD-console typt u deze opdracht meerdere keren om te controleren of de tellers "SeqErr-pkts" en "SeqErr-sum-pkts" positief zijn en toenemen, wat een indicatie is van L2TP out-of-order 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. Belastingbalans

In sommige bijzondere omstandigheden, zoals bijvoorbeeld de congestielinks in de CIN, kan de lastenverdeling bijdragen tot het probleem van pakketten die buiten de bestelling op de bestemming worden ontvangen.

Als u de mogelijkheid hebt om te controleren of de taakverdeling dit probleem veroorzaakt, kunt u testen om een enkel pad af te dwingen waar de taakverdeling is geconfigureerd. Als dit het probleem van de out-of-order pakketten oplost, hebt u de bevestiging van de trigger en kunt u de hoofdoorzaak in uw netwerk verder onderzoeken.

Mogelijke oorzaak 2. Packet Drops

1. Controleer op eventuele verhoogde fouten en vallen op de cBR-8-tellers op de DPIC-kaartinterface waar de RPD is aangesloten, met het gebruik van de opdracht show interface zoals hier weergegeven.

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 zijn, gevallen en out-of-order pakketten op de interfaces en downstream-tellers.

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 downstream InterLaken-tellers meerdere keren om te zien of er fouten zijn en of de tellers toenemen. Om dat te doen, moet u de interface van de lijnkaartconsole invoeren zoals hier wordt weergegeven.

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

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

Stuur enkele pings naar deze modem vanaf 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 omdraait, 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 dalingen kan het probleem zich voordoen in de CIN (bijvoorbeeld knelpuntverbindingen, botsingen, CRC-fouten) die verder moeten worden onderzocht in het CIN-netwerk tussen de cBR-8 en RPD. Als er in plaats daarvan dalingen worden waargenomen in de punten 3 en 4, wordt aanbevolen om Cisco in te schakelen voor verder onderzoek naar de cBR-8.

PTP verlies of ontgrendelt periodiek

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

Op de RPD-console kunt u de PTP-statistieken weergeven en controleren of de tellers "DELAY REQUEST" en "DELAY RESPONSE" nauw overeenkomen. Als u in plaats daarvan een grote kloof ziet, kan dit een indicator zijn van PTP-dalingen in het netwerk:

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 de klok, wat betekent dat deze zelfs voor RF-lijnkaarten wordt gebruikt als deze eenmaal is geconfigureerd. Daarom zou een onbetrouwbare bron problemen veroorzaken in het hele chassis.

Voor meer informatie over de PTP-klokconfiguratie en probleemoplossing kunt u het artikel PTP-ontwerpaanbevelingen voor R-PHY-netwerken lezen.

Overbelaste CIN

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

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

Mogelijke oorzaak 1. QoS

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

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

De CIN moet op de hoogte zijn van QoS, zodat deze pakketten met hoge prioriteit een minimale vertraging ervaren.

Door congestie die gedropte pakketten of vertragingen in de lange wachtrij veroorzaakt, zijn PTP-problemen, late MAP-berichten en verminderde doorvoer ontstaan. Dit soort problemen kan worden gezien door observatie van interfacewachtrijen op de cBR-8-, RPD- en CIN-apparaten.

Als PTP- of MAP-berichten worden verwijderd of vertraagd, zoals blijkt uit klokinstabiliteit of late MAP-berichten, moet de CIN-capaciteit of het QoS-ontwerp worden aangepakt, omdat deze met hoge prioriteit worden verzonden.

DLM is niet bedoeld om korte periodes van jitter te verwerken, omdat de minimale polling cyclus één seconde is, dus het is niet in staat om late MAP-berichten in dit geval te elimineren.

Mogelijke oorzaak 2. uitgestelde best effort traffic

Op dit moment kunnen DLM-pakketmarkeringen niet worden geconfigureerd en wordt de beste inspanning (DSCP 0) gebruikt. Er zijn gevallen geweest waarin de CIN congestie ervaart die leidt tot lange wachtrijvertragingen beperkt tot het verkeer met de beste inspanning.

Dit is meestal aangetoond als verminderde TCP downstream verkeerstarieven, omdat CIN vertragingen relatief grote snelheidsdalingen kunnen veroorzaken als gevolg van gemiste of vertraagde upstream ACK's.

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

Aangezien DLM-pakketten worden gemarkeerd als best effort-verkeer, kan dit type CIN-jitter pieken in de DLM-waarden veroorzaken. Als DLM wordt gebruikt om de netwerkvertraging dynamisch aan te passen, kan deze jitter een onnodige toename van de MAP-timer veroorzaken, wat leidt tot meer upstream aanvragen-subsidie vertragingen.

In dit geval wordt aanbevolen om een statische netwerkvertragingswaarde te gebruiken. Cisco kijkt ook naar opties om DSCP-waarden mogelijk te maken die verder gaan dan alleen de beste inspanning voor DLM in toekomstige releases. Dit kan helpen om de vertraging van upstream aanvragen en subsidies te verminderen, maar pakt mogelijk geen problemen met de doorvoer van TCP aan als ACK's worden vertraagd in de CIN.

Gerelateerde informatie

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