Zase tolik to na vodu/sníh náročné není ...

Jenže přístup "záloha je samozřejmost", takže tam nasadíme něco padacího je příšerný. Ano, pokud to padne jednou ročně a padne to "stabilně", tak ok. Ale pokud to bude padat kvůli počasí, tak to nebude ani tak padat, jako ztrátovat a přepínat okruhy semtam (ospf, ani jiné běžně používané protokoly nejsou až tak rychlé). Čili ano, zálohy zaberou - ale provozuschopné to vlastně nebude.

Vím o čem mluvím. Gigabit laserem na jaře a hlavně na podzim se sítí cvičil naprosto nepředstavitelně. A to je MSTP ještě na rozdíl od OSPF vcelku rychlé.

"Chvíli to sic vydrží, ale pak přijde nějaká ulicha nebo sněhová nadílka a pokud spoj nebude mít zálohu" - záloha je snad dnes již naprostá samozřejmost a netřeba to nijak komentovat. Co to udělá v zimě nikdo neví, není k tomu žádná specifikace ani reálné měření.

Ty lasery byly někdy v roce 2007. RFC pro BFD je z roku 2010 ... tzn. jsme měli smolíka.

Quagga oficiálně BFD neumí dodnes a nějaké nestable patche nikdo zkoušet nebude. Takže též je to nepoužitelné všude.

Změna rout se musí dostat do celé sítě. Čili ani rychlá konvergence pomocí BFD tomu zase tolik nepomůže (resp. nemusí). Hlavně proto, že ten spoj dokázal jet/nejet snad Xkrát za vteřinu. Vývojáři tam jaksi zapomněli dopsat hysterezi.

A u rádií (této kategorie) zase může nastat problém, že to jede, ale špatně ... ospf/bfd/stp se tam ještě "procpe", ale užitečná data už ne ...

Je až s podivem, že toto žádný routovací algoritmus neřeší. Např. by se hodilo, aby po pádu spoje proběhl "návrat" na něj až po nějaké definované době (klidně několik minut...)

skusali ste uz niekto AP WAP a oproti lhg ze do kolko to da ?

Ty lasery byly někdy v roce 2007. RFC pro BFD je z roku 2010 ... tzn. jsme měli smolíka.

Quagga oficiálně BFD neumí dodnes a nějaké nestable patche nikdo zkoušet nebude. Takže též je to nepoužitelné všude.

Změna rout se musí dostat do celé sítě. Čili ani rychlá konvergence pomocí BFD tomu zase tolik nepomůže (resp. nemusí). Hlavně proto, že ten spoj dokázal jet/nejet snad Xkrát za vteřinu. Vývojáři tam jaksi zapomněli dopsat hysterezi.

A u rádií (této kategorie) zase může nastat problém, že to jede, ale špatně ... ospf/bfd/stp se tam ještě "procpe", ale užitečná data už ne ...

Některé spoje umí nastavit port down při výpadku bezdrátové linky, na což OSPF reaguje okamžitě. Teoreticky by to šlo nascriptovat i do wapky a zavést tam delší čekací interval. Za sebe provozuju na podobných linkách BFD a celkem to i stačí.

Ty lasery byly někdy v roce 2007. RFC pro BFD je z roku 2010 ... tzn. jsme měli smolíka.

Quagga oficiálně BFD neumí dodnes a nějaké nestable patche nikdo zkoušet nebude. Takže též je to nepoužitelné všude.

Změna rout se musí dostat do celé sítě. Čili ani rychlá konvergence pomocí BFD tomu zase tolik nepomůže (resp. nemusí). Hlavně proto, že ten spoj dokázal jet/nejet snad Xkrát za vteřinu. Vývojáři tam jaksi zapomněli dopsat hysterezi.

A u rádií (této kategorie) zase může nastat problém, že to jede, ale špatně ... ospf/bfd/stp se tam ještě "procpe", ale užitečná data už ne ...

Některé spoje umí nastavit port down při výpadku bezdrátové linky, na což OSPF reaguje okamžitě. Teoreticky by to šlo nascriptovat i do wapky a zavést tam delší čekací interval. Za sebe provozuju na podobných linkách BFD a celkem to i stačí.

Toto sa da v mk krasne nascriptovat pouzivame ked mame kruh spadne hlavna trasa a opinga ci ide spatna ak ano pusti tade zarial pinga hlavnu vetvu ked nabehne hlavna skontroluje az 5 minut ci ide a az pak prehodi aby to neprehadzovalo aj pri nejakom kratkom naznaku....

A poskytneš ten skriptík? :

Ne vše a všude je mikrotik ... Kromě toho tak nějak odmítám si psát vlastní dynamický routovací protokol ve scriptovacím jazyku ROS.

Toto sa da v mk krasne nascriptovat pouzivame ked mame kruh spadne hlavna trasa a opinga ci ide spatna ak ano pusti tade zarial pinga hlavnu vetvu ked nabehne hlavna skontroluje az 5 minut ci ide a az pak prehodi aby to neprehadzovalo aj pri nejakom kratkom naznaku....

Zase něco pro testery:

Version 6.43rc32

* ) w60g - improved maximal achievable distance;

* ) w60g - properly report center status under "tx-sector-info";

aka je ta max. vzdialenost? vie niekto?

Jeden spoj WAP - WAP mi na 185m jede stabilně 80 signál, 8 MCS. Docela hnusnej déšť to přežilo bez výpadku. Kanál 60480. Naopak spoj na 130m drží podobný signál i MCS, kanál 58320, ale stejný déšť 5x nepřežil. Spoje jsou z jednoho místa na 2 rozdílné strany.

kure05 ina tema nebudme to tu spamovat ale napis pm mozem ti to nejako vysveltit ale musis vediet aspon zaklady skriptovania inak si ani nepipnes bo ked ti dam len skript je to pre teba nepouzitelne to si musis prestavit na svoju siet bo mne to jeden script pusta dalsi a tak :) ale fakci to proste super uz si bez toho neviem predstavit siet pretoze vypadok na spoji a mne nezvoni ziadny telefon ze nejde internet len mi pipne ze vypadol spoj a uz si to spravim ako mi pasuje nie ze hned teraz bo ludi ide ujebat ze nic nejde..

cmgn 185 to ti udrzi ak to mas dobre nasmerovane mam na 195 dva mesiace a uz prsalo neviem ako a drzi bez vypadku...

najnovsie testujem lhg60 na 1 km signal -60 a zatial cakam na dazd ked bol -71 ze to nebolo dobre nasmerovane to padlo pri dazdi teraz ked je to vylepsene na tych 60 som zvedavy ci to uz ten 1 km udrzi ked pride lejak...

Taky si myslím. Jede to zatím moc pěkně. Spis ten druhy spoj na tech cca 130m bude ujetý :-) LHG jdu testovat zítra na 1300m. Uvidíme.

Zdravím, nemáte náhodou někdo vyzkoušení použítí RBwAPG-60ad a síta RBLHGG-60ad na jednom stožáru jestli se to nebude vzájemně rušit. Díky

Zdravím, nemáte náhodou někdo vyzkoušení použítí RBwAPG-60ad a síta RBLHGG-60ad na jednom stožáru jestli se to nebude vzájemně rušit. Díky

ne, ale 2x wap60g v parabole vlastni kostrukce do ruznych smeru na ruznych kanalech se nerusi (taky proc by mel).

connected: yes

frequency: 62640

remote-address: 04:D6:AA:68:AE:93

mcs: 1

phy-rate: 385.0Mbps

signal: 25

rssi: -70

tx-sector: 63

tx-sector-info: left 26.6 degrees, up 26.6 degrees

rx-sector: 96

distance: 1037.93m

connected: yes

frequency: 64800

remote-address: 04:D6:AA:68:AE:93

mcs: 8

phy-rate: 2.3Gbps

signal: 70

rssi: -68

tx-sector: 34

tx-sector-info: right 11.4 degrees, up 3.8 degrees

rx-sector: 96

distance: 1037.95m

- parabola jirous par 24, upraveny ozarovac z 5g-mimo

- zamereno dost presne opticky (mam udelany "dalekohled" do trubky vlnovodu)

- zajimave je, ze to funguje prakticky jen na vyssich 2 kanalech 62640 a 64800, na nizsich se to vubec nespoji

a pri scanu to ukazuje signal 20

vies poslat foto ako si to dostal do tych JRC?

To je teda signál :-D Sotva spojený . . .

Dokončujeme kompakt řešení pro klienty, kteřé dodá trase na každé straně + 10dB

Pro plný přenos potřebujete cca -71 na RSSI, takže to bude fungovat na 1+km proti sobě, proti AP bez úprav cca 400-500m s plnou propustnosti.

connected: yes

frequency: 58320

remote-address: 30

mcs: 8

phy-rate: 2.3Gbps

signal: 85

rssi: -55

tx-sector: 27

tx-sector-info: center

rx-sector: 96

distance: 231.37m

Celkem se povedlo i přizpůsobení, takže to má stejný zisk na všech kanálech, budeme to mít komerčně dostupné cca v druhé půlce července.

Kontrolní otázka, ten "přídavný zisk" , který vygeneruje trubkový zářič před array wapky, je ve směru TX, RX nebo obojím?

📡 Telekomunikace.cz