L3 szintű gateway tartalékolást szeretnék csinálni egy hálózaton. Meg lehet-e oldani egyszerűen azt, hogy egy célt két gateway-en keresztül érjen el a Linux, amelyek közül ha az egyik nem megy, a másik automatikusan átvegye a szerepét?
Elképzelésem szerint erre lenne való a multipath routing. A helyzetemben viszont az a speciális, hogy mindkét gateway ugyanazon a hálózaton van, ezért az nem megoldás, hogy akkor invalidálom az elsődleges irányt, ha down-ba megy az interface. Van valakinek pontos információja róla, hogy az "ip route nexthop" mi alapján dönti el, hogy a nexthop elérhető-e?
Leegyszerűsítve a kérdést: lehet-e egy hálózaton a gépeknek több default gateway-ük, amelyek között automatikus failover van?
A L2 tartalékolás egyébként megoldott, a routerek között nem szeretnék heartbeatet vagy más, virtuális IP megoldást futtatni, inkább megoldom az egészet alkalmazás szintű proxyval.
- 1649 megtekintés
Hozzászólások
metric nem jó erre? (legalábbis Mikrotiknél használunk olyat, hogy metric ÉS check-gateway. ha primer gateway off, akkor jön a második)
- A hozzászóláshoz be kell jelentkezni
Ez nagyon jól hangzik, de úgy tűnik, a check-gateway opció Mikrotik-specifikus. Pedig most nagyon jól jönne...
- A hozzászóláshoz be kell jelentkezni
subs
- A hozzászóláshoz be kell jelentkezni
Miért ragaszkodsz a kliens oldali megoldáshoz, amikor a HSRP / VRRP (és társaikat) pont erre találták ki?
- A hozzászóláshoz be kell jelentkezni
A L2 hálózat bonyolultsága miatt jobb lenne, ha ezt kliens oldalon tudnám megoldani.
Valójában nem ismerem a szóban forgó Infiniband switcheket, és nem tudom, hogy a mac cím átváltást, ill. a gratitous arp-t -- asszem a vrrp ezt használja -- jól kezelik-e. És idő hiányában ezektől szeretném magam a lehető legtávolabb tartani...
- A hozzászóláshoz be kell jelentkezni
gratitous arp-t -- asszem a vrrp ezt használja -- jól kezelik-e.
A VRRP emlékeim szerint nem vált MAC címet, mivel fix multicast MAC címet rendel a VRRP routerhez, és az vándorol mindig a masterra.
- A hozzászóláshoz be kell jelentkezni
Az RFC2338,RFC3768 szerint valóban nem vált, és a nagyobb vendorok implementációi tényleg virtuális MAC címmel operálnak.
Viszont a Linux-on elérhető vrrp implementációk gratious arp-t használnak (valamilyen régi kernel limitáció miatt nem lehetett több MAC címe egy interfésznek, promisc módba kellett kapcsolni ilyen rémlik...), ilyen értelemben nem is szabványosak.
A keepalived git fájában már benne van a vmac támogatás a macvlan driver-en keresztül, de ez egyrészt még nem rilizelt verzió, másrészt > 2.6.32 kernel kell hozzá,ami nem éppen mindig elérhető. (rhel5, centos pl nem tudja, squeeze újabb ubuntuk igen.)
- A hozzászóláshoz be kell jelentkezni
Hát ha meg linux a router, akkor meg tessék rá rakni zebrát, oszt OSPF meg kezitcsókolom.
- A hozzászóláshoz be kell jelentkezni
Rövid és velős leszek: nem, a multipath routing nem errevaló, és nem is használható erre a célra.
Kliens oldalon intelligens megoldással lehet csak elérni ezt a célt (program, ami folyamatosan nézi, hogy melyik jó és melyik nem, és változtatja a routing táblát).
A butább verzió az kb. egy shell script, ami folyamatosan pinget, és a jó routert berakja, a rosszat megkiveszi a listából.
Az okosabb verzió a VRRP, a legokosabb verziót meg úgy hívják, hogy dinamikus routing, és úgy működik, hogy a jól működő routerek hirdetik a létezésüket (és a rajtuk keresztül elérhető route-okat - pl. default route) valamilyen routing protokollal, a kliensen futó routing daemon pedig ezekből tákolgatja a gép routing tábláját. Ehhez nyilván a routereket is fel kell konfigurálni, cserébe nem csak azt látod, hogy a router elérhető-e, hanem azt is, hogy ő látja-e az uplinkjét, vagy ha nem csak default route van, akkor még per route is lehet eltérő a next hop router.
- A hozzászóláshoz be kell jelentkezni
Ezek szerint a helyes sorrend:
Shell script ami bizgeralja a routing tablat,
Vrrp ami a routerek kozt mukodik, de te semmit sem tudsz rola,
BGP
Ha jol ertelmeztem a jobban kifejtett velemenyt :)
- A hozzászóláshoz be kell jelentkezni
A helyes sorrend:
- ha full dinamikus routingot akarsz, akkor OSPF/BGP/whatever
- ha csak default routert akarsz, akkor VRRP
- ha a fentiek nem járhatóak (másé a router, és doszt sem akar segíteni): shell/perl/python script
- A hozzászóláshoz be kell jelentkezni
Kösz a segítséget.
Most már csak azt nem tudom, hogy mikor jó a multipath routing... ;)
- A hozzászóláshoz be kell jelentkezni
Ha van két kb. egyforma sávszélességű vonalad, aminek a túloldalán ugyanaz a hálózat van (mindegy, melyiken küldöd a csomagokat, ugyanoda fog odaérni), és mindkét vonalat szeretnéd egyformán igénybe venni. Load balancing.
- A hozzászóláshoz be kell jelentkezni
JFTR, szerintem nem kell, hogy egyforma sávszélességű vonal legyen, és nem kell az sem, hogy ugyanaz a hálózat legyen a vonalak másik végén (de ilyenkor policy routing is kell). Ráadásul van benne valami failover is, de ennek a pontos működése nem világos.
De abban egyetértünk, hogy nekem most nem ez kell. :S
- A hozzászóláshoz be kell jelentkezni
Nem _kell_, hogy egyforma sávszélességű legyen, csak ha nagyon eltérnek, akkor nem azt fogod kapni, mint amit várnál.
Nem _kell_, hogy ugyanaz a hálózat legyen a vonalak másik végén, csak éppen ha random hol erre, hol arra mennek a csomagok, az leginkább semmire sem lesz jó :)
A policy routingot ne keverd ide, mert az másra való, és ahhoz, amire az való, ahhoz meg nem kell multipath routing.
"van benne failover is": nem, nincs benne failover = nem nézi senki, hogy a next hop router él-e, a lehalt routerre is ugyanúgy próbálkozik majd küldeni a csomagokat.
Ha kikapcsolod a multipath routingot, akkor determinisztikusan (de általad nem vezérelhető módon = azt, amelyik neki tetszik) csak az egyik routert fogja a rendszer használni, ha pedig bekapcsolod, akkor per route cache entry fogja a forgalmat a routerek között szétosztani. Ha kikapcsolod a route cache-t, akkor per packet lesz load-balancing.
- A hozzászóláshoz be kell jelentkezni
Ok, a sorrend nalam a butabbtol ment az okosig :)
- A hozzászóláshoz be kell jelentkezni