Усовершенствование Ping check

[Sfut 173]

В настоящее время алгоритм Ping Check реализован таким образом, что единственный IP-адрес с определенной периодичностью T проверяется N раз. Таким образом, время до принятия решения составляет  TN. К тому же данный алгоритм является ненадежным, так как судить по доступности одного сервера (каким бы он супернадежным не был) о доступности всего Интернета нельзя. Поэтому предлагаю реализовать возможность последовательной проверки в цикле нескольких адресов (например, 5). Проверяем первый, если ответил - дальнейшую проверку не проводим, не ответил - сразу проверяем второй и. т.д. Или проверяем все адреса одновременно. Это позволит сократить время принятия решения в N раз и повысит достоверность. Неплохо бы также реализовать возможность задавать не только IP-адреса, но и адреса в символьном виде.

Думаю, это не так сложно реализовать.

Edited October 24, 2016 by Sfut

[Across 2]

Думаю это проще реализовать путём написания скрипта, нежели править код прошивки. Но в целом интересная задумка!

[vitgan 21]

Хорошая идея!

[drugold 24]

Присоединяюсь.

[TheBB 514]

В 24.10.2016 в 13:36, Sfut сказал:

... Проверяем первый, если ответил - дальнейшую проверку не проводим...

О_о

В 24.10.2016 в 13:36, Sfut сказал:

... не ответил - сразу проверяем второй и. т.д...

и увеличиваем Т+1

В 24.10.2016 в 13:36, Sfut сказал:

... возможность последовательной проверки в цикле нескольких адресов (например, 5)...

5 TN

В 24.10.2016 в 13:36, Sfut сказал:

... Это позволит сократить время принятия решения в N раз и повысит достоверность...

каким образом, если 5 TN (ваш пример) > 1 TN ?

[Sfut 173]

В 13.11.2016 в 00:24, TheBB сказал:

каким образом, если 5 TN (ваш пример) > 1 TN ?

Не совсем так. Сейчас реализовано по умолчанию так: 5 последовательных попыток  коннекта к одному серверу с интервалом 10 сек, то есть решение  будет принято через 50 сек. Я же предлагаю сделать так: проверяем первый сервер, ждем, например, 1 сек, если не ответил запускаем проверку второго и т.д. После запуска проверки последнего можно подождать для гарантии те же 10 сек. В этом случае время принятия решения составит 14 сек, а не 50 сек. Хотя на мой взгляд, ждать еще 10 сек смысла нет, так как вероятность того что до нескольких разных серверов пинг при работающем интернете будет около 10 сек практически нулевая. В этом случае решение будет принято через 5 сек. Серверов также не обязательно должно быть 5 и проверку можно запускать одновременно.

Edited November 14, 2016 by Sfut

[TheBB 514]

1 час назад, Sfut сказал:

Не совсем так...

А как? Сейчас можно минимально настроить так

каждые 3 сек пингуется хост, после 1 неудачной попытки происходит переключение. Где 50 сек? В вашем варианте нужно еще и результаты работы сравнивать, для принятия решения, что увеличивает время срабатывания

[Sfut 173]

2 часа назад, TheBB сказал:

каждые 3 сек пингуется хост, после 1 неудачной попытки происходит переключение

Главное здесь то, что решение принимается только по ОДНОМУ серверу. А он каким бы не был надежным, может быть временно недоступен при доступности интернета в целом. В этом случае решение будет принято ошибочно. Я же предлагаю принимать решение по опросу нескольких серверов. В этом случае при доступности интернета какой-нибудь да ответит. Если ответил хоть один - значит интернет есть. А настройку периодичности проверки и порога срабатывания безусловно необходимо оставить. Необязательно же задавать несколько серверов для проверки, если кто-то захочет может задать один, тогда получится вариант как сейчас.

[TheBB 514]

22 минуты назад, Sfut сказал:

... А он, каким бы не был надежным, может быть временно недоступен, при доступности интернета в целом...

Можно долбить десяток серверов, расположенных по всему земному шару, но, если у вашего провайдера ...опа, то... А сервера-то рабочие по факту... Вам хочется сократить и время отклика, но, следуя вашей логике, оно (время) только увеличивается, т.к.

29 минут назад, Sfut сказал:

... Я же предлагаю принимать решение по опросу нескольких серверов. В этом случае, при доступности интернета, какой-нибудь да ответит. Если ответил хоть один - значит интернет есть...

ping серверА=нет, тогда серверВ=нет, тогда серверС=да-а-а, тогда... /итого: А+В+С+... множенное на время = до-о-офига времени.

К этому можно добавить бригаду "танкистов" (да что там бригада, сразу "танковую" армию), планомерно расстреливающую пингующую сервера, этакая пинг-атака

[Sfut 173]

Дать пользователю возможность выбора, кому 1 сервер, кому 5 в зависимости от задач.

А в общем из теории систем автоматического управления срабатывание по нескольким датчикам всегда надежнее чем по одному. 

Edited November 14, 2016 by Sfut

[KorDen 690]

- добавить указание таймаута пинга/установления TCP, возможно процент потерь. Например, если у меня обычно до тестового IP пинг не выше 20, а тут вдруг выше сотни - явно с соединением что-то не так, лучше бы уйти на резерв. Возможно ввести два состояния - warn/crit, первый - при пинге выше X, второй - при отсутствии ответа/пинге выше Y.

- перед переходом на резерв проверять сам резерв на работоспособность. Например резерв не работает, а у нас warn а не crit - тогда не уходить.

- добавить интервалы запуска, возврата после восстановления, минимальный интервал между сменами. Например, после срабатывания сидеть на резерве минимум 15 минут, после восстановления ждать 5 минут до возврата - если за это время будет опять N провалившихся проверок - увеличивать интервал и не уходить с резерва. Или скажем давать таймаут для загрузки модема.

- доработать саму проверку, об этом уже говорилось тут. Например, ввести понятие passive-active, в пассивном режиме проверяет каждые 20 секунд, если вдруг ответа нет - отправлять следующий уже через 3 секунды для ускорения проверки при недоступности. В идеале с проверкой нескольких хостов, как было описано ранее.

[Le ecureuil 3,362]

В 6/4/2017 в 12:20, KorDen сказал:

- добавить указание таймаута пинга/установления TCP, возможно процент потерь. Например, если у меня обычно до тестового IP пинг не выше 20, а тут вдруг выше сотни - явно с соединением что-то не так, лучше бы уйти на резерв. Возможно ввести два состояния - warn/crit, первый - при пинге выше X, второй - при отсутствии ответа/пинге выше Y.

- перед переходом на резерв проверять сам резерв на работоспособность. Например резерв не работает, а у нас warn а не crit - тогда не уходить.

- добавить интервалы запуска, возврата после восстановления, минимальный интервал между сменами. Например, после срабатывания сидеть на резерве минимум 15 минут, после восстановления ждать 5 минут до возврата - если за это время будет опять N провалившихся проверок - увеличивать интервал и не уходить с резерва. Или скажем давать таймаут для загрузки модема.

- доработать саму проверку, об этом уже говорилось тут. Например, ввести понятие passive-active, в пассивном режиме проверяет каждые 20 секунд, если вдруг ответа нет - отправлять следующий уже через 3 секунды для ускорения проверки при недоступности. В идеале с проверкой нескольких хостов, как было описано ранее.

Спасибо за идеи.

Давно напрашивается мысль о перепроектировании ping-check, следите за новостями.

[KorDen 690]

Постараюсь пояснить свои мысли, на всякий случай, вдруг еще идеи придут. На данный момент отлавливаются абсолютные варианты - не поднимается PPP, перебили кабель, сдох свич, сдох провайдер.

Но, кроме полного отключения, частенько встречаются ситуации, в которых пингчек будет сходить с ума и дергать туда-сюда:

- после гроз/электриков где-нибудь подгорел свич/трансивер/порт и интернет как бы вроде есть, но с ощутимыми (не обязательно большими) потерями до всего. Для игр и голоса 5-10% потерь уже ощутимы. Тут нужна возможность указать процент ппотерь и минимальное количество пакетов для статистики.

- - отдельный вариант - бесконечные перезагрузки или перестроения маршрутизации, в итоге инет отваливается каждые N минут. В этом и остальных случаях нужен период ожидания.

- упал аплинк у провайдера, первые минуты, пока BGP разойдется, половина сайтов не открывается, частично повышенный пинг, частично не изменится. Как назло, ресурс из пингчека будет работать идеально.. Тут нужна проверка нескольких ресурсов и указание максимального пинга

А сейчас просто приходится вручную тушить глючащий канал.

Edited June 5, 2017 by KorDen

[vasek00 407]

Добавлю сюда из соседней ветки про ping check

Цитата

По поводу ping check может заложить один профиль по умолчанию (который будет от разработчиков) например на ваш сервер (от KeenDNS) с нужными параметрами и на нужный порт :

1. проверка шлюза провайдера что он доступен

2. при выполнение п.1 тогда проверка доступа на 80 порт web запросом и если ответ ОК то все в порядке.

тогда наверное можно избежать нескольких проблем при настройках пользователей который используют ping check в качестве переключателя каналов.

 

[Le ecureuil 3,362]

2 часа назад, vasek00 сказал:

Добавлю сюда из соседней ветки про ping check

 

Любой captive portal / перенаправитель трафика успешно пройдет эту проверку, и железка будет ложно считать, что Интернет есть.

[vasek00 407]

1 час назад, Le ecureuil сказал:

Любой captive portal / перенаправитель трафика успешно пройдет эту проверку, и железка будет ложно считать, что Интернет есть.

Не знаю что вы имели ввиду под captive portal и каком то перенаправителе трафика идет речь, да еще и ложное срабатывание - тут всего навсего необходимо проверить канал доступа в интернет и принять решение, зачем пользователю что-то куда перенаправлять.

Microsoft использует данный метод со времен Vista, напомню принцип его работы кратко :

1. из свойств сетевой берем IP адрес шлюза, делаем запрос ARP запрос получаем MAC => вывод шлюз провайдера доступен и канал до него работает

2. проверяем DNS и сам канал это загрузка страницы с нужного ресурса, в данном случае сервер тот же что отвечает за KeenDNS - www.ххххх.хх:80 :

2.1. " HTTP:Request, GET /test.txt" и ответ "HTTP:Response, HTTP/1.1, Status: Ok, URL: /test.txt", в фале test.тхт хоть OK хоть не чего, важно его наличие на нужном месте.

по итогу данного пункта 2.1 принимаем решение, что DNS работает и маршрут до скажем до KeenDNS есть, то маршрут через данный интерефейс (имеется ввиду и default маршрут) активен и доступен и провайдер работает. Любое изменение п.2.1 - интернета на данном канале нет.

Вопрос только во временных параметрах так как TCP протокол с подтверждением и времени переключения между каналами, да и не зачем дергать каналы каждую сек или минуту, к примеру рекомендованных 5минут по умолчанию, но если пользователь хочет то пусть каждую минуту делает (тут уже в ступает в силу если хочет то пусть ставит, мы рекомендовали столько то).

Edited June 6, 2017 by vasek00

[Sergey Avksentyev 9]

Доброго всем. 

А есть ли возможность добавить в проверку не только IP адрес, но и имя хоста?  Это было бы очень удобно. Проверять DDNS, который если не виден, то он бы ребутал интерфейс WAN.

[Le ecureuil 3,362]

18 часов назад, Sergey Avksentyev сказал:

Доброго всем. 

А есть ли возможность добавить в проверку не только IP адрес, но и имя хоста?  Это было бы очень удобно. Проверять DDNS, который если не виден, то он бы ребутал интерфейс WAN.

Что значит "DDNS не виден"? Более техническим языком.

[MDP 196]

Возможно ли как-то сделать проверку на ttl ?

Например: если ttl равен заданному значению,  то всё хорошо...а если например ttl отличен от заданного, тогда переходим на альтернативное соединение...или переподключаемся?

Либо сделать возможность задавать  значение TTL в ping check ?

Провайдер иногда выдает серые адреса...а иногда белые. Есть мысль что если мы зададим пинг-чек на ближайший DNS провайдера, то он будет иметь одно значение...у меня например проходит через 4 узла, а если провайдер будет выдавать серый адрес, тогда ttl скорее всего уже будет другой (по крайней мере NAT обработку пройдет ещё дополнительно). Вот и как-бы можно сделать механизм "защиты" от получения серого адреса.

 

Edited July 11, 2017 by MDP

[KorDen 690]

1 час назад, MDP сказал:

Либо сделать возможность задавать  значение TTL в ping check ?

Как по мне, пригодится не только для таких хитрых проверок - опять же, в случае глюков у провайдера (точнее, скорее у аплинков) пакет может неестественно блуждать по куче хопов, или наоборот, какая-то железка внезапно начнет отвечать на пинг, поэтому ограничение TTL сверху и снизу в качестве одного из вариантов проверки (хоть и не идеального - ведь может поменяться что-то со стороны проверяемого сервера) вполне сгодится.

Правда тут уже надо уже функциональный граф пилить, чтобы каждый сам делал оптимальную для себя схему, но это уже как-то перебор для SOHO наверное

Типа, я хочу следующее:

- Пингуем 1.1.1.1, 2.2.2.2 каждые 20 секунд L=64, 3 пакетов (таймаут = 100ms, ожидаемый TTL=54..49);
- Проверяем TCP на 1.2.3.4:567, 5.6.7.8:123 каждые 60 секунд, таймаут = 500ms
- - хоть один TCP или ICMP не прошел проверку: принудительно пингуем 1.1.1.1 и 2.2.2.2 L=1000 10 пакетов таймаут=50ms, ожидаемый TTL=54..49, проверяем резерв на работоспособность [граф резерва]
- - - основной канал нестабилен, резерв стабилен - уходим на резерв. Основной канал не работает вообще, резерв работает хоть как-то - уходим на резерв. Резерву тоже хана - не дергаемся понапрасну

А кто-то хочет что-то другое....

[vasek00 407]

52 минуты назад, KorDen сказал:

Типа, я хочу следующее:

- Пингуем 1.1.1.1, 2.2.2.2 каждые 20 секунд L=64, 3 пакетов (таймаут = 100ms, ожидаемый TTL=54..49);
- Проверяем TCP на 1.2.3.4:567, 5.6.7.8:123 каждые 60 секунд, таймаут = 500ms
- - хоть один TCP или ICMP не прошел проверку: принудительно пингуем 1.1.1.1 и 2.2.2.2 L=1000 10 пакетов таймаут=50ms, ожидаемый TTL=54..49, проверяем резерв на работоспособность [граф резерва]
- - - основной канал нестабилен, резерв стабилен - уходим на резерв. Основной канал не работает вообще, резерв работает хоть как-то - уходим на резерв. Резерву тоже хана - не дергаемся понапрасну

Чем сложнее система выбора чего либо, тем больше шансов получать "грабли" в том или ином виде.

[vasek00 407]

2 часа назад, MDP сказал:

Провайдер иногда выдает серые адреса...а иногда белые. Есть мысль что если мы зададим пинг-чек на ближайший DNS провайдера, то он будет иметь одно значение...у меня например проходит через 4 узла, а если провайдер будет выдавать серый адрес, тогда ttl скорее всего уже будет другой (по крайней мере NAT обработку пройдет ещё дополнительно). Вот и как-бы можно сделать механизм "защиты" от получения серого адреса.

Т.е. вы хотите сказать - что для вас важно белый или серый в ракурсе то что быстрее (10 узлов) или медленнее (12 узлов) до сервера с которого просмотреть страницу или же белый для другого сервиса?

Edited July 11, 2017 by vasek00

[MDP 196]

4 минуты назад, vasek00 сказал:

Т.е. вы хотите сказать - что для вас важно белый или серый в ракурсе то что быстрее (10 узлов) или медленнее (12 узлов) до сервера с которого просмотреть страницу или же белый для другого сервиса?

Да нужен именно белый адрес...для FTP, ну иногда ещё для соединения по PPTP  с "домашней" сетью.

Скорость соединения совершенно не важна

Edited July 11, 2017 by MDP

[vasek00 407]

Только что, MDP сказал:

Да нужен именно белый адрес...для FTP, ну иногда ещё для PPTP

Ну так тут на форуме было по моему уже описание как отлавливать нужный IP на интерфейсе.

[MDP 196]

31 минуту назад, vasek00 сказал:

Ну так тут на форуме было по моему уже описание как отлавливать нужный IP на интерфейсе.

...где?

Нужно что-бы PPPoE никогда не получал адреса из диапазона 100.64.0.0/10.

Если не трудно ткните..

Ага...нашел..

Edited July 11, 2017 by MDP

[Sergey Avksentyev 9]

В 30.06.2017 в 17:47, Le ecureuil сказал:

Что значит "DDNS не виден"? Более техническим языком.

Мой провайдер иногда выдает такой IP, при получении которого ни сторонний DDNS ни от Зукселя не работает.  Вариант через облако не катит. А тут я бы например делал проверку по имени mayname.mykeenetic.ru и если он не отвечает пингом то ребутать соединение.

[Le ecureuil 3,362]

15 часов назад, Sergey Avksentyev сказал:

Мой провайдер иногда выдает такой IP, при получении которого ни сторонний DDNS ни от Зукселя не работает.  Вариант через облако не катит. А тут я бы например делал проверку по имени mayname.mykeenetic.ru и если он не отвечает пингом то ребутать соединение.

Роутер сам себе будет отвечать в лубом случае.

[Sergey Avksentyev 9]

4 часа назад, Le ecureuil сказал:

Роутер сам себе будет отвечать в лубом случае.

Аа. Ну да.. Не подумал. .Жаль (( Но в таком случае у меня есть адреса в сети, которые с этого серого адреса не работают.. Ну ладно. Я понял, спасибо.

[Dmitriy Sel 0]

для пинг чекера чочу предложить отключение точки доступа при отсутствующем интернете, сколько раз приходил домой, у оператора проблемы, а тебе не приходят на телефон сообщения, потому что АР включен без доступа  к инету

[Alexander Kudrevatykh 0]

Хотелось бы не только icmp/tcp check а http/https, т.к. при отрицательном балансе зачастую tcp/icmp говорят что все хорошо, а по факту интернета-то нет :)