Привет!
Только начал работать с функцией сторожевой собаки и вижу некоторые недостатки, которые можно исправить, добавив несколько новых полей/значений:
* **Несколько целевых IP для пинга:** Хотелось бы иметь возможность указывать до трех, потому что полагаться только на один IP – это как класть все яйца в одну корзину, а мои яйца уже пару раз разбивались. Сторожевой собаке следовало бы перезагружать роутер только если все указанные цели не ответили на пинг указанное количество раз (см. ниже).
* **Интервал пинга:** Очевидно, должен быть допустимый диапазон.
* **Количество последовательных таймаутов пинга, требуемых для перезагрузки:** Сейчас оно жёстко задано как шесть таймаутов за десятисекундные интервалы, то есть одна минута таймаутов перезагружает роутер. Это слишком мало; если мой провайдер перезагружает что-то на выделенной линии между мной и целевым сервером, например роутер, который обеспечивает мне соединение, это может спровоцировать перезагрузку на моей стороне. Возможность регулировать это значение позволит мне учесть такое. Дать больше свободы задержке. Сейчас похоже, что любой пинг сторожевой собаки, который не отвечает за несколько сотен миллисекунд, считается таймаутом. Встретить такое время ответа у шлюза нечасто, но я сейчас наблюдаю задержки больше этого в одном из моих объектов, и это вызвало перезагрузку, вызванную сторожевой собакой. К сожалению, шлюз – самый логичный выбор для цели пинга, так как это следующий узел после роутера, но вышестоящие роутеры придают этому трафику наименьший приоритет. Поэтому полезной была бы настройка максимальной допустимой задержки. Мы говорим о функции, которая будет перезагружать роутер, так что, я действительно думаю, что дополнительные средства управления оправданы.
Спасибо!
Эд
Только начал работать с функцией сторожевой собаки и вижу некоторые недостатки, которые можно исправить, добавив несколько новых полей/значений:
* **Несколько целевых IP для пинга:** Хотелось бы иметь возможность указывать до трех, потому что полагаться только на один IP – это как класть все яйца в одну корзину, а мои яйца уже пару раз разбивались. Сторожевой собаке следовало бы перезагружать роутер только если все указанные цели не ответили на пинг указанное количество раз (см. ниже).
* **Интервал пинга:** Очевидно, должен быть допустимый диапазон.
* **Количество последовательных таймаутов пинга, требуемых для перезагрузки:** Сейчас оно жёстко задано как шесть таймаутов за десятисекундные интервалы, то есть одна минута таймаутов перезагружает роутер. Это слишком мало; если мой провайдер перезагружает что-то на выделенной линии между мной и целевым сервером, например роутер, который обеспечивает мне соединение, это может спровоцировать перезагрузку на моей стороне. Возможность регулировать это значение позволит мне учесть такое. Дать больше свободы задержке. Сейчас похоже, что любой пинг сторожевой собаки, который не отвечает за несколько сотен миллисекунд, считается таймаутом. Встретить такое время ответа у шлюза нечасто, но я сейчас наблюдаю задержки больше этого в одном из моих объектов, и это вызвало перезагрузку, вызванную сторожевой собакой. К сожалению, шлюз – самый логичный выбор для цели пинга, так как это следующий узел после роутера, но вышестоящие роутеры придают этому трафику наименьший приоритет. Поэтому полезной была бы настройка максимальной допустимой задержки. Мы говорим о функции, которая будет перезагружать роутер, так что, я действительно думаю, что дополнительные средства управления оправданы.
Спасибо!
Эд
