Таблица маршрутов

Traceroute измеряет не то, как быстро пакет проходит через маршрутизатор, а то, как быстро маршрутизатор отвечает сообщением ICMP Time Exceeded. Транзитный трафик он пересылает аппаратно и почти не замечает. Ответ для traceroute собирает центральный процессор, с низким приоритетом и ограничением частоты. Занятый маршрутизатор может отвечать медленно или не отвечать вовсе, отсюда строки * * *, и при этом исправно пересылать трафик дальше.

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

Вместо одиночного замера лучше взять mtr. Он шлёт пробы непрерывно и показывает статистику по каждому хопу за минуты, а не за три попытки.

mtr -rwc 200 example.com

Чтобы не фрагментировать пакеты, отправитель ставит флаг DF и полагается на Path MTU Discovery. Если на пути встречается участок с меньшим MTU (туннель, PPPoE с его 1492 байтами), маршрутизатор отбрасывает слишком большой пакет и сообщает об этом через ICMP: Fragmentation Needed в IPv4 или Packet Too Big в IPv6.

Беда начинается, когда файрвол где-то по дороге режет весь ICMP «для безопасности». Отправитель так и не узнаёт, что пакет не пролез, и продолжает слать большие пакеты в пустоту. Мелкие запросы проходят, соединение устанавливается, а на первом полноразмерном сегменте всё замирает.

Лечится это тремя способами: не блокировать нужные типы ICMP, ограничивать MSS на маршрутизаторе перед узким участком или полагаться на PLPMTUD (RFC 4821), который подбирает размер пробами без помощи ICMP. Проверить путь вручную можно так: 1472 байта данных плюс 28 байт заголовков дают ровно 1500.

ping -M do -s 1472 example.com

CUBIC, алгоритм по умолчанию в Linux, ориентируется на потери. Он наращивает окно, пока пакеты не начнут теряться, затем сбрасывает скорость и начинает снова. На канале с глубокими буферами очередь из-за этого постоянно заполнена и задержка растёт. На канале со случайными потерями, как в Wi-Fi, CUBIC принимает каждую потерю за перегрузку и тормозит без причины.

BBR строит модель пути: оценивает пропускную способность узкого места и минимальное время прохождения, а затем отправляет данные ровно с этой скоростью. Очереди остаются короткими, а случайные потери почти не сбивают его с толку. Цена в честности: первая версия BBR в одном канале с CUBIC нередко забирала больше своей доли.

Алгоритм выбирает отправитель, поэтому для скачиваний важен тот, что стоит на сервере. Включается двумя параметрами:

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

При anycast один и тот же префикс анонсируется по BGP сразу из многих мест. Каждый маршрутизатор выбирает лучший для себя путь, и запрос приходит в ту точку присутствия, которая ближе, но ближе по правилам BGP, а не по карте. Обычно это совпадает с географией, но не всегда.

Корневых серверов DNS тринадцать, от a.root-servers.net до m.root-servers.net, а за этими именами стоят больше тысячи экземпляров по всему миру. DNS-запрос — это один UDP-пакет туда и один обратно, поэтому ему безразлично, в какой экземпляр он попал.

Длинным TCP-соединениям anycast подходит хуже: если маршрут перестроится посреди сессии, пакеты уйдут в другой экземпляр, который о соединении ничего не знает. На практике это случается редко, и anycast давно используют и для HTTPS.

Адрес IPv6 делится пополам: 64 бита префикса сети и 64 бита идентификатора интерфейса. На этой границе построен SLAAC: устройство получает префикс из объявления маршрутизатора и само дописывает вторую половину. Префикс длиннее /64 ломает SLAAC, а Android, например, не получает адреса по DHCPv6, так что в такой сети он останется без IPv6.

Поэтому один /64 на весь дом — плохой подарок от провайдера: его нельзя поделить на гостевую сеть и основную. Нормой считается выдавать абоненту /56 или /48. Исключение составляют соединения точка-точка между маршрутизаторами, там уместна /127 (RFC 6164).

Когда до одного префикса известно несколько маршрутов, BGP сравнивает их по цепочке критериев и останавливается на первом, где они различаются. Упрощённо порядок такой: наибольший local preference, самый короткий AS-path, тип происхождения маршрута, наименьший MED, внешние маршруты раньше внутренних, наименьшая IGP-метрика до следующего хопа и, наконец, самый старый маршрут или наименьший router ID.

Главное здесь то, что local preference стоит выше длины пути. Если оператор решил пускать трафик через более дешёвый транзит, он поднимет local preference, и маршрут с коротким AS-path проиграет. Поэтому AS-path prepending влияет только на тех, кто сам ничего не настраивал.