EN

Když přepínače nepřepínají - CVT FI - Blogy

CVT FI

RSS

Novinky a změny v provozu počítačů, počítačové sítě, prezentační a další techniky na FI MU. Další informace jsou dostupné v Technických informacích na webu fakulty.

Pro hlášení problémů prosím kontaktujte příslušnou sekci CVT FI.

Informace o aktuálních problémech naleznete na stránce o výpadcích.

Vlastníci blogu: FI:unix@fi, FI:CVT FI
Starší příspěvky
Kategorie
Vlastníci blogu: FI:unix@fi, FI:CVT FI
Právo číst: kdokoliv v Internetu
Právo komentovat: kdokoliv přihlášený v ISu
18. 5.
2018

Když přepínače nepřepínají

  • RSS
Zajímavé | 22 | 22
RNDr. Jan Kasprzak, Ph.D. (CVT FI MU), učo 1885
infrastruktura
Dnes v noci přišla od našeho monitorovacího systému výstraha, že po síti nekomunikuje několik zařízení, vesměs chladicích jednotek datancentra. Na první pohled komunikace nějak probíhala a chlazení fungovalo, takže jsme odložili řešení problému na ráno. Jak to dopadlo?

Zjistili jsme, že příslušná zařízení nevracejí některé pakety při použití programu ping, a že komunikace celkově vázne. Všechna tato zařízení jsou připojena do stejného ethernetového switche, což by naznačovalo problém na tomto switchi. Nicméně do tohoto switche jsou připojeny i jiné věci, které bez problémů komunikovaly. Problém se týkal jen šesti chladicích jednotek a jednoho zařízení jiného typu. Počítadla chybných paketů na tomto switchi nevykazovala žádnou anomálii, stejně tak jako celkový datový provoz tohoto switche.

Zkusili jsme tedy připojit notebook přímo do stejného switche a spustit ping na jednu z chladicích jednotek. Tady to začalo být zajímavé:

$ ping 42.42.42.42
PING 42.42.42.42 (42.42.42.42) 56(84) bytes of data.
64 bytes from 42.42.42.42: icmp_seq=1 ttl=64 time=0.768 ms
64 bytes from 42.42.42.42: icmp_seq=2 ttl=64 time=0.345 ms
64 bytes from 42.42.42.42: icmp_seq=5 ttl=64 time=0.366 ms
wrong data byte #44 should be 0x2c but was 0x7c
#16     10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 7c 3b f9 98
#48     30 31 32 33 34 35 36 37 
64 bytes from 42.42.42.42: icmp_seq=6 ttl=64 time=0.353 ms

Je vidět, že síť nejenže ztrácela některé pakety, ale některé jiné také poškodila. Změna se týkala vždy bajtu číslo 44 až 47 v ICMP echo paketu.

Pak jsme vyzkoušeli, kterých portů switche se to týká. Fyzicky má switch na přední straně porty dělené do skupin: 1-16, 17-32, 33-44, a optické 45-48. Postupným zkoušením jsme zjistili, že chyba nastává, když aspoň jeden konec komunikace je v některém z portů 17-24. Switch má zřejmě porty obsluhované po osmi samostatnými přepínacími obvody, a problém je v té součástce, která obsluhuje porty 17 až 24.

Pro jistotu jsme vyzkoušeli ještě switch restartovat, kdyby přece jen šlo o softwarový problém v operačním systému samotného switche. Problém ale ani pak nezmizel. Jako poslední pokus jsme vyzkoušeli switch odpojit od napájení a pak zase zapnout. K našemu velkému překvapení tento zásah způsobil, že všechny porty switche začaly komunikovat normálně.

Záhada jestli jde o problém softwaru nebo hardwaru se tedy nevyřešila, problém budeme řešit s výrobcem switche. Zatím si přidáváme tento incident do sbírky příkladů toho, kdy ani reboot nepomůže, a kdy částečný výpadek něčeho je problematičtější a hůře odhalitelný, než když něco přestane fungovat úplně.

Dosud nečteno0 komentářůpermalink
« Vlna e-mailů o nedoručitelnosti (8. 3. 2018 20:23) | Útočník chcel ťažiť kryptomenu na Aise: Ako sme to zistili a ako sa brániť » (14. 6. 2018 16:05)

Zatím žádné komentáře.