Проблема пропускной способности сети (связанная с ARP)

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

симптомы

Основным симптомом является то, что доступ в интернет будет работать, но он очень медленный ... часто до момента ожидания. В качестве примера, типичный результат от Speedtest.net вернет скорость загрузки 4 Мбит / с, но разрешит скорость загрузки от 3 до 8 Мбит / с. Меньшие симптомы могут включать в себя строго ограниченную производительность при передаче данных на наш файловый сервер и с него или даже в некоторых случаях невозможность войти в систему на компьютере (не удается связаться с контроллером домена). Эта проблема затрагивает несколько виртуальных сетей и затрагивает устройства почти в каждой виртуальной сети, с которой мы работаем.

Эта проблема не влияет на все машины в сети. На незатронутую машину обычно загружают не менее 11 Мбит / с с speedtest.net, и, возможно, намного больше, в зависимости от более крупных моделей трафика кампуса в то время.

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

наущению

В конце концов мы заметили, что у всех задействованных машин недавно был арендован dhcp. Мы можем предсказать, когда машина станет «медленной», наблюдая, когда аренда DHCP будет продлена. Мы поиграли с установкой очень короткого времени аренды для тестового vlan, но все, что было сделано, это лишило нас возможности предсказать, когда машина станет медленной. Машины со статическими IP-адресами почти всегда работали нормально. Выпуск / обновление адреса вручную никогда не приведет к замедлению работы компьютера. На самом деле, в некоторых случаях этот процесс исправленмашина в таком состоянии. Однако в большинстве случаев это не помогает. Мы также заметили, что мобильные машины, такие как ноутбуки, могут замедляться при переходе на новые виртуальные сети. Беспроводная связь в кампусе разделена на «зоны», где каждая зона соответствует небольшому набору зданий. Переезд в новое здание может поместить вас в зону, в результате чего вы получите новый адрес. Машина, возобновляющая работу из спящего режима, также может быть медленной.

смягчающих

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

Похоже, что больше всего помогает смягчить проблему, это очистить кэш arp на нашем основном коммутаторе 3-го уровня. Этот коммутатор используется для нашей системы dhcp в качестве шлюза по умолчанию во всех vlans, и он обрабатывает маршрутизацию между vlan. Модель 3Com 4900SX. Чтобы попытаться смягчить проблему, мы установили тайм-аут кэша на коммутаторе до самого низкого возможного времени, но это не помогло. Я также собрал скрипт, который запускается каждые несколько минут для автоматического подключения к коммутатору и сброса кеша. К сожалению, это не всегда работает и может даже привести к тому, что некоторые машины на короткое время остановятся в медленном состоянии (хотя, похоже, они исправляются через несколько минут). В настоящее время у нас есть запланированное задание, которое выполняется каждые 10 минут, чтобы заставить основной коммутатор очистить кэш ARP, но это далеко от совершенства или желательности.

репродукция

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

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

Другие факторы

Стоит отметить, что за последний год у нас было около полдюжины выключателей. В основном это 3Coms эпохи 2003/2004 годов (в основном 4200), которые были введены примерно в одно и то же время. На них по-прежнему должна распространяться гарантия. Покупка HP несколько усложнила получение обслуживания. В основном в источниках питания, которые вышли из строя, но в нескольких случаях мы использовали источник питания от коммутатора с неисправной материнской платой, чтобы вернуть коммутатор с неисправным источником питания к жизни. Сейчас у нас есть устройства бесперебойного питания на всех, кроме трех, четырех коммутаторах, но это был не тот случай, когда я начал работать два с половиной года назад. Серьезные бюджетные ограничения (мы были в списке финансовых учреждений, в котором находился Департамент Эда пару лет назад) вынудили меня обратиться к аналогам Netgear и TrendNet за заменой,

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

диагностика

Сначала нам казалось ясным, учитывая время и постоянный характер проблемы, что источником проблемы была зараженная (или вредоносная) студенческая машина, выполняющая отравление кэша ARP. Однако повторные попытки изолировать источник не увенчались успехом. Эти попытки включают в себя многочисленные следы пакетов проволочной акулы и даже отключение целых зданий на короткое время. Мы не смогли даже найти курящий пистолет с плохим входом в ARP. На данный момент я предпочитаю перегруженный или неисправный основной коммутатор, но я не уверен, как это проверить, а стоимость его замены вслепую высока.

Опять же, любые идеи приветствуются.

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

Джоэл,

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

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

Обычно для проблем связующего дерева вы можете включить обнаружение петли или широковещательное ограничение на порт от вашего поставщика. Это уничтожит любой порт с найденной петлей. Вы также можете включить «защиту bpdu», что означает отключение порта, на котором было получено bpdu, и выдать ошибку получателям прерываний syslog / snmp.

Джо

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

РЕДАКТИРОВАТЬ: Кроме того, это часто встречается в учебных заведениях (две из моих предыдущих работ системного администратора), так как маленькие любимые любят возиться с патч-кабелями / розетками ...

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

Идея Джо хороша, но, учитывая, что вряд ли это будет широковещательный шторм, создающий вашу проблему (я думаю, вы на правильном пути с отравлением кэша ARP или схожей проблемой; это может быть даже конфликт IP-адресов), это, вероятно, не решит проблему.

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

Если у ваших коммутаторов нет этой функции, другой возможностью отследить ее является утилита Linux arpwatch - она ​​отслеживает все запросы ARP и сообщает вам, когда она замечает изменение сопоставления IP-MAC.