VRRP (Virtual Router Redundancy Protocol) позволяет настроить резервирование шлюза по умолчанию. Выбирается один виртуальный IP и MAC-адрес. IP устанавливается на конечном устройстве. Виртуальный MAC же необходим для нормального заполнения коммутационной таблицы на свитчах и ARP-таблицы на конечных устройствах. Если Master станет недоступным, то ARP-таблица не изменится
Отличительные особенности:
Сообщения рассылаются на Multicast-группу 224.0.0.18 и содержат виртуальный IP (для согласования), аутентификацию виртуальный MAC, ID группы (На одном линке может быть настроено несколько VRRP-шлюзов).
00:00:5E:00:01:{Group-ID} - Так выглядит виртуальный MAC-адрес.
Для каждой группы есть Master и Backup роутеры.
Процесс выбора Master-роутера:
Наибольший приоритет (1-254).
Наибольший IP-адрес интерфейса.
Особенности выбора Master-роутера
Если Virtual IP = IP-адресу интерфейса, то роутер с этим интерфейсом получает приоритет 255 и всегда будет Master-роутером для группы.
Есть Preemption (То-есть роутер с большим приоритетом при появлении в сети перехватывает роль Master-роутера).
1.2. Настройка
Тут всё довольно просто. Сначала настроим IP-адресацию, статические маршруты и какой-нибудь адрес на LoopBack-интерфейсе Internet'а (пусть будет 8.8.8.8). Настройка VRRP:
fast-interval - количество времени (мс), после которого отсылается очередной VRRP-пакет. Есть ещё возможность указать advertise-interval в секундах.
preempt - включает preemption. Можно указать Hold-Time, чтобы перевыбор происходил не сразу, а спустя некоторое время в секундах (полезно, если линк флапает, например).
Ну и лучше явно указать, что мы используем 3-ю версию протокола, так как он поддерживает IPv6 и fast-interval. (Но не поддерживает аутентификацию)
advertisements-threshold - если не получаем advertisement-пакет 3 раза, то-есть 3*500мс=1,5с от Master-роутера, то Master считается недоступным.
Закоммитим и посмотрим результат:
root@Gate-1# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/0.0 up 11 master Active A 0.454 lcl 192.168.0.1
vip 192.168.0.254
А теперь настроим Gate-2, но поставим приоритет 230 и посмотрим как работает Preemption:
root@Gate-2# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/0.0 up 11 backup Active D 1.186 lcl 192.168.0.2
vip 192.168.0.254
mas 192.168.0.1
[edit]
root@Gate-2# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/0.0 up 11 master Active A 0.289 lcl 192.168.0.2
vip 192.168.0.254
Перевыбор происходит не сразу, а спустя заданное время.
1.3. Проверка работы протокола
А теперь проверим работу протокола. Стоит обратить внимание на таблицу коммутации (там виден виртуальный MAC-адрес, который был сгенерирован по схеме описанной в теории) и ARP-таблицу PC.
root@PC:~# mtr 8.8.8.8
My traceroute [v0.86]
PC (0.0.0.0) Thu May 20 17:32:13 2021
Resolver: Received error response 2. (server failure)er of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.2 0.0% 12 0.6 5.5 0.5 32.9 11.3
2. 8.8.8.8 0.0% 11 1.4 1.3 1.0 1.5 0.0
Switch>show mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.5e00.010b DYNAMIC Et0/2
1 0050.0000.0800 DYNAMIC Et0/0
1 5000.0004.0002 DYNAMIC Et0/1
1 5000.0005.0002 DYNAMIC Et0/2
Total Mac Addresses for this criterion: 4
root@PC:~# arp -a
? (192.168.0.254) at 00:00:5e:00:01:0b [ether] on ens3
? (192.168.0.1) at 50:00:00:04:00:02 [ether] on ens3
Отключаем Gate-2:
My traceroute [v0.86]
PC (0.0.0.0) Thu May 20 17:37:09 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 11 0.7 9.5 0.6 97.2 29.1
2. 8.8.8.8 0.0% 10 1.1 1.2 1.0 1.6 0.0
root@PC:~# arp -a
? (192.168.0.254) at 00:00:5e:00:01:0b [ether] on ens3
? (192.168.0.1) at 50:00:00:04:00:02 [ether] on ens3
Switch>show mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.5e00.010b DYNAMIC Et0/1
1 0050.0000.0800 DYNAMIC Et0/0
1 5000.0004.0002 DYNAMIC Et0/1
1 5000.0005.0002 DYNAMIC Et0/2
Теперь видно, что трафик идёт другим путём, а коммутатор просто перенёс MAC-адрес в своей таблице на другой порт. За счёт виртуального MAC-адреса не происходит заполнения таблицы коммутации лишними записями.
1.4. Балансировка трафика
Для балансировки трафика можно включить ещё одну группу с другим приоритетом и часть устройств настроить на другой виртуальный IP-адрес. Таким образом мы сделаем аналог балансировки трафика. Добавим, для примера ещё одно устройство (PC2) к нашему свитчу с адресом 192.168.0.6 и укажем на нём Gateway 192.168.0.1.
Соответственно, виртуальный IP у нас будет 192.168.0.1, а основным роутером для новой группы станет Gate-1, так как его приоритет станет 255. Настроим:
[edit interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24]
root@Gate-1# show
vrrp-group 11 {
virtual-address 192.168.0.254;
priority 80;
fast-interval 500;
preempt {
hold-time 25;
}
advertisements-threshold 3;
}
vrrp-group 15 {
virtual-address 192.168.0.1;
priority 255; ##Коммит можно будет сделать только если мы явно
fast-interval 500; ##укажем priority 255, т.к. virtual-address равен
advertisements-threshold 3; ##адресу интерфейса и уберём hold-time для
} ##preemption или сделаем его 0
My traceroute [v0.86]
PC (0.0.0.0) Thu May 20 19:01:13 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.2 0.0% 5 0.8 3.4 0.8 13.4 5.5
2. 8.8.8.8 0.0% 4 1.1 1.2 1.1 1.3 0.0
Проверка PC1:
Switch>sh mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.5e00.010b DYNAMIC Et0/2
1 0000.5e00.010f DYNAMIC Et0/1
1 0050.0000.0800 DYNAMIC Et0/0
1 0050.0000.0900 DYNAMIC Et0/3
1 5000.0004.0002 DYNAMIC Et0/1
Total Mac Addresses for this criterion: 5
root@PC1:~# arp -a
? (192.168.0.1) at 00:00:5e:00:01:0f [ether] on ens3
root@PC1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:00:00:09:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.6/24 brd 192.168.0.255 scope global ens3
valid_lft forever preferred_lft forever
inet6 fe80::250:ff:fe00:900/64 scope link
valid_lft forever preferred_lft forever
root@PC1:~# ip r
default via 192.168.0.1 dev ens3 onlink
192.168.0.0/24 dev ens3 proto kernel scope link src 192.168.0.6
root@PC1:~# mtr 8.8.8.8
My traceroute [v0.86]
PC1 (0.0.0.0) Thu May 20 18:18:36 2021
Resolver: Received error response 2. (server failure)er of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 41 22.3 2.3 0.5 22.3 4.8
2. 8.8.8.8 0.0% 40 1.7 1.2 1.1 1.7 0.0
После того как стал недоступен Gate-1:
Switch>sh mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.5e00.010b DYNAMIC Et0/2
1 0000.5e00.010f DYNAMIC Et0/2
1 0050.0000.0800 DYNAMIC Et0/0
1 0050.0000.0900 DYNAMIC Et0/3
1 5000.0004.0002 DYNAMIC Et0/1
1 5000.0005.0002 DYNAMIC Et0/2
Total Mac Addresses for this criterion: 6
root@PC1:~# mtr 8.8.8.8
My traceroute [v0.86]
PC1 (0.0.0.0) Thu May 20 18:27:04 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.2 0.0% 7 0.7 0.8 0.7 1.0 0.0
2. 8.8.8.8 0.0% 6 1.0 1.2 1.0 1.5 0.0
2. Graceful Restart
Как известно, у Juniper Forwarding Plane и Control Plane разделены. Бывают моменты, когда нам нужно перезагрузить Routing Engine. При этом мы можем не прерывать сервис во время перезагрузки. В этом помогает Graceful Restart. Настроим топологию и включим OSPF. А теперь настроим запустим MTR с R1 в сторону R5 и перезапустим R2:
root@R2> request system halt
Halt the system ? [yes,no] (no) yes
*** FINAL System shutdown message from root@R2 ***
System going down IMMEDIATELY
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 done
All buffers synced.
Uptime: 3m26s
Khelp module "jsocket" can't unload until its refcount drops from 4 to 0.
The operating system has halted.
Please press any key to reboot.
Теперь мы увидим потери трафика на R1:
My traceroute [v0.69]
R1 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Thu May 20 16:59:45 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.0.0.1 44.7% 76 1.4 12.8 1.1 73.7 20.2
2. 5.5.5.5 46.1% 76 2.3 9.4 1.6 75.2 20.1
Graceful Restart позволяет оставить в работе Forwarding Plane, таким образом, транзитный трафик терятся не будет. О том, что устройство перезагружается будут знать только соседи. Включим Graceful Restart:
Тут мы указали, чтобы соседи ждали 500 секунд перезагрузки устройства и только после этого начинали перестраивать свои топологии и считать, что оно недоступно. Закоммитим и перезапустим R2. Результат:
My traceroute [v0.69]
R1 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Thu May 20 17:06:02 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.0.0.1 0.0% 56 1.4 15.3 1.0 203.3 38.2
2. 5.5.5.5 0.0% 55 1.8 6.4 1.4 62.6 12.1
3. Graceful RE Switchover (GRES)
В шасси можно подключить ещё один RE. Это позволит переключиться на него при неполадках с основным RE. Основной и резервный RE содержат одну и ту же конфигурацию и синхронизируют состояние ядра операционной системы. Если внезапно отключится Master RE, то через 2 секунды это обнаружит Backup RE и примет роль Master'а. Это позволит не потерять управление роутером. Однако, Control Plane хранится в RE, поэтому Backup RE после того как он стал Master'ом начнёт запуск различных алгоритмов маршрутизации. Чтобы Graceful RE Switchover работал корректно, необходим уже работающий Graceful Restart. Пересылка трафика при этом на уровне PFE не прервётся.
Включается так:
root@R2# set chassis redundancy graceful-switchover
Проверка работы:
root@R2# run show system switchover
Выбор RE, который должен стать Master'ом:
root@R2# run request chassis routing-engine master switch check
4. Nonstop Active Routing (NSR)
Это дополнение к предыдущему пункту. Позволяет полностью синхронизировать два RE, включая настройки и состояния протоколов. Т.е. демоны маршрутизации на Backup RE находятся в том же состоянии, что и на Master. Также для настройки NSR необходима синхронизация коммитов (её можно включить и для GRES без NSR, но тут она обязательна). По итогу, NSR позволяет сразу же переключиться на другой RE, не запуская процессы расчёта различных протоколов, так как всё синхронизируется в процессе работы.
Graceful Restart необходимо выключить, если используется NSR, так как NSR является заменой Graceful Restart.
После коммита R2 становится Master-ом ({master}[edit]) и мы можем проверить синхронизированные процессы для протоколов:
root@R2# commit
warning: Could not connect to re1 : No route to host
warning: Cannot connect to other RE, ignoring it
commit complete
{master}[edit]
root@R2# run show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol Synchronization Status
OSPF NotStarted
5. In-Service Software Upgrade (ISSU)
Если включены GRES и NSR, то можно обновить нашу ОС без прерывания сервиса. Делается это командой:
root@R2# run request system software in-service-upgrade path-to-image reboot
6. Virtual Chassis
По факту - это стекирование. Когда один RE (или несколько синхронизированных) управляет различными FE и видит их как линейные карты. Подробнее тут: Virtual Chassis.
