Кратко

  • Anja Feldmann и ещё пять исследователей описали потребность как объём, поступивший через один вход и направленный к множеству возможных выходов. Это отделило предложенный трафик от пути, выбранного текущей конфигурацией.
  • На магистрали AT&T команда свела NetFlow, таблицы пересылки, конфигурации маршрутизаторов и контрольные данные SNMP; потери при сборе, устаревшие снимки и несколько возможных входов не маскировались под однозначное измерение.

Красный канал на карте сети выглядит как готовый диагноз. Известна точка, известен процент загрузки. Но его счётчик не отвечает, какие потребности создали сумму. Тем более он не скажет, исчезнет ли перегрузка после смены веса OSPF или появится на соседнем участке.

Совместная работа Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold, Jennifer Rexford и Fred True началась именно с этого ограничения. Матрица трафика не находилась целиком ни в одном маршрутизаторе. Её приходилось выводить из нескольких наборов данных, чьи поля, часы и области видимости не совпадали.

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

Потребность не обязана иметь единственный выход

Матрица для каждой пары адресов получилась бы огромной. Кроме того, отдельный провайдер не видел весь путь: значительная часть трафика пересекала несколько административных доменов, а оператор наблюдал лишь собственный участок.

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

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

Временной масштаб также подчинялся задаче. Для управления трафиком важны десятки минут, часы и дни, а не порядок каждого пакета. Записи потоков распределялись по интервалам и объединялись по входу и множеству выходов. Целью было не воспроизвести разговоры, а сохранить структуру, влияющую на сетевое решение.

Чем меньше точек измерения, тем важнее границы вывода

В идеале данные потоков собирались бы на каждом входе. Запись давала интерфейс, адрес назначения, начало, окончание и число байтов. Таблица пересылки связывала префикс с выходами. Конфигурации сообщали имена и типы каналов, ёмкость, фильтры и параметры OSPF. Модель маршрутов проверяла допустимый путь.

На рабочей магистрали AT&T подробный сбор нельзя было включить на всех клиентских подключениях. Одни маршрутизаторы не поддерживали функцию, на других она создавала чрезмерную нагрузку. Поэтому наблюдение сосредоточили на пиринговых каналах, где более мощное оборудование обслуживало большую долю межоператорского трафика.

Компромисс породил три известных пробела. Внутренний трафик между клиентскими входами мог не касаться пиринга. Исходящий поток наблюдался при выходе, а его первоначальный вход оставался неизвестным. Многоузловой транзит фиксировался и на входе, и на выходе, поэтому вторую запись требовалось исключить.

Для исходящего потока адрес источника указывал на один или несколько возможных клиентских входов. Затем модель для каждого кандидата проверяла: мог ли путь при сохранённых топологии и конфигурации прийти к тому пиринговому интерфейсу, где поток действительно наблюдался? Невозможные варианты отбрасывались.

Иногда оставался один вход, иногда несколько, иногда ни одного. При нескольких кандидатах объём распределялся, а не получал выдуманный уникальный источник. Матрица тем самым различала наблюдаемый выход, однозначно выведенный вход, неразрешённое множество и противоречие со снимком.

Измерительный поток способен потерять девять пакетов из десяти

NetFlow отправлял записи по UDP на сервер сбора. В периоды высокой нагрузки на ведущем к нему канале терялось до 90 процентов экспортных пакетов. Полученная серия не выглядела сломанной: она продолжала естественно колебаться, но показывала неверный масштаб. Правдоподобная неполнота опаснее явного отсутствия данных.

Номера последовательности позволили увидеть разрывы. Их распределение согласовывалось с приближением независимых потерь. Команда оценивала вероятность по десятиминутным интервалам и применяла поправку к полученным потокам. Это не восстанавливало каждую пропавшую запись; неполная выборка расширялась при явно заданном статистическом допущении.

Независимую проверку дали интерфейсные счётчики SNMP с пятиминутным шагом. После поправки загрузка, вычисленная из NetFlow, относительно близко следовала кривой SNMP. Сам SNMP не раскрывал связи входов и выходов, зато мог оспорить реконструкцию, если её сумма не совпадала с измерением канала.

При сведении требовалось согласовать идентичность и время. NetFlow называл интерфейсы числовыми индексами SNMP, а конфигурации и таблицы — именами и адресами. Часы некоторых интерфейсных карт расходились с процессором маршрутизации. Источники снимались в разные часы. Без осторожности из правильных строк можно было собрать состояние, которого никогда не существовало.

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

Покрытие объёма не равно уверенности в происхождении

В четырёх экспериментах ноября 1999 года более 98 процентов байтов на пиринговых каналах обычно удавалось отнести к некоторой форме потребности. Для более чем 99,3 процента исходящих байтов находился хотя бы один вход-кандидат. Однако сначала примерно 35–45 процентов исходящего объёма имело несколько возможных входов.

Модель маршрутов устранила часть вариантов. Примерно от четверти до трети неоднозначного объёма в разных опытах свелось к одному входу. Резервные подключения клиента в одном городе часто оставались неразличимыми и проходили по сходным внутренним путям. После процедуры около 2,5–4 процентов исходящих байтов всё ещё не соответствовало ни одной допустимой потребности.

Эти величины относятся к четырём дням одной сети 1999 года и не являются современным ориентиром. Важно другое: почти полное покрытие не означает уникальной атрибуции. А малая доля остатка может приходиться именно на моменты изменения достижимости.

Анализ показал концентрацию объёма в небольшом числе крупных потребностей, сильную зависимость от времени суток и некоторую устойчивость лидеров на соседних днях. Это делало выборочное измерение привлекательным. Но если крупные потоки сходились на одних каналах, ошибка настройки или смена поведения одного источника получала крупный сетевой эффект.

Матрица сильна тем, что хранит условия своей истинности

Исследовательский профиль Feldmann соединяет анализ трафика, моделирование и маршрутизацию, потому что в этой задаче они проверяли друг друга. Измерение без маршрута описывало только следствие. Маршрут без измеренного спроса переносил воображаемые объёмы. Конфигурация без времени точно объясняла сеть, которой уже могло не быть.

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

Для современной наблюдаемости требование не стало проще. Нужно хранить сырой счётчик вместе с версией маршрутов и конфигурации, потерями при сборе, соответствием интерфейсов, неразрешёнными кандидатами и независимой проверкой. Красный канал показывает место боли. Проверяемая цепочка показывает, не перенесёт ли лечение боль в другое место.

Источники