Quale classificazione QoS dovrebbe essere applicata a NTP?

Il progetto di rete di riferimento della soluzione Enterprise QoS di Cisco suggerisce di classificare l'NTP come traffico di gestione della rete e di contrassegnarlo come CS2:

Quando si affrontano le esigenze di QoS del traffico di gestione della rete, Cisco consiglia le seguenti linee guida:

Il traffico di gestione della rete deve essere contrassegnato su DSCP CS2.

Le applicazioni di gestione della rete devono essere esplicitamente protette con una garanzia di larghezza di banda minima.

Il traffico di gestione della rete è importante per eseguire analisi e risoluzione dei problemi relativi a tendenze e capacità. Pertanto, è possibile eseguire il provisioning di una coda di larghezza di banda minima separata per il traffico di gestione della rete, che potrebbe includere SNMP, NTP , Syslog, NFS e altre applicazioni di gestione .

Dato che l'NTP è sensibile al jitter, perché l'NTP non è contrassegnato come inoltro accelerato e trattato allo stesso modo dei dati vocali?

C'è un motivo per cui non dovrebbe essere inserito nella stessa coda a bassa latenza della voce?

— Stephen Craven
fonte

Non credo che "sensibile al jitter" sia una giusta caratterizzazione dell'NTP. Questo spiega molto, ma credo che l'algoritmo e gli intervalli di polling possano gestire una certa quantità di jitter. Questo mi indurrebbe a pensare che non debba essere trattato come la stessa voce. (So poco di QoS però.)

— Craig Constantine,

@CraigConstantine È corretto. Nella maggior parte degli ambienti, fintanto che è possibile ottenere una coda per battere il traffico BE, probabilmente si è in testa al 95% dei dati.

— Ryan Foley,

@CraigConstantine dai un'occhiata a RFP4594 Buona cattura Stephen. Immagino che Cisco non sia in linea con l'IETF su questo? ...

— Ronnie Royston,

Cisco è una grande azienda con molti individui / gruppi diversi. Non tutti sono sempre d'accordo su ciò che è meglio. Personalmente, penso che la raccomandazione IETF sia migliore quando si tratta di "tempistica ad alta precisione", ma personalmente non vorrei che NTP per le mie apparecchiature di rete (che non classificherei generalmente come alta precisione) sia "temporizzazione dell'orologio da parete" o DF come dice la RFC. La raccomandazione di Cisco sembra essere più "centrale" e in linea con ciò che mi aspetterei avrebbe soddisfatto le esigenze generali di NTP per le apparecchiature di rete.

— YLearn

@StevenCraven, affinché questa sia una domanda di risposta, dobbiamo capire che tipo di requisiti di precisione hai per NTP e come viene utilizzato.

— Mike Pennington,

Risposte:

Risposta modificata: l'NTP deve essere collocato nella classe EF (come i pacchetti vocali in tempo reale) in base alle Linee guida di configurazione RFC 4594 dell'IETF per le classi di servizio DiffServ .

5.2. Mappatura per NTP

Dai test eseguiti, le indicazioni indicano che una distribuzione precisa del tempo richiede un trasporto di variazione del ritardo del pacchetto (jitter) molto basso. Pertanto, suggeriamo di utilizzare le seguenti linee guida per Network Time Protocol (NTP):

o Quando NTP viene utilizzato per fornire tempistiche ad alta precisione all'interno di una rete di amministrazione (vettore) o per utenti / clienti finali, è necessario utilizzare la classe del servizio di telefonia e i pacchetti NTP devono essere contrassegnati con il valore EF DSCP.

o Per le applicazioni che richiedono l'accuratezza del "clock da parete", è necessario utilizzare la classe di servizio standard e i pacchetti devono essere contrassegnati con DF DSCP.

— Ronnie Royston
fonte

corretto in precedenza

— Ronnie Royston il

NTP non è particolarmente sensibile al jitter perché utilizza originatee transmittimestamp per tenere traccia dei ritardi. Ntp.org spiega in dettaglio come tiene sotto controllo i ritardi , ma ecco uno snippet:

La sincronizzazione di un client con un server di rete consiste in diversi scambi di pacchetti in cui ogni scambio è una coppia di richieste e risposte. Quando si invia una richiesta, il client memorizza il proprio tempo (timestamp di origine) nel pacchetto inviato. Quando un server riceve un tale pacchetto, a sua volta memorizzerà il proprio tempo (ricevere il timestamp) nel pacchetto e il pacchetto verrà restituito dopo aver inserito un timestamp di trasmissione nel pacchetto. Quando riceve la risposta, il destinatario registrerà ancora una volta il proprio tempo di ricezione per stimare il tempo di viaggio del pacchetto. Si stima che il tempo di viaggio (ritardo) sia la metà del "ritardo totale meno il tempo di elaborazione remoto", ipotizzando ritardi simmetrici.

Il motivo per cui ciò non rientra nella stessa categoria del controllo di rete è perché questo non è direttamente responsabile del funzionamento del routing / forwarding dei pacchetti. Tutti gli elementi della categoria di gestione della rete non sono componenti critici del sistema di rete nel suo insieme. Se perdessi pacchetti correlati a SNMP, syslog o NTP, probabilmente non te ne accorgeresti nemmeno.

SNMP semplicemente ritrasmetterebbe tali informazioni poiché è basato su TCP. Anche se la connessione si interrompesse, non accadrebbe nulla di catastrofico; potresti semplicemente ottenere un agente snmp che non risponde e quindi riprovare. Se perdessi il traffico syslog (UDP), perderesti semplicemente una serie di informazioni di registrazione, che probabilmente sono ancora contenute nel buffer o in un file di registro sul dispositivo. Poiché NTP calcola il ritardo in base ai pacchetti precedenti, pur tenendo conto dell'errore di offset massimo, in realtà non si verificano problemi. Nel peggiore dei casi, il tuo tempo si sposta di alcuni picosecondi ...

Se hai perso un pacchetto relativo al routing, anche solo per un secondo, potresti dover affrontare l'intero sistema che sta andando giù; rendendo inutili altri segni. A quel punto, l'NTP sarebbe semplicemente totalmente fuori sincrono e si baserebbe sul suo ticker locale per tenere il tempo.

— Ryan Foley
fonte