IPv6 prefix delegation в реална ISP мрежа (част 3): Когато IPv6 се губи по пътя
Дотук в поредицата
В първа част — схемата с
/60на клиент и връзката с билинга. Във втора — капаните в клиентския рутер: IAID,pool-prefix-lengthи заклещеният NDP. Тук са клиентите, при които конфигурацията беше наред, а IPv6 пак не тръгваше.
Симптомът: заявките излизат, нищо не се връща
Картината беше една и съща при няколко клиента:
- DHCPv6 клиентът е
searching..., в лога няма дориcouldn't acquire prefix— отговор не идва изобщо; - на граничния рутер binding-ът е
last-seen=never; - граничният рутер не открива клиента по NDP (
failed); - IPv4 работи, а в MNDP съседите клиентът се вижда нормално, включително с IPv6 link-local адреса си.
Методът: къде точно се губи пакетът
| Стъпка | Какво дава |
|---|---|
| Запис на всички IPv6 пакети на WAN порта на клиента, ~40 s | Кое излиза и кое влиза. При проблемните клиенти: DHCPv6 solicit навън, MNDP навън — и нито един входящ IPv6 пакет. |
| Пинг от граничния рутер към неизползван link-local зад клиента | Гарантира пресен NS пакет към нова solicited-node група. Ако в записа на клиента не се появи — NS-ът се губи по пътя. |
| MAC → порт на комутатора → PON порт → ONU | Сравнение на пътя на работещите и неработещите клиенти. |
Защо към неизползван адрес. Ако записът в
/ipv6 neighborвече еfailed, рутерът може да не прати нов NS веднага. Тогава „в записа няма NS“ не доказва нищо. Пинг към адрес, който никой не носи, винаги тръгва като NS към нова група.
Радиата: IGMP snooping без querier
Първите случаи бяха зад радиолинкове — MikroTik SXT в bridge режим. На всички имаше една и съща комбинация:
/interface bridge set bridge1 igmp-snooping=yes multicast-querier=no /interface bridge port set [find] unknown-multicast-flood=no /interface bridge monitor bridge1 igmp-querier: none mld-querier: none
igmp-snooping в RouterOS покрива и MLD за IPv6. Щом querier няма, никой не пита за групи, групите не се регистрират и mdb таблицата остава празна. А с unknown-multicast-flood=no всичко нерегистрирано се изхвърля. Точно такива са пакетите, от които зависи IPv6 prefix delegation:
| Група | За какво е и какво става |
|---|---|
ff02::1:ffXX:XXXX |
Solicited-node — NS пакетите на NDP. Изхвърлят се → рутерът не открива клиента. |
ff02::1:2 |
Всички DHCPv6 сървъри — solicit-ът на клиента. Изхвърля се → сървърът не вижда заявката. |
ff02::1 |
Всички възли — минава. По нея върви и IPv6 частта на MNDP. |
Точно затова MNDP подвежда: съседът се вижда с IPv6 link-local адрес и изглежда, че IPv6 по пътя е наред. Не е — минава само
ff02::1, а NDP и DHCPv6 ползват други групи.
Поправката, която избрахме за конкретното радио, е най-тясната възможна — snooping-ът остава (във VLAN-а има IPTV multicast), пуска се само флуд на нерегистрираното:
/interface bridge port set [find] unknown-multicast-flood=yes
Резултатът при клиента зад това радио: граничният рутер го открива по NDP, след release DHCPv6 клиентът е bound, пинг навън от LAN префикса минава без загуби. Правилната дългосрочна поправка е работещ querier в домейна — за нея в четвърта част.
ONU-то, при което и това не стигна
При друг клиент същата промяна на радиата помогна само наполовина: DHCPv6 заявката вече излизаше от радиото към оптичния терминал, но граничният рутер пак не я виждаше. А NS пакетите от рутера не стигаха дори до радиото.
Пътят мина през EPON: клиентът, още двама от проблемните и общо 28 MAC адреса бяха зад едно и също ONU — 8-портово, захранващо цял безжичен възел. На същия PON порт имаше и клиент, при когото IPv6 работеше. Сравних настройките на двете ONU-та в OLT-то — идентични: същият VLAN режим, същият mc_switch snooping, същата празна таблица с групи. Разликата беше в самото устройство:
| ONU | Vendor / чип | IPv6 NDP/DHCPv6 през него |
|---|---|---|
| VSOL D401 / D701 (7 проверени) | 0x038C / 0x9125 | ✅ работи |
| 8-портово ONU без марка | 0x4353 / 0x8032 | ❌ не работи |
| ONU с Broadcom (модел 1160) | 0x0479 / 0x9607 | ❌ не работи |
Двете неработещи ONU-та бяха чужди, всичките работещи — VSOL. Това е силна зависимост, но не е 100% доказателство — не съм сменял ONU, за да видя дали проблемът изчезва. Решението засега: клиентите зад такива ONU-та остават без IPv6, а тестовите промени по радиата пред тях върнахме.
! OLT (VSOL), в режим configure terminal interface epon 0/3 show onu 2 ctc onu_info show onu 2 ctc mc_switch show running-config onu 2
Оттогава преди да добавя binding за нов клиент, проверявам и модела на ONU-то пред него. Ако не е от проверените — първо смяна на ONU, после IPv6.
В последната част: два „неканени гости“ в собствената ни мрежа — DHCPv6 сървър в мениджмънта на радиолинк, който раздаваше префикси на наши клиенти, и IGMP querier от транзитен VLAN на доставчик, заради който IPv6 спря да минава през цяло оптично трасе.
Всички части от поредицата
- Част 1: /60 за всеки клиент и връзката с IPv4 билинга — как граничният рутер раздава префикси, DNS през DHCPv6 и защо не по MAC
- Част 2: IAID, pool 68 и заклещеният NDP — капаните в клиентския рутер
- Част 3: Когато IPv6 се губи по пътя — радиа с IGMP snooping без querier и ONU-та, през които не минава
- Част 4: Два неканени гости — DHCPv6 в мениджмънта на радиолинк, IGMP querier от чужд VLAN и чеклист