Einleitung
In diesem Dokument werden Best Practices und Systemprüfungen beschrieben, um sicherzustellen, dass eine Remote PHY (RPHY)- und eine Converged Interconnected Network (CIN)-Umgebung auf Basis der CableLabs RPHY-Spezifikationen effizient arbeiten kann.
Beitrag von Andy Moyer, Cisco TAC Engineer.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Remote-PHY-Gerät (RPD)
- Cisco Converged Broadband-Router (cBR-8)
- DOCSIS-Spezifikation (Data Over Cable Service Interface Specification)
- Quality of Service (QoS)
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf der cBR-8-Hardware.
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 kennen.
DSCP-Werte
Der PTP-Datenverkehr (Precision Time Protocol) zum Core und die RPD müssen priorisiert werden, damit PTP-Pakete nicht verloren gehen. Die RPD muss die IETF RFC 2475 Differentiated Services Code Point (DSCP)-Werte für Expedited Forwarding (EF) und Best Effort (BE) für Downstream External PHY Interface (DEPI)-Tunnel gemäß der CableLabs RPHY-Spezifikation unterstützen: CM-SP-R-PHY-I14-200323. Der PTP-Verkehr wird innerhalb des CIN priorisiert, und es ist gängige Praxis, die gleichen DSCP-Werte wie DEPI-Tunnel zu verwenden. Die DSCP-Werte für die RPD sind im Code festgelegt, und PTP wird der Wert 46 zugewiesen.
|
Posten
|
Per-Hop-Behavior
|
DSCP-Wert
|
|
DOCSIS-Daten (L2TP)
|
BE
|
0
|
|
PTP
|
EF
|
46
|
|
GCP
|
BE
|
0
|
|
MAP/UCD
|
EF
|
46
|
|
BWR/RNG_REQ
|
EF
|
46
|
|
Video
|
CS4
|
32
|
|
MDD, Sprache
|
CS4
|
32
|
|
Abkürzung
|
Definition
|
|
L2TP
|
Layer-2-Tunneling-Protokoll
|
|
GCP
|
Allgemeines Steuerungsprotokoll
|
|
KARTE
|
Zuordnung der Bandbreitenzuweisung
|
|
UCD
|
Upstream-Kanaldeskriptor
|
|
BWR
|
Bandbreitenanforderung
|
|
RNG_REQ
|
Bereichsanforderung
|
|
MDD
|
MAC-Domänendeskriptor
|
Bandbreite berechnen
- Alle Geräte im Pfad vom Core zur RPD müssen eine ausreichende Bandbreite mit hoher Priorität gegenüber dem gesamten anderen Datenverkehr reservieren, um den gesamten MAP-, UCD-, BWR/RNG_REQ- und PTP-Datenverkehr zu übertragen. Diese Formeln können zur Berechnung der gesamten EF-Bandbreite verwendet werden:
Total EF Bandwidth = MAP/UCD BW + BWR/RNG_REG BW + PTP BW
MAP/UCD BW in bits per sec = 500 Maps/sec * 8 bits/byte * MAP-Size * No.-of-Primary-DS * No.-of-US * 2 for UEPI Maps
Worst case MAP-Size: SC-QAM: 660Bytes, OFDMA: 1450bytes
Anmerkung: 38,8 Mbit/s ist die Gesamtbandbreite eines 256 QAM SC-QAM mit Overhead. Verwenden Sie zur Berechnung die höchste Rate in jedem OFDM-Kanal (Orthogonal Frequency Division Multiplexing), den Sie konfiguriert haben.
Von cBR-8:
cBR8# show controllers downstream-Cable rf-channel 158 verbose | include rate
CTRL profile (Profile A): rate: 496000 kbps
Data profile 1 (Profile B): rate: 619000 kbps
cBR8# show controller downstream-Cable counter rf-channel | count DOCSIS
Number of lines which match regexp = 32
-
Alle Geräte im Pfad von CIN zu RPD müssen über den gesamten Pfad ausreichend Gesamtbandbreite reservieren, um einen Verlust von Datenverkehr zu vermeiden. Um die erforderliche Bandbreite zu berechnen, zählen Sie die Anzahl der Downstream (DS)-Einzelkanäle - Quadraturamplitudenmodulation (SC-QAM), und multiplizieren Sie sie mit 38. Fügen Sie dann die OFDM-Kanalrate hinzu, die in Datenprofil 1 von der CLI aus aufgeführt ist.
- Multiplizieren Sie die Anzahl der OFDM DS mit dieser Zahl anstelle von 38 für die OFDM-Kanalrate.
- Garantierte Gesamtbandbreite für CIN = {Anzahl DS} * 38 + OFDM-Kanalrate.
CIN-Prüfungen und Ergebnisse
Wenn das CIN Layer-3-Routing (L3) verwendet, stellen Sie sicher, dass der Pfad vom Core zur RPD eindeutig ist. Wenn die Pakete mehrere Routen nutzen, kann dies dazu führen, dass ein Kabelmodem (CM) einen unvorhersehbaren Durchsatz bereitstellt. Hier sind einige der Probleme, die aufgrund der CIN-Instabilität beobachtet werden können.
- Niedriger TCP/UDP-Durchsatz
- TCP-Wiederholungsversuche und -Neuübertragungen
- Späte MAPs auf RPD beobachtet
- Zeitsynchronisationsverlust oder Umschaltung von PHASE-LOCK auf Holdover und Back
- Wenn MAP-Pakete verpasst wurden
- Bei "
SeqErr-sum-pkts" Erhöhung aller DS-Kanäle
- Wenn der
"Drop-sum-pkts" Anstieg in allen US-Kanälen
Anmerkung: In Befehlsbeispielen zeigen Auslassungszeichen (...) an, dass einige Informationen aus Gründen der Lesbarkeit weggelassen wurden.
Von RPD:
A. Upstream-Zuordnungszähler nach Kanal:
R-PHY# show upstream map counter 0
Wenn in dieser Ausgabe mehr nicht zugeordnete Minislots ausgegeben werden, bedeutet dies, dass MAPs verloren gegangen sind.
R-PHY# show upstream map counter 0 0
Map Processor Counters
==============================================
Mapped minislots : 297797435
Discarded minislots (chan disable): 0
Discarded minislots (overlap maps): 0
Discarded minislots (early maps) : 0
Discarded minislots (late maps) : 0
Unmapped minislots : 0
Last mapped minislot : 3003775
B. Downstream-Kanalzähler:
R-PHY# show downstream channel counter
Wiederholen Sie diesen Befehl mehrmals in 10 Sekunden.
R-PHY# show downstream channel counter
------------------- Packets counter in TPMI -------------------
Level Rx-pkts Rx-sum-pkts
Node Rcv 160159 160159
Depi Pkt 0 0
Port Chan Rx-pkts Rx-sum-pkts
Port Rx-pkts Rx-sum-pkts Drop-pkts Drop-sum-pkts
DS_0 160201 160201 0 0
US_0 2417 2417 0 0
US_1 2417 2417 0 0
------------------- Packets counter in DPMI -------------------
Field Pkts Sum-pkts
Dpmi Ingress 1260566 77868982
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 950 1684498 0 1
0 1 4390912 / 0x00430000 24088 1612049 0 1
0 2 4390912 / 0x00430000 7686168 474015682 0 0
0 3 4390912 / 0x00430000 0 0 0 0
1 0 4390913 / 0x00430001 704757 40898198 0 1
1 1 4390913 / 0x00430001 510 30974 0 1
1 2 4390913 / 0x00430001 0 0 0 0
...
Informationen über DLM
Das DEPI Latency Measurement (DLM)-Paket ist ein spezieller Datentyp zum Messen der Netzwerklatenz zwischen dem CCAP-Core (Converged Cable Access Platform) und der RPD. Es gibt zwei Arten von DLM-Paketen: Eingangs-DLM-Paket und Ausgangs-DLM-Paket. Das Eingangs-DLM misst die Latenz zwischen dem CCAP-Core und dem Eingangspunkt in der RPD und das Ausgangs-DLM die Latenz zwischen dem CCAP-Core und dem Ausgangspunkt der RPD.
Der Einsatz von DLM
Anmerkung: Diese Funktion ist standardmäßig deaktiviert.
Konfiguration
cBR-8# conf t
cBR-8(config)# cable rpd
cBR-8(config-rpd)# core-interface tenGigabitEthernet
cBR-8(config-rpd-core)# network-delay dlm
Prüfung einer RPD
cBR-8# show cable rpd dlm
Load for five secs: 4%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 13:12:36.253 CST Sun Jan 1 2017
DEPI Latency Measurement (ticks) for 0000.bbaa.0002
Last Average DLM: 4993
Average DLM (last 10 samples): 4990
Max DLM since system on: 5199
Min DLM since system on: 4800
Sample # Latency (usecs)
x------------x------------
0 491
1 496
2 485
3 492
4 499
5 505
6 477
7 474
8 478
9 47
Testbefehle für zusätzliche Informationen
Melden Sie sich vom cBR-8 auf der Linecard an, und führen Sie dann diese Testbefehle aus.
cBR-8# request platform software console attach
Summary of all RPD's that use DLM:
Slot-1-0# test cable md cdman show dlm 1 summary
DLM info summary
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.224.98 interval: 1 status: inact [0]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.224.97 interval: 1 status: inact [1]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.224.96 interval: 1 status: inact [2]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.224.99 interval: 1 status: inact [3]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.224.95 interval: 1 status: inact [4]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.227.96 interval: 1 status: inact [5]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.227.95 interval: 10 status: inact [6]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.227.94 interval: 1 status: inact [7]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.222.99 interval: 1 status: inact [8]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.222.97 interval: 1 status: inact [9]
rpd_id: xxxx.xxxx.xxxx rpd_ip: 10.240.222.98 interval: 1 status: inact [10]
Total 11 DLM info (max 80) ucast/mcast/recv_valid/lost/recv_all(pkts): 1000/200/1200/0/1200 <<<<<<<DLM Packets
Ctrlr DLM info summary
ctrlr: 8 rpd_id: xxxx.xxxx.xxx1 status: inact [8][0]
ctrlr: 9 rpd_id: xxxx.xxxx.xxx2 status: inact [9][0]
ctrlr: 10 rpd_id: xxxx.xxxx.xxx3 status: inact [10][0]
ctrlr: 16 rpd_id: xxxx.xxxx.xxx4 status: inact [16][0]
ctrlr: 17 rpd_id: xxxx.xxxx.xxx5 status: inact [17][0]
ctrlr: 18 rpd_id: xxxx.xxxx.xxx6 status: inact [18][0]
ctrlr: 19 rpd_id: xxxx.xxxx.xxx7 status: inact [19][0]
ctrlr: 20 rpd_id: xxxx.xxxx.xxx8 status: inact [20][0]
ctrlr: 30 rpd_id: xxxx.xxxx.xxx9 status: inact [30][0]
ctrlr: 30 rpd_id: xxxx.xxxx.xx10 status: inact [30][1]
ctrlr: 31 rpd_id: xxxx.xxxx.xx11 status: inact [31][0]
Slot-1-0# test cable md cdman show dlm 1 ipv4
Slot-1-0#
rpd_id: 0000:0000:0000 ctrlr: 17 channel: 0
session_id: 0 local_session_id: 0
slot: 1 local_port_id: 13 te_port: 4
interval: 1 measure_only: 0 static_cin_delay: 0 static_cin_delay_usec: 0
IP mcast: <mcast addr> mcast_sec: ucast: <ucast ipv4 addr> src: <source IP> dst:
MAC src: 0000:0000:0000 next_hop: 0000:0000:0000
DLM effect: false
in_use: true refresh_mapadv: true cdm_pak_size: 66
cdm_trans_id: 0 trans_id: 0 trans_id_m_cnt: 0
rpd: ucast/mcast/recv/lost(pkts): 0/0/0/0 trigger_cnt: 0
all: ucast/mcast/recv_valid/lost/recv_all(pkts): 0/0/0/0/0
time_start: [ 0 0 0 0 0 0 0 0 0 0 ]
time_end: [ 0 0 0 0 0 0 0 0 0 0 ]
ingress: [ 0 0 0 0 0 0 0 0 0 0 ] ingress_idx: 0
timestamp: [ 0 0 0 0 0 0 0 0 0 0 ]
seq_num: [ 0 0 0 0 0 0 0 0 0 0 ]
delay_ticks min/max/avg/last_avg/sum: 0/0/0/0/0
except_cnt: 0
full_samples: false
ctrlr: 17 rpd_id: xxxx.xxxx.xxxx status: inact [17][0]
Fehlerbehebung
Debuggen Sie die RPD-DEPI-Sitzung und -Ereignisse sowie DLM.
cBR-8# debug cable rpd depi
cBR-8# debug cable rpd r-depi
cBR-8# debug cable dlm tx
cBR-8# debug cable dlm rx
Zugehörige Informationen