Asbjorn Hojmark's Infrastructure Blog

En af mine kunder spurgte i dag, hvad man egentlig skal gøre ved udstyr, der er omfattet af fx:

• CSCub38654: Switchen kan crashe / hænge, så man ikke længere kan komme i kontakt med den fra VTY (remote) eller konsol. Eneste måde at få liv i switchen igen er at slukke den og tænde den igen. Løst i NX-OS 5.2(1)N1(9) og alle versioner i NX-OS 6 og 7.

Hvis man ikke har lukket for NTP, er det for sent at slå det fra nu, for skudsekundet er allerede signalleret i NTP. På nogle platforme kan man helt stoppe processen (og starte den igen efter skudsekundet), men det er langtfra alle.

Jeg har kigget lidt på problemet med skudsekunder i dag, og for Nexus 5000 gælder:

• CSCub38654: Switchen kan crashe / hænge, så man ikke længere kan komme i kontakt med den fra VTY (remote) eller konsol. Eneste måde at få liv i switchen igen er at slukke den og tænde den igen. Løst i NX-OS 5.2(1)N1(9) og alle versioner i NX-OS 6 og 7. NX-OS 5 er som bekendt sidste release til Nexus 5000 (5010, 5020).
• CSCut81357: Et grimt problem, hvis man kører PTP, da det kan propagere en tid, der er meget langt ude af justering (og dem, der kører PTP gør det jo netop for at få en meget præcis time-stamping). Problemet er løst i 5.2(1)N1(9) og 6.0(2)N2(7). Men hvem kører PTP? Har vi nogen kunder, der gør det?

Min anbefaling: Opgradér til 5.2(1)N1(9). Alternativt kan man slå NTP fra et par dage før skudsekundet, og slå det til igen et par dage efter.

Jeg har kigget lidt på problemet med skudsekunder i dag, og for ASR 1000 gælder:

• CSCua73674: Tiden på routeren kommer et sekund ud af sync ift. NTP-serveren, men vil ret hurtigt justere sig ind igen ved såkaldt ‘clock stepping’, altså at hardware-uret justeres i små ryk til det passer. Løst i IOS 15.2(4)S1, svarende til IOS XE 3.7.1S. Nyeste bugfix er 3.7.7S.
• CSCul73513: Anden fejl, men samme problemstilling og impact som ovenstående. Løst i 15.4(1)S4, svarende til 3.11.4S, der er nyeste bugfix af den release. (Releases ældre end 3.11S er ikke berørt).
• CSCtz61014: Noget værre problem, fordi det kan give et system-crash. Det sker dog kun, hvis routeren er konfigureret som ‘ntp master’, og det er ikke en ‘typisk’ konfiguration. Løst i 15.1(3)S4, svarende til 3.4.4S. Nyeste bugfix er 3.4.6S.
• CSCut65374: Et grimt problem, hvis man kører PTP, da det kan propagere en tid, der er meget langt ude af justering (og dem, der kører PTP gør det jo netop for at få en meget præcis time-stamping). Problemet er ikke løst i nogen software tilgængelig endnu.

Min anbefaling: Hvis man ikke kan leve med, at klokken kommer 1 sekund ud af sync, bør man opgradere til 3.10.5S. Hvis man kører PTP, skal man ud i work-arounds.

Jeg har kigget lidt på problemet med skudsekunder i dag, og Cisco-site’en siger for Catalyst 4500-X “No Expected Impact”, men jeg kan se, softwaren er berørt af (i hvert fald / mindst) følgende bugs:

• CSCua73674: Tiden på routeren kommer et sekund ud af sync ift. NTP-serveren, men vil ret hurtigt justere sig ind igen ved såkaldt ‘clock stepping’, altså at uret justeres i små ryk til det passer. Løst i IOS 15.1(2)SG, svarende til IOS XE 3.4.0SG. Nyeste bugfix er 3.4.6SG. Er også løst i 3.5E og 3.6E.
• CSCul73513: Anden fejl, men samme problemstilling og impact som ovenstående. Løst i 15.1(2)SG6, svarende til 3.4.6SG, der er nyeste bugfix af den release. Jeg kan ikke se, om 15 E er berørt.

Min abefaling: Hvis man ikke kan leve med, at klokken kommer 1 sekund ud af sync, bør man opgradere til 3.4.6SG.