Vrrp что это такое
Принцип работы протокола VRRP
FHRP (First Hop Redundancy Protocol) — семейство протоколов, предназначенных для создания избыточности шлюза по умолчанию. Общей идеей для данных протоколов является объединение нескольких маршрутизаторов в один виртуальный маршрутизатор с общим IP адресом. Этот IP адрес будет назначаться на хостах как адрес шлюза по умолчанию. Свободной реализацией данной идеи является протокол VRRP (Virtual Router Redundancy Protocol). В этой статье рассмотрим основы протокола VRRP.
VRRP-маршрутизаторы объединяются в один виртуальный маршрутизатор. Все маршрутизаторы в группе имеют общий виртуальный IP (VIP) адрес и общий номер группы или VRID (Virtual Router Identifier). Один маршрутизатор может состоять в нескольких группах, каждая из которых должна иметь свою уникальную пару VIP/VRID.
В случае с Cisco виртуальный маршрутизатор задается на интересующем нас интерфейсе командой:
Все маршрутизаторы делятся на два типа: VRRP Master и VRRP Backup.
VRRP Master — это маршрутизатор, который занимается пересылкой пакетов для данного виртуальной группы.
VRRP Backup — это маршрутизатор, который ожидает пакет от Master. Если пакеты от Master перестают приходить, Backup пытается перейти в состояние Master.
Маршрутизатор становится Master, если имеет наивысший приоритет. Master постоянно рассылает сообщения на широковещательный адрес 224.0.0.18, чтобы сообщить Backup маршрутизаторам, что он работает. Master отправляет сообщения согласно таймеру Adver Timer, равный по умолчанию 1 секунде.
При этом в качестве MAC адреса отправителя используется адрес группы 00:00:5E:00:01:xx, где xx — VRID в шестнадцатеричном формате. В данном примере используется первая группа.
Если Backup маршрутизаторы не получают сообщения в течении трех Adver Timer (Master Down Timer), то новым Master становится маршрутизатор с наибольшим приоритетом, либо маршрутизатор с наибольшим IP. При этом Backup маршрутизатор с более высоким приоритетом перехватит роль Master с более низким приоритетом. Однако, когда у Backup отключен режим preempt, Backup не станет перехватывать роль у Master.
Если VRRP-маршрутизатор является владельцем VIP адреса, то он всегда перехватывает роль Master.
VRRP приоритет задается в значениях от 1 до 254. Значение 0 зарезервировано для случаев, когда Master необходимо снять с себя ответственность за маршрутизацию. Значение 255 устанавливается маршрутизатору владельцу VIP. Приоритет по умолчанию равен 100, но может задаваться административно:
Здесь мы можем увидеть приоритет маршрутизатора, когда он задан административно:
А тут представлен случай, когда маршрутизатор является владельцем VIP:
VRRP маршрутизатор может иметь три состояния: Initialize, Backup, Master. Эти состояния маршрутизатор последовательное меняет.
В состоянии Initialize маршрутизатор ожидает начала работы. Если этот маршрутизатор является владельцем VIP адреса (приоритет равен 255), то маршрутизатор отправляет сообщения о том что становится Master. Он также отправляет gratuitous ARP-запрос, в котором MAC-адрес источника равен адресу виртуального маршрутизатора. Затем он переходит в состояние Master. Если маршрутизатор не является владельцем VIP, то он переходит в состояние Backup.
В состоянии Backup маршрутизатор ожидает пакеты от Master. Маршрутизатор в этом состоянии не отвечает на ARP-запросы от VIP-адреса. Также он не принимает пакеты, у которых в качестве адреса назначения стоит MAC-адрес виртуального маршрутизатора.
Если Backup не получает сообщения от Master в течение Master Down Timer, то он отправляет VRRP сообщение о том, что собирается стать Master. Затем отправляет широковещательное VRRP сообщение, в котором MAC-адрес источника равен адресу этого виртуального маршрутизатора. В данном сообщении маршрутизатор указывает свой приоритет.
В состоянии Master маршрутизатор обрабатывает пакеты, адресованные виртуальному маршрутизатору. Он так же отвечает на ARP-запросы к VIP. Master рассылает VRRP сообщения каждые Adver Timer, чтобы подтвердить что он работает.
VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами. Для этого на одном интерфейсе создается две VRRP группы. Одной группе назначается больший приоритет, чем другой. При этом на втором маршрутизаторе приоритет задается противоположным образом. Т.е. если на одном маршрутизаторе приоритет первой группы равно 100, а второй группы — 200, то на другом маршрутизаторе приоритет первой группы будет 200, а второй 100.
Как сказано ранее, в каждой группе должен быть свой уникальный VIP. В итоге, мы получаем два ip адреса, обслуживаемые двумя маршрутизаторами, каждый из которых может служить шлюзом по умолчанию.
Половине компьютеров назначается один адрес шлюза по умолчанию, половине другой. Таким образом половина трафика будет идти через один маршрутизатор, а половина через другой. При выходе из строя одного из маршрутизаторов, второй перехватывает на себя работу обеих VIP.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Протоколы группы FHRP (First Hop Redundancy Protocols)
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Итак начнём с 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 )
Диагностика
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Гостевой пост: опыт использования VRRP
Сегодня мы публикуем необычный пост — его написали наши клиенты.
Компания ITSumma занимается удаленным администрированием серверов и технической поддержкой веб-сайтов, обеспечивает доступность веб-сервисов при высоких и очень высоких нагрузках.
В статье Антон Баранов, Виктория Андриенко и Евгений Потапов делятся практическим опытом использования нашей услуги «Резервирование маршрутизатора (VRRP)». Если вы работаете над обеспечением высокой доступности и отказоустойчивости собственного проекта, вам будет интересно ознакомиться с этим опытом.
Горячее резервирование в Selectel. Достоинства и возможные недостатки, механизмы применения
Немного о резервировании
Относительно недавно Selectel анонсировал возможность использования VRRP (Virtual Router Redundancy Protocol) для своих площадок — эта технология дает очень редкую для российского хостинга возможность практически прозрачного переключения проекта с основной площадки на резервную «на лету». Это решение мы и хотим рассмотреть в деталях.
Когда проект разрастается до требований полноценной доступности 24/7, возникает необходимость в резервном сервере, на который синхронизируются данные, пишется реплика базы данных. В этот момент появляется главный вопрос: как переключать пользователей на этот резервный сервер? При этом необходимо соблюсти согласованность данных на всех уровнях (файлы, БД, настройки ПО) между основным сервером и резервом. Очень важно, чтобы при отказе основного сервера запросы новых посетителей сайта мгновенно переключались на резерв: ведь если по каким-то причинам после переключения запросы посетителей продолжают приходить на недоступный сервер, то мы теряем потенциальных клиентов.
Прежде всего мы рекомендуем, чтобы резервный сервер находился в другом дата-центре (возможно — той же компании), ведь так же часто, как мы видим падения отдельных серверов, мы видим и проблемы на уровне стойки (в периоды мощных DDoS-атак на других клиентов хостинга), проблемы на уровне дата-центра целиком, проблемы на уровне сетевых каналов к дата-центру.
В идеале резервный сервер должен находиться в другом дата-центре другой хостинг-компании и на других сетевых каналах. Однако, даже размещение в нескольких ДЦ одной компании уже может значительно улучшить надёжность проекта. Главное, что мы рекомендуем — не держать резерв в том же физическом дата-центре.
Вне зависимости от того, где будет расположена резервная площадка, возникает вопрос: каким образом пользователи будут переведены на резервный сервер? Смена IP-адреса в DNS зависит от времени кэширования записи, часть пользователей будет долгое время видеть старый IP-адрес. Использование прокси-сервера или облачного балансировщика (например, от Amazon) создает новую возможную точку ошибки, добавляет накладных расходов, а в случае с Amazon’ом, ко всему прочему, могут возникнуть вопросы, связанные с соблюдением закона о персональных данных. Поэтому хочется просто иметь возможность переключить IP- адрес, однако доступных для небольших проектов технологий не так много. Не каждый проект может купить себе подсеть и договориться с дата-центрами о ее анонсе.
VRRP и резервирование в Selectel: устройство и характерные особенности
Изначально протокол VRRP использовался для упрощения ручного труда при авариях в локальной сети.
Пусть в пределах одной локальной сети есть несколько маршрутизаторов и серверов. Если с одним из основных серверов или маршрутизаторов этой сети происходит авария, то нам достаточно просто поднять на сетевом интерфейсе резервного сервера/маршрутизатора IP-адрес основного, и весь трафик внутри сети пойдет на него.
Программное обеспечение, использующее протокол VRRP, обменивается между основным и резервным узлами данными о том, кто выполняет роль «мастера» в рамках резервной группы, и о том, какие узлы — резервные, и какой приоритет у их использования в случае аварии на основном сервере. Каждый из узлов получает от других данные о его роли и весе, и если вдруг узел понимает, что он играет резервную роль, но в сети не осталось узлов с весом выше него (и соответственно — пропал мастер, вес у которого максимальный) — этот узел автоматически поднимает у себя IP-адрес основного узла, берет на себя роль «мастера». В случае, если в сети снова появился узел с более высоким приоритетом — резервный узел, взявший на себя роль «мастера», возвращается в состояние резерва и выключает на интерфейсе IP-адрес основного узла.
Основа системы горячего резервирования с использованием протокола VRRP в Selectel’е — виртуальная локальная сеть между двумя физическими дата-центрами, в Москве и Санкт-Петербурге. Как и в любой локальной сети, IP адрес может быть назначен любому из ее элементов. Соответственно, в указанной виртуальной сети выбираются: основной маршрутизатор и основной сервер в одном из дата-центров, резервный маршрутизатор и резервный сервер в другом дата-центре. Все узлы находятся в пределах одной виртуальной подсети.
Услуга по резервированию не полностью автоматическая: организация резервирования серверов — задача пользователя/администратора (достаточно просто «погасить» IP на основном сервере и «поднять» на резервном), резервирование маршрутизаторов осуществляет сам Selectel, и это отдельная история.
После заказа услуги VRRP Selectel предоставляет подсеть /29, состоящую из 6 ip-адресов. Пусть в нашем примере это будет подсеть 98.76.54.24/29. Назначение IP-адресов в этой подсети распределено следующим образом:
1) IP основного сервера — 98.76.54.28
2) Основной шлюз — 98.76.54.25
3) IP резервного сервера — 98.76.54.29
4) Резервный шлюз — 98.76.54.26
5) Broadcast-IP — 98.76.54.31
6) VRRP IP — 98.76.54.27 (этот IP должен быть по умолчанию поднят на основном сервере 98.76.54.28)
Для резервирования на основном и резервном сервере поднимаются демоны keepalived, которые, обмениваясь между собой информацией или используя скрипт проверки, определяют доступность остальных узлов в схеме резервирования ( фактически резервный сервер пытается понять, доступен или нет основой сервер, и, в случае его недоступности, поднимает VRRP IP на своем интерфейсе).
Подобное резервирование поможет защититься от следующих аварий:
Резервирование на уровне сервера не защитит от следующих проблем:
Для решения такого рода проблем применяется резервирование на уровне маршрутизаторов. Отметим, что эта часть системы резервирования лежит целиком на Selectel’e, то есть контроля над этим процессом у пользователя/администратора нет.
Разберём каждый из из аварийных случаев, и посмотрим, какие действия на стороне маршрутизаторов должны произойти в каждом из них.
Аппаратное падение основного маршрутизатора
Это именно тот случай, в случае которого резервирование на уровне маршрутизаторов организованное Selectel’ом практически гарантировано защитит — резервный маршрутизатор увидит недоступность основного маршрутизатора и возьмет роль основного на себя.
Аппаратное падение основного дата-центра: тоже случай, от которого резервирование на уровне маршрутизаторов защитит, даже по «локальной» оптике резервный маршрутизатор увидит недоступность основного ДЦ и возьмет на себя роль основного.
Полное падение основного дата-центра
Этот случай — самый сложный. В идеале откат в случае аварии на уровне дата-центра происходит следующим образом:
1. Пусть основной дата-центр находится в Москве, резервный — в Санкт-Петербурге.
2. Дата-центр в Москве теряет все свои аплинки, при этом оптика между Санкт-Петербургом и Москвой, по которой связаны ДЦ, остается, виртуальные маршрутизаторы видят доступность друг друга и не переключаются.
3. Идеальный случай: Московский ДЦ перестает анонсировать свои сети, ДЦ в Санкт-Петербурге их анонсирует, трафик по аплинкам идет в Санкт-Петербург затем идет по оптике в Москву на основной маршрутизатор и уже оттуда — на основной сервер.
Прецедентов полного падения одного из дата-центров в Selectel’е мы не видели, поэтому не можем с уверенностью говорить о том, что это резервирование действительно работает и сработает эффективно, — например, при аварии, обусловленной человеческим фактором, когда основной ДЦ перестанет быть виден извне, а его канал до резервного ДЦ останется активным.
Таким образом, VRRP в Selectel’е — это очень полезная технология, которая все же имеет свои особенности, и о них не стоит забывать. Переключение на резервный сервер не всегда означает переключение на резервные каналы.
За пределами сетевого стека важно учесть: любое переключение на резерв всегда связано с двумя возможными проблемами. Первая: резервная площадка по какой-то причине может быть неработоспособна (и проект переключится, например, с плохо работающего сайта на абсолютно неработающий). Вторая: может случиться, что данные и операции, которые были проведены в период работы на резервной площадке, останутся только на ней и не будут синхронизованы с основной площадкой.
Для минимизации этих рисков важно вести мониторинг резервной площадки так же тщательно, как и основной: внимательно следить за репликацией между площадками и быть крайне осторожными с синхронизацией. У вас есть два варианта. С одной стороны, можно организовать резервирование по схеме «мастер-слейв» и в случае аварии превратить резервную площадку в основную, а на основной — «переподнять» резервирование. С другой стороны, можно организовать репликацию по схеме «мастер — мастер». При выборе этого варианта следует учитывать все возможные риски: если данные будут случайны удалены на резервере, то же самое произойдёт и на мастере; переключение на резерв и обратно при нарушении синхронизации приведёт рассинхронизации данных и т.п.
Что следует держать на мониторинге
1. На обeих машинах нужно поднять URL, сообщающий о том, откуда отдаются текущие данные, для примера: http://mysite.com/vrrp.txt возвращаюий msk в случае сервера в Москве и spb в случае сервера в Санкт-Петербурге. При смене значения/недоступности URL — оповещение.
2. Состояние репликации между основным и резервным сервером.
3. Состояние файловой синхронизации между основным и резервным сервером.
4. Доступность URL проекта на резервном сервере.
Бонус-трек: Настройка VRRP в Selectel’e
На стороне linux-серверов VRRP может быть реализован с помощью демона keepalived. Рассмотрим его настройку.
1) IP основного сервера — 98.76.54.28
2) Основной шлюз — 98.76.54.25
3) IP резервного сервера —98.76.54.29
4) Резервный шлюз — 98.76.54.26
5) Broadcast-IP — 98.76.54.31
6) VRRP IP — 98.76.54.27
После этого от нас требуется только три вещи:
1) Сконфигурировать сетевые интерфейсы сервера
Сетевые настройки основного сервера:
Сетевые настройки резервного сервера:
Обратите внимание, что IP интерфейса и шлюз мы указываем для каждого сервера свой.
2) Сконфигурировать keepalived
Для начала установим keepalived. Как правило, он есть в стандартных репозиториях. Пример для CentOS:
Далее нужно его корректно сконфигурировать.
Настройки keepalived на основном сервере:
Настройки keepalived на резервном сервере:
Обратите внимание на следующие моменты:
а) Мы не добавляем keepalived в автозагрузку сервера. Т.к. сервера перезагружаются крайне редко, если это не запланированное обслуживание, а авария, то нам не нужен запущенный keepalived на сервере до того, как мы устраним все причины/последствия аварии, а так же актуализируем данные на этом сервере.
б) Priority у резервного сервера обязательно должен быть меньше, чем у основного.
в) Virtual_router_id должен быть разным у каждой пары серверов с VRRP-ip. Хотя в в документации указано, что он должен быть разным только для разных интерфейсов в рамках одного сервера, на практике мы сталкивались с тем, что когда у разных пар серверов был одинаковый virtual_router_id, возникали проблемы.
3) Прописать соответствующие правила фаерволла для открытия VRRP и мультикаста:
После этого можно запускать keepalived:
Если мы просмотрим логи, то они должный выглядеть примерно так:
На основном сервере
На резервном сервере
Если логи выглядет по-другому, значит что-то где-то настроено неверно. Стоит перепроверить настройки фаерволла и keepalived.
Если же логи примерно совпадают с приведёнными выше примерами, то поздравляем: вы настроили VRRP на своем сервере! Обратите внимание, что проверка доступности серверов может быть реализована с помощью check-скриптов, документацию по работе с которыми вы можете найти по ссылке ниже.
Ссылки для более детального изучения затронутых тем:
Что такое VRRP?
Параметры загрузки
Содержание
Введение
Протокол VRRP (Virtual Router Redundancy Protocol; Протокол резервирования с помощью виртуального маршрутизатора) устраняет единственное слабое место, характерное для стандартных сред со статической маршрутизацией. VRRP задает протокол выбора, который динамически назначает один из концентраторов VPN в LAN ответственным за виртуальный маршрутизатор (кластер концентраторов VPN 3000). Концентратор VRRP VPN, который управляет IP-адресом (адресами), связанным (связанными) с виртуальным маршрутизатором, называется главным устройством; оно переадресовывает пакеты, посылаемые на эти IP-адреса. Когда главное устройство становится недоступным, его место занимает резервный концентратор VPN.
Примечание. Обратитесь к разделу «Конфигурация | Система | IP-маршрутизация | Резервирование» в Руководстве пользователя для концентратора VPN серии 3000 или к тому же разделу интерактивной справочной системы по управлению концентратором VPN 3000 для получения полной информации по протоколу VRRP и способах его настройки.
Предварительные условия
Требования
Для данного документа нет особых требований.
Используемые компоненты
Приводимая в настоящем документе информация относится к концентраторам Cisco VPN серии 3000.
Данные для документа были получены в специально созданных лабораторных условиях. При написании данного документа использовались только устройства с чистой (заданной по умолчанию) конфигурацией. При работе в действующей сети необходимо изучить все возможные последствия каждой команды.
Условные обозначения
Более подробные сведения о применяемых в документе обозначениях см. в статье Условные обозначения, используемые в технической документации Cisco.
Как концентратор VPN 3000 реализует VRRP?
Резервные концентраторы VPN маркируются группой.
Для группы выбирается главное устройство.
Один или несколько концентраторов VPN могут быть резервными для мастера группы.
Главное устройство передает информацию о своем состоянии резервным устройствам.
Если главное устройство не может сообщить свой статус, VRRP пробует использовать резервные устройства в порядке приоритета. Ответившее резервное устройство принимает на себя роль главного устройства.
Примечание. Протокол VRRP обеспечивает резервирование только для туннельных соединений. Поэтому, если происходит перехват управления при отказе VRRP, резервное устройство прослушивает только туннельные протоколы и трафик. Проверка доступности концентратора VPN не работает. Используемые концентраторы VPN должны быть настроены одинаковым образом. Виртуальные адреса, настроенные для VRRP, должны совпадать с настроенными на интерфейсных адресах главного устройства.
Настройка VRRP
Протокол VRRP настраивается на открытых и частных интерфейсах в данной конфигурации. VRRP применяется только к конфигурациям, в которых два или более концентратора VPN функционируют параллельно. У всех этих VPN-концентраторов одинаковые настройки пользователей, групп и межсетевых соединений LAN-LAN. В случае ошибки главного устройства, резервное устройство начинает обслуживать трафик, ранее обработанный главным устройством. Это переключение происходит через 3-10 секунд. В то время как подключения клиентов по протоколам IPSec и PPTP (протокол туннелирования между узлами) во время переключения отсоединены, пользователям следует только восстановить соединение без изменения адреса назначения в их профиле подключения. При соединении двух LAN переключение осуществляется напрямую.
Эта процедура показывает, как выполнить этот образец конфигурации.
На главной и резервной системах:
Выберите Configuration > System > IP Routing > Redundancy. Измените только эти параметры. Оставьте все другие параметры в состоянии по умолчанию:
Введите пароль (максимум 8 символов) в поле Group Password.
Введите IP-адреса в поле общих адресов группы (1 Private) главной и всех резервных систем. В этом примере адрес 10.10.10.1.
Введите IP-адреса в группе общих адресов (2 Public) главной и всех резервных систем. В этом примере адрес 63.67.72.155.
Вернитесь к окнам по всем разделам Configuration > System > IP Routing > Redundancy и установите флажок Enable VRRP.
Примечание. Если вы сначала настроили балансировку нагрузки между двумя VPN-концентраторами, а затем на них настраиваете VRRP, убедитесь в том, что настроен диапазон IP-адресов. Если используется тот же IP-пул, что и раньше, необходимо его изменить. Это необходимо, поскольку трафик от одного IP-пула в сценарии балансировки нагрузки направляется только к одному из VPN-концентраторов.
Синхронизация конфигураций
Эта процедура описывает, как синхронизировать конфигурацию из режима Master (главный) в Slave (подчиненный) путем балансировки нагрузки или перевода из основного режима во вспомогательный, если используется VRRP.
В режиме Master (главный) или Primary (основной) выберите Administration > File Management и в строке CONFIG выберите View.
Когда откроется окно браузера с конфигурацией, выделите и скопируйте конфигурацию (ctrl-a, ctrl-c).
Вставьте конфигурацию в Wordpad.
Выберите пункт меню Edit > Replace и введите открытый интерфейсный IP-адрес устройства Master (главный) или Primary (основной) в поле Find What. В поле Replace With, укажите IP-адрес, который необходимо назначить для Slave (подчиненный) или Backup (резервная копия).
Сделайте то же самое для частного IP-интерфейса и для внешнего интерфейса, если он уже настроен.
Сохраните файл и выберите ему имя. Убедитесь, что вы сохранили его как «текстовый документ» (например, synconfig.txt).
Перейдите в раздел Slave (подчиненный) или Secondary (дополнительный) и выберите Administration > File Management > File Upload.
Введите config.bak в File в поле VPN 3000 Concentrator и перейдите к сохраненному файлу на компьютере (synconfig.txt). Затем нажмите кнопку Upload.
Концентратор VPN загрузит его и автоматически изменит synconfig.txt на config.bak.
Выберите пункт меню Administration > File Management > Swap Configuration Files и нажмите OK для перезагрузки концентратора VPN c загруженным файлом конфигурации.
После возврата в окно System Reboot оставьте установки по умолчанию и нажмите Apply.
После того как вы это сделаете, будет загружена та же конфигурация, что и в режиме Master (главный) или Primary (основной), за исключением ранее измененных адресов.
Примечание. Не забудьте изменить параметры в окне Load Balancing или Redundancy (VRRP) (балансировка нагрузки или резервирование). Выберите Configuration > System > IP Routing > Redundancy.
Примечание. В качестве другого варианта можно выбрать Configuration > System > Load Balancing.