ospf časování a wifi

okoun

Ahoj, chtěl bych se vás zeptat, jestli používáte na wifi spoje nějaké jiné časování ospf než je to defaultní na MK, díky.

ludvik

Ne. Pokud je to potřeba, je ten spoj špatný ...

hapi

cože? to je ale blbá odpověď. Co třeba když chci rychlejší načítání rout po obnově? co když chci rychlejší odpojení nefunkční části nebo rychlejší přepnutí kruhu? rychlejší načtení kruhu? atd...

ludvik

Proč bych to proboha potřeboval? Ono to je rychlé i ve standardním nastavení ... a pokud tam je MK, můžeš použít i BFG, nebo jak tomu říkají.

Pokud potřebuji něco opravdu extra rychlého, nebudu používat OSPF. Jsou i jiné technologie. Ale v našem prostředí - proč?

Pokud potřebuji rychlejší OSPF, rozkouskuji síť do area ... nejlépe stub. Když to vymyslím dobře a nepřeženu to, opět nějaký čas lze ušetřit.

Pokud potřebuji rychlejší OSPF, tak nejspíš proto, že mi to někde habruje a tím pádem platí ta moje věta - spoj je špatný a nemá tam co dělat.

Nevím jak ty, já stavím síť tak, aby se nikde nic neměnilo ... a když se mi někde něco fyzicky porouchá, opravdu mě těch pár vteřin nezajímá.

A co je snad nejhorší - jak máš někde nějaký nestandard, musíš o tom vědět a nezapomenout na to (např. při nějaké výměně HW). Jinak strávíš půlden hledáním chyby někde jinde ...

hapi

dej si voraz jo?

co když ladíš ptp spoj? ty čekáš 20 sekund než se to zase napojí a to v ideálnim případě. Já mám hello intervali na 2 sekundy takže do 10 sekund v pohodě to zase jede. Já nehodlám čekat 40 sekund než vyhnije routa aby se okruh nahodil druhou stranou. Na BFG ti kašlu. Nebudu do toho míchat cizí věci. Ty čísla maji smysl a pokud vim, tak na linuxu maji úplně jiný hodnoty.

Jestli nemáš v OSPFku jiný časování tak prosimtě neodpovídej. A hlavně ne tou blbou odpovědí kterou si odpověděl jako první.

ludvik

Voraz si dej ty. Neříkej o něčem, že je to blbá odpověď jenom proto, že ty to prostě děláš jinak.

Ptal se, jestli to někdo používá ... já říkám proč to nepoužívat. Ty koukám víš prd a víš to jistě. Nechceš do toho míchat cizí věci (ale máš jen mikrotik ...) ... ale default hodnoty si měníš. Když ladím ptp spoj, ladím ten ptp spoj. Routy ze zbytku vzdáleného routeru mě v tu chvilku nezajímají, zajímá mě jen ten jeden spoj. A ten jede hned, jak se to po rádiu spojí. A ladím ho obecně řečeno jen jednou ... Není to důvod, proč si rozhasit konfiguraci sítě zbytečně mimo výchozí hodnoty.

Když budou na neighborech jiné hodnoty, nebude to fungovat správně ... linux (quagga) má stejné defaultní hodnoty.

A přesně opačná rada se dává, když je wifi spoj hodně špatný. Je to z dob počátků wifin ... aby ti to nelítalo sem tam. Vyšší dead-interval. Ale stále platí to, co říkám - potřebuješ-li to změnit, je něco špatně na té síti.

----

takže pokud chce hapi korektní odpověď:

1) chceš-li ušetřit 10 sekund při ladění něčeho, sniž si hello a dead interval. Hapiho důvod.

2) chceš-li ušetřit hodiny zbytečné práce v budoucnu, nesahej do toho. Můj důvod.

Vyber si.

majklik

Hello/dead 10/40 sekund je snad všude - ROS, Cisco, Juniper, ..., a to asi proto, že tyto hodnoty jako příklad uvádí původní RFC specifikace pro OSPFv2 (respektive jako příklad navrhuje 10 sekund pro lokální sítě a 30 sekund pro wan sítě, dead je pak 4x hello). A tak to asi zůstalo hodně dlouho, každý to mlátí jako default hodnoty, než přišel update pro subsekundový hello (což ROS nepodporuje) a potom asi to přešlo ve prospěch univerzálního BFD, který má výhodu, že jedna komunikace hlušiny na lince je použita pro víc protokolů současně. U ROSu umí BFD použít OSPFv2/3, BGP (nefunguje korektně jen multihop BFD, jako vše v ROSu, co používá UDP) a je slíbena podpora pro LDP.

Pokud chci urychlit hlavně start, tak je nejvíc možná ovlivním správnou volbou typu linky. "Startovací časový zabiják" je volba designated a backup routeru na segmentu, kdy po naběhnutí běží wait timeout (který je rovný dead intervalu), kdy routery vysílají jako DR/BDR 0.0.0.0, aby se vzájemně představily a pak začíná volba. Takže pokud mám jen dva routery na lince proti sobě, volím typ linky point-to-point, volba DR/BDR se nekoná a hned se spolu baví (ušetřím wait timeout). Pokud mám na segmentu víc routerů a ze zapojení je jasné, že selhání jednoho uprostřed znamená nefunčnost všeho (ethernetové RBčko propojující přes bridge RBčka typu 911 jako sektory, uplink), tak zde se použije režim broadcast, ale tomu střednímu routeru dám prioritu 100, ostatním 0, tím je automaticky zvoleno a opět se na nic nečeká, že ten jeden je DR a ostatní se s ním hned baví i bez wait po naběhnutí.

A rychlé sejmutí dělá dneska to BFD, pokud ho potřebuji...

Jinak, když na to šahám, tak na na wifi like linkách obvykle hello/dead 4/20 nebo 3/12. Záleží na účelu, zda mám kruh a chci přepnutí na zálohu relativně rychle nebo je to slepá větev a ospf jen plní jen roli distribuce rout a nechci, ať to padne při každém škobrtnutí.

okoun

já asi zkusím to co psal majklik, tedy na backbonu, kde to máme kruhované trochu změním čísla, tedy trochu přiostrým v rychlosti a na těch odhlehlých areas nechám default

hapi

..

no vidíš, a majklik ti to vytřel. My používáme agresivnější časování. Obzvláště na kruhu se to hodí což evidentně okoun chce. hello/dead máme 5/21.

hapi

Pokud chci urychlit hlavně start, tak je nejvíc možná ovlivním správnou volbou typu linky. "Startovací časový zabiják" je volba designated a backup routeru na segmentu, kdy po naběhnutí běží wait timeout (který je rovný dead intervalu), kdy routery vysílají jako DR/BDR 0.0.0.0, aby se vzájemně představily a pak začíná volba. Takže pokud mám jen dva routery na lince proti sobě, volím typ linky point-to-point, volba DR/BDR se nekoná a hned se spolu baví (ušetřím wait timeout). Pokud mám na segmentu víc routerů a ze zapojení je jasné, že selhání jednoho uprostřed znamená nefunčnost všeho (ethernetové RBčko propojující přes bridge RBčka typu 911 jako sektory, uplink), tak zde se použije režim broadcast, ale tomu střednímu routeru dám prioritu 100, ostatním 0, tím je automaticky zvoleno a opět se na nic nečeká, že ten jeden je DR a ostatní se s ním hned baví i bez wait po naběhnutí.

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

majklik

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. :-)

ludvik

Znám síť, co jede staticko-dynamicky. Takové nascriptované OSPF :-) A není to vůbec malá síť ...

Mimochodem opice zapne redistribute connected a jde od toho. Já toho dělám přeci jenom víc :-) Jenom prostě dodržuji pravidlo, že defaultní hodnoty mi stačí. Za ty starosti mi to nestojí. A druhé mimochodem - klidně je možné, že mi stačí proto, že to důležité je switchované a tam MSTP/RSTP.

Ty ostatní (ne-broadcast) možnosti mi dělaly jenom problémy. Chová se to typicky mikrotikácky. Dokonce i na quagga ... Ale je to už pár let, co jsem to zkoušel a zavrhnul.

majklik

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. :-)

okoun

jo ale zapoměl si dodat že u poin-to-point a šifry MD5 může být problém :)

majklik

Jo, ale to je výjmečně problém by OSPF design a ne soukromá úchylka ROSu. Takže když se na to narazí, tak nezbývá, než autorizaci MD5 nepoužívat na dané lince (nebo z toho udělat default s prioritama 0 a 1).

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

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

Další stránka »