55
« kdy: 07. 08. 2023, 21:42:58 »
:-) "tak si to vyzkoušej" - v naší skromné LANce mám běžně spících kompů sáček, a nikdy jsem s nimi neměl problém. Pokud to proti nějakému vadnému modelu switche ve vzácných případech dělá problém, tak bych musel mít na stole ten konkrétní hardware. Jít hledat ztracené klíče někam, kde se dobře hledá, není úplně slibný přístup k problému :-)
Ano mně se taky věci občas se... kazej. Ale neházím je do jednoho pytle hned od pohledu. Že to vypadá prostým okem stejně, nemusí mnoho znamenat. Vysvětlení bývají roztodivná a někdy kuriózní.
"Uspané zařízení typicky moc nekomunikuje" - jako vtip beru. Věcně: no ono nekomunikuje vůbec. Pokud má linknutý Eth port, tak kvůli probouzení. Což funguje tak, že síťovka, zanechaná při usnutí v patřičné konfiguraci a krmená StandBy napájením, autonomně filtruje přišedší pakety (bez omezení průchodnosti) a čeká na "magickou sekvenci". Pokud tuto "žádost o probuzení" zaznamená, pošle budíček standardním postupem do hloubi motherboardu svému hostitelskému čipsetu (PCI signálem PME# nebo analogickým mechanismem na PCI-e).
Dovedu si představit, že jako protiargument použijete scénář, kde spící server má uvnitř bdící IPMI BMC, které na jedné ze síťovek parazituje jakýmsi bočním kanálem - a tedy "uspaný server trochu komunikuje", navíc ta postranní tkanička má omezené pásmo. Toto ale není náš případ, NAS za deset klacků nejspíš BMC obsahovat nebude.
Přijde mi nepravděpodobné, že by síťovka "uspaná do režimu Wake-on-LAN" dokázala autonomně generovat PAUSE frejmy (802.3x flow control) - ale ověřené to nemám. Netušíte někdo, jestli jsou tyhle frejmy viditelné ve wiresharku? Myslím kdybych si to chtěl někdy odposlechnout pasivním TAPem. Když odposlechové síťovce flow control zakážu, tak jestli mi je předá nastojato...
Za druhé mi není jasné, proč by "síťovka v uspaném počítači" PAUSE frejmy posílala. Možná bugem v ovladači nebo v hardwaru - že by brala ohled na plnou frontu vůči hostiteli, kterou sladce spící hostitel samozřejmě ignoruje... ale to je jenom moje bujná fantazie.
Fakt je, že na svých switchích mám 802.3x zakázané. A jsou switche, kde to v managementu zakázat nejde.
Taky byla jeden čas populární čínská inovace "broadcast storm protection" na bázi rate-limitu. Prostě čipset v hardwaru uměl, omezit kapacitu propouštěných broadcastů a multicastů. Třeba na 1 Mbps. Viděl jsem pár modelů unmanaged switchů, které tohle měly zapnuté a nebylo jak to vypnout nebo konfigurovat. Takže když jste poslal nějaký video stream multicastem, tak umřel například ARP a DHCP :-) U některých modelů managed switchů jsem to viděl konfigurovatelné a trochu chytřejší, s vyloučením užitečných druhů provozu...
Switche integrované uvnitř WiFi APček, routerboardů apod. nebývají úplně hloupé. Už třeba proto, že umí hardwarově VLANy, včetně nastavení tagged / untagged portů. Protože procesor APčka do toho integrovaného switche kouká VLANovým trunkem (nebo i dvěma). A vedle toho trunku pro payload mívá management CPU ke switchi i nějaký boční komunikační kanál pro management (nevím zda MDIO nebo I2C apod.) Od výrobce čipsetu mají výrobci krabiček k dispozici proprietární utilitu nebo API, přes které se dají číst a konfigurovat parametry jednotlivých fyzických portů. Třeba v OpenWRT tomu bývá trochu vidět na zoubek, naopak proprietární firmwary (RouterOS) mívají tyhle věci zabalené do GUI/CLI.
"muticast se na hloupym switchi chova presne stejne jako broadcast = switch se zacne chovat jako HUB".
Chápu jak jste to myslel. Terminologicky správně to úplně není, protože switch nadále dělá store and forward, nevzniká kolizní doména.
"Ostatne, stejny problem nastane, kdyz vycerpas ARP."
Měl jste patrně na mysli: když switchi dojdou sloty ve "forwarding database" = v tabulce naučených MAC adres, která mívá v hardwaru switche pevnou maximální velikost.
ARP tabulky existují na L3 stanicích = koncových uzlech sítě. ARP mapuje adresy mezi L3 a L2.
Njn. Bez fyzického přístupu těžko zjistíme, co se tam tazateli přesně děje.
Zobrazit příspěvky
