Сопровождение SDN Amano

Общая информация

Amano — это распределённый SDN-контроллер для управления виртуальными сетями в OpenStack-среде. Данная документация описывает ключевые аспекты его эксплуатации, диагностики и настройки.

Архитектура и основные понятия

Кластер контроллеров

Контроллеры Amano работают в кластере, где один из узлов выполняет роль MASTER, обрабатывая сетевой трафик гипервизоров, а остальные находятся в роли SLAVE в режиме горячего резерва. При этом для каждого из гипервизоров роль MASTER может принадлежать разным контроллерам.

Роль amano-agent

На каждом гипервизоре работает amano-agent. Его основная функция — поддержание базовой сетевой функциональности при полной потере связи с основным кластером контроллеров.

Важно: Агент не обрабатывает трафик в штатном режиме и не настраивает dataplane. Он активируется только при недоступности всех контроллеров "tcp:<IP>:6653".

Особенности обработки ARP

В Amano ARP-запросы обрабатываются иначе, чем остальные типы трафика. Вместо классического подхода «первый пакет – обработка контроллером – установка flow для всех последующих», используется метод, исключающий широковещательную рассылку, которая создаёт избыточную нагрузку на контроллер (N событий на 1 пакет, где N – число гипервизоров).

При получении ARP-запроса контроллер:

самостоятельно формирует ARP-ответ, не рассылая запрос дальше;
устанавливает flow для автоматической генерации ARP-ответов.

Это работает для всех портов, известных Amano (порты инстанса и внешние порты, к которым уже было обращение).

При ARP-запросе от инстанса во внешнюю сеть контроллер направляет пакет только на аплинк, ожидает ответ и заносит информацию об устройстве в БД. Если ответ не приходит, такой ARP-трафик блокируется постоянным правилом. Правило удаляется автоматически, когда информация об устройстве появляется другим способом (например, при создании порта инстанса с этим адресом или при обращении извне).

При ARP-запросе от внешнего устройства к инстансу контроллер сразу вносит запись о внешнем устройстве в БД.

Благодаря этому механизму внутри Amano практически полностью отсутствуют широковещательные рассылки.

Особенности обработки DHCP

DHCP-запросы обрабатываются аналогично ARP: широковещательный запрос перехватывается контроллером, формируется ответ, и broadcast дальше не распространяется.

Если в подсети DHCP отключён, запросы уходят во внешнюю сеть, что может приводить к засорению сети (в образах инстансов по умолчанию включено получение адреса по DHCP). Такой режим не рекомендуется использовать без крайней необходимости.

Аналогично обрабатываются ICMPv6: ND и RA.

Отказоустойчивость

Все HTTP-запросы к Amano проходят через HAProxy, который постоянно выполняет healthcheck контроллеров. Если REST одного из контроллеров недоступен, запросы направляются к другим.

Если HTTP-запрос, создающий какие-либо ресурсы, попадает на контроллер, не отвечающий за гипервизор, на котором создаётся/удаляется инстанс, контроллер делегирует запрос правильному контроллеру по REST API.

Со стороны OpenFlow каждый OVS-коммутатор на гипервизоре отправляет EventOFPEchoRequest каждые inactivity_probe секунд. Если контроллер не отвечает или отвечает с ошибкой, он теряет роль MASTER для данного узла. OVS инициирует переключение на другой контроллер. При восстановлении корректных ответов старого контроллера роль MASTER может вернуться к нему.

Операционная деятельность

Проверка подключения контроллеров

Для проверки, что контроллеры запущены и подключены ко всем гипервизорам, анализируйте логи контроллера. Ищите записи вида:

2025-12-26 12:31:23,873 | AmanoSwitch | INFO | state change on datapath 2 handled: main
2025-12-26 12:31:23,874 | AmanoSwitch | DEBUG | OFPRoleReply received: role=MASTER generation_id=0

Критерий успеха: Общее количество таких записей в логах должно равняться сумме количества гипервизоров (datapath) и количества контроллеров Amano в кластере.

Определение активного (MASTER) контроллера

Чтобы определить, какой контроллер обрабатывает трафик для конкретного гипервизора:

Посмотрите список подключенных контроллеров:

$ sudo ovs-vsctl show

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

Bridge br-int
    Controller "tcp:192.168.25.100:6653"
        is_connected: true
    Controller "tcp:192.168.25.102:6653"
        is_connected: true
    Controller "tcp:192.168.25.101:6653"

Определите контроллер с ролью MASTER:
```
$ sudo ovs-vsctl list Controller
```
В выводе для активного контроллера будет указано role: master.

Принудительное переключение MASTER-роли

Переключиться на другой контроллер можно, если у него is_connected: true. Выполните на гипервизоре:

$ sudo ovs-vsctl set Bridge br-int other_config:default_controller_ip=<IP_адрес_нового_MASTER>

Например:

$ sudo ovs-vsctl set Bridge br-int other_config:default_controller_ip=192.168.25.100

Важное требование: Переменная default_controller_ip должна быть корректно выставлена на каждом гипервизоре для правильной балансировки.

Перезапуск сервисов

Можно ли перезапускать контейнеры `amano` и `amano-agent`?

Да, это безопасно. Максимальный простой control plane сетевых операций не превысит одной секунды, на data plane никаких изменений не произойдет.

Порядок перезапуска может быть любым.
Важное замечание: Корректное распределение ролей MASTER/SLAVE восстановится через N секунд, где N — значение параметра контроллера inactivity_probe (в миллисекундах).
- Параметр можно изменить: sudo ovs-vsctl set controller <uuid> inactivity_probe=10000.
- Запрещено выставлять inactivity_probe=0.

Управление flow-правилами

Можно ли выполнять `sudo ovs-ofctl del-flows br-int`?

Да, но учтите, что контроллерам потребуется время на восстановление всех правил. При сбросе на всех гипервизорах в большой инсталляции полное восстановление сети может занять 10-15 минут. Также инстансы, обрабатывающие большие объемы трафика во время пересоздания могут попасть под flood control (рекомендуется временно изменить его параметры и перезапустить контейнер amano - см. ниже «справочник по параметрам»).

Полное пересоздание dataplane

Эта процедура полезна при крупных обновлениях:

Обновите и запустите контейнеры Amano.
На всех узлах (контроллерах и гипервизорах) выполните:
```
$ sudo ovs-ofctl del-flows br-int
```

Диагностика и устранение проблем

Проблема: Отсутствие связи между конкретными инстансами

Симптом: Нет связи между двумя инстансами или инстансом и внешним узлом, при этом с других аналогичных инстансов связь работает.

Возможная причина: Трафик попал под действие механизма flood control и был заблокирован.

Диагностика:

На гипервизоре-источнике найдите drop-правила, содержащие MAC-адреса проблемных интерфейсов:

$ sudo ovs-ofctl dump-flows br-int | grep drop

Пример проблемного правила:

cookie=0x0, duration=772.063s, table=0, n_packets=24, n_bytes=1536, hard_timeout=800, idle_age=22, priority=199,dl_src=02:04:96:98:80:86,dl_dst=01:00:5e:00:00:01 actions=drop

Решение:

Перезапустите контейнеры Amano на всех контроллерах.
Удалите конкретное проблемное правило на гипервизоре:
```
$ sudo ovs-ofctl del-flows br-int "dl_src=02:04:96:98:80:86,dl_dst=01:00:5e:00:00:01"
```

Устранение ошибок конфигурации

Ошибка: Отсутствует default_controller_ip

Если в логах появляется сообщение:

Bridge does not contain a column whose name matches "other_config:default_controller_ip"

Решение: Необходимо проверить и проставить эту настройку на всех гипервизорах:

$ sudo ovs-vsctl set Bridge br-int other_config:default_controller_ip=<IP_активного_контроллера>

Ошибка: Отсутствует tenant_ip

Если в логах возникает исключение:

Exception: Bridge does not contain a column whose name matches "other_config:tenant_ip"

Причина: На гипервизоре не настроен IP-адрес для туннелей overlay-сети (VXLAN/Geneve).

Решение: На каждом гипервизоре необходимо выставить tenant_ip:

$ sudo ovs-vsctl set Bridge br-int other_config:tenant_ip=<IP-адрес_гипервизора>

Пример:

$ sudo ovs-vsctl set Bridge br-int other_config:tenant_ip=192.168.25.21

Проблемы создания ресурсов (порт/сеть/подсеть/роутер)

Если ресурс не создаётся, необходимо:

Зайти на все контроллеры и проверить логи Neutron:
```
/var/log/containers/neutron/server.log
```
Искать ошибки типа MechanismDriverError – они указывают на проблему в Amano.
Проверить доступность Amano: на каждом контроллере выполнить:

podman logs -f amano

В логах должны каждую секунду появляться записи healthcheck-запросов вида:
```
INFO:     192.168.25.94:53126 - "GET / HTTP/1.0" 200 OK
```
Если таких записей нет, перезапустите контейнер:

podman restart amano
Убедиться, что REST-интерфейс Amano слушает порт 5007:

netstat -ntlp | grep 5007

Должны быть видны адреса контроллеров. Проверить доступность можно curl-запросом:

curl 192.168.25.94:5007

Если ответа нет, перезапустите контейнер. Если ответ есть, вероятна проблема в настройках HAProxy или nftables.
Проверить правила nftables:

nft list ruleset

Убедиться, что есть разрешающее правило для порта 5007.

Проблема: Инстанс не пингуется

Зайти в консоль инстанса, проверить наличие IP-адреса. Если адреса нет, попробовать вручную запустить dhclient. Если DHCP не срабатывает, возможно контроллер Amano перегружен; перезапустите контейнеры amano на всех контроллерах.
Если IP-адрес есть, определить гипервизор, на котором запущен инстанс. Зайти на него и выполнить:

sudo ovs-ofctl dump-flows br-int | grep <IP_или_MAC_инстанса>

Поискать правила с actions=drop (см. раздел про flood control). Если такие есть, удалить их.
Если flows с адресом инстанса присутствуют, проверить группы безопасности: разрешён ли ICMP (или нужный протокол). В крайнем случае временно отключить port security на порту.
Проверить прохождение трафика через tcpdump на интерфейсах veth или patch (зависит от конфигурации). Создать тестовый инстанс на том же гипервизоре и проверить связь между ними. Если они видят друг друга, а внешняя сеть нет – проблема в маршрутизации на физическую сеть.
Убедиться, что veth-пары находятся в состоянии UP и MTU на них не меньше MTU интерфейсов инстанса. Также проверить, что bridge br-int находится в состоянии DOWN (иначе он может создавать излишнюю нагрузку на OVS).
Проверить, что VLAN, в котором находится инстанс, присутствует на uplink-интерфейсе гипервизора, подключённом к br-ex.
Если все проверки не дали результата, проанализировать логи amano на предмет упоминаний пакетов инстанса. Если пакеты видны, но flows не установились, изучить логи OVS:

/var/log/openvswitch/ovs-vswitchd.log

Обратить внимание на сообщения о высокой нагрузке (тысячи flow_mods, переподключения к контроллеру, сообщения от revalidator). В таком случае можно попробовать отключить port security везде, где возможно, и перезапустить amano на всех контроллерах.

Проблема: Рвутся соединения, неравномерная задержка пингов

Убедиться, что br-int находится в состоянии DOWN (иначе мост может создавать избыточную нагрузку на OVS).
Проверить логи OVS на наличие признаков высокой нагрузки (см. выше). При необходимости отключить port security и перезапустить amano.
Если проблема не в этом, вероятно, она на стороне физической инфраструктуры.

Проблема: Нестабильная работа контейнера amano (перезапуски, зависания)

Вероятна перегрузка контроллера. Рекомендуется:

Перезапустить контейнер: podman restart amano.
Ужесточить лимиты блокировки трафика – увеличить время бана и/или уменьшить пороги срабатывания с помощью параметров DDOS_FLOW_TIMEOUT, DDOS_MAX_PACKETS, DDOS_MAX_ARP_PACKETS.

Проблема: Connection timeout между контроллерами при запросах /port_flows, /floating_ip_flows, долгие операции создания/удаления порта

В качестве временного решения можно выставить на всех узлах один и тот же контроллер в качестве default_controller_ip, но это увеличит нагрузку на dataplane этого контроллера:

sudo ovs-vsctl set Bridge br-int other_config:default_controller_ip=<IP_контроллера>

Проблема: Нежелательный трафик не блокируется автоматически

Если какой-то тип трафика (например, большое количество unicast с MAC-адресами не из облака) не попадает под автоматическую блокировку, можно добавить правила вручную с помощью скрипта. Пример скрипта для массовой установки drop-правил на всех узлах:

#!/bin/bash

BAN_IPV4="10.167.0.26"
USER="tripleo-admin"
DOMAIN="ctlplane"
CONTROLLER_NODES=("asperitas-controller-0" "asperitas-controller-1" "asperitas-controller-2")
COMPUTE_NODES=()
for i in {0..30}; do
    COMPUTE_NODES+=("asperitas-compute-$i")
done
ALL_NODES=("${CONTROLLER_NODES[@]}" "${COMPUTE_NODES[@]}")
TOTAL=${#ALL_NODES[@]}
COUNT=0

for NODE in "${ALL_NODES[@]}"; do
    COUNT=$((COUNT + 1))
    echo "[$COUNT/$TOTAL] Processing $NODE..."

    echo "  Adding drop rule for IPv4 $BAN_IPV4"
    ssh "$USER@$NODE.$DOMAIN" "sudo ovs-ofctl add-flow br-int 'table=0,priority=10000,ip,nw_src=$BAN_IPV4,actions=drop'"

    echo "  Adding drop rule for all IPv6"
    ssh "$USER@$NODE.$DOMAIN" "sudo ovs-ofctl add-flow br-int 'table=0,priority=10000,ipv6,actions=drop'"

    echo "  Adding drop rule for multicast 78:e7:d1:23:ed:60 -> 01:00:5e:00:00:12 from 172.17.41.73 to 224.0.0.18"
    ssh "$USER@$NODE.$DOMAIN" "sudo ovs-ofctl add-flow br-int 'table=0,priority=10000,dl_src=78:e7:d1:23:ed:60,dl_dst=01:00:5e:00:00:12,nw_src=172.17.41.73,nw_dst=224.0.0.18,in_port=1,actions=drop'"

    echo "  Done"
    echo ""
done

echo "All nodes processed successfully"

Справочник по параметрам

Контроллер Amano настраивается через переменные окружения:

Переменная	Описание	По умолчанию
`HOST`	IP-адрес или доменное имя интерфейса для запуска сервиса.	`None`
`PORT`	Порт для запуска сервиса.	`None`
`ROLE`	Роль, которую контроллер будет запрашивать у OVS. Не гарантирует получение роли MASTER при выставлении соответствующего значения, гарантирует лишь участие в выборах MASTER. Валидные значения MASTER и SLAVE.	`None`
`LOGGING`	Уровень детализации логов (`INFO`, `DEBUG` и т.д.).	`None`
`DATABASE_URL`	URL для подключения к базе данных.	`None`
`DDOS_FLOW_TIMEOUT`	Время жизни (сек.) правила блокировки флуда. Едино для всех типов.	500
`DDOS_CACHE_TIMEOUT`	Размер временного окна (сек.) для накопления пакетов, для определения флуда.	5
`DDOS_MAX_ARP_PACKETS`	Порог срабатывания (пакетов в DDOS_CACHE_TIMEOUT сек) для блокировки ARP-флуда.	3000
`DEFAULT_ARP_CACHE_TIMEOUT`	TTL (сек.) ARP-кэша в flow-правилах для внешнего трафика.	5
`DDOS_MAX_PACKETS`	Порог срабатывания (пакетов в DDOS_CACHE_TIMEOUT сек) для блокировки storm-control (напр., unknown unicast).	3000
`USE_DDOS_TIMEOUT_FOR_VLANS`	Блокировать трафик для VLAN`ов, не созданных в облаке.	`False`
`USE_DDOS_TIMEOUT_FOR_ARP`	Блокировать ARP-трафик на несуществующие в сети хосты.	`True`