classic.ISPforum.cz

Dobry den,

mam:



potrebuji zajistit 99.99% dostupnost ip 10.10.10.100, pokud to mam takle (cili na obou strijich ip trvale a necham to at se to pere jak umi) a nic nenastavim, mam vypadek pri odpojeni jednoho z portu cca 25s, ale potrebuji to dostat niz. Resim to takto, protoze reseni nesmi zasahovat do node1 ani node2 (jinak bych pouzil heartbeat) a mam k tomu prez ROS api udelane manualni shazovani interfacu na mikrotiku, coz je take pozadovano. Vi nekdo jak dostat cas zdetekovani zmeny v arp as prepnuti nekam pod 10s? Musi to byt plne automatizovane, tak nevim jestli se spolehat na nejaky script a poustet ho po 5s. Nobo jestli na to nema mikrotik uz nejakou ficuru. Z pocatku sem to chtel resit prez rstp protokol, ale tohle neni spravna situace a pri testu se vysledek nezmenil (coz sem cekal)

Dekuji za rady

Nejsem si jistý, zda-li to chápu dobře. Uzel1 a uzel 2 jdou do switche a odsud do RB1? Nebo jdou každý do jiného portu na RB? Pokud do switche, dalo by se použít VRRP na dva routerboardy a z opačné strany pak nějaká dynamika (OSPF). Konfigurace na uzlech by tím pádem zůstala netknutá.

Dobry den,

servery jdou primo do mikrotiku, port1 je uplink, port4 server1 port5 server2, vrrp me napadlo, ale nenasel jsem podrobnosti a trochu se bojim propustnosti. Vyzkousim a dam vedet vysledky.

Dekuji za pomoc

Propustnosti bych se snad ani nebál. Svého času jsme VRRP jeli i na VLAN rozhraních a fungovalo to. Akorát občas se některý VRRP interface označil zničehonic jako invalid a nešlo s ním hnout. Po nějakém čase to opět rozdýchal. Bohužel to bylo na BGP boxu, takže nebyl prostor na žádné experimenty.

Moc dekuji,

chova se to opravdu moc dobre, vypadek kolem 2s, jenze jsem to potreboval mit postavene na jednom mikrotiku a k tomuto musim mit dva, protoze protokol vrrp je pro predavani rout mezi dvema routery a nejde mi zprovoznit mezi dvema porty (ale nejsem obornik na mikrotik a mohu delat neco spatne). Jen pro potvrzeni, skutecne vrrp (pravdepodobne uz z podstaty) nemuze fungovat jen na jednom routeru mezi 2 porty?

Diky...

masi píše:Jen pro potvrzeni, skutecne vrrp (pravdepodobne uz z podstaty) nemuze fungovat jen na jednom routeru mezi 2 porty?

Tu otázku chápeme jako čistě akademickou, páááč VRRP běžící na jednom routeru samozřejmě popírá svůj smysl, jak sám píšeš. Nicméně nezkoušel jsem to, ani mě to zkoušet neláká, ale rád se dozvím výsledek. Tipuju, že to neklapne, protože pokud se nerozsype už samo VRRP na L2, tak se rozhodně rozsype L3 běžící na něm.

Masochista by na odpověď přišel už pohledem do http://wiki.mikrotik.com/wiki/Manual:Pa ... ow#Diagram

jak rychla je featura 'watch ip'? Nebo to take jede pres ARP?

masi píše: protokol vrrp je pro predavani rout mezi dvema routery a nejde mi zprovoznit mezi dvema porty (ale nejsem obornik na mikrotik a mohu delat neco spatne). Jen pro potvrzeni, skutecne vrrp (pravdepodobne uz z podstaty) nemuze fungovat jen na jednom routeru mezi 2 porty?
Diky...

VRRP nezlouzi k predavani rout, ale predevsim k predani MAC a IP adresy, tedy pro failover celeho routeru. Obavam se ze na jednom routeru to fakt nerozjedes, nebo me nenapada jak by slo udelat.

Tak nějak na první pokus mě napadá - mohl by jít použít Bonding v módu active backup.

a me zas napada udelat script, ktery by pingal node1 a v pripade vypadku jedineho pingu (bavime se o kabelu) by disabloval port pro node1 a enabloval port pro node2 = vypadek 1sec...
edit: vlastne staci netwatch

ludvik píše:Tak nějak na první pokus mě napadá - mohl by jít použít Bonding v módu active backup.

Mmm, jak že rychlý má active-backup čas konvergence?

net.work píše:a me zas napada udelat script, ktery by pingal node1 a v pripade vypadku jedineho pingu (bavime se o kabelu) by disabloval port pro node1 a enabloval port pro node2 = vypadek 1sec...
edit: vlastne staci netwatch

Nevím jak vy, ale u nás v síti mají tyhle nesystémové ojebávky zákaz.

Konfigurovatelné je to až na milisekundy. Ale s tím mě správec jednoho Cisca jednou pěkně vyhodil
Pokud je to v módu sledování linku, tak bych o zpoždění snad ani nemluvil. Ale na to se asi dotyčný spolehnout nemůže, musí použít ARP.

Zdeněk Švarc píše:

ludvik píše:Tak nějak na první pokus mě napadá - mohl by jít použít Bonding v módu active backup.

Mmm, jak že rychlý má active-backup čas konvergence?

Díky za tip. Na ten active-backup se musím pořádně mrknout, měl jsem za to, že konvergence tam půjde v řádech vteřin až desítek vteřin. Ale když se sám Mikrotik kasá s HA "Active-backup is best choice in high availability setups", tak na tom asi něco bude.

On ten bonding toho umí docela dost ... http://www.linuxfoundation.org/collabor ... ng/bonding Jestli je i všechno v MK nevím. MK mám jen na strojích, kde to opravdu smysl zase tolik nemá.
Akorát proti switchům jsem nerozchodil statický bond, musím používat LACP.

Zdeněk Švarc píše:Díky za tip. Na ten active-backup se musím pořádně mrknout, měl jsem za to, že konvergence tam půjde v řádech vteřin až desítek vteřin. Ale když se sám Mikrotik kasá s HA "Active-backup is best choice in high availability setups", tak na tom asi něco bude.

Dotyčnému tazateli by teoreticky mohlo stačit i OSPF s tou BFD vlastností. To je také rychlé dost. Ale nesplňuje to podmínku, že nesmí sahat na node1 a node2.

Diky za tipy,

ale bonding konkretne sem zkousel, jeste pred vznesenim dotazu, byla to take prvni myslenka co mi bleskla hlavou, ale nebylo to ono. Asi nejlepsiho vysledku jsem dosahl v modu active-backup, kde bohuzel i podle mikrotiku (ARP monitoring in this mode will not work correctly if both routers are directly connected. In such setups mii-type1 or mii-type2 monitoring must be used or switch should be put between routers. http://wiki.mikrotik.com/wiki/Manual:In ... ding_modes ) nefunguje spravne link-monitoring=arp, skutecne se to prepinalo az po 15 a vice s. Dalsi dost neprijemnou veci bylo, ze pri zapojeni primary to okamzite zaclo prepinat zpet a to v pripade, kdy bude vypadek a po najeti nemusi byt server uplne ok, neni dobre chovani, navic to behem startu takto 2x prepina (POSTTEST a pak jeste jednou). Ospf s BFD by bylo presne me reseni, ale bohuzel zde nemohu routovat, jednou z variant bylo i rstp, ale na serverech nemohu povolit ani to a navic tam v siti uz rstp je a nemam ho ve sprave, takze by nebylo uplne snadne se tam s nimi domluvit. V mem pripade bude vrrp i za cenu 1RB navic nejlepsi reseni.

Jen pro zajimavost, bonding sem mel nastaven v posledni fazi takto, napada nekoho proc to konvertovalo tak pomalu, puvodne sem toto reseni mel opravdu za favorita. Mam tam pouzito to arp, presto ze to nepracuje pry spravne, ja tom mel o trochu rychlejsi nez v pripade mii a hlavne se to samo nepreklopilo zpet, dokud nebyl server skutecne dostupny

interface bonding add name=bond1 arp=enabled slaves=ether4,ether5 primary=ether5 mode=active-backup mii-interval=10ms arp-interval=10ms transmit-hash-policy=layer-2-and-3 link-monitoring=arp arp-ip-target=192.168.88.100

Dekuji

Mě se to takhle nechovalo (opakuji: ne na MK). Sice jsem to neměřil exaktně, ale to přepnutí od oka odpovídalo tomu ARP intervalu. Jediné co mě napadá - ten arp target tam máš jenom jeden. Měl bys tam mít adresy z těch dvou nodeX. A pak si pohrát s těmi Delay intervaly, netuším co je default hodnota (a taky netuším, jestli se to náhodou nevztahuje k LACP, tedy v módu active-backup se to možná ignoruje).

Monitoring založený na MII fungovat může - jenže většinou nejsi schopný zajistit, aby ten link opravdu padnul. Běžnější je spíš stav, kdy fyzicky link je, ale nefunguje to.

Mě to fungovalo proti dvěma Ciscům, kde jsem byl v jedné VLANě. Takže i v tom ARPu jsem vlastně viděl oba targety. Na sekundár to přepnulo jen když se něco stalo na kabelu z primáru. A zpět se to vracelo.