MultiWan не работает без Reset States
-
Снятие галки State Killing on Gateway Failure помогло! После пропадания основного канала, через три потерянных пакета, пинг возобновляется через резервный канал сам! Спасибо большое!
Allow default gateway switching я ставил еще в начале, когда всё делал по инструкции из ссылки в первом посте.
Но столкнулся с новой неприятностью:
При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как сделать, что бы это работало и в обратную сторону? -
Снятие галки State Killing on Gateway Failure помогло!
Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.
По крайней мере в 2.0.3 failower корректно отрабатывает, настройки State Killing on Gateway Failure в 2.0.3 вообще нет.
При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?
Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.
А как\чем вы смотрите, с какого шлюза идет пинг?
-
Снятие галки State Killing on Gateway Failure помогло!
Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.
У меня в версии 2.1.4 эта галка была по умолчанию, и именно после её снятия заработало как надо.
А как\чем вы смотрите, с какого шлюза идет пинг?
Я делаю трасерт во втором окне параллельно и вижу, что трасерт проходит по старом маршруту.
После Reset States начитнает работать по правльному. -
У меня в версии 2.1.4 эта галка была по умолчанию, и именно после её снятия заработало как надо.
Вероятно авторы pfSense перепутали поведение\описание этой настройки.
-
При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?
Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.
Так как решить проблему без ручного сброса states? Хотелось бы автоматическую систему =(
-
Бредовая идея, но :
1. Делаем reset states руками.
2. Возвращаем "галку" на State Killing on Gateway Failure.
3. Снова делаем reset states руками.
4. Проверяем работу failover.Почему ? Потому что именно включение этой опции заставляет корректно работать failover.
P.s. Отпишитесь разработчикам pfsense, если все же проблема не решается. Этим поможете многим (тысячам) :)
Заранее благодарен. -
Бредовая идея, но :
1. Делаем reset states руками.
2. Возвращаем "галку" на State Killing on Gateway Failure.
3. Снова делаем reset states руками.
4. Проверяем работу failover.Почему ? Потому что именно включение этой опции заставляет корректно работать failover.
Попробовал по вашей схеме. Не помогло.
Затем вчитался в коммент к галочке:
The monitoring process will flush states for a gateway that goes down if this box is not checked. Check this box to disable this behavior.
Выходит галочки не должно быть, что бы работало. Ну и ладно, без неё работает переключение хорошо.
Но проблема при возврате на основной интернет канал остаётся! Reset states не происходит! Новые соединения работают по основному каналу, а старые, продолжают работать по резервному! Как это победить?
Перешел даже на последнюю версию 2.1.5. Полностью переустановил всё с форматированием. Та же проблема. -
В 2.1.2 все работает норм. Странно, но галочка state killing
Стоит по умолчанию. В начале у меня были траблы с переключением при падении, но проблема решилась галкой Allow default gateway switching. По поводу возврата на основной шлюз, я считаю, да так и есть в моей реализации, что переключение обратно должно произойти по закрытию старых сессий, то есть все новые сессии будут открываться на восстановившемся канале.
Такой способ правильнее для конечного сайта(ресурса).
И вот еще, 30 сек на самом деле долго для переключения, скорее всего из за dhcp на wan, хоть и наверняка у твоего провайдера твой мак уже сопоставлен с ip. Попробуй сделать default gateway интерфейс со статикой и протестировать схему. -
Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
как сделать? -
Извини, но я хз.
-
@ton:
Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
как сделать?В опциях правил, разрешающих телефонный трафик, есть опция, управляющая поведением этого трафика в States. По умолчанию там Keep state. Может быть поменять его на другую опцию - no-state ?
-
Проблема была в том, что был выключен мониторинг маршрута резервного канала, который должен пинговать шлюз на доступность.
Всем спасибо за страдания! =) -
@ton:
Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
как сделать?В телефонном оборудовании (как правило сервер) есть опция, которая постоянно посылает пакеты. Изза того, что state всегда поддерживается - мы видим то, что траффик не уходит в новый маршрут. Я сделал на своём астериске quality =60000 и всё стало норм.
