OSPF

[Majklik]

Master flag blábol vzniká taky, když se routery korektně vzájemně neslyší, čili to není opravdu broadcast doména, ale adept na NBMA. Jiná varianta, kdy naskakují bláboly, že najednou slyším něco, oc jsme neslyšel je haby v NATu, kdy se bude snažit NATovat OSPF.
ROS nemá to DR/BDR volbu udělánu úplně košer, ale plus/mínus funguje. DR by měl být tne stabilní router, který má nejen dost výkonu, ale hlavně tlustější linku, protože s nim komunikují všechny ostatní routery v segmentu.

[Majklik]

Já jsem lama, takže musím psát jako lama. Vycházím z toho, že má 3 mikrotiky propojené hloupým switchem. Defaultně jde ven vše přes mikrotik 1, ale když umře tak chce aby mu to jelo třeba přes mikrotik 2. Aby zařídil že mu to pojede primárně přes 1 mikrotik, tak druhej s třetím propojí vlanou a dá tam vyšší cost. To jsem pochopil, že chce dosáhnout.

To je jenan možnost. Druhá je, pokud tá záloha je dána propagováním defualt routy, že routery jsou na jednom segmentu L2 i IP bloku, mají stejné costy do toho segmentu a jen router 2 má nastaveno, že propaguje např tu defualt routu s větší cenou než ten první. To je klasičtější nastavení.

[hafieror]

a jen router 2 má nastaveno, že propaguje např tu defualt routu s větší cenou než ten první.

Tak už tu na tu větu a do nastavení svého rbčka koukám docela dlouho, ale nějak mě to nedochází.

[Majklik]

Pro tvůj případ (pokud by oba BFP krámy byly připojeny na jende segment s druhou řadou routerů) primární BGP krám:
/routing ospf instance set 0 distribute-default=always-as-type-1 metric-default=1
Sekundární BGP krám:
/routing ospf instance set 0 distribute-default=always-as-type-1 metric-default=100
Za předpokladu, že třeba tu linku k těm routerům bude mít ten třetí router přemýšlející koho použít jako default routu cenenou na cost 10, tak mu vyjde, že default routa přes primár má za 11 a přes sekundár za 110 a má jasno kam posílat další žádosti o porno...

[Majklik]

Pak Hapi píše, že nepoužívá backbone 0.0.0.0 ale 0.0.0.1. To by pomohlo?

Ne. Tím jenom dosáhneš toho, že pokud uděláš OSPF síť s vícero areami, kde žádná nebude mít číslo 0.0.0.0, tak se ti to fakticky rozpadne na X samostatných areí, které si vzájemně nevyměňují routy (budou se předávat jen uvnitř každé arei zvlášť). To je základní design OSPF. Předávání rout mezi různými areami probíhá pouze skrz areu s číslem 0.0.0.0. Takhle je to vymyšleno z několika důvodů, ať už minimalizece smyček pro zastaralé data, pro to, aby se z toho algoritmus pro výpočet stromu nezbláznil, kdyby to bylo zcela volné, tak i výkonostního škálování do vícero úrovní, ....
Pokud máš celou síť jen jednu areu, tak je v podstatě jedno, jaké číslo použiješ.

[hafieror]

Můžete mě někdo nakoupnout, jak v rámci OSPF řešit následující situaci?


Červenej link není zatím aktivní, ale po propojení bych rád docílil, aby pouze veřejné adresy šly tímto propojem a neveřejné jako dosud do NATrouteru a BGP, tedy cestou kudy i teď jdou veřejné adresy zcela zbytečně. Samozřejmě by stačilo udělat routing mark, kterej bude veřejky posílat přímo na BGP, ale zajímalo by mě zda to jde udělat i v rámci ospf.

[Majklik]

Tohle pomocí jednoduchého OSPF jednoduše nedáš. V podstatě OSPF normálně funguje pouze na základě cílové adresy a ne zdrojové. Takže to směrování toku od Router1 nejde udělat pomocí jendoduchého OSPF. Komplikované varianty jsou možné - víceinstanční OSPF - zvracím - 2x tolik práce pro nic. Nebo OSPF jen jedno a nad to MPLS a TE (traffic engeneering). S tím už pomocí TE tunelu uděláš co chceš - ale proti policy routingu je to tuna klikání navíc v podobě akademického cvičení - zvracím ještě víc.
Takže OSPF nech žít jak je zvykem, kdy defaultně ven na základě ceny default brány tě požene tou přímou cestou router1-bgp a jen na router1 udělej policy routing, kde zdrojové neveřejné IP pošle natvrdo k NAT bedně. Cestu zpět už umí ošetřit nativně ospf, pokud ty veřejné IPčka na které budeš NATovat nabinduješ na nějaký interface a zapropaguješ OSPFkem, takže BGP router pro cestu zpět nebude váhat.

[hafieror]

Tak tu mám pro sebe další zapeklitou situaci. Přepojil jsem jeden dům na nový přístupový a původní rádio jsem nechal jako zálohu, protože jede do netu úplně jinou cestou. To dělám poslední dobou často, ale teď se mě to stalo na místě, kde jsou dvě různé area.

Tento případ by měl řešit virtual link, který se ale nedoporučuje a převedení prvků v area1 do area2 nebo naopak je spíše neřešitelný. Existuje nějaké elegantní řešení?

[Majklik]

Kdo se bojí virtual linku, ten si nesmí dělat zacyklené multi area sítě!

Nebál bych se ho. Kde mám použito, funguje (ale asi vše je případ, že jim spojuju rozpůlenou backbone). Takže dvě rádia, každé v jedné area a na ethernetu lokální sosáči?
Pokud A1 a A2 jsou typu defualt, tak Ethernet udělat další areu3 a udělat dva virtual linky přes ty A1 a A2.
Pokud se virtual linku bojíš víc než finančáku a nebo A1/A2 nejsou default (pak musí být NSSA), tak jiná možnost je nechat rádia patřičně v těch A1 a A2, ethernet nestrkat do žádné arei a vyexportovat ho jako externí routu type1.
Pokud je jen jedna area typu default a druhá je stub nebo NSSA, tak je možno Ethernet strčit do té stub/nssa a udělat jen jeden virtual link. Ale tady jsou už určité ale ohledně priorit uplatňování jednotlivých typů rout (provoz ti může odtékat jinudy, než budeš třeba očekávat jen dle prostého součtu cost - pravidla o upřednostnění intra area cesty, před inter a další)...

[hafieror]

"Takže dvě rádia, každé v jedné area a na ethernetu lokální sosáči?"
- ano přesně tak

"Pokud A1 a A2 jsou typu defualt, tak Ethernet udělat další areu3 a udělat dva virtual linky přes ty A1 a A2."
- tato varianta tomu odpovídá, tak vyzkouším

Děkuji.