Dobry den,
pravdepodobne se to tady nekde resilo, ale nemuzu to najit, tak Vas chci pozadat o radu. Mam topologii napr. A-----B a v bode B se to rozdeluje na vice smeru (napr. C, D a E). Vsude mam nastavene ospf, ale to co chci docilit je, aby napr. v routovaci tabulce u E nebyly routy, ktere se tykaji bodu D. Jde tohle nejak nastavit a pokdu ano, poradite mi jak? Dekuju.
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Nastavení OSPF
pepulis píše:Dobry den,
pravdepodobne se to tady nekde resilo, ale nemuzu to najit, tak Vas chci pozadat o radu. Mam topologii napr. A-----B a v bode B se to rozdeluje na vice smeru (napr. C, D a E). Vsude mam nastavene ospf, ale to co chci docilit je, aby napr. v routovaci tabulce u E nebyly routy, ktere se tykaji bodu D. Jde tohle nejak nastavit a pokdu ano, poradite mi jak? Dekuju.
Tak jsem nasel neco zde - viewtopic.php?f=5&t=4106&start=60, ale nejsem si uplne jisty tim nastavenim. Nema to nekdo v configu?
0 x
Tak to musis E a D udelat jako samostatnou area (pokud je jen jedna cesta tak stub area) misto backbone a nebudou se ti tam propagovat.
0 x
hocimin1 píše:Tak to musis E a D udelat jako samostatnou area (pokud je jen jedna cesta tak stub area) misto backbone a nebudou se ti tam propagovat.
A tu areu musim udelat na vsech routrech, ktere jsou za tim D a E? Proste od bodu B je to hvezda, ktera je o nekolika dalsich spojich: A---B---E-----E1-------E2-------E3 a A----B-----D-------D1-------D2--------D3.
A jeste da se nejak minimalizovat doma nacteni rout po vypadku? Tj. pri vypadku napr. D trva cca 40s nez se ty routy rozdistribuji a teprve pak zacne vse slapat.
Diky.
0 x
K čemu ti to je dobrý? Stejně tam budeš mít default route. Takže ti to tam pošle router B. Pokud nechceš, aby to spolu komunikovalo, musíš to odfirewallovat.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
ludvik píše:K čemu ti to je dobrý? Stejně tam budeš mít default route. Takže ti to tam pošle router B. Pokud nechceš, aby to spolu komunikovalo, musíš to odfirewallovat.
Z duvodu nejakeho zakazani komunikace to nedelam, jen tech routru je postupne vic a tak jsem si rikal, ze v tom udelam poradek. Mam segmenty rozdelene po /29 a diky tomu je v ip routes 455 items, tak jestli to neni uz moc.
0 x
Momentálně jsem na 660 ... A jsou sítě s tisícema. Ale je fakt, že jsem musel vyhodit L3 switch, který uměl jen 512 ... Jinak to ovšem ničemu nevadí.
Pro omezení velikostí a vlastně i náročnosti jsou Stub Area, jak psal hočimin. Ale to se dělá na routeru B (a pak následně C, D, ...) Pokud bude mít ta area jen jeden styk s backbone (tedy jen na B - což musí), bude tam v routovací tabulce jen to co je v té area a pak defaulta. Plus tam lze (opět na B) dělat sumarizace, pokud to má nějaký smysl - pak omezíš velikosti všude.
Ale pokud nelze ušetřit sumarizací, vykašlal bych se na to. Akorát to komplikuje konfigurace. Spíš z lidského hlediska, než technického.
Bych řekl, že někdo, kdo má 450 routovacích záznamů, že o tom už něco ví
Pro omezení velikostí a vlastně i náročnosti jsou Stub Area, jak psal hočimin. Ale to se dělá na routeru B (a pak následně C, D, ...) Pokud bude mít ta area jen jeden styk s backbone (tedy jen na B - což musí), bude tam v routovací tabulce jen to co je v té area a pak defaulta. Plus tam lze (opět na B) dělat sumarizace, pokud to má nějaký smysl - pak omezíš velikosti všude.
Ale pokud nelze ušetřit sumarizací, vykašlal bych se na to. Akorát to komplikuje konfigurace. Spíš z lidského hlediska, než technického.
Bych řekl, že někdo, kdo má 450 routovacích záznamů, že o tom už něco ví
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
20.000 rout v OSPF na MKčku není problém (resketive je, ale řešitelný). Teda pokud to je na něčem slušném. Propože jednak jde pak trochu už o zabranou RAM a pokud se ta síť hejbe, tak CPU začne být na nervy, když dochází moc často na přepočítávání grafu, dokáže na tom pak úspěšně trávit 100% CPU trvale.
500 rout je nic.
Řešení je možných vícero, buď se na to vykašlat, pár rout nebo klasické je použití těch stub areí, kdy A-B je backbone a ty spoje B-C, B-D, ... B-X začu definovat jako samostatné stub arei. Pak dosáhnu, že v rámci stub arei budou komplet jen routy té arei plus default routa. Pozor jen, že v stub arei nemůžu používat externí routy. Pokud potřebuji externí routy, musím použít area typu nssa, pak se musí změnit topologie, a backone to tahat až na ty rotuery C, D, ..., X a nssa area začínají až na ty linky dál. Je to chyba v MK, jeden router neumí korektně ukončovat víc NSSA areí (respektive umí do backbone importovat externí routy jen z jedné NSSA arei, a na ostantí kašle - náprava slíbena v dalších ROS verzích).
NAsazneí sumarizací je další level, který pak slouží spíše k limitaci rout šířených do backbone, když osatní arei jsou stuby.
Samozřejmě všechny routery uvnitř dané arei musí mít nastaveno, že patři do dané arei daného typu, takže area tam musí být definovaná i dané networks, jinak to nepojede.
Ten čas a rychlost než se to dá dohromady ovlivňuje, jak máš nastaveno časování na linkách, po jaké době to detekuje výpadek a podobně (helloo/dead intervall).
Další možnost je udělat v bodě B víc instancí OSPF. Jenda isntance je A-B, druhá bude směr k C a další k D. Pomocí filtru se nastaví, že routy z isntance B-C, B-D, ... se předávají do in stance A-B. Pak každá větev je nezávislá a samostatná. Jenom v té A-B bude strašit velká majorita externích rout (naimportovaných z těch částí C, D, E, ...), což MK opbčas špatně nese. Vyhoda je, že se to konfiguruje jen na B a na zbytek nemusíš šahat. Má to i své nevýhody, kdyby později došlo na kruhování a další voloviny (ale to stjené platí i pro stuby, musím to pak předělat).
500 rout je nic.
Řešení je možných vícero, buď se na to vykašlat, pár rout nebo klasické je použití těch stub areí, kdy A-B je backbone a ty spoje B-C, B-D, ... B-X začu definovat jako samostatné stub arei. Pak dosáhnu, že v rámci stub arei budou komplet jen routy té arei plus default routa. Pozor jen, že v stub arei nemůžu používat externí routy. Pokud potřebuji externí routy, musím použít area typu nssa, pak se musí změnit topologie, a backone to tahat až na ty rotuery C, D, ..., X a nssa area začínají až na ty linky dál. Je to chyba v MK, jeden router neumí korektně ukončovat víc NSSA areí (respektive umí do backbone importovat externí routy jen z jedné NSSA arei, a na ostantí kašle - náprava slíbena v dalších ROS verzích).
NAsazneí sumarizací je další level, který pak slouží spíše k limitaci rout šířených do backbone, když osatní arei jsou stuby.
Samozřejmě všechny routery uvnitř dané arei musí mít nastaveno, že patři do dané arei daného typu, takže area tam musí být definovaná i dané networks, jinak to nepojede.
Ten čas a rychlost než se to dá dohromady ovlivňuje, jak máš nastaveno časování na linkách, po jaké době to detekuje výpadek a podobně (helloo/dead intervall).
Další možnost je udělat v bodě B víc instancí OSPF. Jenda isntance je A-B, druhá bude směr k C a další k D. Pomocí filtru se nastaví, že routy z isntance B-C, B-D, ... se předávají do in stance A-B. Pak každá větev je nezávislá a samostatná. Jenom v té A-B bude strašit velká majorita externích rout (naimportovaných z těch částí C, D, E, ...), což MK opbčas špatně nese. Vyhoda je, že se to konfiguruje jen na B a na zbytek nemusíš šahat. Má to i své nevýhody, kdyby později došlo na kruhování a další voloviny (ale to stjené platí i pro stuby, musím to pak předělat).
0 x
Hele, Majkle ... čistou Quaggou asi víc instancí neudělám, co?
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Add quagga - se obávám, že víc OSPF procesů neumí (pokud za poslední rok se něco nezměnilo). Je podpora jen pro víc BGP instancí.
0 x
Dekuju vsem za vysvetleni.
Co se tyka toho casu, tak hello interval je 10s a dead interval 40s (defaultni nastaveni). Muze nastat nejaky problem, pokud ten dead interval zmenim z 40s na treba 10s, krome tedy toho, ze musi mit vzdy protistrany stejny dead interval, jinak to nebude fungovat? Dekuju.
Co se tyka toho casu, tak hello interval je 10s a dead interval 40s (defaultni nastaveni). Muze nastat nejaky problem, pokud ten dead interval zmenim z 40s na treba 10s, krome tedy toho, ze musi mit vzdy protistrany stejny dead interval, jinak to nebude fungovat? Dekuju.
0 x
S těmi časy si radši moc nehraj. Je to opět jedna z věcí, která tě za rok dva akorát naštve, protože na ní zapomeneš ... Dělá se to, že na mizerných linkách se dead prodlužuje, aby to zbytečně nepadalo, když se tím stejně nic nevyřeší ... ale pro jeho zmenšení nějak nevidím moc důvod. Můžeš mít asi někde něco opravdu "důležitého", kde chceš snížit dobu přehození na zálohu. Ale bych řekl, že to má málokdo. Pro rychlost je asi lepší to odswitchovat a nasadit RSTP nebo něco podobného.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Na routované síti se s RSTP moc toho nazachrání.
Ale jinak se s těm\ časy dá hejbnout, pokud chceš rychlejší odezvu, ale čím rychlejší odezva, tím víc falešných přepnutí, takže to chce s citem. Na spolehlivé rádiové lince se dá jít běžně na časování delay/hello/dead 1/2/8 sec. Pak to reaguje za 8 sec na výpadek i naběhnutí je o něco rychlejší. Chce si to samozřejmě uhlídat a na dané lince to mít nastaveno na všech koncích. Další malé urychlení, pokud je to jen spojovačka a jsou pouze dva routery proti sobě, tak nastavit typ linky pint-to-point, ušetří se trošku v dohadování DR/BDR/other stavu routeru (a chyb s tím spojeným v ROSu), protože je zbytečný.
Pokud máš už všude nějaký celkem aktuální ROS, tka druhá možnost je nechat hello/dead klasicky 10/40 a zapnout na dané lince BFD. Opět musíš na všech routerech na dané lince jednotně. V nastavení BFD si nastavit třeba 5x0,6 sec a máš reakci 3 sec na výpadek (posílá se paket po 0,6 sec a 5 ztracených se hlásí link down). První sestavení trvá dlouho nebo po úplném startu všech routerů také, ale když vypadne jen jeden, tak se pak i rychle vrátí zpět. S BFD na spolehlivých linkách se dá jít hluboko pod 1 sec reakční dobu, ale na ROSu nemám odvahu to moc provozovat pod 1 sec reakci (4x0,25 sec). A hlavně ne na wifi a podobných srandách.
Ale jinak se s těm\ časy dá hejbnout, pokud chceš rychlejší odezvu, ale čím rychlejší odezva, tím víc falešných přepnutí, takže to chce s citem. Na spolehlivé rádiové lince se dá jít běžně na časování delay/hello/dead 1/2/8 sec. Pak to reaguje za 8 sec na výpadek i naběhnutí je o něco rychlejší. Chce si to samozřejmě uhlídat a na dané lince to mít nastaveno na všech koncích. Další malé urychlení, pokud je to jen spojovačka a jsou pouze dva routery proti sobě, tak nastavit typ linky pint-to-point, ušetří se trošku v dohadování DR/BDR/other stavu routeru (a chyb s tím spojeným v ROSu), protože je zbytečný.
Pokud máš už všude nějaký celkem aktuální ROS, tka druhá možnost je nechat hello/dead klasicky 10/40 a zapnout na dané lince BFD. Opět musíš na všech routerech na dané lince jednotně. V nastavení BFD si nastavit třeba 5x0,6 sec a máš reakci 3 sec na výpadek (posílá se paket po 0,6 sec a 5 ztracených se hlásí link down). První sestavení trvá dlouho nebo po úplném startu všech routerů také, ale když vypadne jen jeden, tak se pak i rychle vrátí zpět. S BFD na spolehlivých linkách se dá jít hluboko pod 1 sec reakční dobu, ale na ROSu nemám odvahu to moc provozovat pod 1 sec reakci (4x0,25 sec). A hlavně ne na wifi a podobných srandách.
0 x
Já to tak provozuju ... holt hybrid
Majklik píše:Na routované síti se s RSTP moc toho nazachrání.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Ale jistě, dá se nad sebe vrstvit kde co. Jen si je třeba pak pochytat časování, ať nižší vrstva reaguje rychleji (RSTP), než to co je nad tím (OSPF), ať to pak nemlátí vše tam a zpět... I když - zákazník to většinou stejně neocení.
0 x