Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Fond

Protocole PTP (Precision Time Protocol)

Introduction

Protocol

Processus D'Échange D'Horodatage Master Et Slave

Horloge GrandMaster

Horloge esclave

Horloge de limite

Classes d'horloge

États de l'horloge

Domaines PTP

Profils PTP

Définition des messages de base

Conditions requises

Configuration

Horloge maître PTP sur ASR900

Étape 1. Configurer L'Oscillateur Interne Local

Étape 2. Configurer PTP en tant que maître sur l'ASR900

Vérification

Horloge esclave sur cBR-8

Vérification

Restrictions

Profil G.8275.2

Horloge esclave sur RPD

Vérification

Horloge de limite sur ASR900

Surveillance avec SNMP

Dépannage

Dépannage du maître PTP (ASR900)

Dépannage de l'esclave PTP (cBR-8)

DTI et PTP

Délais d'horloge et décalage

Dépannage de l'esclave PTP (RPD)

Informations connexes

Introduction

Ce document décrit le protocole PTP (Precision Time Protocol) utilisé dans les réseaux câblés avec les réseaux cBR-8 et Remote PHY (R-PHY). L'objectif est de donner une compréhension globale du protocole et de la façon de le configurer dans les déploiements cBR-8 et RPHY.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- R-PHY.

- CCAP (Converged Cable Access Platform) cBR-8.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- cBR-8 exécute la version 16.6.1 ou ultérieure.

- Périphérique Cisco 1x2 Remote PHY (RPD).

Astuce : Reportez-vous à l'article cisco Cisco 1x2 RPD pour plus d'informations.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Fond

Afin d'accorder aux modems les tranches de temps (mini-lots) à transmettre sur un canal en amont, le CCAP mappe les affectations de mini-lot en amont au moyen de messages MAP (bandwidth allocation map). Ces messages MAP sont envoyés en aval et reçus par tous les modems.

Les modems examinent ces messages pour déterminer quels mini-lots sont attribués à quels modems et lesquels sont destinés à des activités basées sur le conflit. Un modem ne transmet le trafic que sur un mini-lot qui lui est attribué (ou sur un logement de contention si vous effectuez une demande de bande passante ou une autre activité de maintenance de station).

Les messages MAP du CCAP allouent environ 2 millisecondes (ms) de temps. Le protocole LLD (Low Latency DOCSIS) offre des options pour réduire cette valeur en dessous de 2 ms.

Il est important que le CCAP et chaque modem aient le même concept de temps, afin d'éviter les chevauchements.

Le CCAP doit s'assurer qu'il n'affecte pas un créneau horaire à un modem trop rapidement à la suite d'une demande, pour éviter que le modem n'ait pas le temps de recevoir le message MAP et de le traiter, et qu'il manque la possibilité d'utiliser ce mini-lot.

Pour éviter cette situation, le CCAP utilise un compteur d'avance MAP, où il ne planifie pas le trafic d'un modem avant un point ultérieur au compteur d'avance MAP.

L'élément de synchronisation de DOCSIS nécessaire pour la planification en amont est toujours présent dans R-PHY. Afin de relier les RPD au CCAP, un CIN (Converged Interconnect Network) est utilisé, basé sur IP, et peut être dédié à l'accès par câble ou partagé par d'autres applications.

Le coeur CCAP gère la planification et la génération en amont des messages MAP. Toutefois, les signaux en aval et en amont sont maintenant émis et terminés physiquement sur la DRE, de sorte que la DRE doit avoir le même concept de temps que le noyau du PAIC.

La spécification de l'interface de temporisation DOCSIS distante (R-DTI) est la spécification de CableLabs qui détaille comment cette synchronisation a lieu. Pour les réseaux Ethernet, le protocole PTP est utilisé pour atteindre ce délai.

Dans la mise en oeuvre actuelle de Cisco, le cBR-8 et le RPD agissent comme un périphérique esclave à une horloge maître PTP.

Protocole PTP (Precision Time Protocol)

Introduction

PTP permet à une horloge esclave de déterminer son décalage horaire à partir d'une horloge maître (différence d'heure entre les horloges), ainsi que le délai de propagation dans le réseau de transport entre les deux horloges.

Les périphériques maître et esclave échangent des messages qui incluent des horodatages avant que l'esclave n'exécute un algorithme pour déterminer ces valeurs.

Les formules de ce calcul supposent une connexion symétrique entre les deux horloges.

Avertissement : Une des principales causes des problèmes DOCSIS dans R-PHY est créée par des liaisons PTP non symétriques qui conduisent à l'instabilité de l'horloge.

Les connexions non symétriques telles que Ethernet Passive Optical Network (EPON) sont répertoriées dans la spécification R-DTI pour utilisation comme CIN, mais dépendent d'une méthode de synchronisation différente, actuellement non prise en charge par Cisco.

La DRE doit atteindre l'horloge principale via le CIN. Le routeur cBR-8 peut accéder à l'horloge principale via des interfaces WAN (Wide Area Network) sur la carte d'interface physique (PIC) du superviseur ou via des interfaces DPIC (Digital PIC) sur la carte de ligne par câble (l'option DPIC a été ajoutée dans la version 16.8.1). Il est recommandé que la DRE ne passe pas par le cBR-8 pour accéder à l'horloge principale.

Le RPD et le cBR-8 ne peuvent fonctionner que comme des horloges esclaves dans le logiciel actuel, bien que la feuille de route du cBR-8 ajoute la prise en charge de cette horloge principale et limite.

Note: Une fois que le cBR-8 est configuré pour utiliser le protocole PTP pour la synchronisation, toutes les cartes de ligne s'appuient sur cette horloge, même les cartes de ligne avec des PIC RF.

Cela signifie que les problèmes de stabilité de l'horloge PTP affectent tous les modems d'un châssis, même ceux des cartes de ligne CCAP intégré (I-CCAP), lorsque vous utilisez un mélange de cartes dans un châssis.

Protocol

PTP est défini sous la norme IEEE 1588-2008.

Les spécifications complètes sont disponibles ici : 1588-2008 - Norme IEEE pour un protocole de synchronisation d'horloge de précision pour les systèmes de mesure et de contrôle en réseau.

Note: Vous devez avoir des utilisateurs enregistrés pour avoir accès au document en entier.

Le protocole PTP permet de distribuer le temps et la fréquence via un réseau :

- Heure (synchronisation) : synchronise le temps entre les périphériques d’un réseau.

- Fréquence (syntonisation) : synchronise la fréquence.

Le protocole PTP utilise la multidiffusion ou la monodiffusion et les ports UDP 319 (pour les événements) et UDP 320 (pour les messages généraux)

Sur la mise en oeuvre du CMTS, le protocole PTP utilise la monodiffusion IPv4.

Le protocole crée une relation maître-esclave entre une horloge maître et les périphériques clients via le réseau. La façon dont PTP choisit une horloge à distribuer dans un réseau consiste à utiliser un algorithme appelé Best Master Clock Algorithm (BCMA).

L’algorithme détermine la meilleure horloge d’un réseau avec les propriétés suivantes :

- Identificateur (numéro, construit à partir de l'adresse MAC du périphérique, ressemble généralement au format EUI-64 (xxxx:xxFF:FExx:xxxx).

- Qualité.

- clockPrécision : Détermine la précision de l'horloge.Plus la valeur est faible, mieux c'est (plus la précision est grande).

Value (hex) Specification

00-1F Reserved

20 The time is accurate to within 25 ns

21 The time is accurate to within 100 ns

22 The time is accurate to within 250 ns

23 The time is accurate to within 1 µs

24 The time is accurate to within 2.5 µs

25 The time is accurate to within 10 µs

26 The time is accurate to within 25 µs

27 The time is accurate to within 100 µs

28 The time is accurate to within 250 µs

29 The time is accurate to within 1 ms

2A The time is accurate to within 2.5 ms

2B The time is accurate to within 10 ms

2C The time is accurate to within 25 ms

2D The time is accurate to within 100 ms

2E The time is accurate to within 250 ms

2F The time is accurate to within 1 s

30 The time is accurate to within 10 s

31 The time is accurate to >10 s

32–7F Reserved

80–FD For use by alternate PTP profiles

FE Unknown

FF Reserved

- clockClass : Reflète la traçabilité de l'heure et de la fréquence distribuées par l'horloge GrandMaster.
Les classes d'horloge sont définies par les spécifications IEEE 1588-2008 en tant que telles :

clockClass (décimal)

0 Reserved to enable compatibility with future versions.

1–5 Reserved.

6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be PTP. A clockClass 6 clock shall not be a slave to another clock in the domain.

7 Shall designate a clock that has previously been designated as clockClass 6 but that has lost the ability to synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The timescale distributed shall be PTP. A clockClass 7 clock shall not be a slave to another clock in the domain.

8 Reserved.

9–10 Reserved to enable compatibility with future versions.

11–12 Reserved.

13 Shall designate a clock that is synchronized to an application-specific source of time. The timescale distributed shall be ARB. A clockClass 13 clock shall not be a slave to another clock in the domain.

14 Shall designate a clock that has previously been designated as clockClass 13 but that has lost the ability to synchronize to an application-specific source of time and is in holdover mode and within holdover specifications. The timescale distributed shall be ARB. A clockClass 14 clock shall not be a slave to another clock in the domain.

15–51 Reserved.

52 Degradation alternative A for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 52 shall not be a slave to another clock in the domain.

53–57 Reserved.

58 Degradation alternative A for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 58 shall not be a slave to another clock in the domain.

59–67 Reserved.

68–122 For use by alternate PTP profiles.

123–127 Reserved.

128–132 Reserved.

133–170 For use by alternate PTP profiles.

171–186 Reserved.

187 Degradation alternative B for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 187 may be a slave to another clock in the domain.

188–192 Reserved.

193 Degradation alternative B for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 193 may be a slave to another clock in the domain.

194–215 Reserved.

216–232 For use by alternate PTP profiles.

233–247 Reserved.

248 Default. This clockClass shall be used if none of the other clockClass definitions apply.

249–250 Reserved.

251 Reserved for version 1 compatibility; see Clause 18.

252–254 Reserved.

255 Shall be the clockClass of a slave-only clock; see 9.2.2.

- Priorité : valeur attribuée par l'administrateur (entre 0 et 255)

- Variance - La stabilité estimée de l'horloge

Processus D'Échange D'Horodatage Master Et Slave

- Le maître envoie un message Sync à l'esclave et prend note de l'heure (t1) à laquelle il a été envoyé.

- L'esclave reçoit le message Sync et note l'heure de réception (t2).

- Le maître transmet à l'esclave l'horodatage t1 ; il incorpore l'horodatage t1 dans un message de suivi.

- L'esclave envoie un message Delay_Req au maître et note l'heure (t3) à laquelle il a été envoyé.

- Le maître reçoit le message Delay_Req et note l'heure de réception (t4).

- Le maître transmet à l'esclave l'horodatage t4 ; il l'intègre dans un message Delay_Resp.

Ce processus est répété plusieurs fois par seconde (généralement 16 à 32 fois par seconde) afin d'assurer une adaptation rapide en cas de petits décalages.

Horloge GrandMaster

Le GrandMaster communique avec les esclaves qui ont établi des sessions avec le grand maître afin d'échanger les informations de synchronisation (Time) et de synchronisation avec ces esclaves. en théorie, un GrandMaster doit être connecté à un PRTC (Prime Reference Time clock), tel un GPS via une antenne GPS, de cette façon, si un GrandMaster tombe en panne et un autre GrandMaster prend le relais, puisque tous deux utilisent la même référence temporelle, les esclaves continuent à utiliser la même référence temporelle. Si vous n'utilisez pas de code PRTC, la défaillance d'une horloge GrandMaster entraîne la modification de la référence temporelle par les esclaves, ce qui entraîne, dans les scénarios CMTS, la mise hors ligne des modems.

Horloge esclave

L'esclave initie la connexion à l'horloge GrandMaster. L'esclave et le maître échangent leurs paramètres de configuration et d'horloge afin de commencer la négociation. Dans ce cas, cBR-8 et RPD sont tous deux esclaves d'un PTP GrandMaster externe.

Avertissement : Le déploiement cBR-8 actuel (à partir de 16.10.1d) ne prend en charge que cBR-8 en tant qu'esclave PTP. Dans le futur, nous pourrions voir la frontière PTP ou le maître PTP.

Horloge de limite

L’horloge de frontière synchronise deux segments de réseau ensemble. Agit comme esclave à une horloge Grand Master (GM) sur le segment 1, puis agit comme horloge GM sur le segment 2. Les horloges non limitrophes sont appelées horloges ordinaires.

Classes d'horloge

Les classes d'horloge sont l'une des valeurs utilisées lors de la négociation pour déterminer quelle horloge, dans un réseau avec plusieurs horloges, est la plus précise.

Les classes d'horloge sont définies par la norme IEEE 1588-2008.

États de l'horloge

- FREERUN : N'est connecté à aucun GM distant, utilise un oscillateur local.

- ATTENTE : Perte de connexion à un GM distant, tentative de récupération et tentative de maintien de l'horloge précédente. Pendant l'état HOLDOVER, l'horloge peut commencer à dériver, et si elle dérive en dehors des spécifications, elle revient au mode FREERUN.

- ACQUISITION : Début de la négociation avec GM et échange de messages avec le GM pour déterminer le délai induit par le réseau et tenter de se synchroniser avec l'horloge GM.

- FREQ_LOCKED : Le périphérique esclave est verrouillé sur le maître par rapport à la fréquence, mais n'est pas aligné sur la phase.

- PHASE_ALIGNÉ : Verrouillé au maître par rapport à la fréquence et à la phase.

Machine d'état pour RPD :

Note: Dans le cas des déploiements RPHY, la période HOLDOVER en spécification prise en charge est de 10 heures (c'est-à-dire lorsque cBR-8 ou RPD ou les deux sont à l'état HOLDOVER). Pendant ce temps, les modems restent en ligne. Après 10 heures de HOLDOVER, la qualité de l'horloge interne de l'oscillateur n'est pas garantie et les modems peuvent tomber hors ligne à cause de l'horloge cBR-8, RPD ou les deux dériver hors spécification.

Domaines PTP

Le domaine PTP est un nombre qui identifie un groupe de périphériques qui communiquent ensemble. Les périphériques esclaves et maîtres doivent se trouver dans le même domaine PTP pour pouvoir se synchroniser. Le domaine 0 est le domaine par défaut et les domaines 1-2-3 sont réservés par spécification. Les autres numéros de domaine peuvent être compris entre 4 et 255,

Notez que certaines variantes PTP telles que G.8275.2 nécessitent que le domaine PTP se trouve dans la plage 44-63. Par conséquent, si vous n'utilisez pas cette variante, évitez d'utiliser cette plage de domaines PTP, car cela peut confondre l'utilisateur et le périphérique.

Profils PTP

Les profils PTP ont été introduits dans la norme IEEE 1588-2008 et comprennent un ensemble d'options de configuration pouvant être sélectionnées pour répondre aux exigences de différentes applications. Il est possible de définir des profils distincts afin d'adapter PTP à différents scénarios.

Exemples de profils PTP courants :

- Profil Telecom-2008 : Profil générique utilisé avant les spécifications G.8265.1. Ce profil utilise les numéros de domaine 0-4. Ce profil est pris en charge sur cBR-8 et RPD, cependant, G.8275.2 est fortement recommandé par rapport à celui-ci, car il est plus résistant aux défaillances.

- G.8265.1 : Profil de télécommunications de protocole de temps de précision pour la synchronisation de fréquence

Ce profil est destiné aux applications qui nécessitent une synchronisation de fréquence uniquement sur les réseaux de télécommunications. Il ne couvre pas l'alignement des phases et/ou l'heure de la journée.

Le cas d'utilisation concerne les maîtres et les esclaves PTP dans les réseaux où les noeuds intermédiaires ne prennent pas en charge PTP.

Note: Ce profil n'est pas pris en charge dans l'environnement DOCSIS avec cBR-8 et RPD

- G.8275.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation phase/temps avec prise en charge de la synchronisation complète à partir du réseau

Ce profil est utilisé dans les systèmes qui nécessitent une synchronisation précise de l'heure et de la phase dans les réseaux de télécommunications (par exemple, réseau cellulaire 4G ou réseau RPD) où une synchronisation de phase et/ou d'heure est requise.

Avec ce profil, chaque périphérique réseau participe au protocole PTP. Une horloge de limite est utilisée à chaque noeud de la chaîne entre le maître de réseau PTP et l'esclave PTP, ce qui réduit l'accumulation d'erreurs temporelles sur le réseau.

- G.8275.2 : Profil de télécommunications de protocole de temps de précision pour la synchronisation temps/phase avec prise en charge de la synchronisation partielle à partir du réseau

Ce profil est basé sur la prise en charge de la synchronisation partielle du réseau, ce qui signifie que les noeuds du domaine PTP n'ont pas besoin d'être directement connectés.

Comme le G.8275.1, il est utilisé dans les systèmes qui nécessitent une synchronisation précise du temps et de la phase, mais permet d'exécuter la synchronisation de la phase et du temps sur les réseaux existants. Il utilise des horloges de limite si nécessaire pour régler le signal temporel sur l’ensemble du réseau.

Pour plus d'informations sur les plates-formes G.8275.1 et G.8275.2 pour ASR900, cliquez ici : Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)

Définition des messages de base

- Sync, Follow_up, Delay_req, Delay_resp sont des messages utilisés par les horloges de frontière et ordinaires pour communiquer des informations d'heure aux esclaves sur le réseau.

- Les messages d'annonce sont échangés à la fois par les esclaves et par le maître pour identifier la meilleure horloge du réseau à l'aide de l'algorithme Best Master Clock (reportez-vous aux images 26, 27 et 28 des spécifications IEEE pour le mécanisme détaillé).

- Les messages de signalisation sont utilisés pour les informations non critiques.

Conditions requises

Ces exigences doivent être satisfaites pour un déploiement correct de PTP dans un cBR-8 et R-PHY dans un réseau de production :

- Utilisez le profil PTP G.8275.2, qui garantit que le protocole PTP fonctionne correctement même si certains éléments réseau du chemin ne prennent pas en charge le protocole PTP

- Pas de chemins ECMP (Equal-Cost Multi-Path), d'équilibrage de charge ou d'asymétrie : PTP suppose toujours que le délai entre le maître et l'esclave et vice versa est égal, et dans les 500 microsecondes (μs)

- Configurez les intervalles de délai et de synchronisation avec les valeurs -4 ou -5 (voir le chapitre Configuration pour plus de détails). Les valeurs supérieures à -4 (-3, ...) peuvent ne pas offrir une précision suffisante pour détecter les petits changements de décalage. Les valeurs inférieures à -5 (-6,...) ont un impact plus important sur l'utilisation du réseau, mais pas un gain de précision de signification.

- Assurez-vous que les paquets PTP pour les RPD ne passent pas par le cBR-8

- Garantir une gigue minimale dans le réseau IP (1 ms max.). La QoS PTP appropriée doit être appliquée à tous les routeurs : cBR-8 et RPD envoient tous les paquets PTP marqués avec le DSCP (Differentiated Services Code Point) 46 (express forwarding - EF). Assurez-vous que l'horloge PTP Grand Master marque également les paquets avec la même valeur DSCP.

- L'horloge PTP Grand Master doit être synchronisée avec le GPS et le rapport clock-class 6, pour une utilisation sur un réseau de production. Les configurations de travaux pratiques peuvent fonctionner avec un maître PTP autonome (clock class 58).

- L'horloge PTP Grand Master doit avoir une précision d'horloge de 100 nanosecondes.

- Si deux horloges PTP Grand Master sont utilisées, vous devez utiliser le GPS pour synchroniser l'heure entre elles. Les deux grands maîtres PTP doivent avoir leurs horloges dans un délai de 500 microsecondes (μs)

Note: Les versions plus anciennes du logiciel RPD peuvent utiliser des valeurs DSCP de 47 - Les versions plus récentes utilisent des valeurs DSCP de 46 (EF) sur RPD, pour s'aligner sur les valeurs CMTS

Configuration

Cette section décrit comment configurer une horloge maître PTP sur un routeur Cisco ASR900, les horloges esclaves sur cBR-8 pour cBR-8 lui-même et RPD, et une horloge frontière sur ASR900.

Horloge maître PTP sur ASR900

Il existe une implémentation de base logicielle du protocole PTP, sous Linux, appelée ptpd. Cependant, étant donné qu'il est basé sur un logiciel, il n'offre pas assez de précision pour que le cBR-8 et le RPD fonctionnent avec lui, par conséquent, les modems ne pourront pas se connecter et la synchronisation PTP ne se produira pas non plus. En outre, l'implémentation de linux PTPd nécessite un horodatage matériel par la carte réseau afin d'augmenter la précision. Cela signifie que lorsque vous utilisez une machine virtuelle ou une carte réseau qui ne prend pas en charge l'horodatage matériel, PTPd peut même ne pas démarrer sous Linux.

Selon le modèle de l'ASR900 utilisé, il peut ou non avoir une antenne GPS. Si l'ASR900 n'a pas d'antenne GPS, vous n'avez pas de PRTC, mais vous pouvez toujours exécuter l'ASR900 en tant que Grand-Maître avec un PRTC local (oscillateur interne). Cela signifie que si cet ASR900 échoue et qu'un autre ASR900 prend le relais, le cBR-8 et le RPD perdent la référence temporelle en raison du fait que les deux horloges ne sont pas synchronisées.

Étape 1. Configurer L'Oscillateur Interne Local

network-clock source quality-level QL-PRC tx

network-clock synchronization automatic

network-clock synchronization mode QL-enabled

network-clock synchronization squelch-threshold QL-PRC

network-clock quality-level tx QL-PRC ptp domain 0

network-clock input-source 1 External R0 10m

Étape 2. Configurer PTP en tant que maître sur l'ASR900

ptp clock ordinary domain 0                             <<< DOMAIN 0 or DOMAIN 44 for G.8275.2

clock-port MASTER master [profile g8275.2]             <<< EITHER DEFAULT OR G.8275.2 PROFILE

sync interval -4

sync one-step

transport ipv4 unicast interface Lo1588 negotiation    <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface

interface Loopback1588

ip address 15.88.15.88 255.255.255.255

end

Note: Si aucun oscillateur local ou GPS n'est configuré comme source, le maître du mode PTP n'est pas disponible.

Si vous choisissez d'utiliser le profil G.8275.2 dans votre environnement au lieu du profil par défaut, vous devez le spécifier dans la configuration du port d'horloge (pour la configuration du profil G.8275.2 sur le cBR-8, reportez-vous à la section : Profil G.8275.2).

Notez que même si IOS-XE permet de configurer le profil G.8265.1, cela n'est pas pris en charge dans l'environnement DOCSIS avec cBR-8 et RPD.

Pour obtenir de plus amples informations sur le profil G.8275.2 de l'ASR900, consultez le guide suivant : Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)

Vérification

Cette section fournit des informations que vous pouvez utiliser afin de vérifier que votre configuration fonctionne correctement.

ASR900#show ptp clock running

PTP Ordinary Clock [Domain 0]

State Ports Pkts sent Pkts rcvd Redundancy Mode

FREQ_LOCKED 1 86307034 36108234 Hot standby

PORT SUMMARY

PTP Master

Name Tx Mode Role Transport State Sessions Port Addr

MASTER unicast master Lo1588 Master 1 -

Note: Lors de la première configuration de l'oscillateur interne, l'oscillateur doit se réchauffer avant d'être stable. Par conséquent, cela peut prendre un certain temps avant que l'état du PTP soit FREQ_LOCKED. Cela peut prendre jusqu'à 35 minutes.

ASR900#show ptp clock dataset parent

CLOCK [Ordinary Clock, domain 0]

Parent Clock Identity: 0x34:6F:90:FF:FE:C1:66:3F

Parent Port Number: 0

Parent Stats: No

Observed Parent Offset (log variance): 0

Observed Parent Clock Phase Change Rate: 0

Grandmaster Clock:

Identity: 0x34:6F:90:FF:FE:C1:66:3F

Priority1: 128

Priority2: 128

Clock Quality:

Class: 58

Accuracy: Within 1s

Offset (log variance): 52592

ASR900#show platform software ptpd stat stream 0

LOCK STATUS : FREERUN

SYNC Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval 0

Tx packets : 5577, Rx Packets : 0

Last Seq Number : 5577, Error Packets : 0

Delay Req Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 0, Rx Packets : 5353

Last Seq Number : 0, Error Packets : 0

Delay Response Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 5353, Rx Packets : 0

Last Seq Number : 0, Error Packets : 0

Announce Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 1904, Rx Packets : 0

Last Seq Number 1904 Error Packets 0

Signalling Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 1, Rx Packets : 1

Last Seq Number : 1, Error Packets : 0

Current Data Set

Offset from master : +0.0

Mean Path Delay : +0.0

Forward Path Delay : +0.0

Reverse Path Delay : +0.0

Steps Removed 0

General Stats about this stream

Packet rate : 0, Packet Delta (ns) : 0

Clock Stream handle : 0, Index : 0

Oper State : 0, Sub oper State : 6

Log mean sync Interval : 0, log mean delay req int : 0

Note: Par défaut, l'oscillateur interne ASR900 signale la classe 58. Si vous utilisez une horloge GM tierce, vous pouvez voir la classe d'horloge 6 aussi si la synchronisation avec le GPS

Horloge esclave sur cBR-8

Le cBR-8 agit comme le noyau du CCAP de la DPR, de sorte qu'il est responsable de la configuration PTP de lui-même et des DPR associées.

Le cBR-8 utilise des profils pour obtenir ces informations PTP aux RPD, et plusieurs options pour le PTP sont configurables :

- Le type de suivi de servo pour le cBR-8 doit être défini sur R-DTI pour accélérer la synchronisation d'horloge.

- Le cBR-8 utilise une adresse de bouclage définie par l'utilisateur comme source de ses paquets PTP. Assurez-vous qu'il existe un routage approprié pour l'horloge principale pour atteindre l'interface de bouclage. Si vous ne parvenez pas à envoyer une requête ping à l'horloge maître avec un paquet provenant de l'adresse de bouclage, le protocole PTP n'est pas opérationnel.

- Le profil G.8275.2 Telecom est recommandé car il prend en charge les protocoles IPv4 et IPv6, et les périphériques de commutation intermédiaires du CIN n'ont pas besoin d'être compatibles PTP.

- Le numéro de domaine PTP est choisi par l'utilisateur mais doit être identique pour le cBR-8 et le RPD.

Les paquets PTP sont marqués avec une QoS plus élevée par la RPD et le cBR-8 pour la priorité sur le CIN. La valeur DSCP 46/EF est utilisée par défaut sur les deux.

ptp clock ordinary domain 0

servo tracking-type R-DTI

clock-port TOMASTER slave

announce interval -3

announce timeout 10

delay-req interval -4                                 <<< RECOMMENDED VALUE

sync interval -4                                      <<< RECOMMENDED VALUE

transport ipv4 unicast interface Lo1588 negotiation   <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface

clock source 15.88.15.88                              <<< THIS IS YOUR PTP MASTER

clock source 15.88.2.8 1                              <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)

Dans cet exemple, le port d'horloge est configuré pour utiliser le profil PTP par défaut. Pour la configuration du profil G.8275.2, reportez-vous à la section : Profil G.8275.2.

Note: La valeur recommandée pour les intervalles de synchronisation et de demande de délai est -4 (16 pps) ou -5 (32 pps). Il est recommandé de ne pas utiliser de valeurs supérieures à -4 (-3,...). Les intervalles d'annonce peuvent être définis sur n'importe quel intervalle inférieur ou égal à 0 (0,-1,-2,-3).

Avec la configuration de redondance PTP, si le maître devient inaccessible, les commutateurs cBR-8 sont dirigés vers l'autre source et dès que le maître est à nouveau disponible, le cBR-8 revient à la source principale.

Vérification

Vérifiez avec cette commande que l'état est PHASE_ALIGNED et que les paquets envoyés et reçus sont plus nombreux :

cBR-8#show ptp clock running domain 0

PTP Ordinary Clock [Domain 0]

State          Ports     Pkts sent   Pkts rcvd   Redundancy Mode

PHASE_ALIGNED  1         462249      1104590     Hot standby

PORT SUMMARY

PTP Master

Name      Tx Mode    Role    Transport   State    Sessions     Port Addr

TOMASTER  unicast    slave   Lo1588      Slave    1            15.88.15.88

SESSION INFORMATION

TOMASTER [Lo1588] [Sessions 1]

Peer addr     Pkts in    Pkts out  In Errs  Out Errs

15.88.15.88   1104590    462249    0        0

Restrictions

- Pour le moment, cBR-8 ne prend pas en charge PTP sur MPLS, donc si les paquets PTP sont étiquetés MPLS, l'horloge ne se synchronise pas. Il existe une demande d'amélioration pour que cette fonctionnalité soit prise en charge et vous pouvez suivre les mises à jour éventuelles à l'adresse suivante : CSCvj02809.

- En tant que profil PTP, vous pouvez soit utiliser le profil par défaut (comme jusqu'à présent), soit spécifier le profil G.8275.2 (recommandé) comme décrit dans la section suivante. Notez que même si IOS-XE permet de configurer le profil G.8265.1, cela n'est pas pris en charge dans l'environnement DOCSIS avec cBR-8 et RPD.

Profil G.8275.2

Vous pouvez configurer le profil G.8275.2 sur l'esclave cBR-8 avec une source GM de cette manière :

ptp clock ordinary domain 44

servo tracking-type R-DTI

clock-port TOMASTER slave profile g8275.2   <<<<<<<<<<

announce interval -3

announce timeout 10

delay-req interval -4

sync interval -4

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.15.88

Note: lorsque la source PTP n'est pas directement connectée et qu'il y a plusieurs sauts entre les deux, il est recommandé d'utiliser le profil G.8275.2

Comme mentionné précédemment dans cet article, la limite PTP n'est pas encore prise en charge sur le cBR-8. Cependant, si vous voulez configurer le profil G.8275.2 sur l'esclave cBR-8 avec deux sources GM, vous devez utiliser la définition de domaine frontière de cette manière :

ptp clock boundary domain 44

servo tracking-type R-DTI

clock-port slave1 profile g8275.2

<...>

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.15.88        <<< THIS IS YOUR PTP MASTER

clock-port slave2 profile g8275.2

<...>

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.2.8          <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY

Note: Malgré le mot clé de limite, le cBR-8 fonctionne comme une horloge ordinaire. Cette configuration de limite doit et ne peut être utilisée que dans ce cas spécifique : configuration PTP redondante avec 2 GM utilisant le profil g8275.2 sur l'esclave cBR-8.

Horloge esclave sur RPD

Malgré cette configuration RPD, elle doit être saisie sur le cBR-8 lui-même, puisque le cBR-8 provisionne le périphérique Remote Phy.

ptp r-dti 1

[profile G.8275.2]                    <-- ONLY IF SPECIFIED IN THE cBR-8 PTP CONFIGURATION

ptp-domain 0

clock-port 1

clock source ip 15.88.15.88           <-- THIS IS YOUR PTP MASTER

clock source ip 15.88.2.8 alternate   <-- THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)

sync interval -4

announce interval -3

Attention : le numéro de domaine ptp doit être le même que celui configuré sur le maître PTP.

Attention : Si la commande ethernet <index> n'est pas configurée sous clock-port <number>, l'index ethernet par défaut est égal au numéro clock-port configuré. Cela correspond aux ports physiques de la RPD (Ethernet 1 correspond à vbh0, Ethernet 2 à vbh1). Si cette configuration ne correspond pas au port physique utilisé sur le RPD, elle ne se synchronise pas avec l'horloge.

Note: Les intervalles de synchronisation et d'annonce sont spécifiés dans l'échelle log2.

Value Log calculation Value in seconds

-5   2^-5        1/32s

-4   2^-4        1/16s

-3   2^-3        1/8s

-2   2^-2        1/4s

-1   2ˆ-1        1/2s

0    2^0         1s

1    2^1         2s

2    2^2         4s

3    2^3         8s

4    2^4         16s

5    2^5         32s

Vérification

Ces commandes émises à partir de la console RPD peuvent être utilisées pour vérifier l'état PTP, qui doit être dans PHASE_LOCK et SUB_SYNC, et les compteurs de réponse de synchronisation, de demande de délai et de délai qui doivent augmenter :

# ssh 10.6.17.9 -l admin

R-PHY>ena

R-PHY#show ptp clock 0 state

apr state : PHASE_LOCK       <<<

clock state : SUB_SYNC       <<<

current tod : 1506419132 Tue Sep 26 09:45:32 2017

active stream : 0

==stream 0 :

port id : 0

master ip : 15.88.15.88

stream state : PHASE_LOCK    <<< Stream state must be PHASE_LOCK

Master offset : 1212         <<< Master offset (in ns) must be as close to 0 as possible

Path delay : -81553

Forward delay : -80341       <<< Forward delay and reverse delay must be within 500us of each other

Reverse delay : -77791       <<< Forward delay and reverse delay must be within 500us of each other

Freq offset : -86279

1Hz offset : -615

R-PHY#show ptp clock 0 statistics

<output omitted>

streamId  msgType           rx          rxProcessed     lost        tx

0        SYNC              8585001     8584995         0           0          <<<<<<

0        DELAY REQUEST     0           0               0           8585000    <<<<<<

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    8584998     8584998         5           0          <<<<<<

0        P-DELAY FOLLOWUP  0           0               0           0

0        ANNOUNCE          536571      536571          0           0

0        SIGNALING         5593        5593            0           5591

0        MANAGEMENT        0           0               0           0

TOTAL                    17712163    17712157        5           8590591

Note: PHASE_LOCK est l'état correct lorsque tout fonctionne. Voir la section État de l'horloge pour d'autres états et leur définition.

Avertissement : Il y a eu des problèmes de stabilité de l'horloge sur les RPD avec des changements importants dans le délai réseau entre le maître PTP et le RPD (changements de plus de 5 ms). Le RPD peut revenir à une synchronisation freerun, ce qui peut provoquer de nombreux problèmes, comme la mise hors ligne de modems. RPD versions V6.7 et ultérieures, filtre les gros paquets de gigue et règle le seuil de délai pour améliorer la stabilité PTP.

Horloge de limite sur ASR900

Supposez que vous voulez configurer une horloge de limite comme maître secondaire pour cBR-8 et RPD, au cas où l'horloge maître échoue ou devient inaccessible. Cette horloge frontière utilise une source maître différente à des fins de redondance (dans cet exemple, 15.88.200.8). La configuration de l'horloge maître dans ce scénario n'est pas différente de celle décrite précédemment. Elle est donc omise dans cette section.

ptp clock boundary domain 0

clock-port TO-MASTER slave

sync interval -5

transport ipv4 unicast interface Lo2008 negotiation

clock source 15.88.200.8      <<< THE PTP MASTER (Different from PTP master described above)

clock source 15.88.20.8 1     <<< AN ALTERNATE MASTER USED FOR REDUNDANCY (OPTIONAL)

clock-port TO-SLAVE master

transport ipv4 unicast interface Lo1588 negotiation

interface Loopback1588

ip address 15.88.2.9 255.255.255.255

end

Surveillance avec SNMP

Afin de surveiller le nombre de sessions ptp sur l'ASR900 et cBR-8 avec SNMP, vous pouvez utiliser :

Objet - cPtpClockPortNumOfAssociatedPorts

OID - 1.3.6.1.4.1.9.9.760.1.2.7.1.10

Dépannage

Cette section fournit des renseignements qui vous permettront de régler les problèmes de configuration.

Dépannage du maître PTP (ASR900)

Sur le maître, la chose la plus importante est de s'assurer que PTP a une source d'horloge réseau pour la synchronisation, soit une antenne GPS (préférée), soit un oscillateur local.

Afin de vous assurer que la source network-clock fonctionne comme prévu, vous pouvez utiliser la commande :

ASR900#show network-clocks synchronization

Symbols: En - Enable, Dis - Disable, Adis - Admin Disable

NA - Not Applicable

* - Synchronization source selected

# - Synchronization source force selected

& - Synchronization source manually switched

Automatic selection process : Enable

Equipment Clock : 2048 (EEC-Option1)

Clock Mode : QL-Enable

ESMC : Enabled

SSM Option : 1

T0 : Internal

Hold-off (global) : 300 ms

Wait-to-restore (global) : 300 sec

Tsm Delay : 180 ms

Revertive : No

Nominated Interfaces

Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx

*Internal NA NA/Dis 251 QL-SEC NA NA   <<<<<

External R0 10M NA/Dis 1 QL-FAILED NA NA

Gi0/2/5 NA Sync/En 1 QL-FAILED QL-PRC -

Dépannage de l'esclave PTP (cBR-8)

Sur le cBR-8 en tant qu'esclave, il est important de noter que le prend uniquement en charge les interfaces DPIC SUP pour se connecter au maître PTP (à partir de maintenant), donc n'utilisez pas l'interface Gig0 ou les interfaces PIC RPHY, car PTP pourrait ne pas fonctionner par ces interfaces.

Note: Référez-vous au Guide de configuration du logiciel du périphérique PHY distant Cisco pour plus d'informations.

Au cours de la négociation PTP initiale, le cBR-8 peut prendre jusqu'à 35 minutes pour régler et aligner son horloge sur l'horloge du maître PTP. Pendant ce temps, l'horloge est affichée en état ACQUISITION sur cBR-8 :

cBR-8#show ptp clock running

PTP Ordinary Clock [Domain 0]

State      Ports     Pkts sent     Pkts rcvd     Redundancy Mode

ACQUIRING  1         687           1995          Hot standby

PORT SUMMARY

PTP Master

Name       Tx Mode     Role     Transport    State           Sessions   Port Addr

TOMASTER   unicast     slave    Lo1588       Uncalibrated    1          15.88.15.88

Si l'état ACQUIRING reste là pendant plus de 35 minutes, cela peut indiquer que l'horloge principale PTP n'est pas très précise et dérive d'avant en arrière, ce qui empêche le cBR de pouvoir ACQUIRE correctement. Ceci peut être vu avec un serveur Linux avec PTPd par exemple.

L'horloge PTP sur le cBR-8 et le RPD doit être synchronisée avec le maître avant de résoudre les problèmes DOCSIS. Plusieurs commandes peuvent afficher cet état ainsi que le nombre de paquets. Vous voulez voir l'incrément de paquets pour la synchronisation, la demande de délai et la réponse de délai dans ce résultat :

cBR-8#show platform software ptpd stat stream 0

LOCK STATUS : PHASE LOCKED                          <<<<<<< must be PHASE LOCKED

SYNC Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -5, Acting Interval -5

Tx packets : 0,  Rx Packets : 24074045            <<<<<<< Rx Packets must increase

Last Seq Number : 42454,  Error Packets : 0       <<<<<<< Last Seq Number must increase

Delay Req Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : -5

Tx packets : 24077289, Rx Packets : 0             <<<<<<< Tx Packets must increase

Last Seq Number : 0, Error Packets : 0

Delay Response Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -5, Acting Interval : -5

Tx packets : 0, Rx Packets : 23983049             <<<<<<< Rx Packets must increase

Last Seq Number : 31420, Error Packets : 0        <<<<<<< Last Seq Number must increase

Announce Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -3, Acting Interval : -3

Tx packets : 0, Rx Packets :  6030915             <<<<<<< Rx Packets must increase

Last Seq Number 44276 Error Packets 0             <<<<<<< Last Seq Number must increase

Signalling Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 9944, Rx Packets : 9521              <<<<<<< Tx Packets and Rx Packets must increase

Last Seq Number : 0, Error Packets : 0

<output omitted>

Le numéro de flux peut être vérifié sous la commande déjà introduite show ptp clock running domain 0, sous la section SESSION INFORMATION. La première session est le flux 0, la seconde le flux 1, etc.

Si certains compteurs n’augmentent pas, il est possible d’avoir un problème de réseau et il est recommandé de vérifier la perte de paquets.

DTI et PTP

Afin de configurer PTP sur le cBR-8, le DTI de l'horloge de câble doit être DÉSACTIVÉ, sinon le message suivant s'affiche :

%[PTP]: NetSync source already configured. PTP slave configuration not allowed.

Enfin, la carte de ligne I-CMTS éventuellement insérée dans le même châssis repose sur la synchronisation PTP. Par conséquent, une panne potentielle sur l'horloge GM PTP peut également affecter les modems situés derrière une carte de ligne I-CMTS.

Délais d'horloge et décalage

Afin de vérifier le décalage de l'horloge maître, et quels sont les retards sur le chemin de transfert vers le chemin maître et le chemin inverse, vous pouvez utiliser cette commande introduite précédemment, et filtrer par la section Jeu de données actuel.

Le décalage du maître doit être aussi proche de 0 que possible et le délai du chemin de transfert doit être aussi égal que possible au délai du chemin inverse.

Voici un exemple avec de bonnes valeurs, comparées aux mauvaises valeurs capturées lors d'une situation problématique :

----------------- GOOD -----------------

cBR-8#show platform software ptpd stat stream 0 | s Current Data Set

Current Data Set

Offset from master : -0.000000313

Mean Path Delay    : +0.000025042

Forward Path Delay : +0.000024729

Reverse Path Delay : +0.000024660

--------------- NOT GOOD ---------------

cBR-8#show platform software ptpd stat stream 0 | s Current Data Set

Current Data Set

Offset from master :  +0.002812485

Mean Path Delay    :  +0.000022503

Forward Path Delay :  +0.002834302

Reverse Path Delay :  -0.002789295

Les valeurs sont exprimées en secondes (d'où le chiffre le moins significatif, le chiffre le plus à droite, est de nanoseconde), et le décalage du masque est calculé comme le délai moyen du chemin, moins le retard du chemin avancé.

Le délai moyen du chemin est calculé comme la moyenne entre l'avant et l'arrière : (retard de chemin de transfert + retard de chemin inverse) / 2.

Dans le monde idéal, le décalage de master serait égal à 0, car le retard de chemin avant serait égal au retard de chemin inverse, ce qui les rend tous deux égaux au retard de chemin moyen.

En fonction de l'asymétrie entre le chemin d'accès avancé et le chemin inverse, vous pouvez avoir un décalage négatif du maître (si le délai du chemin inverse est supérieur au délai du chemin d'accès avancé) ou un décalage positif (si le délai du chemin inverse est inférieur au délai du chemin d'accès avancé).

Si la valeur de décalage est trop importante, ou si vous observez des valeurs très fluctuantes, il est possible que ce soit un problème de gigue, ou une horloge principale inexacte.

Plus la gigue est élevée, plus le RPD ou cBR-8 est long à passer en état PHASE_ALIGNED, et plus il faut de temps pour se remettre d'une situation HOLDOVER.

Les configurations de plusieurs chemins influencent fortement la gigue (en raison du fait que certains paquets utilisent le chemin A et que certains paquets utilisent le chemin B avec des délais différents, ce que voit le cBR-8 et le RPD comme gigue). Par conséquent, il est nécessaire que le trafic PTP utilise un seul chemin (non équilibré en charge sur plusieurs liaisons).

Dépannage de l'esclave PTP (RPD)

Sur RPD, toutes les commandes intéressantes sont sous le parapluie show ptp :

R-PHY#show ptp clock 0 state

apr state : PHASE_LOCK

clock state : SUB_SYNC

current tod : 1506426304 Tue Sep 26 11:45:04 2017

active stream : 0

==stream 0 :

port id : 0

master ip : 15.88.15.88

stream state : PHASE_LOCK

Master offset : 6010

Path delay : -78442

Forward delay : -72432

Reverse delay : -81353

Freq offset : -86206

1Hz offset : -830

R-PHY#show ptp clock 0 statistics

AprState 6 :

2@0-00:14:54.347 3@0-00:14:15.945 2@0-00:06:24.766

1@0-00:06:15.128 0@0-00:03:59.982 4@0-00:03:40.782

ClockState 5 :

5@0-00:06:49.252 4@0-00:06:46.863 3@0-00:06:43.016

2@0-00:06:25.017 1@0-00:06:24.728

BstPktStrm 3 :

0@0-00:14:45.560 4294967295@0-00:14:07.272 0@0-00:06:15.160

StepTime 1 :

406874666@0-00:05:46.080

AdjustTime 99 :

427@0-02:05:11.705 -414@0-02:04:10.705 -396@0-02:03:09.705

145@0-02:02:08.705 -157@0-02:00:06.705 327@0-01:58:04.705

-195@0-01:57:03.705 -46@0-01:56:02.705 744@0-01:55:01.705

streamId msgType rx rxProcessed lost tx

0 SYNC 246417 246417 4294770689 0

0 DELAY REQUEST 0 0 0 118272

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 117165 117165 4294902867 0

0 P-DELAY FOLLOWUP 0 0 0 0

0 ANNOUNCE 82185 82184 4294901761 0

0 SIGNALING 78 78 0 78

0 MANAGEMENT 0 0 0 0

TOTAL 445845 445844 12884575317 118350

R-PHY#show ptp clock 0 config

Domain/Mode : 0/OC_SLAVE

Priority 1/2/local : 128/255/128

Profile : 001b19000100-000000 E2E

Total Ports/Streams : 1 /1

--PTP Port 1, Enet Port 1 ----

Port local Address :10.6.17.9

Unicast Duration :300 Sync Interval : -5

Announce Interval : -3 Timeout : 11

Delay-Req Intreval : -4 Pdelay-req : -4

Priority local :128 COS: 6 DSCP: 47

==Stream 0 : Port 1 Master IP: 15.88.15.88

Note: Pour plus d'informations sur les performances RPD, consultez l'article Dépannage des problèmes de performances du débit DOCSIS RPD

Informations connexes

- Protocole Precision Time - Wikipedia

- 1588-2008 - Norme IEEE pour un protocole de synchronisation d'horloge de précision pour les systèmes de mesure et de contrôle en réseau

- G.8265.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation de fréquence

- G.8275.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation phase/temps avec prise en charge de la synchronisation complète à partir du réseau

- G.8275.2 : profil de télécommunications de protocole de temps de précision pour la synchronisation temps/phase avec prise en charge partielle de la synchronisation à partir du réseau

- Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)

- Guide de configuration du logiciel de périphérique Cisco Remote PHY pour Cisco 1x2 RPD Software 1.1

- Dépannage des problèmes de performances du débit DOCSIS RPD