Comments 7
Мы должны защитить само существование сетевой связности и будущее для инфраструктурных сервисов.
А может кто-нибудь объяснить, в чем практический смысл использования урезанного размера PDU (из п.1.2), например, «L2 Data или IP packet len»? Могу понять это на уровне, скажем, шлюза с разной физикой по разные стороны, где полный объем трафика получается разным м разных сторон; а вот применительно к, например, ethernet-маршрутизатору как-то непонятно, зачем такое делать.
Коммутаторы и маршрутизаторы не считают по 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 (сейчас не проверял).
Такой подсчет встречается у более специализированных устройств. Когда в 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 (сейчас не проверял).
В статье не упомянул два случая, когда графики по-настоящему врут.
1. Для подсчета количества обработанных байт используется 32-х битный счетчик.
На больших скоростях счетчик переполняется между замерами, и на график ставится точка сильно ниже реальной.
2. Для телеметрии использую *flow протоколы со семплированием. Т.е. в подсчет попадают не все пакеты, а один из n.
1. Для подсчета количества обработанных байт используется 32-х битный счетчик.
На больших скоростях счетчик переполняется между замерами, и на график ставится точка сильно ниже реальной.
2. Для телеметрии использую *flow протоколы со семплированием. Т.е. в подсчет попадают не все пакеты, а один из n.
- Собранные данные изначально уже являются неточными.
- Может быть расхождение в коэффициентах семплирования на сенсоре и коллекторе.
- При DDoS-атаке количество flow возрастает. Вследствие этого в сети управления увеличивается количество UDP трафика с телеметрией. Дальше для спасения сети управления часть UDP срезается, либо теряется на забитом линке. В итоге на коллекторе неполная информация, а графики не отображают действительность.
А что по поводу случаев, когда графики завышают значения?
У меня такая ситуация:
Трафик идёт из точки А через маршрутизатор в точку Б
В точках А и Б показывается утилизация В 300 мегабит, а на маршрутизаторе 400-500
У меня такая ситуация:
Трафик идёт из точки А через маршрутизатор в точку Б
В точках А и Б показывается утилизация В 300 мегабит, а на маршрутизаторе 400-500
Пардон, не через маршрутизатор, а через балансировщик. Соответственно, точка Б — это не один сервер, распределение трафика балансёром на несколько серверов
Думаю, что на балансировщике и на A, Б считается трафик на разных уровнях.
Как (инструмент) и с чего (счетчик) снимаются показатели скорости на A и Б?
Укажите поточней значения в момент времени на балансировщике и на А, Б.
Как (инструмент) и с чего (счетчик) снимаются показатели скорости на A и Б?
Укажите поточней значения в момент времени на балансировщике и на А, Б.
Sign up to leave a comment.
Почему графики трафика «врут»