dva interface do WAN

[Dan Lukes]

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