[Перевод] IPv6 у миллиона абонентов: как домашние роутеры устроили провайдеру шторм DHCPv6

Семь лет IPoE-доступа в Непале и авария, которая научила нас большему, чем любая лаборатория.

Переход с IPv4 на IPv6 обычно подают как обновление протокола. В лаборатории так оно примерно и есть: включаете семейство адресов, анонсируете префикс, пингуете что-нибудь и идёте дальше.

В боевой сети широкополосного доступа это не обновление протокола. Это проект по управлению абонентами, проект по совместимости абонентского оборудования (CPE), проект второго уровня, проект по логированию и проект по наблюдаемости, а IPv6 просто вскрывает все пять разом.

В WorldLink Communications мы начали испытывать IPv6 в мае 2016 года, а в июле 2019-го запустили его в работу. Сегодня у нас больше миллиона абонентов на IPoE (IP over Ethernet), у всех 100% включён IPv6, и примерно 70% трафика идёт по IPv6.

Здесь то, чему мы научились за это время. Отчасти это архитектура. Но больше шрамы.

Почему IPoE и почему dual-stack

Классический широкополосный доступ работал на PPPoE (Point-to-Point Protocol over Ethernet). IPoE убирает PPP-сессию: CPE просто запрашивает адрес по DHCP, а шлюз широкополосного доступа (Broadband Network Gateway, BNG) узнаёт абонента по тому, что сеть доступа прикрепила к запросу: circuit-ID и remote-ID из Option 82, VLAN, MAC. Политики поверх этого выдаёт RADIUS.

Абоненту так проще, а масштабировать дешевле. Но есть следствие, которое обычно недооценивают:

Никакого PPP keepalive нет. Сессия — это и есть аренда DHCP и DHCPv6.

Запомните это. Из этого вытекает половина статьи.

Что до двойного стека: мы смотрели на трансляцию и инкапсуляцию, но выбрали dual-stack, потому что только он не ставил транслятор на пути каждого клиента навсегда. Исчерпание IPv4 и так толкало нас к операторскому NAT (Carrier-Grade NAT, CGNAT), а CGNAT — это капитальные затраты, которые растут с каждым новым абонентом: железо, сессии, блоки портов и юридическая обязанность всё это логировать.

У нативного IPv6 ничего этого нет. Каждый пакет, который мы переводим на IPv6, CGNAT уже никогда не придётся обрабатывать.

Рисунок 1. Архитектура dual-stack: IPv4 и IPv6 — две отдельные плоскости сервиса и пересылки поверх одной абонентской сессии

Главное на рисунке 1: IPv4 и IPv6 — две независимые плоскости пересылки и сервиса, которым просто досталась одна абонентская сессия. Начнёте считать их одним целым — рано или поздно и отлаживать будете как одно целое, а там диагностика и умирает.

План адресации и единственное число, которое я бы поменял

Мы получили от APNIC блок /32 и разметили его вполне традиционно (таблица 1).

Таблица 1. План адресации IPv6 в сети WorldLink

Рисунок 2. Пример иерархии распределения IPv6-адресов: магистраль, инфраструктура, WAN и делегирование префиксов клиентам

Последнюю строку таблицы я бы и поменял.

Делегированный /64 даёт клиенту ровно одну рабочую LAN. Ни гостевой сети, ни отдельного сегмента под IoT, ни VLAN за роутером, ни запаса на то, что ему понадобится через пять лет. При этом в одном /32 помещается 16,7 миллиона /56, так что экономия здесь не даёт ничего, что вы когда-нибудь потратите.

Если бы я планировал сеть сегодня, я бы делегировал /56, в самом крайнем случае /60, а бизнес-клиентам /48. Всё преимущество IPv6 в том, что не нужно изощряться, экономя адреса. Обращаться с ним как с IPv4 — значит выбросить единственное, что он даёт бесплатно.

DHCPv6 — это не DHCPv4 с длинными адресами

Именно здесь у большинства dual-stack-внедрений начинаются боли, так что разберём механику точно.

Четыре объекта, которые вы будете видеть в дампах трафика до конца карьеры:

• DUID (DHCP Unique Identifier) — идентификатор клиента. Не MAC и не IP.

• IA_NA (Identity Association for Non-temporary Addresses) — адрес /128 на WAN-интерфейсе CPE.

• IA_PD (Identity Association for Prefix Delegation) — префикс, делегированный в LAN клиента.

• ORO (Option Request Option) — запрос опций: Option 23 — список DNS-серверов, Option 24 — список доменов поиска.

Рисунок 3. Модель сервиса DHCPv6: связь DUID клиента, выдачи адреса IA_NA, делегирования префикса IA_PD и согласования опций в обмене SARR

Обмен идёт по схеме Solicit, Advertise, Request, Reply (SARR). Клиенты на UDP-порту 546, серверы на 547, и всё это через мультикаст. За BNG стоит RADIUS и выдаёт Framed-IPv6-Pool, имя пула для делегирования и профиль ограничения скорости.

А ещё есть T1 и T2. По T1 клиент продлевает аренду у знакомого ему сервера. По T2 он сдаётся и перепривязывается (rebind) к любому, кто ответит. Когда аренда наконец истекает, клиент выбрасывает всё и начинает заново с SOLICIT.

Вот в этом последнем предложении и вся авария.

Обрыв между renew и rebind

На рисунке 4 реальная последовательность из нашей сети. Выше терминала оптической линии (Optical Line Terminal, OLT) рвётся волокно, но BNG ничего об этом не узнаёт: для него абонент по-прежнему вполне себе привязан.

Рисунок 4. Жизненный цикл аренды DHCPv6 при потере связи: попытки renew и rebind, истечение аренды и повторное установление сессии

На T1 CPE пытается продлить аренду. Тишина. На T2 пытается перепривязаться. Тишина. По истечении аренды CPE бросает адрес и префикс и шлёт новый SOLICIT.

И тут производители CPE перестают соглашаться друг с другом.

По RFC 3315 клиент отправляет один SOLICIT с одним идентификатором транзакции, в котором лежат обе IA. BNG видит одного клиента, который заново договаривается, и чисто восстанавливает сессию.

RFC 8415 разрешает клиенту вести отдельный конечный автомат на каждую IA. Тогда он шлёт один SOLICIT с идентификатором транзакции (XID) 1 для IA_NA и другой с XID 2 для IA_PD. Теперь BNG видит двух клиентов. Ни один из обменов не завершается, потому что ни один запрос не просит сессию целиком.

Дальше включаются таймеры повторной отправки, а старое состояние никто не чистит.

Мы намерили 116 SOLICIT за минуту от одного CPE. Если перенести это всего на 10% абонентов BNG на 80 000 подписчиков, выходит примерно 15 467 SOLICIT в секунду. При таком темпе счётчик нарушений control plane по DHCPv6 не обнулится. Ни сегодня, ни когда-либо.

Эффект DBOR

DBOR (delete-binding-on-renegotiation, удаление привязки при повторном согласовании) велит BNG при SOLICIT от уже привязанного клиента снести существующую привязку и построить её заново. В DHCPv4 у этой функции есть веские причины. В DHCPv6, когда CPE выдаёт новые XID для SOLICIT как ему вздумается, она делает то, что показано на рисунке 5.

Рисунок 5. Как DBOR влияет на абонентские сессии: преждевременное удаление привязки может приводить к затяжным сбоям DHCPv6 и перерыву сервиса

Сессия клиента уничтожается и строится заново, и IPv4, и IPv6, а CPE об этом никто не сообщает. CPE продолжает пользоваться адресом и префиксом, которые у него уже были. При следующем продлении BNG отвечает статусами NoAddrAvail (2) и NoPrefixAvail (6). (В оригинале — «status code 13»: 13 — это номер самой опции Status Code в DHCPv6, а коды ошибок в ней — 2 и 6. — Прим. пер.) CPE пробует снова. И так по кругу.

Останавливается это только при отключении питания или обрыве волокна.

Как это выглядело из операторского зала:

• У каждого абонента, попавшего в эту петлю, IPv6 не было вообще.

• Карты CGNAT шли вразнос, потому что весь этот трафик откатывался на IPv4 через NAT.

• Колл-центр завалили жалобами, что тормозят Facebook и YouTube (никто никогда не звонит сообщить о проблеме с DHCPv6).

Немедленный обходной путь, который реально сработал: поставить клиенту роутер постарше, потому что старая прошивка ещё говорит по RFC 3315.

Переговоры с вендорами какое-то время ходили по кругу, и их общую форму стоит описать. Производитель CPE был прав: SOLICIT только с ORO допустим по RFC 8415, а ORO-23 и ORO-24 обязательны для соответствия IPv6-требованиям Broadband Forum (BBF). Производитель BNG тоже был прав: он и так возвращал обе опции в REPLY. Оба утверждения были верны. А у клиента по-прежнему не было IPv6.

Решением была не настройка, а договорённость. RFC 8415, раздел 18.1, а до него RFC 7550, раздел 4, оба говорят, что клиенту следует использовать одну транзакцию для всех IA на интерфейсе — именно для того, чтобы у клиента оставались одна сессия и один конечный автомат. В итоге наши рекомендации свелись к следующему.

На CPE:

• Не слать SOLICIT и REQUEST, в которых только ORO.

• Один конечный автомат на IA_NA, IA_PD и ORO.

• Один обмен для нескольких IA в SOLICIT, RENEW и REBIND.

• После неудачного rebind завершать старые процессы SOLICIT, прежде чем запускать новые.

• Повторять тот же XID, пока обмен SARR не завершится.

• Когда нужен сброс стека на стороне клиента, возвращать NoBinding вместо NoAddrAvail / NoPrefixAvail.

На BNG:

• Включить параметры ORO для Option 24, если платформа это поддерживает.

• Держать одинаковые таймеры аренды для IA_NA и IA_PD.

• Очень хорошо подумать, прежде чем вообще включать DBOR для DHCPv6.

А общий урок, который обошёлся нам дороже любой частности: в dual-stack IPoE нет keepalive. Сессию абонента держит вместе только состояние DHCP, сохранённое на весь срок аренды. Всё, что удаляет привязки из-под клиента, играет с самой сессией.

Большинство ранних сбоев были на втором уровне

Ещё до всего описанного выше у нас была проблема попроще: DHCPv6 работает через мультикаст, а нашу сеть доступа годами старательно настраивали так, чтобы мультикаст подавлять.

Рисунок 6. Типичные условия на втором уровне, мешающие работе IPv6: обработка мультикаста, поведение DHCPv6-relay, ограничения snooping и настройки сети доступа

На схеме шесть ловушек на пути CPE → ONU → OLT → коммутатор доступа → агрегация → BNG (каждый SOLICIT — мультикастовый кадр на ff02::1:2, MAC 33:33:00:01:00:02):

• Фильтры мультикастовых MAC (33:33:00:01:xx:xx → 33:33:ff:ff:ff:ff). Поставленные много лет назад против широковещательных штормов, они отбрасывают DHCPv6 ещё до выхода из коммутатора доступа. Снять их со всех портов, через которые идёт DHCPv6.

• Управление мультикастом по VLAN на OLT зависит от вендора и неединообразно: у одного включено по умолчанию, у другого надо включать явно. Ничего не предполагать, проверять для каждой платформы и каждого VLAN.

• MLD не включён на коммутаторах: без Multicast Listener Discovery у коммутатора нет причины пересылать группу на абонентский порт. Включать MLD везде, где проходит DHCPv6.

• Storm-control для мультикаста в pps — тихий ограничитель: порог на транковом порту спокойно задушит control plane во время массового переподключения. Исключить транки или поднять порог.

• Лимиты таблицы DHCPv6 snooping, например четыре записи на CPE. Отлично для диагностики, смертельно при 8000 абонентов на OLT: таблица перемалывается, и REPLY или ACK отбрасывается.

• Чужой DHCPv6 со стороны клиента (режим моста и U2U): клиентское устройство может отвечать на SOLICIT всего сегмента, если не включена изоляция в нисходящем направлении. Блокировать U2U и downstream в режиме моста.

Каждый из этих пунктов стоил нам реального времени, заметного клиентам. Snooping соблазнительнее всех, потому что DHCP snooping действительно помогает в диагностике — пока у вас не окажется 8000 абонентов на OLT с таблицей snooping на четыре записи на CPE. Массовое восстановление питания перемалывает таблицу, и OLT начинает отбрасывать DHCPv6-REPLY или DHCPv4-ACK по пути вниз. В итоге у вас простаивающие CPE и красивая, бесполезная база snooping.

Пусть OLT занимается только пересылкой и рейнджингом (измерением и выравниванием задержки до каждого ONU). Делайте snooping там, где на это хватает ресурсов.

Остальная эксплуатационная поверхность

То, что не заслужило отдельной истории, но вас всё равно найдёт.

Ограничение скорости в dual-stack. Одно значение полосы из RADIUS превращается в один динамический полисер и два набора фильтров: IPv4 вход/выход и IPv6 вход/выход. Ошибётесь — клиенты получат вдвое больше тарифа или вдвое меньше, смотря в какую сторону ошиблись.

Безопасность, потому что NAT никогда не был файрволом. Фильтрация bogon-префиксов в политике маршрутизации с аплинками. Фильтры control plane, пропускающие только инфраструктурные префиксы. Reverse Path Forwarding (RPF) на шлюзе. Заблокированные уязвимые порты. RA Guard и DHCPv6 Guard на уровне доступа. И неприятное: если вы даёте клиенту глобально маршрутизируемый префикс, файрвол его CPE становится несущей конструкцией, а IPv6-файрвол на CPE был, а местами и остаётся, заметно слабее аналога для IPv4.

Дыры в диагностике CPE. В IPv4 видно, какое устройство какую аренду получило. В IPv6 большинство бытовых CPE не скажут, у какого конечного устройства какой адрес. Многие к тому же до сих пор поставляются без IPv6-ping и traceroute в веб-интерфейсе. Если это не продумать заранее, поддержка отлаживает вслепую.

MTU из конца в конец. «Google открывается, а вот этот сайт нет» — это проблема MTU или Path MTU Discovery (PMTUD) куда чаще, чем что-либо ещё. Проверяйте реальный путь целиком: Ethernet, VLAN, MPLS, BNG, CGNAT. Число на странице статуса CPE ничего не доказывает.

Логирование CGNAT и сопоставление. Если 10.10.10.25:52341 превратился в 203.x.x.x:49122 в 12:31:45, вы должны суметь назвать абонента спустя месяцы. В большинстве юрисдикций этого требует закон.

Проектируйте под шторм переподключений. Вопрос никогда не «что будет, когда всё работает?», а «что будет, когда 100 000 абонентов переподключатся за одни и те же тридцать секунд после регионального отключения питания?». Инфраструктуре DHCP нужны горизонтальное масштабирование, резервирование, устойчивая база аренд и изоляция доменов отказа, рассчитанные именно на этот момент.

Сначала модель данных, потом дашборд

При миллионе сессий вопрос никогда не звучит как «что это за IP-адрес?». Он звучит как «какой абонент владел этим адресом в этот самый момент и что ещё было про него верно?».

У нас обычный стек: LibreNMS, Grafana, InfluxDB, Telegraf, NetBox, ELK и анализ потоков. Дело не в нём. Дело в сопоставлении — в одном ключе абонента, по которому можно связать любую другую систему.

Рисунок 7. Модель эксплуатационных данных вокруг абонента: адресация, аутентификация, логирование, мониторинг и метрики сервиса для диагностики в масштабе

Если на просьбу «покажи всё по этому абоненту» уходят пять систем и таблица в Excel, проблема не в сети. Проблема в модели данных.

Две вещи важнее выбора инструментов:

1. Мониторьте IPv4 и IPv6 как отдельные KPI, а не «интернет работает». Отдельно отслеживайте долю успешных DHCP и DHCPv6. Сбои делегирования префиксов измеряйте отдельной метрикой. С одной стороны следите за сессиями и портами CGNAT, с другой — за использованием IPv6-префиксов и достижимостью. Наш инцидент с DBOR был виден в счётчике нарушений DHCPv6 задолго до того, как появился в жалобах клиентов. Просто мы ещё не считали этот счётчик полноценным сигналом.

2. Рассчитывайте BNG по ресурсу, который кончится первым. Число абонентов из даташита тут плохой ориентир. Следите за сессиями IPv4 и IPv6, темпом транзакций DHCP и DHCPv6, состоянием Neighbor Discovery (ND) и ARP, записями FIB и RIB, пакетами в секунду и загрузкой control plane. BNG может работать на половине паспортной ёмкости по абонентам и всё равно упасть, потому что состояние neighbor discovery упёрлось в потолок.

Число, которое действительно важно

Когда мы запустились в 2019 году, у нас было около 100 000 абонентов с IPv6 из 290 000, и IPv6 только что перевалил за половину нашего трафика. Сегодня он включён у 100% абонентов и несёт примерно 70% трафика в сети, которая выросла больше чем втрое.

Эти два процента — числа разной природы, и вся история в разнице между ними.

Абонент с IPv6-адресом и сломанным делегированием префикса считается «включённым». Как и абонент за CPE, который ни разу не смог продлить аренду. Включённость — это то, во что верит ваша система провижининга. Трафик — это то, что произошло на самом деле. Байты не подделаешь, и каждый процент, перенесённый с IPv4 на IPv6, — это ёмкость CGNAT, которую не придётся покупать.

Поэтому не отчитывайтесь о внедрении IPv6 долей абонентов, у которых есть адрес. Отчитывайтесь долей трафика, который успешно по нему идёт. Первое число красивее на слайде. Второе говорит, работает ли это.

Что бы я сделал иначе

Наблюдаемость и автоматизацию — с первого дня, а не «второй фазой», которая так и не наступает. Всё из раздела про модель данных мы прикручивали задним числом, а встраивать сопоставление в живую сеть на миллион абонентов заметно труднее, чем заложить его при проектировании.

Лабораторию совместимости CPE до массового внедрения. Нужны те самые устройства, которые реально стоят у ваших клиентов, с теми прошивками, на которых они реально работают. Каждый сбой из разделов про обрыв renew–rebind и DBOR был сбоем поведения CPE, и лаборатория с двумя правильными роутерами поймала бы его за полдня.

Письменную договорённость о соответствии между вендорами CPE и BNG с указанием конкретного RFC — до того, как любая из коробок пойдёт в массовое развёртывание. «Обе стороны соответствуют стандарту» — не то же самое, что «обе стороны совместимы», и какой из двух случаев у вас, вы узнаёте в пятницу в восемь вечера.

И /56. Мы выбрали /64 из-за ограничений CPE.

Главное

Если после семи лет передавать тому, кто только начинает, что-то одно, то вот это:

• Внедрение IPv6 — в первую очередь не IPv6-проект. Протокол хорошо изучен и подробно документирован. Трудно всё, чего он касается: управление абонентами, DHCP, DHCPv6, RADIUS, BNG, CGNAT, прошивки CPE, второй уровень сети доступа, безопасность, логирование, мониторинг и поддержка, которой придётся объяснять всё это клиенту, который просто хочет, чтобы загрузился YouTube.

• IPv6 работает в масштабе крупного провайдера. Доказательство — миллион наших абонентов. Но работает он благодаря системе, построенной вокруг него. Одного включённого семейства адресов мало.

• Не измеряйте его числом абонентов с IPv6-адресом. Измеряйте объёмом реального трафика, который по нему успешно идёт.

Вот тогда IPv6 перестаёт быть проектом и становится частью сети.

Автор оригинала — Киджуш Махарджан (Kijush Maharjan), главный сетевой инженер WorldLink Communications, основатель и секретарь npNOG. Статья основана на эксплуатационном опыте WorldLink Communications (Непал); отдельные детали реализации обобщены из соображений конфиденциальности и безопасности.