tady máš takovej hrubej náčrt. Z téhle koncepce je pak fuk co kde odejde. Vždy zůstane trasa, okruh nebo něco průchozí. Switch je většinou bezporuchová věc. RB sem tam odejde, nevadí, postihne to pouze určitou část. Tobě jde o to že když maji klienti bránu na jedno RB který když vypadne tak ačkoliv jiný RB zajistí kruh a L2 vrstva tam je funkční tak nejedou protože rbčko na který klienti maji nastavenou bránu vyhnilo.
Když jednotlivá RBčka beru jako sektory kde každej sektor na wifi straně má svůj /24 subnet a tedy logicky routuje, tak klienti mají nastavený GW na něj. Když nejde on, nejdou což je logický a správný. Ovšem výhodu to má právě v tom co se stává tobě. Při téhle koncepci se to nestane. Pokud sektor přes OSPFko zjistí že vypadla hlavní trasa tak to pustí přes jiný RBčko v tom rozsahu /24 na switchy a jede se dál. Princip je všude routovat z čehož vyplynou ostatní návazný věci. RBčka v hnízdě se vždycky domluví a najdou si cestu skrz OSFPka.
Jistě, je tu problem s tím že když se do takovýhle koncepce vloží 10GHz spoj tak jí docela naruší ale dá se to řešit. Pokud mezi dvěmi hnízdy dám 10GHz spoj tak obě hnizda sloučim pod jedu /24 lehkou změnou IP adres na LAN stranách RBček. OSPFko opět pořeší správný cesty a jede se dál. Z tohoto důvodu tam máme /24 aby nikdy nedošly a taky se s /24 počítá lépe. To je za předpokladu že nechceš vkládat router mezi hnízdo a 10GHz pojítko což chápu.
Je tu pár podmínek který jsem si stanovil jako že klient nikdy nesmí být připojen přímo do hnízda tedy že nesmí mít IP z rozsahu hnízda. Pak totiž můžou vznikat ty problémy který popisuješ. Mezi klientem a hnízdem musí bejt router s OSPFkem kterej ho v případě problémů směruje přes jiný RBčko do netu.
Z tohoto důvodu nesnášim UBNT a nelze ho v téhle koncepci rozumně využít protože by celu touhle koncepci rozbilo. Defakto by šlo nahradit switch nějakým víceportovám RBčkem který by zpravovalo routing a ospfko na ubnt síti nicméně stále tu je ten druhý problém a to je ten že když ty ubnt hračky mají nastavenou bránu na jednu stranu a vypadne tak se z druhý strany na ně těžko dostává. Musí se pak dočasně nastavit natovací pravidlo aby se na ně dalo dostat. To na routovací síti s RBčky a ospfkem nehrozí a vždy se na ně dostanete ať je síť poškozená jak chce protože OSPFko to vždy zajistí.
Snad jsem to rozumně vysvětlil a snad někdo pochopí proč ti velcí ISPíci používají mikrotiky a proč na ně nedají dopustit a proč jsem extrémně nadšenej z toho že máme ospfko a mkčka v síti. Protože ta síť je teď naprosto blbuvzdorná a navíc umožňuje přepojování a vytváření kruhů extrémně lehce. Dám příklad: jedno RBčko na ptp spoji odejde. Co teď, je 2 hodiny ráno, těžko někam polezu a navíc ho nemám doma takže přijde až druhej den. Připojim se na druhý RBčko ptp spoje který je v pořádku, změnim IP adresu na IP adresu sektoru u vadnýho RBčka a připojim se na ten sektor. OSPFko do minuty propojí routovací tabulky a mám dočasný backup než se všechno opraví a to nejhlavnější je že to běží a mám čas na řešení. Takováhle síť je brutálně flexibilní. Rozhodnu se že ptp spoj timhle směrem zrušim a pošlu ho jinym směrem tak jenom přendám anteny, vyplnim správně IPčka podle umístění ve hnízdech a voala, za minutu vše zase běží bez drastických úprav v síti. Pro klienty se vůbec nic nemění.
Pokud mi někdo ukáže lepší koncepci sítě budu rad :-)
odpovědi typu že taková spousta routerů přes 4 hnízda je velká nebo že se na každým routeru snižuje rychlost je mylná. Tak jako tak paket musí zařízením projít a jestli je odbaven bridgem nebo směrován routerem je úplně jedno. Latence jsou stejné a pokud by někdo měl důkaz že při routingu dosahuje větších zátěží na CPU nebo že mu tam proteče míň dat tak ať srovná síly tím že na routerech vypne conn. tracking tak jako ho defaultně bridge má vypnutej.
