problém s ospf, rozkmitání sítě

[okoun]

Ahoj, prosím o radu ohledně ospf. Na jednom bodě kde se rozchází internet do vícero směrů nastane problém s routováním, když mi vypadne jeden z koncových směrů (ifaců). Cca na 10 sec vypadne skoro celá síť (ostatní koncové směry) protože se začnou posílat nové routy, které jsou ale stejné, jelikož nikde není žádný kruh a všude jsou stejné costy. Nevím proč se to děje a kde je problém. Na bezdrátech je samozřejmě všude nastaveno statické Running

Ospf:

Kód: Vybrat vše

[p@p > routing ospf export # may/18/2012 09:08:44 by RouterOS 5.16 # software id = 87NW-BTF1 # /routing ospf instance set [ find default=yes ] disabled=no distribute-default=never in-filter=ospf-in metric-bgp=auto metric-connected=20 \ metric-default=1 metric-other-ospf=auto metric-rip=20 metric-static=20 name=default out-filter=ospf-out \ redistribute-bgp=no redistribute-connected=no redistribute-other-ospf=no redistribute-rip=no redistribute-static=no \ router-id=10.55.3.0 /routing ospf area set [ find default=yes ] area-id=0.0.0.0 disabled=yes instance=default name=backbone type=default add area-id=0.0.0.1 disabled=no instance=default name=ospf_matejov type=default /routing ospf interface add authentication=none authentication-key=xxxxxx authentication-key-id=1 cost=10 dead-interval=40s disabled=no \ hello-interval=10s instance-id=0 interface=all network-type=broadcast passive=no priority=1 retransmit-interval=5s \ transmit-delay=1s use-bfd=no /routing ospf network add area=ospf_matejov disabled=no network=10.55.3.0/25 add area=ospf_matejov disabled=no network=10.55.3.252/30

Iface

[img]iface.jpg[/img]

[tom-tom]

A co to má společného s kmitáním? Rozsekej ty větve na jednotlivé areas, na velikosti sítě nezáleží. Proč by se měly zbytečně přenášet všechny routy z jednoho konce sítě na druhý. Prostě je v tom bodu rozděl ať jsou ty konce nezávislé a máš pokoj.

[hapi]

hehehe... a já už vim čim to je.

mikrotik má tak tochu malej neduh v bridge. Když se mu deaktivuje nebo aktivuje jeden iface v bridge, je schopnej celej bridge inicializovat znova a to způsobí mimo jiné i výpadek OSPFka tedy přesněji řečeno pošle OSPFku že se odpojil iface a to okamžitě pošle okolním routerům že všechno na tom iface už neni dostupný touto cestou. Tim se znova začne sestavovat OSPFko.

řešení? mnoo teoreticky by mohlo pomoci disable-running-check na ethernetech a pro jistotu to prubnout i na ten bridge. Pokud je možný, udělat extra subnety na každej iface nebo skusit ty porty propojit master portem případně nejlépe to pospojovat externím switchem a bude klid.

[ludvik]

Tak přesně kvůli tomu, že zmizení linku na eth zruší i propagaci routy do zbytku ospf používám bridge. Pak si může padat jak chce ...

disable-running-check na ethernetech by pomoci mohlo, ale kdo donutí MK k tomuto parametru? Ale neřekl bych, že je to jeho problém.

hehehe... a já už vim čim to je.

mikrotik má tak tochu malej neduh v bridge. Když se mu deaktivuje nebo aktivuje jeden iface v bridge, je schopnej celej bridge inicializovat znova a to způsobí mimo jiné i výpadek OSPFka tedy přesněji řečeno pošle OSPFku že se odpojil iface a to okamžitě pošle okolním routerům že všechno na tom iface už neni dostupný touto cestou. Tim se znova začne sestavovat OSPFko.

řešení? mnoo teoreticky by mohlo pomoci disable-running-check na ethernetech a pro jistotu to prubnout i na ten bridge. Pokud je možný, udělat extra subnety na každej iface nebo skusit ty porty propojit master portem případně nejlépe to pospojovat externím switchem a bude klid.

[hapi]

Tak přesně kvůli tomu, že zmizení linku na eth zruší i propagaci routy do zbytku ospf používám bridge. Pak si může padat jak chce ...

disable-running-check na ethernetech by pomoci mohlo, ale kdo donutí MK k tomuto parametru? Ale neřekl bych, že je to jeho problém.

hehehe... a já už vim čim to je.

mikrotik má tak tochu malej neduh v bridge. Když se mu deaktivuje nebo aktivuje jeden iface v bridge, je schopnej celej bridge inicializovat znova a to způsobí mimo jiné i výpadek OSPFka tedy přesněji řečeno pošle OSPFku že se odpojil iface a to okamžitě pošle okolním routerům že všechno na tom iface už neni dostupný touto cestou. Tim se znova začne sestavovat OSPFko.

řešení? mnoo teoreticky by mohlo pomoci disable-running-check na ethernetech a pro jistotu to prubnout i na ten bridge. Pokud je možný, udělat extra subnety na každej iface nebo skusit ty porty propojit master portem případně nejlépe to pospojovat externím switchem a bude klid.

a proto jsem přestal používat bridge a začal jsem enablovat tu funkci

Kód: Vybrat vše

interface wireless set wlan1 disable-running-check=yes

samozřejmě na kruhu je tahle funkce nežádoucí. Tam očekávám přepočet okamžitě.

[okoun]

tak a jsem v čoudu, bohužel na ethernety nejde příkaz disable-running-check, co teď?

[ludvik]

Jojo, hapi mluví o ethernetu, ale myslí wifi kartu ... Stejný problém se tu dá myslím alespoň jednou nalézt

Podle mě ti nikdo neporadí. Nedá se v tom moc vyznat.
Vypadne ti v tu chvilku jaká síť? Nějaká za tímto routerem (z routeru za bridgem) tady, nebo "connected" tohodle routeru (/25) na těch ostatních za wlan1?
Ten export ospf oprav. Ať se to dá číst. Přidej i ip/addresses a ip/routes
Nakresli toho víc. Kam co vede, a co zmizí, když něco (vlastně nevíme co) vypadne.
Máš vůbec správně tu areu? Je 0.0.0.1 někde společně s 0.0.0.0?

V době výpadku vysleduj, jak ten bridge vypadá. Třeba má hapi pravdu a mikrotik něco přepočítává (i když STP pravděpodobně na bridgi zapnutý nemáš) a bridge je opravdu neaktivní.

Ono je to vůbec takové divné. Když routovat, tak pořádně. Nebridgovat pokud nemusíš. Vnášíš do toho další softwarovou vrstvu a znáš mikrotik ... Můžeš mít jenom nějakou verzi s nedokumentovaným bugem.
Dobrý zvyk je v ospf interfaces mít každý zvlášť, nikoliv "all". Už jenom proto, že COST znamená přesně to, co překlad ... cenu toho spoje. Tvoje wlan1 určitě není srovnatelná s tím bridgem. Sice by to mít vliv nemělo (zvlášť když nemáš zakruhováno), ale člověk nikdy neví. Dost často se zjistí, že někde kolečko nakonec možná je ...

A třeba já areu 0 na mikrotikovi nikdy nezakazuju, ani když není použitá.

tak a jsem v čoudu, bohužel na ethernety nejde příkaz disable-running-check, co teď?

[hapi]

Jojo, hapi mluví o ethernetu, ale myslí wifi kartu ... Stejný problém se tu dá myslím alespoň jednou nalézt

ne, myslim ethernet. Nevim jestli je to v zavislosti na verzi mk nebo chipu ethernetu ale jde to na ne pouzit taky.

[ludvik]

Podle mě to bývalo v 2.9.x verzích a/nebo možná jen pro x86. V každém případě z MK nikdo neodpověděl a z jiné odpovědi mám takovej pocit, že mají v hlavách zakódováno "chceme být cisco" a už si neuvědomují, že pro SOHO jsou potřeby trochu jiné. Což se projevilo také když jsem se s nimi hádal o IPv6 (aneb - domácí router je router, měl by přijímat RA. Oni - router nesmí přijímat RA, howg).

Kód: Vybrat vše

The option disable-running-check is there for historical reasons especially for ROS which is running on x86 with cheap Ethernet cards like realtek with bad interrupts which clog up the CPU when disable-running-check=no and also is a good option for wireless interfaces for the same reasons.
Definitely it wasn't designed to be used for tricking OSPF into thinking that interface is up and so to propagate the sub-net into routing table. For this purpose use loop-back.
On CISCO there's no disable-running-check option and loop-back it's been used with success for years.


Jojo, hapi mluví o ethernetu, ale myslí wifi kartu ... Stejný problém se tu dá myslím alespoň jednou nalézt

ne, myslim ethernet. Nevim jestli je to v zavislosti na verzi mk nebo chipu ethernetu ale jde to na ne pouzit taky.

[tom-tom]

tak a jsem v čoudu, bohužel na ethernety nejde příkaz disable-running-check, co teď?

a to všichni děláte sítě tímto způsobem, že se vezmou všechny ethernety a wlany co routerboard má a svážete je do jednoho bridge?

[hapi]

Podle mě to bývalo v 2.9.x verzích a/nebo možná jen pro x86. V každém případě z MK nikdo neodpověděl a z jiné odpovědi mám takovej pocit, že mají v hlavách zakódováno "chceme být cisco" a už si neuvědomují, že pro SOHO jsou potřeby trochu jiné. Což se projevilo také když jsem se s nimi hádal o IPv6 (aneb - domácí router je router, měl by přijímat RA. Oni - router nesmí přijímat RA, howg).

Kód: Vybrat vše

The option disable-running-check is there for historical reasons especially for ROS which is running on x86 with cheap Ethernet cards like realtek with bad interrupts which clog up the CPU when disable-running-check=no and also is a good option for wireless interfaces for the same reasons.
Definitely it wasn't designed to be used for tricking OSPF into thinking that interface is up and so to propagate the sub-net into routing table. For this purpose use loop-back.
On CISCO there's no disable-running-check option and loop-back it's been used with success for years.


Jojo, hapi mluví o ethernetu, ale myslí wifi kartu ... Stejný problém se tu dá myslím alespoň jednou nalézt

ne, myslim ethernet. Nevim jestli je to v zavislosti na verzi mk nebo chipu ethernetu ale jde to na ne pouzit taky.

zajímavé, v5.14 a gigový intely a ta funkce tam stále je. Jak tedy na ten loopback? mě nic nenapadá.

[ludvik]

Takže to umí jen x86 verze (já to nepoužívám, takže neznám). By mě zajímalo proč ne všechny ...

Loopback, vzhledem k tomu, že se mikrotik nenaučil dummy rozhranní, lze udělat jen bridgem. Ani v něm nemusí být žádné rozhraní. Jenom je asi vhodné si tam vymyslet nějakou MAC z privátního rozsahu.

zajímavé, v5.14 a gigový intely a ta funkce tam stále je. Jak tedy na ten loopback? mě nic nenapadá.

[hapi]

no ale co to má společnýho s disable-check-running?

napadá mě jenom to, že když lehne jedno rozhraní ze kterýho si to vzalo router-id, tak se logicky ospfko resetne a začne sestavovat znova. Tohle vyřeší ručně zadaný router-id.

jo a ještě k tý v5.14, disable check running tam bylo při instalaci zapnuto automaticky.

[ludvik]

Boha ... nic to nemá společnýho. Ty jsi s tím začal. A mě zajímalo, kde to vlastně na ethernetu vůbec funguje ... na routerboardech rozhodně NE.

no ale co to má společnýho s disable-check-running?

Router-id tam má zadaný ručně. Kromě toho si myslím, že pokud by zadaný nebyl, tak si ho vezme jenom jednou. Při startu. A teoreticky by mu neměl vadit link down.

napadá mě jenom to, že když lehne jedno rozhraní ze kterýho si to vzalo router-id, tak se logicky ospfko resetne a začne sestavovat znova. Tohle vyřeší ručně zadaný router-id.

jo a ještě k tý v5.14, disable check running tam bylo při instalaci zapnuto automaticky.

[hapi]

no a teda na co je ten bridge. Vim o tom ze bridge davaji kvuli administraci a berou tu ip adresu na bridge jako id-router.


pokud padne iface z kteryho si to vzalo id-router tak tusim ze ospfko jede znova.