У нас возникла проблема с нашим коммутатором Catalyst 6500, в связи с чем мы подозреваем, что кэш ARP поврежден. Это проявляется следующими симптомами:
При попытке пинга системы, которая ранее не была разрешена, первый ответ пинга истекает, а каждый последующий ответ успешен: Пингование foo.network.com [xxx.xx.xx.xx] с 32 байтами данных: Запрос истек. Ответ от xxx.xx.xx.xx: байт=32 время=5 мс TTL=55 Ответ от xxx.xx.xx.xx: байт=32 время=3 мс TTL=55 Ответ от xxx.xx.xx.xx: байт=32 время=3 мс TTL=55
При возникновении проблем с повреждением данных каждый второй пинг завершается с тайм-аутом: Пинг foo.network.com [xxx.xx.xx.xx] с 32 байтами данных: Ответ от xxx.xx.xx.xx: байт=32 время=5 мс TTL=55 Время ожидания запроса истекло. Ответ от xxx.xx.xx.xx: байт=32 время=5 мс TTL=55 Время ожидания запроса истекло.
Очистка кэша ARP временно решает проблему. Чтобы очистить кэш ARP, мы используем команды: clear arp cache clear ip cache Это исправляет проблему, но она наверняка повторится.
Подробная информация о коммутаторе:
IOS (tm) s72033_rp Software (s72033_rp-PK9SV-M), Версия 12.2(17d)SXB8, ВЫПУСК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (fc2)
Процессор cisco WS-C6509-E (R7000) (версия 1.1)
Любая помощь приветствуется, Спасибо
УТОЧНЕНИЕ: У нас есть сеть, которой мы управляем, и мы подключены к корпоративной сети. Все запросы к машинам внутри сети, которой мы управляем, работают нормально. У нас проблемы только с машинами в другой сети.
решение1
Я бы посоветовал вам открыть кейс в Cisco.
Они смогут проверить наличие известных ошибок в вашей версии IOS и попросят вас предоставить подробности конфигурации, которые вы, возможно, не захотите здесь публиковать. (но если хотите, вы можете разместить результат sh tech где-нибудь, это может нам помочь)
Также, добавляется ли он после перезагрузки или он начал портиться после длительного безотказного функционирования?
решение2
Вы наблюдаете эту проблему с PING-запросами из интерфейса командной строки коммутатора или с ПК, подключенного к коммутатору?
Обеспечивает ли этот коммутатор функции уровня 3 (маршрутизация)?
Означают ли эти PING-запросы проблемы между двумя устройствами в одной подсети или между подсетями?
Показывает ли журнал на коммутаторе (я полагаю, «show log hist») что-нибудь неладное?
Влияет ли проблема на доставку пакетов только на пару устройств или она затрагивает несколько устройств?
У меня была похожая проблема на этом сайте клиента несколько лет назад. Я захватил вывод "show mac-" до возникновения проблемы, а затем во время возникновения проблемы и сравнил поиск устройств, которые, казалось, были на разных портах до начала сбоя и после.
Я обнаружил, что в локальной сети было встроенное устройство (в данном случае часы), которое периодически передавало пакет кадров с «поддельным» исходным адресом, путая таблицу мостов коммутатора и заставляя коммутатор некоторое время отправлять кадры с неправильного порта. Я смог увидеть это в выводе «show mac-», заметив, что устройства, которые не должны были менять порты, по-видимому, делали это.
Похоже, это весело — решать проблемы! Хотел бы я там быть... >улыбка<
Редактировать:
Спасибо за комментарии.
"show log hist" показывает постоянный журнал. Пока вы не очищаете журнал, все сообщения, которые там были, останутся там после очистки кэша arp на коммутаторе.
Есть ли другой маршрутизатор между вашим 6509 и корпоративным центром обработки данных, где находятся проблемные устройства?
Используете ли вы какие-либо протоколы динамической маршрутизации?
Вот что говорит моя интуиция:
Я настоятельно рекомендую вам сохранять копии «show mac-» и «show arp» до того, как произойдет сбой, а также повторно во время сбоя (их захват с помощью чего-то вроде PuTTY займет всего минуту, поэтому вы сможете быстро очистить кэш arp).
Я понимаю, что вы не можете просто разместить эти снимки здесь, но я бы рекомендовал вам закинуть их в электронную таблицу или базу данных и сопоставить MAC-адрес с портами в одном отчете, а MAC-адреса с IP-адресом в другом. Если вы сравните "до" и "во время", я предсказываю, что вы увидите некоторые различия.
Если предположить, что между вашим 6509 и корпоративным центром обработки данных есть маршрутизатор, я предсказываю, что вы обнаружите, что MAC-адрес этого маршрутизатора «перемещается» между портами, а его IP-адрес — между MAC-адресами.
Если маршрутизатор отсутствует и компьютеры корпоративного центра обработки данных взаимодействуют с этим 6509 на уровне 2, я предполагаю, что сами устройства могут демонстрировать некоторое «перемещение» между портами или перемещение IP-адресов между MAC-адресами.
решение3
Если запустить сниффер на клиенте, который пингуется, вы увидите все пинги или только половину из них?
Что произойдет, если вы отправите пинги с разных интерфейсов на 6500? Происходит ли это для хостов, для которых 6500 является шлюзом по умолчанию?
Как выглядит таблица mac-адресов? Как насчет traceroute? И 'ping -r9 '?
Не исключаю ошибку iOS, но это может быть и многое другое...
решение4
Я согласен с Питером и Эваном. Это больше похоже на подпрыгивающий маршрут/порт, чем на атаку кэша. Особенно на 65xx. Чтобы усилить комментарий Эвана, обязательно получите (рабочую) таблицу ARP, но единственная запись, которая вам действительно понадобится, это маршрутизатор следующего перехода. Вы исключили проблемы с несколькими путями? Я видел, как кто-то спрашивал, используете ли вы протокол динамической маршрутизации (или несколько шлюзов с плавающими статическими маршрутами), но я не видел вашего ответа. Удачи!