ospf časování a wifi

[ludvik]

RSTP honím i přes wifiny Ale za a) jen přes UBNT a za b) už to není v kolečku, takže svým způsobem nehoním ... Důležité je samozřejmě po optikách a profi spojích (10-80GHz).

ptp typ dělal jednu nemilou věc (a nejsem sám kdo na to přišel) - sice na ROSu fungoval, ale do prvního rozpadu. Pak už prostě sám nenajel.
Ale je faktem, že to na MK musím čas od času dělat kdekoliv, bez závislosti na typu spoje. Prostě komunikuje, neighbor stavy jsou ok a stejně nejsou routy ... Víc než jeden pár neighborů na segmentu používám minimálně a když se toto stane, tak tam kde to jsou jen dva. Takže porůznu zakazuji rozhraní, měním priority, rebootuju.

Nu, každý svého průseru strůjcem....

To honíš RSTP/MSTP i přes wifiny?
No, s redistribute connected/static mám celkem nepříjemné zkušenosit u ROSu, externí routy se počítají až v posledním kole a vypadá to, že když je external rout moc, tak zapomene občas ROS některé započítat, pokud je external rout jen menší část, tak OK. takže s eraději snažím to OSPF dotáhnout až na konec a vše posílat jako součást nějaké arei. Samozřejmě jsou věíc, kde to nejde (redistribuce z BGP, RIP, statické routy na posledním hopu na zákoše, ...), ale snažím se tomu vyhýbat.

To podobně platí o broadcast typu sítě, občas se pěkně sekne. Point-to-point typ mám zkušenost, že je nejjendodušší a hrozí minimum seků. U broadcast si musím vychytat vztah router id, DR, BDR tak, aby v kombinaci s master/slave LSA rolí nešly proti sobě na různé klienty, jinak to pak padá na oblíbeném špatný master flag.

Každý si nabije držku na něčem jiném.

[hapi]

když dám ptp tak musim na každý straně nastavit ip protistrany nebo ne?

Ne, u point-to-point se protistrany neuvádí. Ty se vyjmenovávají v případě typu NBMA, proto je také uvádění protistran schováno pod "/routing ospf nbma-neighbor".

Jinak přístup Ludvíka není důvod odsuzovat, zkrátka volí KISS princip - keep it simple, stupid - žádné vylomeniny, když opici řekne zapni OSPF, tak to zapne a většinou se to pak chytí a nemusí lovit tuny parametrů, jiní jedou ještě jednodušeji, že to vše jedou staticky (včetně kruhových sítí, kde pak kruhy při selhání přehodí ručně), ... Každý má tu svoji pravdu.

no jo, vidíš, já používám jenom broadcast a na ptp spojích nastavuju priority 0,1 a zdá se že je klid. Víc mě štve, že na sajtech kde je víc routerů ve switchy tak když chcípne DR tak se sice přehodí na BDR jenomže to neni vždy bezvýpadkově a se sestavujou znova a když naběhne DR kterej má největší prioritu tak se to znova nepřepočítá aby se zase stala DR.

[Majklik]

RSTP honím i přes wifiny Ale za a) jen přes UBNT a za b) už to není v kolečku, takže svým způsobem nehoním ... Důležité je samozřejmě po optikách a profi spojích (10-80GHz).

ptp typ dělal jednu nemilou věc (a nejsem sám kdo na to přišel) - sice na ROSu fungoval, ale do prvního rozpadu. Pak už prostě sám nenajel.
Ale je faktem, že to na MK musím čas od času dělat kdekoliv, bez závislosti na typu spoje. Prostě komunikuje, neighbor stavy jsou ok a stejně nejsou routy ... Víc než jeden pár neighborů na segmentu používám minimálně a když se toto stane, tak tam kde to jsou jen dva. Takže porůznu zakazuji rozhraní, měním priority, rebootuju.

Doufám, že ten RSTP není otevřen až na port, kde jsou koncoví zákoší. Jsem také v jedné takové síti připojen a jeden zákoš si tam inteligentně připojil switch, který zvítězil ve volbě rstp root bridge a pěkně to tu síť složilo - aneb nepoužití funkce root guard ve switchích, co to umí a ROS to bohužel ani neumí...

Co se týče, tak já si zase podobně nabil čumák u default, že v řadě případů nedoběhlo vyjednávání do uspojkojivého stavu, aby se routery začaly spolu bavit. Inu, každý má svého démona, na kterým se vydusil.

Jinak ten stav, že routery se baví, pišou OK stav se sousedy, nerostě počet state changes a jou pěkne ve full sync. V "/ip route" nic není, v "/routing ospf routes" také nic (odtud se to přenáší do systémové routovací tabulky v /ip route), ale v "/routing ospf lsa" je něco, co vypadá jako kompletní LSA databáze, jenom z ní ty routy nespočítal.... Netřeba reboot, obvykle stačí stop/start OSPF instance.

Takž eklidně v malých instalacích, kde je pár routerů a nechce se mi mlátit routy ručně, tak si pustím starý dobrý RIPv2. V jednoduchosti je síla (samozřejmě, občas opět s poprzněným časováním níže, než základní update/timeout timer 30 s / 3 min ).

[Majklik]

no jo, vidíš, já používám jenom broadcast a na ptp spojích nastavuju priority 0,1 a zdá se že je klid. Víc mě štve, že na sajtech kde je víc routerů ve switchy tak když chcípne DR tak se sice přehodí na BDR jenomže to neni vždy bezvýpadkově a se sestavujou znova a když naběhne DR kterej má největší prioritu tak se to znova nepřepočítá aby se zase stala DR.

Jenom při použití default a priorit 0 a 1 neodstraníš ten wait timeout úplně. Odstraníš ho, pokud dojde k restartu připojení toho routeru s prio 0, ten ví, že nikdy DR nebo BR nebude a jak uslyší nějaký hello paket obsahující DR, BDR, tak hned komunikuje a nepřemýšlí. Pokud dojde ke startu toho routeru s prio nenulovou, tak tam se čeká, že může být DR nebo BDR a běží wait timeout na zhjištění, jak to na segmentu vypadá a protože bude slyšet jen toho s prio 0, který bude mít v hello jako DR, BDR 0.0.0.0, tak bude čekat ten dead interval, než se prohlásí za Boha daného segmentu.

Ohledně toho, že když zdechne DR, tak na jeho pozici se přesune BDR (a pak případně proběhne volba nového BDR), tak je to normální, že když se pak objeví router s vyšší prioritou, že se nestane DR. Ta priorita má význam zbožného přání. Pokud v dané chvíli není DR, BDR zvolen, tak se volí dle priorit, zvítězí ten s nejvyšší prio, pokud pak časem se objeví jiný s vyšší prio, tak nepřebíjí stav, ale čeká. Takže až zdechne DR, BDR povýší na DR a ten s nejvyšší prio se zvolí do role BDR. Tak zní kostelní pořádek.

[ludvik]

Používám to, co se hodí. Mikrotik/routerboard se do role access switche nehodí. Ať už tím root-guardem, nebo třeba loopback-detection neumí (o dhcpsnoopingu nemluvě). A v poslední době začínám vyžadovat i ra-guard. K tomuhle dojde jednou každá síť ...

Doufám, že ten RSTP není otevřen až na port, kde jsou koncoví zákoší. Jsem také v jedné takové síti připojen a jeden zákoš si tam inteligentně připojil switch, který zvítězil ve volbě rstp root bridge a pěkně to tu síť složilo - aneb nepoužití funkce root guard ve switchích, co to umí a ROS to bohužel ani neumí...

[hapi]

no jo, vidíš, já používám jenom broadcast a na ptp spojích nastavuju priority 0,1 a zdá se že je klid. Víc mě štve, že na sajtech kde je víc routerů ve switchy tak když chcípne DR tak se sice přehodí na BDR jenomže to neni vždy bezvýpadkově a se sestavujou znova a když naběhne DR kterej má největší prioritu tak se to znova nepřepočítá aby se zase stala DR.

Jenom při použití default a priorit 0 a 1 neodstraníš ten wait timeout úplně. Odstraníš ho, pokud dojde k restartu připojení toho routeru s prio 0, ten ví, že nikdy DR nebo BR nebude a jak uslyší nějaký hello paket obsahující DR, BDR, tak hned komunikuje a nepřemýšlí. Pokud dojde ke startu toho routeru s prio nenulovou, tak tam se čeká, že může být DR nebo BDR a běží wait timeout na zhjištění, jak to na segmentu vypadá a protože bude slyšet jen toho s prio 0, který bude mít v hello jako DR, BDR 0.0.0.0, tak bude čekat ten dead interval, než se prohlásí za Boha daného segmentu.

to sem myslel jako řešení kvůli master status flagu.

[Majklik]

Pokud chceš minimalizovat problém s master flagem, protože to je nějaký bug v ROSu, že blbě posílá ten stav občas do jiného spojení, tak na segmentu, kde mám třeba 5 routerů v defualtu s tím, že tři mají prio 0, jeden 10 a jeden 5, tak abych měl naději na pěvně danu pozici DR a BDR, tak musí pro Router ID RID1 až RID5 platit toto:
RID1 - prio 10 (takže ideálně role DR), RID2 - prio 5 (ideálně role BDR), RID3 až RID5 - prio 0.
A hodnotově RID musí platit:
RID1>RID2, RID2>{RID3, RID4, RID5}.
A ono to platí z daného routeru i vůči okolí do dalších linek, že router na všech směrech by měl být master nebo slave ideálně.

[hapi]

přesně takhle to používám a zatim je dloooouho klid. Taky jsem dospěl ke stejný konfiguraci. Jinak to nešlo než těm blbounům na tvrdo říct kdo je kdo.