У нас возникла проблема с нашим коммутатором Catalyst 6500, из-за которой мы подозреваем, что кеш ARP поврежден. Это проявляется следующими симптомами:
Когда вы пытаетесь выполнить эхо-запрос системы, которая не была решена ранее, время ожидания первого ответа на эхо-запрос истекает, и каждый последующий завершается успешно: Pinging 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 (s72033_rp-PK9SV-M), версия 12.2 (17d) SXB8, ВЫПУСКНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (fc2)
процессор cisco WS-C6509-E (R7000) (версия 1.1)
Любая помощь приветствуется, спасибо
УТОЧНЕНИЕ: У нас есть сеть, которой мы управляем, а затем мы подключаемся к корпоративной сети. Все запросы к машинам внутри сети, которыми мы управляем, работают нормально. У нас проблемы только с машинами в другой сети.
Вы наблюдаете эту проблему с 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-адресами.
Я предлагаю вам открыть дело в Cisco.
Они смогут проверить наличие известных ошибок в вашей версии IOS и спросить у вас детали конфигурации, которые вы, возможно, не захотите публиковать здесь. (но если хотите, можете поместить результат sh tech куда-нибудь, это может нам помочь)
Кроме того, добавляется ли он после перезагрузки, или он начал повреждаться после длительного периода безотказной работы?
Если вы запустите сниффер на клиентском пинге, вы увидите все эхо-запросы или только половину из них?
Что произойдет, если вы отправите эхо-запросы с разных интерфейсов на 6500? Бывает ли, что для хостов 6500 является шлюзом по умолчанию?
Как выглядит таблица MAC-адресов? Как насчет трассировки? А «пинг -r9»?
Не исключайте ошибку IOS, но это также может быть много других вещей ...
Это может быть случай ARP-спуфинга. Если кто-то пытается подделать весь адрес в сети, включая шлюз, спуфинговая машина получит слишком много трафика и, следовательно, не сможет передать все данные на правильные адреса после их чтения. Или машина спуфинга может намеренно сбросить дополнительные пакеты.
Запустите wirehark. Затем используйте "arp -d", чтобы удалить записи arp всех IP-адресов в вашей подсети. Затем попробуйте пропинговать несколько IP-адресов в вашей подсети. Затем перестаньте перехватывать пакеты от wirehark и просто проанализируйте ARP-трафик. Если вы видите несколько ARP-ответов для каждого IP-адреса, который вы проверяли, например, IP 172.16.1.1 находится в xx: xx: xx: xx: xx: xx0, за которым следует IP-адрес 172.16.1, 1 находится в yy: yy: yy: yy: yy: гг. Тогда это определенно случай ARP-спуфинга, и с переключателем все в порядке.
В случае, если это не сработает. Попробуйте обновить Switch IOS до последней версии.
Я должен согласиться с Питером и Эваном. Это больше похоже на прыгающий маршрут / порт, чем на атаку кеша. Особенно на 65xx. Чтобы усилить комментарий Эвана, обязательно получите (рабочую) таблицу arp, но единственная запись, которая вам действительно понадобится, - это маршрутизатор следующего перехода. Вы исключили проблемы с многолучевостью? Я видел, как кто-то спрашивал, используете ли вы протокол динамической маршрутизации (или несколько шлюзов с плавающими статическими маршрутами), но я не видел вашего ответа. Удачи!