Uso delle best practice per il protocollo NTP (Network Time Protocol)

Introduzione

Questo documento descrive le best practice per la progettazione di Network Time Protocol.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di questo argomento:   

• Protocollo orario di rete

• Tecnologia dell'orologio e server per l'ora pubblica

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Le reti basate sul protocollo IP (Internet Protocol) sono passate rapidamente dal tradizionale modello di erogazione del massimo sforzo a un modello in cui le prestazioni e l'affidabilità devono essere quantificate e, in molti casi, garantite dagli SLA (Service Level Agreements). La necessità di una maggiore comprensione delle caratteristiche della rete ha portato a notevoli sforzi di ricerca mirati a metriche e capacità di misurazione importanti per caratterizzare il comportamento della rete. La base di molte metodologie metriche è la misurazione del tempo.

La sincronizzazione dell'ora di rete, al livello richiesto per l'analisi moderna delle prestazioni, è un esercizio essenziale. In base ai modelli aziendali e ai servizi forniti, la caratterizzazione delle prestazioni di rete è considerata un importante fattore di differenziazione dei servizi rispetto alla concorrenza. In questi casi, l'installazione di sistemi di gestione di rete e di risorse tecniche dirette per l'analisi dei dati sulle prestazioni raccolti comporta costi elevati. Tuttavia, se non viene data la giusta attenzione al principio spesso trascurato della sincronizzazione del tempo, questi sforzi sono inefficaci.

Questo documento descrive un'ipotetica definizione di processo per la gestione delle funzioni di gestione della rete per il protocollo NTP (Network Time Protocol). È possibile utilizzare questo articolo come procedura ipotetica e come esempio informativo. Questo può essere personalizzato da un'organizzazione per soddisfare gli obiettivi interni.

Le informazioni fornite in questo documento sono suddivise in varie sezioni principali:

• La sezione Terminologia fornisce le definizioni generali dei termini relativi alla sincronizzazione temporale.
• La sezione Panoramica fornisce informazioni di base sull'hardware degli elementi di rete relativi all'ora del sistema, una panoramica tecnologica dell'NTP e gli aspetti chiave della progettazione per l'architettura NTP.
• La sezione Esempio di installazione NTP fornisce esempi di installazione NTP con configurazioni di esempio per reti WAN, campus ad alto strato e reti di distribuzione del tempo in campus a basso strato.
• La sezione Definizioni processo fornisce una panoramica delle definizioni di processo utilizzate per eseguire la gestione NTP. I dettagli del processo sono descritti in termini di obiettivi, indicatori di prestazioni, input, output e singole attività.
• La sezione Definizioni task fornisce definizioni dettagliate dei task di processo. Ogni attività viene descritta in termini di obiettivi, input, output, risorse necessarie per completare l'attività e competenze di processo necessarie per l'implementazione di un'attività.
• La sezione Identificazione dati descrive l'identificazione dei dati per NTP. L'identificazione dei dati considera l'origine delle informazioni. Ad esempio, le informazioni possono essere contenute nel MIB (Simple Network Management Protocol), in file di registro generati da Syslog o in strutture di dati interne accessibili solo dall'interfaccia della riga di comando (CLI).
• La sezione Raccolta dati descrive la raccolta dei dati NTP. La raccolta dei dati è strettamente correlata alla loro posizione. Ad esempio, i dati MIB SNMP vengono raccolti da diversi meccanismi, quali trap, allarmi ed eventi RMON (monitoraggio da remoto) o polling. I dati gestiti dalle strutture di dati interne vengono raccolti da script automatici o quando un utente accede manualmente al sistema per eseguire il comando CLI e registrare l'output.
• La sezione Presentazione dei dati fornisce esempi di formato di report relativi alla modalità di presentazione dei dati.

Terminologia

• Precisione (Accuracy) - La prossimità del valore assoluto dell'orologio all'offset di zero.

• Accurato (Accurate) - Quando l'offset di un orologio è uguale a zero in un particolare momento nel tempo.

• Deriva (Drift) - Misura della variazione dell'inclinazione o della seconda derivazione dell'offset dell'orologio rispetto al tempo.

• Risoluzione congiunta - Quando vengono confrontati gli orologi, corrisponde alla somma delle risoluzioni di C1 e C2. La risoluzione del giunto indica quindi un limite inferiore conservativo sulla precisione di qualsiasi intervallo di tempo calcolato da timestamp generati da un orologio e sottratti da quelli generati dall'altro.

• Nodo: si riferisce alla creazione di un'istanza del protocollo NTP su un processore locale. Un nodo può anche essere definito dispositivo.

• Offset - Differenza tra l'ora indicata da un orologio e l'ora effettiva definita da UTC (Coordinated Universal Time). Se l'orologio indica un'ora Tc e l'ora effettiva è Tt, l'offset dell'orologio sarà Tc - Tt.

• Peer: si riferisce alla creazione di un'istanza del protocollo NTP su un processore remoto connesso tramite un percorso di rete dal nodo locale.

• Offset relativo (Relative offset) - La nozione di tempo reale viene sostituita dall'ora indicata dall'orologio C1, quando vengono confrontati due orologi, C1 e C2. Ad esempio, l'offset dell'orologio C2 rispetto a C1 in un determinato momento è Tc2 - Tc1, la differenza istantanea di tempo riportata da C2 e C1.

• Risoluzione (Resolution) - L'unità più piccola in base alla quale viene aggiornato l'ora dell'orologio. La risoluzione è definita in termini di secondi. Tuttavia, la risoluzione è relativa all'ora indicata dall'orologio e non all'ora effettiva. Una risoluzione di 10 millisecondi, ad esempio, indica che l'orologio aggiorna la nozione di tempo in incrementi di 0,01 secondi e non indica che questo sia il tempo reale tra gli aggiornamenti.

  Nota: gli orologi possono avere risoluzioni molto fini e comunque essere imprecisi.

• Inclinazione (Skew) - Differenza di frequenza di clock, o prima derivata dell'offset rispetto al tempo.

• Sincronizza (Synchronize) - Quando due orologi sono accurati l'uno rispetto all'altro (l'offset relativo è zero), vengono sincronizzati. Gli orologi possono essere sincronizzati e ancora imprecisi in termini di quanto bene dicono tempo reale.

Panoramica

Panoramica del dispositivo

Il cuore del servizio ora è l'orologio di sistema. L'orologio di sistema viene eseguito dal momento in cui il sistema viene avviato e tiene traccia della data e dell'ora correnti. L'orologio di sistema può essere impostato da diverse fonti e, a sua volta, può essere utilizzato per distribuire l'ora corrente attraverso vari meccanismi ad altri sistemi. Alcuni router contengono un sistema di calendario alimentato a batteria che tiene traccia della data e dell'ora di riavvio del sistema e di interruzioni dell'alimentazione. Questo sistema di calendario viene sempre utilizzato per inizializzare l'orologio di sistema al riavvio del sistema. Può anche essere considerata come una fonte di tempo autorevole e ridistribuita attraverso il NTP se non è disponibile altra fonte. Inoltre, se il protocollo NTP è abilitato, il calendario viene aggiornato periodicamente dal protocollo NTP e ciò compensa la deviazione intrinseca nell'ora del calendario. Quando si inizializza un router con un calendario di sistema, l'orologio di sistema viene impostato in base all'ora nel calendario interno alimentato a batteria. Nei modelli senza calendario, l'orologio di sistema è impostato su una costante di tempo predeterminata. L'orologio di sistema può essere impostato dalle sorgenti elencate di seguito.

• NTP

• Protocollo SNTP (Simple Network Time Protocol)

• Servizio ora VINES (Virtual Integrated Network Service)

• Configurazione manuale

Alcuni dispositivi Cisco di fascia bassa supportano solo il protocollo SNTP. L'SNTP è una versione semplificata dell'NTP disponibile solo dal client. Il protocollo SNTP può ricevere l'ora solo dai server NTP e non può essere utilizzato per fornire servizi di ora ad altri sistemi. Il protocollo SNTP in genere fornisce il tempo entro 100 millisecondi dalla data di completamento. Inoltre, il protocollo SNTP non autentica il traffico, anche se è possibile configurare gli elenchi degli accessi estesi in modo da fornire una certa protezione. Un client SNTP è più vulnerabile ai server non conformi rispetto a un client NTP e deve essere utilizzato solo in situazioni in cui non è richiesta l'autenticazione avanzata.

L'orologio di sistema fornisce l'ora per i servizi elencati di seguito.

• NTP

• Servizio ora VINES

• Comandi show dell'utente

• Registrazione e debug dei messaggi

L'orologio di sistema tiene traccia dell'ora internamente in base all'UTC, noto anche come ora di Greenwich (GMT). È possibile configurare le informazioni relative al fuso orario locale e all'ora legale in modo che l'ora venga visualizzata correttamente rispetto al fuso orario locale. L'orologio di sistema tiene traccia dell'autorevolezza o meno dell'ora. Se non è autorevole, l'ora può essere disponibile solo a scopo di visualizzazione e non può essere ridistribuita.

Panoramica NTP

L'NTP è progettato per sincronizzare l'ora su una rete di macchine. Il protocollo NTP viene eseguito sul protocollo UDP (User Datagram Protocol), con la porta 123 sia come origine che come destinazione, che a sua volta viene eseguito su IP. La RFC 1305 dell'NTP versione 3 viene utilizzata per sincronizzare la gestione del tempo tra una serie di client e server di riferimento orario distribuiti. Un set di nodi in una rete viene identificato e configurato con NTP e i nodi formano una subnet di sincronizzazione, a volte definita rete di sovrapposizione. Sebbene possano esistere più server primari, non è necessario un protocollo di selezione.

Una rete NTP in genere ottiene il proprio tempo da una fonte oraria autorevole, come un orologio radio o un orologio atomico collegato a un server di riferimento orario. NTP quindi distribuisce il tempo in rete. Un client NTP esegue una transazione con il proprio server durante il proprio intervallo di polling (da 64 a 1024 secondi), che cambia in modo dinamico nel tempo a seconda delle condizioni di rete tra il server NTP e il client. L'altra situazione si verifica quando il router comunica con un server NTP errato (ad esempio, un server NTP con un'ampia dispersione); il router aumenta anche l'intervallo di polling. Non è necessaria più di una transazione NTP al minuto per sincronizzare due computer.

La tecnologia NTP utilizza il concetto di strato per descrivere quanti hop NTP distano una macchina da una fonte temporale autorevole. Ad esempio, un server di riferimento ora di strato 1 ha un orologio radio o atomico direttamente collegato. Quindi invia il suo tempo a un server di riferimento temporale di Stratum 2 tramite NTP, e così via. Un computer che esegue NTP sceglie automaticamente il computer con il numero di strato più basso configurato per comunicare con NTP come origine del tempo. Questa strategia consente di creare in modo efficace una struttura auto-organizzante di altoparlanti NTP. L'NTP funziona bene sulle lunghezze dei percorsi non deterministici delle reti a commutazione di pacchetto perché effettua stime affidabili delle prossime tre variabili chiave nella relazione tra un client e un time server.

• Ritardo di rete

• Dispersione degli scambi di pacchetti temporali: misura dell'errore di clock massimo tra i due host.

• Offset orologio (Clock offset) - Correzione applicata all'orologio di un client per sincronizzarlo.

La sincronizzazione dell'orologio a un livello di 10 millisecondi su reti WAN (Wide Area Network) a lunga distanza (2000 km) e a un livello di 1 millisecondo per reti LAN (Local-Area Network) viene eseguita regolarmente.

Ci sono due modi in cui NTP non si sincronizza con una macchina il cui tempo non è preciso. In primo luogo, NTP non si sincronizza mai con un computer che non è sincronizzato da solo. In secondo luogo, NTP confronta il tempo riportato da diverse macchine, e non si sincronizza con una macchina il cui tempo è significativamente diverso dagli altri, anche se il suo strato è più basso.

Le comunicazioni tra computer che eseguono NTP (associazioni) sono in genere configurate in modo statico. A ogni computer viene assegnato l'indirizzo IP di tutti i computer con i quali devono essere create le associazioni. L'accurata temporizzazione è resa possibile dai messaggi NTP scambiati tra ogni coppia di macchine con un'associazione. Tuttavia, in un ambiente LAN, l'NTP può essere configurato in modo da utilizzare i messaggi broadcast IP. Questa alternativa riduce la complessità della configurazione in quanto ogni computer può essere configurato per l'invio o la ricezione di messaggi broadcast. Tuttavia, l'accuratezza della gestione dei tempi è ridotta marginalmente in quanto il flusso di informazioni è unidirezionale.

Il tempo conservato sul computer è una risorsa critica ed è consigliabile utilizzare le funzioni di sicurezza del protocollo NTP per evitare l'impostazione accidentale o dannosa di un tempo errato. Le due funzionalità di sicurezza disponibili sono uno schema di restrizione basato su un elenco degli accessi e un meccanismo di autenticazione crittografato.

L'implementazione Cisco di NTP supporta il servizio Stratum 1 in alcune versioni del software Cisco IOS®. Se una versione supporta il comando ntp refclock, è possibile collegare un orologio radio o atomico. Alcune versioni di Cisco IOS supportano il kit di sincronizzazione NTP Trimble Palisade (solo router Cisco serie 7200) o il dispositivo GPS (Telecom Solutions Global Positioning System). Se la rete utilizza i server di riferimento orario pubblici su Internet e la rete è isolata da Internet, l'implementazione Cisco di NTP consente a un computer di essere configurato in modo che agisca come se fosse sincronizzato tramite NTP, quando in realtà ha determinato l'ora con altri mezzi. Altri computer si sincronizzano quindi con tale computer tramite NTP.

Criteri di progettazione NTP

Ogni client nella subnet di sincronizzazione, che può anche essere un server per i client di uno strato superiore, sceglie uno dei server disponibili per la sincronizzazione. Si tratta in genere di uno dei server di livello più basso a cui ha accesso. Tuttavia, questa non è sempre una configurazione ottimale, perché NTP opera anche con il presupposto che ogni tempo del server deve essere visualizzato con una certa diffidenza. L'NTP preferisce avere accesso a diverse fonti di tempo inferiore dello strato (almeno tre), dal momento che può applicare un algoritmo di accordo per rilevare la pazzia da parte di uno qualsiasi di questi. Normalmente, quando tutti i server sono d'accordo, NTP sceglie il server migliore in termini di strato più basso, più vicino (in termini di ritardo di rete) e precisione richiesta. L'implicazione è che, mentre si deve mirare a fornire a ogni client tre o più origini di tempo di strato inferiore, molti di questi possono solo fornire il servizio di backup e possono essere di qualità inferiore in termini di ritardo di rete e strato. Ad esempio, un peer dello stesso strato che riceve il tempo da origini dello strato inferiore a cui il server locale non accede direttamente può anche fornire un buon servizio di backup.

NTP in genere preferisce i server di strato inferiore ai server di strato superiore, a meno che il tempo del server di strato inferiore non sia significativamente diverso. L'algoritmo è in grado di rilevare quando una fonte temporale è probabilmente estremamente imprecisa, o folle, e di prevenire la sincronizzazione in questi casi, anche se l'orologio impreciso si trova a un livello inferiore dello strato. Inoltre, non è mai in grado di sincronizzare un dispositivo con un altro server che non è sincronizzato.

Per dichiarare l'affidabilità del server, è necessario che siano stati superati numerosi controlli di integrità, ad esempio:

• Le implementazioni devono includere timeout di integrità che impediscano la trasmissione di trap se il programma di monitoraggio non rinnova queste informazioni dopo un lungo intervallo.

• Sono inclusi ulteriori controlli di integrità per l'autenticazione, i limiti di intervallo e per evitare l'utilizzo di dati obsoleti.

• Sono stati aggiunti dei controlli per avvisare che l'oscillatore è andato troppo a lungo senza l'aggiornamento da una fonte di riferimento.

• Le variabili peer.valid e sys.hold sono state aggiunte per evitare instabilità quando l'origine di riferimento cambia rapidamente a causa di grandi ritardi di dispersione in condizioni di grave congestione della rete. I bit peer.config, peer.authenticable e peer.authenticable sono stati aggiunti per controllare funzionalità speciali e semplificare la configurazione.

Se almeno uno di questi controlli ha esito negativo, il router lo dichiara instabile.

Modalità di associazione

Nelle sezioni seguenti vengono descritte le modalità di associazione utilizzate dai server NTP per l'associazione reciproca.

• Client/server

• Simmetrico attivo/passivo

• Trasmissione

Modalità client/server

I client e i server dipendenti in genere funzionano in modalità client/server, in cui un client o un server dipendente può essere sincronizzato con un membro del gruppo, ma nessun membro del gruppo può eseguire la sincronizzazione con il client o il server dipendente. In questo modo è possibile evitare malfunzionamenti o attacchi ai protocolli.

La modalità client/server è la configurazione Internet più comune. Funziona nel classico paradigma RPC (Remote Procedure Call) con server senza stato. In questa modalità, un client invia una richiesta al server e si aspetta una risposta in futuro. In alcuni contesti, questa operazione viene descritta come un'operazione di polling, in quanto il client esegue il polling dei dati di autenticazione e dell'ora dal server. Un client è configurato in modalità client con il comando server e con il nome o l'indirizzo DNS (Domain Name Server) specificato. Il server non richiede alcuna configurazione precedente.

In un modello client/server comune, un client invia un messaggio NTP a uno o più server ed elabora le risposte come ricevute. Il server si interfaccia tra indirizzi e porte, sovrascrive determinati campi del messaggio, ricalcola il checksum e restituisce il messaggio immediatamente. Le informazioni incluse nel messaggio NTP consentono al client di determinare l'ora del server rispetto all'ora locale e quindi di regolare l'orologio locale in base alle esigenze. Inoltre, il messaggio include informazioni per calcolare l'accuratezza e l'affidabilità della conservazione del tempo prevista, nonché per selezionare il server migliore.

I server che forniscono la sincronizzazione a un numero considerevole di client in genere funzionano come un gruppo di tre o più server reciprocamente ridondanti, ognuno dei quali opera con tre o più server di strato 1 o di strato 2 in modalità client/server, nonché con tutti gli altri membri del gruppo in modalità simmetrica. In questo modo è possibile evitare malfunzionamenti in cui uno o più server non funzionano o forniscono un tempo errato. Gli algoritmi NTP sono progettati per resistere agli attacchi quando alcune frazioni delle fonti di sincronizzazione configurate accidentalmente o intenzionalmente forniscono un tempo errato. In questi casi, viene utilizzata una procedura di voto speciale per identificare le fonti false ed eliminare i loro dati. Per garantire affidabilità, gli host selezionati possono essere dotati di orologi esterni e utilizzati per il backup in caso di guasto dei server principali e/o secondari o dei percorsi di comunicazione tra di essi.

La configurazione di un'associazione in modalità client è in genere indicata da una dichiarazione server nel file di configurazione e indica che si desidera ottenere l'ora dal server remoto, ma che non si desidera fornire l'ora al server remoto.

Modalità attiva/passiva simmetrica

La modalità attiva/passiva simmetrica è destinata alle configurazioni in cui un gruppo di peer a basso strato opera come backup reciproci. Ogni peer opera con una o più origini di riferimento primarie, ad esempio un orologio radio, o con un sottoinsieme di server secondari affidabili. Se uno dei peer perde tutte le origini di riferimento o semplicemente cessa di funzionare, gli altri peer vengono riconfigurati automaticamente in modo che i valori di tempo possano passare dai peer correnti a tutti gli altri nella coda. In alcuni contesti, questa operazione viene descritta come operazione push-pull in quanto il peer esegue il pull o il push del tempo e dei valori in base alla configurazione specifica.

La configurazione di un'associazione in modalità simmetrica-attiva, generalmente indicata da una dichiarazione peer nel file di configurazione, indica al server remoto che si desidera ottenere tempo dal server remoto e che si è anche disposti a fornire tempo al server remoto, se necessario. Questa modalità è appropriata nelle configurazioni che coinvolgono diversi time server ridondanti interconnessi tramite percorsi di rete diversi, come avviene attualmente per la maggior parte dei server di strato 1 e di strato 2 su Internet.

Le modalità simmetriche vengono utilizzate più di frequente tra due o più server che operano come gruppi reciprocamente ridondanti. In queste modalità, i server nei membri del gruppo dispongono i percorsi di sincronizzazione per ottenere le massime prestazioni in base al jitter di rete e al ritardo di propagazione. Se si verificano errori in uno o più membri del gruppo, i membri rimanenti vengono riconfigurati automaticamente in base alle esigenze.

Un peer viene configurato in modalità attiva simmetrica con il comando peer e quando viene specificato il nome DNS o l'indirizzo dell'altro peer. Anche l'altro peer è configurato in modalità attiva simmetrica in questo modo.

Nota: se l'altro peer non è configurato specificamente in questo modo, viene attivata un'associazione passiva simmetrica all'arrivo di un messaggio attivo simmetrico. Poiché un intruso può rappresentare un peer attivo simmetrico e inserire valori di tempo falsi, la modalità simmetrica deve essere sempre autenticata.

Modalità broadcast e/o multicast

Se le esigenze di accuratezza e affidabilità sono modeste, i client possono essere configurati per utilizzare le modalità broadcast e/o multicast. Normalmente queste modalità non vengono utilizzate dai server con client dipendenti. Il vantaggio è che i client non devono essere configurati per un server specifico e questo consente a tutti i client operativi di utilizzare lo stesso file di configurazione. La modalità di trasmissione richiede un server di trasmissione nella stessa subnet. Poiché i messaggi broadcast non vengono propagati dai router, vengono utilizzati solo i server broadcast della stessa subnet.

La modalità di trasmissione è destinata a configurazioni che coinvolgono uno o più server e un numero potenzialmente elevato di client. Un server di trasmissione è configurato con il comando broadcast e un indirizzo di subnet locale. Un client di trasmissione è configurato con il comando broadcast client, che consente al client di trasmissione di rispondere ai messaggi di trasmissione ricevuti su qualsiasi interfaccia. Dal momento che un intruso può rappresentare un server di trasmissione e inserire valori di tempo falsi, questa modalità deve sempre essere autenticata.

Imposta secondo balzo NTP

È possibile utilizzare il leap ntp {add | delete} per inserire un secondo bisestile. Sono disponibili opzioni per aggiungere o eliminare i secondi intercalari. A tale scopo, è necessario rispettare due vincoli:

• L'orologio deve essere in stato di sincronizzazione.

• Il comando viene accettato solo entro il mese che precede il salto. Non è possibile impostare il salto se l'ora corrente è precedente a 1 mese dal verificarsi del salto.

Una volta impostata, il secondo intercalare viene aggiunto o eliminato all'ultimo secondo, come mostrato di seguito:

NTP leap second added :
Show clock given continuously
vl-7500-6#show clock
23:59:58.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:58.619 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
<< 59th second occurring twice
vl-7500-6#show clock
23:59:59.131 UTC Sun Dec 31 2006    
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
vl-7500-6#show clock
00:00:00.127 UTC Mon Jan 1 2007
vl-7500-6#show clock
00:00:00.623 UTC Mon Jan 1 2007

Architettura NTP

Queste tre strutture sono disponibili per l'architettura NTP:

• Struttura peer piatta

• Struttura gerarchica

• Struttura a stella

In una struttura peer piatta, tutti i router peer tra loro, con alcuni router geograficamente separati configurati per puntare a sistemi esterni. La convergenza di tempo diventa più lunga con ogni nuovo membro della mesh NTP.

In una struttura gerarchica, la gerarchia di routing viene copiata per la gerarchia NTP. I router principali hanno una relazione client/server con origini temporali esterne, i server temporali interni hanno una relazione client/server con i router principali, i router utente interni (server non temporali) hanno una relazione client/server con i server temporali interni e così via nella struttura. Queste relazioni sono denominate scale gerarchiche. Una struttura gerarchica è la tecnica preferita perché fornisce coerenza, stabilità e scalabilità.

Un'architettura NTP scalabile ha una struttura gerarchica come illustrato nel diagramma successivo.

Architettura NTP scalabile

In una struttura a stella, tutti i router hanno una relazione client/server con alcuni time server nel nucleo. I server di riferimento orario dedicati sono il centro della stella e sono solitamente sistemi UNIX sincronizzati con fonti di riferimento orario esterne o con il proprio ricevitore GPS.

Tecnologia dell'orologio e server per l'ora pubblica

La subnet NTP Internet include attualmente oltre 50 server primari pubblici sincronizzati direttamente con UTC via radio, satellite o modem. In genere, le workstation client e i server con un numero relativamente ridotto di client non eseguono la sincronizzazione con i server principali. Circa 100 server secondari pubblici sono sincronizzati con i server primari e forniscono la sincronizzazione per un totale di oltre 100.000 client e server su Internet. Gli elenchi NTP Time Server pubblici vengono aggiornati di frequente. Esistono inoltre numerosi server privati primari e secondari normalmente non disponibili al pubblico.

Nota: PIX e ASA non possono essere configurati come server NTP, ma possono essere configurati come client NTP.

In alcuni casi, in cui sono necessari servizi temporali altamente precisi nell'azienda privata, ad esempio metriche unidirezionali per le misurazioni VoIP (Voice over IP), i progettisti di rete possono scegliere di distribuire origini temporali esterne private. Il diagramma seguente mostra un grafico comparativo della precisione relativa delle tecnologie correnti.

Grafico comparativo

Fino a poco tempo fa, l'utilizzo di origini di tempo esterne non è stato ampiamente implementato nelle reti aziendali a causa dell'elevato costo delle origini di tempo esterne di qualità. Tuttavia, con l'aumento dei requisiti QoS (Quality of Service) e la continua diminuzione dei costi della tecnologia del tempo, le origini del tempo esterne per le reti aziendali rappresentano un'opzione praticabile.

Esempi di distribuzioni NTP

WAN Time Distribution Network

Nel diagramma successivo, un sistema autonomo aziendale (AS) ottiene informazioni temporali da tre server di riferimento orario pubblici. Il server di riferimento orario aziendale viene visualizzato come Area 0 e Area 1. In questo esempio, la gerarchia NTP descrive la gerarchia OSPF (Open Shortest Path First). Tuttavia, OSPF non è un prerequisito per NTP. Viene utilizzato solo come esempio illustrativo. L'NTP può essere distribuito lungo altri limiti gerarchici logici, ad esempio una gerarchia EIGRP (Enhanced Interior Gateway Routing Protocol) o la gerarchia Core/Distribution/Access standard.

WAN Time Distribution Network

Questo esempio è la configurazione Cisco IOS per il dispositivo A0-R1 come mostrato nel diagramma precedente.

clock timezone CST -5
clock summer-time CDT recurring


!--- This router has a hardware calendar. 
!--- To configure a system as an 
!--- authoritative time source for a network 
!--- based on its hardware clock (calendar), 
!--- use the clock calendar-valid global 
!--- configuration command. Notice later that 
!--- NTP can be allowed to update the calendar 
!--- and Cisco IOS can be configured to be an 
!--- NTP master clock source. 
!--- Cisco IOS can then obtain its clock from 
!--- the hardware calendar.


clock calendar-valid


!--- This allows NTP to update the hardware 
!--- calendar chip.


ntp update-calendar


!--- Configures the Cisco IOS software as an 
!--- NTP master clock to which peers synchronize 
!--- themselves when an external NTP source is 
!--- not available. Cisco IOS can obtain the 
!--- clock from the hardware calendar based on 
!--- the previous line. This line can keep the 
!--- whole network in Sync even if Router1 loses 
!--- its signal from the Internet. Assume, for 
!--- this example, that the Internet time servers 
!--- are stratum 2.


ntp master 3


!--- When the system sends an NTP packet, the 
!--- source IP address is normally set to the 
!--- address of the interface through which the 
!--- NTP packet is sent. 
!--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for 
!--- the public servers and peers for additional 
!--- security.


access-list 5 permit <I-TS-1>
access-list 5 permit <I-TS-2>
access-list 5 permit <I-TS-3>
access-list 5 permit <A0-R2>
access-list 5 permit <A0-R3>
access-list 5 deny any


!--- Configures the access control groups for the 
!--- clients to this node for additional security.


access-list 6 permit <A1-R1>
access-list 6 permit <A1-R2>
access-list 6 permit <A1-R3>
access-list 6 deny any


!--- Restricts the IP addresses for the peers 
!--- and clients.

 
ntp access-group peer 5
ntp access-group serve-only 6


!--- Fault tolerant configuration polling for 3 NTP 
!--- public servers, peering with 2 local servers.


ntp server <I-TS-1>
ntp server <I-TS-2>
ntp server <I-TS-3>
ntp peer <A0-R2> 
ntp peer <A0-R3>

Rete di distribuzione tempo High Stratum Campus

La sezione precedente descriveva una rete di distribuzione temporale WAN. Questa sezione si sposta di un passo verso il basso nella gerarchia per discutere la distribuzione del tempo su una rete di campus ad alto strato.

La differenza principale considerata per la distribuzione del tempo su una rete di campus ad alto strato è il potenziale utilizzo della modalità di associazione del broadcast. Come descritto in precedenza, la modalità di associazione del broadcast semplifica le configurazioni delle LAN, ma riduce l'accuratezza dei calcoli di tempo. Pertanto, il compromesso tra i costi di manutenzione deve essere considerato a fronte dell'accuratezza delle misurazioni delle prestazioni.

Rete di distribuzione tempo High Stratum Campus

La rete di campus ad alto strato, illustrata nel diagramma precedente, è presa dal progetto di rete standard del campus Cisco e contiene tre componenti. Il nucleo del campus è costituito da due dispositivi di layer 3 denominati CB-1 e CB-2. Il componente server, situato nella sezione inferiore della figura, dispone di due router di layer 3 denominati SD-1 e SD-2. Gli altri dispositivi nel blocco server sono dispositivi di livello 2. In alto a sinistra, è presente un blocco degli accessi standard con due dispositivi di distribuzione di layer 3 chiamati dl-1 e dl-2. Gli altri dispositivi sono switch di layer 2. In questo blocco di accesso client, l'ora viene distribuita con l'opzione di trasmissione. In alto a destra è presente un altro blocco di accesso standard che utilizza una configurazione di distribuzione temporale client/server.

I dispositivi backbone del campus sono sincronizzati con i server di area in un modello client/server.

Questa è la configurazione per i dispositivi di distribuzione del layer 3 del dl-1:

!--- In this case, dl-1 can be a broadcast server 
!--- for the Layer 2 LAN.


internet Ethernet0
ntp broadcast

clock timezone CST -5
clock summer-time CDT recurring


!--- When the system sends an NTP packet, the 
!--- source IP address is normally set to the 
!--- address of the interface through which the 
!--- NTP packet is sent. 
!--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for 
!--- the public servers and peers for 
!--- additional security.


access-list 5 permit <CB-1>
access-list 5 permit <CB-2>
access-list 5 permit <dl-2>
access-list 5 deny any



!--- Restricts the IP addresses for the peers 
!--- and clients.


ntp access-group peer 5


!--- Fault tolerant configuration polling 2 
!--- local time servers and 1 local peer.


ntp server <CB-1>
ntp server <CB-2>
ntp peer <dl-2>

Rete di distribuzione del tempo del campus a basso livello

Nel diagramma successivo, una fonte di tempo GPS o Cesium è fornita presso il centro dati centrale per la rete del campus a basso strato. Questo fornisce una fonte di tempo di strato 1 sulla rete privata. Se ci sono più fonti di tempo GPS o Cesium che si trovano nella rete privata, allora la distribuzione di tempo nella rete privata deve essere modificata per sfruttare le fonti di tempo disponibili.

In generale, si applicano gli stessi principi e configurazioni degli esempi precedenti. La differenza principale in questo caso è che la radice della struttura di sincronizzazione è un'origine dell'ora privata anziché pubblica proveniente da Internet. In questo modo viene modificata la progettazione della rete di distribuzione del tempo in modo da sfruttare l'origine del tempo privata ad alta precisione. La fonte dell'ora privata viene distribuita in tutta la rete privata con i principi di gerarchia e modularità descritti nelle sezioni precedenti.

Rete di distribuzione del tempo del campus a basso livello

Definizioni dei processi

Una definizione di processo è una serie connessa di azioni, attività e modifiche eseguite da agenti che intendono soddisfare uno scopo o raggiungere un obiettivo. Il controllo dei processi è il processo di pianificazione e regolamentazione, con l'obiettivo di eseguire un processo in modo efficace ed efficiente. come illustrato nel diagramma successivo. 

Serie di processi

Il risultato del processo deve essere conforme alle norme operative definite da un'organizzazione e basate sugli obiettivi aziendali. Se il processo è conforme all'insieme di norme, viene considerato efficace in quanto può essere ripetuto, misurato, gestito e contribuisce agli obiettivi aziendali. Se le attività sono svolte con il minimo sforzo, anche il processo è considerato efficiente.

Proprietario processo

I processi si estendono su vari confini organizzativi. Pertanto, è importante avere un unico proprietario del processo responsabile della definizione del processo. Il proprietario è il punto focale che determina e segnala se il processo è efficace ed efficiente. Se il processo non è efficace o efficiente, il proprietario del processo determina la modifica del processo. La modifica del processo è gestita dai processi di controllo delle modifiche e revisione.

Obiettivi del processo

Gli obiettivi del processo vengono stabiliti per impostare la direzione e l'ambito per la definizione del processo. Gli obiettivi vengono inoltre utilizzati per definire le metriche utilizzate per misurare l'efficacia di un processo.

L'obiettivo di questo processo è fornire i criteri da documentare durante la fase di progettazione dell'NTP e fornire una capacità di audit per un'architettura NTP distribuita per garantire la conformità a lungo termine con il progetto previsto.

Indicatori prestazioni processo

Gli indicatori di prestazioni del processo vengono utilizzati per misurare l'efficacia della definizione del processo. Gli indicatori di rendimento devono essere misurabili e quantificabili. Ad esempio, gli indicatori di prestazioni elencati di seguito sono numerici o misurati in base al tempo.

• Il tempo necessario per completare l'intero processo.

• La frequenza di esecuzione necessaria per rilevare in modo proattivo i problemi NTP prima che abbiano un impatto sugli utenti.

• Carico di rete associato all'esecuzione del processo.

• Numero di azioni correttive consigliate dal processo.

• Numero di azioni correttive implementate come risultato del processo.

• Il tempo necessario per l'implementazione delle azioni correttive.

• Backlog delle azioni correttive.

• Errori nella risoluzione dei problemi o nella diagnosi attribuiti a problemi correlati all'NTP.

• Numero di elementi aggiunti, rimossi o modificati nel file di origine. Questa è un'indicazione di accuratezza e stabilità.

Input processo

Gli input di processo vengono utilizzati per definire i criteri e i prerequisiti per un processo. L'identificazione degli input del processo fornisce spesso informazioni sulle dipendenze esterne. Di seguito viene fornito un elenco di input relativi alla gestione NTP.

• Documentazione di progettazione NTP

• Dati MIB NTP raccolti dal polling SNMP

Output del processo

Gli output del processo sono definiti come:

• Report di configurazione NTP definiti nella sezione Presentazione dei dati di questo documento

• Azioni correttive NTP

Definizioni attività

Le sezioni seguenti definiscono le attività di inizializzazione e iterative associate alla gestione NTP.

Task di inizializzazione

I task di inizializzazione vengono eseguiti una volta durante l'implementazione del processo e non devono essere eseguiti durante ogni iterazione del processo.

Creazione del progetto NTP

Quando si verificano i task dei prerequisiti, se si determina che uno qualsiasi dei task non è implementato o non fornisce informazioni sufficienti per soddisfare in modo efficace le esigenze di questa procedura, questo fatto deve essere documentato dal proprietario del processo e inviato alla direzione. Nella tabella seguente vengono descritti i task di inizializzazione dei prerequisiti.

Attività prerequisita	Descrizione
Obiettivi attività	Creare un documento di progettazione dettagliato per l'architettura NTP che soddisfi i requisiti di progettazione e gli obiettivi di costo.
Input attività	Progettazione dei requisiti tecnici ed economici Documentazione di progettazione della rete corrente Criteri che definiscono gli aspetti richiesti da registrare nella progettazione per abilitare le funzioni di gestione Informazioni sull'installazione di applicazioni IT Requisiti di monitoraggio delle prestazioni
Output attività	Documentazione di progettazione NTP.
Risorse attività	Architetto di rete Architetto di operazioni di rete.
Ruoli attività	Approvazione tecnica della progettazione della rete da parte di revisori tecnici e operativi Costi di progettazione della rete approvati dal responsabile del budget.

Creazione di un file di inizializzazione

Il processo di gestione NTP richiede l'utilizzo di un file di inizializzazione per eliminare la necessità di una funzione di individuazione della rete. Il file di inizializzazione registra l'insieme di router gestiti dal processo NTP e viene utilizzato anche come punto focale per il coordinamento con i processi di gestione delle modifiche di un'organizzazione. Ad esempio, se vengono immessi nuovi nodi nella rete, è necessario aggiungerli al file di origine NTP. Se vengono apportate modifiche ai nomi delle community SNMP a causa dei requisiti di sicurezza, tali modifiche devono essere riflesse nel file di inizializzazione. Nella tabella seguente viene descritto come creare un file di origine.

Attività prerequisita	Descrizione
Obiettivi attività	Crea un file di inizializzazione che identifica tre categorie di dispositivi di rete: Dispositivi critici: polling frequente delle informazioni di configurazione Dispositivi interessanti: polling meno frequente Tutti i dispositivi abilitati NTP - Quantità minima sottoposta a polling
Input attività	Documentazione di progettazione NTP Documentazione sulla topologia di rete.
Output attività	File di inizializzazione.
Risorse attività	Criteri di progettazione che possono essere utilizzati per identificare e assegnare priorità ai nodi coinvolti nell'architettura NTP.

Parametri delle prestazioni NTP della linea di base

Molti dei parametri disponibili per il monitoraggio della rete NTP presentano alcune normali variazioni previste. Il processo di baseline viene utilizzato per caratterizzare le normali variazioni previste e per impostare soglie che definiscono condizioni inattese o anomale. Questa attività viene utilizzata per la baseline dell'insieme variabile di parametri per l'architettura NTP.

Processo	Descrizione
Obiettivi attività	Parametri delle variabili della baseline.
Input attività	Identificare i parametri delle variabili cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion.
Output attività	Valori di base e soglie.
Risorse attività	Strumenti che raccolgono dati SNMP e calcolano le baseline.
Ruolo attività	Ingegnere di rete Tecnico NMS.

Attività iterative

I task iterativi vengono eseguiti durante ogni iterazione del processo e la loro frequenza viene determinata e modificata al fine di migliorare gli indicatori di prestazioni.

Gestisci file di inizializzazione

Il file di inizializzazione è fondamentale per l'implementazione efficace del processo di gestione NTP. Pertanto, lo stato corrente del file di inizializzazione deve essere gestito attivamente. Il proprietario del processo di gestione NTP deve tenere traccia delle modifiche alla rete che influiscono sul contenuto del file di inizializzazione.

Processo	Descrizione
Obiettivi attività	Mantenere l'accuratezza del file di inizializzazione
Input attività	Informazioni sulle modifiche alla rete
Output attività	File di inizializzazione
Risorse attività	Relazioni, notifiche, riunioni relative alle modifiche
Ruolo attività	Ingegnere di rete Tecnico NMS

Eseguire la scansione del nodo NTP

Raccogliere informazioni sulle analisi critiche, interessanti e di configurazione definite da questa procedura. Eseguire queste tre analisi a diverse frequenze.

I nodi critici sono dispositivi considerati molto importanti per i punti dati di raccolta delle prestazioni. La scansione dei nodi critici viene eseguita spesso, ad esempio ogni ora o su richiesta, prima e dopo le modifiche. I nodi interessati sono dispositivi considerati importanti per l'integrità complessiva dell'architettura NTP, ma che non possono trovarsi nella struttura di sincronizzazione temporale per la raccolta dei dati sulle prestazioni critiche. Questo report viene eseguito periodicamente, ad esempio ogni giorno o ogni mese. Il report di configurazione è un report completo e con un uso intensivo delle risorse che viene utilizzato per caratterizzare la configurazione di distribuzione NTP complessiva rispetto ai record di progettazione. Questo rapporto viene eseguito con minore frequenza, ad esempio, mensile o trimestrale. Un punto importante da considerare è che la frequenza con cui vengono raccolti i report può essere adeguata in base alla stabilità osservata dell'architettura NTP e alle esigenze aziendali.

Processo	Descrizione
Obiettivo del task	Monitoraggio dell'architettura NTP
Input attività	Dati dispositivo di rete
Output attività	Report
Risorse attività	Applicazioni software per la raccolta di dati e la creazione di report
Ruolo attività	Tecnico di rete

Esaminare i report dei nodi NTP

Per eseguire questa operazione è necessario che i report critici, interessanti e di configurazione vengano esaminati e analizzati. Se vengono rilevati problemi, è necessario avviare azioni correttive.

Processo	Descrizione
Input attività	Report di analisi
Output attività	Analisi della stabilità Azioni correttive
Risorse attività	Accesso ai dispositivi di rete per ulteriori indagini e verifiche
Ruolo attività	Tecnico di rete

Identificazione dei dati

Caratteristiche generali dei dati

Nella tabella seguente vengono descritti i dati considerati significativi quando si analizza l'architettura NTP.

Dati	Descrizione
ID nodi	Un dispositivo con NTP configurato
Peer	Peer configurati per il dispositivo
Origine sincronizzazione	Il peer selezionato per la sincronizzazione
Dati di configurazione NTP	Parametri utilizzati per valutare la coerenza del progetto NTP
Dati di qualità NTP	Parametri utilizzati per caratterizzare la qualità delle associazioni NTP

Identificazione dei dati SNMP

Cisco NTP MIB System Group

I dati SNMP NTP sono definiti da Cisco-NTP-MIB. Per informazioni aggiornate sulle versioni che supportano questo MIB, utilizzate lo strumento CCO Feature Navigator e selezionate l'opzione MIB Locator. È possibile accedere a questo strumento dalla pagina Strumenti TAC per le tecnologie voce, telefonia e messaggistica.

Il gruppo di sistema nel MIB Cisco NTP fornisce informazioni per il nodo di destinazione con NTP. Il nodo di destinazione è la destinazione delle query SNMP.

Nome oggetto	Descrizione oggetto
cntpSysStratum	Lo strato dell'orologio locale. Se il valore è impostato su 1, un riferimento primario, la procedura dell'orologio primario descritta nella sezione 3.4.6 della RFC-1305 viene richiamato. ::= { cntpSystem 2 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.2
cntpSysPrecision	Numero intero con segno che indica la precisione dell'orologio di sistema, in secondi, alla potenza di due più vicina. Il valore deve essere arrotondato alla successiva maggiore potenza di due. Ad esempio, a un orologio a frequenza di 50 Hz (20 ms) o 60 Hz (16,67 ms) viene assegnato il valore -5 (31,25 ms), mentre a un orologio a controllo cristallino da 1000 Hz (1 ms) viene assegnato il valore -9 (1,95 ms). ::= { cntpSystem 3 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay	Numero a virgola fissa firmato che indica il ritardo di andata e ritorno totale in secondi, all'origine del riferimento primario nella radice della subnet di sincronizzazione. ::= { cntpSystem 4 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRootDispersion	Errore massimo in secondi, relativo all'origine del riferimento primario nella radice della subnet di sincronizzazione. Sono possibili solo valori positivi maggiori di zero. ::= { cntpSystem 5 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.4
TempoRifSyscntp	Ora locale dell'ultimo aggiornamento dell'orologio locale. Se l'orologio locale non è mai stato sincronizzato, il valore è zero. ::= { cntpSystem 7 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.7
cntpSysPeer	Origine di sincronizzazione corrente contenente l'identificatore di associazione univoco cntpPeersAssocId della voce peer corrispondente nella tabella cntpPeersVarTable del peer che funge da origine di sincronizzazione. Se non è presente alcun peer, il valore è zero. ::= { cntpSystem 9 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.9
cntpSysClock	Ora locale corrente. L'ora locale è derivata dall'orologio hardware del computer specifico e viene incrementata a intervalli in base alla progettazione utilizzata. ::= { cntpSystem 10 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.1.10

Cisco NTP MIB Peer Group - Tabella variabili peer

Il gruppo di peer del MIB Cisco NTP fornisce informazioni sui peer del nodo di destinazione.

Nome oggetto	Descrizione oggetto
cntpPeersVarTable	Questa tabella fornisce informazioni sui peer con cui il server NTP locale ha associazioni. I peer sono anche server NTP che vengono eseguiti su host diversi. Questa è una tabella di cntpPeersVarEntry ::= { cntpPeers 1 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1
cntpPeersVarEntry	Ogni voce dei peer fornisce informazioni NTP recuperate da un server NTP peer specifico. Ogni peer è identificato da un identificatore di associazione univoco. Le voci vengono create automaticamente quando l'utente configura il server NTP per l'associazione con i peer remoti. Analogamente, le voci vengono eliminate quando l'utente rimuove l'associazione peer dal server NTP. Le voci possono anche essere create dalla stazione di gestione impostando i valori per cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode e imposta cntpPeersEntryStatus come attivo (1). Come minimo, la stazione di gestione deve impostare un valore per cntpPeersPeerAddress per rendere attiva la riga. INDEX { cntpPeersAssocId } ::= { cntpPeersVarTable 1 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1
cntpPeersAssocId	Valore intero maggiore di zero che identifica in modo univoco un peer a cui è associato il server NTP locale. ::= { cntpPeersVarEntry 1 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.1
cntpPeersConfigured	Questo bit indica che l'associazione è stata creata in base alle informazioni di configurazione e non deve essere dissociata anche se il peer non è più raggiungibile. ::= { cntpPeersVarEntry 2 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.2
cntpPeerAddress	Indirizzo IP del peer. Quando viene creata una nuova associazione, è necessario impostare un valore per questo oggetto prima di attivare la riga. ::= { cntpPeersVarEntry 3 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersMode	SYNTAX INTEGER { non specificato (0), symmetricActive (1), symmetricPassive (2), client (3), server (4), broadcast (5), ReservedControl (6), ReservedPrivate (7) } Quando viene creata una nuova associazione peer, se non viene specificato alcun valore per questo oggetto, il valore predefinito è symmetricActive (1). ::= { cntpPeersVarEntry 8 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntpPeersStratum	Strato dell'orologio peer. ::= { cntpPeersVarEntry 9 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.9
cntpPeersRootDelay	Numero a virgola fissa firmato che indica il ritardo di andata e ritorno totale in secondi, dal peer all'origine di riferimento primaria nella radice della subnet di sincronizzazione. ::= { cntpPeersVarEntry 13 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.13
cntpPeersRootDispersion	Errore massimo, in secondi, dell'orologio del peer relativo all'origine del riferimento primario nella radice della subnet di sincronizzazione. Sono possibili solo valori positivi maggiori di zero. ::= { cntpPeersVarEntry 14 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.14
TempoRiferimentoPeercntp	Ora locale del peer in cui è stato eseguito l'ultimo aggiornamento dell'orologio. Se l'orologio del peer non è mai stato sincronizzato, il valore è zero. ::= { cntpPeersVarEntry 16 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.16
cntpPeersReach	Registro di spostamento utilizzato per determinare lo stato di raggiungibilità del peer, con bit che entrano dall'estremità meno significativa (all'estrema destra). Un peer è considerato raggiungibile se almeno un bit in questo registro è impostato su uno (l'oggetto è diverso da zero). I dati nel registro dei turni vengono popolati dalle procedure del protocollo NTP. ::= { cntpPeersVarEntry 21 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersOffset	Offset stimato dell'orologio del peer relativo all'orologio locale, in secondi. L'host determina il valore di questo oggetto che utilizza l'algoritmo di filtro del clock NTP. ::= { cntpPeersVarEntry 23 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersDelay	Ritardo di andata e ritorno stimato dell'orologio del peer rispetto all'orologio locale sul percorso di rete tra di essi, in secondi. L'host determina il valore di questo oggetto che utilizza l'algoritmo di filtro del clock NTP. ::= { cntpPeersVarEntry 24 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.24
cntpPeersDispersion	L'errore massimo stimato dell'orologio del peer relativo all'orologio locale sul percorso di rete tra i due, in secondi. L'host determina il valore di questo oggetto che utilizza l'algoritmo di filtro del clock NTP. ::= { cntpPeersVarEntry 25 } identificatore oggetto = .1.3.6.1.4.1.9.9.168.1.2.1.1.25

Raccolta dati

Raccolta dei dati SNMP

Tutte le informazioni richieste da questa procedura possono essere raccolte tramite le query SNMP. Per analizzare i dati e produrre le relazioni, è necessario sviluppare script personalizzati o programmi software.

Presentazione dei dati

Report sui nodi critici NTP

I nodi critici sono dispositivi importanti nella struttura di sincronizzazione dei punti di raccolta dei dati sulle prestazioni selezionati. Se viene monitorato un servizio VoIP ad alto fatturato e vengono raccolte metriche di variazione del ritardo unidirezionale, i nodi di origine e di destinazione in cui vengono registrati i timestamp sono considerati nodi critici.

In questo esempio, il progetto NTP è stato definito in base a una gerarchia OSPF di esempio. Pertanto, i report descritti di seguito vengono formattati per raggruppare i dispositivi NTP in base all'area OSPF del dispositivo. Nei casi in cui un nodo dispone di interfacce in più aree, il software di generazione dei report deve decidere quale area del nodo può essere elencata ai fini del report. Come accennato in precedenza, l'OSPF non è un prerequisito per l'NTP. Viene utilizzata in questo documento solo come esempio illustrativo.

Area	Sul dispositivo bootflash o slot0:	Dati dispositivo	Valore
ID area n	ID dispositivo n. 1	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		TempoRifSyscntp
		cntpSysPeer
		cntpSysClock
	ID dispositivo n	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		TempoRifSyscntp
		cntpSysPeer
		cntpSysClock

Rapporto Nodo interessante NTP

Il formato del report del nodo interessante è identico a quello del report del nodo critico. I nodi interessanti sono quelli considerati importanti per l'architettura NTP complessiva, ma non possono contribuire direttamente alla sincronizzazione temporale dei punti critici di monitoraggio delle prestazioni.

Report configurazione NTP

Il report di configurazione è un report completo che raccoglie informazioni sull'architettura NTP complessiva. Questo report viene utilizzato per registrare e verificare la distribuzione NTP rispetto ai record di progettazione.

Area	Sul dispositivo bootflash o slot0:	Peer	Dati peer	Valore
ID area n	ID dispositivo n	ID peer 1	cntpPeersAssocId
			cntpPeersConfigured
			cntpPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			TempoRiferimentoPeercntp
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion
		PeerId n	cntpPeersAssocId
			cntpPeersConfigured
			cntpPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			TempoRiferimentoPeercntp
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion

Informazioni correlate

• RFC 1305 - Protocollo orario di rete
• RFC 2330 - Framework per le metriche delle prestazioni IP
• Funzionalità essenziali di Cisco IOS per ogni ISP è necessario considerare la versione 2.84
• Supporto tecnico Cisco e download