На основе этой статьи была составлена и прочитана лекция на мероприятии "Академия НАГ 2025" от отдела коммутационного оборудования. В качестве иллюстраций к главам в статье будут представлены слайды презентации для мероприятия.
С чего начинается лечение проблемы
Кому-то тема диагностики и траблшутинга внушает страх, связанный с авариями, недосыпами, депримированием, кто-то находится на стадии гнева, отрицания, торга, депрессии, а кто-то уже пришёл к принятию того, что эта тема так или иначе коснётся его и, если инженер хочет быть специалистом своего дела, то должен владеть знаниями траблшутинга и диагностики различных технологий и протоколов.
С этим встречается как старший инженер, который траблшутит такие сложные вещи как OSPF, BGP, MPLS, PIM, так и младший инженер, который пока только выполняет кабельную диагностику, смотрит MAC'и на порту и разбирается, почему такой высокий пинг в "танках".
Каждый протокол и технология по-своему индивидуальны, и есть конкретные шаги по диагностике той или иной технологии. Если проблема с BGP, то Cisco предлагают большую инструкцию траблшутинга в виде конечного автомата, где вам задают вопросы и в зависимости от ответа алгоритм диагностики меняется.
Пример проще: если нет линка по витой паре до конечного клиента, то первым делом идём смотреть кабельную диагностику.
Но при всей этой индивидуальности выделяют алгоритм, который в общем описывает план работы с проблемой; подходы, которые задают начальную точку и путь поиска причины проблемы и которые помогают сузить зону поиска проблемы; а также инструменты, которые могут помочь в поиске и решении сетевой проблемы.
Глобальный алгоритм работы с проблемой
Новобранцы, специалисты с небольшим опытом встают в ступор, когда появляется проблема, с которой они ранее не сталкивались. Появляется вопрос: а с чего начать решение проблемы? Более конкретный пример: конечный пользователь не может получить реквизиты по DHCP. С чего начать диагностику? Может, с кабельной диагностики до конечного клиента? Или поискать проблему в DHCP Relay на районном HUAWEI'е? Инженерам, за чьей спиной годы опыта, иногда хватает одного взгляда на несколько симптомов проблемы, и они готовы выдвинуть гипотезы. Однако и они могут встать в ступор, когда проблема выходит за пределы их, хоть и большого, опыта.
Для этого я предлагаю ознакомиться с глобальным алгоритмом диагностики сетевых проблем:
- Анализ первичной информации
- Вход в цикл:
a. Выбор проблемной технологии
b. Выбор системы локализации проблемы
c. Составление опорных алгоритмов: показательный и фактический
d. Сравнение опорных алгоритмов
e. Зацикливание - Обоснование проблемы
- Поиск решения проблемы
- Формулировка проблемы и передача на уровень разработчиков
Анализ первичной информации
Для работы с клиентскими заявками команда инженеров моего отдела (отдел коммутационного оборудования) использует систему учёта заявок, построенную на Help Desk.
Заявки мы получаем в виде текстового сообщения с описанием проблемы; также клиенты могут прикреплять туда различные файлы и медиаматериалы.
Информация из тикета и является нашей первичной информацией. Чаще всего в заявке мы получаем:
- «симптомы» проблемы
- условия воспроизведения проблемы
- диагностическая информация, включающая в себя:
- выводы "show" с устройств
- дампы
- логи
Основной показатель, который отличает реально хорошо описанную первичную информацию от не очень хорошей, — это степень подробности и понятности описания заявки. Хорошая первичная информация также может включать в себя:
- Показательные Testcas'ы — это тесты, которые могут дать дополнительную информацию для диагностики. Например: клиент провёл два теста: в одном тесте проблема наблюдается, в другом — нет. Отличие в одной строчке конфигурации. Это даёт нам информацию о том, что проблема связана с конфигурацией данной технологии. Такой тип теста можно назвать сравнительным тестом (мы поговорим ещё о сравнительных принципах далее). Сами по себе тесты могут быть воспроизведены командой разработчиков для дальнейшего изучения
- Варианты временного решения – некоторые баги могут быть решены с помощью конфигурации. Например: удалить какую-то конфигурацию, и сеть начнёт функционировать корректно. Такая информация тоже помогает локализовать причину проблемы
- Статистические данные - данная информация говорит о массовости проблемы и может сказать о степени её важности. Например: клиент сообщил, что на сети 100 коммутаторов A проблема воспроизводится на коммутаторах с версией ПО Y, на остальных коммутаторах, находящихся в похожих условиях, версия ПО старее — X, и проблема не воспроизводится (это тоже сравнительный принцип, о котором мы поговорим далее). Делаем гипотезу, что повлияло изменение в ПО. Смотрим выполненные изменения между версиями X и Y, ищем пересечения в условиях воспроизведения проблемы и списке изменений ПО. Это пример программной проблемы. Таким же образом на основе статистической информации может быть сделана гипотеза об аппаратной неисправности или браке.
И на этом работа по сбору данных не прекращается. В течение всей диагностической работы предстоит уточнять и добывать информацию: и на этапе «Анализа первичной информации» вы можете решить, что данных мало, и запросить ту, которая поможет определить дальнейшие шаги алгоритма, и на этапе «Составления опорных алгоритмов», когда вам нужно знать, как работает фактический алгоритм, и на других этапах тоже.
Выбор проблемной технологии
В данном разделе предлагаем выяснить, с какой именно технологией или набором технологий возникла проблема. Этот шаг очень важен, т.к. определяет набор технологий, которые мы будем диагностировать в последующих шагах.
Как же сделать выбор этой технологии? Для этого выделяются несколько подходов:
- Точечный подход
- Диагностика по модели OSI сверху вниз
- Диагностика по модели OSI снизу вверх
- Сравнительный подход
- Опытный подход
Как выбрать нужный подход? Выбор подхода зависит от уже имеющейся первичной информации. Хорошая, подробная первичная информация подводит нас к первому подходу – точечному.
Точечный подход
Самый простой из подходов, и по статистике чаще всего применяемый. Мы его выбираем, когда признаки проблемы однозначно указывают на проблемную технологию. Обычно, когда приходят такие заявки, где требуется применить «точечный подход», клиенты сами обозначают технологию, с которой возникла проблема, или признаки проблемы ясно говорят о том, с какой технологией связана проблема.
Как результат применения этого подхода, мы выбираем технологию/пул технологий, которые берём к исследованию на следующий шаг.
Диагностика по модели OSI сверху вниз и снизу вверх
Подход по модели OSI сверху вниз описывает порядок избрания технологий для анализа, начиная с верхних уровней и заканчивая нижними уровнями. По сути, это последовательный перебор. При таком подходе инженер считает, что причина проблемы кроется на верхних уровнях, но не исключает, что она может быть и на нижних. Если причина проблемы не выявлена, инженер постепенно спускается до диагностики на нижних уровнях. Такой подход применяется не так часто, но и его приходится применять на деле.
Не отходя слишком далеко от предыдущего, переходим к подходу снизу вверх. Многие уже догадались, что это значит. Диагностика по модели снизу вверх означает, что под подозрение сначала попадают технологии нижних уровней, и последовательно под прицел попадают технологии выше и выше, пока не будет выявлена технология, содержащая ошибку.
Сравнительный подход
Представьте две системы, похожие друг на друга, как близнецы:
- Одинаковая конфигурация
- Одинаковые условия сети
- Одинаковая сетевая нагрузка и т.д.
И тут одна из переменных меняется: обновляется ПО, меняются условия работы сети или что-то другое. Это отличие даёт нам повод обратить внимание на изменения, проанализировать, какие условия поменялись и какой технологии они касаются. Данную технологию и будем брать в работу.
Пример из реальной практики: многофункциональные принтеры Kyocera были подключены к коммутатору HP, был доступ к печати и сканированию. Заменили коммутатор на SNR, применили аналогичные настройки. И принтеры перестали корректно работать. Из конфигурации я увидел, что коммутатор добавляет опцию 82. Чем ещё может отличаться поведение двух коммутаторов? Ничего примечательного в конфигурации не было, остальной трафик коммутировался просто как Ethernet-трафик — ничего сверхъестественного. Сравнили Опции 82 на обоих коммутаторах и оказалось, что опции 82 заполняются по-разному, и сервер DHCP выдавал разные данные, когда получал разные значения Опции 82.
Опытный подход
Подход, который, как не сложно догадаться, основывается на опыте работы, а также знаниях особенностей работы сетевого оборудования. В памяти инженера формируются связи между признаками проблемы, причинами и их решением. Это похоже на натренированность врачей: по неприметным признакам, которые другие даже могут не заметить, они обнаруживают болезнь у человека. Пиком совершенства опыта является развитая профессиональная интуиция: не просто увидеть «симптомы» и вспомнить, что это за проблема, а по косвенным, бессвязным признакам предположить и подтвердить большую проблему.
Например:
- Клиент обращается с таким признаком: в CPU коммутатора попадает лавина ARP-пакетов, и многие из них CPU просто отбрасывает. По опыту скажу, что с высокой вероятностью это связано с функцией изучения транзитного трафика, и есть команда, которая отключает этот функционал
- Многие клиенты обращаются с проблемой: коммутатор не отвечает на некоторые ветки SNMP. Спрашиваем версию ПО, и, как часто это бывает, версия ПО оказывается очень старой: на той версии требуемую ветвь SNMP ещё не добавили
Выбор системы локализации проблемы
Приведу небольшой пример того, о чём пойдёт речь в этой главе. Представьте, что на станцию техобслуживания привезли машину с жалобой: что-то стучит под капотом. Откуда автомеханик начнёт диагностику? Оттуда и начнёт — под капотом. И характер проблемы сразу ограничивает число элементов системы (а машина — это техническая система), которые подлежат проверке. Автомеханик отбросит те элементы, которые не могут создавать такую проблему или если и создают, то очень опосредованно и второстепенно. Есть другие элементы системы, которые больше соответствуют описанным «симптомам». Поэтому автомеханик отбрасывает проверку того, как работает магнитола в машине, не проверяет давление в колёсах или подушку безопасности.
И так с любой системой. Однако некоторые системы могут иметь просто невероятный охват. В нашем случае мы с вами здесь говорим о системах компьютерных сетей. Под системой компьютерных сетей я здесь имею в виду группу физических устройств и программного обеспечения на этих устройствах, которые обеспечивают работу технологии или группы технологий, которые мы исследуем. Под системой локализации проблемы — «урезанную» часть системы компьютерных сетей, в пределах которой мы ищем причину проблемы. Если мы будем диагностировать все устройства системы и абсолютно каждую функцию каждого устройства, то понапрасну потратим лишнее время. В этой главе описаны подходы, благодаря которым мы сможем:
• Выделить все устройства системы, которые в полном составе участвуют в полном цикле работы технологии, которую мы выбрали на предыдущем шаге
• Упростить эту систему и оставить только ключевые части системы, а исключённые части системы обозначить условно. На схемах части сети обозначают облачком с подписью. Здесь так же: обозначьте для себя условно части сети и опишите те технологии, которые обеспечиваются этим участком. Например: IP-сеть маршрутизации, Ethernet-сеть коммутации, ядро MPLS и т.д.
Ещё один вопрос, который вы можете задать: это очевидно, что есть система устройств, выполняющая определённые функции работы сети, но зачем резать и эту систему на маленькие части, если можно проверить все элементы системы, чтобы гарантировать, что мы ничего не упустим? Причин несколько:
- Экономия времени
- Ограниченный доступ к элементам системы. Не каждый инженер имеет доступ на уровень ядра, что уж говорить о различных серверах в ЦОДах компаний
- Экономия сил, которые нужно потратить на добычу некоторых диагностических данных. Некоторые диагностические действия могут потребовать выезда сотрудника на узел связи, съём дампа, что не всегда удобно и легко реализуемо
- Сокращение рисков. Некоторые диагностические действия требуют не только времени и сил, как например, отправить сотрудника на узел связи, но и подразумевают риски. Например, включение некоторых диагностических инструментов может повысить нагрузку на CPU, что может повлиять на сервис
- Одно из главных оправданий этого шага: система на то и система, что элементы системы связаны и взаимодействуют. Это значит, что по признакам, собранным на одном устройстве системы, можно судить о работе других частей системы. Пример: если между двумя IP-устройствами доставляется IP-трафик, то не нужно проверять таблицы маршрутизации промежуточных маршрутизаторов. Доставка пакетов между двумя устройствами служит признаком того, что на остальных участниках системы маршрутизация работает корректно
Кто-то может заметить, что появляется риск отбросить те части системы, где может скрываться причина проблемы. И вы будете правы: иногда такое действительно случается. Но я скажу вам такую идею: как уже говорил, работу сервиса обеспечивает цельная система. А в системе всё взаимосвязано. Это значит, что нарушение работы одного элемента системы мы можем рассмотреть как причину/следствие проблем на других элементах системы. Если мы увидим, что проблема проявляется на участках, которые мы исключили для рассмотрения, мы сможем вернуться к этим частям системы и продиагностировать их.
Когда мы говорим о функционировании сети, мы понимаем, что имеем дело не с одной технологией, а со стеком технологий, где технологии верхних уровней опираются на технологии нижних уровней. Это значит, что, когда мы описываем полную замкнутую систему, предоставляющую определённый сервис, мы включаем в систему все устройства, которые затрагивают технологии всех уровней обеспечения сервиса.
Теперь перейдём непосредственно к выделению системы локализации проблемы. Как я уже говорил, системы могут быть очень большими. Поэтому уже на этапе описания полной системы мы можем начать её сокращать по следующим принципам:
- Разделительный принцип
- Сравнительный принцип
Разделительный принцип
Есть три вида разделения:
- «Вертикальный разрез» — под «вертикальным разрезом» подразумевается исключение части сети, в которой мы уверены, что она гарантированно обеспечивает корректную работу полного стека технологий, и у нас есть основания быть в этом уверенными. Например: у нас возникла проблема с доставкой мультикастовых потоков от стримера A до коммутатора доступа B. Мы из дампа видим, что мультикастовые потоки доходят через магистральные сети до маршрутизатора ядра, в подсеть которого осуществляется доставка. Мы исключаем из системы ядро магистральной сети, потому что мы наблюдали признак, — дамп трафика, — который говорит нам о том, что магистральная сеть и другие устройства за магистралью (мультикастовый сервер) корректно выполняют свою часть обеспечения сервиса
- «Горизонтальный разрез» — строится на том, что мы смотрим на каждое устройство как на реализацию многоуровневой системы OSI. Вы знаете, что есть сетевые устройства первого физического уровня, второго канального уровня, третьего сетевого уровня и т.д. Если мы понимаем, что проблема находится на одном из верхних уровней, то мы можем исключить промежуточные устройства нижестоящих уровней как устройства, которые не принимают участие в работе верхних уровней. Но также мы не забываем, что современные сетевые устройства выходят за рамки работы в пределах своего уровня. Если мы пытаемся понять, почему происходят сбои TCP-сессий, а это 4-й уровень, мы не можем забывать про то, что современные Ethernet-коммутаторы второго уровня способны анализировать даже TCP и UDP заголовки. Пример реальной заявки, который показывает, как в доставке TCP-трафика (4-й уровень) оказался виноват функционал L2-коммутатора. На коммутаторе есть такая функция, как uACL (userdefined-access-list). Она позволяет фильтровать пакеты на основе значений байтов пакета. Клиент захотел отбрасывать IGMPv1 Report и настроил uACL так:
userdefined-access-list standard offset window1 10
userdefined-access-list standard 1200 deny window1 12000000 ff000000
Действительно, IGMPv1 Report попадают под это запрещающее правило. Однако и TCP-пакеты с Sequence Number, начиная с 301989888, тоже попадают под это правило. Для решения заменили правила на следующие, где в фильтре явно указали искать идентификатор протокола IGMP в заголовке IP (в поле Protocol):
userdefined-access-list standard offset window1 6 window2 10
userdefined-access-list standard 1200 deny window1 01020000 ffff0000 window2 12000000 ff000000 - «Комбинированный разрез» — комбинированный подход объединяет оба предыдущих. Мы исключаем целые участки, в работе функций которых мы не сомневаемся и на которых не может быть проблем, и те устройства, на уровне работы которых проблем не выявлено.
Сравнительный принцип
Этот принцип часто используется в том случае, когда сложно добыть диагностическую информацию в конкретной системе, и сервисы сети работают хотя бы для части клиентов.
Я уже говорил, что система предоставляет сервис для определённых устройств в сети (это могут быть роутеры клиентов интернет-провайдера или виртуальные машины в ЦОДах и т. д.) — назовём их «потребителями сервиса». Сравнительный принцип состоит в том, что мы сравниваем работу сервисов для двух «потребителей сервиса». Нужно взять двух «потребителей»: для одного сервис работает, для другого — нет. И теперь мы отбрасываем те части сети, которые являются общими для двух «потребителей сервиса».
Например: два соседа пользуются сервисом телевидения у одного провайдера. У одного телевидение работает, у другого – нет. Без глубокого анализа мы можем взять в свою «систему локализации проблемы» только различающиеся части сети.
Составление опорных алгоритмов: показательный и фактический
«Алгоритм работы избранных технологий» – это алгоритм работы конкретных технологий, которые работают на данной сети (мы рассматриваем на «системе локализации проблемы») и предоставляют разнообразные сервисы. Нас интересуют те технологии, которые мы выделили на этапе «Выбор проблемной технологии».
И далее мы должны составить два алгоритма работа избранных технологий:
- Показательный алгоритм – алгоритм работы сети, как он должен работать
- Фактический алгоритм – алгоритм реальной работы сети
Оба алгоритма мы подвергнем сравнению, поэтому они должны быть описаны на одном уровне глубины, на одном уровне подробностей. Я выделяю несколько уровней глубины описания алгоритмов:
- Уровень сети – для определения, на каком устройстве проблема. Когда мы описываем проблему на уровне сети, мы поверхностно описываем роль каждого устройства в ходе работы сетевого алгоритма
- Уровень процессов на конкретном устройстве – для определения, на каком этапе произошёл сбой. Когда мы описываем проблему на уровне процессов, то здесь мы описываем шаги, которые в рамках алгоритма выполняет конкретное устройство. В данном случае есть тоже свои уровни погружения – можно ограничиться описанием состояний процессов (например, если разбираем протокол OSPF, то описываем состояния OSPF в тот или иной момент работы алгоритма), описанием таблиц (таблицы пересылок, таблицы маршрутизации, OSPF Database, таблицы DHCP Snooping Binding и прочих хранилищ для различных протоколов). Есть и уровни глубже – описание внутренних элементов в программе коммутатора, который реализует функционал (например, когда DHCP Snooping принимает пакет DHCP Discovery, коммутатор создаёт внутреннюю запись DHCP Candidate) – такие вещи касаются реализации у вендора и нужны только для разработчиков
- Дальнейшее углубление – это ещё более подробный съём диагностических данных на «Уровне процессов на конкретном устройстве»
На каком уровне глубины должны быть описаны эти алгоритмы? Этап «Составления опорных алгоритмов» будет повторяться циклически, и с каждым циклом степень глубины и уровня подробностей описания алгоритмов будут увеличиваться.
О том, какие инструменты описания фактического «алгоритма работы» использовать, мы подробнее поговорим в отдельной главе – «Инструменты сбора диагностической информации».
Сравнение опорных алгоритмов
Один из самых простых и ключевых этапов глобального алгоритма диагностики. На этом этапе мы ищем отклонение фактического алгоритма от показательного. Там, где будет отклонение, там и кроется причина проблемы.
Вход в цикл
На данном этапе перед вами стоит выбор или-или:
- Вы обнаружили отклонение между алгоритмами и выявили причину проблемы. Тогда вы выходите из цикла и переходите к следующему шагу
- Вы не обнаружили отклонение и требуется повторить последние действия, о которых я скажу далее. Либо отклонение замечено, но проблема описана на недостаточно глубоком уровне, и вам требуется более подробно описать проблему, собрав ещё более подробные данные работы алгоритма: будь то описание статусов процессов, заполнение таблиц технологий, данные из сообщений Debug и проч.
Войдя в цикл, вы повторяете следующие действия:
- «Выбор проблемной технологии» – нечасто, но иногда случается, что во время диагностики мы понимаем, что неправильно выбрали проблемную технологию. И на этом этапе мы переопределяем проблемную технологию, с которой будем работать
- «Выбор системы локализации проблемы» – если вы пошли на цикл, чтобы добыть подробности проблемы, то это значит, что вы наблюдали устройства и даже процессы, в пределах которых возникает проблема. У вас есть основание сузить «схему локализации проблемы». Также вы могли обнаружить, что признак проблемы проявился на участке, который мы ранее уже обрезали на этапе «Выбора системы локализации проблемы», это повод ещё раз пересмотреть усечённый участок и обновить «систему локализации проблемы»
- «Составление опорных алгоритмов» – мы повторяем этап составления опорных алгоритмов, но погружаемся на более глубокие уровни и собираем и анализируем более глубокие диагностические данные, в том числе требуем информацию у клиента. Чем глубже погружаемся, тем больше «инструментов сбора диагностической информации» применяем (об инструментах будет дальше)
- Сравнение опорных алгоритмов
- Повторный этап «Входа в цикл»
Обоснование проблемы
На этом этапе вы вышли из основного цикла и обнаружили причину возникновения проблемы, описанную на должном для вас уровне подробностей. Что же далее?
Следующий этап – самый «философский», потому что он задаёт вопрос: «А есть ли проблема вовсе?». Перед инженером на самом деле вырастает сразу несколько конкретных вопросов:
- А как должно быть по стандартам? По RFC? По стандартам IEEE?
- А как у Cisco? У HUAWEI? Какой Best Practice?
Здесь к этим вопросам нужно дать комментарии:
- Первый вопрос вполне мог и не вставать, когда вы для себя описывали «Показательный алгоритм», вы с ним сравнивали фактическую работу системы. Но скорее всего в реальной работе вы будете пользоваться своими знаниями, а также интуитивным ожиданием от работы алгоритма (это просто сильно экономит время, чем прочёсывание стандартов каждый раз), и не всегда они соответствуют стандартам и множеству сносок и дополнений у стандартов, поэтому ещё раз проверьте работу алгоритма по стандартам. В итоге вы приобретёте весомый аргумент в пользу того, чтобы запросить у разработчиков изменить алгоритм работы или, наоборот, отказать клиенту и сказать, что оборудование соответствует стандарту (но и тут есть нюанс, связанный с клиентоориентированностью)
- И даже если стандарт на вашей стороне, всё равно задайте вопрос: «А как работает у Cisco? Какие лучшие практики?». Не все вещи описаны в стандартах, и решение некоторых мелких вопросов отведено на усмотрение производителей. Тогда имеет значение взять ориентир на популярные решения. Но здесь есть свои оговорки, которые мы обсудим в главе «Формулировка проблемы и передача на уровень выше»
Поиск решения проблемы
Прежде чем передавать проблему разработчику, надо удостовериться в некоторых вещах: есть ли уже решение у этой проблемы.
Мы выделяем прямые решения и альтернативные:
- Прямое решение:
a. У клиента неверная конфигурация, и её нужно изменить
b. У клиента старая версия ПО, и решение уже есть в новой версии ПО
c. Устройство технически не может работать в таких условиях и предоставлять нужный функционал, проблема аппаратная или сложно реализуема из-за существующей аппаратной или программной архитектуры – решается только заменой на другое устройство
d. Сдать проблему разработчикам, чтобы они сделали программное решение - Альтернативное решение (Workaround):
a. Конфигурационный workaround – включает в себя изменение конфигурации, небольшие дополнительные изменения физической схемы. Хорошим примером служит популярный запрос клиентов: QinQ на Access-порту. То есть клиентский трафик приходит без меток VLAN, а в магистральный порт уходит с двумя метками VLAN. Прямого решения на коммутаторах SNR на сегодняшний день нет. Но есть Workaround с применением физической петли, замкнутой на коммутаторе: трафику клиента присваивается один VLAN на порту доступа и ещё один при возвращении из физической петли
b. Административный workaround – административное изменение логики работы сети. Похоже на конфигурационный workaround, но дополнительно мы требуем изменение работы в логике работы сети клиента. Пример одного из административных workaround: клиент встретился с багом, при котором некорректно работала связка двух технологий: MAB + LLDP-MED. На стыке работы двух технологий не проработан правильный, интуитивно ожидаемый вариант работы совместной работы двух технологий. Поэтому в качестве альтернативы были предложены другие варианты, которые бы поменяли логику работы сети административно: MAB + Voice-VLAN или MAB + выдача Dynamic VLAN через RADIUS.
Сдавать заявку разработчику не всегда хороший вариант, потому что это человеческие ресурсы, иногда очень большие. В некоторых ситуациях прямое решение – это ещё и лишние траты клиента на покупку нового оборудования. Возможно, клиента устроит альтернативное решение, и это сэкономит ресурсы команды разработчиков и деньги клиента.
Пример недавнего события:
Обратился клиент с коллизией MAC-адресов. Коллизия происходила на коммутаторе SNR-S3850. Количество MAC-адресов в сети было более 13 тысяч, на этом числе на коммутаторах серии SNR-S3850 уже начинаются коллизии. Было предложено и прямое решение, и несколько альтернативных решений.
Прямое решение:
1) Непосредственное решение проблемы: замена устройства на другое с большим размером таблицы коммутации.
Альтернативные решения:
1) Плохое решение: Если коллизии невелики, то рекомендуется:
а. Проверить, что включена команда: "mac-address-table bucket size 4" (по умолчанию)
б. Ввести команду "mac-address-learning cpu-control" и проверить, какие хосты создают коллизии ("show collision-mac-address-table")
в. Переместить хосты так, чтобы устранить коллизии
г. Отключить CPU-control: "no mac-address-learning cpu-control"
2) Отключить cpu-control и оставить коммутатор "жить" с коллизиями.
Чтобы предотвратить распространение лишнего BUM-трафика, которого может быть много при большом количестве коллизий, выполнить:
а. Сегментировать сеть на VLAN
б. Изолировать порты, между которыми не должна быть передача трафика
3) Если на коммутаторе есть VLAN, которые отданы только на два порта (Uplink и Downlink), то:
а. Отключить CPU-Control
б. Отключить изучение MAC-адресов в этих VLAN ("mac-address-learning disable vlan <VID>")
В этом случае трафик будет широковещательным, но т.к. портов в домене всего два, то трафик будет только между двумя портами и не будет попадать в лишние порты
4) Сегментировать сеть на VLAN так, чтобы каждый VLAN был только на двух портах (Uplink и Downlink), и выполнить рекомендации из шага №3.
Альтернативные решения позволяют сэкономить деньги на покупку нового оборудования, избежать затрат людских ресурсов на замену оборудования, а также устраняют перерывы связи.
Но если решение всё-таки требует действий разработчиков, то здесь мы переходим к следующей главе.
Формулировка проблемы и передача на уровень выше
Вот мы нашли проблему и готовы её описать разработчикам. Вы можете описать проблему непрерывным потоком своих мыслей, но будьте готовы к тысяче вопросов и времени, которое разработчик потратит на вникание в проблему.
Хорошей практикой будет описание проблемы по разделённым друг от друга пунктам. Я использую следующие пункты:
- Введение. В нём кратко описываем, как клиент наткнулся на эту проблему, добавляем дополнительную информацию о важности клиента, заявившего о проблеме
- Краткое описание проблемы. Напишите проблему сжато и кратко. Полное подробное описание проблемы сложится суммой из всех остальных пунктов. Не бойтесь в этом случае не использовать длинное сложносочинённое предложение, которое трудно понять: всё, что не попало в краткое описание, будет изложено в других пунктах
- Важные условия воспроизведения проблемы
- Testcase. Опишите testcase'ы, где вы отразите «фактический алгоритм» работы. К нему обязательно комментарий, как этот алгоритм отличается от «показательного алгоритма». Также можно добавить testcase’ы, при которых фактический алгоритм работает корректно
- Аргументация запроса. Описание стандарта, ссылка на инструкцию Cisco, Best Practice и подобное
- Дополнительные материалы, на которые вы будете ссылаться в своём запросе. Например: файлы конфигурации для тестов, статистику Zabbix, медиафайлы и прочее
- Варианты Workaround
- Важные нюансы, которые хотите добавить к описанию
И пишите, не забывая о том, что это прочитает человек, а не ИИ.
Теперь затронем ещё один важный нюанс о том, какое решение мы предлагаем реализовать команде разработчиков: когда мы говорим что-то исправить, потому что у нас «не как у Cisco», потому что есть Best Practice и прочее. Ведь кто-то уже пользуется тем, что есть, и вся система работает с расчётом на то, что коммутатор работает именно так, как работает сейчас. Если изменить логику какого-либо функционала, это может сломать работу сети клиента. В таком случае принимается решение оставить два варианта реализации алгоритма – тот, что есть, и тот, что ожидается. А переключение должно работать через вспомогательную команду. По умолчанию, естественно, должно работать так, чтобы не сломалось уже в работающих клиентских системах.
Инструменты сбора и анализа диагностической информации
Перечень инструментов сбора и диагностики информации:
- Debug
- Wireshark
- Съём дампа:
a. Зеркалирование
b. Запись дампа на коммутаторе
Debug
Debug позволяет рассмотреть детали работы различных процессов в виде записей логов о внутренних процессах.
Это очень важный инструмент, в котором можно увидеть:
- Доставку служебных пакетов
- Записи в таблицы различного функционала
- Состояния различных процессов
- Записи о внутренних процессах, предназначенные для разработчиков
Чтобы включить Debug, необходимо ввести команду «debug …», выбрать нужный функционал и элементы debug. Если необходимо вывести сообщения логов в файл или на удалённый логсервер, нужно изменить настройки логирования.
Съём дампов
На коммутаторах есть несколько способов съёма дампа:
- Зеркалирование
- Запись дампа на коммутаторе
Зеркалирование
Зеркалирование – метод сбора дампа, при котором трафик, направляемый в определённый интерфейс, клонируется и направляется в другой интерфейс в направлении устройства записи дампа.
На коммутаторах SNR есть три варианта зеркалирования:
- SPAN – зеркалирование трафика из интерфейса в порт без изменений
- RSPAN – зеркалирование трафика из интерфейса в порт с добавлением метки VLAN
- ERSPAN – зеркалирование трафика из интерфейса в интерфейс туннеля (GRE)
Благодаря зеркалированию мы можем посмотреть, какие пакеты передаются на интерфейсах и их содержание.
Запись дампа в память коммутатора
Чтобы не ставить оборудование съёма дампа или не тянуть зеркалируемый трафик через всю сеть, можно воспользоваться функцией записи трафика прямо во Flash-память коммутатора. Команды продемонстрированы на слайде.
Большинство моделей поддерживает съём такого дампа только из CPU коммутатора. Модели SNR-S5xxx поддерживают запись дампа на Flash из физических интерфейсов.
Анализ дампа в Wireshark
Незаменимый инструмент в руках инженера поддержки и не только — это Wireshark. Это приложение — очень удобный анализатор трафика в реальном времени, у него есть множество крутых функций, таких как:
- Подробное толкование пакетов
- Установка связи между пакетами: Wireshark указывает, какие пакеты друг с другом связаны (например, потоки TCP, цикл обмена DHCP-сообщениями и т. д.)
- Гибкие фильтры сетевого трафика
- Сбор и различные варианты представления статистики сетевого трафика
- И многое другое
Думаю, многие из вас уже использовали его: кто-то в учебных целях, кто-то успел попробовать его для решения рабочих задач. Я покажу вам основные элементы функционала, которые помогают в диагностике клиентских задач.
Панель фильтров
Дампы, с которыми мы сталкиваемся в работе, могут содержать и тысячи, и десятки тысяч пакетов. А в этой куче нам нужен трафик определённого протокола, определённого MAC-адреса или определённого IP-адреса и прочее. А ещё бывает так, к примеру, что в дамп с работой BGP или OSPF попало много пакетов типа BGP Keepalive или OSPF Hello — из-за них приходится бегать между двумя разными концами дампа, чтобы посмотреть нужный пакет BGP и OSPF.
У Wireshark есть решение, чтобы избавиться от этого бардака — фильтрация! Фильтрация позволяет фильтровать трафик не просто по протоколам, а по значениям конкретных полей протокола, а также фильтровать по нескольким параметрам с помощью логических выражений И, ИЛИ, НЕ.
Статистика сетевого трафика
Wireshark имеет инструменты по сбору статистики сетевого трафика и несколько вариантов представления.
Один из инструментов представления – это графический способ, который отображает зависимость числа пакетов от времени. С помощью этого графика мы можем фиксировать микровсплески и увидеть, какой именно трафик создаёт всплески.
Анализ дампа в Wireshark. Диалоги
Способ представления обмена трафиком между конкретными хостами на уровне различных транспортных протоколов таких как:
- Ethernet
- IP
- TCP/UDP
Пример вывода статистики на слайде. В нём можно увидеть вкладки для выбора транспортных протоколов.
Вывод статистики описывает взаимодействие с помощью полей:
- Адрес первого хоста
- Адрес второго хоста
- Вспомогательные столбцы для идентификации хостов (например, для протокола TCP отображается и поле IP-адреса, и поле TCP-порта).
- Статистические столбцы: сколько всего пакетов было передано, сколько всего байт, статистика этих же параметров по отдельности в обоих направлениях
- Время взаимодействия
- и т.д.
Графическое отображение статистики трафика
Инструменты Wireshark позволяют выводить статистику трафика в виде графика зависимости нагрузки трафика от времени. На одном графике вы можете отобразить статистику разных пакетов: хоть всех пакетов, хоть отфильтрованных с помощью тех же фильтров, которые мы можем задавать через панель фильтров.
Чаще всего к графическому представлению мы обращаемся в двух случаях:
- когда обнаруживаем всплески на физических портах, приводящие к переполнению буферной памяти коммутатора
- когда снимаем дамп с CPU, чтобы поймать источник вредоносного трафика, обрабатываемого в CPU
При подобных проблемах мы увидим соответствующие всплески в статистике портов. Собрав дамп, можем переходить к выводу графика через вкладки: «Статистика» → «Графики ввода/вывода». График, который имеет проблемы дропов из-за нехватки ресурсов, покажет картину, как в следующем примере:
1. Случай с переутилизацией CPU, когда CPU загружено постоянно. Дамп снят с помощью зеркалирования с CPU коммутатора SNR-S400X:
- непрерывно в CPU направляется более 2000 пакетов в секунду. По дампу я обратил внимание, что очень много пакетов протокола DHCP. Добавил в график отображение статистики DHCP-пакетов и увидел, что больше половины всех пакетов составляют пакеты DHCP. Так как проблему надо было устранять, перенесли всех клиентов на рядом стоящий SNR-S300G. Клиенты заработали без проблем. А в дампе CPU для SNR-S300G, на который перенесли клиентов и который играет роль DHCP Relay, число DHCP-пакетов не превышало 100 пакетов в секунду:
Так мы пришли к тому, что DHCP Relay на SNR-S400X уровня ядра обрабатывает все пакеты DHCP в процессе работы DHCP Relay на CPU в огромной сети с большим числом хостов. Это было явно некорректно в сравнении с тем же SNR-S300G, старой моделью. Обратите внимание на то, что здесь мы могли наблюдать применение сравнительного подхода при выборе проблемной технологии. Это было быстро сдано разработчикам, и в результате сейчас в Changelog красуется вот такое изменение для SNR-S400X:
V707R302C000B001
FIX|CRM20250723032922 issue with DHCP packets reach the CPU via L3 routing
Функция формата времени в Wireshark
На основной панели просмотра пакетов вы можете редактировать столбцы. Отдельного внимания заслуживает полезная фича изменения формата отображаемых столбцов. Например, в столбце времени можно установить не абсолютное время, а разницу во времени между приходом следующего пакета и предыдущего. Для этого нужно установить формат времени «Delta time displayed».
Заключительное слово
И напоследок я бы хотел сказать, что алгоритм, проверенный сотнями заявок, — это инструмент в руках инженера. Инструментом надо уметь пользоваться и развивать своё мастерство работы с ним: улучшать свои знания вширь, чтобы не тратить время на изучение технологий вместо быстрого применения их в алгоритме, и вглубь, чтобы описывать «фактические алгоритмы» работы системы на глубоком уровне, увеличивая шансы найти проблему, закопанную на очень глубоком уровне сетей.