Проблема пропускной способности сети (связанная с 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 дня все работает хорошо... но я подожду двухнедельную отметку, прежде чем позвонить, чтобы решить проблему.

4 ответа

Джоэл,

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

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

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

Джо

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

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

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

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

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

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

Другие вопросы по тегам