Как устранить неисправности сетевых недостатков
May 30, 2023
Оставить сообщение
Мы знаем, что коммутаторы являются важными сетевыми устройствами в локальных сетях, и их статус работы тесно связан со статусом доступа к Интернету клиентских систем.
Тем не менее, в практической работе, на состояние переключателей может быть легко влиять внешние факторы, что приводит к различным сетевым неисправностям в локальной сети.
Чтобы обеспечить стабильную сетевую работу, мы должны должным образом управлять и поддерживатьпереключателиВ нашей ежедневной работе по предотвращению сбоев переключения.
В этой статье мы расскажем о опыте старшего эксперта по низким напряжению в устранении неисправностей разломов в розетках. Во время обслуживания локальной сети в здании он столкнулся с ошибкой, когда переключатель пола не может быть пронзен из -за неправильных физических соединений. Процесс устранения неполадок для этой сети ошибки оказался довольно сложным.
Поскольку эта ошибка является относительно типичной, и на подход к устранению неисправностей можно ссылаться, на нее разделяется здесь в пользу каждого.
1. Сцена неисправности:
Офисное здание, за которое я отвечал в то время, состояло из нескольких компаний. Чтобы убедиться, что каждая компания может иметь независимый доступ в Интернет и что другие компании не повлияли на их статус в Интернете, я выбрал переключатель маршрутизатора в качестве основного переключателя для сети здания.
В то же время для каждого устройства на коммутаторе были установлены различные виртуальные рабочие подсету.
Поскольку каждое устройство находилось на разных этажах, и количество компаний на каждом этаже различалось, на некоторых этажах было два или три единицы, в то время как у других было до пяти или шести единиц.
Рабочие подсети единиц на разных этажах были подключены к локальной сети здания через соответствующий переключатель пола и доступ к сети Интернета через аппаратный брандмауэр в сети здания.
Чтобы повысить эффективность управления сетью, сетевые администраторы обычно управляют и поддерживают коммутаторы с помощью удаленных соединений.
Тем не менее, однажды утром, когда я начал работу и сканировал и диагностировал рабочее состояние различных портов коммутатора на локальном выключателе сети сети, я обнаружил, что один из портов коммутатора находится в состоянии вниз.
Поэтому я проверил записи управления сетью и обнаружил, что соединение с этим портом было от переключателя на втором этаже на пятом этаже.
Когда я попытался удаленно войти в переключатель пола, я обнаружил, что не могу успешно войти в систему. Когда я использовал команду Ping для проверки IP -адреса переключателя, она вернула «Time Out».
Как раз когда мне было интересно, почему никто не сообщил об ошибке, телефон зазвонил, как и ожидалось, и, конечно же, пользователи с пятого этажа начали сообщать об ошибках сети один за другим.
Основываясь на приведенных выше симптомах неисправности, я подозревал, что может возникнуть неожиданная проблема с переключателем пола.
Поэтому я бросился на сцену неисправного переключателя, отключил его питания, подождал некоторое время, а затем повторно подключил источник питания, чтобы перезапустить его.
После того, как операция перезапуска была завершена, я использовал команду Ping, чтобы снова проверить IP -адрес переключателя.
На этот раз возвращаемые результаты были нормальными, а удаленные операции входа в систему могли пройти гладко.
Тем не менее, через полчаса неисправный переключатель снова показал те же симптомы неисправности, и когда я проверил его с помощью команды Ping, он снова дал ненормальные результаты.
Позже, чувствуя себя неловко, я повторил процесс перезапуска и тестирования, только чтобы обнаружить, что неисправный переключатель все еще не может быть нормально пропин.
2. Глубокий устранение неполадок:
Поскольку повторные перезагрузки не решили проблему, я оценил, что причина разлома была более сложной, учитывая, что этот тип разлома часто встречается в процессах управления сетью.
Поэтому я провел углубленный устранение неполадок после приведенного ниже подхода:
Учитывая, что только на одном этаже переключатель на пятом этаже всей строительной сети продемонстрировал это явление, я первоначально судил, что это может быть вызвано проблемами с этим переключателем пола.
Чтобы точно определить причину неисправности, я планировал заменить неисправный переключатель на правильно функционирующий, и наблюдать, что неисправность все еще сохранялась.
В то же время я бы подключил подозреваемый проблемный переключатель к независимой сетевой среде.
После полчаса тестирования и наблюдения я увидел, что неисправный переключатель, который был подключен к изолированной сетевой среде, нормально функционировал, и его IP -адрес можно было прозвать в этой сетевой среде.
Тем не менее, недавно замененный переключатель при подключении к строительной сети не может быть нормально пропитывать.
Основываясь на этих наблюдениях, я пришел к выводу, что возможность самого переключения пятого этажа было проблемой, была почти незначительной. После исключения факторов, связанных с собственным статусом неисправного коммутатора, я рассмотрел структуру сети и статус всей строительной сети.
В то время как пользователи на других этажах здания могут нормально получить доступ к Интернету, часть пользователей пятого этажа не могла.
Проверяя информацию о сети на пятом этаже, я обнаружил, что на этом этаже было пять единиц. В то время сетевой администратор настроил двухэтажный переключатель на пятом этаже и подключил их в каскадную конфигурацию.
Кроме того, на этих двух переключателях были созданы пять виртуальных рабочих подсетей, чтобы убедиться, что каждое устройство может работать независимо в своих соответствующих виртуальных подсетях.
Поскольку соответствующий порт на выключателе ядра уже был опущен, теоретически, все подразделения на пятом этаже должны быть не в состоянии получить доступ к Интернету. Так почему только некоторые пользователи сообщали об ошибке?
Как только пришло время начать работу, я сразу же связался с несколькими компаниями, которые не сообщили о сетевых разломах. Их ответ заключался в том, что они только что обнаружили ненормальный доступ к сети и собирались обратиться за помощью к администратору строительных сети.
Если это так, то все подразделения на пятом этаже должны быть не в состоянии получить доступ к Интернету. Следовательно, причина ошибки должна лежать в виртуальных рабочих подсетях этих подразделений.
После сужения объема устранения неполадок до пяти единиц на пятом этаже я подумал, что перезапуск оборудования конкретного переключателя на пятом этаже может временно восстановить неисправность сети.
Однако через полчаса такая же ошибка в сети появится.
Учитывая это конкретное явление, я подозревал, что это может быть шторм сетевой трансляции, который вызвал застой в переключении в течение определенного периода времени, в конечном итоге блокируя соответствующий порт коммутатора на выключателе ядра.
Чтобы облегчить анализ ошибки, я использовал инструменты мониторинга сети для анализа передачи сетевых пакетов на каскадных портах переключателя пятого этажа.
Результаты показали, что как входящий, так и исходящий трафик пакета были чрезвычайно высокими, почти превышали нормальные значения примерно в 100 раз. Это указывало на возникновение перегрузки сети в сети четвертого этажа.
Итак, вызвана ли затора сети сетевым вирусом?
Или это вызвано сетевой петлей?
Я планирую наблюдать за изменением информации о состоянии каскадных портов неисправного переключателя, особенно изменения в выходных вещательных пакетах. Если выходные пакеты трансляции продолжают увеличиваться каждую секунду, вполне вероятно, что в сети пятого этажа есть сетевой цикл.
Основываясь на этом подходе к анализу, я напрямую подключился к неисправному переключателю, используя кабель управления консоли и вошел в бэкэнд системы в качестве системного администратора.
Используя команду «Display», я проверил изменения в выходных вещательных пакетах каскадных портов коммутатора, изучая результаты каждую секунду и сравнивая их.
После повторного тестирования я обнаружил, что размер выходных вещательных пакетов от неисправного переключателя действительно постоянно увеличивался.
Это указывает на то, что на пяти единицах на пятом этаже определенно есть сетевая петля.
После тщательного изучения двух переключателей на пятом этаже я обнаружил, что их физическое соединение было нормальным.
Кроме того, различные порты переключателей этих двух переключателей были непосредственно подключены к розеткам на стенах в комнатах на пятом этаже.
Теоретически, пока комнаты не используют переключатели для несанкционированного каскада, не должно быть сетевого цикла.
Теперь, когда доказано, что в сети пятого этажа есть сетевой цикл, это означает, что кто-то произвольно использует коммутаторы для расширения сети. Найдя расширенный переключатель и осматривая его физические соединения, мы можем быстро идентифицировать конкретный неисправный узел.
Итак, я связался с сетевыми администраторами различных подразделений на пятом этаже по телефону, попросив их осмотреть каждую комнату офиса и сообщить о комнатах, используя подчиненные переключатели.
Мне не потребовалось много времени, чтобы сообщить мне результаты проверки, и, что удивительно, около 10 комнат использовали подчиненные переключатели для расширения сети.
В этот момент я знал, что в этих 10 комнатах была высокая вероятность сетевой петли. Но какая именно комната?
Должен ли я посетить каждую комнату и проверять их сетевые соединения один за другим?
После тщательного рассмотрения я взял сетевую документацию и определил номера портов, используемые этими 10 комнатами.
Далее я напрямую подключилсясетевые кабелиВ эти порты и в режиме просмотра этих портов я последовательно пропинг IP -адрес неисправного коммутатора.
Когда я добрался до шестого порта, я обнаружил, что его нельзя успешно пропитать.
Чтобы определить, действительно ли этот порт был проблематичным, я использовал команду «Display» в режиме просмотра порта, чтобы проверить его информацию о состоянии.
После анализа результатов я обнаружил, что размеры входных и выходных пакетов этого порта были значительно ненормальными. Поэтому я оценил, что этот порт определенно был причиной ненормального рабочего статуса неисправного переключателя.
Ссылаясь на записи файлов, я быстро определил соответствующую комнату на основе этого номера порта.
По прибытии на сцену я обнаружил, что два доступных сетевых порта в этой комнате были подключены к небольшим концентраторам, и эти два концентратора были подключены к нескольким компьютерам.
Что еще хуже, был непосредственно подключал сетевой кабель, создавая сетевой цикл между двумя концентраторами.
Этот цикл вызвал трансляцию шторма, в конечном итоге блокировал каскадный порт неисправного коммутатора и приведет к тому, что вся сеть здания не сможет должным образом получить доступ к Интернету.
3. Устранение неполадок:
После удаления дополнительного сетевого кабеля я перепроектировал информацию о состоянии порта переключателя. Результаты показали, что размеры входных и выходных пакетов вернулись к норме.
Когда я снова проверил статус соответствующего порта на выключателе ядра, я обнаружил, что предыдущий статус «вниз» изменился на статус «UP». На этом этапе я также смог успешно пропиннуть неисправный переключатель на четвертом этаже.
Это подтверждает, что проблема действительно была вызвана несанкционированным использованием коммутатора или концентратора пользователем в одной из комнат на пятом этаже. Позже, благодаря дальнейшему расследованию с пользователями Интернета, я узнал, что их комнаты были очищены накануне вечером, и в то время всеEthernet Кабелибыли отключены.
После того, как работа по очистке была завершена из -за ограниченных знаний пользователей в связи, они случайным образом воссоединили кабели, что привело к сетевой цикле. Поэтому, как сетевые инженеры, мы также должны помнить об этом при проведении проектов по техническому обслуживанию.
Предыдущая статья:Что такое кабель Cat7 и как завершить
Следующая статья:Разница между менеджерами кабелей и панелями патча
