У одного молодого развивающегося провайдера на заре становления организации доступа для физ. лиц была принята следующая архитектура для сети:

• IPoE
• привязка порт-ip
• выдача адресов по DHCP (опция 82)
• маршрутизирующий сервер на Linux (CentOS)

По мере роста абонентской базы все проблемы из первых трех пунктов решались успешно. А с последним прогнозировались небольшие проблемы:

• Время даун-тайма при перезагрузке сервера (установка обновлений или сбой) составляло примерно 15 минут. На сервере терминировались vlan в количестве порядка сотни, и поднятие каждого интерфейса для vlan-а занимало около 5-7 секунд, что в сумме давало внушительное время полной загрузки сервера. В это время сервер хоть и пинговался, но ssh отсутствовал, что заставляло немного понервничать.
• Повышение нагрузки на сервер можно было решить наращиванием мощности железа, однако не проводить же бесконечный апгрейд железа.
• И самая главная проблема. Отсутствие резервирования. Время перезагрузок приходилось планировать на позднюю ночь или утро, ради снижения количества звонков в тех.поддержку и уменьшения количества абонентов заметивших отсутствие связи. Я уже молчу про то, что сбой произошедший вечером в час пик добавлял клок седых волос на голове.

Если бы технология была PPPoE или PPTP/L2TP все бы решилось простым добавлением сервера (PPPoE) и прописывание round-robin DNS записи для PPTP/L2TP сервера (немного не силен в данной теме, может что и напутал).

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

Вкратце о VRRP:
Создается виртуальный интерфейс на каждом сервере. Один из серверов становится MASTER, другой — BACKUP, причем весь траффик идет через MASTER-сервер. MASTER-сервер отвечает на arp-запросы, BACKUP-сервер молчит. Два сервера обмениваются специальными пакетами, определяющими кто из них является MASTER и его доступность, чтобы BACKUP-сервер в случае недоступности MASTER-сервера сам перешел в состояние MASTER.

На страничке про VRRP указан способ балансировки нагрузки, когда поднимаются два виртуальных интерфейса, а по DHCP отдаются разные адреса шлюзов.
Я решил использовать другой способ. Т.к. на этих же серверах должны терминироваться vlan-ы, то для каждого из vlan-ов будет один вируальный интерфейс, только для нечетного номера vlan MASTER-ом будет сервер №1, а сервер №2 будет BACKUP. Для четных номеров vlan всё будет с точностью до наоборот — сервер №1 будет BACKUP, а №2 — MASTER. Т.к. интерфейсов достаточно много, то маршрутизируемый траффик будет делиться примерно поровну.

Итак, готовое решение:
Интерфейсы сервера №1 (номер vlan, ip-адрес интерфейса, статус в VRRP):
1 10.0.1.2 MASTER
2 10.0.2.2 BACKUP
3 10.0.3.2 MASTER
...
254 10.0.254.2 BACKUP
255 10.0.255.2 MASTER

Сервер №2 (номер vlan, ip-адрес интерфейса, статус в VRRP):
1 10.0.1.3 BACKUP
2 10.0.2.3 MASTER
3 10.0.3.3 BACKUP
...
254 10.0.254.3 MASTER
255 10.0.255.3 BACKUP

Виртуальные же интерфесы будут иметь адреса (номер vlan, ip-адрес):
1 10.0.1.1
2 10.0.2.1
3 10.0.3.1
...
254 10.0.254.1
255 10.0.255.1

Как настраивать физические интерфейсы описывать не буду — материала по этой теме полно.
Для автоматической загрузки vrrp при запуске системы в /etc/init.d/ создаем стартовый скрипт (можно написать свой или воспользоваться готовыми шаблонами в интернете, благо легко находятся). Суть в том, чтобы запустить по одному процессу для каждого интерфейса. На bash наваял простенький скриптик который генерит что-то подобное для сервера №1:
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 255
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 100
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 255
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 100
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 255

И для сервера №2:
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 100
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 255
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 100
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 255
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 100

В этих примерах:
/bin/vrrpd — путь для исполняемого файла
-i eth1.1 — физический интерфейс, на котором будет поднят виртуальный
-v 1 — id группы vrrp (групп может быть не больше 255)
10.0.1.1 — ip-адрес виртуального интерфейса
-p 255 — приоритет сервера, чем больше, тем приоритетнее. По-умолчанию принято, что приоритет 255 у сервера который является MASTER-ом.
После того как запустится vrrp у виртуального интерфейса MAC-адрес будет 00:00:5E:00:01:xx, где xx — id группы VRRP. Также маршрутизаторы начнут обмениваться пакетами объявляющими свое состояние. Эти пакеты мультикастовые, надо следить чтобы в коммутаторах через которые соединены эти два сервера не фильтровались мультикасты на адрес 224.0.0.18.

И теперь сконфигурируем iptables для того, чтобы сам сервер не фильтровал нужные пакеты. Добавим следующие строки в файл /etc/sysconfig/iptables:
:allow_vrrp - [0:0] # Создадим отдельную цепочку для протокола vrrp
-A RH-Firewall-1-INPUT -p 112 -j allow_vrrp # Перенаправляем пакеты с номером протокола 112 (номер протокола vrrp) в созданную цепочку
-A allow_vrrp -s 10.0.1.0/30 -j ACCEPT # разрешаем прохождение пакетов только для подсети серверов
-A allow_vrrp -s 10.0.2.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.3.0/30 -j ACCEPT
...
-A allow_vrrp -s 10.0.254.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.255.0/30 -j ACCEPT
-A allow_vrrp -j LOG --log-level notice # логгируем всё лишнее
-A allow_vrrp -j DROP # и отбрасываем

Всё.

Результат:

• Переключение на резервный сервер происходит менее чем за одну секунду, более точно не мерил. Для абонента всё происходит прозрачно, единственно только обрываются текущие сессии и (для абонентов за NAT-ом с серыми ip) — меняется ip которым они натятся.
• Перезагрузку серверов можно производить спокойно в рабочее время, зная, что все пользователи будут автоматически переведены на резерв. При сбое тоже нет особой паники.
• Банально, но — два сервера производительнее одного, а при особом желании их количество можно спокойно увеличить.

Особо дотошные абоненты заметили только странность при трассировке удаленных хостов. Странность выглядит примерно так:
tracert ya.ru
0 10.0.34.35 # ip абонента
1 10.0.34.3 # ip заканчивается на .3, хотя шлюз в системе стоит оканчивающийся на .1

P.S. Вообще-то при внедреннии в продакшн этой пары серверов мною были освоены и другие технологии, с которыми я раньше не имел дела (LACP, OSPF), но больше всего было интересно разбираться именно с VRRP.

Источник: http://habrahabr.ru/blogs/linux/128770/