Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Terminologia

Panoramica

Panoramica del dispositivo

Panoramica NTP

Criteri di progettazione NTP

Modalità di associazione

Modalità client/server

Modalità attiva/passiva simmetrica

Modalità broadcast e/o multicast

Imposta secondo balzo NTP

Architettura NTP

Tecnologia dell'orologio e server per l'ora pubblica

Esempi di distribuzioni NTP

WAN Time Distribution Network

Rete di distribuzione tempo High Stratum Campus

Rete di distribuzione del tempo del campus a basso livello

Definizioni dei processi

Proprietario processo

Obiettivi del processo

Indicatori prestazioni processo

Input processo

Output del processo

Definizioni attività

Task di inizializzazione

Creazione del progetto NTP

Creazione di un file di inizializzazione

Parametri delle prestazioni NTP della linea di base

Attività iterative

Gestisci file di inizializzazione

Eseguire la scansione del nodo NTP

Esaminare i report dei nodi NTP

Identificazione dei dati

Caratteristiche generali dei dati

Identificazione dei dati SNMP

Cisco NTP MIB System Group

Cisco NTP MIB Peer Group - Tabella variabili peer

Raccolta dati

Raccolta dei dati SNMP

Presentazione dei dati

Report sui nodi critici NTP

Rapporto Nodo interessante NTP

Report configurazione NTP

Informazioni correlate

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

Nota: una serie di grafici che mostrano una distribuzione NTP scalabile e gerarchica. Il primo grafico mostra due dispositivi NTP di strato 2, ciascuno dei quali è collegato a due dispositivi di strato 1 (mostrati nel diagramma precedente dei dispositivi di strato 2) e un contatto in un'altra subnet indicato da un asterisco. Inoltre, ogni dispositivo di strato 2 ha una freccia rivolta verso il basso. Il secondo grafico ha lo stesso layout, ma con dispositivi dello strato 2 dove erano i dispositivi dello strato 1 e dispositivi dello strato 3 dove erano i dispositivi dello strato 2. Il terzo grafico ha un dispositivo di strato 4 collegato a tre dispositivi di strato 3. In sintesi, l'immagine mostra una topologia in cui ogni dispositivo è connesso a 2-3 dispositivi con uno strato uno inferiore (migliore) del proprio.

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

Nota: Un grafico che presenta modi sempre più precisi di mantenere il tempo dal quarzo (10 alla potenza negativa 8a) al maser a idrogeno (10 alla potenza negativa 15a). Quest'ultima indica una perdita di precisione di circa 1 secondo in 32 milioni di anni. Gli altri metodi elencati tra questi due (dal meno al più accurato) sono Rubidium, Cesium, Loran C, GPS e CDMA. Gli ultimi tre (Loran C, GPS e CDMA) sono elencati insieme.

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

Nota: un diagramma che delinea una topologia NTP che si estende su più reti. Tre dispositivi nell'area 1 (OSPF) sono peer l'uno dell'altro e client dei server nell'area 0. Tre dispositivi nell'area 0 sono peer uno dell'altro, client di server di riferimento orario pubblico e server di client nell'area 1. I server di riferimento orario pubblico vengono visualizzati solo come server per i client nell'area 0.

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

Nota: un diagramma intitolato High Stratum Campus Time Distribution Network che include una topologia generica a tre livelli (backbone, distribuzione, accesso). Gli switch di accesso sono client di switch di distribuzione, gli switch di distribuzione sono client di switch di backbone e gli switch di backbone sono client di server area time (non in figura). Gli switch di distribuzione sono divisi in coppie e hanno una relazione peer solo con l'altro switch della coppia. I due switch della backbone sono anche peer tra loro. Quattro switch di accesso (in alto a sinistra) vengono mostrati come client di trasmissione con frecce punteggiate, mentre tutte le altre relazioni client-server e peer-peer non sono broadcast.

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

Nota: un diagramma intitolato Low Stratum Campus Time Distribution Network che include una topologia generica a tre livelli (backbone, distribuzione, accesso). Due interruttori di distribuzione sono dotati di orologi GPS o cesio. Gli switch di accesso collegati direttamente a questi switch di distribuzione e gli switch della backbone sono client di questi switch di distribuzione. Tutti gli altri switch di distribuzione sulla rete sono client degli switch backbone e gli altri switch di accesso sono anche client dei loro switch di distribuzione collegati direttamente. Quattro switch di accesso (in alto a sinistra) vengono mostrati come client di trasmissione con frecce punteggiate, mentre tutte le altre relazioni client-server e peer-peer non sono broadcast.

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

Nota: diagramma che specifica il significato di un processo utilizzato da questo documento. Ci sono cinque regioni. La regione sinistra ha un bordo solido. Contiene Input, SNMP e Syslog. È presente una freccia unidirezionale dalla regione sinistra alla regione centrale. Anche la regione destra ha un bordo solido. Contiene Output, Report e Metrica. È presente una freccia unidirezionale dall'area centrale all'area destra. L'area superiore presenta un bordo punteggiato. Contiene il proprietario, gli obiettivi e gli indicatori di prestazioni. Intorno ai tre cerchi sono presenti bordi ben delineati. Sono presenti frecce bidirezionali tra (a) proprietario e Indicatori prestazioni (b) obiettivi e Indicatori prestazioni e (c) la regione superiore e la regione centrale. Anche l'area inferiore presenta un bordo punteggiato. Contiene risorse e ruoli. Intorno a entrambi sono presenti cerchi con bordi continui. Esistono frecce bidirezionali che sembrano connettere risorse e ruoli all'area centrale, ma si fermano al bordo dell'area inferiore. L'area centrale presenta un bordo in tinta unita e un'intestazione con il nome Processo. Contiene inoltre una per ogni attività e sottoattività. Ognuna presenta un bordo circolare continuo. All'interno del cerchio di Attività è presente più spazio vuoto di qualsiasi altro elemento del grafico.

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:

1. Dispositivi critici: polling frequente delle informazioni di configurazione

2. Dispositivi interessanti: polling meno frequente

3. 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