OSPF

[Majklik]

Quagga/zebra se chovájí stejně. Ber to tak, že ospf/networks ti popisují topologii dělby na arei. Router si dle těch segmentů určuje, který interfejsy ho zajímají a má na nich pouštět routovací proces/komunikaci. Takže ospf network ideálně rozdělené sítě vypadá třeba:
10.0.0.0/24 - backbone
10.0.0.0/10 - area1
10.64.0.0/10 - area2
10.128.0.0/10 - area3
10.196.0.0/10 - area4
a takto je na všech routerech v síti a router si dle aktuálního stavu IP/sítí na interfejsech určuje, kde co spustí a začne propagovat v dané arei, pokud ty sítě jsou podmnožinou toho dělení v networks. Připadá mi to zcela logické. Pokud potřebuji ty tuny malých prefixů agregovat dohromady (pokud to mám takto krásně ideálně rozděleno a na hranici arei to jde zagregovat), tak zařídím přes area networks na ABR...
Pravda, OSPF3 pro IPv6 to dělá už jinak. Jen definuji, jaký interface leží v jaké arei a ne jaké sítě tvoří jakou arei. To se hodí, pokud má člověk tuny různých sítí a je jich víc na jendom interface, je to jendodušší, než to networks.
Velkému propagování connected bych se vyvaroval. S externíma routama se zachází trošku jinak a občas se někdo diví, co se nakonec dostne do routovací tabulky. V ideálním případě jendoduché sítě je jen jeden externí route záznam, a to default routa. A navíc Mikrotik měl těžjký problém pokud byl velký podíl external rout v route distribuci (cca desítky intra/inter záznamů dohromady s tisícovkou ext záznamů), dost to pak blbo a OSPF se sekal. Ale nezkoumal jsme u posledních verzích, zda na tom nějak zapracovali (ono se ná úplně stejně v podobném stavů boří i Cisco a HP kraksny).

[zubodravec]

Muze nam nekdo tady z odborniku na sitarinu pomoci , ze bych si objednal placeny zasah.
Provozujeme nekolik let Bird, poslednich pet dnu se stal asi nejaky incident a Bird kazdych 5 minut vyhodi routy pro jednu nasi vetev (neni zakruhovana) a klienti maji na par vterin linku dole, a proc to BIrd dela na to jsem nedokazali prijit. Na siti jsem nedelali zadne zmeny. Trasa je Router, 10GHz P2P, Opticka trasa s cca deseti switchi za sebou, 5GHz P2P Mikrotik (soucast Birdu), Alix (Linux distro) tady dochazi k rozapadani trasy (hlasi ze Router je nedostupny). Pokud tento dotaz sem nepatri tak mne nekamenujte.

[hol]

Zdarec, dotaz z jinýho soudku k OSPF. Mám záložní ADSL linku a potřebuju, aby se na ní otáčela komunikace při výpadku hlavní linky. Dalo by se to "ocostovat" poslední páteří, problém je, že i prvek, kterej vytáčí ADSL má své uživatele. Ti navíc potřebují jít na primární konekt, mají tam veřejnou. Takže pokud udělám ručně statickou DEFGW na ADSL prvku, která by se pak distribuovala, ADSL prvek bude přes ní směrován trvale do O2. To je blbě.
Jak to udělat, aby se prvek u ADSL primárně směroval do hlavního konektu a při výpadku přebral zálohu pro celou síť? Teď to mám scriptovaný, ale zdá se mi divné, že by to nešlo udělat nějak nativně,

díky

[Majklik]

Jen pro zajimavost, jak to skriptuješ?

Jinak čistě OSPF řešení existuje, bohužel nefunguje na ROSu, protože mají nějaké "drobné nedodělky". Vypadalo by zhruba takto:
Defualt routu normáně ručně staticky pošleš do PPPoE s metrikou třeba 200 (route tag zatím ignoruj):
/ip route add dst-address=0.0.0.0/0 gateway=pppoe-out route-tag=666 distance=200
Pak pustíš si OSPF s tím, že nedistribuuje defualt routu (distribute-default=never). Toto řeší první polovinu. Pokud ti dojde defualt routa z OSPF od hlavní brány, nainstaluje se ti s distance 110 a uplatní se ta, když hlavní chcípne, uplatní se statická 200 a místní provoz půjde ven přes ADSL. Problém je, že chceš tu defualt routu poslat ostatním žijícím. To nejde udělat z té jedné ospf instance, protože jakmile zapneš redistribuci a ADSL bude nahozeno, vždy lokálně zvítězí lokální routa nad externím importem z ospf (pevné pořadí priorit ze specifikace OSPF bez ohledu na costy). Proto se musí pustit druhá instance ospf (nutno, aby mělo jiné router id než ta první) a v ní povolíš redistribuci default routy. Pro okolní rotuery to bude vypadat, že místo jednoho fyzického routeru jsou tam 2. Nepovolíš lokální redistribuci mezi instancemi (nefunguje stejně pro lokální routy) a navážeš druhou instanci s okolníma routery přes jiný IP blok (třeba i v jiné VLANě) než ten primární. Druhá instance propaguje ven jen default routu, když chcípne hlavní brána, rozšíří se default brána z druhé instace a zde nastává průser, protože se udělá smyčka mezi první a druhou instancí. Potřebuješ, aby první instance ignorovala default routu z druhé instance (a nevložila tak dynamický route záznam, ale zůstal ten statický v FIB). K tomu slouží ten route tag, ten je určen pro zabránění smyček, když se používá víc instancí nebo předávají routy mezi RIP a OSPF. V 1. instanci se nastaví OSPF-in filtr (/routing filter add chain=ospf1-in action=discard route-tag=666), který bude ignorovat externí routy, mající route tag 666 - a toto v ROS nefunguje, do filtrace se nepředávají všechna body data z ospf... On nefunguje ani ten /ip route add ... route-tag=666, přestože se s ním v DOC chlubí, to se ojebe v ospf-out filtru 2. instance, kde ten tag lze nastavit a správně se pak i šíří (/routing filter chain=ospf2-out add action=accept address-family=ip protocol=static set-route-tag=666).
Takže abend.

Bez skriptování a fungující jiná metoda (a jak to ojebat) např. je, že nepustím druhou instanci OSPF, ale pustím si malej metarouter, do toho zatáhnu ten interface s ADSL modemem, v metarouteru se tak ukončí PPPoE a metarouter s hlavním si udělají ospf spojení přes nějaký vnitřní bridge, tím pádem pro fyzický router je to už vzdálená linka přes OSPF, kde ospf importuje jen default routu a funguje to jak má (a metarouter jen def gw exportuje patřičně naceněnou, aby normálně všude zvítězila hlavní brána).

[hol]

Díky, odpověd je vyčeprávající. Zkusím asi ponejprv ten metarouter, když ten druhej postup v mk nefunguje.
No a jak to máme teď. Netwatch sleduje druhou bránu. Pokud nejde hlavní router, zapne def routu do ADSL. Tím, že to nejde, se zároveň splní druhá podmínka, že se přestane distribuoavat def routa z hlavního stroje, kde je nižší cost. Vlastně ani pořádně nevím, zda to funguje )

name="route-adsl-up" owner="admin"
source=/ip route enable [/ip route find comment=ZALOHA-ADSL]

name="route-adsl-down" owner="admin"
source=/ip route disable [/ip route find comment=ZALOHA-ADSL]

[hol]

Mám další otázky, záměrně jsem to rozdělil od minuléo příspěvku, aby to nezapadlo.

1) potýkáme se s problémem, kdy se nám nespojí po restartu předřazeného routeru routery připojený do hvězdy. Taková ta klasika, kdy jede páteř a do ní jsou na daném hnízdě kabelem připojený další RB411 jako AP. Pomůže restart těch Rb na cípech, jak to tu už popisujete. Jaká je z toho cesta? Kolega část těch routerů změnil do stub area, ale to mi přijde zbytečně komplikovaný, takových RB je hromada. Je pravda, že ne všechny blbnou, ale o to je to snad i horší.
Pak Hapi píše, že nepoužívá backbone 0.0.0.0 ale 0.0.0.1. To by pomohlo? Nebo je to ještě něčím dalším? Router ID nastavený máme u všech )


13:38:57 route,ospf,info new master flag=false
13:38:57 route,ospf,info OSPFv2 neighbor 0.0.120.254: state change from Full to 2-Way
13:39:39 route,ospf,info Database Description packet has different master status flag
13:39:39 route,ospf,info new master flag=false
13:39:39 route,ospf,info OSPFv2 neighbor 0.0.120.254: state change from Full to 2-Way
13:40:20 route,ospf,info Database Description packet has different master status flag
13:40:20 route,ospf,info new master flag=false

a na druhym
13:52:54 route,ospf,info OSPFv2 neighbor 0.0.120.253: state change from ExStart to Init
13:52:54 route,ospf,info OSPFv2 neighbor 0.0.125.2: state change from ExStart to Init
13:52:55 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from ExStart to Init
13:53:00 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from ExStart to Init
13:53:01 route,ospf,info OSPFv2 neighbor 0.0.125.253: state change from ExStart to Init
13:53:46 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from Exchange to 2-Way
13:53:48 route,ospf,info Invalid sequence number
13:53:48 route,ospf,info mine=18842
13:53:48 route,ospf,info received=18841
13:53:48 route,ospf,info Discarding packet: MD5 authentication failed
13:53:48 route,ospf,info source=10.168.120.1
13:54:05 route,ospf,info OSPFv2 neighbor 0.0.122.254: state change from Exchange to 2-Way
13:54:24 system,info,account user admin logged in from 10.168.203.2 via telnet
13:54:28 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from Exchange to 2-Way

Loguje to dokola výše uvedené. Mohu poslat i debug..

2) řesíme věc, kdy máme z jednoho eth portu linku do switche a tam se to pak dělí na 2 MK. Na každej jde jinej rozsah IP, páteř je routovaná. Z nějaký logiky věci chceme, aby vše šlo směrem do routeru 1 a linka 2 byla záložní. Když ale vyrobím dva rozsahy pro OSPF pro jedno rozhranní, tak se mi vytvoří druhý interface dynamicky a tam nenastavím cost. Jak se tohle řeší?

díky

[hapi]

1. skuz u všech přepnout prioritu na 0 a u dvou nech 1 a 2 na jednom subnetu. Tohle se nám stává taky, sere mě to, nikdo to neřeší. Priorita řeší kdo se stane master a kdo backup. Tím že je takhle donutíš se nebudou hádat jak trotlové. "Database Description packet has different master status flag" se řeší snad od v3 a žádný výsledky. Možná by chtělo na ně zatlačit.

2. jo tohle je špatnej koncept. Měl by si to přesunout do stejnýho subnetu, vim, pakárna a člověk to občas potřebuje jinak než by bylo žádoucí ale předejdeš problémům.

osobně mám takovej dojem že první problém se stává když se v síti vyskytuje ten druhej

[hafieror]

ad 2) Nevím jestli jsem to správně pochopil, ale já si dělám v tomto případě záložní linky na vlanách. Blbýmu switchi je jedno co za vlany přes něj teče.

[hapi]

pokud to máš na vlanech tak je to přece jakoby jinej iface ne? tak nad tim iface vytvoříš extra ospf.

[hafieror]

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.

[hol]

díky za rychlou reakci. vezmu to opačně:

2) Vlany mi taky napadly, ale znáte to, člověk si vždycky říká, že to půjde nějak jednoduše. Tím nechci říct, že by byla vlan složitá, spíš je to zas něco navíc

1) tohle budu potřeboval líp vysvětlit. Nastavil jsem ty priority, ale nemyslím, že by to bylo lepší. Možná jsem špatně pochopil, co mám nastavit.[list=][/list]

jan/01/2002 02:00:12 route,ospf,info Discarding packet: no neighbor with this source address
jan/01/2002 02:00:12 route,ospf,info RouterId=0.0.125.254
jan/01/2002 02:00:12 route,ospf,info source=10.168.125.254
jan/01/2002 02:00:17 route,ospf,info Discarding packet: no neighbor with this source address
jan/01/2002 02:00:17 route,ospf,info RouterId=0.0.125.253
jan/01/2002 02:00:17 route,ospf,info source=10.168.125.253
jan/01/2002 02:00:17 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state
jan/01/2002 02:00:17 route,ospf,info state=ExStart
15:56:41 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from ExStart to Init
15:56:41 route,ospf,info OSPFv2 neighbor 0.0.120.253: state change from ExStart to Init
15:56:43 route,ospf,info OSPFv2 neighbor 0.0.125.2: state change from ExStart to Init
15:56:46 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from ExStart to Init
15:56:47 route,ospf,info OSPFv2 neighbor 0.0.125.253: state change from ExStart to Init
15:56:48 route,ospf,info Invalid sequence number
15:56:48 route,ospf,info mine=139675
15:56:48 route,ospf,info received=139674
15:56:48 route,ospf,info Discarding packet: MD5 authentication failed
15:56:48 route,ospf,info source=10.168.120.1
15:56:49 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state
15:56:49 route,ospf,info state=Init
15:56:53 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state
15:56:53 route,ospf,info state=ExStart
15:56:54 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state
15:56:54 route,ospf,info state=ExStart
15:57:33 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from Exchange to 2-Way
15:57:33 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from Exchange to 2-Way
15:57:33 route,ospf,info OSPFv2 neighbor 0.0.125.253: state change from Exchange to 2-Way

[hol]

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.

jo přesně tak jsem to myslel. díky

[hapi]

když si vemeš routery ve stejnym subnetu. Dva z nich se museji stát hlavní pro společný subnet zajišťující komunikaci OSPFka. Pouze OSPFka, né routování. Oni vyřizujou OSPFka mezi všemi routery v subnetu Jeden je tzv DR a druhej BDR. Designated router/backup designated router. To kdo se z 10 routerů na jednom subnetu stane takhle vysokej určuje několik pravidel ale nejhlavnější je priorita. Priorita 0 znamená že se nikdy nestane DR nebo BDR. Čim větší číslo priorita má, tim má router šanci větší stát se BDR případně DR. Mimo jiný se určuje i podle router id a pak taky prej někde i podle IP adresy na iface. Nicméně priorita má nějvětší váhu.

Takže na PTP spojích dávám 0 a 1, na každou stranu. Tím se zajistí že nebudou kecat o tom kdo se čím stane.
U PTMP se dává 1 na AP a na klienty 0. Zase, to samí, navíc bez APčka prostě nemá smysl aby si klient povídaly protože neni konekt atd...

na kabelech se to dává obdobně, ten router co míří do netu má obvykle na sobě 1 a ostatní 0 případně u zakruhování maji routery na kruhu 2 a 1 a ostatní 0.

Taky nezapomeň že když náhodou role DR padne na hardwarově slabí RBčko tak nemusí stíhat kočírovat OSPFko procákem a bude odpojovat routy takže takovým zařízením je lepší rovnou nastavit 0 a je klid. Jednou sem se takhle napálil a stačilo chudinka RB133C

Timhle systémem jsme zajistili to že se to ponapojuje vždy bez těch keců do logu atd..

s tim se taky samozřejmě pojí to, že na každej iface nasadíš exta ospfko, ne že uděláš ospfko na all iface. Pak logicky nemůžeš měnit tyhle parametry pro každý rozhraní.

Pokud by to nebylo zřejmé, priorita platí pro rozhraní, ne pro router jako celek. Na jednom ethernetu může mít prio 0 a na druhym 255. Na jednom eth se nikdy nestane DR a na druhym ano. Nevyjednává se to v celé síti nebo v jednom area ale pouze v jednom subnetu!!! pozor na to. pro každý subnet se volí DR a BDR zvlášť. Je to samostatně fungující komunikace.

[ludvik]

Obecně ničemu nevadí, když se to nechá na defaultu, je vhodné to nastavovat snad leda v případech, kdy je na segmentu těch routerů víc. A vyšší prioritu má mít ten "stabilnější" V každém případě to neřeší to, že se mikrotik občas nesrovná a prostě neroutuje. Mám tu dva, co jim "stažení" 600 rout trvá klidně dvacet minut ... pak pár co neumí default routu (po dvou třech rebootech ano) a zbytek je naprosto v pohodě.

Takže na PTP spojích dávám 0 a 1, na každou stranu. Tím se zajistí že nebudou kecat o tom kdo se čím stane.

U PTMP se dává 1 na AP a na klienty 0. Zase, to samí, navíc bez APčka prostě nemá smysl aby si klient povídaly protože neni konekt atd...

U ptmp se na APčko dává passive-interface, většinou se u klientů OSPF nepoužívá (byť hapi zjevně jo).

[hapi]

no ano, pokud by to všechno chodilo podle papírů tak prioritu řešit ani nemusíme. Jenomže když hází do logu master status flag tak je třeba poladit priority.