Погодин Евгений — ИТ Заметки
🔌Сеть Обновлено 10.11.2026

Сети с нуля 18. Отказоустойчивость: резервный шлюз (VRRP), LACP и NIC Teaming

Note

Материал сверен с официальной документацией (RFC, реестры IANA, Microsoft Learn и др.; ссылки — в конце статьи). Примеры вывода — иллюстрации: на вашей системе значения и формат могут отличаться. Перед работой на боевом оборудовании проверьте шаги на тестовом стенде.

Вечером у RTR1 вышел из строя блок питания, и весь офис остался без интернета: и компьютеры, и принтер, и доступ в филиал (RTR3, статья 17). В другой раз из сервера SRV1 выпал один сетевой кабель, и сервер пропал из сети, хотя сам работает. Общее в обеих историях: на пути стоял узел без запасного. Такой узел называют единой точкой отказа (single point of failure, SPOF).

Представьте здание с одной входной дверью: заклинила, и никто не войдёт. Запасная дверь помогает, только если снаружи всё выглядит как прежде. Так же устроено резервирование в сети. В этой статье вы узнаете:

  • где в офисной сети прячутся единые точки отказа;
  • как работает резервный шлюз по умолчанию (VRRP) и чем он похож на HSRP;
  • как несколько кабелей объединяют в один логический канал (LACP, NIC Teaming в Windows Server) и почему «2 × 1 Гбит/с» не означает «2 Гбит/с» для одной передачи;
  • как безопасно проверить отказ.

Что нужно знать заранее

Сеть в примерах — сквозная. Для этой статьи в неё добавлен второй роутер офиса RTR2: адрес 192.168.10.3 (он лежит в диапазоне исключений DHCP), MAC 00-00-5E-00-53-FD. На SRV1 добавлена вторая сетевая карта.

Где у сети единые точки отказа

Что откажет Чем резервируют Технология
Роутер-шлюз второй роутер с общим адресом VRRP (аналог: HSRP)
Кабель, порт коммутатора, сетевая карта сервера несколько линков в одной группе LACP, NIC Teaming
Канал до филиала или провайдера второй канал и выбор пути динамическая маршрутизация (статья 17), второй провайдер
Коммутатор второй коммутатор и защита от петель STP (Spanning Tree Protocol), объединение каналов между коммутаторами

Резервирование добавляет сложность, а неверная настройка резерва иногда ломает сеть хуже, чем его отсутствие. Поэтому резерв проверяют заранее и по плану (последний раздел).

Резервный шлюз: VRRP

Проблема

Компьютеры знают один адрес шлюза (192.168.10.1, статья 05), чаще всего получают его по DHCP. Если RTR1 отказал, PC1 по-прежнему шлёт кадры на его MAC-адрес, и они уходят в пустоту. Перенастраивать все компьютеры на второй адрес долго, а пользователи уже без связи. Поэтому два роутера «договариваются» и изображают один общий шлюз.

Как это работает

VRRP (Virtual Router Redundancy Protocol, протокол резервирования виртуального маршрутизатора) — открытый стандарт IETF. Актуальная версия, VRRPv3 для IPv4 и IPv6, описана в RFC 9568 (2024); она заменила RFC 5798. Основные понятия:

  • Виртуальный роутер. Роутеры в одном сегменте образуют виртуальный роутер с номером VRID (Virtual Router Identifier, от 1 до 255) и одним или несколькими виртуальными адресами. В нашем примере VRID равен 1, адрес — 192.168.10.1.
  • Active и Backup. Один роутер ведёт виртуальный адрес: отвечает на ARP за него и пересылает пакеты. В RFC 9568 он называется Active; в RFC 5798 и в старой документации — Master. Остальные — Backup.
  • Виртуальный MAC. Для IPv4 это 00-00-5E-00-01-{VRID}, для VRID 1 — 00-00-5E-00-01-01. Это не адрес устройства, а значение, которое протокол выводит из номера VRID. Active отвечает на ARP именно этим MAC, и компьютеры видят один и тот же адрес, какой бы роутер ни был активным: ARP-кэш не нужно «переучивать».
  • Приоритет. Число от 1 до 254 (по умолчанию в RFC — 100) у резервных роутеров; 255 получает роутер, которому адрес принадлежит как реальный; 0 в объявлении означает «я прекращаю работу». Чем выше число, тем главнее роутер.
  • Объявления. Active рассылает короткие сообщения (по умолчанию в RFC — раз в секунду). Адрес получателя — multicast (многоадресная рассылка, статья 03) 224.0.0.18 для IPv4 и ff02::12 для IPv6, номер IP-протокола — 112, TTL (hop limit) равен 255, принимающий отбрасывает пакеты с другим значением. Backup сообщений не посылает, только слушает.
  • Переключение. Если Backup не слышит объявлений в течение трёх интервалов плюс небольшая поправка (зависит от приоритета), он считает Active отказавшим и становится им сам. По формуле RFC при интервале 1 секунда и приоритете 100 это около 3,6 секунды; интервал можно сделать и короче секунды. Новый Active рассылает gratuitous ARP с виртуальным MAC (обновляет ARP-кэши), а кадры его объявлений идут с виртуальным MAC в адресе источника, так коммутаторы узнают новый порт.
  • Возврат. Роутер-владелец адреса (приоритет 255) при возвращении забирает роль всегда. Остальные роутеры с более высоким приоритетом забирают её, если включён параметр Preempt (по умолчанию в RFC он включён). Это ещё одно короткое переключение.
        Интернет (у каждого роутера свой канал)
                    |
        +-----------+-----------+
        |                       |
  RTR1 (Active)           RTR2 (Backup)
  192.168.10.1            192.168.10.3
  физ. MAC ...53-FE       физ. MAC ...53-FD
        |                       |
        +---------- SW1 --------+
                    |
        PC1, PC2, SRV1, PRN1
  шлюз у всех — 192.168.10.1, MAC шлюза в ARP — 00-00-5E-00-01-01

В таком варианте RTR1 владеет адресом 192.168.10.1 (приоритет 255) и после возвращения забирает роль независимо от параметра Preempt; RTR2 его только подменяет (приоритет, например, 100). Удобство в том, что шлюз на компьютерах менять не нужно. Не все устройства так умеют: тогда берут отдельный виртуальный адрес (например, 192.168.10.2) и прописывают его как шлюз в области DHCP (статья 06). Соответствие между VRID и виртуальными адресами нужно согласовать между всеми роутерами сегмента. Одинаковым стоит оставить и интервал объявлений: если у Active с более высоким приоритетом он медленнее, чем у резервных, роль неустойчива.

Что видно администратору

На компьютере в Windows виден виртуальный MAC шлюза (в статье 05 у шлюза был физический MAC, здесь он другой):

arp -a

Пример вывода:

Interface: 192.168.10.101 --- 0xc
  Internet Address      Physical Address      Type
  192.168.10.1          00-00-5e-00-01-01     dynamic

Роли роутеров смотрят на самих роутерах (для Cisco — Cisco с нуля 13: HSRP, резервирование шлюза по умолчанию). В захвате трафика (статья 11; только в своей сети) ищите пакеты с IP-протоколом 112 на адрес 224.0.0.18: если они прекратились или идут от двух роутеров сразу, что-то неладно.

HSRP

HSRP (Hot Standby Router Protocol) создан Cisco и решает ту же задачу (RFC 9568 называет VRRP функцией, похожей на HSRP). В версии, описанной RFC 2281, он работает поверх UDP (порт 1985) и рассылает сообщения на 224.0.0.2; этот RFC информационный и не определяет стандарт Интернета.

Ограничения и защита

  • Резервируется только шлюз. VRRP следит за обменом сообщениями между роутерами. Если у Active оборвётся канал к провайдеру, а сам роутер жив, он останется Active, и офис потеряет интернет. В тексте RFC 9568 механизма слежения за внешним каналом нет; у производителей он бывает под другими названиями (отслеживание интерфейса или адреса): смотрите документацию.
  • Службы на роутере и собственный канал. VRRP не резервирует службы, которые стоят на самом роутере. В нашей сети DHCP-сервер — RTR1 (статья 06), поэтому при его отказе новым компьютерам адрес не выдастся, а аренды не продлятся, пока DHCP не настроен отдельно (Windows Server с нуля 07: DHCP-сервер и отказоустойчивость или второй DHCP-сервер на RTR2). У RTR2 должен быть свой канал к провайдеру: при переключении внешний адрес меняется, и установленные соединения, как правило, обрываются.
  • Аутентификации в VRRPv3 нет. Прежние способы не дали достаточной защиты, а злоумышленник в той же сети и так может многое другими средствами. От объявлений из других сетей защищает TTL 255. Внутри сегмента для сетей с недоверенными узлами можно фильтровать на портах пользователей служебные сообщения, в том числе VRRP, если коммутатор это умеет (общие приёмы защиты портов доступа — в Cisco с нуля 10: базовая защита коммутатора). Пользователей и серверы стоит разделить по VLAN (статья 13, Безопасность для начинающих 05).
  • Два Active одновременно. Если объявления не доходят между роутерами (заблокирован multicast, разные VLAN), оба считают себя активными, и у пользователей то есть связь, то нет.

Агрегация каналов: LACP

Зачем это нужно

Один кабель от SRV1 к SW1 — единая точка отказа и потолок скорости. Если проложить два кабеля и объединить их в группу, сервер переживёт обрыв одного из них, а пропускная способность вырастет. С точки зрения IP это один интерфейс с одним адресом.

         SRV1 (192.168.10.10), группа Team1
        Ethernet 1 |    | Ethernet 2
                   |    |
              +----+----+----+
              |      SW1      |   два порта в одной группе
              +---------------+

Стандарт, который описывает такую агрегацию, — IEEE 802.1AX (ранее IEEE 802.3ad). LACP (Link Aggregation Control Protocol) — протокол, которым две стороны договариваются о составе группы. Текст стандарта мы не использовали (условия доступа — на сайте IEEE, как и для 802.3 в статье 02): ниже только то, что подтверждают документация Microsoft, IANA и RFC. Сообщения LACP идут Ethernet-кадрами с EtherType 0x8809: реестр IANA относит его к «медленным протоколам» (Slow Protocols), в том числе агрегации каналов.

Два способа собрать группу

  • Статический. Настройка нужна и на коммутаторе, и на хосте: так определяют, какие линки входят в группу.
  • LACP. Стороны динамически определяют, какие линки соединяют хост и данный коммутатор.

Практика автора: LACP предпочитают статике, потому что ошибку в статической группе заметить труднее.

В Windows режим «активный/пассивный» не выбирают: у командлета New-NetLbfoTeam нет такого параметра, есть лишь -LacpTimer (Slow или Fast), который задаёт, как часто стороны обмениваются LACP-сообщениями. Режимы на стороне коммутатора смотрите в его документации и в Cisco с нуля 09: STP и EtherChannel.

Почему «2 × 1 Гбит/с» не равно 2 Гбит/с

Кадры не раскладываются по кабелям по очереди: если пакеты одного потока пойдут разными путями, они могут прийти не по порядку, и TCP решит, что часть пакетов потеряна (RFC 2991). Поэтому устройство считает хеш от полей пакета (MAC-адресов, IP-адресов, портов; набор зависит от устройства и настроек) и по нему выбирает линк. Для LAG и ECMP это описывает RFC 7424: такой подход сохраняет порядок пакетов в потоке, но может давать неравномерную нагрузку на линки. Что из этого следует:

  • Одно копирование файла по одному соединению, как правило, не выйдет за скорость одного линка (1 Гбит/с в нашем примере). Выигрыш виден, когда потоков много: разные клиенты, разные соединения.
  • Равномерность не гарантирована: два потока могут попасть на один линк. Алгоритм Dynamic в Windows при необходимости переносит исходящие потоки между адаптерами.
  • Для файлового трафика SMB в Windows есть отдельная возможность SMB Multichannel: SMB сам использует несколько адаптеров без группировки.

NIC Teaming в Windows Server

NIC Teaming, он же LBFO (load balancing and failover), объединяет сетевые адаптеры сервера в группу ради двух целей: суммарной полосы и сохранения связи при отказе. Группа получает собственный интерфейс (в документации — team interface; его имя задаёт параметр -TeamNicName), и IP-адрес, как правило, настраивают на нём. Адаптеры разной скорости в одной группе не поддерживаются: система такую группу создаст, но алгоритмы скорость адаптеров не учитывают.

Режимы

Режим (-TeamingMode) Что нужно на коммутаторе Разные коммутаторы
SwitchIndependent ничего можно подключить к разным
Static настроить группу вручную как правило, нужен один коммутатор
Lacp настроить LACP на портах как правило, нужен один коммутатор

«Как правило, один коммутатор» — из рекомендаций Microsoft для кластера Hyper-V; там же сказано, что в большинстве случаев отказ коммутатора переживает только switch-independent. Практика автора: начните с SwitchIndependent, а Lacp включайте, когда нужна полоса и порты уже настроены.

Алгоритмы распределения

Алгоритм (-LoadBalancingAlgorithm) По чему считается распределение
Dynamic адреса и порты TCP; исходящие потоки при необходимости переносятся между адаптерами
TransportPorts адреса и порты TCP
IPAddresses IP-адреса
MacAddresses MAC-адреса
HyperVPort порт виртуального коммутатора Hyper-V, то есть виртуальная машина (про коммутатор поверх LBFO см. врезку «Состояние на ноябрь 2026 года» ниже)

Ограничение режима SwitchIndependent: коммутатор о группе не знает, поэтому группа сама входящий трафик по адаптерам не раскладывает. По документации, при Dynamic он направляется на определённый адаптер группы, при TransportPorts, IPAddresses и MacAddresses весь входящий трафик приходит на основной (primary) адаптер, а при HyperVPort — на тот же адаптер, что и исходящий трафик этого порта.

Hyper-V и SET

Если на сервере работает Hyper-V, виртуальные машины подключаются к виртуальному коммутатору, и у него своя разновидность группировки — SET (Switch Embedded Teaming). SET есть в Windows Server с версии 2016; её включают параметром -EnableEmbeddedTeaming командлета New-VMSwitch. По документации Azure Local, она работает только в режиме switch-independent (алгоритмы Dynamic или HyperVPort) и требует одинаковых адаптеров. В отличие от NIC Teaming, SET допускает группировку адаптеров с RDMA (Remote Direct Memory Access, аппаратной разгрузкой SMB).

Как посмотреть и создать группу

Состояние адаптеров и скорость показывает Get-NetAdapter:

Get-NetAdapter |
    Format-Table Name, InterfaceDescription, Status, LinkSpeed

Пример вывода:

Name        InterfaceDescription    Status LinkSpeed
----        --------------------    ------ ---------
Ethernet 1  Network Adapter #1      Up     1 Gbps
Ethernet 2  Network Adapter #2      Up     1 Gbps

Warning

Создание и удаление группы на время обрывает связь через её адаптеры. Делайте это на тестовом сервере или в окно работ, с консоли (не по RDP через один из этих адаптеров). Перед созданием сохраните вывод ipconfig /all: после создания адрес, как правило, настраивают на интерфейсе группы, а после удаления группы его нужно вернуть на физический адаптер.

Команда создания (параметры и значения — по документации New-NetLbfoTeam):

New-NetLbfoTeam -Name "Team1" `
    -TeamMembers "Ethernet 1","Ethernet 2" `
    -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

Состояние группы и её участников:

Get-NetLbfoTeam
Get-NetLbfoTeamMember

Откат: Remove-NetLbfoTeam -Name "Team1", затем верните адрес на физический адаптер по сохранённым настройкам.

Избыточные пути между коммутаторами

Два кабеля между коммутаторами без защиты дают петлю (статья 02): от неё защищает STP, он блокирует лишние связи. Несколько кабелей можно и объединить в одну логическую связь (EtherChannel); настройка обоих способов — в Cisco с нуля 09.

Резерв Интернета: два провайдера

Идея та же: два канала, основной и запасной. Простейший вариант — два маршрута по умолчанию с разными метриками (статья 05): действует тот, у которого метрика меньше. Но статический маршрут не знает, доходят ли пакеты до интернета, поэтому на роутере настраивают ещё и проверку доступности (например, пинг внешнего адреса). Примеры на оборудовании: MikroTik с нуля 12: два провайдера и Cisco два провайдера. Другие приёмы:

  • ECMP (Equal-Cost Multi-Path): несколько равноценных маршрутов, потоки, как правило, распределяются между ними по принципу «один поток — один путь» (RFC 2991);
  • PBR (Policy-Based Routing, политики маршрутизации): выбор канала по условию, например по источнику (Cisco с нуля 16: prefix-list, route-map, редистрибуция и PBR);
  • динамические протоколы и BGP (статья 17).

У каждого провайдера свой внешний адрес, который подставляет NAT (статья 08), поэтому соединения через отказавшего провайдера, как правило, обрываются и открываются заново.

Быстрее обнаружить отказ: BFD

BFD (Bidirectional Forwarding Detection, RFC 5880) — отдельный протокол быстрого обнаружения отказов между соседними устройствами; «hello»-сообщения протоколов маршрутизации, по тому же RFC, обнаруживают отказ не быстрее секунды. Поддержку BFD смотрите в документации оборудования. Для малого офиса он обычно лишний (практика автора).

Практика: безопасная проверка отказа

Резерв, который не проверяли, считайте не работающим. Порядок (практика автора):

  1. Окно работ. Предупредите пользователей: связь может пропасть.
  2. Копии настроек. Сохраните конфигурации роутеров и коммутаторов (Cisco backup конфигурации, MikroTik с нуля 10: автоматический бэкап и обновление по расписанию).
  3. Второй способ доступа. Консоль или физический доступ к оборудованию. Не отключайте тот интерфейс, через который работаете: документация Disable-NetAdapter предупреждает, что нельзя отключать адаптер, которым вы управляете удалённым компьютером.
  4. Исходное состояние. Запишите, кто Active, что показывают arp -a для шлюза, Get-NetLbfoTeam и ipconfig /all. Запустите на PC1 ping -t до внешнего адреса и до SRV1. Вместо 198.51.100.10 из примеров (это адрес из документации) возьмите реальный адрес, который вы вправе проверять, например адрес DNS-сервера провайдера.
  5. Мягкий отказ. Сначала административно выключите порт или интерфейс роутера, а не дёргайте кабель. Для адаптера сервера: Disable-NetAdapter -Name "Ethernet 1" (по умолчанию запросит подтверждение). Смотрите, сколько запросов ping -t потерялось и сколько секунд длился перерыв.
  6. Откат. Включите обратно (Enable-NetAdapter -Name "Ethernet 1", возврат порта) и дождитесь, пока всё вернётся. Вернувшийся RTR1 (владелец адреса) заберёт роль обратно, и будет ещё одно короткое переключение, поэтому возврат тоже проводят в окне.
  7. Жёсткий отказ. Только если мягкий прошёл без сюрпризов: выдерните кабель или обесточьте роутер, затем замер и откат.
  8. Запись. Зафиксируйте время простоя и сравните с ожидаемым (для VRRP — несколько секунд).

Состояние на ноябрь 2026 года (проверьте актуальность). По странице Microsoft Learn «Features Removed or No Longer Developed in Windows Server» в Windows Server 2022 виртуальный коммутатор Hyper-V нельзя привязать к LBFO-группе, нужна SET; вне Hyper-V LBFO остаётся полностью поддерживаемым. В Azure Local поддерживается только SET. Страница «Network recommendations for a Hyper-V cluster» (дата на странице — октябрь 2025 года) всё ещё содержит пример с виртуальным коммутатором поверх LBFO-группы: ориентируйтесь на документацию своего выпуска. Предел в восемь адаптеров SET указан на странице Azure Local; для Windows Server не подтверждён.

Типичные ошибки и недоразумения

  • Разные параметры на двух роутерах. Не совпали VRID или виртуальный адрес: роутеры не договорились, и каждый может решить, что он единственный Active.
  • После переключения шлюз перестал пинговаться, а интернет работает. По умолчанию Active, который не является владельцем адреса, не принимает пакеты, адресованные самому виртуальному адресу (параметр Accept_Mode в RFC выключен по умолчанию). Это не обязательно сбой.
  • Одинаковые приоритеты. Рекомендация RFC 9568: разные приоритеты с заметной разницей.
  • LACP настроен только с одной стороны или на другой стороне стоит статическая группа: такая группа, как правило, не собирается.

Проверьте себя

  1. Зачем в VRRP виртуальный MAC-адрес? Чтобы компьютеры видели у шлюза один и тот же MAC: ARP-кэш не меняется при переключении, перенастраивать ничего не нужно.
  2. Что означают приоритеты 255 и 0 в VRRP? 255 — роутер, которому адрес принадлежит как реальный (всегда Active); 0 в объявлении — Active прекращает работу и просит резерв подхватить роль.
  3. Почему два линка по 1 Гбит/с в группе не ускоряют одно копирование файла? Распределение идёт по хешу, и один поток, как правило, идёт по одному линку; выигрыш есть при многих потоках.
  4. Какие три режима у NIC Teaming и в каком не нужно настраивать коммутатор? SwitchIndependent, Static и Lacp; настройки коммутатора не нужны в SwitchIndependent.
  5. Почему проверку отказа начинают с окна работ, копий конфигурации и доступа по консоли? Неудачная проверка может оборвать связь, в том числе с самим администратором; копии и консоль позволяют вернуть исходное состояние.

Что дальше

Источники

Ещё по теме «Сеть»