Резервирование каналов передачи и уведомление пользователей о переключении на резевного провайдера, Андрей Сычев (www.mikrotik.net.ua, Украина). Доклад основан на реальном пректе, а именно есть несколько удаленных офисов
имеющих два подключения - проводное и через 3G модем.
При работе основного провайдера пользователи имеют выход в Интернет и доступ к
базе данных в центральном офисе через SSTP туннель.
Для проверки работоспособности провайдеров используется check-gateway хоста в
Интернет через recurcive next-hop.
При падении основного канала происходит перестроение туннеля через 3G модем, но
при этом скорость ниже и доступ в Интернет не предоставляется. Пользователи
начинают нервничать и звонить в техподдержку, это напрягает и я сделал
следующее - настроил web-proxy и завернул трафик с помощью redirect на него.
Теперь пользователь при обращении на веб страницу переадресовывается на
страницу с информацией о том что у нас технические проблемы, мы их решаем, но
работать с базой данных и звонить по телефону можно, для особо нетерпеливых
есть телефон техподдержки провайдера и инструкция что им говорить.
При восстановлении канала все возвращается обратно. В результате имеем снижение
непродуктивных обращений в техподдержку.
В конце расскажу как отлаживать такую систему фильтруя ICMP запросы к тестовым
хостам в таблице output.
Если это сильно просто и обрыв связи на 20-30 секунд критичен, можно построить
два туннеля через основного и резервного провайдера и балансировать трафик с
помощью OSPF или средствами статической маршрутизации.
. PDF: http://mum.mikrotik.com/presentations/RU16/presentation_3819_1475562317.pdf.
имеющих два подключения - проводное и через 3G модем.
При работе основного провайдера пользователи имеют выход в Интернет и доступ к
базе данных в центральном офисе через SSTP туннель.
Для проверки работоспособности провайдеров используется check-gateway хоста в
Интернет через recurcive next-hop.
При падении основного канала происходит перестроение туннеля через 3G модем, но
при этом скорость ниже и доступ в Интернет не предоставляется. Пользователи
начинают нервничать и звонить в техподдержку, это напрягает и я сделал
следующее - настроил web-proxy и завернул трафик с помощью redirect на него.
Теперь пользователь при обращении на веб страницу переадресовывается на
страницу с информацией о том что у нас технические проблемы, мы их решаем, но
работать с базой данных и звонить по телефону можно, для особо нетерпеливых
есть телефон техподдержки провайдера и инструкция что им говорить.
При восстановлении канала все возвращается обратно. В результате имеем снижение
непродуктивных обращений в техподдержку.
В конце расскажу как отлаживать такую систему фильтруя ICMP запросы к тестовым
хостам в таблице output.
Если это сильно просто и обрыв связи на 20-30 секунд критичен, можно построить
два туннеля через основного и резервного провайдера и балансировать трафик с
помощью OSPF или средствами статической маршрутизации.
. PDF: http://mum.mikrotik.com/presentations/RU16/presentation_3819_1475562317.pdf.
- Category
- MikroTik
- Tags
- mikrotik, routerboard, routeros
Be the first to comment