Зависает коммутатор d link

Обновлено: 03.07.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sokal
Когда "разумный" свич зависает, он перестаёт реагировать и на консоль управления - и Telnet, и WEB :( Приходиться перезагружать выключателем питания. По крайней мере, так обстоит дело с Cisco Catalyst 2050G на работе - вроде и фирма не отстойная.
Советую предусмотреть такой выключатель при монтаже.

И ещё - нет ли в близи какого сильного источника радиосигнала. Дом знакомого, где была такая сеть, обжил таксопарк :(, поставил на крышу антенну. Теперь сеть работает с пятого на десятое, особенно когда таксюки увеличивают мощность передатчика - в осадки, в туман ets.

Кабельное наврядли может создать такой сигнал.

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

Кабельное наврядли может создать такой сигнал.

Другим источником такого сигнала могут быть плохо контачащие электрощиты, домашние радиостанции. Все их объединяет термин пробкотрон - источник сильных помех.

а может сам свич - ты пробывал поменчть свичи местами? если будет виснуть всё тот же то скоре всего сам свич
я как то гонялся почти неделю у себя за одним свичём с плавающим глюком (на всё сеть баги давал - из-за него любая машина пинговала сервер через раз) - оказался восьми портовый d-link :)

Сегодня моменял 2 свичи местами. Посмотрим через пару дней что будет.

На этом доме где постоянно глючит свич лифтов нет.

Не успел я выяснить глючил ли свич, он сгорел. :( Теперь поставил новый, посмотрю что теперь будет. Не успел я выяснить глючил ли свич, он сгорел. :( Теперь поставил новый, посмотрю что теперь будет.

Кабельное наврядли может создать такой сигнал.

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

Подскажите пожалуйста, если бы вместо 8 портовый D-Linkов поставить 24-х портовый D-Link у которого внутренний блок питания, а не внешний, потому что мне кажется, что действительно вся проблема в блоках питания. sokal
В принципе я не думаю, что это решит задачу. Да и стоит ли ставить свич на 24 порта, где и 8 достаточно.
Я бы посоветовал свич с большим напряжением питания - на 12 вольт.
они стабильнее работают при перепадах напряжения.

ПРОБЛЕМА РЕШЕНА.
1. Мои свичи находились в одном ящике с усилителями кабельного телевидения. Свичи были убраны и помещены в отдельном ящике.
2. На счет того, что у меня горели свичи и порты то проблема была решена так:
Во - первых, поставил сетевой фильтр (обыкновенный удленитель, такие как ставят в офисах).
Во - вторых, поставил устройство защиты от перенапряжения (прибор с помощью которого устанавливаеш минимальное значение напряжения и максимальное, если напряжение вне установленого коридора то тогда свич отключается, а когда напряжение в норме то автоматически включается).

Теперь сеть работает без проблем и нет никаких глюков с пропажей пакетов при пинговании или копированием информации. Запускал одновременно до 10 потоков при копировании фильмов, музыки и т.д. и все нормально.

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

Спасибо всем за помощь.

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

Здравствуйте! Помогите пожалуйста разобраться с проблемой.

В общем существует небольшая офисная сеть, 18 машин, подключены к свитчу D-Link Des 1024D. Недавно стала периодически вешаться сеть. Всех естественно выкидывает. Тереяются данные, часть пользователей работают с 1С серваком, остальное большинство с сервером-файлообменником. Я заметил что это происходит когда зависает у кого-нибудь комп. Зависают они в произвольном порядке, в наличии и мощные машины и древние мамонты. Как только зависший комп перезагружаешь сеть сразу же появляется. Не могу понять откуда ноги растут. В последнее время это стало довольно частым явлением, несколько раз за день. Очень надеюсь на вашу помощь! Заранее спасибо!

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

Локальная сеть
Здравствуйте. Помогите объединить сети. У одной (А) - адреса 192.168.0.1-100, роутер -.

Локальная сеть
Вопрос, возможно очень глупый, но важный(не особо): у меня от wi-fi роутера lan кабель подключен к.

Локальная сеть
Я работаю в офисе где подключено по сети 5-6 ПК через хаб, так же есть ADSL интернет у всех ПК.

Сеть локальная
Привет. Evolve прекратил свое существование ищу как можно нормально поиграть по сети. Говорят.

у вас айпишники ручками прописаны? вроде есть такая гадасть (вирус) которыйц начинает менять айпишники и маки на железке, попробуйте жестко задать определенные айпи и мак на коммутаторе (аналогия ip-mac-binding на d-link) да, все ручками забито. а как гадость эту зовут вы знаете наверное? неа, но вообще стоит все машины последовательно проверить (скачаете AVZ и/или CureiT и на каждом пк, предварительно отключив от сети, сделать проверку, есстественно такие операции лучше делать когда никого нет).

Вообще у всех AVG бизнесс эдишн стоит. вроде суровый такой. а проверить все компы это нереально. меня максимум на время обеда туда пускают)

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

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

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

Добавлено через 3 минуты
можно попробывать на всех пк сетевку выставить на 10мбит/с, возможно что они вешают коммутатор, соответственно и сеть лежит

не там всего до кучи. и фаервол и антиспам, и еще что то. но мне он не нравится что то.

я когда пришел в эту организацию мне сразу с порога мол тупит сеть что-то при передачи больших объемов на сервак. ну и за три месяца работы всего дважды затупило. а это неделю по 3-4 раза в день все виснит. меня скоро директора порвут) валят уже на меня все.

Добавлено через 3 минуты
я как бы думал уже, что коммутатор не вывозит нагрузки, хочу поменять, на более мощный и портов на 48, но не знаю как их выбирать, и как настраивать тоже, так как я всего лишь дизайнер) на которого скинули еще и должность сисадмина

А что значит виснет? Передача прекращается по всем портам или нет?

DJ Junk
Виснет, значит молчат все порты.
Мой комп подключен к юниту1, включаю мониторинг всех портов юнита2, в какой-то момент HardwareMonitoring Supervisor-а показывает пик нагрузки на юните2, и юнит перестаёт пинговаться, хотя ещё секунд 10 пингуются компы на его портах, потом затыкаются и они, ещё в течение минуты пингуется юнит3, подключенный последовательно после юнита2 через гигабитный порт, потом и он перестаёт пинговаться. Всё, юнит повис. Ещё пару минут и порты юнита3 глохнут, это кажет мониторинг запущенный на компе у порта юнита3. Минут 5 и юнит1 виснет.
Получается, что по какой-то причине первым зависает ip интерфейс свитча, потом порты 10/100 и последними гиговые порты.
Благодарю за ссылки, пошарюсь ещё разок. Может найду подсказку что может быть причиной такого поведения свитча.
VBR Santer
Santer
Если свичи так себя ведут с момента установки, то очень похоже на баг в Firmware. По возможности, свяжись с продавцами, пусть дадут тебе (или сами обновят) новую версию (2.0).
У меня была похожая проблема со стеком свичей (другого производителя). Оказалось, что влияли сразу несколько факторов:
- гигабитные модули были с ошибкой (приводила к циклической перезагрузке стека);
- версия софта для свичей с этими модулями была выложена позже, чем мы их купили;
- проблемы с трафиком в сети (как следствие, высокая утилизация маршрутизирующего коммутатора).
Так что, читай, анализируй и тряси продавцов (поубивал бы некоторых из них). есть еще несколько причин висяков:
1) коллизия (но она временна и редка) - када все дружно начинают обращаться к свитчу
2) когда какая нить карточка по глюку своему начинает выдавать броадкаст сигналы (типа заполняет все свободные порты своим флудом - тогда резетишь эту тачку и все ок.
Техник левый
1) коллизия (но она временна и редка) - када все дружно начинают обращаться к свитчу
Коллизии не вызывают зависание свичей. Ethernet с полудуплексными соединениями просто обязан быть коллизионным. Но если все соединения полнодуплексные, то коллизий может не быть вообще.

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

"Нашли битую карту лишь тогда, когда отключили все соединения на свичах и стали подключать по одному."

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

asenberg
Я в похожей ситуации так ничего и не нашёл
Один из быстрых способовпоиска флудящей карты:
- берем хаб и переключаем в него станции сколько влезет (необязательно, но в свичеванной сетке на все порты ходят в основном широковещательные пакеты, юникасты хрен отловишь)
- запускаем на одной из них анализатор пакетов
- смотрим какой "гад" флудит больше всех (речь идет о преобладании в общем трафике на порядки)

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

Читайте также: