Catalyst 6500 스위치에 ARP 캐시가 손상된 것으로 의심되는 문제가 있습니다. 이는 다음과 같은 증상으로 나타납니다.
이전에 해결되지 않은 시스템에 대해 ping을 시도하면 첫 번째 ping 응답 시간이 초과되고 계속되는 각 응답은 성공합니다. 32바이트 데이터가 있는 foo.network.com [xxx.xx.xx.xx] pinging: 요청 시간 초과 밖으로. xxx.xx.xx.xx에서 보낸 답장: bytes=32 time=5ms TTL=55 xxx.xx.xx.xx에서 보낸 답장: bytes=32 time=3ms TTL=55 xxx.xx.xx.xx에서 보낸 답장: bytes= 32시간=3ms TTL=55
손상 문제가 발생하면 다른 모든 핑 시간이 초과됩니다. 32바이트 데이터가 포함된 foo.network.com [xxx.xx.xx.xx] 핑: xxx.xx.xx.xx에서 응답: 바이트=32 시간=5ms TTL =55 요청 시간이 초과되었습니다. xxx.xx.xx.xx에서 응답: bytes=32 time=5ms TTL=55 요청 시간이 초과되었습니다.
ARP 캐시를 지우면 문제가 일시적으로 해결됩니다. ARP 캐시를 지우려면 다음 명령을 사용합니다:clear arp 캐시 클리어 ip 캐시 이렇게 하면 문제가 해결되지만 문제가 다시 발생할 것이 확실합니다.
스위치에 대한 세부정보:
IOS(tm) s72033_rp 소프트웨어(s72033_rp-PK9SV-M), 버전 12.2(17d)SXB8, 릴리스 소프트웨어(fc2)
cisco WS-C6509-E(R7000) 프로세서(개정 1.1)
도움을 주시면 감사하겠습니다.
설명: 우리가 관리하는 네트워크가 있고 회사 네트워크에 연결되어 있습니다. 우리가 관리하는 네트워크 내부의 컴퓨터에 대한 모든 요청은 정상적으로 작동합니다. 다른 네트워크의 컴퓨터에만 문제가 있습니다.
답변1
Cisco에 케이스를 개설하는 것이 좋습니다.
그들은 귀하의 IOS 버전에서 알려진 버그를 확인할 수 있으며 여기에 게시하고 싶지 않을 수 있는 구성 세부 정보를 요청할 것입니다. (그러나 원하는 경우 sh 기술의 결과를 어딘가에 저장할 수 있습니다. 이는 우리에게 도움이 될 수 있습니다.)
또한 재부팅 후에 추가됩니까, 아니면 긴 가동 시간 후에 손상되기 시작합니까?
답변2
스위치의 CLI 또는 스위치에 연결된 PC의 PING에서 이 문제가 발생합니까?
이 스위치는 레이어 3(라우팅) 기능을 제공합니까?
이러한 PING이 동일한 서브넷에 있는 두 장치 사이에 문제가 있거나 서브넷 전체에 걸쳐 문제가 있음을 보여주고 있습니까?
스위치의 로그("show log hist"라고 생각합니다)에 잘못된 내용이 표시됩니까?
문제가 몇 개의 장치에만 패킷 전달에 영향을 미치나요, 아니면 여러 장치에 영향을 미치나요?
몇 년 전 고객 사이트에서 이와 비슷한 문제가 있었습니다. 문제가 발생하기 전과 문제가 발생하는 동안 "show mac-"의 출력을 캡처하고 중단 시작 전과 이후에 다른 포트에 있었던 것으로 보이는 장치를 찾아 비교했습니다.
LAN에 "스푸핑된" 소스 주소가 포함된 프레임 배치를 주기적으로 전송하여 스위치의 브리징 테이블을 혼란스럽게 하고 스위치가 잘못된 프레임을 보내게 만드는 내장 장치(이 경우 시계)가 있음을 발견했습니다. 잠시 항구. 포트를 변경해서는 안 되는 장치가 포트를 변경하고 있는 것으로 나타났기 때문에 "show mac-" 출력에서 이를 확인할 수 있었습니다.
문제를 해결하는 것이 재미있을 것 같습니다! 거기 있었으면 좋았을텐데... >웃음<
편집하다:
의견을 보내주셔서 감사합니다.
"show log hist"는 지속적인 로그를 보여줍니다. 로그를 지우지 않는 한, 스위치에서 arp 캐시를 지운 후에도 거기에 보고된 모든 메시지는 그대로 남아 있습니다.
6509와 문제 장치가 있는 기업 데이터 센터 사이에 다른 라우터가 있습니까?
동적 라우팅 프로토콜을 사용하고 있습니까?
내 직감은 다음과 같습니다.
오류가 발생하기 전과 오류가 발생할 때 "show mac-" 및 "show arp"의 복사본을 저장해 두는 것이 좋습니다(PuTTY와 같은 것으로 캡처하는 데는 몇 분밖에 걸리지 않으므로 arp 캐시를 빠르게 지울 수 있습니다.)
이러한 캡처 내용을 여기에 쉽게 게시할 수 없다는 것을 알고 있지만 스프레드시트나 데이터베이스에 넣고 MAC 주소를 한 보고서의 포트와 일치시키고 MAC 주소를 다른 보고서의 IP 주소와 일치시키는 것이 좋습니다. "이전"과 "중"을 비교해보면 약간의 차이가 있을 것으로 예상합니다.
6509와 기업 데이터 센터 사이에 라우터가 있다고 가정하면 해당 라우터의 MAC 주소가 포트 간에 "이동"하거나 IP 주소가 MAC 주소 간에 이동한다는 것을 알게 될 것입니다.
라우터가 없고 기업 데이터 센터 시스템이 레이어 2에서 이 6509와 통신하는 경우 장치 자체가 포트 간 "이동"을 표시하거나 MAC 주소 간 IP 주소 이동을 나타낼 수 있다고 예측할 수 있습니다.
답변3
ping 중인 클라이언트에서 스니퍼를 실행하면 핑이 모두 표시됩니까, 아니면 절반만 표시됩니까?
6500의 다른 인터페이스에서 핑을 소싱하면 어떻게 됩니까? 6500이 기본 게이트웨이인 호스트에서도 이런 일이 발생합니까?
Mac 주소 테이블은 어떻게 생겼나요? 추적 경로는 어떻습니까? 그리고 'ping -r9'?
IOS 버그를 배제하지 마세요. 하지만 다른 많은 것들이 있을 수도 있습니다...
답변4
나는 Peter와 Evan의 의견에 동의해야 합니다. 이는 캐시 공격이라기보다는 반송 경로/포트에 더 가깝습니다. 특히 65xx에서는요. Evan의 의견을 확대하려면 (작동하는) arp 테이블을 가져와야 하지만 실제로 필요한 유일한 항목은 다음 홉 라우터입니다. 다중 경로 문제를 배제했습니까? 누군가가 동적 라우팅 프로토콜(또는 부동 정적 경로가 있는 다중 게이트웨이)을 실행하고 있는지 묻는 것을 보았지만 귀하의 답변을 보지 못했습니다. 행운을 빌어요!