On 02/06/10 16:36, Zbyněk Burget:
Zalezi, jestli jsou ty linky takoveho typu, ze se na nich vypadek pozna.
Tohle je uvaha spravnym smerem.
Diky.
Server sam pro svoji cinnost nepotrebuje pripojeni k internetu.
Ale urcite nevadi, ze ho vzdy, pres jednu nebo druhou, linky mit bude.
Poskytuje nejakou sluzbu klientum, podstatne je, aby ta sluzby byla
dostupna pokud mozno bez vypadku. V klientovi budou nastaveny dve IP
adresy. Pokud se mu informaci nepodari ziskat z jedne (posle request,
nevrati se odpoved), zepta se na druhe IP. Komunikace probiha na TCP
protokolu.
Takze, predpokladam, ze nevadi, ze jiz zahajena spojeni se v kazdem
pripade rozpadnou a neni zpusob, jak je zachranit.
Pokud bude mit server nastavenou default routu do subnetu 1 a prijde mu
request ze subnetu 2, jak docilit toho, aby i odpoved sla smerem do
subnetu 2.
Jinymi slovy chces, aby odchozi interface byl zvolen podle zdrojove,
nikoliv podle cilove adresy.
Ale to by snad mela byt trivialni uloha pro ipfw:
ipfw ... fwd <nexthop1> from <local1> to any out
ipfw ... fwd <nexthop2> from <local2> to any out
Dokonce staci jen jedno, pokud je jeden z nexthopN defaultni nexthop ...
Resp. pokud ji posle na default gateway a ona nedorazi k cili
(= nedostane potvrzeni prijeti packetu), aby se server pokusil odpoved
odeslat znovu pres subnet 2.
Ne, to motas zalezitosti z nesouvisejicich urovni a proto to nepujde.
Routing, to je zalezitost treti vrstvy (sitova, IP). Nejake potvrzovani,
to je ctvrta vrstva, (transportni, TCP). Treti vrstva nikdy nic
nepreposila a ctvrta zas nemuze ovlivnit routing.
A navic i kdyby to slo - bylo by to bylo k nicemu. Pokud nema subnet 1
konektivitu tak nema nejmensi smysl posilat odpoved pres subnet 2,
protoze klient bude i nadale komunikovat vyhradne pres subnet 1 - a
tudiz se stejne nedomluvi.
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
