Zdravím,
řeším menší konfiguraci, ale nejsem si s ní tak trošku jistý, tak se chci poradit.
Jako gw je mikrotik RB2011, dále jsou zde dvě konektivity. Jedna bezdrátem na 5GHz, druhá optikou. Myšlenka je taková, že by hlavní konektivita šla přes optiku a v případě jejího výpadku by se spoj automaticky přepnul na bezdrát. Tuhle konfiguraci umím udělat přes různé routovací záznamy s rozdílným distance, ale v tomhle případě to podle mě udělat nepůjde, protože obě sítě směřují na stejnou GW ISP se stejnou IP.
IP GW bude tedy vždy stejná, pouze by se měla měnit cesta sítí k dané gateway. Nevím, jestli by to šlo řešit přes OSPF?
Díky.
❗️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
Backup spoj se stejnou GW jako na hlavní konektivitě
nešlo.
dohodni se s ISP, co ti umožní. Nabízí se OSPF, BGP, STP, bonding. Nebo to rozdělit na dvě samostatné sítě a prohazovat si to nějakým scriptem. Ale ve tvém případě, v této konfiguraci je provozuschopné jen spanning-tree ... které ovšem na wifinách nedoporučuji.
Nebo si napiš script, co bude vypínat jednotlivá rozhraní. Jenže to je řešení polovičaté, nebudeš vědět kdy vrátit trasu zpět. To už je možná lepší to přehazovat ručně. Předpokládal bych, že trasa po optice vypadne málokdy (když už, tak mu vypadne celá GW).
dohodni se s ISP, co ti umožní. Nabízí se OSPF, BGP, STP, bonding. Nebo to rozdělit na dvě samostatné sítě a prohazovat si to nějakým scriptem. Ale ve tvém případě, v této konfiguraci je provozuschopné jen spanning-tree ... které ovšem na wifinách nedoporučuji.
Nebo si napiš script, co bude vypínat jednotlivá rozhraní. Jenže to je řešení polovičaté, nebudeš vědět kdy vrátit trasu zpět. To už je možná lepší to přehazovat ručně. Předpokládal bych, že trasa po optice vypadne málokdy (když už, tak mu vypadne celá GW).
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Konfigurace na zařízení ISP není problém. Akorát teď nemám představu, co je potřeba kde jak nastavit aby to fungovalo.
Napsat skript mě už taky napadlo. Ale jak říkáš, bude to komplikovaný, protože bych musel buď najít nebo přidat do cesty nějaký zařízení, který je dostupný pouze třeba z optiky.
Spanning tree na wifinách zlobí?
Napsat skript mě už taky napadlo. Ale jak říkáš, bude to komplikovaný, protože bych musel buď najít nebo přidat do cesty nějaký zařízení, který je dostupný pouze třeba z optiky.
Spanning tree na wifinách zlobí?
0 x
..:: DobraSit.cz ::..
Zlobí i na ceragonech ... když je vytížíš. Na obecně ztrátových wifi je to prostě o ničem.
Jenom mi není moc jasná potřeba zálohovat optiku wifinou
Nech si udělat dva samostatné spoje, pak máš víc možností. A řeš to s ním ... co je platné, že ti něco poradíme, když to on nebude chtít udělat. Nebo nebude mít možnost.
Jenom mi není moc jasná potřeba zálohovat optiku wifinou
Nech si udělat dva samostatné spoje, pak máš víc možností. A řeš to s ním ... co je platné, že ti něco poradíme, když to on nebude chtít udělat. Nebo nebude mít možnost.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Asi jsme se nepochopili, delame to pro naseho zakaznika. Kterej si to takhle preje. Mit zalozni konekt, kdyby neco... Takze ted se resi jak to nejlip technicky udelat.
0 x
..:: DobraSit.cz ::..
A proc mu tedy na to RB nenastavite OSPF a pouze na ruznych linkach nenastavite jinou cost a je hotovo? Pokud mas moznost kontrolovat obe zarizeni tak kein Problem ne?
A pokud staticky tak proste scriptik co testuje ping nekam do netu a v pripade ze nejde, tak prepne na zalohu a pritom testuje nejakou testovaci IP na tej primarni aby se dalo
odchytit jeji znovu-zprovozneni.
A pokud staticky tak proste scriptik co testuje ping nekam do netu a v pripade ze nejde, tak prepne na zalohu a pritom testuje nejakou testovaci IP na tej primarni aby se dalo
odchytit jeji znovu-zprovozneni.
0 x
Též potom nechápu, kde hledáš problém
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Proto jsem se ptal jestli to pujde pomoci ospf a jak. A tys rikal ze nee. Nemam s nim jeste moc zkusenost... 
0 x
..:: DobraSit.cz ::..
Odpovídal jsem na to, na co jsi se ptal. V konfiguraci, co tam máš OSPF nemáš jak udělat. Spanning-tree možná ano, máš-li tam switche, nebo softwarový bridge (s možnou nespolehlivostí na wifině, což by teoreticky díky té optice možná až tak vadit nemuselo).
Pokud to překonfiguruješ na dva samostatné spoje, OSPF lze.
Pokud to překonfiguruješ na dva samostatné spoje, OSPF lze.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Takže pokud to dobře chápu, OSPF je možné udělat, jen pokud mají obě hlavní routy jinou IP GW (nemohou mít stejnou)?
Asi to zkusím nastavit přes spanning tree a uvidím jak to pojede...
Asi to zkusím nastavit přes spanning tree a uvidím jak to pojede...
0 x
..:: DobraSit.cz ::..
A provozuješ teď v síti OSPF? Pokud ne, tak to jde udělat i bez něj. Pokud zádání zní, že mám dva rouztery, mezi nima dvě cesty a á má se řešit výpadek primární cesty, přepni na druhou.
Jednak na tom L2, že to dáš do kruhu a pustíš RSTP. Ale jak bylo zmíněno, občas problém, když se ztrácí BPDU pakety na wifin a vytvoří se pak smyčka. V tomto konkrétním případě to jde vyřešit pomocí autoizolace portů nebo horizontování, že nevadí, když s eBPDU ztratí občas.
Jiná cesta je na L3, kde to jde i bez toho OSPF a spol. Zkrátka dvě cesty mezi RBčky, dva rozsahy /30 neveřejné jako spojováky a jenda veřejná /32, kteoru má zákazník.
U zákoše:
/interface bridge
add name=bridge-verejka protocol-mode=none
/ip address
add interface=ether-sklo address=10.1.1.2/30
add interface=ether-wifi address=10.1.2.2/30
add interface=bridge-verejka address=82.144.101.64/32
/ip route
add gateway=10.1.1.1 check-gateway=ping distance=1 pref-src=82.144.101.64
add gateway=10.1.2.1 distance=2 pref-src=82.144.101.64
/ip firewall nat
add action=masquerade out-interface=ether-sklo
add action=masquerade out-interface=ether-wifi
Na bráně:
/ip address
add interface=ether-sklo address=10.1.1.1/30
add interface=ether-wifi address=10.1.2.1/30
/ip route
add gateway=10.1.1.2 check-gateway=ping distance=1 dst-address=82.144.101.64
add gateway=10.1.2.2 distance=2 dst-address=82.144.101.64
Na optice si to testuje pingem 1x za 10 sec a pokud neprojde, routa se zneplatní a pojede to wifinou. Až sklo ožije, vrátí se to zpět. Předpokládám, že optiku nemáš tak zacpanou/zprasenou, aby se příliš často ten ping ztrácel. Pokud se ztratí občas za dlouhý čas om\lem, nic se neděje, přepnme se to na chvíli na wifinu, spojení nepopadají, pojede to vše dál.
Na straně brány fakticky to obě IP mohou být na jendom společném iface, u zákazníka už ne.
Jednak na tom L2, že to dáš do kruhu a pustíš RSTP. Ale jak bylo zmíněno, občas problém, když se ztrácí BPDU pakety na wifin a vytvoří se pak smyčka. V tomto konkrétním případě to jde vyřešit pomocí autoizolace portů nebo horizontování, že nevadí, když s eBPDU ztratí občas.
Jiná cesta je na L3, kde to jde i bez toho OSPF a spol. Zkrátka dvě cesty mezi RBčky, dva rozsahy /30 neveřejné jako spojováky a jenda veřejná /32, kteoru má zákazník.
U zákoše:
/interface bridge
add name=bridge-verejka protocol-mode=none
/ip address
add interface=ether-sklo address=10.1.1.2/30
add interface=ether-wifi address=10.1.2.2/30
add interface=bridge-verejka address=82.144.101.64/32
/ip route
add gateway=10.1.1.1 check-gateway=ping distance=1 pref-src=82.144.101.64
add gateway=10.1.2.1 distance=2 pref-src=82.144.101.64
/ip firewall nat
add action=masquerade out-interface=ether-sklo
add action=masquerade out-interface=ether-wifi
Na bráně:
/ip address
add interface=ether-sklo address=10.1.1.1/30
add interface=ether-wifi address=10.1.2.1/30
/ip route
add gateway=10.1.1.2 check-gateway=ping distance=1 dst-address=82.144.101.64
add gateway=10.1.2.2 distance=2 dst-address=82.144.101.64
Na optice si to testuje pingem 1x za 10 sec a pokud neprojde, routa se zneplatní a pojede to wifinou. Až sklo ožije, vrátí se to zpět. Předpokládám, že optiku nemáš tak zacpanou/zprasenou, aby se příliš často ten ping ztrácel. Pokud se ztratí občas za dlouhý čas om\lem, nic se neděje, přepnme se to na chvíli na wifinu, spojení nepopadají, pojede to vše dál.
Na straně brány fakticky to obě IP mohou být na jendom společném iface, u zákazníka už ne.
0 x
To vypadá dobře. Akorát mi není jasný použití té direktivy pref-src. Ta co dělá?
0 x
..:: DobraSit.cz ::..
Zjendodušeně to říká té maškarádě,na co má u odchozí spojení NATnut zdrojovou adresu (řídí se tím i router pro odchozí spojení vzniklé na routeru), takže pokud bude komunikace z routeru nebo LAN mířit přímo do té linky, např na 10.1.1.1, tak jako zdrojová adresa se použije to 10.1.1.2, pokud dojde k uplatnění routy, protože spojneí jde pryč, tak se jako zdrojová adresa použije ta veřejka.
Proto je ta veřejka i dána na ten bridge,musí být někde, kde je pořád up a nneí závislá na stauv linek. Takže aby to i fungovalo správně, tak ani klienti v LAN nesmí aktivně využívat IPčka (např pro DNS, SMTP, ...), které leží přímo na těch linkách.
Proto je ta veřejka i dána na ten bridge,musí být někde, kde je pořád up a nneí závislá na stauv linek. Takže aby to i fungovalo správně, tak ani klienti v LAN nesmí aktivně využívat IPčka (např pro DNS, SMTP, ...), které leží přímo na těch linkách.
0 x
Díky!
Ještě jsem se chtěl zeptat k tomuto. Jak jsi říkal, že se vytvoří smyčka - jakto? Když by vypadávaly pakety, tak se to spíš bude chovat tak, že se spoj bude pořád přepínat sem a tam ne?
Autoizolace a horizontování, to jsou ty featury Bridgů u Mikrotiku - Autoisolate a Horizon?
Kód: Vybrat vše
Jednak na tom L2, že to dáš do kruhu a pustíš RSTP. Ale jak bylo zmíněno, občas problém, když se ztrácí BPDU pakety na wifin a vytvoří se pak smyčka. V tomto konkrétním případě to jde vyřešit pomocí autoizolace portů nebo horizontování, že nevadí, když s eBPDU ztratí občas.Ještě jsem se chtěl zeptat k tomuto. Jak jsi říkal, že se vytvoří smyčka - jakto? Když by vypadávaly pakety, tak se to spíš bude chovat tak, že se spoj bude pořád přepínat sem a tam ne?
Autoizolace a horizontování, to jsou ty featury Bridgů u Mikrotiku - Autoisolate a Horizon?
0 x
..:: DobraSit.cz ::..
Ono těch možností problémů je víc. Jednak při zahlcení linky se mohou BPDU ztrácet, pokud je prioritama nepostřčíš. Pokud se ti na jedné lince toho kruhu ztratí BPDU na dobu forward delay, tak port, který se držel jako zavřený, jako ochrna před smyčkou, tak se otevře a vznikne ti smyčka. To se zas tak moc neděje, pokud obě linky nejsou křáp a trvale ucpané na max.
Spíše případ, že máš dva switche, mezi nima wifi krabičky, wifi část se ti rozpoadne, ale switche ty eth mají pořád up, takže pokud je ropzpojeno přes forward delay, tak se port otevře, pak se spojí wifina a než projde první BPDU (což je obvvykle do 2 sec), tak máš otevřenou smyčku, ten čas stačí na to, aby se ti začlo chvíli něco pěkně honit dokola. Pokud ta linka má slušnou kapacitu, tak stihne ten provoz namnožit tak, že pak ty prvky už nemají sílu to přerušit. Tohle je mnohme běžnější problém. Pokud jsou rádia chytrá, tak umí na eth stranu přenášel stav rádiové linky, když je rádiové linka rozpojena, tak eth je down a cvičí podle toho, pak se toto neděje. Nicméně to znamená chtřejší krabici, která má obvykle i vyhrazneý zvlášť eth port pro management.
Dá se řešit v tom tvém případě tím auto-isolate=on, když takto označíš port, tak to znamená, že musí přicházet BPDU přes něj. Takže pokud vše šlape, tak BPDU chodí a dle priorit je linka buď otevřena nebo zavřena jako záložní od xSTP. Když BPDU nechodí a linka je up, tak xSTP vrstva ji po forward delay otevře, ale autoisolation ji bude blokovat, pokud nebude BPDU chodit. Nicméně je nutná podmínka pro funkčnost, že konfigurace portu je auto-isolate=yes point-to-point=yes edge=no.
Spíše případ, že máš dva switche, mezi nima wifi krabičky, wifi část se ti rozpoadne, ale switche ty eth mají pořád up, takže pokud je ropzpojeno přes forward delay, tak se port otevře, pak se spojí wifina a než projde první BPDU (což je obvvykle do 2 sec), tak máš otevřenou smyčku, ten čas stačí na to, aby se ti začlo chvíli něco pěkně honit dokola. Pokud ta linka má slušnou kapacitu, tak stihne ten provoz namnožit tak, že pak ty prvky už nemají sílu to přerušit. Tohle je mnohme běžnější problém. Pokud jsou rádia chytrá, tak umí na eth stranu přenášel stav rádiové linky, když je rádiové linka rozpojena, tak eth je down a cvičí podle toho, pak se toto neděje. Nicméně to znamená chtřejší krabici, která má obvykle i vyhrazneý zvlášť eth port pro management.
Dá se řešit v tom tvém případě tím auto-isolate=on, když takto označíš port, tak to znamená, že musí přicházet BPDU přes něj. Takže pokud vše šlape, tak BPDU chodí a dle priorit je linka buď otevřena nebo zavřena jako záložní od xSTP. Když BPDU nechodí a linka je up, tak xSTP vrstva ji po forward delay otevře, ale autoisolation ji bude blokovat, pokud nebude BPDU chodit. Nicméně je nutná podmínka pro funkčnost, že konfigurace portu je auto-isolate=yes point-to-point=yes edge=no.
0 x