problém s rozpojováním OSPF

pajas

Ahoj, tušíte někdo, v čem by mohl být problém (kde je chyba) s rozpojováním OSPF. Jedná se o záložní 5G linku a na spoji mám udělanou VLANu.

Spoj jako takový je bez výpadků. RoS 6.34.6

<--- ia1 -->full-to-down-klient.png<--- ia1 -->

<--- ia0 -->full-to-down-AP.png<--- ia0 -->

díky za rady!

ludvik

Bez výpadku to není. Prostě tam ten multicast občas nechodí.

pajas

Ve statusu bezdrátu i VLANu je "Link Downs=0".

Dá se to nějak řešit? Změnit něco v nastavení NV2 ?

ludvik

To nevím. Na "páteře" už mikrotiky nepoužívám.

Ztrátovost a úplné rozpadání spoje jsou dvě různé věci. Teoreticky můžeš na tom spoji v OSPF zvýšit na obou stranách dead interval.

pajas

Dead interval jsem zkoušel zvýšit ze 40 na 50 a žádná změna.

drakk

V jakém rezimu máš ten spoj? Nerozpojuje se na wifi části?

zemji

Ahoj,

také mi to dělá jeden spoj, veškerý HW vyměněn a stále stejné, u mě je to asi způsobeno překážkami ve fresnelce. Problém se spojem to nevyřeší, ale OSPF se nerozpojuje když nastavím v OSPF NBMA neighbors.

Jirka.

k3ny

pres jake zarizeni ty multicasty chodi ?

pajas

Zdravím,

je to záložní spoj, klient (režim station) je 711 v parabole proti APčku (režim APbridge), což je Groove na nějaké 90st sektorce, jinak tam je pár klasických klientů.

Ve statusu wifi čísti to žádné výpadky nepíše.

Jak nastavím to OSPF NBMA neighbors ???

díky

zemji

Ahoj,

Routing->OSPF-> NBMA neighbors tam přidat IP adresy ostatních routerů ve stejné IP síti (v případě PtP jen jednu). Toto na obou stranách. Trasa je stále na prd, ale už nepadá OSPF.

Jirka.

majklik

Použití NBMA by v tomto případě mohlo pomoci, zvláště pokud to APčko je v klasice 802.11 a motá se tam víc wifi klientů, co se vzájemně neslyší. Při NBMA se použije mezi OSPF konci unicast komunikace místo multicastu. Multicast na wifině dělá to, že pro přenost multicastu se u většiny režimu přepne na chvíli na základní modulační rychlost, což někdy blbne, že to protistrany nepoberou a vysílají do toho.

hapi

multicast helper... jinak bych nevinil ospfko za chyby když ten spoj je tragickej sám o sobě. A navíc pokud to je ptp spoj tak použít ptp režim ospfka. NBMA se mi moc nelíbí protože to už není dynamický když musim vyplňovat sousední routery.

majklik

Tobě ten multicast helper v něčem pomohl? Dost jsem měl problém dosáhnout něčeho rozumného. Jako bod-bod spoj z logiky OSPF to provozuje, ale pokud použije peer-to-peer reřim OSPF, tak to stále jede v multicastu, jen se odbourají blbosti s DR/BR volbou. Ale když fyicky to má sektor pro X klientů a jedne klient je jen OSPF link, tak to nikdy nbude rock-stable.

Souhlas, že NBMA je opruz konfigurovat udržovat. Ale pokud s emu sere jende tento spoj takto, tk ať to zkusí a uvidí...

hapi

multicast helper by měl "zabalit" multicast a broadcast do unicast paketu a protlačit ho skrz wifi včetně sledování toho jestli opravdu dorazil na druhou stranu a plnou rychlostí. Jo jinak ospf v ptp jede tušim stále v multicastu akorát jak píšeš, nezdržuje se DR/BR ale píše že má problém na backup spoji tak předpokládám ptp spoj. Základ je mít stabilní wifi spoj. No je fakt že by to asi NBMA řešilo. Někde sem to dělal a nějak se nepochopil ty priority a poll interval a občas se stalo že ani to se mezi sebou nedomluvilo... noo ospf je na mkčku dost zvláštní a nejvíc mě vytáčí když napíše "master status flag false" když je to ptp s definovanou prioritou kde jeden má 0 a druhej 1 atd.. nebo že se vůbec nerozjede ospf dokud se nezakáže a nepovolí instance... k naštvání. A to vůbec nemluvim o to že to nějak ignoruje prioritu def rout atd...

selic

Zdravím,

je to záložní spoj, klient (režim station) je 711 v parabole proti APčku (režim APbridge), což je Groove na nějaké 90st sektorce, jinak tam je pár klasických klientů.

Ve statusu wifi čísti to žádné výpadky nepíše.

Pokud není spoj vyloženě zarušen, tak může být problém v té 711. Svého času jsem měl 711 také na páteři ptp a pozoroval jsem poměrně velé množství "laggů", kdy v logu mikrotiku nebylo nic, ale při podrobném sledování provozu docházelo nepravidelně k přerušení datového toku na několik desetin sekundy až skoro 2sekundy. Dělalo to i v rádiově čistém prostředí několikrát za hodinu. V mnohem menší míře to dělá i po náhradě RB911 L3.

Klient to pozná jen pokud hraje nějakou online střílečku nebo pouští HD video.

Jediné zlepšení nastalo pokud byly obě strany nahrazeny za RB912 s verzí cca 6.33 a vyšší, pak tyto mikrovýpadky prakticky zmizely.

Nezdá se mi, že by to bylo někde na ethernetu - dělal to i spoj zapojený přímo do shaperu s omezením rychlosti na postatně méně než 100Mbit.

Skoro to vypadá jako by procesor v 711 z nějakého záhadného důvodu zaškobrtnul.