13.09.2026 · Самуил Арсов · IPv6, MikroTik, openwrt, Ubiquiti, Рутери

IPv6 prefix delegation в реална ISP мрежа (част 4): Два неканени гости в собствената мрежа

Дотук в поредицата

Схемата с /60 на клиент (част 1), капаните в клиентския рутер (част 2) и изгубеният по пътя multicast — радиа с IGMP snooping без querier и ONU-та, през които IPv6 prefix delegation не минава (част 3). Тук са двете неща, които най-малко очаквах да намеря в собствената си мрежа.

Неканен гост №1: DHCPv6 сървър в мениджмънта на радиолинк

Един клиент не се връзваше към граничния рутер, но DHCPv6 клиентът му не беше searching. Беше bound — към друг сървър:

/ipv6 dhcp-client print detail
 0  interface=ether1 status=bound dhcp-server-v6=fe80::1e6a:1bff:fe00:c9
    prefix=fd12:3456:789a:1::/64

/ipv6 route print where dst-address=::/0
DAd dst-address=::/0 gateway=fe80::1e6a:1bff:fe00:c9%ether1

ULA префикс и default route към устройство, което няма никакъв IPv6 път навън. По MAC адреса стигнахме до мениджмънта на наш радиолинк — Ubiquiti Wave MLO5 в bridge режим, чийто IP за управление стоеше в същия L2 сегмент като клиентите.

Отвътре радиото е OpenWrt. И там, в /etc/config, фабрично:

network.globals.ula_prefix='fd12:3456:789a::/48'
network.lan.ip6assign='60'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'

odhcpd вървеше на br-lan, където е и радиоинтерфейсът. В таблицата с маршрути на радиото имаше ULA делегации към четирима наши клиенти. Двама от тях имаха и наш binding и не бяха забелязали нищо. Другите двама още нямаха — и при тях клиентският рутер се връзваше само към радиото.

Как го изключихме

Опит	Резултат
Уеб интерфейсът	В настройките на мениджмънта има само IPv4. IPv6 настройка няма никъде.
API-то на радиото	IPv6 адресът се вижда в модела на интерфейсите, но записът с изрязан v6 адрес беше отказан — API-то очаква различна структура от тази, която връща.
SSH и `uci`	Работи. SSH-ът беше изключен и първо го пуснахме през API-то — там записът на услугите мина без проблем.

uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ra='disabled'
uci commit dhcp
/etc/init.d/odhcpd restart

Опасението беше дали ще оцелее след рестарт. На старите airOS имаше отделна команда за запис. Тук save_cfg съществува, но е празен скрипт:

#!/bin/sh

return 0

Резервното копие (export_cfg) е просто uci export, а /etc/config е на постоянен overlay. Тоест uci commit е записът. Проверихме с рестарт: настройката остана disabled, odhcpd не тръгна, делегациите изчезнаха. Остатъчният риск е firmware ъпгрейд, който да върне фабричните стойности — това не е проверено.

Бонусът. Lease файлът на odhcpd (/tmp/hosts/odhcpd) пази DUID и IAID на всеки клиент, получил префикс. Форматът се потвърди срещу двама клиенти с известен IAID — и от него взехме IAID 6 за клиента, при когото нито 2, нито 1 ставаха.

Неканен гост №2: IGMP querier от транзитен VLAN

Следващият клиент беше вързан направо на разпределителен комутатор — без радио и без ONU. Пак: заявките излизат, нищо не се връща. Разпределителният комутатор пропускаше всичко (unknown-multicast-flood=yes на всички портове), а между него и ядрото имаше само оптично влакно. Отговорът беше в bridge monitor на ядрото:

/interface bridge monitor bridge1
  multicast-router: no
      igmp-querier: sfp-sfpplus6 192.168.99.3
       mld-querier: none

Ядрото е конфигурирано като querier на домейна (multicast-querier=yes). Но querier се оказа чуждо устройство — оборудване на горен доставчик, пращащо IGMPv2 general query в един от неговите транзитни VLAN-и, които носим през нашите комутатори:

xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:01, vlan 2xxx, 192.168.99.3 > 224.0.0.1: igmp query v2

В избора за querier печели по-ниският IP адрес и загубилият млъква. RouterOS прави този избор за целия bridge, а не за всеки VLAN поотделно. Така querier от чужд транзитен VLAN беше потиснал нашия и в клиентските VLAN-и, в които самият той изобщо не присъства. Последствията: портът към него стана multicast-router, IPv6 групите спряха да се учат, а mdb таблицата на ядрото намаля почти три пъти спрямо замер отпреди месец.

Как го отрязахме

Мястото е границата — портът, през който доставчикът влиза в мрежата. Там сложихме хардуерно ACL правило, което изхвърля само IGMP пакетите от този адрес. Интернет трафикът и BGP сесиите не се засягат, а CPU-то на комутатора изобщо не участва:

/interface ethernet switch rule
add switch=switch1 ports=sfp-sfpplus1 mac-protocol=ip protocol=igmp \
    src-address=192.168.99.3/32 new-dst-ports="" \
    comment="drop foreign IGMP querier"

Проверката след това:

Какво	Резултат
BGP сесиите към доставчика	Established, uptime-ът не е прекъсвал.
Querier на комутаторите след ~5 минути	Чуждият адрес изчезна навсякъде.
NDP към клиентите зад трасето	От `failed` на `reachable` — и при клиента, заради когото търсихме, и при още едно устройство по същото трасе.
DHCPv6	След `release` клиентът е `bound`, пинг навън от LAN префикса без загуби.

Какво остава отворено. След като чуждият querier го няма, комутаторите не показват никакъв querier — нито нашето ядро. Предполагам, че ядрото праща заявките с изходен адрес 0.0.0.0, защото bridge-ът му няма IP (querier-uses-bridge-address=yes), и затова никой не ги признава. Не е проверено. Засяга и IPTV-то в целия домейн, така че е отделна задача — докато не е решена, радиата пред IPv6 клиентите се нуждаят от unknown-multicast-flood=yes.

Чеклист: преди да пуснете IPv6 на бизнес клиент

Проверка	Защо — какво показа практиката
`use-interface-duid=yes` на WAN порта	Иначе DUID-ът е от друг порт и може да сочи към друг договор (част 1).
Истинският IAID в binding-а	При грешен IAID сървърът отговаря `NoPrefixAvail`; не се чете от конфигурацията (част 2).
`pool-prefix-length=64` + `release`	68 по подразбиране чупи LAN адресите на 7.24; `renew` не пресъздава pool-а (част 2).
NDP от граничния рутер към неизползван link-local зад клиента	Най-бързият тест дали multicast минава по пътя (част 3).
Радиата по пътя	`igmp-snooping=yes` + `unknown-multicast-flood=no` без querier реже NDP и DHCPv6 (част 3).
Моделът на ONU-то	Зад чужди ONU-та IPv6 prefix delegation не тръгна (част 3).
Чужди DHCPv6/RA сървъри в клиентския VLAN	Дори ваше устройство с фабрична настройка може да раздава префикси и default route. Проверете `dhcp-server-v6` на клиента; на access комутаторите помислете за DHCPv6 snooping и RA guard.
`igmp-querier` на всички комутатори	Querier от транзитен VLAN потиска вашия в целия bridge.
IPv6 firewall за `forward` на клиентския рутер	По IPv4 LAN-ът е скрит зад NAT. По IPv6 NAT няма — без правила във `forward` вътрешните мрежи са достъпни отвън. Повечето клиентски рутери, които видяхме, нямаха нито едно IPv6 правило.

Самото раздаване на префикси се оказа най-лесната част. Всичко останало беше L2 — неща, които по IPv4 работят с години и никой не ги поглежда, защото ARP ползва broadcast, а не multicast. IPv6 ги изкарва на светло.

Всички части от поредицата

Част 1: /60 за всеки клиент и връзката с IPv4 билинга — как граничният рутер раздава префикси, DNS през DHCPv6 и защо не по MAC
Част 2: IAID, pool 68 и заклещеният NDP — капаните в клиентския рутер
Част 3: Когато IPv6 се губи по пътя — радиа с IGMP snooping без querier и ONU-та, през които не минава
Част 4: Два неканени гости — DHCPv6 в мениджмънта на радиолинк, IGMP querier от чужд VLAN и чеклист