Dva routery

[Filip Huška]

>> Mam 1300, vyhral jsem ;-)
To je detinske ;-) 

>> 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.
Mam multi vendor sit ... a VRRPv2 minimalne pouzit ... pak je to cajk


>>> 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.
Je to na prd ... a fakt spatny napad. V pripade problemu, vysokych toku, generovanych
utoku - router bude routovat, ale nebude odpovidat na ping atd ... pak si do vlastni
site rozdistribujes flap mac adres, protoze budou oba routery tvrdosijne tvrdit, ze ten
druhy nefunguje a pak zazijes peklo ... nic nepojede, packet loss az 100% a vse up.
QOS to nezachrani ... a rozhodne budes chtit mit na samotne routery dobre nastaveny 
firewall/policy. 
Doporucuju mit v routerech vlastni propoj mezi nima na vlane/ip/kabelu, jez neni verejna ...
Dale pouzit zminovane VRRPv2 minimalne .. a uzavrit SSH {naposledy mi uvaril
hacknuty klient router generovanim velkeho poctu SSH spojeni z vnitrni site na router,
router pak jen generoval klice} 

>> 
>>> Byl by tam ale asi drobný výpadek kvůli změně MAC adres,
>>> než by vytimeoutovaly arp cache.
Timeout lze nastavit.
>> 
>> 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.
Presne !!!
>> 
>> 
>>> 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.

S timhle neni co nez souhlasit. BGP s default routou na oba routery to resi
naprosto .. a nemusis se bat tabuli a traffic muzes i rozlozit mezi oba routery.
Stejne ti povedou 2 kabely do kazdeho routeru minimalne.
>> 
>> 
>> 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
>> 
>> 
> -- 
> FreeBSD mailing list (users-l na freebsd.cz)
> http://www.freebsd.cz/listserv/listinfo/users-l