Зачем этот трек

Построить сеть — половина работы. Вторая половина начинается, когда приходит заявка «медленно», «моргает», «не открывается». В этот момент инженер обязан не рассуждать, а измерить — и предъявить результат смежникам так, чтобы его нельзя было оспорить.

Проблема в том, что все четыре базовых инструмента — ping, traceroute, проверка MTU и iperf3 — легко дают уверенно выглядящий неверный ответ. Пинг до транзитного маршрутизатора показывает потери, которых нет у трафика. Трассировка обрывается там, где всё исправно. Канал «не даёт скорость», хотя дело в окне TCP на самом хосте. Этот трек — про то, как отличить измерение от самообмана.

Как устроен трек

Порядок строгий, и он совпадает с порядком реального измерения:

Такой порядок — не вкусовщина. RFC 6349 прямо требует сначала проверить MTU пути и снять базовый RTT, и только потом измерять пропускную способность TCP.

Что понадобится
Литература и первоисточники трека
Что дальше

После измерений остаётся самая ценная часть ремесла — поиск причины периодических, а не постоянных отказов: почему на несколько секунд падает BFD или IS-IS, почему это повторяется по расписанию и как поймать то, чего нет в момент проверки. Этот материал сейчас в работе; следи за страницей направления.