abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 15:22 | Nová verze

    Lehké desktopové prostředí LXQt bylo vydáno ve verzi 2.4.0. Jde o převážně opravné vydání s drobnými vylepšeními podpory Waylandu.

    |🇵🇸 | Komentářů: 0
    dnes 12:44 | IT novinky

    Počítačová hra Kingdom Come: Deliverance 2 českého studia Warhorse získala cenu BAFTA v kategorii nejlepší příběh. V konkurenci pěti dalších nominovaných děl porazila i úspěšnou francouzskou hru Clair Obscur: Expedition 33, která v letošním ročníku získala cenu za nejlepší hru roku.

    Ladislav Hagara | Komentářů: 1
    dnes 12:22 | Komunita

    Projekt KDE oslaví v říjnu 30 let. Matthias Ettrich poslal 14. října 1996 do diskusní skupiny comp.os.linux.misc zprávu, která započala historii projektu. Důležité milníky jsou zobrazeny na časové ose KDE.

    Ladislav Hagara | Komentářů: 1
    dnes 02:55 | Komunita

    Byly vyhlášeny výsledky letošní volby vedoucí/ho projektu Debian (DPL, Wikipedie). Poprvé povede Debian žena. Novou vedoucí je Sruthi Chandran. Letos byla jedinou kandidátkou. Kandidovala již v letech 2020, 2021, 2024 a 2025. Na konferenci DebConf19 měla přednášku Is Debian (and Free Software) gender diverse enough?

    Ladislav Hagara | Komentářů: 15
    dnes 00:55 | Nová verze

    Byla vydána nová verze 10.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přidána byla podpora Orange Pi 4 LTS. Přibyl balíček Prometheus.

    Ladislav Hagara | Komentářů: 0
    včera 18:55 | Nová verze

    Implementace VPN softwaru WireGuard (Wikipedie) pro Windows, tj. WireGuard pro Windows a WireGuardNT, dospěly do verze 1.0.

    Ladislav Hagara | Komentářů: 2
    včera 16:11 | IT novinky

    V Pekingu dnes proběhl 2. ročník půlmaratonu humanoidních robotů. První 3 místa obsadili roboti Honor Lightning v různých týmech. Nový rekord autonomního robota je 50 minut a 26 sekund. Operátorem řízený robot to zvládl i s pádem za 48 minut a 19 sekund. Řízení roboti měli časovou penalizaci 20 %. Před rokem nejrychlejší robot zvládl půlmaraton za 2 hodiny 40 minut a 42 sekund. Aktuální lidský rekord drží Jacob Kiplimo z Ugandy s časem 57 minut a 20 sekund [𝕏].

    Ladislav Hagara | Komentářů: 5
    17.4. 17:11 | Zajímavý článek

    Stanislav Fort, vedoucí vědecký pracovník z Vlčkovy 'kyberbezpečnostní' firmy AISLE, zkoumal dopady Anthropic Mythos (nový AI model od Anthropicu zaměřený na hledání chyb, který před nedávnem vyplašil celý svět) a předvedl, že schopnosti umělé inteligence nejsou lineárně závislé na velikosti nebo ceně modelu a dokázal, že i některé otevřené modely zvládly v řadě testů odhalit ve zdrojových kódech stejné chyby jako Mythos (například FreeBSD CVE-2026-4747) a to s výrazně nižšími provozními náklady.

    MakeIranBombedAgain❗ | Komentářů: 6
    17.4. 12:44 | IT novinky

    Federální návrh zákona H.R.8250 'Parents Decide Act', 13. dubna předložený demokratem Joshem Gottheimerem a podpořený republikánkou Elise Stefanik coby spolupředkladatelkou (cosponsor), by v případě svého schválení nařizoval všem výrobcům operačních systémů při nastavování zařízení ověřovat věk uživatelů a při používání poskytovat tento věkový údaj aplikacím třetích stran. Hlavní rozdíl oproti kalifornskému zákonu AB 1043 a kolorádskému SB26-051 je ten, že federální návrh by platil rovnou pro celé USA.

    MakeIranBombedAgain❗ | Komentářů: 13
    17.4. 12:33 | Nová verze

    Qwen (čínská firma Alibaba Cloud) představila novou verzi svého modelu, Qwen3.6‑35B‑A3B. Jedná se o multimodální MoE model s 35 miliardami parametrů (3B aktivních), nativní kontextovou délkou až 262 144 tokenů, 'silným multimodálním vnímáním a schopností uvažování' a 'výjimečnou schopností agentického kódování, která se může měřit s mnohem rozsáhlejšími modely'. Model a dokumentace jsou volně dostupné na Hugging Face, případně na čínském Modelscope. Návod na spuštění je už i na Unsloth.

    MakeIranBombedAgain❗ | Komentářů: 1
    Které desktopové prostředí na Linuxu používáte?
     (14%)
     (8%)
     (1%)
     (12%)
     (30%)
     (3%)
     (6%)
     (2%)
     (15%)
     (25%)
    Celkem 1361 hlasů
     Komentářů: 30, poslední 3.4. 20:20
    Rozcestník

    Dotaz: prevence: topologická smyčka v síti → zahlcení

    31.3.2009 11:46 vencas | skóre: 32
    prevence: topologická smyčka v síti → zahlcení
    Přečteno: 1473×

    Zdravím,

    řeším problém jak předejít zahlcení sítě při vytvoření smyčky. Síť má asi 100 koncových uzlů a topologie je stromová, asi takhle (všechny switche jsou 3com):

    1. Nahoře je hlavní switch 1GBit Baseline 2816, na kterém visí jednak servery, jednak nižší páteřní switche.
    2. Hierarchicky níže jsou Baseline 2250, 2250+, 2126g, které mají každý 1GBit uplink nahoru a 48 resp. 48 resp. 24 100MBit portů, na kterých už jsou koncové uzly.

    Když propojím 2250 switch sám se sebou přímým kabelem, vznikne smyčka, která položí síť (libovolný broadcast, který si switch posílá stále dokola a pokaždé ho pumpuje znovu do celé sítě?). Když propojím 2250 s 2816 (dublované spojení, které už existuje), síť se taky položí. 2816 se sám se sebou propojit nenechá, asi je inteligentnější.

    Mám tedy 2 otázky − jsou začátečnické, omlouvám se, google mi ale nijak přímo neporadil, asi jsem nevěděl, na co se přesně zeptat:

    1. Jaké switche jsou třeba, aby detekovaly smyčku a vyřadily ji? Stačí: jak se tato vlastnost popisuje? "BPDU protection" všechy ty switche mají (např 2250 má "BPDU protection in Fast Start"), ale to nepomůže. "STP" používají také všechny, ale to ještě asi neznamená, že to smyčky najde.
    2. Co je třeba k tomu, aby se předešlo situaci, že někdo místo koncového uzlu zapojí nějaký levný switch, na kterém se udělá smyčka, a tak zase zahltí celou síť broadcasty a položí ji?

    Doufám že řešení je mezi židlí a klávesnicí a ne v nákupu lepších (dražších) switchů. Díky za nějaké rady, připadá mi že to je problém, který se musí nějak řešit všude, a přitom jsem toho našel pomálu.

    Odpovědi

    31.3.2009 12:00 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení
    Ad 1) To ti poresi STP, zrejme to nemas spravne nastaveny nebo zapnuty vsude.

    Ad 2) To asi STP nepochyti, switche by meli mit neco jako storm control, cili obranu proti DoS utoku.

    Pokud nevyzadujes rozesilani broadcastu po cele siti (pro wokenni sdileni), tak by melo jit rozdelit kolizni domeny. Proste switch nebude preposilat broadcasty mezi normalnimy porty a uplinkem.

    Zdenek
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    31.3.2009 13:13 Zdenek
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení
    STP poresi obe situace.

    Vypnuti broadcastu, ale znefunkcni o hodne vic veci napr. ARP :-)
    31.3.2009 20:24 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení
    Ach so, nejak jsme mel pocit ze jsem napsal blbost. Zadelal by sis na dost problemu...
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    31.3.2009 16:00 vencas | skóre: 32
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení

    Díky za obě odpovědi. Kromě jednoho switche (2250+) jsou ty switche unmanaged. Dá se nějak STP nastavit i na nich (přes snmp?)? Specifikace přitom uvádí u všech něco jako "IEEE 802.1d (bridging)", což je, jestli to chápu STP.

    Pomocí STP si však akorát switche dávají mezi sebou vědět o topologii, ale pokud se to nedá nějak nastavit (třeba priorita), tak o samo o sobě problém neřeší, ne?

    Dík, Vašek

    31.3.2009 17:27 rubicon
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení

    Tyhle přepínače neznám, ale pokud podporují 802.1d (což píšeš, že ano), je STP implicitně povoleno. Přesněji, jde-li o IEEE 802.1D-2004, bude to RSTP - Rapid STP.

    K tvému poslednímu souvětí: problém to řeší, protože přepínače si mezi sebou vyměňují BPDU zprávy na základě kterých rozhodnou o kořenovém přepínači (mostu). Vůči němu, kořeni, začnou tvořit logickou bezesmyčkovou (stromovou) topologii. Vhodně zvolená rozhraní přepínačů se pak přepnou do stavu blocking/discarding, kdy se neúčastní přepínaní rámců a případná smyčka se tak "rozpojí".

    Pokud se ti ty přepínače chovají po zapnutí tak, že je zahltí broadcast storm, jak popisuješ, je někde velká chyba. Zvážil bych reklamaci, protože takto nejsou konformní s 802.1d.

    31.3.2009 17:33 rubicon
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení

    > Pokud nevyzadujes rozesilani broadcastu po cele siti (pro wokenni sdileni), tak by melo jit rozdelit kolizni domeny.

    Nejspíše překlep. Míněny jsou broadcastové domény, neboť přepínač sám o sobě terminuje kolizní domény na každém svém rozhraní. A v době fulduplexu už se s kolizemi ani nepočítá (nepoužívá se CSMA/CD).

    31.3.2009 20:24 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení
    Samozrejme, kolizni domeny byly u HUBu, to uz dnes je pase. Nicmene uz mi doslo ze zrusit broadcasty by prineslo dost problemu. I obyc DHCP a ARP jedou pres broadcasty.

    Jen jsem premyslel zda STP poresi zasmyckovany hloupy switch na jednom portu v STP switchi. STP preci hlida sit tak ze vysle STP broadcast paket a pokud se mu nekterym jinym portem vrati, tak ten dotycny port zakaze. Nevim zda by zakazal i ten samy port kterym se STP paket vratil. Ale vpodstate asi proc ne. Ma to fungovat tak ze z jednoho (typicky uplink) portu prijme STP paket a vsemi ostatnimy porty ho rozesle dal. Zadnym z portu se ten paket nesmi vratit.

    Zdenek
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    31.3.2009 22:19 rubicon
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení

    Ono je ta činnost STP poněkud složitější. Předně, máme-li být přesní, nejde o "STP broadcast paket", ale o STP multicast rámec, což není nic jiného než tady již jednou zmíněný BPDU rámec. Pokud se přepínači tento odeslaný rámec vrátí jiným rozhraním, pozná podle BID (identifikátor přepínače/mostu složený z priority a MAC adresy přepínače), že na těchto dvou portech je připojen sdílený segment (např. HUB) a zakáže jedno z nich. Opět pro přesnost - to rozhraní, které má vyšší číselnou hodnotu PID (Port ID), bude mít roli Backup Port a stav Discarding (uvažujme RSTP); většinou se na prioritu portů nešahá, takže tímto rozhraním bude to, které je vyšší v pořadí.

    A jak ví, že tam je sdílený segment? Protože pokud by na obou rozhraních "visel" další přepínač, nemohl by se vrátit stejný BPDU rámec - BID by odpovídalo tomuto dalšímu přepínači a ne tomu původnímu. To je i odpověď na otázku, "zda by zakazal i ten samy port kterym se STP paket vratil" - k tomuto nemůže v přepínaném Ethernet nikdy dojít (že by po jednom drátu přišlo stejné BPDU tam a zpátky).

    31.3.2009 17:51 rubicon
    Rozbalit Rozbalit vše Re: prevence: topologická smyčka v síti → zahlcení

    Ad 1. "BPDU protection" je něco jiného než si představuješ. Tohle zajišťuje ochranu před připojením přepínače do rozhraní, které je nastaveno jako "Edge", tedy za kterým je očekávána pouze koncová stanice. Tedy vlastně je to částečně odpověď na Ad 2, jen z jiné strany. Provádí se to buď filtrací BPDU rámců nebo rezolutním zakázáním příslušného rozhraní.

    Ad 2. Pokud ten přepínač podporuje STP, a žil jsem v představě, že jej podporují všechny, připojení dalšího přepínače způsobí pouze "přepočítání" logické topologie tak, aby tam ty smyčky zmizely. Jediné riziko je právě v nastavení rozhraní do role Edge, ale to u těch unmanaged přepínačů není jak udělat a téměř jistě tam tenhle problém není.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.