Ok, zostanie to w takim razie czcza dyskusja. U sibie na ok 20 łącz "pod opieką" wszystkie doprowadziłem do wysokiej stabilności (wszystkie kablowe) i przy testach typu odłączanie jednego z WAN-ów to zadziała nawet najprostsze rozwiązanie dualwana. Ale jak widać po postach na forach nawet zaawansowane rozwiązania nie radzą sobie z sytuacjami z prawdziwego życia.
Pomysł powstał po obserwacji zachowania się łącz podczas awarii. Ale skoro uważasz że to zbędny bajer to ok. Nie będe się wykłócał i nalegał. Nie twierdzę że Twoje rozwiązanie nie będzie działać bo ma duże szanse na poprawną pracę, ale miałem kilka sytuacji że na światłowodach pingi szły pięknie do 8.8.8.8, tracert pokazywał trasę z ponad 10 skokami a neta brak, to już wiem że traceroute się po prostu nie sprawdzi. W LTE w trakcie awarii też najczęściej pingi idą a jednak łącze martwe....
Czyli nie chcesz poświęcić 10 minut _swojego_ czasu żeby przetestować nową wersję watchdoga chociaż w jednej lokalizacji, zgadza się?
Natomiast ja mam zainwestować parę godzin _swojej_ pracy, żeby coś tam zrobić?
Właśnie dlatego wszystkie opensorsowe projekty upadają po jakimś czasie, myślisz dlaczego shibby dał sobie spokój? Bo ma dziecko? Ja też mam, i co z tego?
Netowski 1Gb/1Gb
Huawei E3372s-153 non-hilink + 2x15dBi MIMO
FreshTomato: Asus RT-AC3200 + RT-N18U + RT-N66U + RT-N12
Nie, nie rozumiesz mnie. Watchdog jak najbardziej zadziała gdy łącze padnie całkowicie. Twój również oparty o traceroute. Nie zadziała natomiast w sytuacjach o których pisałem wyżej. Sam w 2 lokalizacjach mam Watchdoga włączonego, tyle że użytkownicy są poinstruowani że w razie czego muszą wyłączyć główne łącze aby się router przełączył. Bo sam z siebie w 20-30% przypadków tego po prostu nie robi.
I nic nie da testowanie na "sucho" bo nijak nie odwzoruję realnego scenariusza usterki na którą metoda z cyklicznym pobieraniem pliku mogłaby być receptą. Inna sprawa że u operatorów lokalnych sieci 4 hopy mogą nie wystarczyć do wyjścia poza publiczny IP.
' target='_blank'>Link
