Как проверить свитч на ошибки

Как проверить сетевой коммутатор?

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

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

Коммутатор как проверить с помощью консоли?

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

Как проверить коммутатор самостоятельно?

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

  1. Подключите ноутбук напрямую к сетевому источнику – модему или маршрутизатору – с помощью Ethernet-кабеля. Далее следует открыть веб-браузер, чтобы убедиться, есть ли доступ Интернет. Если это получилось, Ваш модем или маршрутизатор работают должным образом.
  2. Подключите один сетевой кабель от модема или маршрутизатора к порту, обозначенному “WAN” на коммутаторе.
  3. Подключите другой сетевой кабель от Вашего ноутбука к порту “LAN 1” на Вашем коммутаторе.
  4. Нажмите кнопку “Сброс” на задней панели модема или маршрутизатора, чтобы перезагрузить устройство. Если этого не сделать, свитч может не определиться.
  5. Подключите адаптер питания сетевого коммутатора в розетку электросети после завершения загрузки модема или маршрутизатора.
  6. Проверьте, мигают ли зелёные индикаторы над портами “WAN” и “LAN 1” на коммутаторе. Мигающий зелёный свет обозначает активное соединение. Откройте веб-браузер на Вашем ноутбуке, чтобы убедиться, что соединение активно.
  7. Отключите сетевой кабель от порта “LAN 1” и подключите его к каждому из оставшихся портов коммутатора. При проверке каждого порта следует проверять мигающий зелёный индикатор, а затем, как и при предыдущем шаге, делать проверку соединения через веб-браузер на ноутбуке.

Таким образом, с помощью данного способа задача “как самому проверить сетевой коммутатор” оказывается достаточно простой и не требующей никаких специальных знаний и навыков.

Время на прочтение
2 мин

Количество просмотров 5.6K

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

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

  • модули python3: serial и tkinter;

  • сведенный к дефолтным настройкам коммутатор Dlink DGS-1210-28/ME;

  • в моем случая «модеризированный патч-корд» из 4 штук в одной шине (картинка в конце текста), но можно и обычный патч-корд.

Для удобства была написана программа gui на python 3. Она разбита на два модуля, один из которых реализует подключение по COM порту, второй — графический интерфейс.

Подробный алгоритм диагностики портов:

  1. включаем коммутатор (ждем когда загрузится), подключаем его к компьютеру через конвертор USB to RS-232;

  2. Чтобы узнать какие USB устройства у вас подключены можно воспользоваться командой:
    ls /dev/ttyUSB*;
    (номер(строка) идущая после «USB» указать при запуске скрипта main.py)

  3. запускаем программу командой:
    python3 main.py 0
    0
    — это часть имени USB to RS-232, который в программе представлен как:
    port = "/dev/ttyUSB"+str(sys.argv[1]);
    у вас эта часть может отличаться.

  4. запускаем параллельно в другом терминале minicom командой:
    minicom -D /dev/ttyUSB0 -b 9600;
    после запуска нажать несколько раз Enter, чтобы пройти строки авторизации;

  5. коммутируем порты витой пары или SFP. Нажимаем кнопки графического интерфейса, что в свою очередь генерирует данные диагностики кабеля соответствующего порта.

Диагностику можно проводить как на одном так и на множестве коммутаторов:

Четыре совмещенных патч-корда склеил для удобства, в основном пользуюсь одним из них, переключая и проверяя сразу 4 порта (8 — если на одном коммутаторе).
SFP так же можно диагностировать, для этих портов прописанное отдельное условие для команды коммутатора show ports <номер порта(25-28)>.

Программу планирую дорабатывать:

  • универсальность для DGS 3120, 3100, 1210;

  • индикация о состоянии кабелей;

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

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

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

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

Один из распространенных методов проверки свитча на работоспособность – это удаленный пинг (ping test). Он позволяет определить, работает ли свитч, а также проверить задержку и потери пакетов при обмене данными. Для проведения теста введите команду «ping» в командной строке и укажите IP-адрес компьютера или другого устройства в сети.

Содержание

  1. Шаги проверки работоспособности свитча
  2. Очистите свитч
  3. Проверьте подключение
  4. Проверьте питание
  5. Проверьте соединение с другими устройствами
  6. Проведите диагностику портов
  7. Проверьте наличие ошибок и проблем
  8. Проверьте конфигурацию свитча
  9. Произведите тестирование свитча
  10. Вопрос-ответ

Шаги проверки работоспособности свитча

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

Ниже приведены основные шаги, которые помогут вам проверить работоспособность свитча:

  1. Проверьте питание свитча. Убедитесь, что устройство подключено к электрической сети и включено.
  2. Проверьте светодиодные индикаторы на передней панели свитча. Они могут указывать наличие питания, активность портов, ошибки и другую информацию о работе устройства.
  3. Проверьте физические соединения свитча, включая подключение сетевых кабелей к соответствующим портам. Убедитесь, что все кабели правильно подключены и надежно закреплены.
  4. Проверьте настройки свитча. Войдите в интерфейс управления устройством и убедитесь, что все настройки соответствуют требованиям вашей сети.
  5. Проверьте функциональность портов свитча. Подключите конечные устройства (компьютеры, принтеры и т. д.) к портам свитча и убедитесь, что они подключаются к сети и функционируют нормально.
  6. Проверьте скорость и пропускную способность свитча. Проведите тест скорости и пропускной способности сети с использованием специальных инструментов или онлайн-сервисов. Убедитесь, что свитч обеспечивает необходимую производительность и скорость передачи данных.
  7. Проверьте наличие обновлений программного обеспечения для свитча. Периодически проверяйте наличие новых версий прошивки или программного обеспечения у поставщика свитча и обновляйте их при необходимости. Обновление программного обеспечения может исправить ошибки, улучшить безопасность и добавить новые функции.

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

Очистите свитч

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

Для очистки свитча выполните следующие шаги:

  1. Отключите питание. Прежде чем начать очищать свитч, убедитесь, что он полностью отключен и не подключен к источнику электропитания. Это важно для вашей личной безопасности.
  2. Возьмите мягкую щетку или влажную тряпку. Мягкая щетка или тряпка помогут удалить пыль и грязь без повреждения самого свитча.
  3. Помойте свитч. Для более тщательной очистки свитча вы можете использовать слегка увлажненную тряпку или специальные очищающие средства. Однако, перед использованием каких-либо жидкостей, убедитесь, что они безопасны для использования с вашим свитчем.
  4. Дайте свитчу высохнуть полностью. После того, как вы произвели очистку свитча, дайте ему полностью высохнуть перед подключением обратно к источнику питания. Это поможет предотвратить возникновение короткого замыкания или других проблем связанных с влагой.

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

Проверьте подключение

Перед тем как приступить к проведению проверки свитча на работоспособность, убедитесь, что он правильно подключен к сети и к другим устройствам.

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

  1. Убедитесь, что свитч включен в электрическую розетку или имеет подключение к источнику питания.
  2. Проверьте, что сетевой кабель правильно подключен к свитчу и к другим устройствам (например, компьютерам или маршрутизаторам). Убедитесь, что кабель не поврежден и к нему не присоединен оборванный или сломанный коннектор.
  3. Проверьте светодиодные индикаторы на свитче. Они могут сигнализировать о состоянии подключения. Убедитесь, что индикаторы горят или мигают в соответствии с ожидаемым состоянием.
  4. Если у вас есть доступ к административной панели свитча (обычно через веб-интерфейс), проверьте настройки сети. Убедитесь, что IP-адрес и другие сетевые настройки настроены правильно. Также проверьте наличие обновлений программного обеспечения для свитча.

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

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

Проверьте питание

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

Вот несколько шагов, которые вы можете выполнить, чтобы проверить питание свитча:

  1. Убедитесь, что кабель питания правильно подключен как к свитчу, так и к источнику питания.
  2. Проверьте, есть ли электроснабжение в розетке или источнике питания, к которому подключен свитч. Для этого можно использовать другое электроприборное устройство, чтобы убедиться, что оно работает.
  3. Если свитч подключен к источнику питания через предохранитель, убедитесь, что предохранитель не сгорел и все контакты в порядке.

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

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

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

Для проверки соединения с другими устройствами можно воспользоваться следующими шагами:

  1. Подключите другое устройство к свитчу — это может быть компьютер, ноутбук, принтер или другое сетевое устройство. Убедитесь, что он подключен к правильному порту на свитче и настройки сети установлены правильно.
  2. Проверьте соединение — убедитесь, что связь между свитчем и подключенным устройством работает. Можно воспользоваться командой ping для проверки доступности других устройств в сети.
  3. Проверьте скорость передачи данных — с помощью специальных инструментов можно проверить скорость передачи данных между свитчем и другими устройствами. Это поможет определить, работает ли свитч с максимальной скоростью.
  4. Проверьте наличие маршрутизации — если в сети находятся другие свитчи или маршрутизаторы, убедитесь, что свитч правильно настроен для передачи данных между ними.

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

Проведите диагностику портов

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

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

  1. Подключите сетевой кабель от устройства, которое вы хотите проверить, к одному из портов свитча. Убедитесь, что кабель надежно подключен к порту.
  2. На своем компьютере откройте командную строку (в Windows можно воспользоваться комбинацией клавиш Win+R, введите «cmd» и нажмите Enter).
  3. В командной строке введите команду «ipconfig» и нажмите Enter. Вы увидите информацию о сетевых адаптерах, включая IP-адрес вашего компьютера.
  4. Сравните IP-адрес вашего компьютера с IP-адресами, полученными от свитча. Если оба адреса находятся в одной подсети, это означает, что порт свитча работает корректно и устройство подключено правильно.

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

Проверьте наличие ошибок и проблем

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

Для начала, проверьте наличие следующих проблем:

  1. Отсутствие питания: Убедитесь, что свитч подключен к источнику питания. Проверьте наличие электричества и работу розетки.
  2. Проблемы с кабелями: Проверьте состояние сетевых кабелей. Убедитесь, что они не повреждены или обрываются. При необходимости замените кабель.
  3. Проблемы с подключением: Проверьте правильность подключения устройств к свитчу. Убедитесь, что все кабели подключены и фиксируются надлежащим образом.
  4. Проблемы с настройками: Проверьте настройки свитча. Убедитесь, что они соответствуют требованиям и правильно сконфигурированы.

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

Проверьте конфигурацию свитча

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

  1. Подключитесь к свитчу через терминал. Для этого вам потребуется использовать консольный кабель и программу эмуляции терминала, такую как PuTTY или SecureCRT. Убедитесь, что вы подключены к правильному порту и настройте параметры соединения (скорость передачи, биты данных, контроль четности и прочее) в соответствии с требованиями свитча.
  2. Войдите в систему управления свитчем. Вам может потребоваться ввести учетные данные (логин и пароль), чтобы получить доступ к интерфейсу управления свитчем. Учетные данные предоставляются поставщиком свитча или могут быть настроены вами или вашей компанией.
  3. Проверьте текущую конфигурацию свитча. В интерфейсе управления свитчем вы можете найти различные разделы и настройки, отвечающие за работу устройства. Проверьте настройки портов, включая скорость передачи данных, режим работы (внешний или внутренний), наличие идентификаторов VLAN и другие параметры.
  4. Проверьте наличие обновлений прошивки. Свитч может быть обновлен до более новой версии прошивки, которая может включать в себя исправления ошибок и новые функции. Проверьте наличие обновлений на официальном сайте производителя и, если необходимо, выполните процесс обновления прошивки.

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

Произведите тестирование свитча

Для тестирования работоспособности свитча нужно выполнить следующие шаги:

  1. Подключите свитч к электрической сети и убедитесь, что он включен.
  2. Подключите компьютеры или другие устройства к портам свитча с помощью Ethernet-кабелей.
  3. Убедитесь, что световые индикаторы на портах свитча горят или мигают, что говорит о наличии соединения.
  4. Откройте командную строку на компьютере и выполните команду «ipconfig» (для Windows) или «ifconfig» (для Linux и Mac). Убедитесь, что компьютер получил IP-адрес от свитча.
  5. Проверьте скорость и стабильность соединения между компьютерами. Для этого можно выполнить пинг одного компьютера с другого или выполнить скоростной тест с помощью специальных онлайн-сервисов.
  6. Если все проверки прошли успешно, то свитч работоспособен и соединение между компьютерами установлено.

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

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

Вопрос-ответ

попал в руки D-Link DES-1016D (100mb, 16port). По легенде он сломан (что то сгорело). Отдал мне его директор фирмы в которой он стоял когда-то (уже прошло достаточно продолжительное время). При визуальном осмотре внутренностей ничего не увидел. Методом тыка выбрал два порта и подключил к ним сеть. работает. Как можно определить что в нем неисправно

Проверить все порты по очереди?

P.S. Сталкивался с управляемыми свитчами Compex, из-за ошибки в прошивке при большой нагрузке просто висел.

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

Возможно. Не мой случай — 100% :) Официально признанная бага для того свитча.

У меня свич D-link 1226G однажды просто повис из-за перегрева, помогло только полный ресет+настройка заново, сброс по питанию не помогал. А порты могут и работать, но будут такиииииииие тормоза по сети…

1016 это тупой свич, никаких настроект в нем нет

Dlink иногда флудят, генерируя холостой трафик …

такое за ними замечал только после грозы…

так все-таки как определить то? идей кроме проверки поочередно всех портов я не услышал. :(

в любом случае, часть диагностики — внимательно выслушать предыдущего владельца :)

предыдущий владелец ничего не знает. к нему подошел бывший(!) сисадмин и сказал что он сгорел. коммутатор поменяли

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

16 портов проверить не так уж и долго, от силы час, но это ты еще и скорость замереешь и качество линии и еще кучу всего

каким образом это сделать? в наличии есть три машины

берешь с одной машины на другую копируешь N-нное количество фильмов или запускаешь пинг. и втыкаешь второй хвост по очереди во все порты

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

и его потом никто не увидит :-)))
где мои три свича??

на самом деле однажды встречал забавный глюк у горевшего после грозы свитча Corega:
если два компа соединить в любые два порта — сеть 100 мегабит пашет на ура
но если подключить еще третий порт к третьему компу………. :)))) полный за глюк, пакеты тутже перестают ходить, и вообще не работает, в плоть до того что сетевухи с ума сходили, и приходилось тачку перегружать, дабы справиться с повисанием сети….
это не сказка, свитч реально так работал, и был успешно заменен по гарантии :)))

SFx писал(а)
на самом деле однажды встречал забавный глюк у горевшего после грозы свитча Corega:

это не сказка, свитч реально так работал, и был успешно заменен по гарантии :)))

Это Вам сильно повезло, что после грозы (!!!) свич поменяли — случай-то негарантийный.

на такие случае вообще грозозащиты есть … хотя при стоимости 5-8 портовых свитчей около $10 — проще их менять.

они не работают…. проверно…
да и землю найти в наших хрущевках сложнее чем свитчи менять …

а потому что в Москве брали… тама нет понятия не гарантийный случай — слишком большая конкуренция среди фирм… и качество обслуживание столичное… :)
хотя и в нино находились «одаренные» которые меняли полугорелые свитчи…
правда иногда и не меняли… вот лежат тут на полки два делинка и один акорп… все думаю взять на работу да попробывать починить… трансформаторы поменять, да саму микруху комутатора…
А Вы, кстати, не пожертвуете приципальной схемой свитча, или хотябы даташитом на микросхему ?

SFx писал(а)
а потому что в Москве брали… тама нет понятия не гарантийный случай — слишком большая конкуренция среди фирм… и качество обслуживание столичное… :)

это, простите, бред. По поводу схемы — это вряд ли получится.

сори за офф… если все сложится очень печально, то ваш БП найдет своего хозяина, обращайтесь :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разветвителя

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

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

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

connect10.gif
Рис. 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 в целом является очень полезным средством диагностики.

Заключение

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

Понравилась статья? Поделить с друзьями:
  • Как проверить программный код на ошибки
  • Как проверить сайт на ошибку 500
  • Как проверить ошибку на опель вектра б
  • Как проверить проводник на наличие ошибок
  • Как проверить сайт на тильде на ошибки