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

[Sfut]

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

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

Edited October 24, 2016 by Sfut

[Across]

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

[vitgan]

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

[drugold]

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

[TheBB]

В 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]

В 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]

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

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

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

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

[Sfut]

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

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

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

[TheBB]

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

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

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

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

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

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

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

[Sfut]

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

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

Edited November 14, 2016 by Sfut

[KorDen]

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

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

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

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

[Le ecureuil]

В 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]

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

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

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

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

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

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

Edited June 5, 2017 by KorDen

[vasek00]

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

Цитата

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

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

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

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

 

[Le ecureuil]

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

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

 

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

[vasek00]

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]

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

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

[Le ecureuil]

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

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

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

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

[MDP]

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

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

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

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

 

Edited July 11, 2017 by MDP

[KorDen]

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]

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]

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

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

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

Edited July 11, 2017 by vasek00

[MDP]

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

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

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

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

Edited July 11, 2017 by MDP

[vasek00]

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

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

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

[MDP]

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

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

...где?

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

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

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

Edited July 11, 2017 by MDP

[Sergey Avksentyev]

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

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

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

[Le ecureuil]

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

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

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

[Sergey Avksentyev]

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

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

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

[Dmitriy Sel]

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

[Alexander Kudrevatykh]

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

[Alexander]

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

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

Хочу поддержать автора предложения с небольшим дополнением. Сейчас в методе проверки доступности интернета (ping-check профиле) "Автоматический" уже реализована проверка нескольких узлов (google.com, facebook.com, yahoo.com), однако нет никакой возможности изменить этот список или создать новый профиль со своим списком даже через CLI.

Предлагаю реализовать такую возможность!

Так же хотел бы уточнить у разработчиков алгоритм проверки в режиме "Автоматический".

Цитата

Интервал проверки — 10 секунд. Минимальное число успешных попыток для перехода из выключенного состояния во включенное — 5. Число неуспешных попыток для перехода из включенного состояния в выключенное — 5.

Узлы перебираются циклически или только в случае недоступности первого в списке?