Причины расхождения показаний разделил на три группы:
1. Подсчет
2. Сбор и хранение
3. Отображение
1. Подсчет
Начну с главной причины расхождения и которую чаще всего упускают.
1. Инженеры часто считают, что минимальный размер «пакета» 64 Байт.
2. Сетевое оборудование по-разному считает количество переданной информации.
Истоки заблуждений и ответы находятся на этой картинке.
1.1 RTFM
Напомню структуру заголовков Ethernet
Для примера будем делать расчеты для 10 GbE. Через 10 GbE интерфейс максимум проходит 10000000000 бит (10^10).
Переведем размеры заголовков из октетов в биты
bytes | bits | |
---|---|---|
L1 Header size | 20 | 160 |
L2 MAC Header size | 14 | 112 |
L2 FCS size | 4 | 32 |
L2 VLAN size | 4 | 32 |
Payload min | 46 | 368 |
Payload max | 1500 | 12000 |
Total | ||
Min payload w/o VLAN | 84 | 672 |
Min payload w VLAN | 88 | 704 |
Max payload w/o VLAN | 1538 | 12304 |
Max payload w VLAN | 1542 | 12336 |
* Применение оверлейных технологий на транспортной сети влияет на исходный размер PDU, что уменьшает максимальный pps.
** Для примера взял VLAN. Обработка фрейма с vlan ID на сетевых интерфейсах может различаться. Одни увеличивают MTU, другие уменьшают допустимый максимальный размер payload.
Рассчитаем максимальную и минимальную скорость в PDU в секунду при полной утилизации интерфейса (wirespeed)
Max pps | 14880952.38 |
Max pps w VLAN | 14204545.45 |
Min pps | 812743.8231 |
Min pps w VLAN | 810635.5383 |
Т.е. через 10 GbE интерфейс максимум проходит ~14,88 Mpps. Для простоты запоминания называем зигапакетом.
Еще обращу внимание, что max pps и min pps различаются больше, чем в 18 раз. По этой причине, рассматривая antiDDoS решения, нужно обращать внимание на производительность в Mpps. Часто вендора заявляют производительность в Gbps, умалчивая в пакетах. Описание методик оценки производительности систем защиты тема для отдельной большой статьи.
1.2 Особенности подсчета размера PDU
Сетевое оборудование может считать размер PDU на разных уровнях и исключать поля из подсчета. Частые наборы полей для подсчета:
- L2 Data или IP packet len
- L2 Data + MAC Header
- L2 Data + MAC Header + FCS (CRC Checksum)
Теперь рассчитаем показания на графике при атаке TCP SYN Flood на wirespeed без и c использованием vlan.
PDU size (bytes) |
Gbps Multiplier | ||
---|---|---|---|
109 | 230 | ||
Pps w/o vlan = 14880952.38 | |||
L1 | 84 | 10 | 9.313225746 |
L2 | 64 | 7.619047619 | 7.095791045 |
L2 w/o FCS | 60 | 7.142857143 | 6.652304104 |
L2 Data (IP+TCP) | 40 | 4.761904762 | 4.434869403 |
Pps w vlan = 14204545.45 | |||
L1 | 88 | 10 | 9.313225746 |
L2 | 68 | 7.727272727 | 7.196583531 |
L2 w/o FCS | 64 | 7.272727273 | 6.773255088 |
L2 Data (IP+TCP) | 40 | 4.545454545 | 4.23328443 |
Вот так при полной утилизации 10 GbE интерфейса на графике можно наблюдать скорость в 4,43 Gbps.
Поэтому при сравнениях значений скорости в разных системах нужно понимать, как считается размер PDU. Для упрощения сравнения мы для себя сделали калькулятор, показывающий скорость при подсчете разных заголовков.
Следующие две другие группы причин влияют на сглаживание пиков и применимы для всех графиков скорости.
2. Сбор и хранение
2.1 Частота опроса счетчика
Обычно опрашиваются счетчики показывающие абсолютное значение обработанных байт и пакетов. Для отображения скорости нужно посчитать производную.
Точность графика сильно зависит от частоты опроса счетчика. Чем реже, тем больше усреднение. Например, у операторов принято снимать значения раз в пять минут. Поэтому при Pulse Wave DDoS attacks профили графиков в системе мониторинга и системе фильтрации будут сильно отличаться.
2.2 Консолидация данных (Retention policy)
Часто для хранения значений счетчиков принят подход циклических баз данных (rrd). В целях экономии ресурсов данные за разный период хранятся с разной точностью. Чем дальше в прошлое, тем более разреженные значения, тем больше усреднение.
В разных системах может быть разный retention policy, поэтому ретроспективно просматривая графики можно наблюдать разные значения.
3. Отображение
3.1 Количество точек на графике
Обычно на графике есть ограничение на количество показываемых точек. Если за запрошенный период точек больше, то при отображении точки консолидируют. Чаще всего соседние точки консолидируют в одну со среднем значением. Такое усреднение сглаживает пики.
Наглядный пример:
3.2 Двоичные приставки
Дополнительное расхождение показаний добавляют инструменты отрисовки графиков. Для графиков в битах могут использовать различные степени для отображения одинаковой приставки. Подробней можно почитать ru.wikipedia.org/wiki/Двоичные_приставки
3.3 Единицы измерения
В основном счетчики на сетевом оборудовании показывают количество обработанной информации в байтах. Если не конвертировать, то график будет показывать скорость в Bps (байты в секунду), а не в bps (биты в секунду).
Заключение
Графики — полезный и информативный инструмент. Взглянув на правильно составленный набор графиков, можно быстро найти ответы на множество вопросов. Но при работе с графиками нужно понимать нюансы, особенно при коррелировании графиков из разных систем. Поэтому первый раз взглянув на график, выясните:
- что и как собирается;
- как хранится;
- как отображается.
Комментарии (7)
lexxxef
25.02.2019 22:21А может кто-нибудь объяснить, в чем практический смысл использования урезанного размера PDU (из п.1.2), например, «L2 Data или IP packet len»? Могу понять это на уровне, скажем, шлюза с разной физикой по разные стороны, где полный объем трафика получается разным м разных сторон; а вот применительно к, например, ethernet-маршрутизатору как-то непонятно, зачем такое делать.
gleb4inka Автор
26.02.2019 15:38Коммутаторы и маршрутизаторы не считают по L2 Data.
Такой подсчет встречается у более специализированных устройств. Когда в pipeline обрабатывается уже содержимое на следующем уровне стека.
Например, summary график mitigation из Arbor TMS при TCP SYN Flood
Если смотреть на графики, то метрики атаки ~105 Kpps ~33,7 Mbps
Обычно при SYN Flood размеры IP Headres = 20Bytes и TCP Headers = 20 Bytes, в сумме 40 Bytes.
Расчеты на калькуляторe (линк с установленными значениями) показывают, что подсчет идет на L3 уровне. На физическом уровне использование линка 70,56 Mbps.
По-видимому, в этом случае можно будет наблюдать ситуацию, когда 10 GbE линк забит, а на графике всего 4,76 Gbps (сейчас не проверял).
gleb4inka Автор
26.02.2019 16:35В статье не упомянул два случая, когда графики по-настоящему врут.
1. Для подсчета количества обработанных байт используется 32-х битный счетчик.
На больших скоростях счетчик переполняется между замерами, и на график ставится точка сильно ниже реальной.
2. Для телеметрии использую *flow протоколы со семплированием. Т.е. в подсчет попадают не все пакеты, а один из n.
- Собранные данные изначально уже являются неточными.
- Может быть расхождение в коэффициентах семплирования на сенсоре и коллекторе.
- При DDoS-атаке количество flow возрастает. Вследствие этого в сети управления увеличивается количество UDP трафика с телеметрией. Дальше для спасения сети управления часть UDP срезается, либо теряется на забитом линке. В итоге на коллекторе неполная информация, а графики не отображают действительность.
Ghool
26.02.2019 19:58А что по поводу случаев, когда графики завышают значения?
У меня такая ситуация:
Трафик идёт из точки А через маршрутизатор в точку Б
В точках А и Б показывается утилизация В 300 мегабит, а на маршрутизаторе 400-500Ghool
26.02.2019 19:59Пардон, не через маршрутизатор, а через балансировщик. Соответственно, точка Б — это не один сервер, распределение трафика балансёром на несколько серверов
gleb4inka Автор
26.02.2019 20:19Думаю, что на балансировщике и на A, Б считается трафик на разных уровнях.
Как (инструмент) и с чего (счетчик) снимаются показатели скорости на A и Б?
Укажите поточней значения в момент времени на балансировщике и на А, Б.
YetAnotherSlava
Мы должны защитить само существование сетевой связности и будущее для инфраструктурных сервисов.