ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Протоколы группы FHRP (First Hop Redundancy Protocols)
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Итак начнём с HSRP
Протокол HSRP рассчитан на 2 роутера, 3 это уже лишний и с этим уже справиться протокол GLBP
Сам VPC должен получить следующие настройки: IP : 192.168.0.10/24 GW: 192.168.0.254
TRACKING
R1,R2,R0 будут настраиваться одинаково, принцип сохраняется.
А теперь нюансы HSRP
Поэтому рекомендуют использовать HSRP version 2(по умолчанию вкл 1 максимум 255 процессов,а во 2 их 4095) и использовать наилучший приоритет для того роутера, который сейчас в сети root primary за текущий VLAN. И хорошей практикой будет если номер VLAN будет совпадать с номером процесса HSRP. ( № HSRP = VLAN )
Диагностика
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Применение VRRP в MikroTik RouterOS (часть 1)
Ближайшие
тренинги Mikrotik
MTCEWEEnterprise Wireless Engineer
Места
проведения
г. Санкт-Петербург, Крестовский остров, Северная дорога, дом 12.
г. Санкт-Петербург, ст. м. «Приморская»,
ул. Одоевского, д. 24 к. 1, 2 этаж
Механизмы протокола VRRP, особенности реализации и конфигурации в операционной системе RouterOS. Сценарии использования для повышения доступности услуг в локальной сети.
VRRP в MikroTik RouterOS
Для улучшения своей доступности сети нуждаются в избыточных каналах связи, коммутаторах и маршрутизаторах. Когда к сети LAN подключены два и более маршрутизаторов, используемых как стандартные маршрутизаторы для хостов в локальной сети, целесообразным решение является применение FHRP.
В рамках статьи будут рассмотрены принципы работы протокола VRRP, описание реализации протокола в Микротик RouterOS и простейшие примеры использования в сетевых схемах.
Принципы работы протокола VRRP
На сети, имеющей избыточную топологию, выделяется несколько (два и более) маршрутизаторов, которые будут выполнять роль маршрутизатора по умолчанию для устройств из LAN-сегмента. На каждом из маршрутизаторов создаётся виртуальный интерфейс, которым присваивается одинаковые ip- и MAC- адреса.
Посредством обмена служебными сообщениями, среди маршрутизаторов выбирается active, который будет обрабатывать пакеты от хостов в LAN, предназначенные шлюзу по умолчанию. Остальные устройства становятся passive-маршрутизаторами, проверяющие доступность master-устройства. Таким образом, для конечных пользователей одновременно существует лишь один шлюз по умолчанию, представляющий из себя виртуальное устройство.
Рассмотрим схему на рисунке 1, условившись, что маршрутизаторы R1 и R2 используют протокол VRRP для LAN-сегмента.
Для обмена служебными сообщениями маршрутизаторы должны находиться в одном широковещательном домене 192.168.25.0/24. Кроме того, адрес виртуального маршрутизатора также принадлежит этой сети, но с более узкой маской – 192.168.25.254/32 (если использовать одинаковые маски на физическом и виртуальном интерфейсах, относящихся к одной сети, то в таблице маршрутизации будет формироваться два connected-маршрута с поддержкой ECMP и протокол VRRP может работать некорректно).
В процессе обмена служебными сообщениями маршрутизаторы должны распределить между собой роли, выбрав какое из устройств будет в данный момент являться active, а какое находиться в резерве. Протокол подразумевает следующие роли:
Служебные сообщения инкапсулируются в ip-пакет со следующими специфическими параметрами:
| Параметр | Значение |
|---|---|
| Номер протокола | 112 |
| ip-адрес отправителя | ip-адрес интерфейса, ассоциированного с широковещательным доменом |
| ip-адрес получателя | 224.0.0.18 |
| TTL | 255 (если получен служебный пакет со значением TTL, отличным от 255, пакет будет отброшен) |
После распределения ролей master-маршрутизатор продолжает рассылку служебных сообщений для backup-маршрутизаторов с заданной периодичностью interval. В случае отсутствия служебных сообщений от master в течении down-interval (down-interval=3*interval), backup-маршрутизаторы повторяют процедуру распределения ролей, выбирая master среди существующих backup. В этот момент на пользовательских устройствах наблюдается кратковременный перерыв связи.
Приоритет маршрутизатора
Приоритет (priority) — параметр, влияющий на процесс распределения ролей: устройства с бОльшим значением приоритета становится master. Значение приоритета является целым числом, лежащим в интервале от 1 до 255, однако существует несколько зарезервированных значений:
значение приоритета, формируемое в advertisement-сообщении master-маршрутизатором в случае его выключения.
Предназначено для ускоренного запуска процесса выбора master среди backup-маршрутизаторов, не дожидаясь down-interval
значение приоритета owner-маршрутизатора (RouterOS позволяет вручную выставить данное значение, однако,
для совместимости с другим оборудованием, использование этого значения не рекомендуется)
Preemption-mode
Рассмотрим ситуацию, когда маршрутизатор R1 в схеме на рисунке 1 имеет приоритет 254, а маршрутизатор R2 — 100. При конфигурации VRRP маршрутизатор R1 становится master, а R2 — backup. При выходе из строя R1, функцию master возьмёт на себя R2 в соответствии с логикой протокола.
Опция preemption-mode указывает на то, станет ли R1 master-маршрутизатором после восстановления: если опция активна, то при восстановлении работоспособности R1 будет заново запущен процесс распределения ролей и R1 станет master, а R2 — backup.
Owner-маршрутизаторы игнорируют сконфигурированное значение preemption-mode, принимая его равным “yes”.
Параметры виртуального маршрутизатора
При создании интерфейса виртуального маршрутизатора (меню /interface vrrp) возможны следующие настройки:
| Параметр | Значение | Совпадение на всех устройствах | Комментарий |
|---|---|---|---|
| arp | (disabled | enabled | proxy-arp | reply-only; Default: enabled) | не требуется | режим работы протокола arp на виртуальном маршрутизаторе |
| authentication | (ah | none | simple; Default: none) | требуется | режим аутентификации |
| interface | (string) | не требуется | имя интерфейса, ассоциированного с широковещательным доменом |
| interval | (time [10ms..4m15s]; Default: 1s) | требуется | интервал рассылки служебных advertisement сообщений, формируемых master |
| mtu | (Default: 1500) | не требуется | размер mtu |
| name | (string) | не требуется | имя виртуального интерфейса |
| on-backup | (script text) | не требуется | текст скрипта, запускаемый в случае перехода роли маршрутизатора из master в backup |
| on-master | (script text) | не требуется | текст скрипта, запускаемый в случае перехода роли маршрутизатора из backup в master |
| password | (string) | требуется | значение пароля при использовании аутентификации |
| preemption-mode | (yes | no; Default: yes) | требуется | опция приоритетного режиме |
| priority | (integer: 1..254; Default: 100) | не требуется | приоритет маршрутизатора |
| v3-protocol | (ipv4 | ipv6; Default: ipv4) | требуется | используемый протокол (опция применяется только для vrrp ver.3) |
| version | (integer [2, 3]; Default: 3) | требуется | версия протокола vrrp (в версии 3 добавлена поддержка ipv6) |
| vrid | (integer: 1..255; Default: 1) | требуется | идентификатор виртуального маршрутизатора |
Пример стандартной схемы VRRP
Рассмотрим схему, когда локальной сети есть два маршрутизатора R1 (192.168.25.1) и R2 (192.168.25.2), используемые как маршрутизаторы по умолчанию, R1 имеет больший приоритет, чем R2. Каждый из маршрутизаторов имеет доступ в Интернет, который в данной схеме эмулирует маршрутизатор R3, на котором создан loopback-интерфейс с ip-адресом 8.8.8.8. Клиентское устройство представлено персональным компьютером с ip-адресом 192.168.25.100. 
Конфигурация устройств
На интерфейсе локальной сети ether4 настраиваем работу протокола vrrp с vrid=25 и высшим приоритетом 254. Интерфейс в сторону провайдера ether1 ассоциируем с ip-адресом 172.16.1.2, настраиваем src-nat через этот ip-адрес и добавляем маршрут по умолчанию через адрес провайдера 172.16.1.1.
Вам помогла эта статья?
Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!
На интерфейсе локальной сети ether4 настраиваем работу протокола vrrp с vrid=25 и приоритетом по умолчанию 100. Интерфейс в сторону провайдера ether1 ассоциируем с ip-адресом 172.16.2.2, настраиваем src-nat через этот ip-адрес и добавляем маршрут по умолчанию через адрес провайдера 172.16.2.1. Интерфейс vrrp ассоциирован с ip-адресом шлюза по умолчанию 192.168.25.254, как и на маршрутизаторе R1.
Анализ VRRP
Убедимся, что маршрутизаторы обменялись служебными пакетами, выбрав master.
Проверка определения ролей на маршрутизаторе R1: 
Проверка определения ролей на маршрутизаторе R2: 
На рисунках видно, что протокол vrrp активен на интерфейсах ether4, которые подключены к локальной сети. Маршрутизатор R1 является активным в данный момент (флаг R — running) и master (флаг M — master), а маршрутизатор R2 находится в резерве (флаг B — backup).
Тестирование
Запустим ping с клиентского устройства до адреса в сети Интернет 8.8.8.8 и отключим интерфейс ether4 на маршрутизаторе R1 (команда “/interface ethernet set ether4 disabled=yes”): 
На рисунке видно, что при отключении интерфейса маршрутизатора R1 теряются два пакета, после чего связь восстанавливается.
В этот момент маршрутизатор R2 берёт на себя роль master для данного LAN-сегмента, а vrrp-интерфейс R1 становится неактивным, т.к. привязан к отключенному интерфейсу ether4.
Статус vrrp-интерфейса на маршрутизаторе R1 после отключения LAN-интерфейса: 
Статус VRRP-интерфейса на маршрутизаторе R2 после отключения R1 от LAN-сегмента:
Таким образом, связность клиентского устройства с сетью Интернет, после отключения R1, устанавливается через маршрутизатор R2 и пакеты ходят по правому плечу схемы.
Тестирования preemption-mode
Поскольку по умолчанию, при создании vrrp-интерфейса, опция preemption-mode активна, проверим её работу. Для этого совершим обратные манипуляции, активировав LAN-интерфейс на R1 (команда “/interface ethernet set ether4 disabled=no”): 
На рисунке красным прямоугольником выделен момент восстановления маршрутизатора R1. Видно, что увеличилось время ответа, однако ни один пакет при этом не потерян.
Поскольку опция preemption-mode активна и маршрутизатор R1 имеет больший приоритет, то он должен стать master, а R2 – backup. Убедимся в корректности распределения ролей между маршрутизаторами.
Проверка определения ролей на маршрутизаторе R1: 
Проверка определения ролей на маршрутизаторе R2: 
Пример стандартной схемы VRRP с отличающейся адресацией на виртуальном и системных маршрутизаторах
Протокол VRRP позволяет использовать адресацию на системных и виртуальном маршрутизаторе, относящиеся к разным подсетям, что бывает полезно в некоторых конфигурациях. Выделим для связности маршрутизаторов между собой подсеть 10.0.0.0/30 и изменим адресацию на интерфейсах локальной сети.
Vrrp что это такое
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
VRRP (Virtual Router Redundancy Protocol) — сетевой протокол, предназначенный для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию. Это достигается путём объединения группы маршрутизаторов в один виртуальный маршрутизатор и назначения им общего IP-адреса, который и будет использоваться как шлюз по умолчанию для компьютеров в сети.
Содержание
[править] Терминология протокола
[править] Описание протокола
Протокол VRRP предназначен для увеличения доступности маршрутизаторов, выполняющих роль шлюза по умолчанию.
Для группы маршрутизаторов настраивается их принадлежность виртуальному маршрутизатору. Фактически, виртуальный маршрутизатор — это группа интерфейсов маршрутизаторов, которые находятся в одной сети и разделяют Virtual Router Identifier (VRID) и виртуальный IP-адрес.
VRRP-маршрутизатор может находиться в нескольких виртуальных маршрутизаторах, каждый с уникальной комбинацией VRID/IP-адрес. Соответствия между VRID и IP-адресом должны быть одинаковыми на всех маршрутизаторах в одной сети.
В любой момент времени только один из физических маршрутизаторов выполняет маршрутизацию трафика, то есть, становится VRRP Master router, остальные маршрутизаторы в группе становятся VRRP Backup router. Если текущий VRRP Master router становится недоступным, то его роль берет на себя один из VRRP Backup маршрутизаторов — тот, у которого наивысший приоритет. Задание приоритета позволяет определить более приоритетные пути административно.
Backup-маршрутизатор не будет пытаться перехватить на себя роль Master-маршрутизатора, если только у него не более высокий приоритет, чем у текущего Master-маршрутизатора. VRRP позволяет административно запретить перехват роли Master-маршрутизатора. Единственное исключение из этого правила — VRRP-маршрутизатор всегда будет становиться Master, если он владелец IP-адреса, который присвоен виртуальному маршрутизатору.
В каждом виртуальном маршрутизаторе только Master отправляет периодические VRRP-объявления на зарезервированный групповой адрес 224.0.0.18. На канальном уровне в качестве MAC-адреса отправителя VRRP-объявлений используется виртуальный MAC-адрес.
[править] Примеры использования
Первый пример приведён для понимания принципов работы протокола. Как правило, такая схема не используется в реальных сетях.
Два маршрутизатора, R1 и R2, находятся в одном широковещательном сегменте, и на интерфейсах, которые смотрят в локальную сеть, назначены IP-адреса, соответственно 10.0.1.1 и 10.0.1.2. Компьютеры в сети используют в качестве шлюза по умолчанию R1 (обозначен DG на рисунке).
Должен быть определён виртуальный маршрутизатор, который поставит в соответствие уникальному идентификатору (VRID) IP-адрес, для которого один из маршрутизаторов является владельцем. R1 владелец IP-адреса 10.0.1.1, а R2 владелец IP-адреса 10.0.1.2. Для примера определён виртуальный маршрутизатор, для которого VRID = 1, а IP-адрес 10.0.1.1. После включения VRRP на маршрутизаторе R1 для VRID = 1, он берет на себя роль Master. Для него приоритет устанавливается равным 255, так как он является владельцем IP-адреса виртуального маршрутизатора. После включения VRRP на маршрутизаторе R2 для VRID = 1, он становится Backup-маршрутизатором. Для него приоритет устанавливается равным 100, так как он не является владельцем IP-адреса виртуального маршрутизатора.
При таких настройках, если маршрутизатор R1 доступен, все компьютеры передают трафик через R1 (обозначено стрелками на рисунке). Если R1 по каким-либо причинам выходит из строя, то VRRP переводит R2 в роль Master. После этого R2 отвечает за передачу трафика, который отправлен на IP-адрес виртуального маршрутизатора.
В первом примере IP-адрес не резервируется и используется только R2, как IP-адрес интерфейса. Следующий пример показывает как выполнить резервирование и IP-адреса R2.
Второй пример показывает схему, которая использовалась и в первом примере, но теперь маршрутизаторы используют два виртуальных маршрутизатора и оба маршрутизатора передают трафик. Такая схема более предпочтительна для использования в реальных сетях, чем предыдущая.
Половина компьютеров использует в качестве шлюза по умолчанию R1, вторая половина — R2. Настройки виртуального маршрутизатора с VRID = 1 остаются точно такими же как в первом примере. Добавляется второй виртуальный маршрутизатор с VRID = 2 и IP-адресом 10.0.1.2. Для этого виртуального маршрутизатора R2 будет выполнять роль Master, а R1 — Backup.
В примере используется не только резервирование маршрутизатора по умолчанию, но и балансировка нагрузки между двумя маршрутизаторами.
Хотя в обоих примерах использовались только два маршрутизатора, маршрутизаторов может быть и больше. Тогда будет один Master и несколько Backup и, при выходе из строя Master-маршрутизатора, приоритет, присвоенный Backup-маршрутизаторам, будет определять, кто из них будет новым Master (если приоритет больше, то маршрутизатор становится Master). Если у маршрутизаторов одинаковые значения приоритетов, то сравниваются их IP-адреса — тот у кого больше IP-адрес, будет Master.
Как правило, IP-адреса компьютерам назначаются с помощью протокола DHCP. Во втором примере DHCP-сервер должен выдавать половине компьютеров в подсети IP-адрес маршрутизатора по умолчанию 10.0.1.1, а другой половине компьютеров — 10.0.1.2. Это можно реализовать с помощью опции 82 DHCP. Идея заключается в том, чтобы выдавать компьютерам, которые подключены к разным коммутаторам, разные значения IP-адреса шлюза по умолчанию.
[править] Формат пакета VRRP
VRRP-пакеты передаются для того, чтобы передать всем VRRP-маршрутизаторам информацию о состоянии и приоритете Master-маршрутизатора, который ассоциирован с VRID.
VRRP-пакеты инкапсулируются в IP-пакеты и отправляются на адрес групповой рассылки, который зарезервирован для VRRP.
[править] Поля IP-пакета
Так как VRRP-пакеты инкапсулируются в IP-пакеты, ниже описаны значения некоторых полей IP-пакета:
[править] Параметры виртуального маршрутизатора
Параметры виртуального маршрутизатора:
[править] Таймеры VRRP
[править] Описание состояний маршрутизаторов
Диаграмма перехода между состояниями:
[править] Initialize
Цель состояния Initialize — ожидание начала работы (Startup event).
Если VRRP включен на маршрутизаторе, то:
[править] Backup
Цель состояния Backup — мониторинг доступности и состояния Master-маршрутизатора.
Когда VRRP-маршрутизатор находится в этом состоянии он должен делать следующее:
[править] Master
В состоянии Master маршрутизатор отвечает за отправку пакетов, отправленных на IP-адрес, ассоциированный с виртуальным маршрутизатором.
Когда VRRP-маршрутизатор находится в этом состоянии, он должен делать следующее:
Резервирование маршрутизатора с использованием протокола VRRP
Мы запустили новую услугу: резервирование маршрутизатора с использованием протокола VRRP (за рубежом она известна под названием failover IP. Насколько нам известно, в России до нас никто ничего подобного не делал. Услуга будет интересна в первую очередь тем, кто хотел бы обеспечить постоянную доступность бизнес-значимых интернет-ресурсов, но при этом не обладает для этого достаточными техническими возможности: не имеет ни собственной автономной системы, ни блока IP-адресов, ни подключений к провайдерам по протоколу BGP.
Об особенностях её технической реализации мы подробно расскажем в этой статье.
Выбираем схему резервирования
Представим себе, что у нас есть критически важный для бизнеса интернет-ресурс, который должен всегда доступен большому количеству пользователей. У этого ресурса www.mysite.ru есть IP-адрес 12.34.56.78, выданный провайдером в составе блока 12.34.56.72/29.
Сетевые настройки ресурса (адрес, маска и шлюз по умолчанию) выглядят так:
Чтобы повысить уровень доступности конечного хоста, требуется резервирование сетевой инфраструктуры.
Для резервирования на уровне L2 в простейшем случае используется Virtual Chassis/Fabric/MC-LAG. Тогда конечный хост подключается сети дата-центра с использованием LAG (Etherchannel):
Возможными точками отказа являются сам конечный хост и маршрутизатор.
Резервирование конечного хоста — это ответственность заказчика. Очень желательно, чтобы конечный и резервный хост были расположены в разных дата-центрах. Это позволит избежать многих проблем (с сетевой структурой, с доступностью конкретного физического сервера, с электропитанием и охлаждением на отдельно взятых площадках).
Организовать перенос IP-адреса между основным и резервным хостами можно разными способами.В пределах одного L2-сегмента это можно сделать с помощью протоколов CARP/HSRP/VRRP и их аналогов:
О полноценном резервировании на уровне дата-центра можно вести речь только в случае, если все компоненты сервиса зарезервированы, и у них нет единой точки отказа.
Идеальную схему резервирования можно представить так:
Конечный и резервный хосты заказчика находятся в разных дата-центрах. Маршрутизаторы, принадлежащие оператору, также расположены в разных дата-центрах. Дата-центры могут быть соединены несколькими каналами связи.
При возникновении неисправности в одном из дата-центров конечный хост все равно остаётся доступным. Описанный подход можно использовать для резервирования как по L2-, так и по L3-схемам.
Резервирование маршрутизаторов
Примером резервирования на уровне L3 может служить anycast-маршрутизация и использованием BGP с вышестоящим оператором. Каждый из хостов анонсирует на маршрутизаторы оператора связи сеть 12.34.56.72/29 с разным приоритетом. При этом каждый хост подключается к маршрутизаторам оператора связи отдельной подсетью, отдельным VLAN’ом:
При использовании L2-схемы оператор организует единый L2-домен между основным и резервным хостами. Между маршрутизаторами организуется VXLAN или MPLS-туннель:
VXLAN / MPLS помогают организовать резервирование с использованием нескольких каналов связи между маршрутизаторами провайдера.
Конечный и резервный хосты между собой используют VRRP или его аналоги. Таким образом IP-адрес 12.34.56.78 оказывается на активном в текущий момент хосте (если оба хоста активны — то на сконфигурированном master-хосте). Конечный хост получает IP-адрес из этой сети — 12.34.56.77, резервый хост получает адрес из той же сети — 12.34.56.76. Если на хостах установлена ОС Windows, то вместо VRRP можно использовать NLB-кластеризацию.
Аналогичная схема строится и со стороны оператора. Оба маршрутизатора участвуют в одном VRRP-домене и разделяют между собой адрес шлюза по умолчанию —12.34.56.73/29. Маршрутизатор 1 является предварительно сконфигурированным мастером с физическим IP-адресом 12.34.56.73, а маршрутизатор 2 — резервным маршрутизатором с физическим адресом 12.34.56.74; адрес 12.34.56.73 для него является виртуальным и активным только в момент недоступности маршрутизатора 1.
Если случится неисправность: как это работает
В нормальной ситуации работают оба маршрутизатора и оба хоста заказчика. Один из маршрутизаторов на этапе построения схемы назначается основным (мастером) и отвечает на адрес 12.34.56.73. Аналогичным образом обстоит дело и с хостами: один из них является основным и отвечает на запросы на адрес 12.34.56.78. Второй маршрутизатор и второй хост являются резервными.
Запросы из Интернета проходят через маршрутизатор 1 и попадают на основной конечный хост. На маршрутизаторах присутствует ARP-запись 12.34.56.78 с МАС-адресом 0000:5E00:01xx, указывающим в сторону основного хоста. Основной хост отвечает хостам в Интернете по роутингу через маршрутизатор 1 (для хостов указан default gateway 12.34.56.73). Для сокращения сетевой задержки основной маршрутизатор размещается в том же дата-центре, что и основной хост.
Что происходит, когда один из хостов недоступен? VRRP на резервном хосте определяет, что основной хост перестал отвечать на keep-alive запросы, и на резервном хосте устанавливается IP-адрес 12.34.56.78:
апросы из интернета попадают на маршрутизатор 1; он в своей ARP-таблице видит МАС-адрес, соответствующий IP-адресу 12.34.56.78 со стороны маршрутизатора 2 и отправляет трафик на резервный хост. Резервный хост отправляет ответный трафик на шлюз по умолчанию 12.34.56.73, т.е. через маршрутизатор 1. При использовании этой схемы увеличивается сетевая задержка между хостами в Интернете и резервируемым хостом.
После устранения неисправностей IP-адрес 12.34.56.78 снова становится доступен на основном хосте, и схема работает в штатном режиме.
Аналогичным образом эта схема работает в случае неисправности сетевой инфраструктуры между маршрутизатором и конечным хостом:
При выходе промежуточного коммутатора из строя основной хост по-прежнему остаётся носителем адреса 12.34.56.78, но у него нет сетевой связи с маршрутизатором и он не участвует в обработке запросов из Интернета. Резервный хост, потеряв связность с основным, становится ответственным за адрес 12.34.56.78.
Если становится недоступным маршрутизатор 1 или вообще весь дата-центр 1 целиком, то схема работает исключительно через маршрутизатор 2 и резервный хост:
После восстановления инфраструктуры схема переходит в работу в штатном режиме. Практически никакие неисправности в дата-центре 2 не влияют на доступность конечного хоста.
Данное решение позволяет осуществлять инсталляцию и обслуживание высокодоступных ресурсов, полноценное их резервирование и разнесение в раздельные дата-центры.
Заключение
В этой статье мы рассмотрели технологии резервирования сетевых подключений с использованием протокола VRRP. Соответствующую услугу можно заказать в нашей панели управления.
Если у вас есть вопросы — добро пожаловать в комментарии. Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем к нам в блог.