Настройка резервирования на основе CARP
Резервирование IP-адреса шлюза посредством протокола CARP
В рамках резервирования IP-адреса шлюза посредством протокола CARP проверяется отказоустойчивость шлюза на уровне IP-адреса.
Для резервирования шлюза используется два физических подключения, которые подключены в разные юниты RTT-M300, которые соединяют два сегмента сети LAN и WAN. CARP позволяет произвести резервирование шлюза на уровне IP-адреса, распределяя роли юнитов ведущий и ведомый. Ведущий будет шлюзом для каждого сегмента до момента аварии или повреждения линка. Если ведущий юнит откажет, тогда роль ведущего примет ведомый и будет выступать в качестве шлюза.
В первую очередь необходимо настроить адресацию интерфейсов каждого юнита в соответствии со схемой. Шлюз для каждого сегмента настраивается через виртуальные интерфейсы. Конфигурация виртуальных интерфейсов ведущего юнита (Unit 1) представлена на рисунках.
Конфигурация первого виртуального интерфейса ведущего юнита (Unit 1)
Конфигурация второго виртуального интерфейса ведущего юнита (Unit 1)
Далее необходимо аналогично настроить ведомый юнит.
Конфигурация первого виртуального интерфейса ведомого юнита (Unit 2)
Конфигурация второго виртуального интерфейса ведомого юнита (Unit 2)
Описание параметров:
Режим: CARP – режим резервирования шлюза на уровне IP-адреса;
Интерфейс – интерфейс, который участвует в резервировании шлюза;
Адрес – виртуальный адрес шлюза, который используется конечными хостами в соответствующем сегменте сети;
Пароль виртуального IP-адреса – аутентификация юнитов в группе, использующих один общий виртуальный адрес;
Группа VHID – группирование для изоляции разных виртуальных IP-шлюзов;
Частота синхронизации – периодичность синхронизации юнитов в группе;
Сдвиг времени(приоритет) – чем больше значение, тем ниже вероятность, что юнит станет ведущим;
Dead timer – таймер, который используется для определения доступности соседнего юнита;
Приоритетный флаг – параметр, который позволяет зафиксировать роль ведущего юнита(параметр не фиксирует состояние юнита, как ведущий);
Описание – общее описание.
После конфигурирования виртуальных интерфейсов каждого юнита, необходимо проверить статус виртуальных соединений
Произведем проверку доступности шлюза с хостов из сегмента LAN и WAN:
Pinging 10.0.0.3 with 18 bytes of data:
18 bytes from 10.0.0.3: icmp_seq=1. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=2. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=3. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=4. time=0 ms
----10.0.0.3 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
console#ping 20.0.0.3
Pinging 20.0.0.3 with 18 bytes of data:
18 bytes from 20.0.0.3: icmp_seq=1. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=2. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=3. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=4. time=0 ms
----20.0.0.3 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
Далее для проверки отказоустойчивости выключим основной юнит, через который проходит трафик и проверим доступность шлюза.
console#ping 10.0.0.3
Pinging 10.0.0.3 with 18 bytes of data:
18 bytes from 10.0.0.3: icmp_seq=1. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=2. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=3. time=0 ms
18 bytes from 10.0.0.3: icmp_seq=4. time=0 ms
----10.0.0.3 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
console#ping 20.0.0.3
Pinging 20.0.0.3 with 18 bytes of data:
18 bytes from 20.0.0.3: icmp_seq=1. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=2. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=3. time=0 ms
18 bytes from 20.0.0.3: icmp_seq=4. time=0 ms
----20.0.0.3 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
Резервирование шлюза на уровне IP-адреса корректно работает. При отключении основного юнита, который выполняет маршрутизацию трафика, второй юнит автоматически берет на себя роль основного и выполняет пересылку трафика.
Для каждого сегмента резервируется ближайший шлюз, т.е., например, если пускать трафик из сегмента LAN в WAN, при неисправности одного из линков интерфейса LAN 1, трафик стабильно пройдет используя альтернативный интерфейс (виртуальный адрес шлюза). Но если выйдет из строя удаленный интерфейс WAN 2, в данном случае резервирование линка для трафика из сегментов LAN в WAN не произойдет.
Подробное описание реализации CARP
После конфигурирования и запуска виртуального интерфейса, система подключается к IGMP группе и начинает отправлять анонсы протокола VRRP (CARP для взаимодействия с соседней стороной использует VRRP) на мультикастный адрес 224.0.0.18.
Анонсы отправляет только ведущий юнит тем самым показывает, что доступен и необходимо использовать его физический интерфейс. Как только происходит авария на данном линке или юните, вещать начинает резервный юнит, тем самым становясь ведущим.
Факторы, влияющие на синхронизацию юнитов:
Виртуальный IP-адрес – адрес должен быть одинаковым на каждом юните;
Пароль виртуального IP-адреса – пароль должен быть одинаковым на каждом юните.
Состав пакета приведен на рисунке
Описание основных полей приведено в таблице
Параметр |
Примечание |
|---|---|
Virtual Rtr ID |
Группа VHID |
Priority |
Частота синхронизации со сдвигом во времени(приоритет) |
Adver int |
Частота синхронизации базовая |
<virtualip>
<vip>
<type>single</type>
<subnet_bits>32</subnet_bits>
<mode>carp</mode> # Режим
<interface>lan1</interface> # Интерфейс
<subnet>10.0.0.3</subnet> # Виртуальный IP - адрес
<vhid>1</vhid> # Группа VHID
<advskew>40</advskew> # Частота синхронизации cо сдвигом времени, а должен быть приоритет.
<advbase>3</advbase> # Частота синхронизации
<deadtime>1</deadtime> # Dead timer
<password>Rusteletech</password> # Пароль виртуального IP-адреса
<pflag>1</pflag> # Приоритетный флаг
</vip>
</virtualip>