neznáte někdo fígl, jak donutit mikrotika, aby přes OSPF propagoval síť i když je dané rozhraní down?
U wifi karet funguje parametr disable-running-check, ale u ethernetu nic takovýho není (byť dle manuálu by být mělo).
Všiml jsem si toho až teď, co se nám vrátil z reklamace jeden routerboard s mikrotikem V3rc9 a jak na potvoru na eth není momentálně nic připojeného.
ospf na mikrotiku jede super verze 3,15 , jenom je dat bacha na silu linky cim mensi rozdily tim to lepe funguje , nemichejte routry postavene na linuxu a mikrotikem sit se potom houpe pokud mate vice kruhu , oddelovat routry roydelenim site , nemejte na jedne siti - treba x.x.x.0/28 vice spoju , cim vice to rozdelite tim lepe , do dualstreemu je ybytecne davat vetsi sit nez je x.x.x.x/30 , hlavne nezapomente si sit zapsat , treba do nagiosu , ono se tezko pamatuje 200 spoju
No - nemíchat softwary na routerech jde v našem prostředí dost blbě ... Ale to nebyl ten problém. Pokud chceš zamezit "houpání" ospf, musíš důkladně rozdělovat síť do area. Nějaké hrátky s costama a ip sítěma nemají smysl.
Problém je, že ethernet (tedy ne wlan) ve stavu down nepropaguje routu ("network" direktivu) do OSPF. Využít bridge mě teda nenapadlo ...
Jediné RB co mají s naším počtem rout problémy jsou nejslabší typy jako RB133 a podobně. Ty ale jsou pouze u klientů a mají většinou nastavené statické routování a propagaci do OSPF u nich provádí nadřazený router. S Wrapy nemám zkušenosti, pracděpodobně u nás není ani jeden.
Pokud začne OSPF blbout po výpadku proudu, je zjevně problém v mikrotiku a nikoliv v kombinaci mikrotik/linux (či něco jiného). Už jsem viděl pár spojů, kde se po nějakých změnách nechtělo OSPF spojit a pomohl až kompletní restart, ale jednalo se o místa, kde okolo běžely samé mikrotiky, takže nekompatibilitou různých implementací OSPF v různých OS to být nemohlo. Nicméně nic není bez chyb, tak se stát může lecos.
01.11.2007 v 16:06
