1.     Посылайте с устройства host-behind-spoke1 на host-behind-hub1 защищаемый ICMP-трафик:

root@host-behind-spoke1:~# ping 192.168.100.100

PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data.

64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=3.54 ms

64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=2.33 ms

64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=2.49 ms

64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=2.26 ms

64  bytes from 192.168.100.100: icmp_seq=5 ttl=64 time=2.32 ms

...

2.     Смоделируйте отказ канала связи, например, отключив сетевой кабель внешнего интерфейса, на том криптошлюзе из резервного ЦОДа (Spoke1-0 или Spoke1-1), через который в данный момент идет защищаемый ICMP трафик от 192.168.100.101 к 192.168.100.100. Определить криптошлюз, через который в данный момент идет требуемый трафик, можно при помощи запуска утилиты tcpdump на capture интерфейсе.

3.     При помощи диагностических команд, выполняемых на коммутаторах Int-switch1-Spoke1, Int-switch1-Hub1, убедитесь в том, что сетевые интерфейсы, которые были подключены к криптошлюзам, через которые шел защищаемый ICMP трафик от 192.168.100.101 к 192.168.100.100, переведены в неактивное состояние (с точки зрения протокола LACP).

4.     Подождите некоторое время пока протокол LACP перебалансирует трафик на рабочую пару криптошлюзов. Убедиться в этом можно также при помощи запуска утилиты tcpdump на capture интерфейсе.

5.     Как только произошла перебалансировка трафика, убедитесь в том, что в IPsec туннелях рабочей пары криптошлюзов симметрично увеличиваются счетчики Sent и Rcvd. Для просмотра счетчиков выполните команду run sa_mgr show из cisco-like консоли криптошлюзов.

При наличии отклонений проанализируйте журналы на криптошлюзах. Сделать это можно при помощи команд из linux bash:

less /var/log/cspvpngate.log

и

journalctl -xe -u l2svc_s@<l2svc_конфиг>.service

(где <l2svc_конфиг> – название файла конфигураций для L2).