Inleiding
Dit document beschrijft hoe u problemen met Network Time Protocol (NTP) op Cisco Unified Communications (UC)-producten kunt oplossen.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
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
Cisco Unified Communications Manager (CUCM) vereist dat NTP wordt geconfigureerd om te garanderen:
- De tijd op de CUCM-knooppunten is gesynchroniseerd.
- De tijd is correct voorafgaand aan om het even welke tijd-gevoelige configuratieverandering zoals certificaatregeneratie.
- Databasereplicatie is gesynchroniseerd op alle knooppunten in het cluster.
NTP-pollingmechanisme in UC-producten
CUCM gebruikt de NTP-waakhond om de tijd gesynchroniseerd te houden met de NTP-server. De NTP Watchdog stelt periodiek een externe NTP-server(s) in en start NTP opnieuw op als de tijd met meer dan drie seconden wordt gecompenseerd.
De NTP-daemon corrigeert de tijd regelmatig, maar op een tijdschaal van een milliseconde. Een herstart van NTP houdt in dat u een NTP one-shot uitvoert om een bruto tijdcorrectie uit te voeren en te volgen met een herstart van de NTP daemon voor voortgezette regelmatige microcorrecties.
NTP Watchdog polls NTP één keer per minuut over VMware en elke 30 minuten over fysieke machines. Het pollinginterval is korter voor VMware omdat de klok in virtuele machines (VM's) minder stabiel is dan op fysieke machines, en VMware-functies zoals VMotion en Storage Migration de tijd negatief beïnvloeden.
Een primair knooppunt dat op VMware draait, moet altijd worden geconfigureerd om te synchroniseren met externe NTP-servers die op een of meer fysieke machines draaien, ter compensatie van de hogere mate van tijdverschuiving of vertraging in een VM. Secundaire knooppunten worden altijd automatisch geconfigureerd om de NTP-server van de primaire knooppunt als referentie te gebruiken om ervoor te zorgen dat alle knooppunten binnen het cluster op tijd dicht bij elkaar liggen.
NTP Watchdog houdt bij met welke snelheid de NTP-daemon wordt herstart voor brutotijdcorrecties als gevolg van VMWare-VMotions en opslagmigraties. Als deze snelheid hoger is dan 10 herhalingen per uur, stelt NTP Watchdog verdere herhalingen uit totdat de vereiste snelheid van herstart onder de 10 per uur daalt. De gecombineerde snelheid van VMotions en Storage Migrations mag niet hoger zijn dan 10 per uur, omdat dit aantal als buitensporig wordt beschouwd.
Vanwege deze NTP Watchdog implementatie, volgt u niet de poll interval, die wordt gezien in utils ntp status. Een snifferopname heeft 8 NTP-polls (sample) elke 60 seconden onthuld. Dit komt vooral doordat de NTP-implementatie NTP Watchdog gebruikt, en hoe ntpdate de NTP-server in UC-implementatie polls.
Identificeer gebruikte NTP-versie
Opmerking: CUCM Publisher is geconfigureerd met een externe NTP-server, en de abonnee die aan het cluster wordt toegevoegd, synchroniseert met de Publisher.
Opmerking: CUCM versie 9.x en hoger vereist dat de NTPv4 server is geconfigureerd als de voorkeursserver voor NTP.
Voer een snuffelopname uit om de NTP-versie te identificeren die door de geconfigureerde NTP-server wordt gebruikt:
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48
16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48
CUCM verstuurt een NTPv4-pakket en als reactie ontvangt u een NTPv3-pakket. Hoewel NTPv4 achterwaarts compatibel met NTPv3 is, varieert de implementatie van CUCM van NTP, wat resulteert in niet-gesynchroniseerde NTP:
admin:utils ntp status
ntpd (pid 22458) is running...
remote refid st t when poll reach delay offset jitter
=================================================================
172.28.5.9 .INIT. 2 u 45 64 377 0.374 492.965 18.189
unsynchronised
time server re-starting
polling server every 64 s
Om het probleem op te lossen, raadt Cisco u aan een op Linux gebaseerde externe NTP-server of Cisco IOS® of Cisco IOS® XE NTP-server te gebruiken en ervoor te zorgen dat NTPv4 is geconfigureerd.
Hier volgt een beschrijving van de NTP-terminologie in de NTP-statusuitvoer:
- De refid kolom geeft de tijdbron van de afstandsbediening aan. LOCAL(0) is de lokale hardwareklok. .INIT. betekent dat de initialisering nog niet is geslaagd.
- De eerste kolom is het stratum van de externe NTP server. 16 is een ongeldige stratum waarde dat betekent, deze server wordt niet beschouwd als een time provider. Het stratum kan om verschillende redenen ongeldig zijn. De meest voorkomende is dat de tijdprovider niet gesynchroniseerd, de geconfigureerde bron niet bestaat, of dat de ntp server niet actief is.
- De t kolom geeft het servertype aan (l: lokaal; u: unicast; m: multicast, of b: broadcast).
- De wanneer kolom geeft aan hoeveel seconden geleden de afstandsbediening werd gevraagd.
- De opiniekolom geeft het opiniepeilingsinterval in seconden aan. Bijvoorbeeld: 64 betekent dat de afstandsbediening elke 64 seconden wordt gepolled. Het kortste interval NTP gebruik is elke 64 seconden en het langste is 1.024 seconden. Hoe beter een NTP-bron in de loop van de tijd wordt beoordeeld, hoe langer het interval. (UCS-implementatie volgt niet het hier gedefinieerde interval.)
- De bereikkolom geeft de trend van bereikbaarheidstests in octal aan, waarbij elk cijfer, wanneer omgezet in binair getal, aangeeft of een bepaalde poll succesvol was (binair getal 1) of niet succesvol (binair getal 0). 1 betekent bijvoorbeeld dat er tot nu toe maar één enquête is gehouden, en dat die met succes is afgerond. 3 (= binair getal 11) betekent dat de laatste twee peilingen succesvol waren. 7 (= binair getal 111) betekent dat de laatste drie peilingen succesvol waren. 17 ( = binair 1 111) betekent dat de laatste vier peilingen succesvol waren. 15 (= binair getal 1 101) betekent dat de laatste twee peilingen succesvol waren. De peiling daarvoor was geen succes, en de peiling daarvoor was wel succesvol.
- De vertraging, offset en jitter kolommen zijn de ronde-trip vertraging, dispersie en jitter in milliseconden.
Diagnose van NTP-gerelateerde problemen in CUCM
Voltooi deze stappen om NTP-gerelateerde problemen te diagnosticeren:
- Zorg ervoor dat CUCM op poort 123 kan communiceren met de NTP-server.
- Verkrijg de output van utils ntp status.
- Voor optimale prestaties kan het stratumniveau lager zijn dan 4 op de uitgever.
- Als meerdere NTP-servers zijn geconfigureerd, zorg er dan voor dat ten minste één server bereikbaar is; u kunt het (*) symbool zien tegen de NTP-server die als referentie wordt gebruikt door CUCM.
- Herzie het syslogalarm en neem dienovereenkomstig actie. Mogelijke oorzaken van syslog alarmen zijn:
- De externe NTP-server is niet bereikbaar.
- NTP-stratum is hoger dan de aanvaardbare limiet.
- De uitgever is neer, zodat is de Subscriber NTP niet gesynchroniseerd.
- Als ntpdate -q gerelateerde waarschuwingen worden gezien, is het mogelijk dat u NTP versie 4.2.6+ met de Kus van de Dood (KoD) functie ingeschakeld. (Door ontwerp, is het minimuminterval tussen burst en burst pakketten die door om het even welke cliënt worden verzonden twee, die deze beperking niet overtreden. Pakketten die door andere implementaties worden verzonden die deze beperking overtreden kunnen worden gelaten vallen en een KoD pakket (teruggekeerd indien toegelaten). Het wordt aanbevolen om deze functie uit te schakelen wanneer u die versie gebruikt als de NTP-server voor een UC-product.
- Gebruik deze diagnosemodule om te controleren of de NTP-server is geconfigureerd.
- hulpprogramma's diagnosemodule ntp_reach
- hulpprogramma's diagnosticeren module ntp_Clock_drift
- hulpprogramma's diagnosticeren module ntp_stratum
- Voer hulpprogramma’s in om de NTP-client/server opnieuw te starten. Deze opdracht is handig wanneer een bruto-tijdcorrectie onmiddellijk moet plaatsvinden of wanneer externe servers nog bereikbaar en operationeel zijn, maar synchronisatie mislukt. Gebruik de utils ntp status commando om de operationele status van externe NTP servers te bepalen.
Vaak bekende problemen met NTP-associatie op CUCM
Cisco bug-id CSCue18813: NTP-configuratietools maxdistenparameter gecontroleerd via CLI
Resolutie: De case van Cisco Technical Assistance Center kan worden verhoogd om de max. maxdistparameter handmatig toe te voegen in het ntp.conf-bestand.
Cisco bug-id CSCuq70611: NTP-stratumtest valideert niet correct met één NTP-server
Vaste versie: 10.5(2.10000.005)
Cisco bug-id CSCui85967: CUCM-sprongupgrade van 6.1.5 naar 9.1.2 mislukt vanwege ontbrekende NTP-referentie
Resolutie: de documentatie van de Jump-upgrade is bijgewerkt en de NTP-configuratie wordt vermeld als een van de taken die vóór de upgrade zijn uitgevoerd.
Cisco bug-id CSCtw46611: NTP-synch mislukt vanwege onjuiste etikettering van bestandssysteem van capture.txt
Vaste versie: 8.6(2.24900.017)
Cisco bug-id CSCur94973: time sync-probleem tussen VMHost en VM Instance tijdens M1-migratie
Resolutie: Schakel de NTP-synchronisatie van de VM met de ESXi-host uit met behulp van deze tijdelijke oplossing. Een alternatieve tijdelijke oplossing is om de ESXi-server en CUCM Publisher te configureren om naar dezelfde NTP-server te wijzen.
Feedback