❗️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
kruhova fail-over topologie
Re: kruhova fail-over topologie
Hm, hm, a jak je UBQT na tom aktuálně s otázkou spolehlivého bridgování multicastu, to také svého času bylo dost scifi? OSPF jde ojebat přes NBMA konfiguraci, ale s VRRP se nehne.
0 x
whiteagle píše:Bohužel přečíslovat už nejde, ta topologie se mění příliš rychle a museli jsme to přečíslovat celkem nedávno. Takto bych musel mít skoro co klient, to segment:)
Nat je zase problem kvuli shapingu, který dělám na hlavní gw, ale je pravda, že v případě toho backup připojení se klidně shapingu na pár minut vzdám ve prospěch funkčnosti:)
Obávám se, že dva NATy budou aktivní i při korektním provozu, ne jen výpadku, jinak v okamžiku výpadku ti to bude blbnout a část sítě nepojede. Nebo druhý NAT zapínat na hlavním směru opět dynamicky až při rozpojení segmentu. Zkrátka ti klienti přitečou do hlavní brány s jinou IP, než 192.168.1. vždy a adresa se bude lišit, zda přitečou zleva nebo zprava. Samozřjemně můžeš použít ne NAT 1:N, ale 1:1 netmap a a pak shaping půjde OK, jen klienty budeš místo 192.168.1.X značkovat třeba na 192.168.11.X a 192.168.12.X současně. Možná by šel ten druhý NAT je pro záložní směr, ale to se mi nechce domýšlet, záleží pak na nastavneí OSPF.
To je daň za to, že mícháš trnasportní segmenty a access segmenty IP dohromady, to v kruhové topologii vždy dělá bordel. Elegantně řeší routování všeho zmíněné výše a již vyloučené.
0 x
Majklik bude muset to svoje pochopení překreslit. Já se v tom jeho nákresu tedy nevyznám
Ale dle mého názoru, pro pár apček, routerů a klientů vymýšlet kombinaci OSPF, VRRP, NAT a ještě do toho scriptovat ... to je lepší obětovat víkend a udělat to správně.
Je to přeci naprosto normální technologie a topologie: access pointy buď sami routují, nebo končí v nějakém routeru. Takže mají vždy jeden klientský segment distribuovaný do zbytku sítě. Co mám ve zbytku sítě je pak naprosto šumák, klidně opět bridge spoje mezi routery (co jiného je alcoma ...), nebo klidně switchovanou topologii (kde poběží spanning tree - což ale pro 5G apod. nedoporučuji. Funguje, ale zbytečně to vnáší do zbytku sítě hupy). Může to vypadat jako hvězda, kruh, galaxie, je to prostě jedno ... Pokud musím přemýšlet nad NATy, mám něco špatně (použití VRRP majklik snad vysvětlil - to je vhodné pro připojení "věcí" co mohou mít jen jednu gateway, typicky koncové počítače).
Ale dle mého názoru, pro pár apček, routerů a klientů vymýšlet kombinaci OSPF, VRRP, NAT a ještě do toho scriptovat ... to je lepší obětovat víkend a udělat to správně.
Je to přeci naprosto normální technologie a topologie: access pointy buď sami routují, nebo končí v nějakém routeru. Takže mají vždy jeden klientský segment distribuovaný do zbytku sítě. Co mám ve zbytku sítě je pak naprosto šumák, klidně opět bridge spoje mezi routery (co jiného je alcoma ...), nebo klidně switchovanou topologii (kde poběží spanning tree - což ale pro 5G apod. nedoporučuji. Funguje, ale zbytečně to vnáší do zbytku sítě hupy). Může to vypadat jako hvězda, kruh, galaxie, je to prostě jedno ... Pokud musím přemýšlet nad NATy, mám něco špatně (použití VRRP majklik snad vysvětlil - to je vhodné pro připojení "věcí" co mohou mít jen jednu gateway, typicky koncové počítače).
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že piješ špatnou značku. 
Ale pokud to musí být, tak viz příloha.
Zkrátka APčka nemá připojení do něčeho, co routuje, ale na bridge a pokud to má pobastleno na UBQT, který neumí routovat, tak má problém, jak se vypořádat s tím, když mu chcícpne třeba propoj mezi bridge A a bridge B. Podobně, když chcípne propoj mezi router 1 a bridge C.
Pak se mu hodí to použití VRRP pro přetažení default routy na druhou stranu.
Jinak, pokud tam má něco, co neumí routovat a není ochoten to vyhodit a dát tam něco jiného, tak cesta nejmenšího odporu a funkčnosti je PPPoE.
Klienti budou mít aktivného PPPoE klieta, PPPoE servery poběží na iface routerů 192.168.1.1 a 192.168.7.1. Klienti tam dostanou IP jiné, než 192.168.1.0 a 192.168.7.0 (třeba něco z 100.64./10).
Na roputeru 2 běží jednoduchý ping test na obě strany, zda je dostupný 192.168.1.1 a 192.168.7.1, pokud ano/ne, tak zakáže/povolí PPPoE server na ifacech 192.168.1.8 a 192.168.7.40.
Na kruhu běží klasické OSPF, který bude pasivně redistribuovat IPčka z PPPoE serveru.
Klienti normálně budou viset na PPPoE serveru blíže k hlavní bráně, když se mu v bridge síti něco rozbije, tak se pustí PPPoE i na druhé straně bridge segmentu, takže klienti přilezou na něj, když ten provní už nbeuslyší, bez problému mu to pojede i v případě, že se rozpadne spoj mezi btrigeA a bridgeB, když na bridgeA budou viset také klienti, stejně jak na bridgeB, část klientů pak pobere PPPoE server na hlavní bráně, část na router2. OSPF zařídí, aby se správné klientské IP/32 adresy dostaly ke správnému PPPoE serveru nějakou existující cestou. KDyž s emu bridge část správí, tak vzdálený PPPoE server se shodí a klieti se vrátí na tne blíže vrcholu. NAT má jen jeden na hlavní bráně IP klienta se nemění, ať přiteče kudikoliv. Nic lepšího asi nevymyslí, pokud nechce ty bridge body předělávat.
Ale pokud to musí být, tak viz příloha. Zkrátka APčka nemá připojení do něčeho, co routuje, ale na bridge a pokud to má pobastleno na UBQT, který neumí routovat, tak má problém, jak se vypořádat s tím, když mu chcícpne třeba propoj mezi bridge A a bridge B. Podobně, když chcípne propoj mezi router 1 a bridge C.
Pak se mu hodí to použití VRRP pro přetažení default routy na druhou stranu.
Jinak, pokud tam má něco, co neumí routovat a není ochoten to vyhodit a dát tam něco jiného, tak cesta nejmenšího odporu a funkčnosti je PPPoE.
Klienti budou mít aktivného PPPoE klieta, PPPoE servery poběží na iface routerů 192.168.1.1 a 192.168.7.1. Klienti tam dostanou IP jiné, než 192.168.1.0 a 192.168.7.0 (třeba něco z 100.64./10).
Na roputeru 2 běží jednoduchý ping test na obě strany, zda je dostupný 192.168.1.1 a 192.168.7.1, pokud ano/ne, tak zakáže/povolí PPPoE server na ifacech 192.168.1.8 a 192.168.7.40.
Na kruhu běží klasické OSPF, který bude pasivně redistribuovat IPčka z PPPoE serveru.
Klienti normálně budou viset na PPPoE serveru blíže k hlavní bráně, když se mu v bridge síti něco rozbije, tak se pustí PPPoE i na druhé straně bridge segmentu, takže klienti přilezou na něj, když ten provní už nbeuslyší, bez problému mu to pojede i v případě, že se rozpadne spoj mezi btrigeA a bridgeB, když na bridgeA budou viset také klienti, stejně jak na bridgeB, část klientů pak pobere PPPoE server na hlavní bráně, část na router2. OSPF zařídí, aby se správné klientské IP/32 adresy dostaly ke správnému PPPoE serveru nějakou existující cestou. KDyž s emu bridge část správí, tak vzdálený PPPoE server se shodí a klieti se vrátí na tne blíže vrcholu. NAT má jen jeden na hlavní bráně IP klienta se nemění, ať přiteče kudikoliv. Nic lepšího asi nevymyslí, pokud nechce ty bridge body předělávat.
- Přílohy
-
- KruhX.png (71.73 KiB) Zobrazeno 937 x
0 x
Tak teď už mi to jasné je ... Předělat.
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.