Quelle classification de QoS devrait être appliquée au NTP?

La conception de réseau de référence de solution d' entreprise QoS de Cisco suggère de classer NTP comme trafic de gestion de réseau et de le marquer comme CS2:

En répondant aux besoins de QoS du trafic de gestion de réseau, Cisco recommande les directives suivantes:

Le trafic de gestion de réseau doit être marqué vers DSCP CS2.

Les applications de gestion de réseau doivent être explicitement protégées avec une garantie de bande passante minimale.

Le trafic de gestion de réseau est important pour effectuer une analyse des tendances et des capacités et un dépannage. Par conséquent, vous pouvez provisionner une file d'attente de bande passante minimale distincte pour le trafic de gestion de réseau, qui pourrait inclure SNMP, NTP , Syslog, NFS et d'autres applications de gestion .

Étant donné que NTP est sensible à la gigue, pourquoi NTP n'est-il pas marqué comme transfert accéléré et traité de la même manière que les données vocales?

Y a-t-il une raison pour laquelle il ne devrait pas être placé dans la même file d'attente à faible latence que la voix?

— Stephen Craven
source

Je ne pense pas que "sensible à la gigue" soit une description juste du NTP. Cela explique beaucoup de choses, mais je crois que l'algorithme et les intervalles d'interrogation peuvent gérer une certaine gigue. Cela m'amènerait donc à penser qu'il n'a pas besoin d'être traité de la même manière que la voix. (Je connais cependant peu la QoS.)

— Craig Constantine

@CraigConstantine C'est exact. Dans la plupart des environnements, tant que vous pouvez obtenir une file d'attente pour battre le trafic BE, vous êtes probablement en avance de 95% sur les données, de toute façon.

— Ryan Foley

@CraigConstantine jetez un œil au RFP4594 Bonne capture Stephen. Je suppose que Cisco n'est pas en ligne avec l'IETF sur celui-ci? ...

— Ronnie Royston

Cisco est une grande entreprise avec de nombreux individus / groupes différents. Tous ne sont pas toujours d'accord sur ce qui est le mieux. Personnellement, je pense que la recommandation de l'IETF est meilleure en ce qui concerne le "timing de haute précision", mais personnellement, je ne voudrais pas que le NTP pour mon équipement réseau (que je ne qualifierais généralement pas de haute précision) soit un "timing d'horloge murale" ou DF comme le dit la RFC. La recommandation de Cisco semble être plus «intermédiaire» et conforme à ce à quoi je m'attendrais pour répondre aux besoins NTP généraux en matière d'équipement réseau.

— Apprendre

@StevenCraven, pour que cela soit une question à laquelle nous pouvons répondre, nous devons comprendre quel type d'exigences de précision vous avez pour NTP et comment il est utilisé.

— Mike Pennington

Réponses:

Réponse modifiée: NTP doit être placé dans la classe EF (identique aux paquets vocaux en temps réel) conformément aux directives de configuration RFC 4594 de l' IETF pour les classes de service DiffServ .

5.2. Cartographie pour NTP

D'après les tests qui ont été effectués, les indications sont que la distribution temporelle précise nécessite un transport à très faible variation de retard de paquet (gigue). Par conséquent, nous suggérons que les lignes directrices suivantes pour (NTP) Network Time Protocol utiliser:

o Lorsque NTP est utilisé pour fournir le calendrier de haute précision au sein d' un réseau de l' administrateur (du transporteur) ou aux utilisateurs finaux / clients, la classe de service de téléphonie doivent être utilisés et les paquets NTP doivent être marqués avec la valeur EF DSCP.

o Pour les applications qui nécessitent une précision de synchronisation "horloge murale", la classe de service standard doit être utilisée et les paquets doivent être marqués avec DF DSCP.

— Ronnie Royston
source

corrigé ci

— Ronnie Royston

NTP n'est pas particulièrement sensible à la gigue, car il utilise originateet transmithorodate pour garder une trace du retard. Ntp.org explique en détail comment il garde le retard en échec , mais voici un extrait:

La synchronisation d'un client avec un serveur réseau consiste en plusieurs échanges de paquets où chaque échange est une paire de demande et de réponse. Lors de l'envoi d'une demande, le client stocke sa propre heure (horodatage d'origine) dans le paquet envoyé. Lorsqu'un serveur reçoit un tel paquet, il stockera à son tour son propre temps (horodatage de réception) dans le paquet, et le paquet sera retourné après avoir mis un horodatage de transmission dans le paquet. Lors de la réception de la réponse, le récepteur enregistrera une fois de plus sa propre heure de réception pour estimer le temps de trajet du paquet. Le temps de déplacement (retard) est estimé à la moitié du "retard total moins le temps de traitement à distance", en supposant des retards symétriques.

La raison pour laquelle ce n'est pas dans la même catégorie que le contrôle réseau est parce qu'il n'est pas directement responsable du fonctionnement du routage / transfert des paquets. Tous les éléments de la catégorie de gestion de réseau ne sont pas des composants critiques du système de réseau dans son ensemble. Si vous avez perdu des paquets liés à SNMP, syslog ou NTP, vous ne le remarquerez probablement même pas.

SNMP retransmettrait simplement ces informations car elles sont basées sur TCP. Même si la connexion chutait tous ensemble, rien de catastrophique ne se produirait; vous pourriez simplement obtenir un agent snmp qui ne répond pas , puis réessayer. Si vous avez perdu le trafic Syslog (UDP), vous perdriez simplement une partie des informations de journalisation, qui sont probablement toujours contenues dans le tampon ou dans un fichier journal sur le périphérique. Étant donné que NTP calcule le retard en fonction des paquets précédents, tout en tenant compte de l'erreur de décalage maximale, vous ne rencontrez vraiment aucun problème. Dans le pire des cas, votre temps dérive de quelques picosecondes…

Si vous avez perdu un paquet lié au routage, même pendant une seconde, vous pourriez être confronté à la panne de tout le système; rendant toute autre marque sans valeur. À ce stade, NTP serait tout simplement totalement désynchronisé et compterait sur son ticker local pour garder le temps.

— Ryan Foley
source