Я работаю инженером технической поддержки в ISP. В статье поделюсь опытом построения корпоративной сети со статической маршрутизацией и резервированием каналов связи, а также автоматическим информированием об аварии на email, при ограниченном бюджете для торговой сети магазинов. Для опытных сетевых инженеров статья вряд ли будет интересной. Для админов, которым поставлена подобная задача, данная статья может пригодиться.
Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.
Ко мне обратились клиенты – местная торговая сеть. Которой мы предоставляем услуги по организации локальной сети для связи между распределенными по городу магазинами.
С технической точки зрения – провайдер выделяет им отдельный VLAN в своей сети. Все магазины (их 12) подключены к ISP через оптику используя две технологии: FTTH и PON.
Схема сети предприятия до модернизации изображена на картинке.
В двух магазинах и центральном офисе подключение по технологии Ethernet (FTTH). В остальных 9-ти магазинах подключение происходит через технологию PON (Passive Optical Network). При подключении через PON используется Huawei терминалы, модель HG810 – они же ONU (Optical Network Unit). О технологии PON можно прочесть тут.
Оборудование данной компании имеет специфические функции. Которые с одной стороны не нужны для пользователей ISP и играют позитивную роль в плане дизайна сети абонентского доступа. С другой стороны, эти функции могут иметь негативный эффект для корпоративных клиентов.
Давайте рассмотрим их подробнее:
С остальным трафиком проблем нет, никаких фильтраций и ограничений.
Касаемо проблем 2 и 3, если среди читающих найдутся инженеры, которые в своих сетях используют PON фирмы Huawei и знают, как разрешить проходимость такого трафика, буду рад совету.
На момент обращения ко мне, сеть магазинов представляла из себя плоскую, неуправляемую сеть, с одним маршрутизатором под управлением Kerio Control Server.
В сети все IP устройства из всех магазинов были видны друг другу. Таблица FDB на коммутаторах провайдера насчитывала более 350 устройств в их VLAN. Все эти устройства были в одном большом broadcast-домене.
Из-за этого в сети происходили различные сбои которые мешали работе магазинов, поэтому сеть нуждалась в сегментации.
Иногда случались аварии у провайдера из-за которых терялась связь между офисом и отдельным магазинов.
Хуже, когда случается потеря связи между центральным офисом и сетью провайдера. Именно в таком случае все 12 распределенных по городу магазинов, остаются без связи с серверами расположенными в офисе и без доступа к сети интернет. В этот период работа магазинов существенно ограничивается, пропадают возможности:
Центральный офис был подключен через Ethernet. Так как им требовалось раздавать DHCP для устройств во всех магазинах. Оптика из офиса идет в ближайший многоквартирный дом, где размещается узел связи провайдера. Когда в этом доме или домах подключённых далее пропадает электропитание – все 12 магазинов остаются без связи с офисом.
Чтобы работать в случае аварии по питанию, в главный офис заведена линия PON. Использовалась она лишь как резерв на случай падения Ethernet, т.к. через нее не проходили DHCP пакеты. Переключение между каналами связи Ethernet и PON осуществлялось вручную.
Мне были поставлены задачи:
Для выполнения данных задач куплено оборудование фирмы MikroTik. В центральный офис куплена модель RB1100AHx2, а в каждый из 12-ти магазинов MikroTik hEx (RB750Gr2).
В центральном офисе и во всех магазинах подключается второй провайдер – Ростелеком. У которого компания покупает только доступ в интернет. В центральном офисе подключение выполняется кабелем (FTTH), в магазинах через ADSL. Модемы арендуются у провайдера и работают исключительно в режиме моста.
В сети предприятия введена распределенная схема адресации:
Для работы маршрутизации между офисами введены две вспомогательные сети в которых организована связь между маршрутизаторами MikroTik:
Главный офис имеет доступ в сеть интернет через 3 канала:
Ниже пример конфигурации:
Для PPPoE от второго провайдера:
Для организации работы удаленных магазинов в случае пропажи связи между магазином и ISP-1, на главном роутере в офисе созданы по 2 пользователя VPN для каждого магазина. Это сделано чтобы каждый из магазинов имел одновременно два активных подключения через внешнюю сеть интернет на два внешних IP адреса в офисе от обоих провайдеров.
Вводим еще 2 вспомогательные сети для обмена трафиком между офисом и магазинами уже через VPN.
Включаем L2TP Server на роутере и создаем профили пользователей (здесь привожу пример для одного магазина):
Командой /interface l2tp-server добавляю жесткую привязку в разделе PPP для каждого магазина. Это делается для удобного определения какие магазины подключены. И через что идет трафик.
У нас получаются четыре сети для обмена трафиком.
Для удобства я спланировал адресацию таким образом, что сеть 192.168.15.0/24, будет доступна через 10.10.10.15, 10.10.20.15, 10.20.30.15 и 10.30.40.15, другие подсети будут иметь другие адреса соответственно.
Теперь создадим маршруты.
Я использую для разных маршрутов разные значения административного расстояния. В штатном режиме данные в магазин пойдут через сеть 10.10.10.15, т.к. у нее самый низкое значение административного расстояния – 10. Сеть 10.10.10.0/24 доступна через eth-1, а значит основной канал Ethernet от ISP-1.
В случае выхода из строя канала связи eth-1 данные будут идти по сети eth-2 через PON, если и там беда тогда уже в помощь VPN через PPPoE от ISP-2.
Пример подключения сети в офисе изображен на картинке ниже.
Выполним аналогичные настройки в удаленном магазине. Назначаем адреса:
Создаем l2tp VPN подключение
Предлагаю взглянуть на схему подключения магазина:
В случае выхода канала из строя eth-1 в удаленном магазине, он автоматически теряет связь с офисом через оба локальных маршрута, идущих через ISP-1. Тут нам на помощь приходит VPN сети 10.20.30.1 и 10.30.40.1 которые всегда подняты, причем подняты они всегда через резервный интернет канал для магазина!
Для реализации такой хитрости я создал отдельную таблицу маршрутизации для ISP-2.Также это делается для того, чтобы роутер всегда мог ответить на запросы, приходящие со стороны ISP-2 через тот-же интерфейс, но подробно на этом я останавливаться не буду.
Создаем таблицу маршрутизации для ISP-2 в магазине:
И создаем правила маршрутизации, согласно которым трафик до обоих IP VPN сервера в офисе будет ходить только через резервный интернет.
Теперь у нас всегда доступен и поднят VPN вне зависимости от того, через какой из каналов берет интернет магазин и сам роутер. Сеть VPN будет работать всегда только через резервный канал и всегда готова принять на себя миссию по связи с офисом.
Сам интернет по умолчанию работает через ISP-1 от офиса, поэтому созданы также 2 отдельные таблицы маршрутизации для доступа в интернет через офис.
Нам нужно убедится, что трафик до 10.10.10.1 и 10.10.20.1 не пойдет через дефолтный роут, откуда с некой вероятностью может прилететь ответ. Для этого я создаю жесткую привязку где искать адреса 10.10.10.1 и 10.10.20.1.
Последнее для магазина — создаем маршруты к офису.
С таблицей маршрутизации на этом все. Теперь нам нужно настроить автоматическое и максимально быстрое переключение между этими каналами связи.
В начале статьи я писал, что на мой взгляд в данном случае не очень уместна динамическая маршрутизация. Хотя она выигрывает по простоте настройки – просто банально меньше требуется создавать и писать.
Но, во-первых, большинство магазинов подключены через PON, который не пропускает multicast. И OSPF, и RIP просто не взлетели бы через локалку.
Во-вторых, у меня мало опыта работы с OSPF. И я не уверен в том, как именно она поведет себя, в случае, если канал через ISP-1 локально будет доступен, но в нем будут потери 20-25% и выше. Трафик ходить будет и пакеты с Router Hello будут видны, а вот с живым трафиком будут трудности.
Третье – это скорость реакции и переключения, по умолчанию в настройках OSPF значение Router Dead Interval равно 40 сек. Что для магазина достаточно долго (ну вот такие заказчики). Конечно, его можно подкрутить и уменьшить, но насколько стабильно тогда будет работать OSPF?
И последним вердиктом в пользу статики я назову немалое количество критики и недовольства среди пользователей MikroTik на стабильность работы OSPF. О чем, например, писалось тут.
Честно ничего против OSPF не имею. Но в данном случае, решил перестраховаться и сделать переключение через скрипт.
Как такового опыта написания скриптов я увы, не имею поэтому, некоторые мои правки, внесенные в заимствованные скрипты (первоисточники будут приведены) могут показаться вам слишком костыльными. Я всегда рад критике.
За основу скрипта проверки доступности локальных каналов связи был взят скрипт хабраюзера magnitudo.
Принцип работы скрипта прост. Мы пингуем по 7 раз каждый из интерфейсов на главном роутере большими пакетами по 1500 байт. Удовлетворительным результат считается если вернулось не менее 5 пакетов. Такой метод очень чуток к вероятным проблемам со связью в канале. Если проблемы есть – канал считается не доступным.
В зависимости от результата, устанавливаем значение административного расстояния. Увеличиваем его на 100 если канал не доступен.
Если пропадают оба канала подключенных локально, то скрипт инициирует запуск другого скрипта, отсылающего письмо о падении, либо о восстановлении.
Кто-то заметил, что у меня четыре маршрута, а скрипт проверяет только три. Это делается с целью экономии времени, т.к. все три интерфейсах (два – локально, один через инет) завязаны на основного провайдера. И если у него будет провал на всех 3х интерфейсах, тогда уже остается только последний резервный внешний VPN через ISP-2. Который всегда имеет AD = 40.
Здесь приведен скрипт из магазина, аналогичный скрипт крутится на главном роутере, для каждого магазина свой скрипт.
Кто-то подумает это же сколько скриптов постоянно будут крутится? И вообще, сколько времени нужно чтобы скрипт отработал? С каким интервалом его запускать?
Для меня критично время реакции по доступности маршрута. При проверке скрипта я пробовал засекать время отработки. В случае, когда все штатно это где-то 7 секунд.
Если какой-то из каналов не доступен и скрипт ждет ответа по тайм-ауту, то время увеличивается примерно до 15 секунд.
Что значительно быстрее чем OSPF ждущая по дефолту 40 секунд.
С каким интервалом запускать скрипт? А ни с каким! Я не делал для этого скрипта scheduler!
Этим еще быстрее сократил время реакции. Мне удалось добиться практически моментального времени реакции (на практике около 5 секунд) благодаря подключению к делу NetWatch!
Когда созданы маршруты и созданы скрипты для проверки надежности канала и уведомления об аварии, нам нужно придумать триггер запуска этих скриптов.
Создаем Netwatch для всех 3х адресов:
Поясню – NetWatch пингует хост 10.10.10.1 каждые 10 секунд, с тайм-ауте в 2 секунды. В случае падения, мы сразу превентивно устанавливаем административное расстояние +100 — делаем маршрут не активным.
После этого, мы инициализируем запуск скрипта с более точной проверкой состояния доступности локальной сети. Которая в случае ложной тревоги вернет приоритет маршрута назад, а в случае действительного падения обоих локальных каналов отправит письмо админам.
В случае восстановления пинга, мы не возвращаем сразу маршрут в качестве активного. А опять-же запускаем более детальную проверку, которая уже решит можно ли вернуться на основной канал или нет.
Такие NetWatch созданы для всех трех внутренних адресов в сети ISP-1. Которые регулярно пингуют друг друга с двух сторон и в случае проблем, моментально меняют AD и запускают более детальную проверку скриптом.
Ниже привожу листинг скрипта, уведомляющего о падении и восстановлении связи с офисом. За основу скриптов для уведомления использовал статью seventh.
Скрипт о восстановлении EMAIL-IT- RECOVER идентичен, за исключением текста.
Вот собственно и все. Хотя я не рассказал обо всем, что хотел. За скобками осталась реализация резервирования самого интернета в офисе и в филиалах, уведомление об аварии связанных с интернетом и их восстановлением. Счетчиками количества времени – сколько лежит канал в интернет. Как я ловил Wi-Fi принтер, гуляющий по магазинам через OSPF.
Спасибо всем, кто дочитал до конца. Жду вашей критики, советов, предложений. Будут вопросы, с удовольствием на них отвечу.
Если будет интересно, напишу еще по пару статей по этому проекту, с описанием некоторых костылей в работе сети, которые приходилось решать нетривиальными способами.
Последнее — общая схема подключения офиса и одного из 12 магазинов.
Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.
Часть 0. Что дано
Ко мне обратились клиенты – местная торговая сеть. Которой мы предоставляем услуги по организации локальной сети для связи между распределенными по городу магазинами.
С технической точки зрения – провайдер выделяет им отдельный VLAN в своей сети. Все магазины (их 12) подключены к ISP через оптику используя две технологии: FTTH и PON.
Схема сети предприятия до модернизации изображена на картинке.
В двух магазинах и центральном офисе подключение по технологии Ethernet (FTTH). В остальных 9-ти магазинах подключение происходит через технологию PON (Passive Optical Network). При подключении через PON используется Huawei терминалы, модель HG810 – они же ONU (Optical Network Unit). О технологии PON можно прочесть тут.
Оборудование данной компании имеет специфические функции. Которые с одной стороны не нужны для пользователей ISP и играют позитивную роль в плане дизайна сети абонентского доступа. С другой стороны, эти функции могут иметь негативный эффект для корпоративных клиентов.
Давайте рассмотрим их подробнее:
- В сети PON построенной на оборудовании компании Huawei, по умолчанию запрещен обмен трафиком, между ONU работающих от одной базовой станции (OLT – Optical Line Terminal). Эту проблему нам удалось решить, используя специальные профили для корпоративных VLAN.
- ONU не пропускает DHCP пакеты со стороны абонента по направлению в сеть провайдера. Из сети провайдера в сторону абонента – все ходит. Если подключить главный офис с DHCP сервером к распределенной корпоративной сети через ONU, то сервер находящийся в офисе не сможет раздать адреса узлам, которые находятся за пределами офиса.
- Аналогичная проблема с проходимостью Multicast – пакетов. Все Multicast пакеты, не проходят через ONU и не видятся в других участках сети.
С остальным трафиком проблем нет, никаких фильтраций и ограничений.
Касаемо проблем 2 и 3, если среди читающих найдутся инженеры, которые в своих сетях используют PON фирмы Huawei и знают, как разрешить проходимость такого трафика, буду рад совету.
На момент обращения ко мне, сеть магазинов представляла из себя плоскую, неуправляемую сеть, с одним маршрутизатором под управлением Kerio Control Server.
В сети все IP устройства из всех магазинов были видны друг другу. Таблица FDB на коммутаторах провайдера насчитывала более 350 устройств в их VLAN. Все эти устройства были в одном большом broadcast-домене.
Из-за этого в сети происходили различные сбои которые мешали работе магазинов, поэтому сеть нуждалась в сегментации.
Иногда случались аварии у провайдера из-за которых терялась связь между офисом и отдельным магазинов.
Хуже, когда случается потеря связи между центральным офисом и сетью провайдера. Именно в таком случае все 12 распределенных по городу магазинов, остаются без связи с серверами расположенными в офисе и без доступа к сети интернет. В этот период работа магазинов существенно ограничивается, пропадают возможности:
- Принимать оплату безналичными платежами.
- Проводить прием и ревизию товаров.
- Выполнять синхронизацию цен и остатков.
Центральный офис был подключен через Ethernet. Так как им требовалось раздавать DHCP для устройств во всех магазинах. Оптика из офиса идет в ближайший многоквартирный дом, где размещается узел связи провайдера. Когда в этом доме или домах подключённых далее пропадает электропитание – все 12 магазинов остаются без связи с офисом.
Чтобы работать в случае аварии по питанию, в главный офис заведена линия PON. Использовалась она лишь как резерв на случай падения Ethernet, т.к. через нее не проходили DHCP пакеты. Переключение между каналами связи Ethernet и PON осуществлялось вручную.
Мне были поставлены задачи:
- Сегментировать сеть и разбить ее на множество мелких broadcast-доменов, чтобы исключить негативное влияние в одном из них на общую сеть.
- Внедрить способ автоматического переключения внутренних каналов связи на случай если между главным офисом и провайдером пропадет связь через Ethernet или PON.
- Внедрить способ автоматического переключения связи с офисом, на случай если в каком-то конкретном магазине пропадает связь с ISP – а значит локальная связь с офисом и выход в интернет.
- Внедрить возможность автоматического уведомления системных администраторов предприятия об аварии на том или ином участке сети (пропала связь с офисом или пропал резервный интернет).
Часть 1. Решение поставленных задач
Для выполнения данных задач куплено оборудование фирмы MikroTik. В центральный офис куплена модель RB1100AHx2, а в каждый из 12-ти магазинов MikroTik hEx (RB750Gr2).
В центральном офисе и во всех магазинах подключается второй провайдер – Ростелеком. У которого компания покупает только доступ в интернет. В центральном офисе подключение выполняется кабелем (FTTH), в магазинах через ADSL. Модемы арендуются у провайдера и работают исключительно в режиме моста.
В сети предприятия введена распределенная схема адресации:
- 192.168.1.0/24 – сеть центрального офиса.
- 192.168.2.0/24 – 192.168.13.0/24 локальные сети каждого из 12 магазинов.
Для работы маршрутизации между офисами введены две вспомогательные сети в которых организована связь между маршрутизаторами MikroTik:
- 10.10.10.0/24 – сеть, приходящая в главный офис через основной Ethernet канал
- 10.10.20.0/24 – сеть, приходящая в главный офис через резервный канал (PON)
Главный офис имеет доступ в сеть интернет через 3 канала:
- ISP1-A – через Ethernet канал, с префиксом /30 IP – 1.1.1.1
- ISP1-B – через PON канал, с префиксом /30 IP – 2.2.2.2
- ISP-2 (Ростелеком) — через PPPoE, IP — 3.3.3.3
Ниже пример конфигурации:
[s@MAIN-BORDER-ROUTER] > ip address export
# nov/27/2015 22:43:50 by RouterOS 6.32.2
#
/ip address
add address=10.10.10.1/24 comment=ISP-LOCAL-ADDRESS interface=eth-1 network=10.10.10.0
add address=10.10.20.1/24 comment=ISP-RESERVE-LOCAL-ADDRESS interface=eth-2 network=10.10.20.0
add address=1.1.1.1/30 comment=ISP1-MAIN-INET-ADDRESS interface=eth-1 network=1.1.1.0
add address=2.2.2.2/30 comment=ISP1-RESERVE-INET interface=eth-2 network=2.2.2.0
add address=192.168.1.1/24 comment=OFFICE-LOCAL-ADDRESS interface=bridge-MAIN-OFFICE network=192.168.1.0
Для PPPoE от второго провайдера:
[s@MAIN-BORDER-ROUTER] > interface pppoe-client print
Flags: X - disabled, R - running
0 R name="RT-PPPoE" max-mtu=1480 max-mru=1480 mrru=1600 interface=eth-3 user="U" password="P"
profile=default keepalive-timeout=30 service-name="" ac-name="" add-default-route=no dial-on-demand=no use-peer-dns=no
allow=pap,chap,mschap1,mschap2
Для организации работы удаленных магазинов в случае пропажи связи между магазином и ISP-1, на главном роутере в офисе созданы по 2 пользователя VPN для каждого магазина. Это сделано чтобы каждый из магазинов имел одновременно два активных подключения через внешнюю сеть интернет на два внешних IP адреса в офисе от обоих провайдеров.
Вводим еще 2 вспомогательные сети для обмена трафиком между офисом и магазинами уже через VPN.
- 10.20.30.0/24 – сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-1
- 10.30.40.0/24 сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-2
Включаем L2TP Server на роутере и создаем профили пользователей (здесь привожу пример для одного магазина):
/interface l2tp-server server
set enabled=yes keepalive-timeout=15
add local-address=10.20.30.1 name=VERTOLET-VPN password=Pass profile=default-encryption remote-address=10.20.30.15 service=l2tp
add local-address=10.30.40.1 name=VERTOLET-VPN-RESERVE password=Pass profile=default-encryption remote-address=10.30.40.15 service=l2tp
/interface l2tp-server
add name=15.VERTOLET-VPN user=VERTOLET-VPN
add name=15.VERTOLET-VPN-RESERVE user=VERTOLET-VPN-RESERVE
Командой /interface l2tp-server добавляю жесткую привязку в разделе PPP для каждого магазина. Это делается для удобного определения какие магазины подключены. И через что идет трафик.
У нас получаются четыре сети для обмена трафиком.
[s@MAIN-BORDER-ROUTER] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; IT-MAIN-LOCAL-ADDRESS
10.10.10.1/24 10.10.10.0 eth-1
1 ;;; IT-RESERVE-LOCAL-ADDRESS
10.10.20.1/24 10.10.20.0 eth-2
2 D 10.30.40.1/32 10.30.40.15 2.VERTOLET-VPN-RESERVE
3 D 10.20.30.1/32 10.20.30.15 2.VERTOLET-VPN
Для удобства я спланировал адресацию таким образом, что сеть 192.168.15.0/24, будет доступна через 10.10.10.15, 10.10.20.15, 10.20.30.15 и 10.30.40.15, другие подсети будут иметь другие адреса соответственно.
Теперь создадим маршруты.
[sbl@MAIN-BORDER-ROUTER] > ip route export
# nov/27/2015 23:24:47 by RouterOS 6.32.2
#
/ip route
add comment=1.VERTOLET distance=10 dst-address=192.168.15.0/24 gateway=10.10.10.15
add comment=2.VERTOLET distance=20 dst-address=192.168.15.0/24 gateway=10.10.20.15
add comment=3.VERTOLET distance=30 dst-address=192.168.15.0/24 gateway=10.20.30.15
add comment=4.VERTOLET distance=40 dst-address=192.168.15.0/24 gateway=10.30.40.15
Я использую для разных маршрутов разные значения административного расстояния. В штатном режиме данные в магазин пойдут через сеть 10.10.10.15, т.к. у нее самый низкое значение административного расстояния – 10. Сеть 10.10.10.0/24 доступна через eth-1, а значит основной канал Ethernet от ISP-1.
В случае выхода из строя канала связи eth-1 данные будут идти по сети eth-2 через PON, если и там беда тогда уже в помощь VPN через PPPoE от ISP-2.
Пример подключения сети в офисе изображен на картинке ниже.
Выполним аналогичные настройки в удаленном магазине. Назначаем адреса:
[s@VERTOLET-GW] > ip address export
# nov/27/2015 23:47:45 by RouterOS 6.32.3
#
/ip address
add address=192.168.15.2/24 interface=bridge-VERTOLET network=192.168.15.0
add address=10.10.10.15/24 comment=LOCAL-MAIN-ADDRESS interface=ether1 network=10.10.10.0
add address=10.10.20.15/24 comment=LOCAL-RESERVE-ADDRESS interface=ether1 network=10.10.20.0
add address=192.168.15.253/30 interface=ether2 network=192.168.15.252
Создаем l2tp VPN подключение
[s@VERTOLET-GW] > interface l2tp-client export
# nov/27/2015 23:54:11 by RouterOS 6.32.3
#
/interface l2tp-client
add connect-to=2.2.2.2 disabled=no keepalive-timeout=45 mrru=1600 name=VPN-OFFICE password=Pass user=VERTOLET-VPN
add connect-to=3.3.3.3 disabled=no keepalive-timeout=45 mrru=1600 name=VPN-OFFICE-RESERVE password=Pass user=VERTOLET-VPN-RESERVE
Предлагаю взглянуть на схему подключения магазина:
В случае выхода канала из строя eth-1 в удаленном магазине, он автоматически теряет связь с офисом через оба локальных маршрута, идущих через ISP-1. Тут нам на помощь приходит VPN сети 10.20.30.1 и 10.30.40.1 которые всегда подняты, причем подняты они всегда через резервный интернет канал для магазина!
Для реализации такой хитрости я создал отдельную таблицу маршрутизации для ISP-2.Также это делается для того, чтобы роутер всегда мог ответить на запросы, приходящие со стороны ISP-2 через тот-же интерфейс, но подробно на этом я останавливаться не буду.
Создаем таблицу маршрутизации для ISP-2 в магазине:
[s@VERTOLET-GW] > ip route export
# nov/28/2015 00:13:41 by RouterOS 6.32.3
#
/ip route
add distance=1 gateway=RT-INET-Reserve routing-mark=ISP2-Reserve
И создаем правила маршрутизации, согласно которым трафик до обоих IP VPN сервера в офисе будет ходить только через резервный интернет.
[s@VERTOLET-GW] > ip route export
# nov/28/2015 00:13:41 by RouterOS 6.32.3
/ip route rule
add action=lookup-only-in-table dst-address=2.2.2.2/32 table=ISP2-Reserve
add action=lookup-only-in-table dst-address=3.3.3.3/32 table=ISP2-Reserve
Теперь у нас всегда доступен и поднят VPN вне зависимости от того, через какой из каналов берет интернет магазин и сам роутер. Сеть VPN будет работать всегда только через резервный канал и всегда готова принять на себя миссию по связи с офисом.
Сам интернет по умолчанию работает через ISP-1 от офиса, поэтому созданы также 2 отдельные таблицы маршрутизации для доступа в интернет через офис.
[s@VERTOLET-GW] > ip route export
# nov/28/2015 00:13:41 by RouterOS 6.32.3
#
/ip route
add distance=1 gateway=10.10.10.1 pref-src=10.10.10.2 routing-mark=ISP1-A
add distance=1 gateway=10.10.20.1 pref-src=10.10.20.2 routing-mark=ISP1-B
Нам нужно убедится, что трафик до 10.10.10.1 и 10.10.20.1 не пойдет через дефолтный роут, откуда с некой вероятностью может прилететь ответ. Для этого я создаю жесткую привязку где искать адреса 10.10.10.1 и 10.10.20.1.
[s@VERTOLET-GW] > ip route rule export
# nov/28/2015 00:13:41 by RouterOS 6.32.3
/ip route rule
add action=lookup-only-in-table dst-address=10.10.10.1/32 table=ISP1-A
add action=lookup-only-in-table dst-address=10.10.20.1/32 table=ISP1-B
Последнее для магазина — создаем маршруты к офису.
[s@VERTOLET-GW] > ip route export
# nov/28/2015 00:13:41 by RouterOS 6.32.3
/ip route
add comment=1.Local-NET-MAIN-IT distance=10 dst-address=192.168.1.0/24 gateway=10.10.10.1
add comment=2.Local-NET-RESERVE-IT distance=20 dst-address=192.168.1.0/24 gateway=10.10.20.1
add comment=3.Local-NET-RESERVE-INET distance=30 dst-address=192.168.1.0/24 gateway=10.20.30.1
add comment=4.Local-NET-RESERVE-INET distance=40 dst-address=192.168.1.0/24 gateway=10.30.40.1
С таблицей маршрутизации на этом все. Теперь нам нужно настроить автоматическое и максимально быстрое переключение между этими каналами связи.
Часть 2. Настройка автоматического переключения
В начале статьи я писал, что на мой взгляд в данном случае не очень уместна динамическая маршрутизация. Хотя она выигрывает по простоте настройки – просто банально меньше требуется создавать и писать.
Но, во-первых, большинство магазинов подключены через PON, который не пропускает multicast. И OSPF, и RIP просто не взлетели бы через локалку.
Во-вторых, у меня мало опыта работы с OSPF. И я не уверен в том, как именно она поведет себя, в случае, если канал через ISP-1 локально будет доступен, но в нем будут потери 20-25% и выше. Трафик ходить будет и пакеты с Router Hello будут видны, а вот с живым трафиком будут трудности.
Третье – это скорость реакции и переключения, по умолчанию в настройках OSPF значение Router Dead Interval равно 40 сек. Что для магазина достаточно долго (ну вот такие заказчики). Конечно, его можно подкрутить и уменьшить, но насколько стабильно тогда будет работать OSPF?
И последним вердиктом в пользу статики я назову немалое количество критики и недовольства среди пользователей MikroTik на стабильность работы OSPF. О чем, например, писалось тут.
Честно ничего против OSPF не имею. Но в данном случае, решил перестраховаться и сделать переключение через скрипт.
Как такового опыта написания скриптов я увы, не имею поэтому, некоторые мои правки, внесенные в заимствованные скрипты (первоисточники будут приведены) могут показаться вам слишком костыльными. Я всегда рад критике.
За основу скрипта проверки доступности локальных каналов связи был взят скрипт хабраюзера magnitudo.
Скрипт для проверки доступности локальных каналов
name="CHECK-LOCAL-ALARM" owner="admin" policy=read,write,policy,test,sniff,sensitive
#DEFINE GLOBAL VARIABALES for LOCAL-REACHIBLE-STATUS
:global GlobalITFail
#DEFINE INTERNAL PING TARGETS
:local PingCount 7 #Количество пакетов для проверки качества канала связи
# MAIN LOCAL CENTRAL-GW IP ADDRESS
:local PingTarget1 10.10.10.1 # Адрес главного роутера подключенного через основной канал
# RESERVE LOCAL CENTRAL-GW IP ADDRESS
:local PingTarget2 10.10.20.1 # Адрес главного роутера подключенного через резервный канал
# RESERVE VPN LOCAL CENTRAL-GW IP ADDRESS
:local PingTarget3 10.20.30.1 # Адрес главного роутера внутри VPN который цепляется на внешний IP ISP1-B
#CHECK MAIN LOCAL SERVER ADDRESS
:local MainLocalServerOK false;
#Проверяем доступность и качество основного локального канала связи через пинг БОЛЬШИМИ пакетами
:local PingResult1 [/ping $PingTarget1 count=$PingCount size=1500 ]
#Если из 7ми пакетов по 1500 байт вернулось МИНИМУМ 5 то канал считается доверенным
:set MainLocalServerOK ( $PingResult1 >= 5)
#CHECK RESERVE LOCAL SERVER ADDRESS
:local ReserveLocalServerOK false;
:local PingResult2 [/ping $PingTarget2 count=$PingCount size=1500 ]
:set ReserveLocalServerOK ( $PingResult2 >= 5)
# Все тоже самое для резервного локального канала
#CHECK VPN LOCAL SERVER ADDRESS
:local VpnLocalServerOK false;
# К каналу через VPN у нас более лояльные требования пинг стандартными пакетами, количество меньше
:local PingResult3 [/ping $PingTarget3 count=5 ]
:set VpnLocalServerOK ( $PingResult3 >= 4)
### Информация для отладки скрипта при запуске через /system script run <>
:put "MainLocalServerOK=$MainLocalServerOK"
:put "ReserveLocalServerOK=$ReserveLocalServerOK"
:put "VpnLocalServerOK=$VpnLocalServerOK"
#DEFINE GATEWAYS Administrative Distances
#Смотрим какие текущие Административные расстояния присвоены маршрутам
:local MainLocalServerGWDistance [/ip route get [find comment="1.Local-NET-MAIN-IT"] distance]
:local ReserveLocalServerGWDistance [/ip route get [find comment="2.Local-NET-RESERVE-IT"] distance]
:local VpnLocalServerGWDistance [/ip route get [find comment="3.Local-NET-RESERVE-INET"] distance]
### Информация для отладки скрипта при запуске через /system script run <>
:put "MainLocalServerGWDistance=$MainLocalServerGWDistance"
:put "ReserveLocalServerGWDistance=$ReserveLocalServerGWDistance"
:put "VpnLocalServerGWDistance=$VpnLocalServerGWDistance"
###
#SETUP ADMINISTRATIVE DISTANCE
# FROM MAIN LOCAL SERVER
if ($MainLocalServerOK) do={
if ($MainLocalServerGWDistance != 10) do={
/log warning "Switch LOCAL-ROUTE to MAIN LOCAL SERVER"
}
/ip route set [find comment="1.Local-NET-MAIN-IT"] distance=10
}
if (!$MainLocalServerOK) do={
/ip route set [find comment="1.Local-NET-MAIN-IT"] distance=110
}
###
# FROM RESERVE LOCAL SERVER
if (!$MainLocalServerOK && $ReserveLocalServerOK) do={
/log warning "Switch LOCAL-ROUTE to RESERVE LOCAL SERVER"
}
if ($ReserveLocalServerOK && ($ReserveLocalServerGWDistance != 20)) do={
/ip route set [find comment="2.Local-NET-RESERVE-IT"] distance=20
}
if (!$ReserveLocalServerOK && ($ReserveLocalServerGWDistance != 120)) do={
/ip route set [find comment="2.Local-NET-RESERVE-IT"] distance=120
}
###
#FROM VPN LOCAL SERVER
if (!$MainLocalServerOK && !$ReserveLocalServerOK && $VpnLocalServerOK) do={
/log warning "Switch LOCAL-ROUTE to RESERVE LOCAL SERVER"
}
if ($VpnLocalServerOK && ($VpnLocalServerGWDistance != 30)) do={
/ip route set [find comment="3.Local-NET-RESERVE-INET"] distance=30
}
if (!$VpnLocalServerOK && ($VpnLocalServerGWDistance != 130)) do={
/ip route set [find comment="3.Local-NET-RESERVE-INET"] distance=130
}
####
### Далее идет секция, посвященная информированию системных администраторов. Информирование будет выполнятся за счет запуска отдельных внешних скриптов. Один для падения, другой для восстановления.
####INFORMING############################################
:local ITfail false;
#Если связь с офисом не доступна через оба сети 10.10.10.0/24 и 10.10.20.0/4, тогда магазин потерял связь с офисом через основной канал ISP-1 и вынужден (при возможности) работать через VPN.
if (!$MainLocalServerOK && !$ReserveLocalServerOK) do={
:set ITfail true;
}
# Если связь с офисом доступна хотя-бы через одну из двух сетей, значит магазин по оптике подключен к сети ISP и со связью с ним все хорошо, алармов мы в этом случае не шлем
if ($MainLocalServerOK) do={
:set ITfail false;
}
if ($ReserveLocalServerOK) do={
:set ITfail false;
}
# Модуль запуска внешних скриптов для отсылки email
# Для информационного вывода переменных, при ручном запуске скрипта из консоли
:put "1.ITfail=$ITfail"
:put "1.1.GlobalITFail=$GlobalITFail"
#Сравниваем локальное значение полученное в результате запуска скрипта, со значением глобальным полученным в результате прошлых работ скрипта
if ($ITfail != $GlobalITFail) do={
if ($ITfail && !$GlobalITFail) do={
:set GlobalITFail true;
/log error "WARNING!!!! IT-MAIN LIK IS DOWN!!!!"
:delay 8
/system script run EMAIL-IT-FAIL
}
if (!$ITfail && $GlobalITFail) do={
:set GlobalITFail false;
/log warning " IT-MAIN LINK RECOVERED!!!!!"
/system script run EMAIL-IT-RECOVER
} }
Принцип работы скрипта прост. Мы пингуем по 7 раз каждый из интерфейсов на главном роутере большими пакетами по 1500 байт. Удовлетворительным результат считается если вернулось не менее 5 пакетов. Такой метод очень чуток к вероятным проблемам со связью в канале. Если проблемы есть – канал считается не доступным.
В зависимости от результата, устанавливаем значение административного расстояния. Увеличиваем его на 100 если канал не доступен.
Если пропадают оба канала подключенных локально, то скрипт инициирует запуск другого скрипта, отсылающего письмо о падении, либо о восстановлении.
Кто-то заметил, что у меня четыре маршрута, а скрипт проверяет только три. Это делается с целью экономии времени, т.к. все три интерфейсах (два – локально, один через инет) завязаны на основного провайдера. И если у него будет провал на всех 3х интерфейсах, тогда уже остается только последний резервный внешний VPN через ISP-2. Который всегда имеет AD = 40.
Здесь приведен скрипт из магазина, аналогичный скрипт крутится на главном роутере, для каждого магазина свой скрипт.
Кто-то подумает это же сколько скриптов постоянно будут крутится? И вообще, сколько времени нужно чтобы скрипт отработал? С каким интервалом его запускать?
Для меня критично время реакции по доступности маршрута. При проверке скрипта я пробовал засекать время отработки. В случае, когда все штатно это где-то 7 секунд.
Если какой-то из каналов не доступен и скрипт ждет ответа по тайм-ауту, то время увеличивается примерно до 15 секунд.
Что значительно быстрее чем OSPF ждущая по дефолту 40 секунд.
С каким интервалом запускать скрипт? А ни с каким! Я не делал для этого скрипта scheduler!
Этим еще быстрее сократил время реакции. Мне удалось добиться практически моментального времени реакции (на практике около 5 секунд) благодаря подключению к делу NetWatch!
Когда созданы маршруты и созданы скрипты для проверки надежности канала и уведомления об аварии, нам нужно придумать триггер запуска этих скриптов.
Создаем Netwatch для всех 3х адресов:
[s@VERTOLET-GW] > tool netwatch export
# nov/28/2015 01:53:17 by RouterOS 6.32.3
/tool netwatch
add down-script="/ip route set [find comment="1.Local-NET-MAIN-IT"] distance=110\r \n/system script run CHECK-INET-ALARM\r \n/system script run CHECK-LOCAL-ALARM\r \n" host=10.10.10.1 interval=10s timeout=2s up-script= "/system script run CHECK-INET-ALARM\r \n/system script run CHECK-LOCAL-ALARM"
Поясню – NetWatch пингует хост 10.10.10.1 каждые 10 секунд, с тайм-ауте в 2 секунды. В случае падения, мы сразу превентивно устанавливаем административное расстояние +100 — делаем маршрут не активным.
После этого, мы инициализируем запуск скрипта с более точной проверкой состояния доступности локальной сети. Которая в случае ложной тревоги вернет приоритет маршрута назад, а в случае действительного падения обоих локальных каналов отправит письмо админам.
В случае восстановления пинга, мы не возвращаем сразу маршрут в качестве активного. А опять-же запускаем более детальную проверку, которая уже решит можно ли вернуться на основной канал или нет.
Такие NetWatch созданы для всех трех внутренних адресов в сети ISP-1. Которые регулярно пингуют друг друга с двух сторон и в случае проблем, моментально меняют AD и запускают более детальную проверку скриптом.
Ниже привожу листинг скрипта, уведомляющего о падении и восстановлении связи с офисом. За основу скриптов для уведомления использовал статью seventh.
Скрипт уведомления о падении канала связи в магазине
Скрипт о падении EMAIL-IT-FAIL
:local sysname [/system identity get name];
:local smtpserv [:resolve "you_mail_server "];
:local Eaccount "you_username";
:local pass "you_password";
:local date [/system clock get date];
:local time [/system clock get time];
:local mailto you@mail.yu
/tool e-mail send to=$mailto from=you@mail. \
user=$Eaccount password=$pass server=$smtpserv port=587 start-tls=yes subject=("$sysname-ALARM!!!") body=("ВНИМАНИЕ В МАГАЗИНЕ $sysname ПРОПАЛА СВЯЗЬ С ОФИСОМ! Если письмо дошло до вас, значит магазин работает через VPN. Дата отправки письма $time $date")
Скрипт о восстановлении EMAIL-IT- RECOVER идентичен, за исключением текста.
Конец
Вот собственно и все. Хотя я не рассказал обо всем, что хотел. За скобками осталась реализация резервирования самого интернета в офисе и в филиалах, уведомление об аварии связанных с интернетом и их восстановлением. Счетчиками количества времени – сколько лежит канал в интернет. Как я ловил Wi-Fi принтер, гуляющий по магазинам через OSPF.
Спасибо всем, кто дочитал до конца. Жду вашей критики, советов, предложений. Будут вопросы, с удовольствием на них отвечу.
Если будет интересно, напишу еще по пару статей по этому проекту, с описанием некоторых костылей в работе сети, которые приходилось решать нетривиальными способами.
Последнее — общая схема подключения офиса и одного из 12 магазинов.
Комментарии (14)
AntiHelper
01.12.2015 17:03+2Очень обстоятельно вы подошли к статье…
1) Но зачем Вам нужен l2-сегмент с отсутствующими преимуществами l2? Может лучше просто в gre или ipip запихнуть? Это такой стандартный костыль, который уже давно не костыль т.к помогает отслеживать состояние соединения с удалённым офисом.
2) Проблемы с OSPF(если они действительно есть в нынешних версиях, т.к. за последние 3 года их не встречал) в Вашем случае неважны, т.к. у Вас должна быть одна Area и в принципе пофиг на авторизацию в тунельных интерфейсах.
3) OSPF на этих объёмах Вам бы ничего не сократил, т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов. Но OSPF всё-равно более правильный вариант решения этой проблемы — понять это можно только попробовав и вникнув.
feo_sobolev
01.12.2015 22:50+1Спасибо за проявленный интерес к статье.
1. Что именно Вы имеете ввиду под l2-сегментом? То, что дает провайдер? Или то, что для маршрутизации между магазинами я использую прямой l2-сегмент и роутинг идет напрямую на IP-адреса интерфейсов без внутренних туннелей?
У меня были мысли, создать внутренние туннели. Действительно, тогда было бы удобнее отслеживать падение магазинов. Так-же, это помогло бы решить проблему с непроходимостью OSPF. Но, мне не хотелось делать лишние инкапсуляции при передачи данных между магазинам по основным каналам. Поэтому, я решил отказаться от внутреннего туннелирования. Да и отследить проблему падения магазина помогает скрипт в магазине, на случай если он отвалится. В случае, если отвалится один из приходящих каналов от ISP-1 в офисе, то соответственно отвалится один из каналов в интернет (идущих через ISP-1). В таком случае, письмо с уведомлением о падении интернет канала придет из главного офиса. Магазины в таком случае, будут молча работать через второй внутренний канал от ISP-1.
Плюс в таблице маршрутизации линки, которые не работают будут с АД равным = 110,120,130 соответственно от рабочих 10,20,30.
По пунктам 2 и 3. Я полностью с Вами согласен насчет того, что через OSPF было бы правильнее. Но, так как, мне еще нужно было брать интернет в магазинах из центрального офиса (от ISP-1), то я остановился на статической маршрутизации и только скриптах.
т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов
А вот это было решающим.
Но, хочу сказать, что в данном проекте я все равно поднял OSPF, но использую ее не для связи между магазинами, а для другой цели, о чем кратко упомянул в статье:
Как я ловил Wi-Fi принтер, гуляющий по магазинам через OSPF.
Хочу посвятить этой теме отдельную небольшую статью в будущем.
Так-же, думаю описать в статье свои изменения в скрипте пользователя magnitudo. Который я использую и в магазинах, и в центральном офисе. Может, кому-то будет интересно и пригодится.
l0ser140
02.12.2015 12:31Можно было запускать пинги параллельно в разных скриптах по расписанию и передавать результат по каждому пингу в глобальную переменную.
l0ser140
02.12.2015 13:05Или еще десяток секунд можно сократить, храня в памяти результаты 7 последних пингов.
Скрипт, запускаемый раз в секунду, будет пинговать лишь 1 раз, класть результат в глобальную переменную, при этом сдвигая прошлые результаты назад. Ну обычная такая очередь.
А скрипт с логикой, который теперь тоже можно раз в секунду запускать, будет просто смотреть на результаты последних 7 пингов, а не пинговать каждый раз по 7 раз.
Время реакции наверное до 2-4 секунд уменьшится.feo_sobolev
02.12.2015 13:23Спасибо за интерес к статье.
Мне как раз таки не хотелось, чтобы на роутере запускалось много скриптов с низким интервалом. Так-же не очень хотелось создавать много переменных. Если я правильно понял Вас, то по-идее, для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Собственно, для заказчика сейчас идеальное время реакции… И наиболее важно в отличии от обычного OSPF, что именно тестируется качество канала связи.
Чуть позже, я думаю, напишу статью о том, как именно поставляется и резервируется сам интернет, а не связь между магазинами. Там, я как раз использую глобальные переменные, но немного для других целей.
Получается, что у меня 3 канала в интернет. Хотя из трех каналов, по факту, два от одного провайдера, с одинаковым выходом с мир (от провайдера) и политикой нарезки скорости. Но, для клиента, эти 2 канала абослютно независимы друг от друга физически. Балансировки нет.l0ser140
02.12.2015 13:29для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Можно использовать массивы.
А почему 100 переменных в памяти — много? Только если в плане удобства их использования.
Может массив массивов (не уверен, что это работает, сам не пробовал), будет 1 переменная, но например 1 магазин уже не так просто добавить/убрать, не накосячив с выходом за границы и т.д.
AcidVenom
Как обстоят дела с кодировкой кириллицы при отправке сообщения электронной почтой?
seventh
Нормально.
AcidVenom
Да, все в норме. В 6.32 были какие-то проблемы с кодировкой, приходили кракозябры.
feo_sobolev
Почту отправляю через учетку заведенную на Яндексе. Письма отправляю на gmail. C отображение кодировок проблем нет. Единственный момент, это некорректное отображение при чтении письма с gmail через почтовый клиент HTC Sense.
Через клиент gmail все отображение корректно.
AcidVenom
Возможно, проблема именно в Gmail'е. Идентичная ситуация и у меня (HTC, Gmail, Outlook), после переезда на Mail.ru отображается корректно.
feo_sobolev
Я не совсем понял, что именно у Вас переехало на Mail.ru?
Учетка, которая используется маршрутизатором для отправки e-mail? (В моем случае Яндекс)
Или учетка на которую маршрутизатор шлет письма? (В моем случае Gmail)
AcidVenom
Gmail на отправке, Gmail на приеме. При этом была проблема.
Mail на отправке, Mail на приеме сейчас. HTC корректно отображает, Outlook нет.
feo_sobolev
Понял, спасибо за информацию. Сильных проблем это не доставляет. Но, в случае чего, буду иметь ввиду.