Главная Кабели Локации Мониторинг Исследования Инструкция
← Все статьи
Страна

1969 мс до Раротонги: неделя перегрузки на кабеле Manatua

В ранние часы 11 апреля 2026 года один-единственный ICMP-ответ от Раротонги шёл до нашего сервера в Минске 1968 миллисекунд. В четыре утра того же дня тот же ответ пришёл за 443. К двум часам дня сеть вернулась к своему скучному baseline в 440 мс и сделала вид, что ничего не было.

Это не одиночный инцидент. Восемь дней подряд пять наших измерительных пробов — в Минске, Тбилиси, Иерусалиме, Севастополе и Алматы — наблюдают, как связность до Островов Кука волнами распадается. Наш монитор кабелей всё это время рапортует кабель Manatua — единственный подводный линк на всю страну из пятнадцати островов — здоровым. Обе эти вещи одновременно правдивы, и статья про то, что это значит.

Что мы замеряли

Каждые девяносто минут каждый из наших пробов прогоняет полный traceroute к одному IP-адресу: 202.90.64.1, пограничный маршрутизатор внутри сети Telecom Cook Islands. За двадцать дней до 3 апреля базовый round-trip из Европы или Кавказа до этого адреса держался на 430–490 миллисекундах, стабильно, с джиттером в несколько миллисекунд. Это физическая реальность маршрутизации IP-пакета от Минска до маленького тихоокеанского острова: Европа → транзит GTT через Атлантику → Лос-Анджелес → Papeete по цепочке кабелей Honotua и Manatua → последний отрезок внутри абонентской сети Островов Кука. Около 450 мс туда-обратно, каждый раз.

Потом хвост распределения стал толстым.

Дата (UTC)ИзмеренийСпайки >800 мсСпайки >1500 мсТаймауты
2026-04-0334100
2026-04-0440000
2026-04-0540000
2026-04-0640000
2026-04-0739310
2026-04-0838104
2026-04-0940000
2026-04-1051002
2026-04-116910511

Первый спайк мы записали 3 апреля — одно измерение из Тбилиси вернулось с 973 мс вместо обычных 440. Любопытство. Через четыре дня, 7 апреля, три спайка в одном и том же вечернем окне, один из них достиг 1928 мс из Иерусалима. 8 апреля — четвёртый спайк и четыре таймаута ближе к концу дня. Затем три спокойных дня: 9 и 10 апреля выглядели как baseline. А потом случилось 11 апреля.

Максимум RTT до Островов Кука по дням, мс 0 500 1000 1500 2000 baseline ~440 мс 973 1928 1135 1969 3 апр 4 5 6 7 8 9 10 11 апр Пять пробов, одна цель 202.90.64.1 (Telecom Cook Islands). Baseline 2026-03-22 … 2026-04-02: максимум не превышал 490 мс.

11 апреля, час за часом

Восемь дней нарастающей tail latency сжались в один день. Самое плохое пришлось на два штормовых окна — одно посреди ночи, другое около семи утра UTC — а между ними сеть выглядела абсолютно нормально.

Час UTCМинскТбилисиИерусалимСевастопольАлматы
00htimeout1327timeout960timeout
01h112616459201033timeout
02h1969469timeout445470
04h443460503457timeout
07h186915405351811timeout
10h485437462450462
14h443440439470467
20h458440456498464

Все значения — round-trip в миллисекундах до 202.90.64.1. Жирным выделены значения выше 800 мс. Пять пробов в пяти разных странах, и в штормовые окна четверо из них одновременно согласились, что что-то не так. Это исключает локальную проблему конкретного проба — это не наш минский сервер в плохом настроении, это не флап тбилисского ISP. Единственный способ для четырёх евразийских пробов одновременно увидеть один и тот же паттерн — это проблема где-то после их первого общего хопа, а этот общий хоп находится в пятнадцати тысячах километрах и одном подводном кабеле отсюда.

Алматы показывает другой паттерн — восемь таймаутов из четырнадцати измерений за день, но без спайков. У него уже около недели есть отдельная проблема с ICMP-достижимостью до этой конкретной цели, и мы считаем её отдельным случаем, исключая из анализа спайков.

Тот же маршрут, другая задержка

Самый полезный traceroute, который мы поймали, — тот, что стоит за цифрой 1969 мс. Вот как он выглядит. А вот как выглядел тот же проб двадцатью часами ранее, в спокойный день.

10 апреля, Минск → Острова Кука — 466 мс (baseline)

ХопМестоположениеASN · ОператорRTT
1Private LAN1.5 мс
4Минск BYAS12406 Business Network2.7 мс
7Москва RUAS12389 Rostelecom14.6 мс
8Вена ATAS9002 RETN22.1 мс
9Стокгольм SEAS3257 GTT78.1 мс
10Лос-Анджелес USAS3257 GTT209.8 мс
11Papeete PFAS3257 GTT301.9 мс
12–14(таймаут)
15Faaa PFAS9471 Onati454.0 мс← ответ цели

11 апреля, 02:59 UTC, Минск → Острова Кука — 1969 мс (спайк)

ХопМестоположениеASN · ОператорRTT
1Private LAN1.0 мс
4Минск BYAS12406 Business Network2.1 мс
7Таллин EEAS9002 RETN6.0 мс
8Вена ATAS9002 RETN76.5 мс
9Вена ATAS3257 GTT63.6 мс
10Лос-Анджелес USAS3257 GTT225.4 мс
11Papeete PFAS3257 GTT304.4 мс← транзит по кабелю В НОРМЕ
12–18(таймаут)
19Faaa PFAS9471 Onati1968.9 мс← ответ цели, +1515 мс к baseline

До 11-го хопа два трейсроута почти неотличимы. Путь чуть разный — RETN выбрал таллинский ingress в одном и московский в другом — но профиль задержек идентичен: Минск → Вена → Лос-Анджелес → Papeete, с приходом в 302 мс в хороший день и 304 мс в плохой. Если бы сам Manatua транзит деградировал или если бы тихоокеанский бэкбон GTT притормозил, мы бы увидели это здесь. Мы не видим. Транзит по кабелю был нормальным в оба дня.

Расхождение начинается после Papeete. В нормальный день три промежуточных хопа молчат, а цель отвечает на 454 мс — чистые +150 мс на последний сегмент, примерно то, что ожидаешь для фиброволокна Papeete → Раротонга плюс пара устройств абонентской сети. В плохой день — семь молчащих хопов, и цель отвечает на 1969 мс, +1665 мс хвоста, которому нет физического оправдания. Тот же IP, тот же кабель, тот же транзит, тот же последний хоп. Другой день.

Чтобы убедиться, что это не чисто минский сюжет, вот спайк из Иерусалима от 7 апреля, 21:00 UTC, 1928 мс:

ХопМестоположениеASN · ОператорRTT
1Private LAN0.8 мс
5Иерусалим ILAS1680 Cellcom164.7 мс
7Франкфурт DEAS1299 Arelion55.4 мс
11Лос-Анджелес USAS3257 GTT199.4 мс
12Papeete PFAS3257 GTT294.4 мс← транзит по кабелю В НОРМЕ
13–16(таймаут)
17Faaa PFAS9471 Onati1927.7 мс← ответ цели, +1633 мс к baseline

Другая страна-источник, другой евразийский ISP, другой транзитный бэкбон (Arelion вместо RETN на пути в LA). Одна и та же сигнатура. Хвост живёт где-то между Papeete и конечной целью, и он сделан не из оптоволокна.

Где живут 1650 мс задержки, если они не сделаны из расстояния?

Физическое расстояние от Papeete до Раротонги по кабелю Manatua — примерно 1150 км. Свет в оптоволокне движется со скоростью около 200 000 км/с — две трети от скорости света в вакууме из-за коэффициента преломления волокна. Путь фотона в одну сторону на 1150 км занимает 5,75 мс, в обе — 11,5 мс. Прибавь обработку пакета на каждом маршрутизаторе, немного очереди в тихий день — и получишь те 150 мс, которые мы реально видели 10 апреля между Papeete и целью. Это в пределах нормального overhead для сети малого острова, где локальный бэкбон собран из commodity-свитчей, а агрегированный линк к внешнему миру — это не 400 Гбит/с.

Чего физика объяснить не может — это 1665 мс. Это почти в сто раз больше, чем бюджет скорости света для того же пути. Нет на Земле оптоволокна, достаточно медленного, чтобы это произвести. Это не расстояние. Это не обрыв кабеля. Это очередь.

Учебный термин — buffer bloat. Когда сетевой линк насыщается — слишком много трафика, слишком мало пропускной способности, или и то и другое — пакеты не дропаются. Они ждут в очереди на выходе маршрутизатора своей очереди на передачу. Если очередь большая (мегабайт или два, что совершенно обычно для commodity-железа), а линк медленный (несколько сотен мегабит), пакет, попавший в конец полной очереди, может просидеть там полторы секунды, прежде чем его передадут. В конце концов он приходит целым и невредимым. Просто очень долго. TCP congestion control не был рассчитан на это: он реагирует на потери, не на задержки, так что эффективно не откатывается, а очередь продолжает оставаться полной. Задержка сворачивается в самоподдерживающийся туман.

11 апреля очередь заполнилась дважды. Около 01:00 UTC и снова около 07:00 UTC. Между двумя штормами трафик оттекал, и измерения возвращались к baseline. К 10 утра хвост исчез. Если недельный тренд продолжится — а один изолированный спайк, за которым идут кластер из трёх, а потом стена из десяти, — это тренд, — нам следует ждать ещё одного окна 12 апреля и ещё одного 13-го.

А кабель тем временем здоров

Наша система мониторинга кабелей проверяет здоровье Manatua независимо. Каждые несколько часов она пингует endpoint в landing point напрямую через кабель и фиксирует round-trip и отношение к baseline. Вот то же самое временное окно с её точки зрения:

ДатаManatua avg RTTBaselineОтношениеАномалии
2026-04-11436 мс409 мс1,070
2026-04-10426 мс409 мс1,040
2026-04-09551 мс0
2026-04-08427 мс408 мс1,050
2026-04-07400 мс409 мс0,980
2026-04-06404 мс409 мс0,990

SELECT * FROM cable_alerts WHERE cable_id='manatua' — ноль строк за всё окно. Мы ни разу не подняли предупреждение по кабелю Manatua ни в одном из штормовых окон. И формально мы были правы: кабель передавал пакеты, всё у него было в порядке, со скоростью почти как вчера. Проблема жила в другом месте.

Этот разрыв стоит назвать вслух. Когда мониторинг на уровне кабеля пингует landing point, он проверяет фиброволокно и пограничный маршрутизатор на другом его конце. Но он не проверяет бэкбон оператора, ни upstream peering, ни абонентское оборудование, ни QoS-политику, ни буфер интерфейса, который сейчас, возможно, в четыре раза больше, чем должен быть. В большинстве здоровых, хорошо спроектированных сетей это не имеет значения — подводный кабель там самое узкое и чаще всего ломающееся звено в пути, так что тест именно его — справедливый прокси для всего пути. На одиночнокабельном острове — нет. Всё между Papeete и пользователем на Раротонге — это backhaul одного маленького оператора, и этот backhaul невидим для ping-теста, который останавливается на границе кабеля.

Острова Кука в цифрах

Пятнадцать островов, около 17 500 жителей, бóльшая часть на Раротонге. Один подводный кабель — Manatua, 3634 километра, в эксплуатации с 2020 года, посадки на Раротонге и Аитутаки, далее продолжается в Ниуэ, Самоа, Бора-Бора и Papeete. До Manatua международная связность страны обеспечивалась спутниками O3b, которые в хороший день давали около 700 мс задержки, а в плохой — несколько этих значений. Один национальный оператор, Telecom Cook Islands, что на практике означает тот самый /24, в который мы упрямо целимся нашими трейсроутами. Одно транзитное отношение upstream, видимое в каждом нашем трейсроуте: AS9471 Onati, из Papeete.

Альтернативного пути нет. Если Manatua падает, Острова Кука откатываются на спутник. Если Telecom Cook Islands неправильно сконфигурирует очередь на своём uplink, несколько мегабайт пакетов нарастают в буфере за час и остаются там до утра. Нет второго поставщика, через которого можно было бы маршрутизироваться в обход, нет конкурирующего бэкбона для failover. Вот так в 2026 году выглядят single points of failure на практике.

Ничего из этого не является критикой оператора. Вести национального ISP на 17 000 абонентов, разбросанных по пятнадцати островам, — настоящий инженерный подвиг, а Manatua стала самым важным инфраструктурным событием в современной истории Островов Кука. Это реальность связности малых островов. Когда что-то идёт не так, оно идёт не так в точке, где нет резервирования — потому что именно там нет резервирования.

Что это говорит о том, как мы мониторим кабели

Мы не поймали эту неделю. Наша собственная система, мониторинг здоровья кабелей, всё время показывала Manatua чистым. Она говорила нам, что кабель здоров, и она говорила правду. Это был просто не тот вопрос.

Правильный вопрос для страны с единственным кабелем — не «передаёт ли кабель пакеты», а «может ли пакет дойти от внешнего мира до абонентского endpoint и вернуться за разумное время». Это два разных измерения с разными режимами отказа, и зазор между ними — это ровно то место, где живёт инцидент этой недели. Правильная стратегия мониторинга Тихого океана нуждается в обоих: cable-level здоровье (оно у нас есть) и country-level endpoint здоровье (которого у нас пока нет в нужном для таких паттернов разрешении).

Мы это починим. Малые островные страны с единственным коммерческим оператором — Острова Кука, Ниуэ, Токелау, Тувалу, Науру, Кирибати и ещё несколько — заслуживают отдельного мониторинга на уровне endpoint, потому что у них есть режимы отказа, которые их кабели не умеют выражать. Если бы такой мониторинг был у нас две недели назад, мы бы пометили выброс 3 апреля, кластер 7-го и окно 8-го как нарастающий тренд — и входили бы в 11 апреля ожидая его, а не обнаруживая его в утреннем отчёте.

Что вообще это вызывает?

Честно — мы не знаем.

Что мы видим снаружи: кабель Manatua в порядке, транзит GTT из Европы в Papeete в порядке, проблема где-то после 11-го хопа внутри сети Onati и Telecom Cook Islands, и она проявляется как паттерн задержки в очереди, согласующийся с buffer bloat на насыщенном линке. Чего мы не видим: является ли это насыщение проблемой capacity planning (абоненты наконец переросли uplink), частичной деградацией фиброволокна на тихоокеанском сегменте, которая снизила эффективную полосу вдвое, изменением маршрутизации, которое направило больше трафика в одну трубу, неправильно настроенным буфером интерфейса, peering-спором или чем-то ещё целиком. На такие вопросы можно ответить только изнутри сети оператора — а внутри мы не находимся.

Что мы можем сказать с уверенностью — оно ухудшается. Один спайк 3 апреля. Три — 7-го. Десять — 11-го. Каждая волна больше предыдущей; каждый большой спайк ближе к потолку в 2000 мс, где уже ломается сам TCP. Если тренд сохранится — а восемь дней данных, четыре штормовых окна и упорядоченная последовательность — это тренд — нашу следующую публикацию мы напишем про 13 или 14 апреля, не только про 11-е.

Попробуйте сами

Живые измерения к этой цели публикуются на странице маршрутов — они обновляются по мере поступления новых трейсроутов, и если описанный здесь паттерн продолжится, график это покажет. Также можно прочитать baseline-историю, которая эти измерения подготовила: как чистый round trip до Островов Кука оказывается равным 462 мс в первую очередь. И у самого кабеля есть страница: Manatua, 3634 км тихоокеанского бэкбона, который с 2020 года остаётся единственной волоконно-оптической связью между Островами Кука и остальным миром.

Мы опубликуем follow-up, когда увидим, что принесут 12 и 13 апреля.

Evgeny K.
Автор
Evgeny K.
Инженер инфраструктуры · Основатель GeoCables
Построил GeoCables для мониторинга подводных кабелей в реальном времени. Использует собственную сеть из 4 серверов с пробами RIPE Atlas в Минске, Алматы, Тбилиси и Иерусалиме.

🌐 Log In

Access your routes, favorites, and API key

Create account Forgot password?