Inhoud

Inleiding

Achtergrondinformatie

NTP-stemmechanisme in UC-producten

Gebruikte NTP-versie identificeren

NTP-gerelateerde problemen in CUCM analyseren

Gemeenschappelijke bekende problemen met de NTP-associatie op CUCM

Inleiding

Dit document beschrijft hoe u problemen met Network Time Protocol (NTP) kunt oplossen bij Cisco Unified Communications Manager (CUCM) en Cisco Unified Communications Manager (UC)-producten.

Achtergrondinformatie

CUCM vereist dat NTP zodanig wordt geconfigureerd dat het:

- De tijd op de CUCM-knooppunten is gesynchroniseerd.

- De tijd is correct voorafgaand aan enige tijd gevoelige configuratieverandering zoals certificaat regeneratie.

- De replicatie van de databank wordt gesynchroniseerd op alle knooppunten in de cluster.

NTP-stemmechanisme in UC-producten

CUCM gebruikt de NTP-waakhond om de tijd gesynchroniseerd met de NTP-server te houden. De NTP Watchdog instelt periodiek de geconfigureerde externe NTP-server(s) en start NTP opnieuw op als de tijd met meer dan drie seconden is gecompenseerd.

De NTP-daemon corrigeert regelmatig tijd, maar op een milliseconde tijdschaal. Een herstart van NTP houdt in dat u een NTP-één-shot runt om een brutotijdcorrectie uit te voeren en volgt met een herstart van de NTP-daemon voor voortgezette reguliere micro-correcties.

NTP Watchdog informeert NTP één keer per minuut over VMware en één keer per 30 minuten over fysieke machines. Het steminterval is korter voor VMware omdat de kloktijd in virtuele machines (VMs) minder stabiel is dan op fysieke machines en VMware-functies zoals VMotion, opslagmigratie een negatieve invloed heeft op de tijd.

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 werken, om te compenseren voor de hogere mate van tijdverlies of vertraging in een VM. Secundaire knooppunten worden altijd automatisch ingesteld om de primaire knooppunt-NTP-server te verwijzen om er zeker van te zijn dat alle knooppunten binnen de cluster binnen de tijd dicht zijn.

NTP Watchdog houdt bij in welk tempo het de NTP-datum opnieuw start voor brutotijdcorrecties door VMWare VMotions en Storage Migraties. Als dit percentage hoger is dan 10 restart per uur, stelt NTP Watchdog verdere restart uit totdat het vereiste aantal restart minder dan 10 per uur bedraagt. Het gecombineerde tarief voor VMotions en Storage Migraties mag niet hoger zijn dan 10 per uur, omdat dit percentage als buitensporig wordt beschouwd.

Vanwege deze NTP Watchdog implementatie, volg u het poll interval niet, dat is gezien in utils ntp status. Een snuffelbedekking heeft elke 60 seconden 8 NTP-peilingen (een steekproef) onthuld. Dit komt vooral doordat de NTP-implementatie NTP Watchdog gebruikt en hoe NTP de NTP-server in UC Implementatie opiniepeilt.

Gebruikte NTP-versie identificeren

Opmerking: CUCM Publisher wordt geconfigureerd met een externe NTP-server en de abonnee wordt toegevoegd aan de cluster door middel van synchronisaties aan de uitgever.

Opmerking: CUCM versie 9.x en vereist later dat de NTPv4-server wordt geconfigureerd als de geprefereerde NTP-server.

Draai een snuffer-opname 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 stuurt een NTPv4-pakket en in antwoord daarop ontvangt u een NTPv3-pakket. Hoewel NTPv4 achterwaarts compatibel is met NTPv3, varieert de CUCM-implementatie 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 de kwestie te repareren, raadt Cisco u aan een Linux-gebaseerde externe NTP-server of Cisco IOS® of IOS XE-gebaseerde NTP-server te gebruiken en ervoor te zorgen dat NTPv4 is geconfigureerd.

Hier is een beschrijving van de NTP-terminologie in de NTP-statusuitvoer:

- De kolom geeft de tijdbron van de afstandsbediening aan. LOKAAL(0) is de lokale hardwareklok. INIT. betekent dat de initialisering nog niet is geslaagd.

- De meest gebruikte kolom is het stratum van de externe NTP-server. 16 is een ongeldige stratumwaarde die betekent dat "deze server niet als tijdprovider wordt beschouwd". Het stratum kan om verschillende redenen ongeldig zijn, waarvan de meest voorkomende is dat de "time provider not synchronized", de "geconfigureerde bron bestaat niet" of de "ntp server not run".

- De kolom geeft het servertype aan (l: plaatselijk; u: eenling; m: multicast, of b: uitzending).

- Het moment dat de kolom aangeeft hoeveel seconden geleden de afstandsbediening is aangevraagd.

- De opiniekolom geeft het steminterval in seconden aan. "64" betekent bijvoorbeeld dat de afstandsbediening elke 64 seconden wordt gepolst. Het kortste interval dat NTP gebruikt is elke 64 seconden en de langste is 1.024 seconden. Hoe beter een NTP bron wordt bepaald in de loop der tijd, hoe langer het interval. (UC Implementatie volgt niet het hier gedefinieerde interval.)

- De reach-kolom geeft de trend van bereikbaarheidstesten in octal aan, waarbij elk cijfer, bij conversie naar binair getal, representeert of een bepaalde poll succesvol was (binair 1) of onsuccesvol (binair 0). "1" betekent bijvoorbeeld dat er tot nu toe slechts één enquête is gehouden en dat die succesvol was. "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 getal 1 111) betekent dat de laatste vier peilingen succesvol waren. "15" (= binair getal 1 101) betekent dat de laatste twee peilingen succesvol waren, dat de opiniepeiling daarvoor niet succesvol was en dat de opiniepeiling daarvoor succesvol was.

- De vertragings, offset, en jitter kolommen zijn de retourvertraging, dispersie en jitter in milliseconden.

NTP-gerelateerde problemen in CUCM analyseren

Voltooi deze stappen om NTP-gerelateerde problemen te diagnosticeren:

1. Zorg ervoor dat CUCM met de NTP-server op Port 123 kan communiceren.

2. Verkrijg de output van utils ntp status.

- Stratumniveau moet minder dan 4 bedragen voor uitgeverij voor optimale prestaties

- Als meerdere NTP-servers zijn geconfigureerd, zorg er dan voor dat ten minste op de server bereikbaar is; U dient het (*) symbool tegen de NTP-server te zien, gebruikt als referentie door CUCM.

3. Controleer het syslogalarm en onderneem dienovereenkomstig maatregelen. Mogelijk zijn de oorzaken van syslipalarmen:

- Externe NTP-server is niet bereikbaar.

- NTP-stratum is hoger dan de aanvaardbare limiet.

- Uitgeverij is uitgeschakeld, zodat Subscriber NTP niet-gesynchroniseerd is.

- Als er melden-q gerelateerd zijn gezien, is het mogelijk dat u NTP versie 4.2.6+ hebt ingeschakeld met de Kus of Death (KoD) optie. (Door ontwerp, is het minimum interval tussen burst en iburst pakketten die door om het even welke cliënt worden verzonden twee, die deze beperking niet overtreden. Packets die door andere implementaties worden verzonden die deze beperking overtreden, zullen worden ingetrokken en een KoD-pakket (indien ingeschakeld) wordt teruggegeven. Aanbevolen wordt deze optie uit te schakelen wanneer u die versie als NTP-server voor een UC-product gebruikt.

4. Gebruik deze diagnostische module om te controleren of de NTP-server is geconfigureerd.

- utisten diagnosticeren module ntp_bereikbaarheid

- utisten diagnosticeren module ntp_clock_drift

- utils diagnosticeert module ntp_stratum

5. Voer utils ntp-start in om de NTP-client/server opnieuw te starten. Deze opdracht is handig wanneer er direct een correctie voor de brutotijd nodig is of wanneer externe servers nog bereikbaar en gebruiksklaar zijn, maar de synchronisatie-opties mislukt. Gebruik de opdracht utils ntp status om de operationele status van externe NTP-servers te bepalen.

Gemeenschappelijke bekende problemen met de NTP-associatie op CUCM

Cisco bug-ID CSCue18813: NTP-configuratie "tos maxdist"-parameter, gecontroleerd via CLI

Resolutie: De case van Cisco Technical Assistance Center moet worden verhoogd om de tos maxdist-parameter handmatig toe te voegen aan het ntp.conf-bestand.

Cisco bug-ID CSCuq70611: NTP Stratum-test valideert niet goed met één NTP-server

Vaste versie: 10.5(2.1000.005)

Cisco bug-ID CSCui85967: De CUCM-upgrade van 6.1.5 naar 9.1.2 is niet voltooid omdat NTP-referentie ontbreekt

Resolutie: De documentatie van de upgrade van de pomp is bijgewerkt en de configuratie van NTP is vermeld als één van de pre-upgrade taak.

Cisco bug-ID CSCtw4611:  NTP-synch faalt als gevolg van een onjuist label van het bestandssysteem met betrekking tot Capture.txt

Vaste versie: 8,6

Cisco bug-ID CSCur94973: tijdsync-probleem tussen VMHost en VM Instance tijdens M1-migratie

Resolutie: de NTP-sync van de VM met de ESXi-host uitschakelen met het gebruik van deze tijdelijke oplossing . Een alternatieve workround is het configureren van de ESXi server en CUCM Publisher om naar dezelfde NTP server te wijzen.