tcptraceroute: 홉이 응답하지 않습니다.

tcptraceroute: 홉이 응답하지 않습니다.

AFAIK는 tcptraceroute방화벽이 서비스에 대한 TCP 연결을 차단하고 있는지 확인하는 가장 좋은 도구입니다. (더 좋은 도구를 아시는 분은 댓글 남겨주세요)

일부 홉이 응답하지 않습니다. 보다* * *

remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
 1  * * *
 2  172.18.56.12  0.407 ms  0.222 ms  0.230 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  10.102.1.1  32.017 ms  31.728 ms  31.486 ms
 8  * * *
 9  10.101.7.124 [open]  31.728 ms  32.391 ms  33.549 ms

거기에용어이 홉의 행동에 대해?

홉이 응답하지 않고 * * *출력에 표시되는 경우 이를 호출하는 방법은 무엇입니까?

(안타깝게도 평판이 300개도 아니고 새 태그 "tcptraceroute"를 생성할 수 없습니다)

배경: 나는 네트워크에 대한 책임이 있는 사람들에게 NOW-I-AM-MISSING-THE-MAGIC-TERM을 수행하는 라우터를 사용해야 한다고 말하고 싶습니다.

답변1

이에 대한 정확한 단어는 없지만 해당 네트워크를 관리하는 사람들과의 대화에 도움이 되도록 CoPP(Control Plane Policing)를 살펴볼 수 있습니다.

장치가 실제로 이러한 패킷을 거부하도록 설정되지 않았을 수도 있고 속도를 제한할 수도 있다는 점은 주목할 가치가 있습니다. 따라서 응답을 원할 경우 속도 제한에서 특정 IP를 제외하거나 필요한 경우 모든 IP에 대한 제한을 높이도록 요청할 수 있습니다. 원하는.

네트워크 팀은 DoS 공격이나 컨트롤 플레인의 정상적인 사용 과부하로부터 장치를 보호하기 위해 존재하므로 이러한 변경을 수행하는 데 어려움을 겪을 수 있음을 경고하겠습니다.

에서Cisco 문서, 제어 플레인이 과부하된 경우 볼 수 있는 몇 가지 효과는 다음과 같습니다.

  • 서비스 품질 저하(예: 음성, 비디오 또는 중요한 애플리케이션 트래픽 저하)
  • 높은 경로 프로세서 또는 스위치 프로세서 CPU 사용률
  • 라우팅 프로토콜 업데이트 또는 연결 유지 손실로 인한 라우팅 플랩
  • 불안정한 레이어 2 토폴로지
  • CLI와의 느리거나 응답하지 않는 대화형 세션
  • 메모리, 버퍼 등 프로세서 리소스 고갈
  • 수신 패킷의 무분별한 삭제

답변2

댓글에서 이미 언급했듯이 이에 대한 실제 답변은 없습니다(따라서 이 글을 입력하는 것은 약간 어리석은 느낌이지만 댓글을 달기에는 너무 길어질 것입니다). 당신이 보고 있는 것은 단지 tcptraceroute홉으로부터 응답을 받지 못했다는 것입니다. 이에 대한 용어는 없으며 단지 Traceroute가 설계된 방식일 뿐입니다. 홉이 ICMP 요청에 응답하지 않으면 응답을 받습니다. *즉, 아무것도 반환되지 않았으므로 ping 응답 시간 형식의 응답을 확인할 수 없다는 뜻입니다.

따라서 배경을 알아보려면 다음을 수행하세요.

나는 사람들에게 네트워크에 대한 책임이 어떻게 있는지, 그들이 NOW-I-AM-MISSING-THE-MAGIC-TERM을 수행하는 라우터를 사용해야 한다고 말하고 싶습니다.

라우터가 ICMP 요청을 차단하도록 해야 한다고 말하면 짜잔, 몇 마디만 하면 무슨 뜻인지 이해할 것입니다. 또한 기능이 아니라 설정이기 때문입니다. 따라서 "ICMP 요청을 차단하는 라우터를 사용"하지 않고 그렇게 하도록 지시합니다(기본 설정일 수도 있지만 그럼에도 불구하고 설정입니다). 네트워크 담당자는 이를 알아야 합니다.

관련 정보