Používáte v síti RSTP máte na MK zapnuto nebo vypnuto ?
RSTP zapnuté nebo vypnuté
taky zalezi na jakem MK. Nekde ho mit zapnute znamena ztratu propustnosti.
S Mikrotikem používám i MSTP. Ale jak kde. Záleží na topologii. Každopádně u každé trochu složitější sítě je dobré to zapnout, nebo to může skončit jako parlament na Slovensku, kde poslanec udělal smyčku tím, že propojil dva porty na switchi a celé to šlo dolu... 
Zdar Max
maxdevaine Tak az budem opet neco opravovat, mam to testnou?
Zdravim 
o 2 roky později
Stale je to RSTP na Mikrotiku spatne?
S narustajicima 60G a potrebou zaloh mame nejakych lokalitach vice vysilacu v ramci jedne obce zakruhovane. Snazime proto drzet jeden rozsah v ramci obce aby prave bylo mozne i treba kvuli poruse jedne trasy vse preklopit tak nebo tak. Mockrat se nam to vyplatilo a usetrilo hodiny a hodiny vypadku. Nebo jsme nemuseli vylozene hned vyjizdet a opravili pozdeji a klienti vylozene nic nepoznali.
Vse je only MK s temer stejnou verzi... Ted jsme pridali dalsi trasu a dle meho to asi neni chyba RSTP, ale v takove slozitosti uz potreba nejakeho specifistejsiho nastaveni.
Pouziva to nekdo aktivneji? Zkousim nastavovat costy na ten interface ale spis to delam blbe a nevim presny postupy a principy...
Diky
Backhauly je obecně lepší řešit na L3 (OSPF).
to mam. Obecne co obec, tak router... privody ospf... ale pak v ramci obce 2 - 5 vysilacu ruzne okruhove propojeny... na jednom rozsahu... Tak to potrebuji tim rstp na L2 udelat tak aby cesta tekla tudy kama ma, a kdyz neco padne tak se prepocita a posle jinudy...
Takže máš jeden router v lokalitě, z něj máš 2 a víc uplinků L3 přes OSPF a z toho routeru máš lokální L2 kruh přes 2 a víc vysílačů už jen s RSTP?
Co ti na tom nefunguje? To vypadá celkem "jednoduše" a snad i funkčně, pokud rádia moc neblbnou, neztrácejí se pakety a linky nejsou ucpané na 100%... A doufám, že ty rádia tvořící kruh jsou v režimu point-point proti sobě a není to i multipoint na kterém visí i koncoví klienti. :-)
Já to provozuji jen na kabelových sítí a aktuálně mi to funguje všude v pohodě (i v kombinaci s random switchi od HPE/Huawei/Cisco/TP-Link). Na bezdrátu bohužel nevím. Dřív (před ROS 7) jsem to na Tiku nikdy nepoužíval, takže nemohu pouzovat rozdíl.
- Upraveno
majklik 
ano, taky jsem se te diskuze docetl. Jsou tam tyto "blbe pripady". Jedine o co mi jde, zda i s tim multipointem lze technicky neco delat. Nebo proste tento pripad neni jak osetrit?
Jinak ano, co obec a propojeni mezi obcemi jsou vetsinou ptp jeden nebo 2. Vetsina site je propojena kruhem coz ridi OSPF.
Jinak v ramci je jedna sit, ktera dle moznosti tvori kruh nebo i vice kruhu s tim, ze tam jsou ptp ale i pripady multipointu.
Tzn kdyz jsou treba 4 vysilace, coz jsou klasicky bridge, + mezi tim je bud 5G nebo 60G zase v bridge jeden nebo 2 spoje...
Pak jsou treba ty multipointy, kde rekneme je (bytovka) jako klient 60G na jeden vysilac ptmp s tim ze ta bytovka vidi na jiny vysilac, kde je druhy klient 5G...
Coz chapu neni idealni, ale zase pri pripad jakehokoliv vypadku se to sakra hodi...
Nerikam, ze je potreba mit vsechno takto temi ptmp zdvojene ci ztrojene... Nechal bych si nejake ty ptmp az treba na rucni zasah...
Spis by me zajimaly takovy ty jednoduchy rychly principy jak pracovat s prioritama a costama...
Root bridge vim, ty mam definovany, a pak nasledne sleduji root path cost, kde predpokladam, ze mi to rika "cenu/pocet skoku k rootovi"
Diky
- Upraveno
basty OK. První upozornění - RSTP (a MSTP) není bez smyčkový protokol - jakmile je to víc než primitivní zapojení a pohne se víc věcí naráz, můžou vznikat krátkodobě otevřené smyčky (v podstatě v trvání do hello intervalu, takže 2 sec default), takže je třeba mít v dané L2 doméně vše odolné občasné paketové bouři (tu je třeba brzdit např pomocí horizontování na tom koncovém klientu mezi 5G a 60G portem). Riziko vzniku otevřených smyček výrazně roste, pokud mezi bridgi s aktivním RSTP nebudou čisté přímé PtP propoje (rozuměj, mám třeba mikrotika/switch s aktivním RSTP a do jeho metalických portů nastrkány třeba cube rádia a tyto rádia budou mezi metalikou a rádiem jako čistý bridge bez rstp, podobně je, když mezi metalické porty nacpu externí FX/TX převodníky na optiku).
Pak je třeba mít ošetřeno, aby ti nemohlo přijít "cizí" BPDU od klientů, které by ti tu síť převrátilo. Což už jde hlídat v ROS7 pomocí BPDU guard nebo restricted role na portu. Plusem je i ta auto isolate funkce, která umí brzdit start (bohužel neumí hlídat vytuhnutí už sestavené linky - izolovat port, pokud najednou přestane nečekaně BPDU chodit).
Pokud ty PTMP sektory jsou jen mířeny na koncové klienty, tak se s tím dá asi něco dělat, takže to PTMP AP rádio bude vždy a jen pouze jako otevřený forwarding/designed port, musím se vyhnout konfiguraci, aby se stal root/alternate/backup portem, pak se s tím dá žít (čili na něm musí být ta restricted role).
Priorita bridge asi volit jasně tak, aby byl na tom rotueru a pak postupně jdeš dolů. Počet skoků k rootovi se při volbě root portu nepoužívá. Hraje se dle té nasčítané cost od roota směrem dolů. Taktéž priorita portu je ti fakticky jedno - je to až poslední rozhodovací parametr a jen v případě, kdyby jsi měl dvě linky paralelně k nadřazenému bridgi (kdybych měl na AP vedle sebe 60G i 5 G sektor, oběma těm linkám dal stejnou cost a koncový klient byl připojen na ten 60G a 5G současně, tak jenom zde by rozhodovala priorita portu - použije prioritně tu nižší ohlašovanou od nadřazeného bridge).