Ohledně "tlustoproudu" (pardon: 220V = "nízké napětí" = nikoli tlustoproud):
tohle chce průzkum na místě. Každopádně by to měl dělat někdo, kdo ví co dělá a má na to papíry. Aby nezpůsobil horší průser, než tam teď zrovna je.
Napadá mě rámcově následující postup:
1) shodit hlavní jistič a změřit / zkontrolovat / zajistit, že je rozvod bez napětí (co ty UPSky? Aby něco neposlaly zpátky)
2) na "centrálním uzlu zemí" = asi ekvipotenciální přípojnice na patě baráku, odpojit modrý nulák (resp. všechny modré nuláky co vedou do baráku)
3) změřit na tom odpojeném nuláku (nulácích) odpor proti stromu žlutozelených zemí. Pokud je nižší než nekonečný, hledat kde je to propojené.
4) po nalezení nežádoucího propoje (a jeho odstranění)
uvést nulovací můstek na patě baráku do původního stoprocentního stavu a nejspíš by na to měla být i
nová revize :-( Což ale... když hledáte ducha v napájení, tak je možná revize namístě i tak.
5) Pokud to celé vypadá dobře, tak zkusit naopak změřit průsakové proudy ve žlutozeleném stromě (měřit nějaké miliampéry bez odpojení - snad kvalitním klešťákem?)
Pokud máte jeden chránič a na něm houfec okruhů k různým spotřebičům, nebo třeba jeden okruh široce "rozesmyčkovaný" (rozvětvený), a lítá Vám chránič, doporučuji to rozdělit na větší počet menších větví a na každou zvlášť chránič. Pokud máte nějaký "podezřelý spotřebič" tak šup s ním na samostatný chránič. Pokud nechcete cpát peníze do chráničů / nemáte místo v rozvodnicích, tak aspoň osadit
jističe s odpojováním nuláku - jističe na uvedeném odkazu jsou široké 1 modul. Aby toto mělo smysl, tak to předpokládá, že máte rozvětvené (samostatné) aspoň rozvody=kabely 1F+N(+PE) do různých větví.
Ohledně záhady v LAN při "správném" pořadí naběhnutí jednotlivých aktivních prvků:
- dá se problém nasimulovat i mimo událost s vybavením chrániče? Možnost reprodukovat problém na požádání je snadno 80% práce na úspěšném řešení :-)
- totálně lehne na záda vždy tentýž z obou switchů, a to ten ke kterému je připojené APčko?
- zkoušel jste koukat wiresharkem, co se na síti děje ve chvíli, kdy "se všechno strašně vleče"? Cíl: možná byste viděl konkrétní traffic, který se tam zacyklil...
Viděl jsem nebo jsem zaslechl o všelijakých "malých překvapeních" :-) která mohou mít za následek broadcast storm nebo něco podobného - obecně mám pocit, že není jeden konkrétní well-known problém, ale spíš že "zelený je strom života". Namátkou:
Sešly se mi kdysi na stole (resp. v síti):
1) krabička (tuším průmyslový switch/router nebo tak něco), která když neměla napájení, tak vykazovala vazbu mezi páry RX/TX na 100Mb Eth portu, který koukal do mé sítě. Prostě bez napájení se to chovalo jako loopback.
2) switch, který ve spojení s dotyčnou krabičkou "detekoval vrácenou energii" = linknul se sám proti sobě a při "nasazení RX/TX loopbacku" rozjel mocný broadcast storm. S jinými switchi tento problém nenastával - co jsem tehdy zkoušel jiné switche, tak se na loopbacku odmítly linknout.
Minulý týden jsem si tu hrál s
OpenWRT na platrofmě IPQ4019. Je tam taková bizardní fičurka, že on-chip switch prováže jedno vnější rozhraní s interním virtuálním eth1 a ostatní vnější rozhraní s interním virtuálním eth0. A i když si to oddělím VLANami, resp. je to tak odděleno magicky v hardwaru, tak pokud udělám soft-bridge mezi eth0 a eth1, tak sice nezpůsobím broadcast storm, ale každý broadcast projde switchem *2x*. A protože ten interní switch nemá per-VLAN FDB, tak si tím soft-bridgem způsobím, že se mi ve switchi (a potenciálně i v širší síti - přeskakuji ohavné podrobnosti) přesměrují FDB entries pro různé stroje špatným směrem, tzn. konkrétně směrem k té mojí hračko-krabičce s OpenWRT. Ozáplatoval jsem to záznamem v ebtables, který zamezil forwarfování mezi eth0 a eth1 = aby se mi provoz nevracel zpátky do HW switche. Rovnák na ohejbák a vytloukání klínu klínem, ale momentální problémek mi to vyřešilo...
Kdysi jsem znal síť s mnoha VLANami a STP, kde použité switche při určité úrovni zátěže CPU / za nějakých okolností přestaly stíhat počítat STP, a prostě forwardovaly všechno všude. Což v redundantní topologii znamenalo masivní broadcast storm. Následkem čehož všechny switche přestaly stíhat počítat STP, a forwardovaly všechno všude...
Při bootování firmwaru na různých malých switchích si lze představit chybku integrace FW+HW (např. OpenWRT se tak může chovat na některém hardwaru) kdy po startu po nějakou dobu funguje mezi všemi porty otevřený HW switch, bez STP. Což otvírá prostor pro všelijakou zábavnou neplechu v závislosti na tom, co a jak má člověk na takovou krabičku zvenčí připojeno. Netvrdím, že wifina od Cisca s originálním firmwarem bude dělat zrovna tohle :-)
Jinak divné věci v síti může způsobit taky nečekaný/nežádoucí/ "rogue" DHCP server, který si někde omylem zapnete. Výsledkem ale není broadcast storm a zmatení se nedostaví hned - dotkne se to jenom stanic, které si řeknou o DHCP ve chvíli, kdy je v síti druhý DHCP server (a tento stihne odpovědět jako první). Takže třeba pokud by byl "vadný" DHCP server vidět jenom pár vteřin v průběhu startu AP, tak se vlastně nic neděje.
Pokud se stane, že management switche (obvykle dost slabý CPU) dostane třeba pár vteřin kopanec broadcast stormem, nebo nějakým jiným provozem na ten způsob, který ho položí na záda, mohou se dít všelijaké věci. Bohužel u takových "nechtěných efektů" se může případ od případu velice lišit a chcete-li specifické odpovědi, je potřeba "vložit ruku do otevřené rány".
Pokud wireshark na koncové stanici nic moc neukáže, tak různá média se dají i pasivně odposlechnout. Nejsnáz optika. Konkrétně problém je to na 1Gb/10Gb metalice, tam leda vložit počítač se soft-bridgem (nebo drahý profi forwardující tap).
Zkoušel jste v těch switchích a v tom AP poaktualizovat firmware?
Zobrazit příspěvky
