pokial tam budes mat bridge nemas tam v konecnom dosledku 3 subnety ale len jeden => jednoduchsi sietovy dizajn. V navaznosti na to tam mas viac ospf susedov a v podstate uplne zbytocne.
Ja osobne by som radsej routing zveril tym dvom RB800 kedze je to kusok silnejsie zelezo.
Pri tom routingu mas vacsiu sancu ze ti nieco s cpuckom zacivici napr spusteny conntrack...
Routing bude mat o nieco vyssie latencie nez bridge-ing. (v tom setupe bude v mac tabulke kolko zaznamov? A kolko ich bude v routovacej v pripade celej siete? Pri Single Area aj vcelku dost ..) atd atd ..
No co si budeme hovorit ...
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
problém s ospf, rozkmitání sítě
tak teď už v tom mám úplně bordel a nevím jak to dělat bez toho abych měnil HW na bodech
0 x
lukas-svk píše:pokial tam budes mat bridge nemas tam v konecnom dosledku 3 subnety ale len jeden => jednoduchsi sietovy dizajn. V navaznosti na to tam mas viac ospf susedov a v podstate uplne zbytocne.
Ja osobne by som radsej routing zveril tym dvom RB800 kedze je to kusok silnejsie zelezo.
Pri tom routingu mas vacsiu sancu ze ti nieco s cpuckom zacivici napr spusteny conntrack...
Routing bude mat o nieco vyssie latencie nez bridge-ing. (v tom setupe bude v mac tabulke kolko zaznamov? A kolko ich bude v routovacej v pripade celej siete? Pri Single Area aj vcelku dost ..) atd atd ..
No co si budeme hovorit ...
bla bla bla bla.
jakto že má routing větší latence? to je zajimavá teorie.
máme tu i na RB133 okolo 200 rout a nějak jí to netíží.
0 x
Na ostatne nezareagujes?
ad latencia: Uplne normalne, latencia stupa s velkostou routovacej tabulky ty trdlo .. nemusis to vidiet, ale je to tak. Ked sa nasklada viacero hopov tak tam rozdiel bude. 200 rout na routerboarde 133 .. slusny vykon.
Nejak neviem ci ti ma zmysel tu pisat nieco viac.. proste rob co musis.
L.
ad latencia: Uplne normalne, latencia stupa s velkostou routovacej tabulky ty trdlo .. nemusis to vidiet, ale je to tak. Ked sa nasklada viacero hopov tak tam rozdiel bude. 200 rout na routerboarde 133 .. slusny vykon.
Nejak neviem ci ti ma zmysel tu pisat nieco viac.. proste rob co musis.
L.
hapi píše:lukas-svk píše:pokial tam budes mat bridge nemas tam v konecnom dosledku 3 subnety ale len jeden => jednoduchsi sietovy dizajn. V navaznosti na to tam mas viac ospf susedov a v podstate uplne zbytocne.
Ja osobne by som radsej routing zveril tym dvom RB800 kedze je to kusok silnejsie zelezo.
Pri tom routingu mas vacsiu sancu ze ti nieco s cpuckom zacivici napr spusteny conntrack...
Routing bude mat o nieco vyssie latencie nez bridge-ing. (v tom setupe bude v mac tabulke kolko zaznamov? A kolko ich bude v routovacej v pripade celej siete? Pri Single Area aj vcelku dost ..) atd atd ..
No co si budeme hovorit ...
bla bla bla bla.
jakto že má routing větší latence? to je zajimavá teorie.
máme tu i na RB133 okolo 200 rout a nějak jí to netíží.
0 x
Tak hlavně WDS bridge je L2 bridge. Nemáš problémy s VLANy, nemáš problémy s IPv6. Ale jak říkám - nemám groove, ale nanobridge (takže routovat ani nemůžu, zároveň mi to přijde prostě zbytečné). Jediné, co je otravné - default gateway je tam v takovém případě staticky a pokud je to v kruhu, nemusíš se při jeho rozpadu jednoduše dostat na management takového bridge (mluvím o standardním firmware bez úprav).
S tou latencí bych to tak hrozně neviděl. Nalezení routy v routovací tabulce moc nestojí. Na latenci to nepoznáš, je to naprostý zlomek oproti všemu ostatnímu. Problém spíš způsobuje "distribuce" a následné výpočty v OSPF, byť ve stabilní síti je to také zanedbatelné. Jenže něco paměti to přeci jenom sežere - a na některých zařízeních to už může vadit. Ale teoreticky vzato - nalezení MACky v tabulce o dvou či čtyřech záznamech asi rychlejší bude.
Síťařina není matematika. Možných správných řešení je povícero. A někdy je správnější i to horší ...
A pokud máš 200 rout, máš malou síťku
S tou latencí bych to tak hrozně neviděl. Nalezení routy v routovací tabulce moc nestojí. Na latenci to nepoznáš, je to naprostý zlomek oproti všemu ostatnímu. Problém spíš způsobuje "distribuce" a následné výpočty v OSPF, byť ve stabilní síti je to také zanedbatelné. Jenže něco paměti to přeci jenom sežere - a na některých zařízeních to už může vadit. Ale teoreticky vzato - nalezení MACky v tabulce o dvou či čtyřech záznamech asi rychlejší bude.
Síťařina není matematika. Možných správných řešení je povícero. A někdy je správnější i to horší ...
A pokud máš 200 rout, máš malou síťku
0 x
ja to beriem, ale naco routovat tak ako to bolo na obrazku proste je tam potom pridany dalsi stupen komplexivity.
Btw ja by som router pouzil tam kde by som chcel rozdelit vacsiu bcast domenu, zaroven to nema zmysel delit na prilis male casti, ideal z mojho pohladu je jeden router na kazdej strane wifi poja.
Tam ten obrazok by som ja riesil napr.
RB800 dedina1 RB800 dedina2
wlan4 172.16.1.1-------(172.16.1.0/30)--------172.16.1.2 wlan4
eth1 172.16.1.9 ------groove1 bridge --- (172.16.1.8/29) ---groove2 bridge ------ 172.16.1.10 eth1
grove1 ip: 172.16.1.11
gw: 172.16.1.9
groove2 ip: 172.16.1.12
gw 172.16.1.10
nie je to idealne, ako pises v pripade vypadku je problem sa dostat na mgmt ale to sa da riesit (nudzovo) cez web proxy/portforwardy smerom na groovy.
pripadne vrrp ..
Btw ja by som router pouzil tam kde by som chcel rozdelit vacsiu bcast domenu, zaroven to nema zmysel delit na prilis male casti, ideal z mojho pohladu je jeden router na kazdej strane wifi poja.
Tam ten obrazok by som ja riesil napr.
RB800 dedina1 RB800 dedina2
wlan4 172.16.1.1-------(172.16.1.0/30)--------172.16.1.2 wlan4
eth1 172.16.1.9 ------groove1 bridge --- (172.16.1.8/29) ---groove2 bridge ------ 172.16.1.10 eth1
grove1 ip: 172.16.1.11
gw: 172.16.1.9
groove2 ip: 172.16.1.12
gw 172.16.1.10
nie je to idealne, ako pises v pripade vypadku je problem sa dostat na mgmt ale to sa da riesit (nudzovo) cez web proxy/portforwardy smerom na groovy.
pripadne vrrp ..
0 x
když ty groovy propojíš do bridge, uděláš z nich prosté pojítko, končící ethernetama, a pojítka neroutujou 
0 x
no ved tie rb800vky budu routovat. Bral som to tak ze ich tam ma hned vedla ...
0 x
však jo, může to lehce nahradit nanověcma, mocGHz věcma, optikou, kabelem, prostě mi logika praví, že je to správný a instantní řešení
0 x
Peyrak píše:když ty groovy propojíš do bridge, uděláš z nich prosté pojítko, končící ethernetama, a pojítka neroutujou
jenže to bych je musel dělat WDSkama protože klasický station bridge neprojde
0 x
když je tady řeč o wds bridgi, stalo se mi nedávno u jednoho páru 711-tek s 1 chainem v NV2, že měly o cca 10M nižší propustnost a ping v max. zátěži kolem 40ms. A bylo jim úplně jedno, jestli jely na 5.6 nebo 5.14 (tehdy aktuální verze)
0 x
nene wds a bridge na rádiích už ne, tenkrát jsem s tím začínal a třeba se stalo i to, že skrze to neprolezlo ospf a nevím do dnes proč, jakmile jsem spoj přehodil do modu bridge --> station a dal jsem tam /30 síť, tak se hnedle rozběhnul
0 x
No vidíš ... já jinak než WDS nanobridge nekonfiguruju. Ono může jít vyloženě o chybu HW. Např. ubnt 5.3.x má prý chybu ve zpracování multicastu a občas u něj ztrácí pakety. Pak to OSPF kraví. Ale tak nějak u nás tento problém nepozoruju.
okoun píše:nene wds a bridge na rádiích už ne, tenkrát jsem s tím začínal a třeba se stalo i to, že skrze to neprolezlo ospf a nevím do dnes proč, jakmile jsem spoj přehodil do modu bridge --> station a dal jsem tam /30 síť, tak se hnedle rozběhnul
0 x
ludvik píše:No vidíš ... já jinak než WDS nanobridge nekonfiguruju. Ono může jít vyloženě o chybu HW. Např. ubnt 5.3.x má prý chybu ve zpracování multicastu a občas u něj ztrácí pakety. Pak to OSPF kraví. Ale tak nějak u nás tento problém nepozoruju.
Konfiguruj přes takové pochybné spoje OSPF s network type NBMA, pak se místo multicastu používá klasický unicast a úchylky UBNT tě neohrozí. Jen musíš v tom případě vyjmenovat seznam routerů proti sobě, což je trošku práce navíc (v NBMA Neighbors).
0 x