В этой теме я хочу собрать всё, что пока не работает на 100% при чистом развёртывании IPv6 в кластере Proxmox PVE (обычно в настройке типа mesh). Мне не хватает страницы в Wiki, поэтому пока использую эту, как таковую. В общем, я немного экспериментирую с IPv6, и хочу добавить сюда обходные решения и тикеты (особенно связанные с upstream), если это уместно.
Важно: я считаю, что один отдельный узел PVE (особенно для домашней настройки с подключённым напрямую хранилищем) с одним только IPv6 должен работать без проблем, но проблемы начинаются, когда добавляешь остальную часть сети – тогда всё начинает ломаться странным образом.
Касательно mesh (сетевая топология):
Corosync в mesh вызывал проблемы примерно в версии 8.3.5 — засыпал логи сообщениями с предупреждениями kronosnet(sp?) о пакетах, приходящих на «неправильный» физический интерфейс, хотя IP были привязаны к loopback интерфейсам и маршрутизировались соответствующим образом.
В PVE это исправили с версии 8.4.0(?), upstream пока ещё работает над исправлениями.
FRR (версия 10.3.1, последний проверенный) пока не работает с IS-IS на интерфейсах без нумерации IPv4.
IPv6-маршруты работают и распространяются корректно.
IPv4-маршруты не «импортируются», так как нет IPv4 следующего хопа с «назначением».
В таких случаях лучше использовать OpenFabric — при предположении, что это только P2P-ссылки. Если нужно использовать (как правило, LAN с несколькими соседями IS-IS/пирами на интерфейсе), просто назначьте IPv4-адрес... любой, достаточно /32. Обычно я ставлю и добавляю loopback IPv4 на эти интерфейсы, и всё работает.
Проблемы с IPv6 в ifupdown2:
VxLAN endpoint’ы не поддерживают IPv6.
Linux kernel и iproute2 поддерживают IPv6.
ifupdown2 требует релиза 3.10.0 или новее (последняя проверка была, что в 3.9.x это ещё не работает).
Есть патчи, чтобы добавить функционал, но PVE ждёт релиза ifupdown2 версии 3.10.0 в Debian, чтобы добавить нужную версию.
Обходной путь: добавлять IPv4 endpoint’ы для VxLAN (обычно loopback IP).
Создание виртуальной конечной точки remote peers SOURCE-IP выбирает IPv6 hostname lookup, и ifupdown2 на этом падает.
Проблема в том, что при хост-lookup всегда возвращается IPv6 IP (а я этого «требую» для удалённого доступа и разных IPv6-only задач).
Я завёл тикет с просьбой добавить local-ip для жёсткого задания исходного IP.
Это также влияет на FRR, связанный с EVPN (по крайней мере до версии 10.3.1).
L2VPN EVPN пока не поддерживает IPv6 VTEP’ы — routing/nht заполняет router-id, а не конечный IPv6-адрес назначения.
Есть тикеты и работа по поддержке IPv6 VTEPs в L2VPN EVPN — PR открыт, но в нём нет необходимых topotests и документации для принятия.
Если заметите что-то ещё, что я упустил — дайте знать.
Важно: я считаю, что один отдельный узел PVE (особенно для домашней настройки с подключённым напрямую хранилищем) с одним только IPv6 должен работать без проблем, но проблемы начинаются, когда добавляешь остальную часть сети – тогда всё начинает ломаться странным образом.
Касательно mesh (сетевая топология):
Corosync в mesh вызывал проблемы примерно в версии 8.3.5 — засыпал логи сообщениями с предупреждениями kronosnet(sp?) о пакетах, приходящих на «неправильный» физический интерфейс, хотя IP были привязаны к loopback интерфейсам и маршрутизировались соответствующим образом.
В PVE это исправили с версии 8.4.0(?), upstream пока ещё работает над исправлениями.
FRR (версия 10.3.1, последний проверенный) пока не работает с IS-IS на интерфейсах без нумерации IPv4.
IPv6-маршруты работают и распространяются корректно.
IPv4-маршруты не «импортируются», так как нет IPv4 следующего хопа с «назначением».
В таких случаях лучше использовать OpenFabric — при предположении, что это только P2P-ссылки. Если нужно использовать (как правило, LAN с несколькими соседями IS-IS/пирами на интерфейсе), просто назначьте IPv4-адрес... любой, достаточно /32. Обычно я ставлю и добавляю loopback IPv4 на эти интерфейсы, и всё работает.
Проблемы с IPv6 в ifupdown2:
VxLAN endpoint’ы не поддерживают IPv6.
Linux kernel и iproute2 поддерживают IPv6.
ifupdown2 требует релиза 3.10.0 или новее (последняя проверка была, что в 3.9.x это ещё не работает).
Есть патчи, чтобы добавить функционал, но PVE ждёт релиза ifupdown2 версии 3.10.0 в Debian, чтобы добавить нужную версию.
Обходной путь: добавлять IPv4 endpoint’ы для VxLAN (обычно loopback IP).
Создание виртуальной конечной точки remote peers SOURCE-IP выбирает IPv6 hostname lookup, и ifupdown2 на этом падает.
Проблема в том, что при хост-lookup всегда возвращается IPv6 IP (а я этого «требую» для удалённого доступа и разных IPv6-only задач).
Я завёл тикет с просьбой добавить local-ip для жёсткого задания исходного IP.
Это также влияет на FRR, связанный с EVPN (по крайней мере до версии 10.3.1).
L2VPN EVPN пока не поддерживает IPv6 VTEP’ы — routing/nht заполняет router-id, а не конечный IPv6-адрес назначения.
Есть тикеты и работа по поддержке IPv6 VTEPs в L2VPN EVPN — PR открыт, но в нём нет необходимых topotests и документации для принятия.
Если заметите что-то ещё, что я упустил — дайте знать.
