IPv6 шлюз не устанавливается при включении VLAN-WAN интерфейса

[qmxocynjca]

Ситуация:

Есть незамысловатый интерфейс GigabitEthernet0/Vlan100:

Спойлер

interface GigabitEthernet0/Vlan100
    security-level public
    ip global 61734
    ipv6 address auto
    ipv6 prefix auto
    up
!

 

На другой стороне запущен radvd с radvd.conf:

Спойлер

interface ens19 {
        AdvSendAdvert on;

        prefix ::/64 {
            AdvOnLink on;
            AdvAutonomous on;
            DeprecatePrefix on;
        };
};

Где ens19:

Спойлер

3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:41:8d:08 brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet6 fd2c:7b40:f98f:0:be24:11ff:fe41:8d08/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 85861sec preferred_lft 13861sec
    inet6 fd2c:7b40:f98f::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fe41:8d08/64 scope link 
       valid_lft forever preferred_lft forever

Проблема: при включении интерфейса в Кинетике, он успешно отсылает RS и получает RA (видно по tcpdump), в логах даже видно что дефолтный маршрут получен и выставлен:
Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe41:8d08).

но по факту интерфейс конфигурирует только адрес, а шлюз не появляется ни в ip -6 route, ни в разделе Маршрутизация. Периодические перепосылы RA так же не добавляют гейтвей. Однако, если остановить и запустить radvd на другой стороне (именно так, т.к. stop отсылает RA с lifetime 0), то маршрут "::/0 fe80::be24:11ff:fe41:8d08" на Кинетике успешно появляется во всех местах где он должен быть виден (на карточке интерфейса, в разделе Маршрутизация, в ip -6 route).

По ощущениям это выглядит как гонка, когда маршрут ещё не может быть добавлен по какой-то причине на старте интерфейса. Префиксы менял, dhcpv6 с делегацией подсовывал, параметры в radvd крутил, всё в итоге свелось к такому минимально-воспроизводимому сетапу. Прошивка 4.3.4, селф-тест следующим сообщением.

[qmxocynjca]

Путём экспериментов выяснилось, что гейтвей не устанавливается, если RA был обработан до перехода ipv6 на интерфейсе в состояние "running":

Ip6::Dhcp::Client: "GigabitEthernet0/Vlan100": state "bound".
Network::Interface::Ip6: "GigabitEthernet0/Vlan100": interface "GigabitEthernet0/Vlan100" is global, priority 65278.
Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe30:96b0).
Network::Interface::Base: "GigabitEthernet0/Vlan100": "ip6" changed "ipv6" layer state "pending" to "running".

@Le ecureuil есть шанс на фикс?

Изменено 16 июля пользователем qmxocynjca

[Le ecureuil]

@slomblobov

[qmxocynjca]

Есть какие-нибудь подвижки или может рекомендации куда копнуть? У меня нет провайдера с IPv6, поэтому толком и глянуть негде как оно должно работать в реальности. Может какие dhcp опции надо выставить? Нужен ли DNS? В ситуации с проводным интернетом гейтвей же всегда должен быть link-local? Или есть другой механизм, который может использоваться у провайдеров? Как-то же оно работает у людей, и никто не жалуется...

[slomblobov]

Если вы хотите сконфигурировать роутер, то сервер должен делегировать префикс по dhcpv6, одним RA тут не обойтись.

По селфтесту видно, что по vlan100 префикс не получен.

[qmxocynjca]

Приложил скрытым сообщением два self-test, первый при запуске интерфейса, второй после рестарта radvd на другой стороне. DHCPv6 включен, префикс уходит, OPKG выключен.

После включения интерфейса:

После рестарта radvd:

[qmxocynjca]

По self-test вижу что до рестарта radvd, в table_254 маршрута через fe80::be24:11ff:fe30:96b0 нет, а после рестарта он появляется. При этом в таблице политики table_14 он присутствует сразу. Кажется где-то здесь что-то не так.

Изменено Среда в 12:47 пользователем qmxocynjca

[slomblobov]

Интерфейс ISP имеет приоритет 65501. GigabitEthernet0/Vlan100 меньший - 65469.

Не получится сделать так, чтобы v4 был с приоритетного, а v6 с запасного.
Необходимо GigabitEthernet0/Vlan100 сделать v6 only и поставить высокий приоритет, как это сделано с туннелями 6in4.
 

[qmxocynjca]

Да, если его сделать самым приоритетным, то маршрут остаётся, но это прям wtf moment.

Тут возникают дополнительные вопросы - почему IPv6 маршруты WG в такой же ситуации на месте? И почему выкл-вкл radvd восстанавливает маршрут на Vlan100? Точно надо грохать/игнорировать этот маршрут на старте интерфейса? Кинетик же через свой radvd не анонсирует себя как гейтвей, если самое приоритетное соединение без ipv6, поэтому плохо никому не должно быть.

Очень прошу - почините это, маршрут в таблице должен оставаться, даже если соединение не приоритетное. На 5-й версии готов тестировать любой фикс, лишь бы это заработало адекватно.

34 минуты назад, slomblobov сказал:

Не получится сделать так, чтобы v4 был с приоритетного, а v6 с запасного.

Это не так важно в данном случае. Предположим, что я из entware хочу делать запросы по ipv6, и рабочее соединение, пусть и не приоритетное, должно работать при явном вызове curl --interface eth2.100 -6. Сейчас это работает корректно для nwg*, и приоритеты тут не играют роли.

[Le ecureuil]

В 23.07.2025 в 17:21, qmxocynjca сказал:

Очень прошу - почините это, маршрут в таблице должен оставаться, даже если соединение не приоритетное. На 5-й версии готов тестировать любой фикс, лишь бы это заработало адекватно.

Не должен. Сейчас существует консенсус, что основное v4 и v6 соединение должно быть одно и то же, расщепление не допускается. То есть default route в обоих протоколах должен вести в один и тот же интерфейс. 

WG работает только потому, что это L3-only интерфейс, и в него можно пихать пакеты не зная адреса gateway. С L2-интерфейсами так не прокатит, обязательно нужен gateway.

[qmxocynjca]

Окей, кажется я проникся вашим консенсусом и в целом понимаю вас. Сделал на основном профиле IPv6 соединение приоритетным, чтобы роутер включил всё что нужно, а уже политиками разрулил по сегментам и устройствам.

Всё же есть некоторые нестыковки:

• При наличии приоритетного подключения 6in4 соединения же будут расщепляться, верно?
• В политиках разрешается расщепляться.
• Как быть с KeenDNS, если хочется анонсить IP с другого подключения?

В принципе текущий подход приемлем, но кажется его можно разрешать и без приоритетного IPv6 подключения, например слегка расширив директиву local-prefix, добавив опциональный флаг "routable".

ipv6 local-prefix (default | ‹prefix›) [routable]

Пусть наличие этого флага включает анонс гейтвея, разрешает использование IPv6 с первого возможного подключения в дефолтном профиле и работу IPv6 в политиках. Эта opt-in фича удовлетворила бы кучу страдальцев без нативного IPv6, меня в том числе . Тем более в 5-й версии IPv6 зеленый свет, отличный повод сделать его ещё доступней.

Изменено Четверг в 22:13 пользователем qmxocynjca

[Le ecureuil]

7 часов назад, qmxocynjca сказал:

 

• При наличии приоритетного подключения 6in4 соединения же будут расщепляться, верно?
• В политиках разрешается расщепляться.
• Как быть с KeenDNS, если хочется анонсить IP с другого подключения?

1. Это единственное узаконенное исключение, еще есть Dslite и MAP-T в этом списке.

2. Нет, а если все же расщепляется - давайте поправим.

3. Никак, такие хотелки не реализованы.

[Leshiyart]

8 минут назад, Le ecureuil сказал:

2. Нет, а если все же расщепляется - давайте поправим.

если речь об этом? то да, в отдельной политике в4 от одного прова в6 от другого. но тут надо проголосовать надо ли такое фиксить, так же слабо себе представляю что будет если будет несколько провов с в6

[Leshiyart]

P.s. в основной политике пров с в6 вверху, по в6 ходят все политики по нему, а вот по в4 зависит от приоритета в этой политике. Если сделать прова с в6 не приоритетным, в6 не будет ни в одной политике пока оно не станет приоритетным/активным

[qmxocynjca]

51 минуту назад, Le ecureuil сказал:

2. Нет, а если все же расщепляется - давайте поправим.

42 минуты назад, Leshiyart сказал:

да, в отдельной политике в4 от одного прова в6 от другого. но тут надо проголосовать надо ли такое фиксить

Согласен с @Leshiyart, не хочется рубить с плеча, меня это тоже устраивает. Возможно есть и другие, кто пользуются этим не осознанно и тоже получают профит.

По хорошему бы уметь и правильный режим и opt-in расщепление. Если сплит в политиках запретить, то девайсы в них будут думать что IPv6 есть, и даже могут иметь GUA адрес, а роутер при этом не будет пускать их по IPv6, что как-то так себе.