Функции коммутатора устранять ошибки коммутатора

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

• насколько интенсивно используется каждый порт;

• каким образом идентифицируется и отслеживается источник ошибок;

• что является источником широковещательного шторма;

• правильно ли работают таблицы пересылки;

• какие рабочие станции подключены к конкретному порту;

• накладывает ли коммутатор ограничения по скорости на какие-либо протоколы или порты;

• относится ли порт к виртуальной сети VLAN, и если да, то принадлежит ли сервер или служба к той же самой виртуальной сети?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• войти в систему с помощью сеанса TELNET;

• войти в систему с помощью сеанса SSH;

• войти в систему через сеанс Web;

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

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

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

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

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

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

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

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

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

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

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

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

Вот типичные вопросы, которые возникают при использовании коммутируемой среды:

• Насколько загружен каждый порт?
  
• Как найти источник ошибок?
  
• Что является источником широковещательного шторма (размножения некорректно сформированных широковещательных сообщений)?
  
• Правильно ли работают таблицы MAC-адресов?
  
• Какие станции подключены к данному порту?
  
• Ограничивает ли коммутатор скорость работы какого-либо протокола или порта?
  
• Находится ли данный порт в виртуальной локальной сети (VLAN)? Если да, то находится ли сервер в этой же самой VLAN?

Общие рекомендации по конфигурации сети

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

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

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

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

Пять методов диагностики коммутируемых сетей

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

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

Рис. 1. Простейший вариант сети с коммутатором

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

Метод 1. Настройка коммутатора через Telnet или последовательный порт

В процессе поиска неисправности сетевой администратор (если у него есть пароль доступа) может проверить правильность настроек коммутатора путем подключения к консольному порту RS-232 (рис. 2) или с помощью Telnet-сессии.

Рис. 2. Использование консольного порта

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

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

Метод 2. Подключение анализатора к свободному порту коммутатора

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

Рис. 3. Мониторинг с любого свободного порта

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

Трафик, приходящий на порт мониторинга, будет почти полностью состоять из широковещательных фреймов. Возможно, там окажется еще несколько случайных фреймов, пришедших от неизвестных отправителей. Такие фреймы могут появляться из-за старения таблицы MAC. Некоторые невнимательные сетевые администраторы в таких случаях решают, что в сети действительно почти 100% пакетов — широковещательные, и при этом не замечают, что уровень использования (утилизации) сетевых ресурсов очень низкий. В результате делается некорректный вывод о наличии в сети широковещательного шторма. А если жалоб от пользователей не поступало, то администратор вообще может решить, что такая ситуация — часть нормального процесса функционирования сети.

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

Более содержательные результаты могут быть получены при использовании так называемого зеркального копирования (зеркалирования) портов: большинство коммутаторов разрешают копировать трафик из выбранного порта или портов на другой порт, к которому и подключается анализатор (рис. 5). Зеркалирование позволяет прибору «видеть» трафик между сервером и «проблемным» компьютером, пользователь которого жалуется на низкую производительность. У старых моделей коммутаторов в качестве порта для мониторинга можно сконфигурировать специально выделенный порт; на новых коммутаторах для этого подходит любой порт.

Способ реализации данного метода варьируется у различных производителей, но имеется несколько общепринятых способов зеркалирования. Отметим, что в большинстве случаев пакеты, перенаправленные в порт мониторинга, будут отфильтрованы так же, как и пакеты, посылаемые на все остальные порты. Это означает, что все ошибки будут отфильтрованы коммутатором и не достигнут порта мониторинга. Тогда зеркалирование трафика на порт мониторинга может оказаться неэффективным для целей диагностики, поскольку при таком подходе коммутатор скрывает целый класс проблем. Кроме того, чтобы правильно настроить порт мониторинга, нужно подключиться к нему либо с консоли (порт RS-232 на коммутаторе), либо через Telnet-сессию — следовательно, помимо анализатора потребуется еще и компьютер.

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

Пропускная способность порта мониторинга — серьезная проблема. Дело в том, что порт имеет приемную (Rx) и передающую (Tx) части. Передающая часть порта мониторинга может быть заблокирована коммутатором, но независимо от этого пропускная способность приемного канала (от порта коммутатора к анализатору) все равно ограничена. Если зеркалируется полнодуплексный порт, работающий с той же скоростью, что и порт мониторинга, коммутатор может просто отбросить часть трафика, не выдав об этом никакого сообщения. И неважно, подключен прибор по полуили полнодуплексному каналу — ограничение скорости работы приемника все равно будет одним и тем же.

Предположим, возникла необходимость проанализировать трафик сервера, подключенного к коммутатору на скорости 100 Мбит/с по полнодуплексному каналу (рис. 6). При полном дуплексе приемная и передающая части могут соответственно передавать и принимать по 100 Мбит/с трафика каждая. Таким образом, суммарная пропускная способность канала составляет 200 Мбит/с. Для зеркалирования трафика, идущего от сервера, может использоваться только приемник (Rx). Следовательно, размер контролируемого трафика ограничен максимумом в 100 Мбит/с. Любой трафик сервера, превышающий 50% емкости данной линии (200 Мбит/с), будет потерян.

Рис. 6. Ограничение пропускной способности порта мониторинга

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

Очевидное решение проблемы — подключить прибор к высокоскоростному порту, который может принять весь «зеркальный» трафик. Если бы пропускная способность порта мониторинга (см. рис. 6) составляла 1 Гбит/с вместо 100 Мбит/с, совокупный трафик в 200 Мбит/с был бы с легкостью принят и проанализирован.

Метод 3. Установка хаба в тестируемый сегмент

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

Рис. 7. Использование хаба для мониторинга канала подключения сервера

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

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

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

Двухскоростные хабы 10/100 на самом деле представляют собой два хаба — на 10 и 100 Мбит/c, соединенных между собой мостом. Такой хаб использовать можно, только следует убедиться, что сервер и анализатор работают на однойскорости.

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

Метод 4. Использование разветвителя кабеля

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

Рис. 8. Использование разветвителя

Оптические разветвители (сплиттеры) являются пассивными устройствами и не требуют электропитания. Сплиттер характеризуется процентом отводимой оптической мощности (например, разветвитель 80:20 отводит 20% мощности). Очевидно, что добавление сплиттера в линию связи приводит к уменьшению мощности сигнала, поступающего на приемник. А если бюджет по затуханию на этой линии практически исчерпан, то добавление сплиттера неизбежно приведет к нарушению связи. Впрочем, некоторые оптические передатчики более устойчивы к внесению затухания, так что можно попробовать установить сплиттер на другой стороне линии.

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

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

Рис. 9. Функциональная схема работы разветвителя

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

Метод 5. Сбор данных по протоколу SNMP

Самый эффективный метод диагностики коммутируемой сети — запросить информацию о ситуации в сети у самого коммутатора. Это делается удаленно с помощью протокола SNMP (рис. 10) или путем непосредственного подключения к консольному порту коммутатора. Использование SNMP удобнее, поскольку администратору не нужно ходить с ноутбуком от коммутатора к коммутатору — вся информация будет поступать на его рабочее место. Если реализована система управления сетью, можно настроить коммутатор на автоматическую отправку сообщений о событиях, проходящих в сети (SNMP trap), например, об ошибке или выходе значения какого-либо параметра за пределы заданных пороговых значений. Сетевому администратору останется лишь с помощью тестирующего устройства выяснить, почему это нежелательное событие произошло.

Рис. 10. Использование протокола SNMP для мониторинга коммутатора

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

SNMP, пожалуй, самый удобный и наименее разрушительный метод мониторинга коммутируемой сети. SNMPклиент может располагаться в любом месте сети, а доступ к диагностической информации защищен паролем (community string). К одному и тому же коммутатору может быть несколько паролей с различными правами доступа. Ограничения доступа также могут касаться подсетей и даже отдельных IPадресов. В отношении защищенного доступа к коммутатору необходимо обратить внимание на следующее. Большинство коммутаторов поставляется с паролем «public», и просто поразительно, как много сетевых администраторов не меняют его! Еще одна угроза безопасности связана с тем, что пароли передаются по сети в открытом виде. Шифрование предусмотрено в версии SNMPv3, но она пока не получила широкого распространения.

Перечень контролируемых параметров зависит от используемой базы MIB. Большинство производителей коммутаторов предлагают MIB-базы собственной разработки, но можно воспользоваться и стандартной (MIB II, Ethernet-Like Interface MIB, RMON Ethernet, RMON 2, SMON и т.д.).

Маршрутизаторы, через которые проходят SNMP-пакеты, могут накладывать на них различные ограничения, а межсетевые экраны (firewall) могут полностью блокировать SNMP. Кроме того, SNMP-агенты могут работать с ошибками, что приводит к ложным срабатываниям. Тем не менее SNMP в целом является очень полезным средством диагностики.

Заключение

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

Повторное включение портов, отключенных из-за ошибки

После устранения причины проблемы порты остаются отключенными, если на коммутаторе не настроено восстановление из состояния «errdisabled». В этом случае необходимо включить порты вручную. Выполните команду shutdown , а затем — команду интерфейсного режима no shutdown на соответствующем интерфейсе, чтобы вручную включить порты, если не поможет — команду reload для перезагрузки (иногда помогает)

Содержание

Введение

Предварительные условия

     Требования

     Используемые компоненты

     Условные обозначения

Общие сведения

     Платформы, на которых используется отключение из-за ошибки

Состояние «Errdisabled»

     Назначение состояния «Errdisabled»
     Причины возникновения состояния «Errdisabled»
     Проверка нахождения портов в состоянии «Errdisabled»
     Определение причины состояния «Errdisabled» (сообщения консоли, системный журнал и команда «show errdisable recovery»)
     Восстановление порта из состояния отключения из-за ошибки

Связанные обсуждения сообщества поддержки Cisco
Дополнительные сведения

Введение

В данном документе дается определение состояния отключения из-за ошибки, описывается восстановление из этого состояния и предоставляются примеры такого восстановления. В данном документе взаимозаменяемо используются термины «errdisabled» и «отключенный из-за ошибки». Зачастую клиенты обращаются в службу технической поддержки Cisco, когда замечают, что один или несколько портов коммутатора отключены из-за ошибки, т.е. данные порты находятся в состоянии «errdisabled». Такие клиенты хотят знать, почему произошло отключение из-за ошибки и как восстановить нормальное состояние портов.

Примечание: Состояние порта err-disabled отображается в выходных данных команды show interfaces interface_number status .

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты

Для воспроизведения примеров, приведенных в данном документе, необходимы два коммутатора серии Cisco Catalyst 4500/6500 (или эквивалентных) в лабораторной среде с настройками, сброшенными до заводских. На коммутаторах должно быть установлено ПО Cisco IOS®, и у каждого коммутатора должно быть по два порта Fast Ethernet, поддерживающих функции EtherChannel и PortFast.

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

Условные обозначения

Более подробные сведения о применяемых в документе обозначениях см. в документе Cisco Technical Tips Conventions (Условные обозначения, используемые в технической документации Cisco).

Общие сведения

Платформы, на которых используется отключение из-за ошибки

Функция отключения из-за ошибки поддерживается на следующих коммутаторах Catalyst:

• коммутаторы Catalyst со следующим программным обеспечением Cisco IOS:

  • 2900XL / 3500XL

  • 2940 / 2950 / 2960 / 2970

  • 3550 / 3560 / 3560-E / 3750 / 3750-E

  • 4000 / 4500

  • 6000 / 6500

• коммутаторы Catalyst со следующим программным обеспечением Catalyst (CatOS):

  • 2948G

  • 4500 / 4000

  • 5500 / 5000

  • 6500 / 6000

Способ реализации функции отключения из-за ошибки зависит от программной платформы. В этом документе особое внимание уделяется функции отключения из-за ошибки на коммутаторах с программным обеспечением Cisco IOS.

Состояние «Errdisabled»

Назначение состояния «Errdisabled»

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

Когда порт отключается из-за ошибки, он фактически выключается, а прием и отправка трафика через него не выполняются. Цвет индикатора порта становится оранжевым, а при выполнении команды show interfaces
отображается состояние порта err-disabled. Ниже приводится пример вывода данных о порте в состоянии error-disabled из интерфейса командной строки коммутатора:

cat6knative#show interfaces gigabitethernet 4/1 status 

Port    Name       Status       Vlan       Duplex  Speed Type
Gi4/1              err-disabled 100          full   1000 1000BaseSX

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

%SPANTREE-SP-2-BLOCK_BPDUGUARD: 
   Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.
%PM-SP-4-ERR_DISABLE: 
   bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state

Сообщение данного примера отображается, когда порт хоста принимает блок BPDU. Фактический вид сообщения зависит от причины состояния ошибки.

Функция отключения из-за ошибки решает две задачи.

• Она позволяет администраторам знать, когда и где возникла проблема с портом.

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

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

Причины возникновения состояния «Errdisabled»

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

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

• неисправная сетевая интерфейсная плата (с физическими неполадками или проблемами драйверов);

• неправильная конфигурация дуплексного режима порта.

  Неправильная конфигурация дуплексного режима порта является распространенной причиной ошибок из-за невозможности правильного согласования скорости и дуплексного режима между двумя напрямую соединенными устройствами (например, сетевой адаптер, подключенный к коммутатору). Только у полудуплексных соединений могут возникать конфликты в ЛВС. Так как для Ethernet характерен множественный доступ с контролем несущей (CSMA), конфликты являются обычным явлением для полудуплексных соединений, пока они составляют малую часть трафика.

Интерфейс может перейти в состояние «errdisabled» по различным причинам. Среди таких причин могут быть следующие:

• Несоответствие дуплексных режимов

• неправильная конфигурация каналов портов

• нарушение защиты BPDU

• состояние обнаружения однонаправленной связи (UDLD)

• обнаружение поздних конфликтов

• обнаружение переброски канала

• нарушение безопасности

• переброска по протоколу агрегации портов (PAgP)

• защита протокола туннелирования уровня 2 (L2TP)

• ограничение скорости DHCP-отслеживания

• неисправный модуль GBIC, подключаемый модуль малого форм-фактора (SFP) или кабель

• проверка протокола ARP

• встроенное питание

Примечание: По умолчанию для всех таких причин включено обнаружение отключения из-за ошибки. Чтобы отключить обнаружение отключения из-за ошибки, выполните команду no errdisable detect cause . Команда show errdisable detect отображает состояние обнаружения отключения из-за ошибки.

Проверка нахождения портов в состоянии «Errdisabled»

Чтобы определить, был ли порт отключен из-за ошибки, выполняется команда show interfaces .

Пример данных об активном порте:

cat6knative#show interfaces gigabitethernet 4/1 status 
!--- Refer to show interfaces status for more information on the command.

Port    Name               Status       Vlan       Duplex  Speed Type
Gi4/1                      Connected    100          full   1000 1000BaseSX

Ниже приводится пример данных о том же порте в состоянии отключения из-за ошибки:

cat6knative#show interfaces gigabitethernet 4/1 status 
!--- Refer to show interfaces status for more information on the command.

Port    Name               Status       Vlan       Duplex  Speed Type
Gi4/1                      err-disabled 100          full   1000 1000BaseSX

Примечание: Если порт отключен из-за ошибки, индикатор на передней панели, соответствующей данному порту, будет выключен.

Определение причины состояния «Errdisabled» (сообщения консоли, системный журнал и команда «show errdisable recovery»)

Когда коммутатор переводит порт в состояние отключения из-за ошибки, он отправляет консоли сообщение с описанием причины отключения порта. В данном разделе приведены два примера сообщений с причинами отключения портов.

• В первом случае отключение вызвано функцией защиты PortFast BPDU.

• Во втором случае отключение вызвано ошибкой в конфигурации EtherChannel.

Примечание: Эти сообщения можно также увидеть в системном журнале, если выполнить команду show log .

Вот примеры сообщений:

%SPANTREE-SP-2-BLOCK_BPDUGUARD: 
   Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.

%PM-SP-4-ERR_DISABLE: 
   bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state

 %SPANTREE-2-CHNMISCFG: STP loop - channel 11/1-2 is disabled in vlan 1

Если выполнена команда errdisable recovery, можно определить причину состояния «errdisabled» с помощью команды
show errdisable recovery
. Ниже представлен пример:

cat6knative#show errdisable recovery
ErrDisable Reason    Timer Status
-----------------    --------------
udld                 Enabled
bpduguard            Enabled
security-violatio    Enabled
channel-misconfig    Enabled
pagp-flap            Enabled
dtp-flap             Enabled
link-flap            Enabled
l2ptguard            Enabled
psecure-violation    Enabled
gbic-invalid         Enabled
dhcp-rate-limit      Enabled
mac-limit            Enabled
unicast-flood        Enabled
arp-inspection       Enabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface      Errdisable reason      Time left(sec)
---------    ---------------------    --------------
  Fa2/4                bpduguard          273

Восстановление порта из состояния отключения из-за ошибки

В этом разделе предоставляются примеры способов обнаружения портов, отключенных из-за ошибки, и их восстановления, а также краткое обсуждение некоторых дополнительных причин отключения портов из-за ошибки. Чтобы восстановить порт из состояния «errdisabled», сначала необходимо установить и устранить основную причину проблемы, а затем включить порт. Если включить порт, не устранив причину проблемы, он снова будет отключен из-за ошибки.

Исправление основной причины

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

• Неверная конфигурация EtherChannel

  Порты, задействованные в работе EtherChannel, должны обладать согласованными конфигурациями. У портов должны быть одинаковые сети VLAN, режим магистрали, скорость, дуплексный режим и т.д. Большинство отличий конфигураций в рамках одного коммутатора выявляются и заносятся в отчет при создании канала. Если на одной стороне коммутатор настроен для EtherChannel, а на другой — нет, процесс STP может отключить объединенные в канал порты на стороне, настроенной для поддержки режима EtherChannel. В режиме EtherChannel перед объединением портов в канал PAgP-пакеты не отправляются другой стороне для согласования; предполагается, что на другой стороне режим объединения в канал также поддерживается. Кроме того, в данном примере режим EtherChannel не включается на другом коммутаторе, однако соответствующие порты оставляются отдельными, не задействованными в каналах портами. Если оставить другой коммутатор в этом состоянии примерно на минуту, протокол STP коммутатора с включенным режимом EtherChannel считает, что образовалась петля. В результате объединенные в канал порты переводятся в состояние отключения из-за ошибки.

  В данном примере обнаружена петля и отключены порты. В выходных данных команды show etherchannel summary указывается, что Number of channel-groups in use (Число используемых групп каналов) равно 0. Если обратить внимание на один из вовлеченных портов, можно заметить, что он находится в состоянии err-disabled:

  %SPANTREE-2-CHNL_MISCFG: Detected loop due to etherchannel misconfiguration 
  of Gi4/1
  
  
  cat6knative#show etherchannel summary
  !--- Refer to show etherchannel for more information on the command.
  
  Flags:  D - down        P - in port-channel
          I - stand-alone s - suspended
          H - Hot-standby (LACP only)
          R - Layer3      S - Layer2
          U - in use      f - failed to allocate aggregator
  
          u - unsuitable for bundling
  Number of channel-groups in use: 0
  Number of aggregators:           0
  
  Group  Port-channel  Protocol    Ports
  ------+-------------+-----------+-----------------------------------------------

  Режим EtherChannel отключен, так как на данном коммутаторе порты были переведены в состояние «errdisable».

  cat6knative#show interfaces gigabitethernet 4/1 status
  
  Port    Name               Status       Vlan       Duplex  Speed Type
  Gi4/1                      err-disabled 100          full   1000 1000BaseSX

  Чтобы определить характер проблемы, см. соответствующее сообщение об ошибке. В сообщении указывается, что функция EtherChannel обнаружила петлю в дереве STP. В этом разделе описывается возникновение данной проблемы, когда на одном устройстве (в этом случае коммутатор) канал EtherChannel вручную переведен в режим «Включено» (в противоположность режиму согласования), а на другом подключенном устройстве (в этом случае другой коммутатор) канал EtherChannel вообще не включен. Один из способов разрешения этой ситуации заключается в переводе режима канала в состояние «desirable» на обеих сторонах соединения с последующим повторным включением портов. В результате обе стороны формируют канал только после взаимного согласования. Если создание канала не согласовано, обе стороны продолжают функционировать как обычные порты.

  cat6knative(config-terminal)#interface gigabitethernet 4/1
  cat6knative(config-if)#channel-group 3 mode desirable non-silent
  

• Несоответствие дуплексных режимов

  Несоответствие дуплексных режимов встречается довольно часто из-за неудачного автоматического согласования скорости и дуплексного режима. В отличие от полудуплексного устройства, которому приходится дожидаться освобождения своего сегмента ЛВС другими передающими устройствами, дуплексное устройство при необходимости выполняет передачу независимо от других устройств. Если эта передача выполняется одновременно с передачей полудуплексного устройства, данное устройство будет рассматривать это как конфликт (в течение данного временного интервала) или как поздний конфликт (по истечении данного временного интервала). Так как дуплексное устройство никогда не ожидает конфликтов, на этой стороне никогда не допускается необходимость повторной передачи отброшенных пакетов. Низкий процент конфликтов характерен для полудуплексного режима, но не для дуплексного. Регистрация на порте коммутатора слишком большого количества конфликтов обычно указывает на несоответствие дуплексных режимов. Убедитесь, что на обеих сторонах кабеля порты настроены на одинаковые скорость и дуплексный режим. Команда show interfaces interface_number
  предоставляет данные о скорости и дуплексном режиме портов коммутатора Catalyst. Более поздние версии протокола обнаружения Cisco (CDP) могут предупреждать о несоответствии дуплексных режимов перед переводом порта в состояние отключения из-за ошибки.

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

  Ниже перечислены другие возможные причины поздних конфликтов:

  • неисправный сетевой адаптер (с физическими неполадками, а не просто с ошибками конфигурации);

  • неисправный кабель

  • слишком длинный сегмент кабеля

• защита портов BPDU

  В режиме PortFast порт должен подключаться только к конечной станции (рабочей станции или серверу), а не к устройствам, генерирующим BPDU-блоки дерева STP, таким как коммутаторы, мосты или маршрутизаторы, формирующие мостовые соединения. При приеме BPDU-блока дерева STP через порт с включенной STP-функцией PortFast и защитой от пакетов BPDU дерева STP коммутатор переводит порт в состояние «err-disable», чтобы защитить сеть от возможного возникновения петель. Функция PortFast предполагает, что порт коммутатора не может сформировать физическую петлю. Поэтому PortFast пропускает первоначальные проверки протокола STP для данного порта, чтобы избежать тайм-аута конечных станций при загрузке. Сетевые администраторы должны тщательно реализовывать функцию PortFast. На портах с включенной функцией PortFast защита BPDU препятствует образованию петель в ЛВС.

  В следующем примере показано, как включить эту функцию. Этот пример выбран из-за простоты создания ситуации отключения из-за ошибки в данном случае:

  cat6knative(config-if)#spanning-tree bpduguard enable
  !--- Refer to spanning-tree bpduguard for more information on the command.
  
  

  В этом примере коммутатор Catalyst 6509 подключен к другому коммутатору (серии 6509). Коммутатор Catalyst 6500 отправляет блоки BPDU каждые 2 секунды (при использовании настроек STP по умолчанию). При включении режима PortFast для порта коммутатора 6509 функция защиты BPDU отслеживает поступающие в этот порт блоки BPDU. Поступление блока BPDU в порт означает, что устройство не является конечным. В этом случае функция защиты BPDU отключает данный порт во избежание возможного образования петли в дереве STP.

  cat6knative(config-if)#spanning-tree portfast enable
  !--- Refer to spanning-tree portfast (interface configuration mode) 
  !--- for more information on the command.
  
  
  Warning: Spantree port fast start should only be enabled on ports connected
  to a single host.  Connecting hubs, concentrators, switches, bridges, etc. to
  a fast start port can cause temporary spanning tree loops.
  
  %PM-SP-4-ERR_DISABLE: bpduguard error detected on Gi4/1, putting Gi4/1 in 
  err-disable state.

  В этом сообщении коммутатор сообщает о поступлении блока BPDU в порт с поддержкой PortFast, из-за чего коммутатор отключает порт Gi4/1.

  cat6knative#show interfaces gigabitethernet 4/1 status
  
  Port    Name               Status       Vlan       Duplex  Speed Type
  Gi4/1                      err-disabled 100          full   1000 1000BaseSX

  Функцию PortFast необходимо отключить, так как данный порт является портом с непригодным соединением. Соединение является непригодным, так как включена функция PortFast, а коммутатор подключается к другому коммутатору. Необходимо помнить, что функция PortFast используется только на портах, подключенных к конечным станциям.

  cat6knative(config-if)#spanning-tree portfast disable
  

• UDLD

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

  Примечание: Работа UDLD основана на обмене пакетами протокола между соседними устройствами. Устройства на обеих сторонах соединения должны поддерживать протокол UDLD. Этот же протокол должен поддерживаться на соответствующих портах. Если UDLD включен только на одном порте, на этом конце соединения может быть настроен переход UDLD в состояние «err-disable».

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

  PM-SP-4-ERR_DISABLE: udld error detected on Gi4/1, putting Gi4/1 in 
  err-disable state.

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

• Ошибка неустойчивости соединения (link-flap)

  Неустойчивость соединения означает постоянное подключение и отключение интерфейса. Если число таких ошибок за 10 секунд больше пяти, интерфейс переводится в состояние «err-disable». Распространенной причиной неустойчивости соединения являются проблемы первого уровня (L1), такие как неисправность кабеля, несоответствие дуплексных режимов или неисправная плата GBIC. Просмотрите сообщения консоли или сообщения, отправленные на сервер системного журнала, в которых сообщается причина отключения портов.

  %PM-4-ERR_DISABLE: link-flap error detected on Gi4/1, putting Gi4/
  1 in err-disable state

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

  cat6knative#show errdisable flap-values
  !--- Refer to show errdisable flap-values for more information on the command.
  
  ErrDisable Reason    Flaps    Time (sec)
  -----------------    ------   ----------
  pagp-flap              3       30
  dtp-flap               3       30
  link-flap              5       10

• Ошибка обратной петли (loopback)

  Ошибка обратной петли возникает, когда пакет запроса keepalive возвращается обратно к отправившему его порту. По умолчанию коммутатор отправляет запросы keepalive всем интерфейсам. Устройство может отправлять пакеты обратно исходному интерфейсу по петле, которая обычно возникает из-за наличия в сети логической петли, не заблокированной протоколом STP. Исходный интерфейс принимает отправленный им пакет сообщения keepalive, а коммутатор отключает данный интерфейс (errdisable). Когда пакет keepalive возвращается обратно к отправившему его порту, появляется следующее сообщение:

  %PM-4-ERR_DISABLE: loopback error detected on Gi4/1, putting Gi4/1 in
  err-disable state

  По умолчанию в ПО на базе Cisco IOS версии 12.1EA сообщения keepalive отправляются всеми интерфейсами. В программном обеспечении на базе Cisco IOS 12.2SE или более поздней версии сообщения keepalive по умолчанию не отправляются оптоволоконными и восходящими интерфейсами. Дополнительные сведения см. в описании ошибки с идентификатором CSCea46385
  
  (registered customers only)
  .

  Предлагаемый обходной путь заключается в отключении запросов keepalive и обновлении до ПО Cisco IOS 12.2SE или более поздней версии.

• Нарушение защиты порта

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

  cat6knative(config-if)#switchport port-security violation shutdown
  

  Нарушение безопасности происходит в следующих двух ситуациях:

  • Когда на защищенном порте число защищенных MAC-адресов достигло максимума, а исходный MAC-адрес входящего трафика не совпадает ни с одним из идентифицированных защищенных MAC-адресов.

    В этом случае защитой порта применяется настроенный режим нарушения.

  • Если трафик с защищенным MAC-адресом, настроенный или полученный на одном защищенном порте, пытается получить доступ к другому защищенному порту в той же сети VLAN.

    В этом случае защита порта применяет режим нарушения завершения работы.

  Дополнительные сведения о защите порта см. в документе Настройка защиты порта.

• Защита L2pt

  Когда блоки PDU уровня 2 входят в туннель или порт доступа на входящем пограничном коммутаторе, коммутатор заменяет пользовательский MAC-адрес PDU-назначения хорошо известным проприетарным адресом многоадресной рассылки Cisco: 01-00-0c-cd-cd-d0. Если включено туннелирование 802.1Q, пакеты также помечаются двумя тегами. Внешний тег является пользовательским тегом муниципальной сети, а внутренний тег — пользовательским тегом сети VLAN. Основные коммутаторы игнорируют внутренние теги и пересылают пакет всем магистральным портам в одной муниципальной сети VLAN. Пограничные коммутаторы на исходящей стороне восстанавливают данные о необходимом протоколе уровня 2 и MAC-адресе и пересылают пакеты всем туннельным портам или портам доступа внутри одной муниципальной сети VLAN. Поэтому блоки PDU уровня 2 сохраняются неизмененными и через инфраструктуру сервис-провайдера доставляются на другую сторону сети заказчика.

  Switch(config)#interface gigabitethernet 0/7
  l2protocol-tunnel {cdp | vtp | stp}
  

  Интерфейс переходит в состояние отключения из-за ошибки. Если инкапсулированный блок PDU (с собственным MAC-адресом назначения) получен из туннельного порта или порта доступа с включенным туннелированием уровня 2, туннельный порт отключается, чтобы предотвратить появление петель. Этот порт также отключается, когда достигается пороговое значение завершения работы для данного протокола. Порт можно снова включить вручную (выполнив последовательность команд shutdown, no shutdown
  ), или если включено восстановление из состояния «errdisabled», данная операция повторяется через указанный интервал времени.

  Интерфейс можно восстановить из состояния «errdisabled» включив порт с помощью команды errdisable recovery cause l2ptguard. Эта команда используется для настройки механизма восстановления после ошибки «максимальной скорости» уровня 2, чтобы интерфейс можно было вывести из отключенного состояния и попытаться снова использовать. Можно также задать временной интервал. Восстановление из состояния «errdisabled» по умолчанию отключено; при включении временной интервал по умолчанию равен 300 секундам.

• Неисправный SFP-кабель

  Порты переходят в состояние «errdisabled» с сообщением об ошибке %PHY-4-SFP_NOT_SUPPORTED при подключении коммутаторов Catalyst 3560 и Catalyst 3750 с помощью соединительного SFP-кабеля.

  Соединительный SFP-кабель для коммутаторов Cisco Catalyst 3560 (CAB-SFP-50CM=) является бюджетным решением для соединений Gigabit Ethernet типа «точка-точка» между коммутаторами серии Catalyst 3560. 50-сантиметровый кабель является альтернативой использованию трансивера SFP при соединении коммутаторов серии Catalyst 3560 через SFP-порты на небольших расстояниях. Все коммутаторы серии Cisco Catalyst 3560 поддерживают соединительные SFP-кабели.

  При подключении коммутатора Catalyst 3560 к коммутатору Catalyst 3750 или любой другой модели коммутатора Catalyst нельзя использовать кабель CAB-SFP-50CM=. Два коммутатора можно соединить с помощью медного кабеля с SFP (GLC-T) на обоих устройствах вместо кабеля CAB-SFP-50CM=.

Повторное включение портов, отключенных из-за ошибки

После устранения причины проблемы порты остаются отключенными, если на коммутаторе не настроено восстановление из состояния «errdisabled». В этом случае необходимо включить порты вручную. Выполните команду shutdown
, а затем — команду интерфейсного режима no shutdown на соответствующем интерфейсе, чтобы вручную включить порты.

Команда errdisable recovery позволяет выбрать тип ошибок, после которых порты снова автоматически включаются через указанный промежуток времени. Команда show errdisable recovery показывает состояние по умолчанию после восстановления из состояния отключения из-за ошибки для всех возможных условий.

cat6knative#show errdisable recovery
ErrDisable Reason    Timer Status
-----------------    --------------
udld                 Disabled
bpduguard            Disabled
security-violatio    Disabled
channel-misconfig    Disabled
pagp-flap            Disabled
dtp-flap             Disabled
link-flap            Disabled
l2ptguard            Disabled
psecure-violation    Disabled
gbic-invalid         Disabled
dhcp-rate-limit      Disabled
mac-limit            Disabled
unicast-flood        Disabled
arp-inspection       Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Примечание: Стандартный интервал тайм-аута равен 300 секундам, и по умолчанию он отключен.

Чтобы включить errdisable recovery и выбрать состояния отключения из-за ошибки, выполните следующую команду:

cat6knative#errdisable recovery cause ?
  all                 Enable timer to recover from all causes
  arp-inspection      Enable timer to recover from arp inspection error disable
                      state
  bpduguard           Enable timer to recover from BPDU Guard error disable
                      state
  channel-misconfig   Enable timer to recover from channel misconfig disable
                      state
  dhcp-rate-limit     Enable timer to recover from dhcp-rate-limit error
                      disable state
  dtp-flap            Enable timer to recover from dtp-flap error disable state
  gbic-invalid        Enable timer to recover from invalid GBIC error disable
                      state
  l2ptguard           Enable timer to recover from l2protocol-tunnel error
                      disable state
  link-flap           Enable timer to recover from link-flap error disable
                      state
  mac-limit           Enable timer to recover from mac limit disable state
  pagp-flap           Enable timer to recover from pagp-flap error disable
                      state
  psecure-violation   Enable timer to recover from psecure violation disable
                      state
  security-violation  Enable timer to recover from 802.1x violation disable
                      state
  udld                Enable timer to recover from udld error disable state
  unicast-flood       Enable timer to recover from unicast flood disable state

В этом примере показано, как разрешить условие восстановления из состояния «errdisabled» при включенной защите BPDU:

cat6knative(Config)#errdisable recovery cause bpduguard

Полезное свойство этой команды состоит в том, что при включении восстановления из состояния «errdisabled», команда выдает список общих причин перевода портов в состояние отключения из-за ошибки. В следующем примере обратите внимание на то, что функция защиты BPDU была причиной отключения порта 2/4:

cat6knative#show errdisable recovery
ErrDisable Reason    Timer Status
-----------------    --------------
udld                 Disabled
bpduguard            Enabled
security-violatio    Disabled
channel-misconfig    Disabled
pagp-flap            Disabled
dtp-flap             Disabled
link-flap            Disabled
l2ptguard            Disabled
psecure-violation    Disabled
gbic-invalid         Disabled
dhcp-rate-limit      Disabled
mac-limit            Disabled
unicast-flood        Disabled
arp-inspection       Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface      Errdisable reason      Time left(sec)
---------    ---------------------    --------------
  Fa2/4                bpduguard          290

Если разрешено любое из условий восстановления из состояния «errdisabled», порты с таким условием снова включаются через 300 секунд. Это значение по умолчанию (300 секунд) можно изменить, выполнив следующую команду:

cat6knative(Config)#errdisable recovery interval timer_interval_in_seconds

В следующем примере длительность интервала восстановления из состояния «errdisabled» изменяется с 300 на 400 секунд:

cat6knative(Config)#errdisable recovery interval 400

Проверка

• show version— отображение версии программного обеспечения, используемого на данном коммутаторе.

• show interfaces interface interface_number status— отображение текущего состояния порта коммутатора.

• show errdisable detect— отображение текущих настроек функции тайм-аута состояния «err-disable» и, если в данный момент есть порты, отключенные из-за ошибки, причины их отключения.

Устранение неполадок

• show interfaces status err-disabled— отображение локальных портов в состоянии отключения из-за ошибки.

• show etherchannel summary— отображение текущего состояния EtherChannel.

• show errdisable recovery— отображение периода времени, по истечении которого интерфейсы восстанавливаются из состояния «errdisabled».

• show errdisable detect— отображение причины состояния «err-disable».

Дополнительные сведения об устранении неполадок с портами коммутаторов см. в документе Устранение интерфейсных проблем и неполадок портов коммутатора.

http://www.cisco.com/cisco/web/support/RU/10/105/105416_errdisable_recovery.html

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

Интеллектуальные функции коммутаторов

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

Flow Control

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

Jumbo Frame

В простонародье «пакеты увеличенного объема», что актуально в гигабитных свитчах с пропускной способностью 1 Гбит/сек и более. В определенных случаях прирост передачи достигает 300%, если принимающее и передающее оборудование поддерживают Jumbo Frame.

На сегодняшний день этот протокол можно назвать прогрессивной альтернативой уже устаревающего Ethernet, однако на обработку каждого пакета затрачивается больше времени. Основная мысль следующая: чем больше объем блока, тем меньше пакетов понадобится, и скорость обработки будет выше. Но если говорить простыми словами, тут как с Wi-Fi 6: перспективно, но пока рановато, если у вас не подготовлена инфраструктура.

Full-duplex и Half-duplex

Стандартная функция параллельного приема и передачи (Full) без потери пакетов данных и повышения нагрузки на оборудования. В режиме Half информация бродит по кабелям только в одну сторону.

QoS

Другими словами — приоритизация трафика согласно протоколу IEEE 802.1p. Коммутатор в этом режиме способен понимать, кому отдавать «полезное пространство» в сети (VoIP, видеоконференция), выделяя под эти нужды часть канала передачи данных. Если на вашем предприятии акцент делается на общение с клиентами, связь — функционал незаменим.

VLAN

Виртуальная сеть внутри физической (протокол IEEE 802.1q). На нее можно повесть отдельные права доступа, дать определенную пропускную способность, ограничить параметры для конкретных пользователей. Эдакий выделенный канал для привилегированных (начальство, бухгалтерия, администрация). Функция полезна, но зачастую лишь в корпоративном сегменте.

Traffic Segmentation

Иногда на коробке сегментация трафика описана как DES-3828. Функция необходима для разграничения доменных адресов на канальном уровне. Администратор может настраивать группы портов, или отдельные гнезда в режиме полной изоляции друг от друга. При этом оба порта по-прежнему подключены к одному серверу или сетевой магистрали.

Port mirroring

Зеркалирование (дублирование) трафика может потребоваться в тех случаях, если необходимо максимально повысить надежность сети. Простыми словами: одна и та же информация отправляется сразу на два-три источника согласно протоколам SPAN/RSPAN. Затем данные проверяются на совместимость. Если по одному из путей что-то не совпадает — можно паниковать и искать виновных.

Loopback Detection

Другая маркировка — LBD, Spanning Tree Protocol. Сегодня уже устаревшая функция, поскольку устаревшие концентраторы (хабы) практически никто не использует. Но если у кого-то есть неуправляемый коммутатор, где периодически встречаются закольцованные участки сети — штука полезная.

Система автоматически блокирует кольцевание, которое зачастую является причиной тормозов, понижения производительности. Выполняют это протоколы STP:

• IEEE 802.1d;
• IEEE 802.1w;
• IEEE 802.1s.

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

Link Aggregation

Агрегация работает по протоколу IEEE 802.3ad и по факту объединяет несколько физических портов в один логический с увеличенной пропускной способностью. Благодаря технологии можно выдать по кабелю до 8 Гбит/сек, что критически важно для скоростных магистралей.

Стекирование коммутаторов

Стекирование — это физическое объединение нескольких коммутаторов в единый кластер с большим количеством портов. Если на предприятии требуется хаб, в котором от 48 Ethernet-розеток и более, всегда обращайте внимание на стекирование. Для домашнего использования функционал бесполезен, при этом сильно повышает итоговую стоимость оборудования. А вот на крупных предприятиях, и в коммерческих структурах — must have.

IGMP Snooping

Протокол блокировки IPTV для тех абонентов внутри сети, которые подобный функционал не заказывали. Бонус от такой особенности — освобождение пропускной способности канала от multicast-трафика, при этом никто не будет жаловаться, что «как-то оно тормозит, хотя я плачу за условные 100 Мбит/с».

Обратная сторона технологии — повышенные требования к железу коммутатора, а именно к памяти, CPU и NPU-блокам машинного обучения. Устройство должно запоминать и регулярно контролировать, какой поток по какому порту передает. Это полезно с точки зрения оптимизации трафика, но классическая ретрансляция всем абонентам обходится в разы дешевле.

Storm Control

Если грубо — защита от DDoS и попыток обрушить сеть «мусорными» пакетами. Представьте, что огромное количество широковещательных пакетов — различный канализационный хлам, который моментально закупоривает трубопровод и не дает возможности воде ходить по линии. Storm Control — фильтр на пути к вот таким издевательствам.

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

В случае с однонаправленным штормом мы имеем дело с нацеленными атаками огромным количеством ICMP-протоколов диагностики перегрузки сети на определенный порт. В результате все участники отвечают на сервисный ICMP-запрос на адрес «жертвы».

Дополнительные функции коммутаторов

Если с основными возможностями разобрались, давайте переходить к опциональным. Здесь нас интересуют:

• Диагностика кабеля — автоматические определение неисправности в проводах при включении оборудования (КЗ, обрыв жилы, открытая изоляция). Зачастую порт при этом горит определенным цветом;
• Защита от вирусов (Safeguard Engine) — стабильность сети, отсеивание мусорного трафика в помощь фаерволам, малварям и антивирусному ПО;
• Энергосбережение (Ethernet 802.3az) — самостоятельно переводит нерабочие порты в спящий режим, что позволяет сократить расходы на электроэнергию на 50-80%;
• Power over Ethernet (PoE, IEEE 802.af) — возможность питать оборудование по витой паре.

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

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

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

Основные операции коммутатора

Коммутация
представляет собой технологию, которая
уменьшает вероятность переполнения в
сетях Ethernet, Token Ring и Fiber Distributed Data Interface
(FDDI). В сетях LAN коммутаторы часто
используются для замены совместно
используемых концентраторов. Коммутаторы
LAN разрабатываются таким образом, чтобы
они могли быть установлены в уже
существующие кабельные сетевые
инфраструктуры без нарушения уже
сложившегося характера работы сети. В
современных коммуникациях все
коммутирующие устройства выполняют
две основные операции:

■ Коммутация
фреймов данных.
Эта операция состоит в получении фрейма
из входной передающей среды и передаче
его в выходную среду.

■ Поддержка
операций по коммутации.
При своей работе коммутатор строит и
поддерживает таблицы коммутации.

Под
мостовыми
операциями (bridging)
понимается технология, в которой
устройство, известное как мост, соединяет
два или более сегментов сети LAN.
Коммутаторы были разработаны с
использованием мостовых технологий и
часто рассматриваются как многопортовые
мосты. Мост передает дейтаграммы из
одного сегмента к получателям, находящимся
в других сегментах. Когда включается
питание и начинается функционирование
моста, он изучает МАС-адреса поступающих
дейтаграмм и строит таблицу адресов
известных ему получателей. Если мосту
известно, что пункт назначения дейтаграммы
находится в том же сегменте где и ее
отправитель, то дейтаграмма отбрасывается,
поскольку в ее передаче нет необходимости.
Если мосту известно, что получатель
находится в другом сегменте, то он
передает ее только в этот сегмент. Если
же сегмент пункта назначения неизвестен,
то мост передает дейтаграмму во все
сегменты, кроме того, в котором находится
отправитель этой дейтаграммы. Такая
передача называется лавинной рассылкой
(flooding). Основным достоинством моста
является ограничение перемещения
потоков данных лишь некоторыми сетевыми
сегментами. Как мосты, так и коммутаторы
соединяют между собой сегменты сети
LAN, используют МАС-адреса для определения
сегмента, в который требуется передать
дейтаграмму и уменьшают объем передаваемых
данных. В современных сетях коммутаторы
выполняют большее количество функций,
чем мосты, поскольку они позволяют
осуществлять большее количество
соединений, работают с гораздо большими
скоростями, чем мосты, а также поддерживают
новые функции, такие как виртуальные
локальные сети (virtual LAN — VLAN). В мостах
коммутацию обычно осуществляет
программное обеспечение, в то время
как в коммутаторах коммутация обычно
выполняется аппаратно.

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

Операции,
выполняемые LAN-коммутатором

• Пересылает
пакеты на основе данных таблицы пересылки

— Пересылает
пакеты на основе МАС-адреса (2-й уровень)

• Функционирует
на 2-м уровне модели OSI

• Узнает
расположение станции путем исследования
адреса отправителя

— Осуществляет
рассылку со всех портов если адрес
получателя является широковещательным,
многоадресатным или неизвестен

— Осуществляет
пересылку в том случае, если получатель
расположен на другом интерфейсе

10
Мбит/с

Рис.
5.17. Операции LAN-коммутатора

Следует
помнить о том, что при прохождении
потоков данных по сети коммутатор
функционирует на 2-м уровне; это означает,
что коммутатор просматривает адрес
МАС-уровня. При передаче фреймов станцией
А и получении их коммутатором, последний
просматривает МАС-адрес отправителя
и сохраняет его в адресной таблице, как
показано на рис. 5.18. При прохождении
данных через коммутатор в адресной
таблице создается новая позиция, в
которую заносится адрес станции-отправителя
и интерфейс коммутатора, к которому
она подсоединена. После этого коммутатору
известно где подсоединена станция А.
Как показано на рис. 5.19, после поступления
фрейма данных на коммутатор он лавинным
образом рассылается на все порты,
поскольку станция-получатель пока
неизвестна.

10
Мбит/с

Рис.
5.19. Лавинная рассылка на все порты

Однако
после создания соответствующей позиции
в адресной таблице поступает ответ от
станции В к станции А. Теперь коммутатору
известно, что станция В подсоединена
к 4-му интерфейсу, как показано на рис.
5.20.

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

Первоначальная
передача указала МАС-адрес станции, от
которой поступили данные, что позволило
коммутатору более эффективно осуществлять
передачу данных.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #