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

name="route-adsl-down" owner="admin"

source=/ip route disable

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 route,ospf,info new master flag=false

13 route,ospf,info OSPFv2 neighbor 0.0.120.254: state change from Full to 2-Way

13 route,ospf,info Database Description packet has different master status flag

13 route,ospf,info new master flag=false

13 route,ospf,info OSPFv2 neighbor 0.0.120.254: state change from Full to 2-Way

13 route,ospf,info Database Description packet has different master status flag

13 route,ospf,info new master flag=false

a na druhym

13 route,ospf,info OSPFv2 neighbor 0.0.120.253: state change from ExStart to Init

13 route,ospf,info OSPFv2 neighbor 0.0.125.2: state change from ExStart to Init

13 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from ExStart to Init

13 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from ExStart to Init

13 route,ospf,info OSPFv2 neighbor 0.0.125.253: state change from ExStart to Init

13 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from Exchange to 2-Way

13 route,ospf,info Invalid sequence number

13 route,ospf,info mine=18842

13 route,ospf,info received=18841

13 route,ospf,info Discarding packet: MD5 authentication failed

13 route,ospf,info source=10.168.120.1

13 route,ospf,info OSPFv2 neighbor 0.0.122.254: state change from Exchange to 2-Way

13 system,info,account user admin logged in from 10.168.203.2 via telnet

13 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.

jan/01/2002 02 route,ospf,info Discarding packet: no neighbor with this source address

jan/01/2002 02 route,ospf,info RouterId=0.0.125.254

jan/01/2002 02 route,ospf,info source=10.168.125.254

jan/01/2002 02 route,ospf,info Discarding packet: no neighbor with this source address

jan/01/2002 02 route,ospf,info RouterId=0.0.125.253

jan/01/2002 02 route,ospf,info source=10.168.125.253

jan/01/2002 02 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state

jan/01/2002 02 route,ospf,info state=ExStart

15 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from ExStart to Init

15 route,ospf,info OSPFv2 neighbor 0.0.120.253: state change from ExStart to Init

15 route,ospf,info OSPFv2 neighbor 0.0.125.2: state change from ExStart to Init

15 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from ExStart to Init

15 route,ospf,info OSPFv2 neighbor 0.0.125.253: state change from ExStart to Init

15 route,ospf,info Invalid sequence number

15 route,ospf,info mine=139675

15 route,ospf,info received=139674

15 route,ospf,info Discarding packet: MD5 authentication failed

15 route,ospf,info source=10.168.120.1

15 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state

15 route,ospf,info state=Init

15 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state

15 route,ospf,info state=ExStart

15 route,ospf,info Ignoring Link State Acknowledgment packet: wrong peer state

15 route,ospf,info state=ExStart

15 route,ospf,info OSPFv2 neighbor 0.0.170.254: state change from Exchange to 2-Way

15 route,ospf,info OSPFv2 neighbor 0.0.125.254: state change from Exchange to 2-Way

15 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.

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š.

« Předchozí stránka Další stránka »