В первой части серии мы прошлись взглядом по типичным схемам сетей Ethernet и различным ситуациям при захвате трафика. Поэтому в текущей статье (и во всех последующих!) я буду считать, что вы ознакомились с предыдущими частями. Сегодня давайте обсудим, в каком случае скорость интерфейса и режим дуплекса становятся очень важны, и что такое эти «дропы».

Скорость и дуплекс

Есть 2 режима дуплекса, которые можно встретить при работе с сетью Ethernet:

1. Полудуплекс, также известный как «HDX», «Half Duplex». Он означает, что только один передатчик может отправлять данные в определенный момент времени, иначе возникнут проблемы (они же «коллизии»).
2. Полный дуплекс («Full duplex», «FDX»). В этом режиме возможна двусторонняя коммуникация, то есть и передача, и прием возможны одновременно.

Ну так и что же случится, если одна сторона работает в режиме FDX, а вторая всего лишь в HDX? Ничего хорошего. Узел, который использует FDX, будет думать, что он спокойно может передавать данные когда только пожелает, не понимая, что это вызовет коллизию, если вдруг случится так, что HDX-сосед как раз в этот момент отправляет что-то свое. Называется такая ситуация «duplex mismatch». Что в результате? Скорость передачи упадет до совсем печального уровня (уточним: это считанные килобайты в секунду вместо мегабайтов в секунду на линке в 100 Мбит/с).

Интересный факт 1: Автосогласование

Иногда люди думают, что “10/100 автосогласование” на одной стороне окажется достаточно разумным алгоритмом, чтобы распознать параметры второй стороны, настроенной вручную. Типа: «так, я поставлю на одной стороне 100 Мбит/с + полный дуплекс самостоятельно, а вторая сторона должна это увидеть и подстроиться». Давайте рассмотрим это на примере. Сторона номер 1 (обычно коммутатор) настроена принудительно на “100/полный дуплекс”, сторона номер 2 (обычно ПК) – выставлена на “автосогласование”. Что получится? Правильно, несоответствие, именно этот duplex mismatch:

Почему так происходит? Сторона 2 (ПК, настроенный в “авто”), сообщает: «я могу 10Мбит/с полудуплекс; 10Мбит/с полный дуплекс; 100Мбит/с полудуплекс; 100Мбит/с полный дуплекс». Ну, то есть, перечисляет все свои возможные режимы. А что говорит сторона 1 – коммутатор? А вообще ничего, он же настроен жестко. Из-за этого ПК, который ничего не слышит, на всякий случай переходит в режим полудуплекса (предполагает худшее). И это ещё хорошо, что скорость он все же может обнаружить и все-таки выставит себе 100Мбит/с, а иначе мы бы получили полный сбой соединения – стороны с несогласованной скоростью порта не могут общаться вообще никак!

Поэтому существует такое правило: ставим или обе стороны на авто, или обе вручную! По крайней мере, так было, пока не вышла спецификация 1Гбит/с  (IEEE 802.3z), которая содержит небольшое, но важное предписание сообщать о параметрах, даже если узел настроен статически вручную.

По этой причине в последнее время, когда все стали переходить на гигабит и больше, количество проблем с duplex mismatch пошло на убыль.

Интересный факт 2: Полудуплекс на гигабите!

Да, есть такой стандарт: 1Гбит/с, полудуплекс. Ходят слухи, что инженеры (естественно, зная, что полудуплекс – дело прошлого) все равно должны были описать этот режим, чтобы стандарт формально остался в группе 802.3. Которая называется «CSMA-CD», и где CD означает «Collision Detection», а для этого Collision Detection нужен полудуплекс, иначе откуда там взяться коллизиям?  🙂

Что? Опять про дуплекс?

Могу себе представить, что некоторые читатели, снова смотря на главу про полный/полудуплекс, скажут: «чувак, об этом надо было помнить лет 10-15 назад, но сейчас? Сейчас все на полном дуплексе!» Ну, во-первых, этот цикл создавался для начинающих. А, во-вторых, давайте зададим простой, но важный вопрос более знающим читателям:

Сможете ли вы захватить полностью загруженный гигабитный полнодуплексный канал, используя один такой же полнодуплексный порт гигабитной сетевой карты?

И ответ… нет, не сможете.

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

Ну так что это означает, если мы говорим про гигабитный полнодуплексный канал? 1 гигабит в секунду на прием и 1 гигабит в секудну на отправку (а совсем не 500Мбит/с на прием и 500Мбит/с на отправку, как часто неправильно думают мои ученики на курсах по Wireshark). Итого, когда мы говорим про полнодуплексный гигабитный канал, по факту мы имеем дело с общей скоростью передачи 2 гигабита в секунду (да-да, конечно, если он полностью загружен). То же относится и к 10Гбит FDX – это по сути 20Гбит. 25Гбит означает 50Гбит, 40 означает 80, 100 означает 200, если мы имеем дело с полным дуплексом.

Но все же, и почему мы не сможем захватить такой канал одним портом гигабитной карты? Она же тоже полнодуплексная, правда?

Оно-то так, но карта захвата может только получать трафик, но не отправлять (точнее, не должна бы отправлять, или, по моему мнению, не должна отправлять ни в коем случае). Итак, скорость карты захвата на передачу нам становится полностью неважна и бесполезна. И все, что нас интересует – это скорость карты захвата на прием, а она равна 1 Гбит/с. Выходит, что такой карты мало, для того, чтобы захватить полнодуплексный гигабитный загруженный канал. Потому что он будет иметь в сумме скорость 2 Гбит/с. А мы сможем принять из них только 1 Гбит/с. Нам придется с этим столкнуться ещё позже, но если уже сейчас вы подумали «вот же…», то вы на правильном пути.

Захватываем преамбулу и протокол автосогласования

Захватить преамбулу и делимитер Ethernet-кадра, которые передаются перед самим кадром, практически невозможно. Может, удастся их увидеть на экране осциллографа в медленной сети (10Мбит/с), или получится захватить коллизию (смотрите в предыдущей статье).

А причина в том факте, что сетевая карта передает компьютеру только сами кадры. Ей незачем передавать также всякие служебные вещи, которые происходят где-то в проводах, потому что попросту эти вещи никому кроме самой сетевой карты не нужны и никакого смысла загружать ими ПК нет. Если все-таки очень хочется увидеть эти данные, понадобится как минимум специализированная (читайте: профессиональная и очень дорогая) карта захвата. Никакая обычная потребительская сетевая карта не позволит этого сделать.

Если вы обладатель профессиональной карты захвата совместно с TAP, то вы как минимум сможете захватить импульсы протокола автосогласования, как на рисунке ниже (это только часть, ещё многое происходит позже, но, как видите, эта часть происходит как раз перед переходом в состояние “link up”). Захватывался этот дамп на специализированном устройстве Network General S6040 в комбинации с полнодуплексным оптическим ТАР:

«Дропы»

«Дроп», он же «отброшенный пакет» – это пакет, который по факту был в сети и должен был быть захвачен, но не захватился. Разница «потерянного» (lost) и «отброшенного» (drop) пакетов в том, что потерянный пакет пропал где-то в сети (то есть, на входе нашего порта его уже не было), и в случае, если у нас ТСР, то такой пакет будет переотправлен заново отправителем. Если же пакет не захватился, в дампе отсутствует, но в сети он был, дошел до получателя и никуда по пути не пропал – то это «дроп» То есть отбросили его мы. Примерно ситуация с дропами выглядит так:

Пример дропов в дампе

Если вы видите в Wireshark сообщение “TCP ACKed unseen segment” (это сообщение генерируется модулем-анализатором ТСР) – это верный признак дропов при захвате: Wireshark видит, что в дампе присутствует ACK (подтверждение) для какого-то пакета данных, а вот самого пакета не видит. Так как узел, участвующий в обмене данными, подтвердил прием, следовательно, пакет с данными дошел до получателя нормально. Просто этот пакет с данными не добрался до нас, до самого Wireshark’а. Всего две основных причины могут быть связаны с этим:

1. Дропы. Производительность устройства захвата была недостаточной, чтобы обработать весь входящий поток без потерь.
2. Асинхронный маршрут. Случается так, что загруженные пакеты с данными идут к получателю одним путем, в то время, как АСК-подтверждения от получателя возвращаются по другому маршруту, на котором вы не захватываете трафик. В этой ситуации пропавшие пакеты не являются дропами, ведь мы их не отбрасывали. Это легко заметить по тому признаку, что у вас в итоге получается «односторонний дамп», и вы вообще не видите обратного потока.

Но все же больше, чем в  95% случаев причиной “недолета” пакетов является первая – было недостаточно производительности устройства захвата. Кстати, ещё один признак дропов – это сообщения “TCP Previous segment not captured”, после которых нет переотправленных пакетов с данными. Подумайте об этом.

Причины дропов

Возможны несколько причин, но все они попадают в категорию «ваше устройство захвата было недостаточно быстро, чтобы захватить весь трафик без потерь». Дропы могут возникнуть по вине коммутатора, ответвителя ТАР, сетевой карты, жесткого диска и даже ЦП или памяти вашего ПК (к примеру, если ваш софт недостаточно оптимизирован). Подведем итог: всё, что угодно, – любое устройство или схема – которые находятся между пакетом в проводе и диском, куда пишется дамп, может стать причиной дропов. Что-то из этого виновато чаще, что-то реже. (Дорогие производители ТАР, следите за своим давлением, мы будем рассматривать ТАР позже, и тогда же уточним, почему дропы могут возникнуть и здесь).

В зависимости от ситуации, дропы могут иметь разную степень критичности.

Критичные дропы

Считаются таковыми, если вам нужна полная информация, и вы не можете себе позволить ни одного потерянного пакета. Зачастую это касается задач сетевой безопасности, когда необходима реконструкция контента, переданного по сети. Если у вас пропал один или несколько пакетов, которые были частью переданного вредоносного файла – вы уже не сможете этот файл полностью восстановить, и его реверс-инжиниринг будет невозможен (или как минимум затруднен).

В другой ситуации у вас может быть задача исследовать причину потерь пакетов – и дропы приведут вас к ложным выводам, просто потому, что вы думали, что пакет был потерян в сети (packet loss), а на самом деле он дропнулся на вашем устройстве захвата. (В случае с ТСР об этом хотя бы косвенно можно догадаться, как написано выше. А вот UDP и другие уже не дадут таких подсказок. – прим. перев.)

Некритичные дропы

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

Как пример можно взять анализ ТСР-соединения, которое страдает от симптома «низкая производительность (bad performance)». Здесь аналитик сможет пережить редкие дропы, потому что он видит, что TCP ACK на эти «как бы потерянные» пакеты есть, а значит, эти пакеты потеряли мы сами.

В обратном случае (исследование места реальных потерь пакетов в сети, packet loss), где задача – найти сбойное сетевое устройство, вызывающее потери, вы не можете себе позволить дропы, потому что они исказят всю картину. Вы можете быть не в состоянии разграничить, был ли этот пакет реально потерян кем-то другим, или виновник – вы же сами.

Несущественные дропы

Дропы становятся несущественными, если аналитику и так не нужен был каждый пакет. Например, если он делает снимок характеристик трафика в сети (baselining). Если просто нужно собрать некоторую статистику сети (например, распределение протоколов, «какой процент от всех пакетов у нас НТТР?»), вы можете запросто пережить дропы. Они особо не повлияют на конечный результат (ну, конечно, если у вас их не огромное количество)  🙂

Заключение

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

Что стоит вынести из данной статьи:

– дропы могут быть как большой проблемой, так и не очень;

– полный дуплекс – это скорость больше, чем она кажется на первый взгляд, и если канал загружен, а у вас карта захвата только с одним портом…

Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net 

Использование материала статьи без согласования запрещено! 

Оригинал статьи находится по адресу: https://blog.packet-foo.com/2016/10/the-network-capture-playbook-part-2-speed-duplex-and-drops/

This article has been translated and published with author’s (Jasper Bongertz) permission. For packettrain.net website only!

Original article can be found at: https://blog.packet-foo.com/2016/10/the-network-capture-playbook-part-2-speed-duplex-and-drops/