OSPF - Podivne Chovani

[okoun]

u mě se ten problém stane když z obrázku router R1 je zapnutý, R2 a R3 v důsledku výpadku napětí je vyplý. Když se náhodou R3 nahodí dříve jak R2 tak je zle. Když se ale nahodí dříve R2 tak je to OK. Mám dojem jako by někde něco vypnutého v synchonizaci, prostě jako sousední je vidět ale nekomunikují mezi sebou, jeví se to jako by měl načtené všechny routy, ale někdy jich má 20% někdy 45% někdy 80% atd, někdy i 100%, někdy chybí defaultní routa. Pomůže reset či zakázání a obnovoení instance.

map.jpg (17.3 KiB) Zobrazeno 1573 x

[kolousekkk]

tak to netusim,predpokladam ze mas spravne nastaveno co jsme tady resili, tzn nikde na siti nemas dve stejne router id,pak tedy pokud mas ruco nastavene tak jen ty interface kam chces ospf sirit,prioritu bych nechal default pokud nemas uzavreny kruh, a pak samozrejme spravne nastaveny cost. Neber to jako rady od profika, ber to tak jaky mam ja nazor a v podstate jak to mam ja. Sam sem byl bezradnej ale po delsi dobe sem to tahle vyresil. A jeste se blbe zeptam kdyz mas ospf i nterface automaticky tak ti to taky dela? A na jake jsi verzi? ja abych pravdu rekl mam verze ruzne, rozhodne ne vsude stejne. Ridim se tim co finguje ok na to nesahat takze kdyz me to jede na starsi verzi a splnuje vse co ma, nedavam nove. Vim ze kolega tohle vyresil tak ze tam dal nejakou verzi 4.xx to se muzu zeptat. Ale kdyz to pak zaclo z niceho nic u me, ja sem tohle reseni delat nechtel a tak jsem se stim nakonec popral tahle a moc diky za to tem co mi v tomhle vlakne poradili.

[Majklik]

A řve to něco do logu při tomto stavu něco?
Jinka k těm routám, psotřehl jsme na některých verzích ROSu, že nesouhlasí to, co vypisuje winbox pod IP routes s realitou, z příkazové řáky /ip route print to bylo OK. A je jedno, zda routy šly z OSPF nebo BGP.
A pokud jsou R1-R2 a R2-R3 point-point linky, respektive jen dva routery proti sob na lince, tak přepni network type u interfaces na obou stranách na point-to-point a nějkaé priority dál tě trápit nemusí.
Když to načte půlky rout, jak hlásí stav vzdáleného routeru ve state v neighors.

V OSPF (a nejen v něm) má ROS nasekáno chyb řadu.

[kolousekkk]

aaa zdravim Majklika a jeste jednou diky za help v mem problemu.

[okoun]

A řve to něco do logu při tomto stavu něco?
Jinka k těm routám, psotřehl jsme na některých verzích ROSu, že nesouhlasí to, co vypisuje winbox pod IP routes s realitou, z příkazové řáky /ip route print to bylo OK. A je jedno, zda routy šly z OSPF nebo BGP.
A pokud jsou R1-R2 a R2-R3 point-point linky, respektive jen dva routery proti sob na lince, tak přepni network type u interfaces na obou stranách na point-to-point a nějkaé priority dál tě trápit nemusí.
Když to načte půlky rout, jak hlásí stav vzdáleného routeru ve state v neighors.

V OSPF (a nejen v něm) má ROS nasekáno chyb řadu.

routy tam nejsou zařízení kolikrát není ani vidět v dohledu, protože kolikrát nemá default routu, kontroluji to jak SSHčkem tak winboxem.

"Když to načte půlky rout, jak hlásí stav vzdáleného routeru ve state v neighors."
To mohu zjistit, ale vlogu právě nic není je to tam jako by se nic nestalo jako by to bylo v cajku.

[hapi]

teď mi došlo že to samí se děje jednomu známému. Taky se sem tam prostě nenačtou routy a je třeba restart. Podle mě tam bude něco někde zakopanýho a nemusí to bejt tam kde se to nenačte ale klidně úplně někde jinde na síti. Někde na síti bude něco špatně nastavený nebo nebude správně procházet broadcast nebo něco.

[Majklik]

Polovina podobných případů je, že mám na síti 2x stejné router id. A může trvat dlouho, ne se to někde projeví (záleží to na pořadí nahození jendotlivých linek, pokud si sendou dobře, tak se ten prblém může dlouho maskovat).
V podstat jde o to, že router vysílá všem routerům v OSPF pod svým id informace o svých změnách. Pokud vyílají dva orutery pod stejným od, tak to pak zlbne, že jeden shodí přenos druhému někde v půlce...
Pokud mám síť jen jednu areu, tak slušný příznak toho stavu je, že kdy se podívám do routers / ospf / lsa, dám utřídit podle originátor, tak obvkyle sekvenční čísla pro jeden zdroj jsou tak nějak vedle sebe a i stáří těch dat. Pokud něco extrám ustřeluje, tak je to buď příznak, že ta linka je totální držák (nízké seq číslo, vesoké stáří) neustále padá (age je nízké) nebo to pochází z jiného routeru se stejným router id...
Pokud si to utřídím podle času, tak jako nejmládší, pokud něco pořád přeskakuje, tak kolem routeru s daným router id bude něco nestabilního.

Pokud je multiarea síť a nejlépe se stuby, tak je trošku horší pro hledání (zvláště pokud zdojené router id bude v různých/vzdálených areí).

Pak jsou další možné příčiny od blbosti typu, e mám omylem v routeru zavlečen nějaký filtr, chyba ROS, ...
Je dobré se podíva,t že orutovací tabulka ospf procesu je ve shosě s tou aktivně používanou /ip route kontra /routing ospf route.

[kolousekkk]

take se priklanim k ID routeru, ja muzu potvrdit ze jsem opravdu mel na dvou routerech id 0.0.0.0 bohuzel to zapomel kolega prepsat, cili nevylucuji ze nepomohlo i to prepsani

[Majklik]

id 0.0.0.0 znamená, že router si sám zvolí své router id na základě lokálníh IP adres.
Je pravda, že pokud je ospf aktivní a přepíšu mu pak ručně router id, tak to občas nedopadne dobře, je třeba ho disablovat/povolit.

Jiný častý problém je, že sousední linky se nedostanou do state full sync - plně předané databáze vektorů. Pak to blbne také, příčin může být povícero (počínaje, že nemám přesně identické nastavení parametrů peera pro dané iface proti sobě, ztrácí se multicast, moc natvrdo nastavené dead/hello/bfd, nat prznící ospf pakety, ...). Tohle je obvkyle vidět, že neustále roste pro daného peera přes danou linku v neighbors čítač state changes.

[okoun]

Polovina podobných případů je, že mám na síti 2x stejné router id. A může trvat dlouho, ne se to někde projeví (záleží to na pořadí nahození jendotlivých linek, pokud si sendou dobře, tak se ten prblém může dlouho maskovat).
V podstat jde o to, že router vysílá všem routerům v OSPF pod svým id informace o svých změnách. Pokud vyílají dva orutery pod stejným od, tak to pak zlbne, že jeden shodí přenos druhému někde v půlce...
Pokud mám síť jen jednu areu, tak slušný příznak toho stavu je, že kdy se podívám do routers / ospf / lsa, dám utřídit podle originátor, tak obvkyle sekvenční čísla pro jeden zdroj jsou tak nějak vedle sebe a i stáří těch dat. Pokud něco extrám ustřeluje, tak je to buď příznak, že ta linka je totální držák (nízké seq číslo, vesoké stáří) neustále padá (age je nízké) nebo to pochází z jiného routeru se stejným router id...
Pokud si to utřídím podle času, tak jako nejmládší, pokud něco pořád přeskakuje, tak kolem routeru s daným router id bude něco nestabilního.

Pokud je multiarea síť a nejlépe se stuby, tak je trošku horší pro hledání (zvláště pokud zdojené router id bude v různých/vzdálených areí).

Pak jsou další možné příčiny od blbosti typu, e mám omylem v routeru zavlečen nějaký filtr, chyba ROS, ...
Je dobré se podíva,t že orutovací tabulka ospf procesu je ve shosě s tou aktivně používanou /ip route kontra /routing ospf route.

ahoj, mohl bych ti dát demo na hlavní GW že by ses kouknul jestli tam nevidíš chybu?

[Majklik]

Třeba jo.

Jinak, myslím, že mi došlo, že hodně lidem uniká ještě jeden detial. Dle těch rad ohledně nastavování priorit interfejsů pro volbu DR, BDR. Jde o oblíbenou hlášku "Database Description packet has different master status flag". Ta je buď způsobena chybou ROSu, která se táhne od 3.x nebo okolnistmi.
Vliv té chyby jde ovlivnit/potlačit správným nastavením tak, aby designated router byl zároveň i master pro všechny spojení. Jde o dvě věci. Mějme ethernet segment se třemi routery a prioritami:
priority RID
0 1.1.1.1
1 2.2.2.2
0 3.3.3.3

Při takovémto nastení, až se všechny routery uslyší, nastává volba DR routeru (BDR nebude existovat). Na základě priorit se jím stane ten 2.2.2.2.
routery 1.1.1.1 a 3.3.3.3 pak komunikují a mění data jen s 2.2.2.2 a ne spolu.
Dále následuje volba stavu master-slave na těchto spojích k DR, každý volí samostatně jen na základě router ID, kdy vyšší router id je vždy master. Takže to dopadne:
1.1.1.1(slave)<->2.2.2.2(master)
3.3.3.3(master)<->2.2.2.2(slave)
Jen naster má právo měnit sekvenční čísla v dané výměně. A vypadá to, že ROSu to občas ujede a DR pošle blbě svůj status protistraně, při takovéto konfoguraci třeba routeru 1.1.1.1 pošle, že je slave omylem a už to letí k zemi.
Takže je žádoucí to nastavovat tak, když už šaháte na priority, aby nejvyšší prioritu pro volbu DR/BDR/other něl ten router s nejvyšším router id (nebo naopak, aby DR pro všechna pojení držel jen slave status), takže v tomto připadě:
priority RID
0 1.1.1.1
0 2.2.2.2
1 3.3.3.3
a master slave dopadne:
1.1.1.1(slave)<->3.3.3.3(master)
2.2.2.2(slave)<->3.3.3.3(master)

Pro větší síť to není soprocentní, ale dost to dokáže vyelimitovat blbě poslaný master flag. Pokud je routerů víc a hraje se na DR/BDR/other, tak platí to stejné, DR nejvýšší RID, pod ním obvyklý BDR a pak ostantí, opět, ať vzdat DR-BDR je master-slave a vztahy DR-other a i BDR-other je stále master-slave.

Toot platí pro broadcast/nbma linky, Kde používáte PtP, tak je to fuk (i na point-point linkách se volí master-slave dle toho RIDu, vynechává se to DR/BDR).

A jinak, pro utěšení. I Cisco má v sobě podobného démona ve vzdáleně podobné variantě. Tam ta deprimující hláška má jen tvar %OSPF-4-BADLSA..... Tato hláška se samozřejmě vyskytuje jen zcela ojediněle ve zcela exotických případech a pokud ji neodstraní shození/nahození routeru, tak máte kontaktovat support.

[okoun]

poslal jsem ti PM