Dva routery
wire
wiro.wire at gmail.com
Wed Feb 22 09:58:23 CET 2012
V portoch je aj keepalived ktory sa da v jednoduchej konfiguracii prave
na toto pouzit.
Pouziva uz zmienene VRRP, nastavia sa len vsetky spojovacky ktore ten
router pouziva ako virtualne IP a mozu plavat medzi routrami podla toho
ktory vypadne.
Umoznuje pridat vlastne scripty jak na kontrolu tak aj na akcie ak to
vypadne.
Pouzivali sme to pred par rokmi na rovnaky ucel.
On 02/21/2012 09:58 PM, Dan Lukes wrote:
> On 02/21/12 18:05, Zbyněk Burget:
>> Jak jsem se zmínil v minulém e-mailu, mám síť s cca 700 uživateli. A
>
> Mam 1300, vyhral jsem ;-)
>
>> zatím pouze jedinou konektivitu do internetu s jediným hraničním
>> routerem (FreeBSD). To samo o sobě není až takový problém - všechno
>> stíhá, jak má, ale chtěl bych mít nějakou pojistu pro případ havárie
>> toho routeru.
>> Prozatím by mi stačilo, kdybych měl dva redundantní routery.
>
> Jo, tohle bys do konference klidne poslat mohl, takze ja to tam ted
> poslu v ramci odpovedi.
>
> Jedna z odpovedi na tvoji otazku zni "VRRP"
>> http://datatracker.ietf.org/wg/vrrp/charter/
> FreeBSD port net/freevrrpd
> jediny problem je, ze Cisco si myusli, ze jeho pouzitim porusujes
> jejich patentova prava. Alespon mam ten dojem. A Cisco neni jedine,
> taky Nortel a IBM okolo toho mrmlaji.
>
>
> Dalsi mozna odpoved je "CARP"
>> http://www.freebsd.org/cgi/man.cgi?query=carp&sektion=4
>
> Prestoze je o implementace dost ruzne, zakladni princip je shodny -
> oba routery maji na svem interface jednak svoji vlastni adresu, ktera
> je jen jejich, a pak jednu spolecnou, putovni, coz je ta, kterou jako
> adresu routeru znaji ostatni stanice.
>
> Ani jeden z protokolu jsem zatim osobne nepouzival, takze to jak
> funguji znam jen zhruba.
>
>> Jedna
>> varianta, která mě napadla byla routery synchronizovat např. pomocí
>> rsync, jen mít nastavené jiné IP na adaptérech. V případě výpadku
>> primárního routeru be se pomocí skriptu přehodily IP a funkci by převzal
>> záložní router.
>
> No a to je samozrejme dalsi moznost - ze si podobnou funkcionalitu
> implementujes sam. Ono to zas tak slozite neni.
>
>> Byl by tam ale asi drobný výpadek kvůli změně MAC adres,
>> než by vytimeoutovaly arp cache.
>
> Nikoli nutne. Zaprve pri predani "putovni" IP adresy lze vyslat
> gratiuous-arp, ktere by melo problem statisticky vyresit, i kdyz
> nektera zarizeni paket dostat nemusi.
>
> Ona se ale nutne MAC menit nemusi - i MAC totiz muze byt "putovni",
> podobne jako IP. Prinejmensim VRRP tento rezim "umi" (ale nevim, zda
> ho umi take freevrrp implementace).
>
> Pokdu ano, musis uz jen dat pozor na to, ze nektere switche mohou
> reagovat velmi nedutklive na to, ze se jim ARP, kterou maji naucenou
> na jednom portu, nahle zjevi an portu jinem. Mohou to povazovat za
> topologicky nebo bezpecnosti problem. Zalezi co tam mas a jak presme
> to je nakonfigurovany.
>
>
>> Druhý s tím spojený problém je, že můj ISP má statickou arp tabulku a
>> musel bych jim zavolat.
>
> Ja mel zatim na mysli spis reseni smerem do vnitrni site. Smerem ven
> patrne budes vic limitovan tim, co ti na tomhle poli umozni tvuj ISP.
>
> Zejmena pokud bys zjistil, ze "stehovava MAC" z VRRP protokolu na
> FreeBSD k dispozici neni.
>
>> nevím, jestli pak nebude třeba zvlášť řešit vnitřní a vnější
>> stranu sítě.
>
> No, to vyplyne z reseni na strane k ISP, kde si nemuzes vybirat uplne
> svobodne.
>
>> Co se mého ISP týká, není problém, abych od něj dostal druhou "vnější"
>> IP.
>
>> Pokud by bylo potřeba nějaké dynamické routování směrem do venku,
>> myslím, že by neměl být zásadní problém se s ISP doluvit.
>
>
> V tom pripade by resenim mohl byt obycejny dynamicky routovaci
> protokol smerem k ISP, takze on by tobe routoval na tu IP, ktera by
> byla "ziva" -a pak uz bys musel jen zaridit, aby stav vnejsich karet
> (tech smerem k ISP korespondoval se stavem karet "dovnitr" - repsneji
> - aby "ven" byla ziva karta na tomtez routeru, ktery zrovna drzi
> funkci routeru smerem do vnitrni site.
>
> Ale zadnej step-by-step ani osobni zkusenosti ti nenabidnu. Nekdo jiny
> ale mozna ano.
>
> Dan
>
>
More information about the Users-l
mailing list