Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:

  • насколько интенсивно используется каждый порт;
  • каким образом идентифицируется и отслеживается источник ошибок;
  • что является источником широковещательного шторма;
  • правильно ли работают таблицы пересылки;
  • какие рабочие станции подключены к конкретному порту;
  • накладывает ли коммутатор ограничения по скорости на какие-либо протоколы или порты;
  • относится ли порт к виртуальной сети VLAN, и если да, то принадлежит ли сервер или служба к той же самой виртуальной сети?

С чего следует начинать, когда вы получаете сообщение о том, что в коммутируемой сети возникла проблема? Как правило, главная трудность заключается в невозможности «заглянуть» внутрь коммутатора. Источник неполадок следует искать в первую очередь на втором уровне сетевой модели OSI при организации коммутатором моста, при этом использование виртуальных сетей VLAN и других функций третьего и более высоких уровней, а также правил продвижения трафика, может дополнительно осложнить ситуацию. Если в сети реализованы «продвинутые» функции коммутации, например, маршрутизация на четвертом уровне и выше вкупе с балансировкой нагрузки, то за диагностику должен браться специалист, отлично разбирающийся во всех тонкостях настройки коммутаторов.

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

Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.

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

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

ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ

Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.

При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.

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

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

МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ

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

Однако даже сочетание всех методов не позволяет следить за коммутируемой сетью в таких подробностях, как это можно было делать в сетях на базе концентраторов. Увидеть и отследить абсолютно весь трафик и все ошибки, относящиеся к коммутатору, практически невозможно. Большинство диагностических процедур подразумевает, что трафик проходит между рабочей станцией и соответствующим сервером или направляется на магистральный порт. Если две рабочие станции обмениваются данными напрямую через одноранговое (пиринговое) соединение, то трафик не проходит ни через магистральный порт, ни через какой-либо другой порт коммутатора. Такие соединения редко обнаруживаются, если только не искать их специально. Обычно ошибки не распространяются за пределы порта коммутатора, однако для некоторых их типов и определенных настроек коммутаторов возможна и дальнейшая трансляция.

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

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

МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ

Получить доступ к настройкам коммутатора можно разными способами, включая следующие:

  • войти в систему с помощью сеанса TELNET;
  • войти в систему с помощью сеанса SSH;
  • войти в систему через сеанс Web;
  • подключиться через последовательный порт коммутатора.

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

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

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

Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.

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

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

Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.

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

О других методах диагностирования коммутаторов мы расскажем в следующих выпусках рубрики.

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.