classic.ISPforum.cz

Ahoj,
pokud to nemáte jako svoje interní tajemství, jak řešíte zálohování na 60G pro chvíle výpadků? Zatím to trénuji na stole a s žádným řešením nejsem úplně spokojený. Mým cílem je 60G hlavní + backup na 5G s hysterezí ve chvíli kdy hlavní spoj padá (z důvodu deště) a v krátkých chvílích se rozpojuje a spojuje(EDIT:špatný popis, nerozpojí se, ale ztrátuje) (aby se pořád nevracel backup na hlavní a znovu a znovu) ...... možná řešení technického problému:
RSTP:
- cca 6s výpadek max
- nemá hysterezi
+ jednoduché na konfiguraci
OSPF + bfd:
- pro transparetní spoj vyžaduje nasadit nad tím mpls+vpls, složité na konfguraci, vlana pro druhý spoj
- nemá hysterezi
+ výpadek cca 2s
OSPF'+ custom script
- pro transparetní spoj vyžaduje nasadit nad tím mpls+vpls, složité na konfguraci, vlana pro druhý spoj
- vyžaduje dobře napsaný skript pro detekci chybovosti spoje (u mk jak známo nemusí v budoucích verzích fungovat, nutnost údržby)
+ výpadek cca 2s
+ lze naprogramovat hysterezi pro návrat

Používáte něco jiného co mě nenapadlo?

EDIT: Funkční skript na hysterezi jsem postnul níže.

Nabízí se ještě varianta známá z profispojů - "port down on link down" - hysterezi řídí scriptem samotná wAPka, která jako jediná má přehled o stavu radiové trasy. Nad tím už jakýkoli protokol s rozumnými timery. Mám v plánu něco takového brzo vyzkoušet, mordor se už blíží

Ok, to je trochu jiný přístup nežli kontrolovat nedostupnost protistrany pomocí icmp. Reálně znám totiž třeba na mimose i ubnt spoustu stavů, kdy linka ztátuje, ale link down není (u profi spojů je to jiné proti wifi). U 60G je to podobné, vyzkoušet se to dá lehce - dáš ruku před zářič, link down není, ale spoj ztrátuje. Touhle cestou nepůjdu. Hysterezi mi řeší skript na samotném 60G radiu.

Ta moje třetí varianta:
Zapojení vypadá tak, že jsou spojené dvě 60G a routují. Pak mají mezi sebou ještě přes lan port propojku přes vlanu a přes jiný spoj, zase routují. Celé to řídí ospf jen mezi dvěmi 60G, nad tím celém stojí mpls/vpls aby to ve finále dalo transparentní propoj. Problém je s tím skriptem (napsal jsem ho, fungje to dobře), ale raději bych použil něco standartizovaného.

no koukám že u mikrotiku to zase nedodělali u BFD

pgb píše:Ok, to je trochu jiný přístup nežli kontrolovat nedostupnost protistrany pomocí icmp. Reálně znám totiž třeba na mimose i ubnt spoustu stavů, kdy linka ztátuje, ale link down není (u profi spojů je to jiné proti wifi). U 60G je to podobné, vyzkoušet se to dá lehce - dáš ruku před zářič, link down není, ale spoj ztrátuje. Touhle cestou nepůjdu. Hysterezi mi řeší skript na samotném 60G radiu.

Ta moje třetí varianta:
Zapojení vypadá tak, že jsou spojené dvě 60G a routují. Pak mají mezi sebou ještě přes lan port propojku přes vlanu a přes jiný spoj, zase routují. Celé to řídí ospf jen mezi dvěmi 60G, nad tím celém stojí mpls/vpls aby to ve finále dalo transparentní propoj. Problém je s tím skriptem (napsal jsem ho, fungje to dobře), ale raději bych použil něco standartizovaného.

Jasně, operation down status na wlan je až poslední fáze rozpadnutí (u profispojů ostatně taky, bereme-li v úvahu ACM, proto taky existuje standard na předávání informace o modulační rychlosti na nejbližší switch/router, který podle toho může balancovat trasy). Na wifině by šla klidně hlídat modulace, na 60 GHz signál nebo použít ICMP. Zásadní mi přijde rychlost předání informace o nedostupnosti a potom ta hystereze. Když shodím port, je reakce prvku na druhé straně okamžitá i v případě OSPF, RSTP. A wAPka pak bude koukat na signál, pingat a když minutu dobrý, tak port zapne. Zatím je to jen vize, skusím to napsat a otestovat.

Tvé řešení vypadá hezky (rychlost předání si řeší interně wAPka, hysterezi script), jen by mi úplně nevyhovovalo z hlediska topologie - při pádu jedné linky posílám provoz často jinudy, ne paralelním záložním spojem na stejný bod.

Pokud to posíláš jinudy, tak to situaci samozřejmě trohu komplikuje. Ano ... (jen pro vysvětlení pro ostatní - neshazuji port fyzicky), pouze v interfacu ospf, jinak by skrz něj nešlo dělat kontrolu jak to vypadá. Dokončil jsem ten skript na paralelní trasu. Není to žádná krása, ale funguje to dobře, někomu to třeba bude sloužit pro inspiraci. Nepouští se to každou minutu, ale pouze jednou po startu - běží to v cyklu a funguje to kvalitně. Posílá icmp na cílový host a pokud detekuje výpadek, tak ten port v ospf na 30s vyřadí, pak zkusí znovu icmp a pokud po 30s projde tak ho povolí.Takhle to pošle jedno icmp za sekundu, díky shození ospf interfac u se to za 2s překlopí celé.

edit: ten skript s hysterezí ti bude takhle fungovat i ve tvém setupu, když data posíláš zálohou jinudy. Stačí ho nasadit na správném zařízení

Skript na hysterezi:


edit: skrip upraven, vypnout se dá pomocí příkazu v konzoli

ja to mam poriesene cez skripty.... ako nahle sa strati 20 pingov prehodi na backup a je jedno ze po 20 pingov to uz ide pokial to nepojde 100 pingov bez vypadku dva krat po sebe v 5 minutovych intervaloch neprepne spat....

a po tych 10 minutach yz vzdy dazd ustali a ak sa nestratit ani jeden ping tak to v klude prepne na 60...

A jak prosim docilit toho, aby testovana IP adresa nebyla dostupna pres zalozni linku? V okamziku kdy se 60G spoj rozpoji, tak bude protejsi testovana ip adresa dostupna pres zalozni linku. Premyslim jak to upravit. Mam rozjete OSPF tak, ze se automaticky diky cost prepinaji linky. Dekuju za radu.

udělej to tak jak ti kreslím, fungovalo to dobře na FSO:


To znamená na každé straně máš bridge RSTP jedna ta bridge cesta má jiný cost než druhá, ty si budeš scriptem pingat a zjištovat průchodnost trasy pomocí těch privátních ip adres 192.168. pokud script vyhodnotí průšvih tak ihned vyhodí trasu port z bridge tím dojda k okamžitému přepnutí trasy, for je v tom že ty privátní ip stále budou fungovat takže si můžeš stále scriptem ověřovat jestli ta shozená trasa je už ok nebo jestli stále chybuje, je to prosté a jednoduché....

ale preci se musi pingat nejdrive 0.2... za 60G spojem. Jakmile padne tak je stale dostupna pres 5G, tudis normalne se nepozna ze 60 je OK... nasledne po vypadku se musi kontrolovat IP 0.1. pres 5G zalohu zase na druhy konec za 60G. Za predpokladu, ze nebude 5G chybovat taky což je problem zase... nebo se mylim?

no není protože ty ip jsou privátní a nejsou v bridge!, jako pokud bude chybovat 5G tak není kam přepnout, to chybovat nesmí to je snad jasný

zakladem prepnuti by mela byt prahova hodnota signalu a ne rozpadnuti linky. U MK to nejde asi zajistit jinak nez prave pres script. Ostatni vyrobci definuji failover.

no jo no to je vyšší dívčí pro mikrotik, prostě co bych za to dal, bohatě by stačilo dát port down.
jako ale myšlenka dobrá určitě by to šlo nascriptovat aby ti to při určitém signálu vyřadilo z bridge na tom LHGG eth1 a tím by se to ihned přeplo proč ne, to moje řešení bylo na FSO které nemělo žádné scriptovací možnosti, nic.

každopádně to řešení co tu píši funguje naprosto exceletně a každý si to může ohnout jak potřebuje, podstatné v tom řešení je že přepnutí na zálohu prakticky zákazník nepozná, vypadne ping maximálně dva, právě trochu mě mrzí to že ubnt záloha 5GHz u 60GHz takto nefunguje a člověk si pomalu uvaří kafe než se to přepne

okoun píše:udělej to tak jak ti kreslím, fungovalo to dobře na FSO:
zaloha.jpg

To znamená na každé straně máš bridge RSTP jedna ta bridge cesta má jiný cost než druhá, ty si budeš scriptem pingat a zjištovat průchodnost trasy pomocí těch privátních ip adres 192.168. pokud script vyhodnotí průšvih tak ihned vyhodí trasu port z bridge tím dojda k okamžitému přepnutí trasy, for je v tom že ty privátní ip stále budou fungovat takže si můžeš stále scriptem ověřovat jestli ta shozená trasa je už ok nebo jestli stále chybuje, je to prosté a jednoduché....

Toto ale jestli to dobre chapu predpoklada, ze na kazde strane spoje musim mit nejaky router, kde ten bridge udelam, tj. pokud jsou obe jednotky na kazde strane zapojeny do ne-mikrotik routeru, tak mam asi smulu. Pochopil jsem to spravne?

pokud tam máš rozumnej switch, tak se to dá udělat i s pomocí vlan a na LHGG b vridgi budeš přepínat mezi vlan a 60gwifi interfacem