Asbjorn Hojmark's Infrastructure Blog

Som mange vil vide, er det generelt (traditionelt) et krav ved ‘varm’ vMotion på VMware (altså med VM’en tændt), at man flytter VM’en til en host med en CPU magen til eller til en host med en nyere CPU. Man kan generelt ikke flytte en VM til en ældre CPU eller — mere teknisk korrekt — til en CPU med færre features. Sådan har det været ca. altid.

Heads up!

Cisco har open-sourced en trafik-generator, TRex:

• Site
• Demo
• Code

Der er desværre ingen routing-support, men ellers ser det godt ud.

-A

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.

Nattens hyggelige fejlsøgning…

Redundans for OSPF-ringe virkede ikke ordentligt: Når det direkte link mellem to distributions-routere var nede, og trafikken skulle flyde via en af de mange, vidunderlige holde-OSPF-areas-sammen GRE-tunnels, røg trafikken i bitspanden.

Fejlsøgning viste, at problemet skyldtes, at tunnel destination (7600) modtog pakken som IP-i-GRE-i-MPLS, og det kan en 7600 ikke terminere / route til et rent IP-interface. Tunnel source / destination er separate loopbacks, da tunnel-trafik ellers software-forwardes på den platform, og loopbacks er så som normalt passivt inkluderet i IGP’en (i dette tilfælde ISIS).

Dagens sjove fejlsøgning…

Nogle bestemte web-sites virkede ikke for klienter på bestemte typer af access-switche (de gamle 3560 fejlede, men de endnu ældre 3550 virkede fint). Man kunne se en TCP SYN (eller ICMP ECHO) blive sendt, men ikke noget svar.