что такое резервный канал
Резервный канал Интернета
Бесперебойность Интернет-соединения — потребность каждой современной компании. Любые технические работы со стороны провайдера могут повлечь отключение от сети на несколько часов, а следовательно — практически заморозить жизнь офиса на это время. В текущей конкурентной среде бизнес не может позволить себе такую роскошь. Поэтому необходимой страховкой на случай внезапного отключения соединения является резервный канал связи.
Резервирование каналов связи. Основные плюсы
Потеря связи, даже на час, может создать ощутимые проблемы и замедлить бизнес-процессы компании.
Резервирование линий Интернета позволит исключить критические перебои соединений и обеспечит стабильную передачу данных;
Быть на связи 24/7, без прерываний — не только преимущество, но и необходимость.
Клиенты выбирают компании, которые готовы ответить в любую минуту и не пытаются оправдаться отсутствием соединения или техническими издержками третьей стороны;
Еще одно преимущество иметь резервный Интернет канал — возможность распределить трафик и предотвратить технические сбои при возросших на сеть нагрузках.
Какими бывают резервные каналы связи
Самый распространённый способ выхода в Интернет — проводное соединение. И некоторые организации выбирают в качестве страховки второй такой же кабель от другого поставщика услуг;
Прекрасный вариант, особенно если используется оборудование MikroTik или Ubiquiti.
Модем оператора подключается к маршрутизатору, настраивается, а при падении основного канала — мгновенно возобновляет прерванное соединение. Такой способ пользуется спросом в небольших компаниях;
С помощью радиомостов можно соединить объекты, расположенные друг от друга на значительном расстоянии (вплоть до 100км при соответствующей видимости).
Связь организуется посредством установки мощного специализированного оборудования. Работу по настройке радиомостов можно доверить только серьезной IT-организации;
Это самый редкий вариант резервирования, поскольку он наиболее затратный, и, как правило, требуется крупным предприятиям.
Чаще всего оптоволокно прокладывают до здания, а в самом здании по офисам ведут кабели Ethernet или настраивают бесшовный Wi-Fi.
Важное уточнение: подключение каналов связи разных провайдеров, но проходящих по одному физическому носителю, по большому счёту не является резервированием — при физическом повреждении кабеля обе линии перестанут работать.
Какие ещё возможности даёт организация резервного Интернет-канала?
Кроме выполнения очевидной задачи — обеспечения автоматического возобновления передачи данных при неполадках основного соединения — резервирование каналов связи позволит решить и другие вопросы:
Интернет — неотъемлемая часть бизнеса, существование без которой в современном мире невозможно. Поэтому так важно следить за тем, чтобы эта часть работала устойчиво и не «отваливалась» в самый неподходящий момент. Качественная организация двух (или более) каналов связи — гарантия стабильности соединения. Но тут важно уточнение — именно «качественная», так как если провести настройку с ошибками, то и второй канал не спасёт. Поэтому лучше не пытайтесь выполнить данную работу самостоятельно.
Позаботьтесь о своей ИТ-инфраструктуре, обезопасьте бизнес от форс-мажорных ситуаций, доверив работу профессионалам.
Резервный канал Интернета — как сделать?
Для бизнеса важен вопрос стабильности подключения к Интернету в офисах, представительствах, на торговых точках. Для большинства организаций внезапное отключение от сети означает частичную или полную приостановку работы компании, значительные убытки. Во избежание таких ситуаций стоит провести резервный канал Интернета. Распространенные операции, которые сотрудники офиса не смогут выполнить без подключения к сети:
Любая такая проблема может привести к простою, ухудшению репутации и прямым убыткам компании. При этом каждый руководитель отдельно решает, насколько для его бизнеса важно бесперебойное подключение к сети и стоит ли выделять средства на подключение резервного Интернет-канала.
Виды подключения резервному канала Интернета
При организации резервной линии подключения к Интернету можно использовать разные типы подключения. Подробнее о них можно узнать в статье «Как выбрать интернет-провайдера — 9 параметров». Надежный вариант — это заключение договоров с двумя провайдерами. Каналы от них могут использоваться одновременно или поочередно.
На заметку! Оба интернет-провайдера могут зависеть от одной и той же проблемы, например, неполадки оборудования в региональном дата-центре. В таком случае ни одна из подключенных линий работать не будет.
Можно использовать резервный канал Интернета, который подключается в случае форс-мажора. Возможные варианты:
Отключенный USB-модем с деньгами на счету, который может пополняться после наступления форс-мажора. В случае проблем с основным подключением модем подключается к раздаточному оборудованию, и офис продолжает свою работу.
В случае отсутствия Интернета к роутеру подключается телефон в режиме точки доступа.
На заметку! Не все тарифные планы поддерживают раздачу Интернета. Например, для некоторых тарифов Билайн такую услугу нужно подключать отдельно.
Вы договариваетесь с соседом, подключенному к другому провайдеру, что в случае форс-мажоров Вы можете подключаться к сети друг друга.
Организация резервного подключения — это гарантия доступа к сети в любой ситуации. Запасной Интернет-канал обеспечивает стабильную коммуникацию внутри офиса и при работе с клиентами. Сегодня даже маленькие фирмы подключаются к резервным линиям, потому что из-за простоя при большом количестве заявок бизнес может понести значительные убытки.
Подключение резервной линии Интернета в Москве
Закажите настройку резервной линии у специалистов аутсорсинговой компании «Lan-Star». Мы качественно выполним все необходимые работы по подключению запасного канала, подберем оборудование и гарантированно обеспечим бесперебойную работу вашей организации, что минимизирует возможные убытки. Для получения дополнительной информации свяжитесь с нами по телефону (посмотреть) или закажите обратный звонок.
Резервирование внутренних и внешних каналов связи, статическая маршрутизация, корпоративная сеть на 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 и играют позитивную роль в плане дизайна сети абонентского доступа. С другой стороны, эти функции могут иметь негативный эффект для корпоративных клиентов.
Давайте рассмотрим их подробнее:
Касаемо проблем 2 и 3, если среди читающих найдутся инженеры, которые в своих сетях используют PON фирмы Huawei и знают, как разрешить проходимость такого трафика, буду рад совету.
На момент обращения ко мне, сеть магазинов представляла из себя плоскую, неуправляемую сеть, с одним маршрутизатором под управлением Kerio Control Server.
В сети все IP устройства из всех магазинов были видны друг другу. Таблица FDB на коммутаторах провайдера насчитывала более 350 устройств в их VLAN. Все эти устройства были в одном большом broadcast-домене.
Из-за этого в сети происходили различные сбои которые мешали работе магазинов, поэтому сеть нуждалась в сегментации.
Иногда случались аварии у провайдера из-за которых терялась связь между офисом и отдельным магазинов.
Хуже, когда случается потеря связи между центральным офисом и сетью провайдера. Именно в таком случае все 12 распределенных по городу магазинов, остаются без связи с серверами расположенными в офисе и без доступа к сети интернет. В этот период работа магазинов существенно ограничивается, пропадают возможности:
Чтобы работать в случае аварии по питанию, в главный офис заведена линия PON. Использовалась она лишь как резерв на случай падения Ethernet, т.к. через нее не проходили DHCP пакеты. Переключение между каналами связи Ethernet и PON осуществлялось вручную.
Мне были поставлены задачи:
Часть 1. Решение поставленных задач
Для выполнения данных задач куплено оборудование фирмы MikroTik. В центральный офис куплена модель RB1100AHx2, а в каждый из 12-ти магазинов MikroTik hEx (RB750Gr2).
В центральном офисе и во всех магазинах подключается второй провайдер – Ростелеком. У которого компания покупает только доступ в интернет. В центральном офисе подключение выполняется кабелем (FTTH), в магазинах через ADSL. Модемы арендуются у провайдера и работают исключительно в режиме моста.
В сети предприятия введена распределенная схема адресации:
Ниже пример конфигурации:
Для PPPoE от второго провайдера:
Для организации работы удаленных магазинов в случае пропажи связи между магазином и ISP-1, на главном роутере в офисе созданы по 2 пользователя VPN для каждого магазина. Это сделано чтобы каждый из магазинов имел одновременно два активных подключения через внешнюю сеть интернет на два внешних IP адреса в офисе от обоих провайдеров.
Вводим еще 2 вспомогательные сети для обмена трафиком между офисом и магазинами уже через VPN.
Командой /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.
Последнее для магазина — создаем маршруты к офису.
С таблицей маршрутизации на этом все. Теперь нам нужно настроить автоматическое и максимально быстрое переключение между этими каналами связи.
Часть 2. Настройка автоматического переключения
В начале статьи я писал, что на мой взгляд в данном случае не очень уместна динамическая маршрутизация. Хотя она выигрывает по простоте настройки – просто банально меньше требуется создавать и писать.
Но, во-первых, большинство магазинов подключены через 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 магазинов.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
Значение интернета в повседневной жизни и деятельности предприятий всех форм и размеров с каждым днем только растет, особенно сейчас, когда весь мир переходит на дистанционные методы работы в связи с пандемией короновируса. Но этот вопрос актуален также и для торговых предприятий, платежные карты используются практически каждым вторым покупателем и отсутствие интернета мгновенно скажется на выручке предприятия. В данной статье мы рассмотрим, каким образом можно организовать резервный канал и обеспечить быстрое переключение на него и обратно штатными средствами RouterOS.
Как показывает читательский отклик, маршрутизация для многих администраторов является достаточно сложной темой. Тем не менее если вы внимательно выполните все инструкции данной статьи, то всё будет работать. Однако слепое выполнение инструкций не добавляет понимания происходящих процессов и, если что-то пойдет не так вы окажетесь в весьма затруднительном положении, поэтому перед тем, как перейти к практике мы выполним небольшой теоретический ликбез.
Теория
Действительно, маршрутизация достаточно сложная тема, поэтому мы сознательно упростили многие моменты для того, чтобы обеспечить понимание процессов начинающими в объеме необходимом для решения поставленной задачи.
Что такое маршрутизация? Это процесс определения пути следования данных в сетях связи. Его можно сравнить с прокладкой маршрута с использованием навигатора, вы задаете начальную и конечную точку и получаете несколько вариантов проезда с указанием всех промежуточных точек. В некоторых точках маршрут может разделяться на несколько вариантов, из которых вы можете выбрать наиболее оптимальный, исходя из оценки текущей дорожной обстановки.
Для каждого узла маршрута, а наш роутер является одним из них, решение о маршрутизации принимается на основании таблицы маршрутизации. Рассмотрим ее простейший вариант, за основу мы взяли стандартный вывод в терминале Mikrotik и добавили дополнительные данные, сейчас они могут быть непонятны, но ниже мы будем к ним обращаться.
Прежде всего разберемся как заполняется таблица маршрутизации. Это может происходить несколькими способами:
К одной цели могут вести несколько маршрутов, приоритетом их выбора является значение административной дистанции, чем ниже это значение, тем выше приоритет у маршрута. Если вернуться к нашей аналогии с навигатором, то он может проложить нам несколько маршрутов, но приоритет получит самый короткий. Но если на этом маршруте возникнут серьезные затруднения, скажем, пробка или авария, то мы можем выбрать более длинный маршрут. Также и здесь, если маршрут с наименьшей административной дистанцией недоступен, то выбирается маршрут с более высокой дистанцией.
Теперь разберемся как все это работает. Допустим мы хотим обратиться к узлу 8.8.8.8, роутер берет таблицу маршрутизации и осуществляет в ней поиск наилучшего маршрута к запрашиваемому узлу. В нашем случае искать особо нечего и это будет «нулевой» маршрут со шлюзом 192.168.3.1. Но маршрутизаторы крупных сетевых узлов могут содержать тысячи и десятки тысяч маршрутов и поэтому поиск может оказаться совсем не простым и дешевым действием.
Коротко напомним о том, что такое «нулевой» маршрут или шлюз по умолчанию, он используется в том случае, если в таблице для узла назначения не было найдено ни одного подходящего маршрута. Проще говоря, если роутер не знает куда отправить данные, он отправляет их шлюзу по умолчанию. Особой записи для узла 8.8.8.8 в нашей таблице нет, поэтому будет использоваться «нулевой» маршрут.
В нашем случае основной задачей маршрутизатора будет определить интерфейс выхода, т.е. куда именно физически нужно направить данные, чтобы они добрались до требуемого места назначения. Поэтому роутер снова начинает поиск в таблице маршрутизации чтобы определить каким образом следует добраться до искомого адреса шлюза 192.168.3.1, согласно таблице, будет найден маршрут к сети 192.168.3.0/24 через интерфейс ether5. Так как интерфейс выхода определен, то поиск прекращается и роутер формирует необходимый тип данных для передачи на канальном уровне.
Здесь тоже следует дать краткие пояснения, если интерфейс выхода является сетью Ethernet, то роутер выполнит ARP-запрос для адреса шлюза и сформирует Ethernet-кадр, а если это туннельный интерфейс точка-точка (VPN, PPPoE), то выполнит инкапсуляцию IP-пакета и отправит его на другую сторону туннеля.
И здесь мы приходим к следующим соображениям: таблица маршрутизации может быть большая и поиск по ней может быть затратным, в тоже время шлюз будет располагаться в одной из непосредственно присоединенных сетей, возможно следует ограничить поиск только по ним?
По умолчанию данные опции имеют следующее значение:
Таким образом область поиска существенно снижается и маршрут к шлюзу ищется только среди непосредственно присоединенных сетей. Теперь самое время перейти к рекурсивной маршрутизации.
Mikrotik имеет возможность проверять доступность шлюза, используя для этого пинг, если шлюз оказывается недоступным, то маршрут становится неактивным. Это хорошо, но позволяет выявлять только проблемы в сети провайдера, и если шлюз остается доступным, то маршрут будет продолжать оставаться активным, несмотря на остуствие доступа в интернет. Но что, если указать в качестве шлюза удаленный высокодоступный узел?
Давайте рассмотрим следующую таблицу маршрутизации:
В качестве шлюза по умолчанию мы указали адрес одного из DNS-серверов Cloudflare, обратите внимание, что такой адрес не должен использоваться в вашей сети, потому что после отказа связанного с ним провайдера он окажется недоступен. Теперь мы можем проверять наличие интернета за пределами сети провайдера и своевременно переключать маршруты в случае его недоступности.
Теперь разберемся как это работает. Когда мы хотим связаться с каким-либо узлом в сети интернет маршрутизатор выполнит поиск по таблице маршрутизации и, если не указано иных маршрутов, выберет «нулевой» в котором указан шлюзом 1.1.1.1, так как найден адрес, то поиск будет продолжен, чтобы определить интерфейс выхода. Так как указанный нами шлюз не находится ни в одной из непосредственно присоединенных сетей, то сделать это не удастся и такой маршрут работать не будет.
Практика
Будем считать что на вашем роутере уже настроен доступ к двум провайдерам и мы не будем останавливаться на этапе базовой настройки, если вы испытываете затруднения с этим, то обратитесь к нашей статье: Базовая настройка роутера MikroTik.
Перед тем, как переходить к дальнейшим настройкам нам нужно выяснить и запомнить адреса шлюзов провайдеров, для этого можно заглянуть на закладку Nexthops, для коммутируемых подключений (VPN, PPPoE) следует проверить свойства соответствующего соединения.
Внимание! Дальнейшие действия следует производить имея физический доступ к устройству!
После этого доступ в интернет по обоим каналам пропадет. Имейте это ввиду при планировании работ.
Эти же действия через терминал:
Затем добавим два рекурсивных «нулевых» маршрута. Для первого провайдера:
Для второго провайдера:
То же самое быстро в терминале:
Теперь таблица маршрутизации будет выглядеть следующим образом:
Наши маршруты добавились как рекурсивные и активным является маршрут через основного провайдера. Теперь имитируем аварию у первого провайдера, буквально через 10-20 секунд таблица маршрутизации изменится и рабочим станет маршрут через резервный канал:
После того, как первый провайдер устранит неисправность снова произойдет изменение маршрутов и рабочим снова станет основной канал.
Как видим на практике все оказалось достаточно просто, но мы уверены, что слепое повторение инструкций без понимания сути производимых действий никого и никогда ни к чему хорошему не приводило, поэтому настоятельно советуем не пренебрегать теоретической частью материала.
Рекурсивная маршрутизация и PPPoE
При использовании PPPoE подключения вы рано или поздно столкнетесь с проблемой изменения адреса шлюза провайдера, это может произойти даже при наличии выделенного IP адреса. После чего маршрут к высокодоступному узлу перестает работать, что приводит к полной неработоспособности этого провайдера. Диагностика такой неисправности может оказаться весьма затруднительной если вы не сталкивались с данной проблемой ранее и недостаточно четко представляете себе принципы работы рекурсивных маршрутов.
Чтобы этого избежать используем одну небольшую хитрость. Вспомним, о чем мы говорили в теоретической части. При использовании PPPoE соединения адрес шлюза провайдера роутеру как таковой не нужен. Он используется только для определения интерфейса выхода. Для работы протокола PPP, который лежит в основе PPPoE, IP-адреса не требуются. Это дает возможность самостоятельно присвоить произвольный адрес для удаленного конца туннеля и использовать его в качестве шлюза.
В терминале это можно сделать так:
После чего назначим этот профиль вашему PPPoE соединению:
И после его перезапуска убедимся, что удаленный адрес соединения теперь соответствует назначенному нами:
Теперь можно использовать данный адрес как шлюз для этого провайдера, не беспокоясь о возможных изменениях.
Рекурсивная маршрутизация и DHCP
Описанная выше проблема актуальна и для провайдеров, выдающих настройки по DHCР, в том случае если у клиента нет выделенного IP-адреса, текущий адрес может быть назначен из нескольких диапазонов, а следовательно, будет изменен и адрес шлюза. В отличие от PPPoE здесь мы не сможем задать произвольный адрес, поэтому нам на выручку придут скрипты.
Прежде всего добавим к маршруту для высокодоступного узла через шлюз провайдера уникальный комментарий, например, ISP1.
Теперь при каждом новом получении адреса по DHCP скрипт будет находить наш маршрут и изменять в нем значение шлюза на реально полученный адрес. Попробуем смоделировать данную ситуацию и выдадим нашему роутеру адрес первого провайдера из другого диапазона. Как видим, все автоматически изменилось согласно вновь полученных настроек:
Таким образом мы снова успешно решили задачу поддержания маршрутной информации в актуальном состоянии несмотря на ее возможные изменения со стороны провайдера.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 