Internet przewodowy z dwóch źródeł

Nie jest to jakiś palący problem, ale interesuje mnie, w jaki sposób podłączyć router (a nawet, na co zwrócić uwagę kupując taki router czy inne urządzenie), żeby mieć automatyczne przełączanie internetu.

Aby nie komplikować bez potrzeby, załóżmy taką fikcyjną i trochę bezsensowną konfigurację: Mam podpisane dwie umowy z dwiema firmami internetowymi. Pierwsza nazwijmy "A", która zapewnia bardzo dobry transfer, ale bywają przerwy w działaniu. Druga firma, nazwijmy "B", daje transfer taki sobie, możliwe, że też z przerwami (ale zakładając, że nie ma przypadków, w których akurat w obu firmach jest przerwa). Obie firmy dostarczyły modem przewodowy.

Najbardziej powszechny i oczywisty sposób korzystania z takiej instalacji (dopóki nie poszuka się jeszcze innej firmy, która daje internet o dobrym transferze i bez przerw): Komputer (lub cały LAN) jest podłączony do modemu "A", a w razie czego przepinam przewód do modemu "B", a po jakimś czasie przepinam z powrotem, bo może przerwa w firmie "A" się skończyła.

Co jest potrzebne i jak ustawić, żeby to działo się automatycznie? Wyobrażam sobie, że to dodatkowe urządzenie jest podłączone do obu modemów, które logicznie są od strony WAN, przy czym normalnie korzysta z modemu "A", jak wyczuje brak internetu w "A", to korzysta z "B", ale cały czas czuwa przy "A", gdzie jak tylko wróci internet, to przełącza z powrotem.

Chodzi o działanie takie samo, jak we wszystkich smartfonach, gdzie domyślnie internet jest pobierany z WiFi, a tylko wtedy, gdy WiFi nie jest osiągalne (co w przypadku telefonu zdarza się nagminnie i jest rzeczą normalną), to ewentualnie korzysta z sieci telefonicznej, a jak tylko telefon wyczuje WiFi, to znowu korzysta z WiFi.

Czy w ogóle i w jaki sposób robi się taką redundancję w firmach? Wiadomo, że każdy dostawca internetu stara się jak może, ale czasami przerwy są możliwe z powodu awarii urządzeń i sieci dostawcy. Trudno sobie wyobrazić, żeby był jakiś gość 24/7, który w razie czego biegnie do serwerowni i przepina przewody, żeby firma miała internet.

Wszystko zależy od dostępności infrastruktury. Jeśli kabelki nie sa dostępne w pobliżu to czekają Cię wydatki na dociągnięcie światła (zakładam że miedzi nikt już nie oferuje).
Router to chyba najmniejszy powód do zmartwień, możesz wziąć jakieś enterprise rozwiązanie, ale możesz również użyć czegoś z Linuxem na górze (VyOS, OpenWRT itp itd są tego dziesiątki). Kiedyś korzystałem z jakiegoś hardware na E (sry nie mogę sobie przypomnieć nazwy :D) i nad nim był właśnie VyOS, konfigurujesz reguły zgodnie z dokumentacją i jak przez N czasu nie ma połączenia z dostawcą to się sieć przepina i lokalnie niczego nie musisz ruszać.
Jak się robi w firmach? Różnie, konfigurowałem przypadki gdzie były dwa kabelki do routera i też takie gdzie nie było redundancji kabelkowej, a firmy wykupowały sobie wyższe SLA (w/g legislacji domyslnie jest to 75% czasu na umowie/rok - chyba się nie zmieniło wiedza sprzed 2 lat). Wtedy jakaś firma ma jakichś tam techników i jak się coś spieprzy to spawają, klikają na SDNie i inne cuda robią aby połączenie przywrócić.

Sam się orientowałem w temacie jakiś czas temu i nie jest to takie proste, tzn takich routerów na rynku (za normalne pieniądze jak do domu) jest niewiele a jeśli chcesz od razu z wifi to nie ma wcale więc musisz się liczyć z tym, że masz router jeden i do niego wpięty jakiś access point. Tutaj pierwszy z brzegu tego typu sprzęt https://www.mediaexpert.pl/komputery-i-tablety/urzadzenia-sieciowe/routery/router-tp-link-tl-er605 Możesz w nim ustawić tak połaczenie jako load balancer jak i wersje z łączem głównym i awaryjnym, z tym, że w LB podobno są problemy np z bankami bo im nie pasuje że requesty lecą naraz z 2 różnych ip.

Bierzesz dowolnego Mikrotika za dosłownie kilka stów - w tych urządzeniach nie masz na sztywno przypisanych funkcij do portów typu LAN czy WAN, możesz wszystko wpiąć wszędzie.
A potem patrzysz na poniższe filmy i obczajasz w 5 minut, jak zrobić dual WAN oraz failover.

Kilka uwag technicznych:

• oba modemy od ISP podłączasz do routera jednocześnie, nie baw się w przełączanie kabli jak coś się wywali
• nie radzę bawić się w load-balancing, czyli rozdzielenie ruchu na oba łącza i ich jednoczesne używane. Tak, jak napisał @ehhhhh powyżej - bywa z tym dużo problemów, a korzyści niewielkie
• ewentualnie można rozbić to tak, że np. cały ruch idzie jednym łączem, a drugie jest to masówki - typu wrzucanie czegoś do chmury albo torrenty. Ale nadal bym pozostał przy wersji failover - jedno łącze główne, na którym pracujesz, a drugie się odpala w razie awarii
• co do sprzętu - chociażby Mikrotik hAP ma WiFi i kilka gniazd RJ45, więc spokojnie da radę, a kosztuje jakieś 3 stówki: https://www.ceneo.pl/80057556, https://www.x-kom.pl/p/731308-router-mikrotik-hap-ac2-tower-1200mb-s-a-b-g-n-ac.html czy https://www.senetic.pl/product/RBD52G-5HacD2HnD-TC

Ubiquiti UDM pro obsluguje takie coś - opisane jest to jako WAN Failvoer

@andrzejlisek: Istnieją takie rozwiązania, które potrafią monitorować osiągalność określonego systemu w sieci i w razie potrzeby w bardzo krótkim czasie (ułamki sekund) przełączać się wielokrotnie, samodzielnie bez udziału kogokolwiek pomiędzy różnymi ISP. A najważniejszą cechą jednego z takich rozwiązań było to, że w ogóle nie traciło się połączeń TCP/IP zestawionych np. na ISP1 po przełączeniu się na ISP2 albo i kolejnym ISPn. W ciągu sekundy można było wiele razy przełączać się między ISP-kami a użytkownik końcowy nawet nie miał świadomości tego ile razy, kiedy i że w ogóle dostawca netu był wiele razy zmieniany.

vtx napisał(a):

@andrzejlisek: Istnieją takie rozwiązania, które potrafią monitorować osiągalność określonego systemu w sieci i w razie potrzeby w bardzo krótkim czasie (ułamki sekund) przełączać się wielokrotnie, samodzielnie bez udziału kogokolwiek pomiędzy różnymi ISP. A najważniejszą cechą jednego z takich rozwiązań było to, że w ogóle nie traciło się połączeń TCP/IP zestawionych np. na ISP1 po przełączeniu się na ISP2 albo i kolejnym ISPn. W ciągu sekundy można było wiele razy przełączać się między ISP-kami a użytkownik końcowy nawet nie miał świadomości tego ile razy, kiedy i że w ogóle dostawca netu był wiele razy zmieniany.

A jakieś konkrety, co to za rozwiązania? Bo brzmi to trochę, jakbś proponował ziomkowi postawienie w chacie BGP ;) Poza tym - podejrzewam, że to o czym piszesz (chociaż ciężko się odnieść, bo za dużo konkretów nie podałeś) bardziej brzmi jakby coś z wyposażenia serwerowni jakiegoś dużego ISP, a nie routerek za max. kilka stówek dla ziomka do posadzenia w salonie ;)

cerrato napisał(a):

vtx napisał(a):

@andrzejlisek: Istnieją takie rozwiązania, które potrafią monitorować osiągalność określonego systemu w sieci i w razie potrzeby w bardzo krótkim czasie (ułamki sekund) przełączać się wielokrotnie, samodzielnie bez udziału kogokolwiek pomiędzy różnymi ISP. A najważniejszą cechą jednego z takich rozwiązań było to, że w ogóle nie traciło się połączeń TCP/IP zestawionych np. na ISP1 po przełączeniu się na ISP2 albo i kolejnym ISPn. W ciągu sekundy można było wiele razy przełączać się między ISP-kami a użytkownik końcowy nawet nie miał świadomości tego ile razy, kiedy i że w ogóle dostawca netu był wiele razy zmieniany.

A jakieś konkrety, co to za rozwiązania? Bo brzmi to trochę, jakbś proponował ziomkowi postawienie w chacie BGP ;) Poza tym - podejrzewam, że to o czym piszesz (chociaż ciężko się odnieść, bo za dużo konkretów nie podałeś) bardziej brzmi jakby coś z wyposażenia serwerowni jakiegoś dużego ISP, a nie routerek za max. kilka stówek dla ziomka do posadzenia w salonie ;)

Nie nie, tu nie chodzi o BGP i jakiegoś dużego ISP.
Co do BGP to nie mam zbyt dużej praktyki w używaniu go ale coś mi się wydaje, że on nie udostępnia możliwości utrzymania połączeń TCP/IP nawet po wielokrotnej zmianie ISP. Ale może czegoś nie wiem? Jeśli tak - chętnie się dowiem.

Co do konkretów to mam na myśli takie jedno rozwiązanie. Autorskie rozwiązanie. Napisane w C. Bez jakiegokolwiek GUI. Działało to sobie na Linuxie i udostępniało dostęp do netu poprzez interfejsy WiFi, gdzie każdy z interfejsów WiFi mógł być połączony z innym ISP. Nie powinno być problemu w zasadzie z przepięciem tego na jakikolwiek inny interfejs np. na ethernetowy.
W testach laboratoryjnych bardzo fajnie to sobie działało. Było w stanie wiele razy na sekundę zmienić ISP-ka (np. wymuszając to podczas testów funkcjonalnych) i nie zerwać ani jednego połączenia TCP/IP. Testowane przykładowo na kilku zestawionych połączeniach: skype, telnet, ftp i ssh w tym samym czasie. Żadne połączenie nie padło. Ale nie było niestety zweryfikowane poza laboratorium w realnym świecie.

Nie wiem czy to rozwiązanie wyszło poza jedną taką firmę.

Dużo domowych routerów posiadających faliover działa tak, że owszem przełączą się podczas awarii głównego łącza, ale ponownie już trzeba przełączyć się ręcznie i ręcznie monitorować czy główne łącze już działa.
Nie wiem nawet czy nie było tak w starszych mikrotikach.
Do rozważenia w ogóle load balancer z faliover.
Przykład urządzenia BR-6624
Przed zakupem doczytaj czy faliover sam przywraca działanie lacza i czy oby nie dziala tylko na WAN i USB.

@cerrato napisał: > @vtx: OK, to daj jakiś namiar na te źródła (albo binarki do pobrania). W sensie - daj cokolwiek, co może być przydatne dla pytającego. Bo na razie to jest opowiadanie legend że ktoś gdzieś kiedyś coś widział, co było zajebiste i działało idealnie. Tylko co z tego, jeśli z powodu braku konkretów, przydatność takiej porady/odpowiedzi dla autora wątku jest praktycznie zerowa?

Ok, żeby ktoś nie odniósł wrażenia, że mój post jest bezużyteczny, niekonstruktywny, niemerytoryczny, etc to może spróbuję tak:

Jakie info można wyciągnąć z moich dotychczas podanych informacji:

• jest dostepne rozwiazanie programowe dla Linuxa
• nie trzeba BGP
• dostepne sa zrodla w C dla Linuxa - autor je posiada
• latwe w uzytkowaniu bo automatycznie dzialajace - chociaz nie posiada gui
• nie wymaga jakiejkolwiek interwencji manualnej (jest to rozwiazanie w stylu: "fire and forget")
• nie zrywa zadnych polaczen TCP/IP podczas i po przelaczaniu sie miedzy ISP-kami
• zapewnia failover, redundancje
• dzialalo w warunkach laboratoryjnych bardzo szybko w sposob niezauwazalny dla uzytkownika koncowego
• nie przetestowane "in real life" poza labem
• jest autorskim rozwiazaniem
• rozwiazanie oryginalne bylo dedykowane pod wifi ale zdaje sie moznaby przerobic to na ethernet (wymaga dodatkowego rozpoznania)
• jest potencjal do dalszego rozwoju rozwiazania (wymaga dodatkowego rozpoznania co do zakresu mozliwosci)
• OP i nie tylko OP ma punkt zaczepienia w postaci mozliwosci skontaktowania sie z autorem (mógłbym pomóc w kontakcie z autorem)

Czego do tej pory nie napisalem - a co uzupelniam w tym poscie:

• nie jest idealnym rozwiazaniem - ma swoje wady
• zrodla byly pisane jakis czas temu i trzebaby zaadaptowac je do aktualnych linuxow
• zrodla w C sa dostepne owszem ale tylko dla autora (czyli nie wpadly przypadkiem do /dev/null)
• autor nie planuje udostepniania aktualnych zrodel komukolwiek
• brak koniecznosci instalacji wielomegabajtowych jakichs dodatkowych bibliotek komercyjnych
• pisane to bylo dla pewnych urzadzen mobilnych
• istnieje mozliwosc rozszerzenia zrodel np. o priorytetyzacje okreslonych ISP-kow, etc
• mialo wsparcie do autoryzacji jako zabezp przed nieautoryzowanym dostepem
• autorskie rozwiazanie oznacza tutaj tez ze jedna osoba to wymyslila, zaprojektowala i oprogramowala i posiada dokumentacje projektowa i zrodla
• istnieje mozliwosc napisania rozwiazania calkowicie od nowa bazujac na dotychczasowych zrodlach, rozpoznaniu, etc

p.s. sorry za brak pliterek.

@vtx Możesz i 10x tyle napisać, ale nadal nie mamy linka, ani chociażby nazwy tego rozwiązania.

To teraz patrz - ja mam źródło darmowej i w 200% ekologicznej energii elektrycznej. W piwnicy mam prostej roboty reaktor atomowy, bezpieczny w 100%. To rozwiąże problem całego świata. Ale.... nie udostępnie go, nie powiem w której piwnicy się znajduje. Ale obiecuje że działa i jeszcze problem głodu zwalcza.... Może ma troszkę przestarzałe wtyczki, ale to mozna naprawić, tylko że nikt tego nie zrobi, bo nikt nic nie wie o tym reaktorze...... a jego konstruktor nie udostępni nic związanego z jego budową.

W skrocie wielkim, nic nie pokazałeś, nic nie udostępniłeś, nic nie pomogłeś, tylko napisałeś że jakiś tam autor coś ma, ale nie udostępni. Twoje posty nie wnoszą zupełnie nic.

@cerrato: Wnioskuje o usunięcie wpisów @vtx jak również i tego posta (bo też nic nie wnosi do dyskusji)