Use Best Practices for Network Time Protocol (Aanbevolen procedures voor Network Time Protocol gebruiken)

Inleiding

Dit document beschrijft de best practices voor het ontwerpen van Network Time Protocol.

Voorwaarden

Vereisten

Cisco raadt u aan bekend te zijn met dit onderwerp:   

• Network Time Protocol

• Kloktechnologie en openbare tijdservers

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Op IP-gebaseerde netwerken (Internet Protocol) zijn snel geavanceerd van het traditionele model voor de levering van beste prestaties naar een model waarin prestaties en betrouwbaarheid moeten worden gekwantificeerd en in veel gevallen moeten worden gegarandeerd met Service Level Agreement (SLA’s). De behoefte aan groter inzicht in netwerkkenmerken heeft tot significante onderzoeksinspanningen geleid die op belangrijke metriek en metingsmogelijkheden worden gericht om netwerkgedrag te karakteriseren. De basis van vele metrische methodologieën is de meting van tijd.

De synchronisatie van de netwerktijd, in de mate die voor moderne prestatiesanalyse wordt vereist, is een essentiële oefening. Gebaseerd in de bedrijfsmodellen, en de diensten die worden verleend, wordt de karakterisering van netwerkprestaties beschouwd als een belangrijke concurrerende de dienstdifferentiator In deze gevallen, worden de grote uitgaven opgelopen wanneer u netwerkbeheersystemen en directe ingenieursmiddelen opstelt om de verzamelde prestatiesgegevens te analyseren. Als echter niet voldoende aandacht wordt besteed aan het vaak over het hoofd geziene principe van tijdsynchronisatie, zijn deze inspanningen niet effectief.

Dit document beschrijft een hypothetische procesdefinitie voor het beheer van de netwerkbeheerfunctie voor het Network Time Protocol (NTP). Je kunt dit artikel gebruiken als een hypothetische procedure en een informatief voorbeeld. Dit kan door een organisatie worden aangepast om interne doelstellingen te bereiken.

De informatie in dit document wordt in verschillende hoofdstukken gepresenteerd:

• De sectie Terminologie biedt algemene definities van termen rond tijdsynchronisatie.
• De sectie Overzicht verstrekt achtergrondinformatie over de hardware van het netwerkelement met betrekking tot systeemtijd, een technologisch overzicht van NTP, en zeer belangrijke ontwerpaspecten voor de architectuur NTP.
• De sectie van de Plaatsing van NTP van het Voorbeeld voorziet NTP plaatsingsvoorbeelden van steekproefconfiguraties voor WAN, high stratum campus, en lage stratum de distributienetwerken van de campustijd.
• De sectie Procesdefinities biedt een overzicht van de procesdefinities die worden gebruikt om NTP-beheer te realiseren. De procesdetails worden beschreven in termen van doelen, prestatie-indicatoren, inputs, outputs en individuele taken.
• De sectie Taakdefinities biedt gedetailleerde definities voor procestaken. Elke taak wordt beschreven in termen van doelstellingen, input van taken, output van taken, vereiste middelen om de taak te volbrengen, en baanvaardigheden die nodig zijn voor een taakuitvoerder.
• In het gedeelte Data Identification wordt de gegevensidentificatie voor NTP beschreven. Identificatie van de gegevens is de bron van de informatie. Deze informatie kan bijvoorbeeld worden opgeslagen in de Simple Network Management Protocol (SNMP) Management Information Base (MIB), in door Syslog gegenereerde logbestanden of in interne gegevensstructuren die alleen toegankelijk zijn via de opdrachtregelinterface (CLI).
• In het gedeelte Gegevensverzameling wordt beschreven hoe de NTP-gegevens worden verzameld. Het verzamelen van de gegevens houdt nauw verband met de locatie van de gegevens. SNMP MIB-gegevens worden bijvoorbeeld verzameld door middel van verschillende mechanismen, zoals traps, alarmen en gebeurtenissen voor controle op afstand (RMON) of peilingen. Gegevens die door interne gegevensstructuren worden bijgehouden, worden verzameld door automatische scripts of wanneer een gebruiker zich handmatig aanmeldt in het systeem om de CLI-opdracht uit te geven en de uitvoer op te nemen.
• De sectie Data Presentation biedt voorbeelden van het rapportageformaat van hoe de gegevens kunnen worden gepresenteerd.

Terminologie

• Nauwkeurigheid: de nabijheid van de absolute waarde van de kloktijd tot de offset van nul.

• Nauwkeurig — wanneer een klokoffset op een bepaald moment op nul staat.

• Drift - de meting in de variatie van de scheefheid, of de tweede afleiding van de klokoffset ten opzichte van de tijd.

• Gezamenlijke resolutie—Wanneer klokken worden vergeleken, is het de som van de resoluties van C1 en C2. De gezamenlijke resolutie geeft dan een conservatieve ondergrens aan van de nauwkeurigheid van de tijdsintervallen die worden berekend door tijdstempels die door een klok worden gegenereerd en afgetrokken van die welke door de andere klok worden gegenereerd.

• Knooppunt—verwijst naar een concretisering van het NTP-protocol op een lokale processor. Een knooppunt kan ook een apparaat worden genoemd.

• Offset-het verschil tussen de tijd die door een klok wordt gemeld en de werkelijke tijd zoals gedefinieerd door Coordinated Universal Time (UTC). Als de klok een tijd Tc rapporteert en de echte tijd Tt is, dan is de klokoffset Tc - Tt.

• Peer—verwijst naar een concretisering van het NTP-protocol op een externe processor die is aangesloten via een netwerkpad vanaf de lokale knooppunt.

• Relatieve offset—het begrip werkelijke tijd wordt vervangen door de tijd zoals aangegeven door kloktijd C1, wanneer twee klokjes, C1 en C2, worden vergeleken. Bijvoorbeeld, de offset van de klok C2 ten opzichte van C1 op een bepaald moment is Tc2 - Tc1, het momentane verschil in tijd gerapporteerd door C2 en C1.

• Resolutie—De kleinste eenheid waarmee een kloktijd wordt bijgewerkt. De resolutie wordt gedefinieerd in seconden. De resolutie is echter relatief ten opzichte van de door de klok aangegeven tijd en niet ten opzichte van de werkelijke tijd. Een resolutie van 10 milliseconden betekent bijvoorbeeld dat de kloktijd in stappen van 0,01 seconde wordt bijgewerkt en niet dat dit de werkelijke hoeveelheid tijd tussen de updates is.

  Opmerking: klokken kunnen zeer fijne resoluties hebben en nog steeds onnauwkeurig zijn.

• Scheefheid—Een klokfrequentieverschil of een eerste afgeleid van de offset ten opzichte van de tijd.

• Synchroniseren—Wanneer twee klokken nauwkeurig zijn ten opzichte van elkaar (relatieve offset is nul), worden ze gesynchroniseerd. Klokken kunnen gesynchroniseerd worden en nog steeds onnauwkeurig zijn in termen van hoe goed ze de werkelijke tijd vertellen.

Overzicht

Apparaatoverzicht

Het hart van de tijdsdienst is de systeemklok. De systeemklok loopt vanaf het moment dat het systeem start en houdt de huidige datum en tijd bij. De systeemkloktijd kan uit een aantal bronnen worden ingesteld en kan worden gebruikt om de huidige tijd via verschillende mechanismen naar andere systemen te verdelen. Sommige routers bevatten een batterij-aangedreven kalender systeem dat de datum en de tijd over systeemherstart en stroomuitval volgt. Dit kalendersysteem wordt altijd gebruikt om de systeemklok te initialiseren wanneer het systeem opnieuw wordt opgestart. Het kan ook als een gezaghebbende bron van tijd worden beschouwd en via NTP worden herverdeeld als er geen andere bron beschikbaar is. Bovendien, als NTP is ingeschakeld, wordt de kalender periodiek bijgewerkt vanaf NTP, en dit compenseert de inherente verschuiving in de kalendertijd. Wanneer een router met een systeemkalender wordt geïnitialiseerd, wordt de systeemklok ingesteld op basis van de tijd in zijn interne batterij-aangedreven kalender. Op modellen zonder kalender wordt de systeemklok ingesteld op een vooraf bepaalde tijdconstante. De systeemklok kan worden ingesteld uit de volgende bronnen.

• NTP

• Simple Network Time Protocol (SNTP)

• Virtual Integrated Network Service (VINES) - Tijdservice

• Handmatige configuratie

Bepaalde low-end Cisco-apparaten ondersteunen alleen SNTP. SNTP is een vereenvoudigde, client-only versie van NTP. SNTP kan alleen de tijd van NTP-servers ontvangen en kan niet worden gebruikt om tijdservices aan andere systemen te leveren. SNTP biedt doorgaans tijd binnen 100 milliseconden van de nauwkeurige tijd. Daarnaast verifieert SNTP geen verkeer, hoewel u uitgebreide toegangslijsten kunt configureren om enige bescherming te bieden. Een SNTP-client is kwetsbaarder voor niet-conforme servers dan een NTP-client en mag alleen worden gebruikt in situaties waarin geen sterke verificatie is vereist.

De systeemklok geeft tijd aan de volgende diensten.

• NTP

• VINES time service

• Gebruiker toont opdrachten

• Berichten vastleggen en debuggen

De systeemklok houdt de tijd intern bij op basis van UTC, ook wel bekend als Greenwich Mean Time (GMT). U kunt informatie over de lokale tijdzone en de zomertijd zo configureren dat de tijd correct wordt weergegeven ten opzichte van de lokale tijdzone. De systeemklok houdt bij of de tijd betrouwbaar is of niet. Als de tijd niet betrouwbaar is, kan deze alleen beschikbaar zijn voor weergavedoeleinden en kan deze niet opnieuw worden gedistribueerd.

NTP-overzicht

NTP is ontworpen om de tijd te synchroniseren op een netwerk van machines. NTP loopt over het User Datagram Protocol (UDP), met poort 123 als zowel bron als bestemming, die op zijn beurt via IP loopt. NTP versie 3 RFC 1305 wordt gebruikt om de tijd tussen een reeks gedistribueerde tijdservers en clients te synchroniseren. Een set knooppunten op een netwerk wordt geïdentificeerd en geconfigureerd met NTP en de knooppunten vormen een synchronisatiesubnet, soms aangeduid als een overlay-netwerk. Hoewel meerdere primaire servers kunnen bestaan, is er geen vereiste voor een verkiezingsprotocol.

Een NTP-netwerk krijgt zijn tijd meestal van een gezaghebbende tijdbron, zoals een radiokloktijd of een atoomklok die is aangesloten op een tijdserver. NTP verdeelt deze tijd vervolgens over het netwerk. Een NTP-client maakt een transactie met de server over zijn pollinginterval (van 64 tot 1024 seconden) die dynamisch verandert in de tijd afhankelijk van de netwerkvoorwaarden tussen de NTP-server en de client. De andere situatie doet zich voor wanneer de router communiceert met een slechte NTP server (bijvoorbeeld NTP server met grote dispersie); de router verhoogt ook het poll interval. Er is niet meer dan één NTP-transactie per minuut nodig om twee machines te synchroniseren.

NTP gebruikt het concept van een stratum om te beschrijven hoeveel NTP-hop weg een machine is van een gezaghebbende tijdbron. Bijvoorbeeld, een stratum 1 tijdserver heeft een radio of atoomklok direct aan het bevestigd. Het stuurt dan zijn tijd naar een stratum 2 tijdserver via NTP, enzovoort. Een machine die NTP in werking stelt kiest automatisch de machine met het laagste stratumaantal dat het om met NTP als zijn tijdbron wordt gevormd te communiceren. Deze strategie bouwt effectief een zelforganiserende boom van NTP-sprekers. NTP presteert goed over de niet-deterministische weglengten van pakketgeschakelde netwerken omdat het robuuste ramingen van de volgende drie zeer belangrijke variabelen in de verhouding tussen een cliënt en een tijdserver maakt.

• Netwerkvertraging

• Dispersie van het pakket van de tijd uitwisseling-een maatregel van maximumklokfout tussen de twee gastheren.

• Klokoffset: de correctie die wordt toegepast op een clientkloktijd om deze te synchroniseren.

Kloksynchronisatie op het niveau van 10 milliseconden over WAN-netwerken (2000 km) en op het niveau van 1 milliseconde voor LAN-netwerken (Local Area Networks) wordt routinematig bereikt.

Er zijn twee manieren waarin NTP niet synchroniseert met een machine waarvan de tijd niet nauwkeurig is. Ten eerste, NTP synchroniseert nooit met een machine die niet gesynchroniseerd is. Ten tweede vergelijkt NTP de door verschillende machines gerapporteerde tijd en synchroniseert niet met een machine waarvan de tijd aanzienlijk verschilt van de andere, zelfs als haar stratum lager is.

De communicatie tussen machines die NTP (verenigingen) in werking stellen wordt gewoonlijk statisch gevormd. Elke machine krijgt het IP-adres van alle machines waarmee het associaties moet vormen. Nauwkeurige tijdregistratie wordt mogelijk gemaakt door NTP-berichten die tussen elk paar machines met een associatie worden uitgewisseld. In een LAN-omgeving kan NTP echter worden geconfigureerd om IP-uitzendberichten te gebruiken. Dit alternatief vermindert de complexiteit van de configuratie, omdat elke machine kan worden geconfigureerd om broadcast-berichten te verzenden of ontvangen. De nauwkeurigheid van de tijdsbewaring wordt echter marginaal verminderd omdat de informatiestroom slechts eenrichtingsverkeer is.

De tijd die op een machine wordt gehouden is een kritieke bron en het wordt sterk aanbevolen dat u de beveiligingsfuncties van NTP gebruikt om de toevallige of kwaadaardige instelling van onjuiste tijd te vermijden. De twee beschikbare beveiligingsfuncties zijn een op toegangslijsten gebaseerde beperkingsregeling en een versleuteld verificatiemechanisme.

Cisco-implementatie van NTP ondersteunt de service stratum 1 in bepaalde Cisco IOS®-softwarereleases. Als een release de opdracht ntp refClock ondersteunt, is het mogelijk om een radio- of atoomklok aan te sluiten. Bepaalde releases van Cisco IOS ondersteunen ofwel de Trimble Palisade NTP-synchronisatiekit (alleen Cisco 7200-Series routers) of het Global Positioning System (GPS)-apparaat (Telecom Solutions). Als het netwerk de openbare tijdservers op het internet gebruikt en het netwerk van het internet is geïsoleerd, kan een machine door Cisco-implementatie van NTP worden geconfigureerd, zodat het doet alsof het via NTP gesynchroniseerd is, terwijl het in feite de tijd op een andere manier heeft bepaald. Andere machines synchroniseren vervolgens met die machine via NTP.

NTP-ontwerpcriteria

Elke client in het synchronisatiesubnet, die ook een server kan zijn voor hogere stratum clients, kiest een van de beschikbare servers om te synchroniseren. Dit is meestal een van de laagste stratum servers waartoe het toegang heeft. Dit is echter niet altijd een optimale configuratie, omdat NTP ook werkt vanuit het uitgangspunt dat elke servertijd met een bepaalde hoeveelheid wantrouwen moet worden bekeken. NTP geeft de voorkeur aan toegang tot verschillende bronnen van lagere stratum tijd (ten minste drie) omdat het dan een overeenkomst algoritme kan toepassen om waanzin te ontdekken van de kant van een van deze. Normaal, wanneer alle servers akkoord gaan, kiest NTP de beste server in termen van laag stratum, het dichtst (in termen van netwerkvertraging), en beweerde precisie. De implicatie is dat, terwijl men moet proberen om elke cliënt van drie of meer bronnen van lagere stratumtijd te voorzien, verscheidene hiervan slechts reservedienst kunnen verlenen en van minder kwaliteit in termen van netwerkvertraging en stratum kunnen zijn. Bijvoorbeeld, een zelfde-stratum peer die tijd van lagere stratum bronnen ontvangt de lokale server niet direct toegang heeft tot, kan ook goede reservedienst verlenen.

NTP verkiest over het algemeen lagere stratum servers boven hogere stratum servers, tenzij de lagere stratum server tijd aanzienlijk anders is. Het algoritme is in staat om te detecteren wanneer een tijdbron waarschijnlijk extreem onnauwkeurig of krankzinnig is, en om synchronisatie in deze gevallen te voorkomen, zelfs als de onnauwkeurige kloktijd zich op een lager stratumniveau bevindt. En het kan nooit een apparaat synchroniseren met een andere server die niet gesynchroniseerd is.

Om te kunnen verklaren of een server betrouwbaar is, moet deze vele controles van de gezondheid doorstaan, zoals:

• De implementaties moeten voorzien in tijdsbestekken die de doorgifte van valstrikken voorkomen indien het controleprogramma deze informatie na een lange periode niet verlengt.

• Er worden aanvullende controles op de juistheid van de authenticiteit, de bereikgrenzen en het gebruik van zeer oude gegevens voorkomen.

• Er zijn controles toegevoegd om te waarschuwen dat de oscillator te lang is gegaan zonder update van een referentiebron.

• De variabelen peer.geldige en sys.hold werden toegevoegd om instabiliteit te voorkomen wanneer de referentiebron snel verandert als gevolg van grote dispersieve vertragingen bij ernstige netwerkcongestie. De peer.config, peer.authenticable en peer.authentieke bits werden toegevoegd om speciale functies te controleren en de configuratie te vereenvoudigen.

Als minstens één van die controles ontbreekt, verklaart de router het krankzinnig.

Associatiemodi

In de volgende secties worden de koppelingsmodi beschreven die door NTP-servers worden gebruikt om aan elkaar te koppelen.

• Clientserver

• Symmetrisch actief/passief

• uitzenden

Clientmodus/servermodus

De afhankelijke cliënten en de servers werken normaal in cliënt/serverwijze, waarin een cliënt of de afhankelijke server aan een groepslid kunnen worden gesynchroniseerd, maar geen groepslid kan aan de cliënt of de afhankelijke server synchroniseren. Dit biedt bescherming tegen storingen of protocolaanvallen.

De client/server-modus is de meest gebruikelijke internetconfiguratie. Het werkt in het klassieke remote-procedure-call (RPC) paradigma met stateless servers. In deze modus stuurt een client een verzoek naar de server en verwacht een antwoord op een later tijdstip. In sommige contexten, zou dit als opiniepeilingsverrichting worden beschreven, in die zin dat de cliënt de tijd en de authentificatiegegevens van de server opiniepeilt. Een client is geconfigureerd in clientmodus met de serveropdracht en met de domeinnaam (DNS) naam of adres opgegeven. De server hoeft niet vooraf te worden geconfigureerd.

In een gemeenschappelijk client/server model, een client verzendt een NTP bericht naar een of meer servers en verwerkt de antwoorden zoals ontvangen. De server wisselt adressen en poorten uit, overschrijft bepaalde velden in het bericht, herberekent de controlesom en retourneert het bericht onmiddellijk. Informatie die in het NTP-bericht is opgenomen, stelt de client in staat de servertijd te bepalen ten opzichte van de lokale tijd en vervolgens de lokale klok aan te passen zoals nodig. Daarnaast bevat het bericht informatie om de verwachte nauwkeurigheid en betrouwbaarheid van de tijdregistratie te berekenen en de beste server te selecteren.

De servers die synchronisatie aan een aanzienlijke populatie van cliënten verstrekken werken normaal als groep van drie of meer wederzijds overtollige servers, en elk werkt met drie of meer stratum 1 of stratum 2 servers in cliënt/serverwijzen, evenals alle andere leden van de groep in symmetrische wijzen. Dit biedt bescherming tegen storingen waarbij een of meer servers niet werken of een onjuiste tijd gebruiken. De NTP-algoritmen zijn ontworpen om aanvallen te weerstaan wanneer een deel van de geconfigureerde synchronisatiebronnen per ongeluk of met opzet onjuiste tijd geeft. In deze gevallen wordt een speciale stemprocedure gebruikt om verkeerde bronnen te identificeren en hun gegevens te verwijderen. In het belang van de betrouwbaarheid kunnen geselecteerde hosts worden uitgerust met externe klokken en worden gebruikt voor back-up in geval van storing van de primaire en/of secundaire servers, of communicatiepaden tussen hen.

De configuratie van een associatie in de clientmodus wordt meestal aangegeven door een serververklaring in het configuratiebestand en geeft aan dat u tijd wilt winnen van de externe server, maar dat u geen tijd wilt geven aan de externe server.

Symmetrische actieve/passieve modus

De symmetrische actieve/passieve modus is bedoeld voor configuraties waarbij een groep laagstratumpeers als wederzijdse back-ups voor elkaar fungeert. Elke peer werkt met een of meer primaire referentiebronnen, zoals een radiokloklokatie of een subset van betrouwbare secundaire servers. Als een van de peers alle referentiebronnen verliest of de werking simpelweg stopt, worden de andere peers automatisch opnieuw geconfigureerd, zodat de tijdwaarden kunnen stromen van de huidige peers naar alle anderen in de wachtrij. In sommige contexten wordt dit beschreven als een push-pull-operatie, in die zin dat de peer de tijd en waarden die zijn gebaseerd op de specifieke configuratie, trekt of drukt.

De configuratie van een associatie in symmetrisch-actieve modus, meestal aangegeven door een peer-verklaring in het configuratiebestand, geeft aan dat men tijd wil winnen van de remote server en dat men ook bereid is om tijd te leveren aan de remote server indien nodig. Deze modus is geschikt in configuraties waarbij een aantal redundante tijdservers betrokken zijn die onderling verbonden zijn via verschillende netwerkpaden, wat momenteel het geval is voor de meeste stratum 1- en stratum 2-servers op het internet.

Symmetrische modi worden meestal gebruikt tussen twee of meer servers die werken als een wederzijds redundante groep. In deze modi regelen de servers in de groepsleden de synchronisatiepaden voor de maximale prestaties, gebaseerd op netwerksplitter en voortplantingsvertraging. Als een of meer van de groepsleden falen, zullen de overige leden automatisch naar wens aanpassen.

Een peer is geconfigureerd in symmetrische actieve modus met de peer opdracht en wanneer de DNS naam of het adres van de andere peer is gespecificeerd. De andere peer is ook op deze manier geconfigureerd in symmetrische actieve modus.

Opmerking: Als de andere peer niet specifiek op deze manier is geconfigureerd, wordt bij aankomst van een symmetrisch actief bericht een symmetrische passieve associatie geactiveerd. Aangezien een indringer een symmetrische actieve peer kan imiteren en valse tijdwaarden kan inspuiten, moet de symmetrische modus altijd worden geverifieerd.

Uitzending en/of multicast-modus

Als de vereisten op het gebied van nauwkeurigheid en betrouwbaarheid bescheiden zijn, kunnen clients worden geconfigureerd om broadcast- en/of multicastmodi te gebruiken. Normaal gesproken worden deze modi niet gebruikt door servers met afhankelijke clients. Het voordeel is dat clients niet hoeven te worden geconfigureerd voor een specifieke server, en dit stelt alle operationele clients in staat om hetzelfde configuratiebestand te gebruiken. In de uitzendmodus is een uitzendserver op dezelfde subnetserver nodig. Aangezien de uitzendingsberichten niet door routers worden verspreid, worden slechts uitzendingsservers op zelfde Subnet gebruikt.

De uitzendmodus is bedoeld voor configuraties waarbij een of enkele servers en een potentieel grote clientpopulatie betrokken zijn. Een uitzendingsserver wordt gevormd met het uitzendingsbevel en een lokaal subnetadres. Een broadcast-client is geconfigureerd met de opdracht broadcast-client, waarmee de broadcast-client kan reageren op de broadcast-berichten die op een willekeurige interface worden ontvangen. Aangezien een indringer een uitzendserver kan nabootsen en valse tijdwaarden kan inspuiten, moet deze modus altijd worden geverifieerd.

NTP-schrikkelseconde instellen

U kunt de ntp sprong gebruiken {add | schrap} bevel om een sprongseconde op te nemen. Er zijn opties voor het toevoegen of verwijderen van schrikkelseconden. Er zijn twee beperkingen voor dit om voor te komen:

• De klok moet in sync-staat zijn.

• Het commando wordt alleen geaccepteerd binnen de maand voordat de sprong moet gebeuren. Er kan geen sprong worden gemaakt als de huidige tijd vóór 1 maand na het optreden van de sprong ligt.

Nadat u het hebt ingesteld, wordt de sprongseconde toegevoegd of verwijderd tot de laatste seconde zoals hier getoond:

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

NTP-architectuur

Deze drie structuren zijn beschikbaar voor NTP-architectuur:

• Platte peer-structuur

• Hiërarchische structuur

• Sterstructuur

In een vlakke peer structuur, alle routers met elkaar, met een paar geografisch afzonderlijke routers die worden gevormd om aan externe systemen te richten. De convergentie van de tijd wordt langer met elk nieuw lid van het NTP-netwerk.

In een hiërarchische structuur, wordt de routing hiërarchie gekopieerd voor de NTP hiërarchie. Core-routers hebben een client/server-relatie met externe tijdbronnen, de interne tijdservers hebben een client/server-relatie met de kernrouters, de interne gebruiker (niet-tijdservers)-routers hebben een client/server-relatie met de interne tijdservers, enzovoort in de boomstructuur. Deze relaties worden hiërarchische schalen genoemd. Een hiërarchische structuur heeft de voorkeur omdat deze zorgt voor consistentie, stabiliteit en schaalbaarheid.

Een schaalbare NTP-architectuur heeft een hiërarchische structuur zoals in het volgende diagram.

Schaalbare NTP-architectuur

In een sterstructuur, hebben alle routers een cliënt/serververhouding met een paar tijdservers in de kern. De speciale tijdservers zijn het centrum van de ster en zijn meestal UNIX-systemen gesynchroniseerd met externe tijdbronnen, of hun eigen GPS-ontvanger.

Kloktechnologie en openbare tijdservers

Het Internet NTP-subnetnummer omvat momenteel meer dan 50 openbare primaire servers die direct gesynchroniseerd zijn met UTC via radio, satelliet of modem. Normaal gesproken synchroniseren clientwerkstations en servers met een relatief klein aantal clients niet met primaire servers. Ongeveer 100 openbare secundaire servers zijn gesynchroniseerd met de primaire servers en zorgen voor synchronisatie met een totaal van meer dan 100.000 clients en servers op het internet. De openbare lijsten van NTP-tijdservers worden regelmatig bijgewerkt. Er zijn ook tal van privaat primaire en secundaire servers die normaal niet beschikbaar zijn voor het publiek.

Opmerking: PIX en ASA kunnen niet als NTP-server worden geconfigureerd, maar als NTP-client.

In bepaalde gevallen, waar de hoogst nauwkeurige tijddiensten op de privé onderneming worden vereist, zoals unidirectionele metriek voor de metingen van de Stem over IP (VoIP), kunnen de netwerkontwerpers verkiezen om privé externe tijdbronnen op te stellen. Het volgende diagram toont een vergelijkende grafiek van de relatieve nauwkeurigheid van de huidige technologieën.

Vergelijkende grafiek

Tot voor kort is het gebruik van externe tijdbronnen niet breed ingezet in ondernemingsnetwerken vanwege de hoge kosten van externe tijdbronnen van hoge kwaliteit. Aangezien de vereisten voor Quality of Service (QoS) toenemen en de kosten van de tijdtechnologie blijven dalen, zijn externe tijdbronnen voor ondernemingsnetwerken echter een levensvatbare optie.

Voorbeeld NTP-implementaties

WAN-tijddistributienetwerk

In het volgende diagram, verkrijgt een collectief autonoom systeem (AS) tijdinformatie van drie openbare tijdservers. Het bedrijfs-AS wordt weergegeven als Area 0 en Area 1 time servers. In dit voorbeeld beschrijft de NTP-hiërarchie de Open Shortest Path First (OSPF)-hiërarchie. OSPF is echter geen voorwaarde voor NTP. Het wordt alleen als illustratief voorbeeld gebruikt. NTP kan langs andere logische hiërarchische grenzen zoals een Enhanced Interior Gateway Routing Protocol (EIGRP)-hiërarchie of de standaard Core/Distribution/Access-hiërarchie worden geïmplementeerd.

WAN-tijddistributienetwerk

Dit voorbeeld is de Cisco IOS-configuratie voor apparaat A0-R1 zoals in het vorige diagram.

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>

Tijddistributienetwerk voor hoge stratum campus

In de vorige paragraaf werd een WAN-tijddistributienetwerk beschreven. Deze sectie beweegt één stap neer in de hiërarchie om tijddistributie op een hoog stratumcampusnetwerk te bespreken.

Het in aanmerking genomen primaire verschil voor tijddistributie op een hoog stratum campusnetwerk is het potentiële gebruik van de uitzending associatiemodus. Zoals eerder beschreven, vereenvoudigt de omroepassociatiemodus de configuraties voor de LAN’s maar vermindert deze de nauwkeurigheid van de tijdberekeningen. Daarom moet de afweging van de onderhoudskosten worden afgezet tegen de nauwkeurigheid van prestatiemetingen.

Tijddistributienetwerk voor hoge stratum campus

Het hoge netwerk van de stratumcampus, dat in het vorige diagram wordt getoond, wordt overgenomen uit het standaard het netwerkontwerp van de Campus van Cisco en bevat drie componenten. De campuskern bestaat uit twee Layer 3-apparaten met de naam CB-1 en CB-2. De servercomponent, die zich in de onderste sectie van het cijfer bevindt, heeft twee Layer 3-routers met de naam SD-1 en SD-2. De andere apparaten in het serverblok zijn Layer 2-apparaten. In de linker bovenkant is er een standaard toegangsblok met twee Layer 3-distributieapparaten met het label dl-1 en dl-2. De rest van de apparaten zijn Layer 2-switches. In dit blok voor clienttoegang wordt de tijd gedistribueerd met de uitzendoptie. In de rechterbovenhoek is er een ander standaard toegangsblok dat een client/server tijddistributieconfiguratie gebruikt.

De backbone-apparaten van de campus worden gesynchroniseerd met de tijdservers van het gebied in een client/servermodel.

Dit is de configuratie voor de dl-1 Layer 3-distributieapparaten:

!--- 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>

Tijddistributienetwerk laag op de campus

In het volgende diagram, wordt een GPS of Cesium tijdbron verstrekt bij het centrale datacentrum voor het lage stratum campusnetwerk. Deze bepaling is een stratum 1-tijdbron op het particuliere netwerk. Als er meerdere GPS- of Cesium-tijdbronnen zijn in het particuliere netwerk, dan moet de tijdverdeling in het particuliere netwerk worden gewijzigd om te profiteren van de beschikbare tijdbronnen.

In het algemeen zijn dezelfde beginselen en configuraties van toepassing als bij de voorgaande voorbeelden. Het belangrijkste verschil in dit geval is dat de wortel van de synchronisatieboom een privé tijdbron eerder dan een openbare tijdbron van Internet is. Dit verandert het ontwerp van het tijddistributienetwerk om uit de hoge nauwkeurigheid privé tijdbron voordeel te halen. De privé tijdbron wordt verdeeld door het privé netwerk met de principes van hiërarchie en modulariteit die in de vorige secties zijn beschreven.

Tijddistributienetwerk laag op de campus

Procesdefinities

Een procesdefinitie is een samenhangende reeks acties, activiteiten en wijzigingen die worden uitgevoerd door agenten die een doel willen bereiken of bereiken. Procesbeheersing is het proces van planning en regulering, met als doel een proces op een effectieve en efficiënte manier uit te voeren. Dit wordt in het volgende diagram getoond. 

Reeks processen

De output van het proces moet voldoen aan operationele normen die door een organisatie zijn vastgesteld en die zijn gebaseerd op zakelijke doelstellingen. Als het proces voldoet aan de reeks normen, wordt het proces als effectief beschouwd aangezien het kan worden herhaald, gemeten, beheerd, en bijdraagt aan de bedrijfsdoelstellingen. Indien de activiteiten met een minimale inspanning worden uitgevoerd, wordt het proces ook als efficiënt beschouwd.

Proceseigenaar

Processen bestrijken verschillende organisatiegrenzen. Daarom is het belangrijk dat er één enkele proceseigenaar is die verantwoordelijk is voor de definitie van het proces. De eigenaar is het brandpunt dat bepaalt en rapporteert of het proces effectief en efficiënt is. Als het proces niet effectief of efficiënt is, stuurt de proceseigenaar de wijziging van het proces aan. Wijziging van het proces wordt bepaald door veranderingsbeheersing en herzieningsprocessen.

Procesdoelstellingen

Er worden procesdoelstellingen vastgesteld om de richting en de reikwijdte van de procesdefinitie te bepalen. De doelstellingen worden ook gebruikt om metriek te bepalen die worden gebruikt om de doeltreffendheid van een proces te meten.

Het doel van dit proces is om criteria te verstrekken die tijdens de ontwerpfase van het NTP moeten worden gedocumenteerd, en om een controlecapaciteit voor een gebruikte NTP-architectuur te verstrekken om naleving op lange termijn van het voorgenomen ontwerp te verzekeren.

Procesprestatie-indicatoren

Procesprestatie-indicatoren worden gebruikt om de doeltreffendheid van de procesdefinitie te meten. De prestatie-indicatoren moeten meetbaar en kwantificeerbaar zijn. De hierna genoemde prestatie-indicatoren zijn bijvoorbeeld numeriek of mettertijd gemeten.

• De tijd die nodig is om het gehele proces te doorlopen.

• De uitvoeringsfrequentie die nodig is om NTP-problemen proactief te kunnen detecteren voordat ze gevolgen hebben voor de gebruikers.

• De netwerkbelasting die is gekoppeld aan de uitvoering van het proces.

• Het aantal corrigerende maatregelen dat in het proces wordt aanbevolen.

• Het aantal corrigerende maatregelen dat als gevolg van het proces is uitgevoerd.

• De tijd die nodig is om corrigerende maatregelen uit te voeren.

• De achterstand van corrigerende maatregelen.

• De fouten in probleemoplossing of probleemdiagnose worden toegeschreven aan problemen die verband houden met NTP.

• Het aantal items dat is toegevoegd, verwijderd of gewijzigd in het seed-bestand. Dit is een indicatie van nauwkeurigheid en stabiliteit.

Procesingangen

Procesinputs worden gebruikt om de criteria en voorwaarden voor een proces te definiëren. Vaak verschaft de identificatie van procesinputs informatie over externe afhankelijkheden. Vervolgens wordt een lijst van input met betrekking tot NTP-beheer verstrekt.

• NTP-ontwerpdocumentatie

• NTP MIB-gegevens verzameld door SNMP-enquête

Procesuitgangen

De procesoutput wordt als volgt gedefinieerd:

• NTP-configuratierapporten die in de sectie Gegevenspresentatie van dit document zijn gedefinieerd

• NTP-corrigerende maatregelen

Taakdefinities

In de volgende secties worden de initialiserings- en herhalingstaken gedefinieerd die aan het NTP-beheer zijn gekoppeld.

Initialisatietaken

Initialisatietaken worden eenmaal uitgevoerd tijdens de implementatie van het proces en mogen niet tijdens elke iteratie van het proces worden uitgevoerd.

Het NTP-ontwerp maken

Wanneer u de vereiste taken verifieert, als wordt vastgesteld dat een van de taken niet wordt uitgevoerd of onvoldoende informatie verstrekt om effectief aan de behoeften van deze procedure te voldoen, moet dit door de proceseigenaar worden gedocumenteerd en aan het management worden voorgelegd. De volgende tabel schetst de vereiste initialisatietaken.

Voorwaarde voor taak	Beschrijving
Taakdoelstellingen	Maak een gedetailleerd ontwerpdocument voor de NTP-architectuur dat voldoet aan de ontwerpvereisten en kostendoelstellingen.
Invoersnelheid van taak	Technische en economische ontwerpvereisten Huidige documentatie van netwerkontwerp Criteria voor de definitie van de aspecten die in het ontwerp moeten worden opgenomen om de beheerfuncties mogelijk te maken Informatie over implementatie van IT-toepassingen Eisen inzake prestatiebewaking
Taakuitvoer	NTP-ontwerpdocumentatie.
Taakresources	Netwerkengineer architect Netwerk werkzaamheden architect.
Taakrollen	Netwerkontwerp technische goedkeuring door Engineering en Operations reviewers Netwerkontwerpkosten goedgekeurd door verantwoordelijke budget manager.

Een zaadbestand maken

Het NTP-beheerproces vereist het gebruik van een zaadbestand om de noodzaak van een netwerkdetectiefunctie te verwijderen. Het zaadbestand registreert de set routers die worden beheerd door het NTP-proces en wordt ook gebruikt als een focal point om te coördineren met de processen voor wijzigingsbeheer in een organisatie. Bijvoorbeeld, als nieuwe knooppunten in het netwerk zijn ingevoerd, moeten zij aan het NTP-zaadbestand worden toegevoegd. Als de SNMP-communitynamen moeten worden gewijzigd vanwege beveiligingsvereisten, moeten die wijzigingen worden weergegeven in het zaadbestand. De volgende tabel geeft aan hoe u een zaadbestand kunt maken.

Voorwaarde voor taak	Beschrijving
Taakdoelstellingen	Maak een zaadbestand dat drie categorieën netwerkapparaten identificeert: Kritieke apparaat—Gerold op een frequente basis voor configuratie-informatie Interessante apparaten—minder vaak gepolled Alle NTP-enabled apparaten—Gepolled het kleinste aantal
Invoersnelheid van taak	NTP-ontwerpdocumentatie: documentatie over netwerktopologie.
Taakuitvoer	Seed-bestand.
Taakresources	Ontwerpcriteria die kunnen worden gebruikt om de knooppunten die bij de NTP-architectuur betrokken zijn, te identificeren en er prioriteiten aan toe te kennen.

Baseline NTP-prestatieparameters

Verscheidene van de parameters beschikbaar voor de controle van het netwerk NTP vertoonden sommige normale verwachte variaties. Het proces van baselining wordt gebruikt om de normale verwachte afwijkingen te karakteriseren en om drempels vast te stellen die onverwachte of abnormale omstandigheden bepalen. Deze taak wordt gebruikt om de variabele reeks parameters voor de NTP-architectuur te baseren.

Proces	Beschrijving
Taakdoelstellingen	Variabele parameters voor de basislijn.
Invoersnelheid van taak	Identificeer variabele parameters cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion.
Taakuitgangen	Uitgangswaarden en drempelwaarden.
Taakresources	Tools die SNMP-gegevens verzamelen en basislijnen berekenen.
Takenrol	Network Engineer NMS Engineer.

Iteratieve taken

Bij elke iteratie van het proces worden iteratieve taken uitgevoerd en de frequentie ervan wordt bepaald en gewijzigd om de prestatie-indicatoren te verbeteren.

Het zaadbestand onderhouden

Het startbestand is van cruciaal belang voor de doeltreffende uitvoering van het NTP-beheerproces. Daarom moet de huidige status van het startbestand actief worden beheerd. Veranderingen in het netwerk die de inhoud van het zaadbestand beïnvloeden, moeten door de eigenaar van het NTP-beheerproces worden gevolgd.

Proces	Beschrijving
Taakdoelstellingen	Nauwkeurigheid van het zaadbestand behouden
Invoersnelheid van taak	Informatie over netwerkwijzigingen
Taakuitgangen	startbestand
Taakresources	Rapporten, kennisgevingen, vergaderingen die betrekking hebben op wijzigingen
Takenrol	Network Engineer NMS Engineer

Voer de NTP-knoopsscan uit

Verzamel informatie over kritieke, interessante, en configuratiescannen die door deze procedure worden bepaald. Voer deze drie scans uit op verschillende frequenties.

Kritieke knooppunten zijn apparaten die als zeer belangrijk worden beschouwd voor de datapunten van de prestatieverzameling. De kritieke nodescan wordt vaak uitgevoerd, bijvoorbeeld per uur, of op vraagbasis voor en na wijzigingen. Interessante knooppunten zijn apparaten die belangrijk worden geacht voor de algehele integriteit van de NTP-architectuur, maar niet in de tijdsynchronisatiestructuur voor het verzamelen van kritieke prestatiegegevens kunnen worden opgenomen. Dit rapport wordt periodiek uitgevoerd, bijvoorbeeld dagelijks of maandelijks. Het configuratierapport is een uitgebreid en intensief resourcerapport dat wordt gebruikt om de totale NTP-implementatieconfiguratie te karakteriseren aan de hand van ontwerprecords. Dit rapport wordt minder frequent uitgevoerd, bijvoorbeeld op maand - of kwartaalbasis. Een belangrijk punt om rekening mee te houden is dat de frequentie waarmee de rapporten worden verzameld kan worden aangepast op basis van de waargenomen stabiliteit van de NTP-architectuur en de zakelijke behoeften.

Proces	Beschrijving
Taakdoelstelling	Monitor NTP-architectuur
Taakinvoer	Apparaatgegevens netwerk
Taakuitvoer	Rapporten
Taakresources	Softwaretoepassingen voor het verzamelen van gegevens en het opstellen van rapporten
Takenrol	Netwerkengineer

Herzie de Rapporten van het NTP-knooppunt

Deze taak vereist dat de kritische, interessante en configuratieverslagen worden bekeken en geanalyseerd. Als er problemen worden gedetecteerd, moeten er corrigerende maatregelen worden genomen.

Proces	Beschrijving
Invoersnelheid van taak	Scanrapporten
Taakuitgangen	Stabiliteitsanalyse Correctieve maatregelen
Taakresources	Toegang tot netwerkapparaten voor verder onderzoek en verificatie
Takenrol	Netwerkengineer

Identificatie van gegevens

Algemene gegevenskenmerken

De volgende tabel beschrijft gegevens die als significant worden beschouwd wanneer u de NTP-architectuur analyseert.

Gegevens	Beschrijving
Knooppunten-id	Een apparaat dat NTP heeft geconfigureerd
Gelijken	De geconfigureerde peers voor het apparaat
synchronisatiebron	De geselecteerde peer voor synchronisatie
NTP-configuratiegegevens	Parameters die worden gebruikt om de consistentie van het NTP-ontwerp te beoordelen
NTP-kwaliteitsgegevens	Parameters die worden gebruikt om de kwaliteit van de NTP-associaties te karakteriseren

SNMP-gegevensidentificatie

Cisco NTP MIB-systeemgroep

De NTP SNMP-gegevens worden gedefinieerd door Cisco-NTP-MIB. Voor huidige informatie over de releases die deze MIB ondersteunen, gebruikt u het CCO Feature Navigator-gereedschap en selecteert u de optie MIB Locator. Deze tool is toegankelijk via de pagina TAC Tools for Voice, Telephony and Messaging Technologies.

De systeemgroep in Cisco NTP MIB biedt informatie voor de doelknooppunt waarop NTP wordt uitgevoerd. Het doelknooppunt is de bestemming van de SNMP-vragen.

Objectnaam	Objectbeschrijving
cntpSysStratum	Het stratum van de lokale klok. Als de waarde is ingesteld op 1, een primaire referentie, dan wordt de procedure voor primaire kloktijd beschreven in paragraaf 3.4.6, in RFC-1305 wordt ingeroepen. ::= { cntpSystem 2} object identifier = .1.3.6.1.4.1.9.9.168.1.1.2
cNTPsysPrecision	Ondertekend geheel dat de precisie van de systeemklok, in seconden, aan de dichtstbijzijnde macht van twee aangeeft. De waarde moet worden afgerond op de volgende grotere kracht van twee. Bijvoorbeeld, een 50-Hz (20 ms) of 60-Hz (16.67 ms) macht-frequentie klok wordt toegewezen de waarde -5 (31.25 ms), terwijl een 1000-Hz (1 ms) kristal-gecontroleerde klok wordt toegewezen de waarde -9 (1.95 ms). ::= { cntpSystem 3} object identifier = .1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay	Een ondertekend vast-puntaantal dat op de totale round-trip vertraging in seconden, aan de primaire referentiebron bij de wortel van synchronisatiesubnet wijst. ::= { cntpSystem 4} object identifier = .1.3.6.1.4.1.9.9.168.1.1.4
CNTPsRootDispersie	De maximumfout in seconden, met betrekking tot de primaire referentiebron bij de wortel van synchronisatiesubnet. Er zijn alleen positieve waarden groter dan nul mogelijk. ::= { cntpSystem 5} object identifier = .1.3.6.1.4.1.9.9.168.1.1.4
cNTPsysrefTijd	De lokale tijd waarop de lokale klok voor het laatst is bijgewerkt. Als de lokale kloktijd nooit is gesynchroniseerd, is de waarde nul. ::= { cntpSystem 7} object identifier = .1.3.6.1.4.1.9.9.168.1.1.7
CNTPsyspeer	De huidige synchronisatiebron die de unieke associatie-identificatiecode cntpPeersAssocId bevat van de corresponderende peer-ingang in de cntpPeersVarTable van de peer die als synchronisatiebron fungeert. Als er geen peer is, is de waarde nul. ::= { cntpSystem 9} object identifier = .1.3.6.1.4.1.9.9.168.1.1.9
CNTPsysClock	De huidige lokale tijd. De lokale tijd wordt afgeleid van de hardwareklok van de betreffende machine en stappen met tussenpozen gebaseerd op het gebruikte ontwerp. :: = { cntpSystem 10} object identifier = .1.3.6.1.4.1.9.9.168.1.1.10

Cisco NTP MIB-peer groep - peers variabele tabel

De peer groep van Cisco NTP MIB biedt informatie over de peers van het doelknooppunt.

Objectnaam	Objectbeschrijving
cntppeersVarTable	Deze tabel geeft informatie over de peers waarmee de lokale NTP-server associaties heeft. De peers zijn ook NTP-servers die op verschillende hosts draaien. Dit is een tabel van cntpPeersVarEntry::= { cntpPeers 1} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1
CCNTPpeersVarEntry	Elke peers' entry biedt NTP informatie opgehaald uit een bepaalde peer NTP server. Elke peer wordt geïdentificeerd door een unieke associatie-identificatie. Inzendingen worden automatisch gemaakt wanneer de gebruiker de NTP-server configureert die moet worden gekoppeld aan externe peers. Op dezelfde manier worden items verwijderd wanneer de gebruiker de peer associatie verwijdert van de NTP server. De ingangen kunnen ook door het beheerstation worden gecreëerd door waarden voor cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode in te stellen en de cntpPeersEntryStatus als actief in te stellen (1). Op zijn minst moet het beheerstation een waarde voor cntpPeersPeerAddress instellen om de rij actief te maken. INDEX { cntpPeersAssocId} ::= { cntpPeersVarTable 1} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1
CCNTP-peersASSOCid	Een geheel getal groter dan nul dat op unieke wijze een peer identificeert waarmee de lokale NTP server is geassocieerd. :: = { cntpPeersVarEntry 1} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.1
CNTP-peers geconfigureerd	Dit is een beetje dat erop wijst dat de vereniging van configuratieinformatie werd gecreëerd en niet moet worden losgemaakt zelfs als de peer onbereikbaar wordt. :: = { cntpPeersVarEntry 2} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.2
CNTP-peersPeerAddress	Het IP-adres van de peer. Wanneer een nieuwe associatie wordt gemaakt, moet een waarde voor dit object worden ingesteld voordat de rij actief wordt gemaakt. ::= { cntpPeersVarEntry 3} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersMode	SYNTAX INTEGER { unespecified (0), symmetricActive (1), symmetricPassive (2), client (3), server (4), broadcast (5), reservecontrole (6), gereserveerdPrivate (7) } Wanneer een nieuwe peer associatie is gecreëerd, als er geen waarde is gespecificeerd voor dit object, staat deze standaard voor symmetricActive (1). ::= { cntpPeersVarEntry 8} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntppeersStratum	Het stratum van de peer klok. ::= { cntpPeersVarEntry 9} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.9
cntppeersRootDelay	Een ondertekend vast-puntaantal dat op de totale round-trip vertraging in seconden, van de peer aan de primaire referentiebron bij de wortel van synchronisatiesubnet wijst. :: = { cntpPeersVarEntry 13} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.13
CNTPpeersRootDispersie	De maximumfout, in seconden, van de peer kloktijd met betrekking tot de primaire referentiebron bij de wortel van synchronisatiesubnet. Er zijn alleen positieve waarden groter dan nul mogelijk. :: = { cntpPeersVarEntry 14} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.14
CCNTP-peersRefTime	De lokale tijd bij de peer toen zijn klok het laatst werd bijgewerkt. Als de peer kloktijd nooit gesynchroniseerd is, is de waarde nul. ::= { cntpPeersVarEntry 16} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.16
CCNTP-peersReach	Een verschuivingsregister dat wordt gebruikt om de bereikbaarheidsstatus van de peer te bepalen, met bits die vanuit het minst significante (meest rechtse) einde binnenkomen. Een peer wordt als bereikbaar beschouwd als ten minste één bit in dit register op een is ingesteld (object is niet-nul). De gegevens in het verschuivingsregister worden ingevuld door de NTP-protocolprocedures. :: = { cntpPeersVarEntry 21} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntppeersOffset	De geschatte offset van de peer-klok ten opzichte van de lokale klok, in seconden. De host bepaalt de waarde van dit object dat het NTP klokfilter algoritme gebruikt. :: = { cntpPeersVarEntry 23} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
CCNTP-peersVertraging	De geschatte round-trip vertraging van de peer kloktijd ten opzichte van de lokale kloktijd over het netwerkpad tussen hen, in seconden. De host bepaalt de waarde van dit object dat het NTP klokfilter algoritme gebruikt. :: = { cntpPeersVarEntry 24} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.24
CNTP-peers, dispersie	De geschatte maximumfout van de peer-kloktijd ten opzichte van de lokale kloktijd via het netwerkpad tussen beide, in seconden. De host bepaalt de waarde van dit object dat het NTP klokfilter algoritme gebruikt. :: = { cntpPeersVarEntry 25} object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.25

Gegevensverzameling

SNMP-gegevensverzameling

Alle informatie die bij deze procedure wordt vereist, kan via SNMP-vragen worden verzameld. Om de gegevens te kunnen parseren en de rapporten te kunnen produceren, moeten aangepaste scripts of softwareprogramma's worden ontwikkeld.

Presentatie van gegevens

NTP-rapport over kritisch knooppunt

Kritieke knooppunten zijn apparaten die belangrijk zijn in de synchronisatiestructuur van geselecteerde prestatiegegevensverzamelpunten. Als er een VoIP-service met hoge opbrengsten wordt bewaakt en eenrichtingsvertragings-variatiemaatstaven worden verzameld, worden de bron- en doelknooppunten waar de tijdstempels worden geregistreerd, als kritieke knooppunten beschouwd.

In dit voorbeeld, is het ontwerp NTP gevestigd volgende een voorbeeldhiërarchie OSPF. Daarom worden de hierna beschreven rapporten opgemaakt om de NTP-apparaten te groeperen op basis van het OSPF-gebied van het apparaat. In gevallen waarin een knooppunt interfaces op meerdere gebieden heeft, moet door de software voor het genereren van rapporten een beslissing worden genomen over het gebied dat het knooppunt voor rapportagedoeleinden kan worden vermeld. Zoals eerder vermeld, is OSPF geen voorwaarde voor NTP. Het wordt in dit document alleen ter illustratie gebruikt.

Gebied	Apparaat	Apparaatgegevens	Waarde
#n gebied-id	#1 apparaat-id	cntpSysStratum
		cNTPsysPrecision
		cntpSysRootDelay
		CNTPsRootDispersie
		cNTPsysrefTijd
		CNTPsyspeer
		CNTPsysClock
	#n apparaat-id	cntpSysStratum
		cNTPsysPrecision
		cntpSysRootDelay
		CNTPsRootDispersie
		cNTPsysrefTijd
		CNTPsyspeer
		CNTPsysClock

NTP-rapport over interessant knooppunt

De opmaak van het interessante knooppunt-rapport is hetzelfde als de opmaak voor het kritische knooppunt-rapport. Interessante knooppunten zijn knooppunten die belangrijk worden geacht voor de algehele NTP-architectuur, maar niet rechtstreeks kunnen bijdragen aan de tijdsynchronisatie van kritische prestatiebewakingspunten.

NTP-configuratierapport

Het configuratierapport is een uitgebreid rapport dat informatie over de algehele NTP-architectuur verzamelt. Dit rapport wordt gebruikt om de NTP-implementatie te registreren en te verifiëren aan de hand van ontwerpgegevens.

Gebied	Apparaat	Peer	Peer data	Waarde
#n gebied-id	#n apparaat-id	#1 van peer-id	CCNTP-peersASSOCid
			CNTP-peers geconfigureerd
			CNTP-peersPeerAddress
			cntpPeersMode
			cntppeersStratum
			cntppeersRootDelay
			CNTPpeersRootDispersie
			CCNTP-peersRefTime
			CCNTP-peersReach
			cntppeersOffset
			CCNTP-peersVertraging
			CNTP-peers, dispersie
		#n van peer-id	CCNTP-peersASSOCid
			CNTP-peers geconfigureerd
			CNTP-peersPeerAddress
			cntpPeersMode
			cntppeersStratum
			cntppeersRootDelay
			CNTPpeersRootDispersie
			CCNTP-peersRefTime
			CCNTP-peersReach
			cntppeersOffset
			CCNTP-peersVertraging
			CNTP-peers, dispersie

Gerelateerde informatie

• RFC 1305-netwerktijdprotocol
• RFC 2330: Framework voor IP-prestatiestatistieken
• Essentiële Cisco IOS-functies Elke ISP moet v2.84 overwegen
• Cisco Technical Support en downloads