...

вторник, 1 декабря 2015 г.

[Из песочницы] Резервирование внутренних и внешних каналов связи, статическая маршрутизация, корпоративная сеть на MikroTik

Я работаю инженером технической поддержки в ISP. В статье поделюсь опытом построения корпоративной сети со статической маршрутизацией и резервированием каналов связи, а также автоматическим информированием об аварии на email, при ограниченном бюджете для торговой сети магазинов. Для опытных сетевых инженеров статья вряд ли будет интересной. Для админов, которым поставлена подобная задача, данная статья может пригодиться.

Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.

Часть 0. Что дано


Ко мне обратились клиенты – местная торговая сеть. Которой мы предоставляем услуги по организации локальной сети для связи между распределенными по городу магазинами.

С технической точки зрения – провайдер выделяет им отдельный VLAN в своей сети. Все магазины (их 12) подключены к ISP через оптику используя две технологии: FTTH и PON.

Схема сети предприятия до модернизации изображена на картинке.

В двух магазинах и центральном офисе подключение по технологии Ethernet (FTTH). В остальных 9-ти магазинах подключение происходит через технологию PON (Passive Optical Network). При подключении через PON используется Huawei терминалы, модель HG810 – они же ONU (Optical Network Unit). О технологии PON можно прочесть тут.

Оборудование данной компании имеет специфические функции. Которые с одной стороны не нужны для пользователей ISP и играют позитивную роль в плане дизайна сети абонентского доступа. С другой стороны, эти функции могут иметь негативный эффект для корпоративных клиентов.

Давайте рассмотрим их подробнее:

  1. В сети PON построенной на оборудовании компании Huawei, по умолчанию запрещен обмен трафиком, между ONU работающих от одной базовой станции (OLT – Optical Line Terminal). Эту проблему нам удалось решить, используя специальные профили для корпоративных VLAN.
  2. ONU не пропускает DHCP пакеты со стороны абонента по направлению в сеть провайдера. Из сети провайдера в сторону абонента – все ходит. Если подключить главный офис с DHCP сервером к распределенной корпоративной сети через ONU, то сервер находящийся в офисе не сможет раздать адреса узлам, которые находятся за пределами офиса.
  3. Аналогичная проблема с проходимостью Multicast – пакетов. Все Multicast пакеты, не проходят через ONU и не видятся в других участках сети.

С остальным трафиком проблем нет, никаких фильтраций и ограничений.

Касаемо проблем 2 и 3, если среди читающих найдутся инженеры, которые в своих сетях используют PON фирмы Huawei и знают, как разрешить проходимость такого трафика, буду рад совету.

На момент обращения ко мне, сеть магазинов представляла из себя плоскую, неуправляемую сеть, с одним маршрутизатором под управлением Kerio Control Server.

В сети все IP устройства из всех магазинов были видны друг другу. Таблица FDB на коммутаторах провайдера насчитывала более 350 устройств в их VLAN. Все эти устройства были в одном большом broadcast-домене.

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

Иногда случались аварии у провайдера из-за которых терялась связь между офисом и отдельным магазинов.

Хуже, когда случается потеря связи между центральным офисом и сетью провайдера. Именно в таком случае все 12 распределенных по городу магазинов, остаются без связи с серверами расположенными в офисе и без доступа к сети интернет. В этот период работа магазинов существенно ограничивается, пропадают возможности:

  1. Принимать оплату безналичными платежами.
  2. Проводить прием и ревизию товаров.
  3. Выполнять синхронизацию цен и остатков.

Центральный офис был подключен через Ethernet. Так как им требовалось раздавать DHCP для устройств во всех магазинах. Оптика из офиса идет в ближайший многоквартирный дом, где размещается узел связи провайдера. Когда в этом доме или домах подключённых далее пропадает электропитание – все 12 магазинов остаются без связи с офисом.

Чтобы работать в случае аварии по питанию, в главный офис заведена линия PON. Использовалась она лишь как резерв на случай падения Ethernet, т.к. через нее не проходили DHCP пакеты. Переключение между каналами связи Ethernet и PON осуществлялось вручную.

Мне были поставлены задачи:

  1. Сегментировать сеть и разбить ее на множество мелких broadcast-доменов, чтобы исключить негативное влияние в одном из них на общую сеть.
  2. Внедрить способ автоматического переключения внутренних каналов связи на случай если между главным офисом и провайдером пропадет связь через Ethernet или PON.
  3. Внедрить способ автоматического переключения связи с офисом, на случай если в каком-то конкретном магазине пропадает связь с ISP – а значит локальная связь с офисом и выход в интернет.
  4. Внедрить возможность автоматического уведомления системных администраторов предприятия об аварии на том или ином участке сети (пропала связь с офисом или пропал резервный интернет).

Часть 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 магазинов.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

на
Ярлыки: ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)