classic.ISPforum.cz

Zdravím společnost,

přemýšlím nad tím, jak efektivně zálohovat E-band spoje. Jednoduchá varianta je použít metodu přímo od výrobce například Ericsson 1+1. Ovšem existují situace, kdy to buď není finančně možné například při nasazení Mikrotik v pásmu 60GHz, nebo neefektivní v kruhové topologii. Na tyto případy bych se rád zaměřil. Doufám, že s přicházejícími výrobky a slíbeným pásmem se tyto rady budou hodit také někomu jinému a společně posuneme E-band dále. V současnosti mám vše řešené přes OSPF, ale reakční doba je pomalá a není dost dobrá reakce na packet loss.

V konfiguraci Mikrotik se nabízí: OSPF, OSPF + BFD (na Mikrotiku ), STP, Interface Bonding a další...

Pro jednoduchost můžeme uvést příklad PTP spojení dvou POP pomocí LHG60 a starého spoje UBNT M5. Pokud jsou na POP routery Mikrotik, jak nejlépe spoj zálohovat?

Summity umí zálohu sami o sobě. Mají funkci, že když se rozpadne spojení, tak data tekoucí po jednom ethernetu/SFP do rádia forwardnou do druhého ethernetu/SFP, kde může být pŕipojený jiný spoj. Ale nezkoušel jsem to.

Pěkné, to jsem už viděl i v konfiguraci. Ale zařadil bych to k profi řešení, které by mělo fungovat a když ne, tak s tím nic moc neuděláme. Předpokládám, že podobné řešení by měl mít každý profi spoj.

no vzhledem k tomu ze zalohujes MK V-BAND (60GHz), UBNT v 5.x tak to asi nejde v teto cenove kategorii udelat lepe. Jak resit packet lost na zarizeni u ktereho je to vlastnosti, trosku nechapu. Co by si konkretne chtel? Mas zarizeni za tisice a reakcni doba by mela byt v idelani pripade v nS, tak aby to zakaznik nepoznal ani na RTSP?

V příkladu jsem chtěl poradit, jak udělat přepnutí problémového V-band spoje rychlejší a tím zajistit lepší službu za méně peněz. Například BFD slibuje rychlou reakční dobu, ale v praxi jsem to ještě neviděl. K3NY, nemáš s BFD na Mikrotiku zkušenosti?

nemusíš chodit daleko. Erik stejně jako třeba ray má svoje protokoly na řešení výpadků pojítek atd.. erik dokonce dokáže signalizovat jednotce před ním že se mu tenčí kapacita třeba vinou počasí tak na to může reagovat switch/router a posílat to jinudy nicméně i to je většinou nereálný bez výměny fůry páteřních prvků a nebude to kompatibilní mezi různými výrobci a už vůbec nepodporovaný s něčim jako je mikrotik nebo ubnt. Ani u toho summitu neni dobrý řešení prostě přepnout provoz na jinej port, hádám že mezi tím se na backupový pojítko nedostanu.

Asi by bylo lepší vymyslet jak detekovat špatný stav pojítka a pak tím dopovat OSPF pro rychlejší reakce třeba i toho že daný port se totálně vypne což způsobí okamžitou reakci OSPF a přepne s minimálním zpožděním. Samozřejmě by to šlo udělat i na blbý detekci toho jestli daný pojítko jede na požadovanou rychlost a když ne tak OSPFko pěkně předem přepnout na druhou trasu a až se zase rychlost pojítka zvedne tak se zase vrátit což by nemělo způsobit žádný výpadek.

Ale co si budeme povídat, většinou lze postavit trasy tak aby prostě nepadaly ono taky jak chceš zálohovat třeba 5GHz něco jako je e-band s gigovou rychlostí. To už bych asi spíš přetrpěl ten výpadek a nebo si koupil lepší pojítko do e-bandu.

No to by šlo. Realizace na Mikrotiku skriptem, který by hlídal tx-packet-error-rate a tx-phy-rate a samozřejmě spojení. Výsledek by dle podmínek promítal do OSPF cost? K přepnutí by tak mohlo dojít ještě za funkčního spoje.

Jestli nasadit, nebo ne, to už nechám na úsudku každého.

Problem bude ten spoj ktery pujde na pusu kvuli pocasi. Kdyz nebude prenaset data, bude se to OSPF s BFD preklapet akorat rychleji (u MK je BFD defaultne 5 pokusu a jeden interval ma 200ms (nejsme si uplne jisty), takze za 1 vetrinu dojde teoreticky k preklopeni, ale to asi nedojde protoze ono to jednou z peti pokusu projde a pak zase ne a tak porad dokola). Hlavni je ze BFD, STP/RSTP ani OSPF nejsou nastroje na reseni techto situaci. Jedna z moznosti by byla pokud to MK (i ostatni spoje pripadne) umel, dojdeli k poklsu signalu/kvality linky na tolik ze vim kdy muze nastat problem, treba spoj bezi do -65dB ale ja uz pri -62dB vypnu datovy presnos a cekam nez se hodnota dostane na -58dB, pak data zase zapnu. Bylo by to castene bezpecnejsi reseni kdy dojde jen k jednomu preklopeni (nebo aspon prodlouzeni intervalu mezi nezadoucim stavem) a tak mensimu zlu. Cele to stoji na samotne diagnostice spoje, ktery musi sam zjisti ze je problem a linku odstavit -> neflappovat.

To dává smysl. Existuje nějaká standardizovaná funkce/protokol, která by řešila diagnostiku spoje a oznamování jeho stavu spoje síti? Aby ostatní prvky mohly reagovat před úplným selháním spoje?

Siae umí vypínat link na eth, když nedokáže přenášet co má, mng bude možné dát na jiný port. Lhg60 řeším skriptem, výpadek 1s není problém, nestavíme to tak, aby to padlo pětkrát do hodiny.

Myslíš, že by ses mohl o skript podělit, nebo alespoň popsat co dělá?