classic.ISPforum.cz

Zdravím jak řešíte následující problém:
je nějaká páteřní síť dejme tomu
192.168.1.0/24
gw do internetu má třeba 192.168.1.1 přes switch a 10Ghz je připojený další router který má ip na rozhraní 192.168.1.2 a třeba ip 192.168.2.100 která je přes nějaké další routery zase na páteř. Jde o to že když vypadne 10ghz spoj na straně u switche ip adresy ze sítě 192.168.1.0/24 se stanou nedostupné, internet sice jde protože jede přes zálohu a default gw ale routing do 192.168.1.0/24 nefunguje. Další nevýhoda v tomto provedení je i že se z jedné strany pro každý spoj nedá nastavit cost spojů a nastavuje se pro celou páteř.

U 5Ghz spojů se dá routovat přímo na nich tam je to bez problémů. Jediné co mě napadá jsou L3 switch, nebo přidat další router - to je ale neefektivní protože pro každý spoj by musel být nějaký router, nebo nějak vypínat ip adresy na routeru, ale to se mi nezdá moc spolehlivé a je to nekoncepční.


Ip adresy jsou samozřejmě vymyšlené. Díky za každé nasměrování správným směrem.

hehe, stejně to je u nás. Co spoj to /30 právě kvůli tomu co píšeš. Každej sektor /24 a každej spoj /30 a každý "hnízdo" se sektory na lanu /24. Všude se routuje a jedině tak je možný používat kruh bez závislosti na nějakym jinym routeru pro daný úsek. Ano, s 10GHz spojem v tomhle smyslu máme taky problem ale dá se řešit buď tak že na jedný straně je router kterej ho odděluje což jak píšeš je opravdu neefektivný protože to mohlo v klidu switchovat na další routery a nebo se protahne "hnízdo" na druhej sajt a spojí se switchovaně jako by to bylo jedno hnízdo čimž se spojí každej router s každym.

a nebo se protahne "hnízdo" na druhej sajt a spojí se switchovaně jako by to bylo jedno hnízdo čimž se spojí každej router s každym.

To nám bohužel ale neřeší problém nebo jsem to špatně pochopil. Je to možné trochu rozvést? Nebo praktický příklad když máme gw router 192.168.1.1/24 switch a ze switch třeba 3x 10ghz spoje na 3 routery 192.168.1.2, 192.168.1.3, 192.168.1.4 .

To je naprosto normální. A důvod, proč za a) nebridgovat v takovýhle případech, za b) nemít na spoji žádné jiné provozní IP.

Ono i když budeš routovat, budeš mít mezi dvěma routery síť /29 (dvě strany a v něm dvě třeba alcomy s inband managementem). Oba routery propagují ten samý segment. Když se spoj rozpadne, tak se na tu vzdálenější stranu prostě nedostaneš. Skončíš na té bližší a ta co? Visí ve vzduchu. A pokud ten spoj má jen inband (i bez VLANy, to už je vlastně outband), máš problémy se datově dostat na obě jednotky, jednoduše se dostaneš opět jen na tu bližší.

Proto se používají tzv. loopback interface/adresy. Tedy adresy nezávislé na žádném spoji. Ty se pak odroutují vždy správně. Trochu problém je, že třeba mikrotik na to nic nemá - já používám IP na té LAN straně co je třeba domovní LAN síť (pokud je tam stále link, je to v pohodě). Případně vytvářím samostatný bridge s jednou /32 adresou.

Ono ti ani switchování (spanning tree) moc nepomůže. Ve chvilku, kdy přes ten spoj nepojedou data, tak se tam opět nedostaneš ...

Ale teoreticky je možné, že jsem tě jen špatně pochopil

to Ludvik:

To je naprosto normální. A důvod, proč za a) nebridgovat v takovýhle případech, za b) nemít na spoji žádné jiné provozní IP.

Jak jinak to udělat a nebridgovat, když spoje jsou čísté bridge, a žádný routing na nich nenastavíme, na to se ptám. Provozní ip na spoji nemáme, respektive ta otázka nebyla o tom jak se dostat na spoje ale za ně. Viz příklad.

Proto se používají tzv. loopback interface/adresy. Tedy adresy nezávislé na žádném spoji. Ty se pak odroutují vždy správně. Trochu problém je, že třeba mikrotik na to nic nemá - já používám IP na té LAN straně co je třeba domovní LAN síť (pokud je tam stále link, je to v pohodě). Případně vytvářím samostatný bridge s jednou /32 adresou.

loopback interface/adresy samozřejmě používáme na routerech, na spoji mi je to skoro jedno. V 95% pokud jedna strana nejde, je mrtvá nebo bez napájení takže se na ní stejně nedostanu respektive máme managment oddělený od dat takže se na ně dostanu. Jinak mikrotik na loopback má právě bridge který není nikam připojený a není tedy nikdy ve stavu down.

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.

Na UBNT na "páteřních" spojích lze koukat jako na jakoukoliv jinou alcomu. Buď je to úplně čistý bridge, na spoji je /29 a dohledová IP je z něj na obou zařízeních. Má to ty problémy v případě rozpadnutí spoje, ale lze to. Případně lze udělat zmíněný outband management. A v obou případech pomocí VLANy. Každá strana spoje má jinou VLAN na management, která končí na přímo připojeném routeru, na tom u eth portu. Samotná data jdou jakoby mimo, bez VLAN. A na obě strany spoje, na obě zařízení se dostaneš i když se ten spoj rozpadne. Management segment se odroutuje správně jinudy. Naprosto není potřeba tam routovat, není potřeba nějak zesložišťovat zařízení, které má jen přehazovat pakety mezi eth a rádiem.

U mikrotiku to svádí - každá wifi karta je vlastní rozhraní (a zároveň je jich tam víc). A většinou se tam routuje z jiných důvodů, tak už je fuk, že routuju i vlastně na tom PtP spoji. Nemluvě o tom, že si tam můžu udělat ten loopback.

no a jak se bez natu na tom routeru dostaneš na to pojítko když má definovanou bránu na druhou stranu a druhá strana nefunguje? Z pohledu centra je to snadný ale co když budu na druhý straně spoje?

Vždycky ti zůstane nějaká možnost jak to rozbít ... Když se ti rozsype spoj mezi wifi kartama mikrotiku, tak se také dostaneš jen na jednu z těch dvou IP odkudkoliv.

Je to stejný ze všech pohledů. Každou stranu toho rádiového spoje routuje ten bližší router (a tam má ta strana defaultu) - pokud se ten podělá, tak se tam logicky nedostaneš. Což ti může být fuk, nejede ti tím pádem ani jakýkoliv backup do toho tvého "hnízda".
Můžeš si pomoci dočasným přidělením té samé vlany i na druhé straně, pokud je (v případě UBNT) definovaná jak na eth, tak na wifi straně (což já ale nedělám). A třeba u alcomy je to fuk, pro jejich dohled stačí mít dostupnou jednu stranu (a dokonce to funguje i se špatnou default route, nevím jak to dělají). U jiných pojítek to může být jinak.

Prostě mít management rádia ve stejném IP rozsahu, jako jsou hraniční IP routerů je problematické, pokud je to součástí nějakého kolečka. Buď děláš to co já, nebo tam routuješ komplet, nebo to nějak přežiješ a těch pár výjimečných situací vyřešíš dočasnou NATkou (tedy defaulty jsou tam, kam jde provoz normálně).

hapi píše:no a jak se bez natu na tom routeru dostaneš na to pojítko když má definovanou bránu na druhou stranu a druhá strana nefunguje? Z pohledu centra je to snadný ale co když budu na druhý straně spoje?

no já si myslím, že právě spanning tree by to mělo vyřešit úplně v klídku

Myslíš špatně. Co udělá spanning tree s duplicitní cestou? Zablokuje pro všechny pakety, kromě BPDU. Dostaneš se tedy na to rádio na tomhle spoji? Ne.
Jo, MSTP by to řešilo - ale jsi tam, co v mém příkladu ... management musí být VLANě, kterou STP nezablokuje.
Kromě toho používat STP na rádiích, notabene halfduplexech ve free pásmu, je cesta do pekel. A to nemluvím o podstatně problematičtější konfiguraci a i dohledu takové sítě (v porovnání s OSPF apod.). Ale sehnat gigabitový switch není problém za malé peníze, stejný router - a člověk se nedoplatí. Vše má své pro a proti.

okoun píše:no já si myslím, že právě spanning tree by to mělo vyřešit úplně v klídku