Что делать если указанные технические данные порта на коммутаторе не совпадает с фактическими
Топ-5 причин выхода коммутатора из строя: перегрузка и другие поводы
Поломку коммутационного оборудования могут спровоцировать внешние и внутренние факторы.
Нарушение базовых правил эксплуатации
К выходу свитча из строя может привести банальная неаккуратность. На качество работы влияют различные механические воздействия:
резкие выдергивания сетевых кабелей;
случайные удары по корпусу;
падения с большой высоты.
Среди причин повреждения внутренних компонентов также стоит упомянуть возгорание микросхем в результате контакта с водой или какой-либо другой жидкостью.
Чтобы защитить свитч от человеческого фактора, достаточно соблюдать правила безопасной эксплуатации, детально описанные в пользовательском руководстве.
Некачественное программное обеспечение
С проблемой недостаточно надежного ПО сталкиваются владельцы бюджетных коммутаторов от неизвестных производителей, а также пользователи контрфактного сетевого оборудования (подделок продукции известных брендов).
Вернуть работоспособность свитчу в случае сбоя в работе ПО может повторная прошивка.
Нестабильность электрической сети
Скачок электрического напряжение или короткое замыкание губительны практически для любого сетевого оборудования. В особенности подвержены повреждениям свитчи, маршрутизаторы, точки доступа и другие устройства во время грозы.
Для защиты девайсов от токов КЗ и резких перепадов напряжения следует использовать источники бесперебойного питания и внешний стабилизаторы.
Повреждения портов для подключения оборудования
Если сам коммутатор по визуальным признакам работает без перебоев, а подключить какое-либо устройство к нему не удается, проблема кроется в сетевых портах. Скорее всего, в результате продолжительной эксплуатации «входы» просто износились и стали непригодными для использования.
Решить эту проблему можно в любом сервисном центре. Специалисты быстро произведут замену поврежденных портов и вернут устройству функциональные возможности.
Выход из строя одного из внутренних элементов коммутатора
Если коммутатор перестал включаться, причину поломки стоит искать внутри. Возможно, сгорела плата памяти устройства, вышла из строя одна из микросхем или перестал работать встроенный блок питания.
Устранить все эти поломки поможет поход в сервис или же самостоятельная замена неисправных запчастей.
Не стоит паниковать и сразу после возникновения сбоев в работе коммутатора искать ему замену. Большинство проблем можно устранить, потратив на ремонт гораздо меньше средств, чем на покупку нового устройства.
Иногда мы сталкиваемся с проблемой совместимости, заключающейся в том, что Smart/управляемые коммутаторы TP-Link не могут подключиться к коммутаторам других производителей при подключении через порт SFP. Например, как показано на рисунке, два коммутатора соединены оптоволокном, и на портах горят индикаторы, но данные между ними не передаются. В этом FAQ, состоящем из двух шагов, мы расскажем, что делать в такой ситуации.
Шаг 1. Убедитесь, что оба коммутатора имеют одинаковую скорость на SFP-портах.
При подключении коммутаторов через SFP-порты сначала нужно убедиться, что у их SFP-портов одинаковая скорость. Например, если скорость SFP-порта коммутатора TP-Link составляет 1000 Мбит/с, скорость SFP-порта другого коммутатора также должна быть 1000 Мбит/с.
Примечание: обычно при разработке коммутаторов большинство производителей не внедряют функцию автоматического согласования скорости для портов SFP, поэтому скорость порта SFP почти всегда выставляется вручную.
Шаг 2. Проверьте режим дуплекса на коммутаторах.
Помимо скорости порта SFP на результат согласования также влияет режим дуплекса. Убедившись, что скорость на портах одинаковая, нужно проверить на коммутаторах режим дуплекса.
Если порт SFP коммутатора поддерживает только принудительный (Force) режим, это может привести к неудачному согласованию. Для решения этой проблемы можно использовать последние модели Smart/управляемых коммутаторов TP-Link (например, T2600G-28TS V4), чьи SFP-порты имеют поддержку функции автоматического согласования дуплекса, благодаря которой коммутатор сначала попробует согласовать тип дуплекса с другим коммутатором в режиме автоматического определения, а если ответа не будет, он вернётся в принудительный режим. Поэтому нужно просто оставить автоматический режим дуплекса для SFP-порта коммутатора TP-Link, тогда он сможет работать с большинством коммутаторов других производителей.
Однако у некоторых более старых коммутаторов TP-Link нет режима автоматического согласования, и нужно вручную устанавливать дуплексный режим — такой же, как и на «коммутаторе-соседе». Если вы не уверены в дуплексном режиме второго коммутатора, можно попробовать поочерёдно менять дуплексный режим коммутатора TP-Link до тех пор, пока они не заработают. Обычно дуплексный режим порта SFP поддерживает только два типа: полный и автоматический.
Чтобы изменить режим дуплекса, перейдите в L2 FEATURES > Switching >Port > Port Config .
Проблемы, с которыми приходится сталкиваться в коммутируемой сетевой среде, мало чем отличаются от сбоев в разделяемой среде передачи.
Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:
Устанавливая в сети коммутатор, вы фактически создаете отдельный коллизионный домен на каждом порту – именно таков принцип работы коммутаторов. Если к порту подключить концентратор, ресурсы которого используются совместно, то коллизионный домен может увеличиться до максимально допустимого для данного варианта Ethernet размера. Коммутирующее оборудование постоянно дешевеет, поэтому в большинстве современных сетей к каждому порту подключается всего одна рабочая станция, и в этом случае коллизионный домен состоит из единственного кабельного сегмента.
Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.
Если на каждом порту создается собственный широковещательный домен, то возможности диагностики сильно ограничены. Кроме того, организация отдельного широковещательного домена на каждом порту требует от коммутатора выделения для маршрутизации значительной части ресурсов центрального процессора на продвижение всего сетевого трафика. В реальной жизни очень трудно представить себе сеть, где требовалось бы обрабатывать и перенаправлять каждый запрос и отклик по отдельности. При отсутствии очень веских оснований создания именно такой структуры сети следует избегать.
К сожалению, весьма распространена конфигурация, когда в одну подсеть или широковещательный домен помещаются все серверы, а пользователи распределены по некоторому количеству других подсетей или широковещательных доменов. В таком случае практически все запросы должны маршрутизироваться. Если ради удобства обслуживания необходимо разместить все серверы в одном помещении (серверной), то их рекомендуется распределить по нескольким виртуальным сетям VLAN. Пользователей, которые обращаются к конкретному серверу, следует отнести к той же виртуальной сети. В такой конфигурации матрица коммутатора может использовать для обычного трафика мост на втором уровне модели OSI, поэтому маршрутизироваться будут только нетипичные или редкие запросы. Если сервер обслуживает более одного сообщества пользователей, то установите в него дополнительные сетевые карты, чтобы связь осуществлялась на втором уровне модели OSI.
ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ
Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.
При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.
Другая стратегия – дождаться, пока от пользователей начнут поступать жалобы. Во многих сетях применяется именно такой подход, который не стоит недооценивать из-за внешней простоты – на самом деле, он очень эффективен. Пользователи чутко реагируют на состояние сети, несмотря на то, что представление о ее работе больше основывается на подсознательном восприятии, чем на логических заключениях. Заметив малейшее ухудшение
в работе сети, пользователь обычно тут же обращается с жалобой в отдел ИТ или к системному администратору. Так что работу по поиску и устранению неисправности можно начать с его рабочего места. Такой подход называется реактивным, поскольку предполагает реагирование на уже произошедший сбой.
Напротив, профилактические, проактивные методы направлены на то, чтобы не допустить возникновения сбоя. Для этого проводится регулярный опрос коммутаторов, мониторинг качества трафика на каждом порту коммутатора и в каждом сегменте. Когда проблема уже появилась (поступила жалоба, либо вы сами обнаружили сбой), диагностировать ее можно разными методами, каждый из которых имеет свои плюсы и минусы.
МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ
Получить информацию о работе коммутатора можно как минимум десятью основными способами. Каждый предполагает свой порядок действий и имеет свои положительные и отрицательные стороны. Как обычно, единого рецепта на все случаи жизни не существует. Выбирать подходящее решение из разных вариантов следует, прежде всего, исходя из доступности ресурсов, опыта специалиста, проводящего работы, и оценки последствий для функционирования сети (приостановка, перерывы в работе) при использовании того или иного метода.
Однако даже сочетание всех методов не позволяет следить за коммутируемой сетью в таких подробностях, как это можно было делать в сетях на базе концентраторов. Увидеть и отследить абсолютно весь трафик и все ошибки, относящиеся к коммутатору, практически невозможно. Большинство диагностических процедур подразумевает, что трафик проходит между рабочей станцией и соответствующим сервером или направляется на магистральный порт. Если две рабочие станции обмениваются данными напрямую через одноранговое (пиринговое) соединение, то трафик не проходит ни через магистральный порт, ни через какой-либо другой порт коммутатора. Такие соединения редко обнаруживаются, если только не искать их специально. Обычно ошибки не распространяются за пределы порта коммутатора, однако для некоторых их типов и определенных настроек коммутаторов возможна и дальнейшая трансляция.
Для простоты представим себе минимальный сегмент сети: сервер, подключенный к коммутатору. В одних случаях мы будем предполагать, что пользователи, испытывающие проблемы, подключены к тому же самому коммутатору, в других — что они будут пытаться получить доступ к серверу через магистральный порт, ведущий либо к другому коммутатору, либо к маршрутизатору. Диагностика начинается в ответ на жалобу о медленной работе сети при обращении к серверу. К сожалению, такое описание проблемы ничего не говорит специалисту ИТ. Если речь идет не об обычном сбое, а взломе системы защиты, причем предполагаются последствия юридического характера, то необходимо принять дополнительные меры, чтобы обеспечить достоверность и юридическую силу собираемых данных.
Информация, относящаяся сразу к нескольким методам, будет приводиться в описании того метода, в котором она раскрывается наиболее полно. Большая часть описаний относится также к методам, отличным от того, которому посвящен конкретный раздел, причем она может иметь как тривиальные, так и фундаментальные последствия для конечного результата.
МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ
Получить доступ к настройкам коммутатора можно разными способами, включая следующие:
подключиться через последовательный порт коммутатора.Некоторые коммутаторы обладают рядом встроенных диагностических средств, которыми можно воспользоваться, но следует помнить, что их функциональные возможности существенно различаются в зависимости от производителя и модели коммутатора. Расширенные команды операционной системы позволяют провес-ти более глубокий анализ транслируемого трафика, однако имеющийся интерфейс нельзя назвать дружественным к пользователю. Чтобы успешно применить такие функции, надо обладать значительным опытом и глубоким знанием теории сетей.
Плюсы. Консольный доступ – очень эффективный метод диагностики, он широко распространен и используется чаще других. Множество самых разных проблем в сети вызвано именно неправильными настройками коммутаторов и выполняемыми в соответствии с этими настройками действиями.
Получить доступ к консоли управления коммутатором можно всегда — одним из вышеперечисленных способов. Почти повсеместная доступность беспроводных сервисов и услуг передачи данных, предоставляемых мобильной связью, позволяют управлять сетью из любой точки планеты. Настроив систему управления сетью на отправку уведомлений на мобильные устройства, вы сразу узнаете о возникновении сбоя.
Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.
Минусы. Старшие системные администраторы и другие ведущие сотрудники отделов ИТ, обладающие паролями для доступа к настройкам коммутаторов, при проведении диагностики уделяют столь повышенное внимание конфигурации, что никакие другие варианты даже не приходят им в голову, пока этот метод себя полностью не исчерпает. Между тем, отказ от прочих подходов может существенно задержать устранение сбоя и дополнительно осложнить ситуацию. С помощью только консольного доступа удается выявить и устранить только часть сетевых проблем.
Обычные команды, подаваемые с помощью консоли, позволяют установить средние уровни использования, но не дают информации о конкретных видах сетевой активности или исходной причине сбоя того или иного протокола. Более того, данные, получаемые с помощью консольного доступа, указывают, скорее, на то, как сеть должна работать, а не сообщают о реальном положении дел, поэтому они мало помогут в случае, например, некорректного функционирования части коммутатора. Просмотр конфигурации не позволяет выявить программные ошибки в операционной системе или неточности и упущения в настройках. Иногда, выведя дамп конфигурации на экран, нельзя узнать настройки по умолчанию, поскольку выдаются только изменения по сравнению с настройками по умолчанию. Между тем, причиной снижения производительности сети вполне могут быть именно эти настройки.
Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.
Если речь идет о критически важных сегментах сети, то консольный доступ из удаленных точек может быть либо запрещен, либо разрешен только с конкретной группы жестко фиксированных адресов. Обычно пароли для доступа к коммутаторам не известны рядовому персоналу отделов ИТ и служб технической поддержки, поэтому они не имеют возможности использовать консольный доступ. Инженеры более высокого уровня, располагающие паролями, как правило, не участвуют в ежедневной работе по устранению сбоев в сетях. А теперь представьте, каким образом специалист, в прямые обязанности которого входит постоянное поддержание производительности сети, сможет эффективно работать, если консольный доступ ему запрещен?
О других методах диагностирования коммутаторов мы расскажем в следующих выпусках рубрики.
Для диагностики ошибок на портах коммутатора Cisco необходимо подключиться к консоли
коммутатора через утилиту telnet , используя консольный порт (прямое подключение)
или по IP-адресу.
Следующим шагом мы переходим в привилегированный режим редактирования конфигурации Enable (en).
Следующей командой мы можем посмотреть счетчики ошибок по всем портам коммутатора:
или по одному порту gi1/33
Приведем описание наиболее важных счетчиков
| Счетчик | Описание | Возможная причина |
|---|---|---|
| CrcAlign-Err | Количество ошибок выравнивания определяется числом полученных кадров, которые не заканчиваются четным числом октетов и имеют неверную контрольную сумму CRC | Данные ошибки обычно являются результатом несоответствия дуплексных режимов или физической проблемы (такой как прокладка кабелей, неисправный порт или сетевая плата). При первом подключении кабеля к порту могут возникнуть некоторые из этих ошибок. Кроме того, если к порту подключен концентратор, ошибки могут вызвать конфликты между другими устройствами концентратора |
| Collisions | В счетчиках кадров с конфликтами содержится число пакетов, одна попытка передачи которых была неудачной, а следующая — успешной. Это означает, что в случае увеличения значения счетчика кадров с конфликтами на 2, коммутатор дважды неудачно пытался передать пакет, но третья попытка была успешной | Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этих полях наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс |
| Undersize | Это общее число принятых пакетов с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и допустимым значением FCS | Указывает на поврежденный кадр, сформированный подключенным устройством. Убедитесь, что подключенное устройство функционирует правильно |
| Oversize | Число принятых портом из сети пакетов с длиной более 1514 байтов2 | Это может указывать на сбой оборудования либо проблемы конфигурации режима магистрального соединения для dot1q или ISL |
| Fragment | Общее число кадров с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и неверным значением FCS | Увеличение значения этого счетчика указывает на то, что порты настроены на полудуплексный режим. Установите в настройках дуплексный режим |
| Single-Col | Число конфликтов, произошедших до того, как интерфейс успешно передал кадр носителю | Нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством |
| Multi-Col | Число множественных конфликтов произошедших до того, как порт успешно передал кадр носителю | Нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством |
| Late-Col | Количество обнаруженных конфликтов в определенном интерфейсе на последних этапах процесса передачи. Для порта со скоростью 10 Мбит/с это позднее, чем время передачи 512 битов для пакета. В системе со скоростью передачи данных 10 Мбит/с 512 битовых интервалов соответствуют 51,2 микросекунды | Ошибка, в частности, может указывать на несоответствие дуплексных режимов. В сценарии с несоответствием дуплексных режимов на стороне с полудуплексным режимом наблюдается поздний конфликт. Во время передачи со стороны с полудуплексным режимом на стороне с дуплексным режимом выполняется одновременная передача без ожидания своей очереди, что приводит к возникновению позднего конфликта. Поздние конфликты также могут указывать на слишком большую длину кабеля или сегмента Ethernet. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны |
| Excess-Col | Количество кадров, для которых передача через отдельный интерфейс завершилась с ошибкой из-за чрезмерного числа конфликтов. Избыточный конфликт возникает, когда для некоторого пакета конфликт регистрируется 16 раз подряд. Затем пакет отбрасывается | Чрезмерное количество конфликтов обычно обозначает, что нагрузку на данный сегмент необходимо разделить между несколькими сегментами, но может также указывать на несоответствие дуплексных режимов с присоединенным устройством. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны |
| Deferred-Col | Общее число кадров, первая попытка передачи которых была отложена из-за трафика в сетевом носителе | Отбрасывание кадров вызвано чрезмерной нагрузкой трафика, направленного к данному коммутатору. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный коммутатор. Может потребоваться изменение топологии сети, чтобы снизить нагрузку трафика на данный коммутатор |
| Carri-Sen | Счетчик увеличивается каждый раз, когда контроллер Ethernet собирается отослать данные по полудуплексному соединению. Контроллер обнаруживает провод и перед передачей проверяет, не занят ли он | Нормально для полудуплексного сегмента Ethernet |
Далее проверяем, включено ли обнаружение отключения из-за ошибки на порту коммутатора:
где, по умолчанию, в колонке Detection все значения должны быть Enabled
Смотрим порты которые находятся в состоянии ошибки errdisable (порт
автоматически отключен операционной системой коммутатора, так как порт
обнаружен в состоянии ошибки):
где в колонке ErrDisable Reason отображается причина перехода порта в состояние errdisable .
В нашем случае портов в состоянии errdisable не обнаружено.
Просмотр подробной информации о настройках и состоянии порта коммутатора:
Как видно из вывода команды, ошибок на порте коммутатора не обнаружено.
Также, набрав следующую команду, можно посмотреть статус и используемые протоколы на портах коммутатора:
Читайте также: