최근에 나는 그들의 모듈과 그들의 이더넷 스위치 중 하나 사이의 링크에 문제가있는 것으로 나타났다 사이트를 처리. 시스템 관리자를 테스트할 때 프레드에게 전화하여 스위치를 핑핑하고 모든 핑이 프레드가 답장을 받았기 때문에 문제가 다른 곳에 있다고 결론을 내렸습니다.
이 결론의 문제점은 핑이 스위치에 대한 모듈의 링크를 통해 진행되지 않았다는 것입니다.
네트워킹 구성을 설명해 드리고, IP 주소를 개인 네트워크로 변경했지만 인터페이스와 네트워크 간의 관계는 비슷합니다.
모듈에는 #enet10 및 #enet192 두 개의 인터페이스가 있습니다. #enet10 IP 주소는 10.1.1이며 문제가 있는 링크를 통해 스위치에 연결된 인터페이스입니다. #enet192 IP 주소는 192.168.1이며 다른 링크를 통해 다른 스위치에 연결됩니다. 기본 게이트웨이는 192.168.1.254이며 다른 경로는 구성되지 않습니다. 스위치의 관리 IP 주소는 172.16.100.100입니다.
172.16.100.100에 도달하려면 모듈은 기본 게이트웨이를 사용해야 하며 기본 게이트웨이에 도달하려면 패킷을 #enet192 인터페이스에서 보내야 합니다. 스위치는 ping 패킷의 소스를 #enet192 주소인 192.168.1.1로 보고 있으므로 해당 주소에 회신합니다. 패킷이 #enet10 떠나거나 도착하지 않습니다. #enet10 스위치에 직접 연결되어 있다는 사실은 중요하지 않습니다. 중요한 것은 패킷의 대상 주소와 모듈의 라우팅 테이블뿐입니다.
그래서 프레드가 #enet10 스위치 사이의 링크를 테스트 할 수있는 방법이 있습니까? 아니요, Fred가 할 수 있는 가장 좋은 방법은 10개의 서브넷에서 다른 호스트를 핑하는 것입니다. 이로 인해 패킷이 #enet10 전송되고 대상 호스트에 대한 링크를 통해 이동하며 회신이 동일한 방식으로 돌아올 수 있지만 #enet10 스위치와 스위치 및 대상 호스트 사이의 다른 링크 모두 테스트됩니다.
Fred는 "netstat-인터페이스 #enet10" 명령을 사용하여 하드웨어 또는 드라이버가 링크에서 낮은 수준의 오류를 보고하는지 확인할 수 있습니다. 또한 스위치에는 #enet10 연결된 링크에 연결된 포트의 오류 수를 보고하는 명령도 있습니다. 그러나 #enet10 스위치 사이의 링크를 테스트 할 수있는 방법은 없습니다.
회사