On 8.2.2010 0:59, Filip Huska:
Spojeni navazuje klient (neni tohle nakonec naprosto vetsinove chovani u
klient-server architektury ?)
Ano, je, neuvedomil jsem si to, omlouvam se. Sam pouzivam spise opacne zamerene
servery :
MRTG, Nagios, jakkekoliv sledovani a seskupovani dat, spojeni do databaze v
jine lokaci, backup atd.
Opacne zamerenym serverum se rika klient ;-)
Databazovy klient se pro ucely ukladani dat spojuje na databazovy
server. Ne obracene. Taktez backup probiha tak, ze klidne uklada zalohy
na zalohovaci server. No a MRTG je SNMP klient a WWW server.
V seznamu nevidim jediny server, ktery by se spojoval na klienta.
Ale to asi neni podstatne, to je, zrejme, jen nejaky terminologicky
problem a ty proste pojmem server myslis neco jineho, nez je bezne.
Nastesti to neni pro problem podstatne. Budeme proste mluvit o tech, co
spojeni navazuji a o tech, co spojeni prijimaji a pojmum jako server a
klient se vyhneme - a bude to.
Zajimalo by me, jak by jste resili tohle bez pouziti dynamiky.
Chces rict, ze jediny zpusob jak poznat, ze linka je nefunkcni, ktery znas, je
dynamicky routing ?
Ano, v dynamice rozhodnu, ktery upstream je lepsi, proto, aby me mereni bylo
nejkvalitnejsi i za cenu zvysenych nakladu pri zmene route path providera.
Kvalitu linky s packetlossem, vetsim poctem hopu,
velkou latenci povazuji za nefunkcni. Jinak me nenapada jak to zmerit bez
traceroutu, serii pingu viz predchozi mail.
No, to je pak jasne, v cem je nedorozumeni.
My se tu bavili o tom, jak zjistit, ze je linka funkcni. Linkou se mysli
spojeni na nejblizsi router - ten u providera. Dal spojeni neresim -
pokud mam server, o jehoz provoz mi jde natolik, ze mu zrizuju dve
nezavisla pripojeni, tak je zrizuju k nejakym serioznim ISP u kterych se
da rozumne predpokladat, ze maji svoji konektivitu take rozumne
redundandni - a jakmile se tudiz dostanu na router kterehokoliv z nich
tak proste mam spojeni kamkoliv.
Ty tu rozebiras, jak zjistit, ktera ze dvou funkcnich je funkcni lepe, a
to na zaklade docela slozitych kriterii. To znamena, ze bud' potrebujes
spojeni opravdu super-super-super spolehlive. Jenze, to bys delal k
takovym ISP, u kterych by nebyl problem dynamicky routing domluvit.
Takze spis delas spojeni k nejakejm "garazovejm ISP" u kterych ocekavas,
ze jejich konektivita neni prilis spolehliva ...
To je ale problem jine kategorie, nez o kterem tu byla rec dosud a me
ten posun nejak uniknul.
2 interfacy od 2 ASek na 2 subentech, tzn, kazdy interface ma ipcko z jineho
aska a tudiz i default routu
Interface nema route a tudiz ani default route. Routovaci tabulka je
"per system" nikoliv "per interface". Nektere systemy umoznuji mit v
routovaci tabulce vic zaznamu pro stejnou sit, co to ale znamena pro
odesilane pakety se pak na ruznych systemech lisi. FreeBSD dva zaznamy
pro stejnou cilovou sit neumoznuje vubec, takze odlisne implementace
nemusime rozebirat.
Ani proti jednomu z routeru nemuzu navazat zadnou dynamiku.
Interface A je za cenu nizsi nez interface B, tudiz je "chtene" inicializovat
spojeni pres interface A, pokud je v poradku.
V poradku je mysleno, ze na - napriklad vyhrazene domeny skrze NIX/local bude
zarucena idealni cesta s rozumnym zpozdenim,
To chces za malo penez docela dost muziky. Nastesi se i s malym
kasparkem da hrat velky divadlo. Jen si myslim, ze to co potrebujes je
natolik specificke, ze to nenajdes hotove a budes si muset trochu
zaprogramovat, ale ani ne moc slozite, takze to urcite zvladnes. Ono by
to nejspis slo napsat i jako shellovsky script.
Ohodnotit, jaka linka je "dostatecne dobra" je subjektivni zalezitost,
ale nastesti, svoji predstavu si dodal - serii pingu. Takze potrebujes
poslat tu svoji serii pres oba interface, vyhodnotit odpovedi, zjistit,
ktery smer ti vyhovuje lepe a podle toho nastavit routovaci tabulku.
Jevi se mi to trivialni, at uz to budes psat jako shellovsky script nebo
jako program v nejakem jazyce.
Jedine s cim bys snad mohl mit problem je - jak poslat pakety pres
pozadovany interface. Ale na to tu odpoved uz preci padla - to zvladne
ipfw fwd. A nebo, s ohledem na zrovna dve konkretni pozadavky - dokonce
to pijde i pomoci host-zaznamu v routovaci tabulce (az si pro kazdy
interface vyberes na jake cile chces v ramci testu posilat pakety, vyber
si je tak, aby byly ruzne od stroju na ktere se chces spojovat
"normalne" a pak si muzes komunikaci na ty vybrane stroje nasmerovat
beznymi zaznamy v routovaci tabulce do toho smeru, jaky budes potrebovat)
Jak jsem uvedl, prehodit default routu z interfacu A na interface B -
rozhodnuti na zaklade kvality linky A - neni orisek, to bych vedel. Ale jak
vyresit prepojeni zpet aniz bych musel prehazovat default routu kazdych 5 minut
abych poslal serii pingu a testu {zahodil mozna flowy}a zase vratil v pripade
problemu.
Mam zasadni potiz, ze netusim, proc potrebujes kvuli tomu, abys mohl
testovat interface X nastavovat defaultni routu tak, aby smerovala
provoz do interface X. Bud' me nebo tobe neco uniklo.
Do interface X potrebuju nasmerovat pouze testovaci provoz testujici
linku pripojenou do interface X.
Do interface Y potrebuju nasmerovat pouze testovaci provoz testujici
linku pripojenou do interface Y.
Default route mi smeruje tam, kam mi vyhodnoceni parametru testovaciho
provozu reklo, ze je to lepsi.
A to je na co se ptam, nemam BGP demona, ktery se propocita tabulku a vybere
best path, tudiz se dynamicky prehodi.
I kdybys BGP mel, BGP nema ty vlastnosti, ktere ty pozadujes. Jeho
algoritmus na vyber "best path" je typicky o dost jednodussi, nez ty
pozadujes (on je ten algoritmus castecne implementacne zavisly, tak to
nemuzu rict s jistotou - ale proste neznam implementaci, ktera by do
vypoctu zahronvaly vsechny ty parametry, o kterych's mluvil).
Zahozeni stavajicich flowu je celkem neprijemne.
Tomu se ale nevyhnes. Zahozeni nebo nezahozeni existujicich spojeni neni
primarne otazka toho, jestli mas nebo nemas se svymi vice ISP dynamicky
routing, ale jestli mas skutecne multihomed pripojeni. Coz neni totez,
jako mit dve "obycejne" linky do jednoho stroje.
Dynamicky routing bezici jen na jedne strane linky (tedy bez kooperace
protistrany) - to neni problem. To si reknes podle ceho se chces
rozhodovat "kterou" a pak to proste tak udelas.
Co ale na dvou "obycejnych" linkach a bez spoluprace vsech zucastnenych
proste nedosahnes je prave to "multihomed". A bez toho neni sance pri
vypadku jedne linky spojeni, ktera sla pres ni zachranit.
Chtel bych dynamiku simulovat {to je ta dynamika bez dynamiky ;-)}
Jo, uz jsem pochopil, ze's chtel rict, ze bys rad dosahnul
"funkci jako ma dynamicky routing ale bez nektereho z obvyklych
dynamickych routovacich protokolu"
Ano, ja to mam ctyrikrat delsi, otazka je, jestli tvoje setrnost za tu
snizenou pochopitelnost stala.
Mimochodem, dynamicky routing je obecny termin oznacujici situaci, kdy
se nastaveni routovaci tabulky meni automaticky na zaklade vlastnosti
sitoveho okoli a nikoliv tim, ze jsou nastavene napevno. "Dynamicky
routing" neznamena, ze ty informace o okoli musis ziskavat aktivni
spolupraci s nekym, kdo vi, ze shanis informace kvuli routingu a jako
takove ti je poskytovat. Je jedno, kde si ty informace sezenes a jak a
jestli ten druhy vi k cemu je shanis.
Takze to, o cem mluvis je porad dynamicky routing. Proste's vymyslel
vlastni algoritmus dynamickeho routingu, ktery pro ziskavani informaci
potrebnych pro svoji cinnost nepotrebuje specializovany protokol pro
vymenu informaci. Ale porad jde o dynamicky routing.
Otazka je, zda serii testu poslat nexhopem
Kdyz to je fakt tezky. Nemusis psat litanie jako mam ve zvyku ja. Ale
opacny extrem je nejmene stejny problem. Pod "posilat test nexthopem" si
dokazu predstavit celou radu moznosti, co bys tim tak mohl myslet. Ale
co tim myslis doopravdy, tak fakt netusim. Vzhledem k tomu, ze otazka
smeruje k posouzeni efektivity takoveho (neznameho) reseni pripadne
navrzeni reseni efektivnejsimu je to zasadni nedostatek ...
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
