주요 콘텐츠로 건너뛰기

문제를 해결 할 때 여러 번 사람들에게 네트워크 추적을 보내달라고 요청합니다. 네트워크 추적은 종종 문제의 근본 원인을 가리킵니다.  최소한 문제 공간을 관리할 수 있는 공간으로 줄입니다. 예를 들어 네트워크 프린터가 가비지 인쇄를 시작했을 때 며칠 동안 TTP를 살펴보는 데 시간을 보냈습니다. 마침내 네트워크 추적을 받았을 때 우리는 완벽하게 좋은 텍스트를 보내고 있다는 것을 발견했습니다. 문제는 프린터에 있었다. 다른 경우, 모듈 간의 OSL 성능 문제는 수천 마일 떨어져 네트워크 문제로 보였지만 추적은 서버 모듈에 문제가 있음을 분명히 보여주었습니다.  네트워크 추적이 아니었다면 두 가지 문제에 대해 계속 작업할 것입니다.

네트워크 추적은 어떻게 얻을 수 있습니까? 세 가지 가능성이 있습니다.

packet_monitor

VOS packet_monitor 명령을 사용하면 몇 가지 제한 사항이 있으므로 모듈이 네트워크에서 전송하고 받는 모든 것을 모니터링할 수 있습니다. 자세한 내용은 http://community.stratus.com/blog/openvos/getting-most-out-packetmonitor http://stratadoc.stratus.com/vos/17.0.1/r419-09/wwhelp/wwhimpl/js/html/wwhelp.htm?context=r419-09&file=ch9r419-09i.html 참조하십시오.

packet_monitor 명령에는 몇 가지 제한 사항이 있습니다. 보낸 것으로 보고된 프레임이 실제로 전송되었는지 100% 확신할 수 없습니다. 예를 들어 어댑터의 오류로 인해 프레임이 전송되지 않을 수 있습니다. 또한 CRC 오류와 같은 오류로 받은 프레임은 상류로 보내지지 않으므로 packet_monitor 볼 수 있습니다. packet_monitor 어댑터를 난잡한 모드로 배치하지 않으므로 어댑터로 주소가 주소가 있는 프레임만 이 프레임에 대해 상류로 전달됩니다. 링크는 90% 바쁠 수 있으며 packet_monitor 어댑터 또는 브로드캐스트 주소로 해결되는 유일한 프레임이기 때문에 1프레임만 보고합니다.

일반적으로 packet_monitor 와 같은 호스트 기반 모니터는 다른 형태의 추적에 추가하거나 다른 형태의 네트워크 추적을 사용할 수 없는 경우에만 유용합니다.
포트 미러링 일명 SPAN (ANalysis용 스위치 포트) 포트

미러 또는 스팬 포트는 스위치의 하나 이상의 포트(또는 VLAN에서 볼 수 있는 모든 트래픽을 복제하는 스위치의 포트)입니다. 미러 포트는 네트워크 모니터링 어플라이언스에 연결되어 있어야 합니다. 이 어플라이언스는 와이어샤크(http://www.wireshark.org/) 또는 tcpdump와 같은 호스트 기반 모니터를갖춘 Linux 또는 Microsoft Windows를 실행하는 특수 목적 장치 또는 PC일 수 있습니다. 미러 포트는 쉽게 설정할 수 있으며 스위치에서 몇 개의 명령만 입력해야 합니다.

불행히도 미러 포트를 사용하는 데는 몇 가지 주요 단점이 있습니다. 첫째, 포트를 올바르게 구성해야 합니다. 잘못 구성된 포트는 네트워크 추적에서 누락되거나 중복된 프레임으로 이어질 수 있습니다. 둘째, 스위치는 모든 유형의 오류로 프레임을 복제하지 않으므로 이러한 프레임은 추적되지 않습니다. 셋째, 바쁜 스위치는 미러 포트로 복제하는 대신 프레임을 떨어뜨릴 수 있습니다. 넷째, 전체 VLAN 또는 여러 스위치 포트에서 프레임을 수락하는 미러 포트또는 하나의 전체 이중 포트만 오버로드되어 일부 프레임을 떨어뜨릴 수 있습니다. 다섯째, 스위치와 호스트 사이에 도입된 오류는 완전히 다른 스위치 포트에 연결된 네트워크 모니터링 응용 프로그램에서 볼 수 없습니다. 동일한 토큰으로 미러 포트와 네트워크 응용 프로그램 사이에 도입된 오류는 네트워크 어플리케이션에 호스트가 실제로 스위치에서 받는 내용을 왜곡된 볼로 제공합니다.
네트워크 탭

탭은 스위치와 호스트 간에 연결하는 수동 장치입니다. 그들은 문자 그대로 네트워크 연결을 활용합니다. 미러 포트와 마찬가지로 네트워크 어플라이언스에 연결해야 하지만 미러 포트보다 단점이 적습니다.

첫째, 일반적으로 구성이 없습니다. 당신은 그것을 연결하고 작동합니다. 둘째, 고급 탭은 프레임을 모니터링 포트로 복제하기 위해전력에만 의존합니다. 복제 활동이 신뢰할 수 있도록 이중 전원 공급 장치가 있습니다.  전원이 실패하면 이러한 탭은 네트워크 포트 간에 프레임을 계속 전달합니다. 복제만 중지됩니다. 셋째, 탭에는 1개의 함수만 있으며, 이는 프레임을 복제하고 네트워크 모니터 응용 프로그램으로 전달하는 것입니다. 탭은 트래픽의 높은 볼륨에 의해 압도 될 가능성이 훨씬 적습니다. 또한 집계 탭에는 버퍼 공간이 있어 프레임을 떨어뜨리지 않고 전체 이중 링크에서 대량의 트래픽을 전달할 수 있습니다. 물론. 지속적인 높은 속도는 여전히 버퍼를 압도 할 수 있습니다. 탭 을 집계하면 여러 입력을 결합 할 수 있습니다. 예를 들어 두 포트 장치를 사용하면 이중 어댑터 쌍의 활성 및 대기 어댑터를 모두 모니터링할 수 있습니다. 이렇게 하면 어댑터 장애 조치에도 지속적인 모니터링이 보장됩니다. 마지막으로 호스트 어댑터에서 탭을 연결하면 네트워크 모니터링 어플리케이션이 호스트 어댑터를 떠나는 모든 프레임과 스위치에서 호스트 어댑터로 도착하는 모든 프레임을 볼 수 있다는 최상의 확신을 가질 수 있습니다.

많은 탭이 미러 포트와 공유하는 한 가지 단점은 손상된 프레임을 삭제한다는 것입니다. 많은 네트워크 모니터링 어플라이언스, 특히 기성이체 하드웨어가 있는 PC만 있는 기기도 손상된 프레임을 떨어뜨리기 때문에 탭 제조업체는 이 에러가 심각한 오류라고 생각하지 않습니다.

탭 과 스위치 포트에 대한 자세한 내용은 http://www.lovemytool.com/blog/2007/08/span-ports-or-t.html 또는 http://taosecurity.blogspot.com/2009/01/why-network-taps.htm l을 보거나 좋아하는 검색 엔진에 "네트워크 탭 및 범위 포트"를 입력하십시오.
모니터링 과제

첫 번째 과제는 모니터링 시기와 기간입니다. 이상적으로는 프로덕션 시스템의 중요한 네트워크 링크를 지속적으로 모니터링해야 합니다. 첫 번째 발생 시 문제를 캡처하고 네트워크 추적을 손에 들고 문제가 발생하거나 모니터링을 설정하고 복제하거나 다시 발생하기를 기다리는 것보다 훨씬 빠릅니다. 추적 파일은 클 수 있습니다. 기가비트 링크의 50%의 부하는 초당 약 62.5메가바이트 또는 분당 3.75기가바이트를 생성합니다. 추적 파일은 최악의 경우 응답 시간보다 오래 보관할 필요가 없습니다. 신고된 문제에 한 시간 만에 응답할 수 있는 경우 1시간 동안 추적 데이터만 보관해야 합니다. 저장하는 추적 데이터가 많을수록 응답해야 할 여지가 더 많거나 조사해야 하는 문제가 있음을 인식해야 합니다.  대형 디스크는 적어도 중단 비용에 비해 상당히 저렴하므로 추적 데이터를 보유하기 위해 하나 이상의 테라바이트 크기의 디스크 드라이브를 구입하는 것이 좋습니다.

스팬 포트를 사용할 때 이 모니터링 수준을 유지하는 것이 어려울 수 있습니다. 복잡한 네트워크에서 네트워크 관리자는 여러 방향으로 당겨지고 범위가 포트를 유지하고 문제가 발생할 경우 지속적인 모니터링이 어려울 수 있습니다.

반면에 호스트 옆에 설치된 네트워크 탭은 해당 호스트에 전념합니다. 정교한 네트워크 모니터링 어플라이언스를 구입하거나 Linux 또는 Windows를 실행하고 tshark 프로그램(와이어샤크에 대한 비GUI 인터페이스)을 실행하는 1테라바이트 하드 드라이브의 기본 PC를 사용하여 시작할 수 있습니다. 이 설정은 266분의 추적 데이터(500mbps의 데이터 전송률가정)를 제공하며 대부분의 용도에 완벽하게 적합합니다.  주변 쇼핑시 1테라바이트 드라이브를 $100 미만으로 구입할 수 있습니다.

기본 네트워크의 상태는 지속적으로 사용할 수 있는 응용 프로그램에 필수적입니다.  일상적인 방식으로 네트워크 활동의 정확한 추적을 캡처하기 위해 노력하십시오.  문제가 자르면 재발을 기다리지 않고 신속하게 해결할 수 있습니다.  보너스로 추적 데이터를 분석하고 이전에 숨겨진 네트워크에 대해 알아볼 수도 있습니다.packets

© 2024 스트라투스 테크놀로지스.