В маленьком колледже, где я работаю, возникают очень странные проблемы с сетью. Я ищу здесь любые советы или идеи. Летом у нас все было хорошо, но проблемы начались через несколько дней после того, как студенты вернулись в кампус на осенний семестр.
Симптомы
Главный симптом - доступ в Интернет будет работать, но он очень медленный ... часто вплоть до тайм-аутов. Например, типичный результат Speedtest.net возвращает скорость загрузки 0,4 Мбит / с, но допускает скорость загрузки от 3 до 8 Мбит / с. Менее заметные симптомы могут включать в себя сильно ограниченную производительность при передаче данных на наш файловый сервер и с него, или даже в некоторых случаях невозможность войти в систему на компьютере (не удается достичь контроллера домена). Проблема затрагивает несколько vlan и затрагивает устройства почти на каждом vlan, с которым мы работаем.
Проблема не затрагивает все машины в сети. Неповрежденная машина обычно видит по крайней мере 11 Мбит / с при загрузке со speedtest.net и, возможно, намного больше, в зависимости от более крупной загруженности кампуса в то время.
Есть один вариант более крупного вопроса. У нас есть один vlan, где пользователи вообще не могли войти почти на все машины. ИТ-персонал будет входить в систему, используя учетную запись локального администратора (или, в некоторых случаях, кэшированные учетные данные), и оттуда выпуск / обновление или пинг шлюза позволят машине работать ... некоторое время. Проблема усложняется тем, что этот vlan распространяется на наши компьютерные лаборатории, которые используют программное обеспечение Deep Freeze для полного сброса жестких дисков после перезагрузки. Это может быть та же проблема, которая проявляется по-разному из-за устаревших данных на машинах, которые не меняли постоянно низкоуровневую информацию в течение нескольких недель. Однако мы смогли решить эту проблему, создав новый vlan и переместив лаборатории на новый vlan оптом.
Подстрекательства
В конце концов мы заметили, что у всех задействованных машин была недавняя аренда dhcp. Мы можем предсказать, когда машина станет «медленной», посмотрев, когда появится аренда dhcp для продления. Мы поигрались с установкой очень короткого времени аренды для тестовой vlan, но все, что нам удалось сделать, это лишить нас возможности предсказывать, когда машина станет медленной. Машины со статическими IP-адресами почти всегда работали нормально. Освобождение / обновление адреса вручную приведет к никогда заставляют машину замедляться. Фактически, в некоторых случаях этот процесс фиксированный машина в таком состоянии. Однако в большинстве случаев это не помогает. Мы также заметили, что мобильные машины, такие как ноутбуки, могут замедлиться при переходе на новые виртуальные локальные сети. Беспроводная связь в кампусе разделена на «зоны», каждая из которых соответствует небольшому набору зданий. Переезд в новое здание может поместить вас в зону, в результате чего вы получите новый адрес. Машина, выходящая из спящего режима, также очень вероятно будет медленной.
Смягчения
Иногда, но не всегда, очистка кеша arp на пораженной машине позволяет ему снова нормально работать. Как уже упоминалось, освобождение / обновление IP-адреса локальной машины может исправить эту машину, но это не гарантируется. Проверка связи шлюза по умолчанию также может иногда помочь на медленной машине.
Что, кажется, больше всего помогает смягчить проблему, так это очистка кеш-памяти arp на нашем основном коммутаторе уровня 3. Этот переключатель используется для нашей системы DHCP в качестве шлюза по умолчанию для всех виртуальных локальных сетей и обрабатывает маршрутизацию между виртуальными локальными сетями. Модель - 3Com 4900SX. Чтобы попытаться смягчить проблему, мы установили тайм-аут кеширования на коммутаторе до минимально возможного значения, но это не помогло. Я также составил сценарий, который запускается каждые несколько минут для автоматического подключения к коммутатору и сброса кеша. К сожалению, это не всегда работает и может даже привести к тому, что некоторые машины останутся в медленном состоянии на короткое время (хотя они, кажется, исправляются через несколько минут). В настоящее время у нас есть запланированное задание, которое запускается каждые 10 минут, чтобы заставить коммутатор ядра очистить свой кеш ARP, но это далеко не идеально и не желательно.
Размножение
Теперь у нас есть тестовая машина, которую мы можем принудительно перевести в медленное состояние. Он подключен к коммутатору с портами, настроенными для каждого из наших vlan. Мы замедляем машину, подключаясь к разным vlan, и после нового подключения или двух она будет медленной.
В этом разделе также стоит отметить, что это происходило раньше в начале предыдущих условий, но в прошлом проблема исчезла сама по себе через несколько дней. Она разрешилась сама собой до того, как у нас появилась возможность проделать большую диагностическую работу ... поэтому мы позволили ей затянуться на этот раз так долго; ожидалось, что это будет недолгая ситуация.
Прочие факторы
Стоит упомянуть, что за последний год у нас было около полдюжины переключателей, которые полностью отказали. В основном это 3COM 2003/2004 годов (в основном 4200), которые были введены примерно в одно и то же время. На них по-прежнему должна распространяться гарантия, покупка HP несколько затруднила получение обслуживания. В основном в источниках питания, которые вышли из строя, но в нескольких случаях мы использовали источник питания от коммутатора с неисправной материнской платой, чтобы вернуть коммутатор с неисправным источником питания к жизни. Сейчас у нас есть ИБП на всех, кроме трех из четырех переключателей, но этого не было, когда я начинал два с половиной года назад. Серьезные бюджетные ограничения (пару лет назад мы входили в список организаций, испытывающих финансовые трудности), вынудили меня обратиться за заменой к Netgear и TrendNet, но пока что эти бюджетные модели, похоже, держатся самостоятельно. .
Также стоит упомянуть, что большим изменением в нашей сети этим летом стал переход от единого беспроводного SSID между кампусом к зонированному подходу, упомянутому ранее. Я не думаю, что это причина проблемы, как я уже сказал: мы видели это раньше. Однако возможно, что это усугубляет проблему и может быть основной причиной того, что ее было так сложно изолировать.
Диагностика
Сначала нам казалось очевидным, учитывая время и постоянный характер проблемы, что источником проблемы была зараженная (или злонамеренная) машина ученика, отравляющая ARP-кеш. Однако неоднократные попытки изолировать источник не увенчались успехом. Эти попытки включают в себя многочисленные трассировки пакетов wirehark и даже отключение целых зданий на короткие периоды. Мы не смогли даже найти плохую запись ARP. Мое лучшее предположение - это перегруженный или отказавший коммутатор ядра, но я не уверен, как это проверить, а стоимость его слепой замены высока.
Опять же, любые идеи приветствуются.
Обновить:
Основной выключатель заменен. Через 4 дня все работает нормально ... но я подожду двухнедельной отметки, прежде чем называть проблему решенной.
Джоэл,
Поскольку у вас есть настройки транков и вы можете продублировать проблему по желанию. Установите Wireshark на ноутбук и отразите / охватите порт восходящей связи. Если вы видите, что скорость пакетов превышает 10 000 или загрузка порта близка к максимальной, у вас проблемы.
У вас может быть проблема с оборудованием или связующим деревом. Обычно я обнаружил, что пользователи подключают оба сетевых адаптера к своим машинам «для увеличения пропускной способности».
Обычно для проблем с связующим деревом вы можете включить обнаружение петель или ограничение широковещательной рассылки для каждого порта от вашего поставщика. Это убьет любой порт с найденным циклом. Вы также можете включить «защиту bpdu», что означает отключение порта, на котором был получен bpdu, и выдачу ошибки приемникам ловушек syslog / snmp.
Джо
Я видел проблемы, подобные этой, и раньше, и это была петля в локальной сети, которая вызывает хаос и насыщение всей подсети (предположительно из-за широковещательного трафика из-за того, что коммутатор видит свой собственный MAC-адрес на дополнительном порту).
РЕДАКТИРОВАТЬ: Кроме того, это распространено в образовательных учреждениях (две из моих предыдущих должностей системного администратора), так как маленькие милые любят возиться с патч-кабелями / розетками ...
Мне кажется, у вас плохое оборудование, которое вызывает широковещательные штормы. Используйте Wireshark, чтобы смотреть трансляции и находить хост, который доставляет вам проблемы ...
Идея Джо хороша, но, учитывая, что это вряд ли будет широковещательный шторм, создающий вашу проблему (я думаю, вы на правильном пути с отравлением кеша ARP или аналогичной проблемой; это может быть даже конфликт IP-адресов), это, вероятно, не решит проблему.
Связанный метод использования динамической проверки ARP и DHCP, если ваши коммутаторы это поддерживают. Если вы включите это, коммутаторы будут отслеживать транзакции DHCP и разрешать только те записи ARP, которые соответствуют известным записям в базе данных DHCP или тем, которые вы указали вручную.
Если в ваших коммутаторах нет этой функции, другой способ отслеживания - это утилита Linux arpwatch - она отслеживает все запросы ARP и сообщает вам, когда замечает изменение сопоставления IP-MAC.