SNMP는 가장 널리 사용되는 네트워크 관리 프로토콜로 발전했으며 현재 적용되는 버전에는 주로 SNMP v1, SNMP v2c 및 SNMP v3가 있습니다. 버전 간의 주요 차이점은 정보 정의, 통신 프로토콜 작동 및 보안 메커니즘에 있습니다. 동시에 두 가지 SNMP 애플리케이션 확장인 RMON(원격 네트워크 모니터링)과 RMON2도 나타났습니다.
물리 계층의 관점에서 볼 때 SNMP를 사용하여 네트워크를 관리하려면 NMS(네트워크 관리 스테이션), 에이전트(Agent) 및 프록시 서버(프록시)가 포함되어야 합니다. 네트워크 관리에서는 명령을 내리고 알림 정보를 받기 위해 하나 이상의 NMS가 필요합니다. 에이전트는 관리 노드의 요청에 응답할 수 있으며 알림 정보를 사전에 생성할 수도 있습니다. 네트워크 관리에는 하나 이상의 에이전트가 있을 수 있습니다. 프록시는 서로 다른 네트워크 또는 서로 다른 버전 간에 SNMP 요청 및 알림 메시지를 전달합니다.
프로토콜 계층의 관점에서 보면 SNMP에는 SMI(관리 정보 구조, 관리 정보 구조) 및 MIB(관리 정보 베이스, 관리 정보 베이스)가 포함됩니다. SMI는 ASN.1(Abstract SyntaxNotation one)의 하위 집합으로, ASN.1의 요소, 사용자 정의 데이터 유형 및 매크로를 SNMP에서 사용할 수 있다고 규정합니다. SNMP의 MIB. MIB는 에이전트에서 관리 가능한 개체에 대한 추상적인 설명입니다. SNMP에서 MIB는 보기 위해 트리 구조로 구성되어 있습니다. 트리의 각 노드는 OID(Object Identifier)라고 하며, 이는 웹 사이트 도메인 이름과 유사한 방식으로 구성되며 각 노드는 인증서로 표시됩니다. 1.3.
SNMP는 HTTP 및 FTP 프로토콜과 유사한 TCP/IP 프로토콜 스택에 속하는 애플리케이션 계층 프로토콜입니다. 단지 SNMP 전송 계층이 UDP 프로토콜을 사용한다는 것입니다.
SNMP v1에서는 NMS에서 에이전트로의 간단한 인증 모드인 커뮤니티가 제공됩니다. NMS가 에이전트에 요청을 보낼 때 에이전트는 문자열을 받은 후 커뮤니티 문자열이 로컬과 일치하는지 확인해야 합니다. 하나. 커뮤니티를 전송할 때 일반 텍스트를 사용하기 때문에 명백한 보안 위험이 있습니다.
1996년 IETF는 v1을 기반으로 관리 스테이션 간의 통신을 정의한 SNMP v2c(Community-BasedSNMP v2)를 출시했습니다. 모두 분산 네트워크 관리를 지원하지만 보안 메커니즘은 여전히 v1과 동일합니다.
1998년 IETF는 SNMP v2를 기반으로 보안(사용자 기반 보안 모델 및 보기 기반 액세스 제어 모델) 및 관리 메커니즘을 확장한 SNMP v3을 출시했습니다. 보안 측면에서 v3 버전은 프로토콜 메시지에 보안 매개변수를 추가하여 암호화된 전송과 메시지의 필수 확인을 허용하는 보안 프로토콜입니다. SNMP v3은 모듈식 아이디어를 사용하여 프로토콜의 각 구성 요소 모듈을 정의하고 프로토콜 아키텍처를 개선하며 가장 중요한 것은 SNMP v1 및 SNMP v2와의 호환성을 유지한다는 것입니다.
SNMP의 에이전트는 주로 정보 업로드를 담당합니다. SNMP 프로토콜의 레벨 기능 외에도 NMS에는 송수신 정보 로깅, 알림 정보 기록 및 관리 기능도 있습니다. 구성 및 그래픽 구성 및 관리 인터페이스를 제공할 수 있습니다.
이러한 기능을 실현하기 위해 SNMP에는 주로 다음을 포함하는 일련의 작업 명령이 포함되어 있습니다.
명령 읽기: 일련의 명령을 받고 NMS는 관리 정보를 수집하도록 에이전트에 요청을 보냅니다.
Set 명령: Set 명령, NM은 메시지에 포함된 데이터를 에이전트에 기록합니다.
알람 기능: 트랩 시리즈, 에이전트가 NMS에 알람/이벤트 메시지 정보를 적극적으로 보냅니다.
그림 13-1
1. Get 작업
Get 작업은 NMS에서 적극적으로 시작하는 작업입니다. Get 요청 플래그 외에도 전송된 메시지에는 요청될 OID 이름 및 값 쌍도 포함되며, 관리 개체 정보는 이 이름 및 값 쌍을 바인딩하는 형태로 전송됩니다. 물론 Get 연산에서 OID에 해당하는 값은 NILL이다.
2. Get-Next 연산
Get-Next 연산은 Get 함수와 유사하지만, 쿼리되는 정보가 메시지에 바인딩된 OID 정보가 아니라 객체의 다음 OID 정보라는 점입니다. OID 정보를 읽을 수 있습니다). 예를 들어 NMS는 Agent 측에서 sysName의 다음 노드인 sysLocation의 정보를 수집하려고 하며 요청 메시지에서는 sysName.0이고 반환된 메시지는 sysLocation.0 및 값에 바인딩됩니다.
3. Get-Bulk 작업
은 실제로 SNMP v2에 추가된 새로운 작업 방법인 여러 Get-Next 작업의 모음입니다.
4. 설정 작업
설정 작업은 장치의 매개변수 관리, 구성 및 제어를 달성하기 위해 쓰기 가능한 권한으로 OID에 대한 매개변수를 설정할 수 있습니다. Get 작업 바인딩 변수와 달리 Set은 해당 OID 설정 값을 바인딩해야 합니다.
5. Get-Response
Get-Response는 NMS의 Get 및 Set 명령에 대한 응답으로, 명령과 명령에 포함된 매개변수에 따라 해당 반환 변수 바인딩 정보와 오류 상태 정보(명령 실행 성공 여부를 나타냄) 또는 실패) 등
6. Trap 시리즈
Trap은 Agent가 중요한 이벤트를 NMS에 사전에 보고하는 메커니즘입니다. 이러한 보고에 대해 NMS는 Agent에 응답할 필요가 없습니다. 트랩 정보의 내용은 언제, 어디서 무슨 일이 일어났는지 나타냅니다.
1, SMI
SMI는 SNMP의 ASN.1 구문으로 정의된 정보 모듈이며 ASN.1의 하위 집합입니다. 이러한 모듈에는 다양한 SNMP 관련 매크로, 사용자 정의 데이터 유형 및 규칙 등이 포함되어 있습니다. 이러한 매크로, 데이터 유형 및 규칙을 정의하는 세 가지 주요 목적은 다음과 같습니다. 하나는 SNMP 응용 프로그램에서 고유한 데이터 유형을 표현하고 정의하는 것이고, 다른 하나는 관리 개체의 정의 방법을 단순화하는 것입니다. SNMP Coding 방식으로 관리 객체를 관리합니다. SNMP는 RFC 문서에 정의된 이러한 정보 모듈을 기반으로 프로토콜을 표준화함으로써 다양한 조직, 기업 및 개인이 관리 개체를 정의할 때 일관성을 유지할 수 있도록 합니다.
SNMP에는 실제로 두 가지 버전의 SMI가 정의되어 있습니다. 즉, RFC 1151에 정의된 SMI v1과 RFC 2578에 정의된 SMI v2입니다. SMI v1에서는 여러 데이터 유형, 규칙 설명, OBJECT-TYPE 매크로 등이 간단하게 정의됩니다. SMI v2에서는 모든 관련 내용이 모듈식 정의 방식으로 완벽하게 구성됩니다.
SMI v1에 정의된 기본 데이터 유형은 다음과 같습니다.
INTEGER: 실제로는 32비트 정수입니다.
OCTET STRING: 0개 이상의 8비트 문자(싱글바이트)로, 텍스트 문자나 물리적 주소를 나타낼 수 있습니다. 값 범위는 0~65535입니다.
OBJECT IDENTIFIER: 점으로 구분된 십진수 표기법으로 표현된 OID입니다.
NULL: SMI v1에서만 정의되며 SMI v2에서는 더 이상 사용되지 않습니다.
순서: 정의 목록.
SEQUENCE OF: 테이블을 정의합니다.
SMI v2에서는 위 데이터 유형의 범위 제한 및 업데이트가 더욱 명확해지고 BITS 유형도 도입되었습니다.
SMI v1의 사용자 정의 데이터 유형에는 다음이 포함됩니다.
NetworkAddress(네트워크 주소)(인터넷 이외의 네트워크 주소 계열일 수 있음),
NetworkAddress::= CHOICE {Internet IPAddress}
32비트 네트워크 바이트 순서로 표현된 IP 주소
IPAddress::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))
카운터 유형 값이 최대값에 도달한 후 0으로 돌아갑니다. 다시 계산 시작(에이전트가 다시 시작된 후에도 0으로 재설정됨), 주로 인터페이스
Counter::= [APPLICATION 1] IMPLICIT INTEGER (0.. 4294967295)에서 보내고 받는 바이트 수를 계산하는 데 사용됩니다. )
게이지 유형 값은 증가하거나 감소할 수 있으며 최대값에 도달하면 최대값으로 유지됩니다. 예를 들어 라우터의 인터페이스 속도는
유형으로 표현할 수 있습니다. Gauge::= [APPLICATION 2]IMPLICIT INTEGER (0.. 4294967295)
TimeTicks는 타이밍에 0.01초를 사용하여 두 시점 사이의 시간 간격을 나타냅니다. 설명에 타이밍 기반이 명시되어 있어야 합니다.
TimeTicks ::= [ APPLICATION 3 ] IMPLICIT INTEGER (0 .. 4294967295)
Opaque는 다른 ASN.1 유형으로 인코딩된 값을 두 번 캡슐화합니다. 이전 버전과의 호환성을 위해 이 유형은 SMIv2에도 정의되어 있으며 권장되지 않습니다.
Opaque ::= [APPLICATION 4 ] IMPLICIT OCTET STRING
SMI v1과 비교하여 SMI v2에서 변경된 사용자 정의 데이터 유형은 다음과 같습니다.
Gauge32와 Gauge는 실제로 동일합니다. Gauge32와 Unsigned32는 동일한 애플리케이션 유형 태그를 공유하므로 인코딩은 기본적으로 동일합니다.
Gauge32 ::= [응용 프로그램 2 ] 암시적 정수 (0 .. 4294967295)
Unsigned32 ::= [응용 프로그램 2 ] 암시적 정수 (0 .. 4294967295)
Count er64는 더 넓은 범위의 카운터입니다. , 64개가 있습니다: 2^64-1 (0..18446744073709551615). Counter32는 카운터가 1시간 이내에 0으로 반환되는 경우에만 표준 MIB 모듈에서 사용됩니다.
Counter64::= [APPLICATION6] IMPLICIT INTEGER (0..18446744073709551615)
IPAddress 유형은 SMI v2에서 계속 유지되며 변경 사항이 없습니다. 단, IPv6의 128비트 주소에는 적용되지 않습니다. Counter32에 대한 추가 설명: 현재 카운트 값은 초기 값과 기록된 변화가 있는 경우에만 명확한 의미를 갖습니다.
MIB 관점에서 SMI는 MIB의 정의를 직접적으로 안내하고, MIB의 데이터 유형과 구문을 정의하며, MIB의 관리 개체에 대한 OID 공간을 할당하는 헌장입니다.
2, MIB
MIB는 비즈니스 요구 사항이나 네트워크 관리 표준에 따라 합의된 조직 규칙 및 정의 구문에 따라 작성된 구조화된 텍스트 파일입니다.
MIB(관리 정보 데이터베이스)의 각 관리 개체는 이름, 설명, 데이터 유형 및 기타 정보를 포함한 모든 속성을 명확하게 설명해야 합니다. 통신 당사자는 개체의 고유 식별자(OID)를 통해 이러한 속성의 내용을 식별할 수 있습니다. 즉, MIB는 NMS와 Agent 사이의 통신을 위한 브리지입니다. Agent가 MIB를 구현하고 NMS가 MIB를 알고 있는 경우에만 둘이 올바르게 협력하여 해당 관리 기능을 구현할 수 있습니다. MIB를 NMS로 가져온 후에만 NMS는 관리할 개체의 모든 세부 정보를 알 수 있습니다. MIB에 정의된 관리 개체가 에이전트에 구현되면 에이전트는 MIB를 지원합니다.
에이전트는 여러 MIB를 구현할 수 있으며 각 MIB에는 더 많거나 적은 관리 개체가 포함될 수 있습니다. 명확한 요구 사항은 없습니다. MIB는 크게 두 부분으로 구성되는데, 그 중 하나는 국제표준화기구(International Organization for Standardization)에서 정의한 MIB-I(RFC1156), MIB-II(RFC1213) 등의 표준 관리 객체이다. 네트워크에 연결된 모든 장치는 표준 MIB에 정의된 일반 및 기본 관리 개체를 지원합니다. 또 다른 부분은 주요 제조업체, 기관 또는 개인이 맞춤화한 프라이빗 MIB입니다. 이러한 프라이빗 MIB는 표준 MIB에 없는 장치 관리 요구 사항 및 관리해야 하는 개체에 따라 제조업체에서 맞춤화한 것입니다. 개인 MIB는 노드 기업(1.3.6.1.4.1) 아래에 정의됩니다.
표준 MIB는 관리 개체를 MIB 트리의 10개 분기인 10개 그룹으로 나눕니다. 시스템, 인터페이스, AT(주소 변환, 상태가 더 이상 사용되지 않음을 나타냄) 버전), IP, ICMP, TCP, UDP, EGP, 전송, SNMP, 해당 상위 노드는 1.3.6.1.2.1(mib-2)입니다. 이 10개 그룹의 관리 개체는 네트워크 관리의 가장 중요한 부분 중 하나입니다.
시스템 그룹: 주로 에이전트 시스템 수준 정보를 설명하는 데 사용됩니다. sysName, sysLocation, sysDescr, sysServices, sysUpTime, sysContact, sysObjectID 등을 포함합니다. 이러한 OID는 장치의 이름, 위치, 온라인 시간 등 네트워크 관리에 매우 중요한 정보를 제공하며, 실제 환경에서는 이러한 정보를 제때 업데이트할 수 없으며 쉽게 무시됩니다.
Interfaces 그룹: 이 그룹은 네트워크 장치의 모든 인터페이스 정보를 제공하는 데 사용됩니다. 인터페이스 유형, 인터페이스 설명, 인터페이스 속도, 인터페이스 상태 등을 포함합니다.
AT 그룹: 주소 번역 그룹입니다. 이 시간 그룹은 네트워크 주소와 물리적 주소 간의 매핑 관계를 구현하는 테이블 개체입니다. 테이블을 탐색하면 IP 주소와 MAC 주소 간의 대응 관계를 얻을 수 있습니다.
IP 그룹: IP 계층 관련 정보의 관리 대상을 정의합니다. 이러한 개체에는 IP 패킷, 오류 정보, 주소 정보, 라우팅 정보 및 주소 매핑 정보가 포함됩니다.
ICMP 그룹: 이 그룹은 다양한 ICMP 메시지의 전송 및 수신을 설명하는 26개의 스칼라 객체를 정의합니다. 이들은 모두 카운터 유형입니다. 이러한 객체는 메시지 전송 및 수신 속도와 다양한 ICMP 메시지 유형(요청, 응답)의 속도를 쉽게 제공할 수 있습니다.
TCP 그룹: 이 그룹에는 주로 구성 관리를 위한 TCP 재전송 정책, 재전송 시간이 가장 길고 짧은 객체, 성능 관리를 위한 링크 거부 요청 수, TCP 통신 상태 간 전송 상태 등이 포함됩니다. 레코드, 총 재전송 횟수, 총 수신 오류 횟수, 결제 관리에 사용할 수 있는 TCP 데이터 세그먼트 송수신을 위한 기술적 개체, 보안 관리에 사용할 수 있는 tcpConnTable 테이블 개체, 원격 IP 및 포트 원격지에서 의심스러운 링크를 추적하기 위해 테이블, 상태 및 기타 정보를 분석하여 기록된 숫자입니다.
UDP 그룹: 이 그룹에는 UDP 패킷 수신 및 전송을 위한 카운팅 개체, 오류 보고 카운팅 개체 및 포트, IP 주소 등 관련 정보의 성능 및 계정 관리에 사용할 수 있는 개체가 포함됩니다.
EGP(Exterior Gateway Protocol) 그룹: EGP는 자율 시스템 간(이웃 간) 라우팅 정보를 교환하는 데 사용되는 프로토콜입니다. 이 그룹에는 사용자 실패 관리를 위한 이웃 실행 상태, 사용자 구성 관리를 위한 로컬 자율 시스템의 도메인 번호, 성능 관리를 위해 로컬 엔터티에 들어오고 나가는 EGP 메시지 비율, 오류 카운트 객체.
전송 그룹: 이 그룹의 역할은 다양한 전송 매체에 따라 해당 관리 정보를 제공하는 것입니다. 이 그룹은 매우 특별합니다. MIB-II는 이 분기에서 명확한 관리 개체를 정의하지 않고 대신 특정 전송 매체를 관리해야 할 때 해당 인터페이스 유형을 재구성에 추가합니다.
SNMP 그룹: SNMP와 관련된 객체를 상세하게 정의하는 그룹입니다. 예를 들어 결함 관리에 사용할 수 있는 다양한 유형의 오류 수에 대한 통계, 트랩 인증 실패가 구성 관리에 사용할 수 있는 메시지 객체 생성 여부, 인증에 사용할 수 있는 다양한 메시지 송수신 수에 대한 통계 성과 관리.
SNMP에서는 모든 관리 객체가 트리 구조로 구성되어 있으며, 관리 객체는 트리의 노드로 구현되며, 이 트리는 관련 국제 표준화 기구 및 경영진에 의해 유지관리됩니다. 이러한 구조화되고 계층적인 조직을 통해 객체를 관리하고 확장하는 것이 매우 편리합니다. 이러한 관리 및 확장은 노드 할당에 반영됩니다.
기업, 조직 또는 개인은 트리 구조의 분기가 되기 위해 국제기구의 노드를 신청할 권리가 있습니다. 노드를 성공적으로 신청한 후에는 모니터링 또는 관리 비즈니스 요구에 맞게 지점 아래에 다른 노드를 자유롭게 할당할 수 있습니다.
OID 번호, MIB 번호라고도 합니다. MIB는 실제로 OID로 구성된 ASN.1 모듈로, 실제로는 트리 구조로 구현됩니다. 인터넷에는 많은 표준 MIB가 있습니다. SNMP는 MIB-I, MIB-II 등을 정의하며 기업, 조직 및 개인이 정의한 MIB도 포함합니다. 아래 그림과 같이.
OID 트리에서는 최상위 루트 노드만 특정 번호를 갖지 않으며, 다른 노드는 구별을 위해 동일한 수준의 고유 번호를 가지고 있다고 볼 수 있습니다.
상단에 있는 다음 레벨 노드는 CCITT(현 ITU-T)에서 관리하는 ccitt(0)와 ISO에서 관리하는 ISO(1)입니다.
인터넷 노드 아래에는 많은 하위 노드가 있으며, 디렉토리(1)은 예약되어 있으며 향후 OSI 디렉토리 서비스에 사용될 수 있습니다. mgmt(2)는 IAB의 책임이며 실제로는 MIB-I 및 MIB-II인 RFC의 표준 관리 개체를 정의하는 데 사용됩니다. Experiment(3)도 IAB에 의해 관리되며 인터넷의 실험적 성격의 관리 개체를 정의하는 데 사용됩니다. 민간(4) 및 하위 노드 기업(1)은 IANA에 의해 할당 및 관리됩니다. 기업(1) 노드는 주로 다양한 기업이나 조직에 할당하는 데 사용됩니다.
OID 트리 구조는 아래 그림 13-2와 같습니다. ㅋㅋㅋ SNMP로 항목 옵션을 모니터링할 때 정보 유형 및 저장 값 옵션을 아래 표와 같이 구성하는 것이 좋습니다.
Description | Zabbix추천 모니터링 항목 옵션 |
INTEGER 기호 32는 다음과 같습니다. 정수 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 숫자 부호 없는 십진수 | 저장 값: 있는 그대로 | 값 매핑 표시
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Text | 저장 값: 현재대로 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 저장값: 그대로
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 저장 값: 델타(초당 속도) |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 저장값: 그대로 |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 저장 값: 델타(초당 속도) |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 저장 값: 그대로 |
|
위 내용은 Zabbix 3.0이 모니터링하는 네트워크 장치는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
