대부분의 NMS(네트워크 관리 시스템)는 사용자가 MIB를 로드할 수 있는 방법을 제공합니다.MIB를 로드하는 것은 NMS가 이름, OID(개체 식별자) 및 데이터 유형(예: 카운터)과 같은 새 MIB 개체에 대해 배울 수 있는 방법입니다.
MIB는 로드될 때 구문 분석될 수도 있고, NMS 애플리케이션이 실행될 때 나중에 발생할 수도 있습니다.구문 분석을 수행하는 소프트웨어는 MIB 컴파일러입니다.
구문이 올바른 MIB는 모든 공급업체의 MIB 컴파일러에서 성공적으로 구문 분석되어야 합니다.안타깝게도 서로 다른 MIB 컴파일러는 서로 다른 문제를 일으킬 수 있습니다.
Cisco는 고객에게 게시된 MIB가 구문적으로 정확한지 확인하기 위해 지속적으로 노력하고 있습니다.Cisco는 또한 인기 있는 NMS 제품에서 문제가 있다고 판명된 MIB 구조를 방지합니다.이러한 노력에도 불구하고 필드에 있는 모든 MIB 컴파일러에서 해당 문제를 해결할 수는 없습니다.
이 문서에서는 몇 가지 일반적인 문제를 다루고 해결 방법을 제시합니다.공급업체의 MIB 컴파일러에서 이러한 문제가 발생할 경우(RFC 14xx와 RFC 19xx 문제 제외) 해당 MIB 컴파일러의 부족 때문입니다.공급업체 또는 공급업체에게 컴파일러를 수정하도록 요청할 수 있습니다.
이 문서의 독자는 MIB에 익숙해야 합니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
로드 순서는 MIB를 로드할 때 가장 중요하고 일반적인 문제입니다.많은 MIB가 다른 MIB에 정의된 정의를 사용합니다.이러한 정의는 MIB 상단 근처의 IMPORTS 절에 나열됩니다.
예를 들어 MIB mumble이 MIB bumble에서 정의를 가져오는 경우 일부 MIB 컴파일러는 MIB mumble을 로드하기 전에 MIB bumble을 로드해야 합니다.로드 순서가 잘못되면 컴파일러는 가져온 MIB가 정의되지 않았다고 주장합니다.
다른 여러 MIB를 가져오는 MIB의 목록과 해당 MIB를 로드해야 하는 순서입니다.이 경우 로드 순서 문제의 95%가 처리될 수 있습니다(다른 대부분의 MIB는 순서에 상관없이 로드할 수 있음).
SNMPv2-SMI.my
SNMPv2-TC.my
SNMPv2-MIB.my
RFC1213-MIB.my
IF-MIB.my
CISCO-SMI.my
CISCO-PRODUCTS-MIB.my
CISCO-TC.my
참고: 이러한 MIB의 v1 버전을 로드하는 경우 MIB 파일 이름은 실제로 IF-MIB-V1SMI.my와 같습니다("-V1SMI"는 v2에서 v1로 변환된 MIB의 이름에 추가됩니다). 이에 대한 예외는 RFC1213-MIB.my MIB이며 v1 버전으로만 존재합니다(즉, RFC1213-MIB-V1SMI.my는 없음).
다른 MIB를 로드하려고 할 때 컴파일러에서 정의되지 않은 항목에 대해 불평하는 경우 이 MIB가 가져오는 MIB를 식별하고 다른 모든 MIB를 먼저 로드했는지 확인합니다.
참고: 각 MIB에 대해 SNMP Object Navigator(SNMP 개체 탐색기) > View & Download MIBs(MIB 보기 및 다운로드)에서 정확한 컴파일 순서와 함께 로드해야 하는 MIB의 정확한 목록을 확인할 수 있습니다.View MIB dependencies and download MIB를 선택합니다.
Cisco MIB 데이터 유형 정의가 일치하지 않지만 일부 표준 RFC MIB의 경우 이러한 정의가 될 수 있습니다.예를 들면 다음과 같습니다.
MIB 음량 정의:SomeDatatype ::= INTEGER(0..100)
MIB 결점은 다음과 같습니다.SomeDatatype ::= INTEGER(1..50)
이 예는 사소한 오류로 간주되며 MIB가 경고 메시지와 함께 성공적으로 로드됩니다.
다음 예는 사소한 오류로 간주되며(두 정의가 기본적으로 동일하더라도) MIB가 성공적으로 구문 분석되지 않습니다.
MIB 음량 정의:SomeDatatype ::= DisplayString
MIB 결점은 다음과 같습니다.SomeDatatype ::= OCTET 문자열(SIZE(0..255))
MIB 컴파일러가 이러한 오류를 오류로 처리하거나 경고 메시지를 제거하려면 정의가 일치하도록 이 동일한 데이터 유형을 정의하는 MIB 중 하나를 편집합니다.
이러한 MIB를 로드하면 OID 재정의가 발생할 수 있습니다(이 오류가 발생하는 다른 인스턴스가 있을 수 있음).
예를 들면 다음과 같습니다.
OLD-CISCO-CPU-MIB.my는 다음을 정의합니다.lcpu 개체 식별자::= { local 1 }
OLD-CISCO-ENV-MIB.my는 다음을 정의합니다.렌즈 개체 식별자::= { local 1 }
이러한 두 MIB를 로드하면 MIB 컴파일러에서 lcpu OBJECT IDENTIFIER가 새 이름 lenv로 재정의되고 있다고 불평할 수 있습니다.OLD-CISCO-MEMORY-MIB.my 및 OLD-CISCO-SYSTEM-MIB.my와 마찬가지로 { local 1 }에 새 이름을 지정합니다.
이 오류는 사소한 오류로 처리되며 MIB가 경고 메시지와 함께 성공적으로 로드됩니다.
MIB가 성공적으로 로드되지 않거나 경고 메시지를 제거하려면 모든 MIB가 동일한 이름을 사용하도록 MIB 중 하나를 편집합니다.
많은 MIB 컴파일러는 DisplayString과 같은 일부 데이터 유형에 대한 기본 지식을 갖추고 있습니다.이러한 컴파일러 중 일부는 MIB에서 이러한 데이터 유형에 대한 정의를 볼 경우 불만을 제기합니다.예를 들어, DisplayString은 SNMPv2-TC에 정의되어 있습니다.
해결 방법은 MIB 파일에서 잘못된 정의를 제거하거나 주석 처리하는 것입니다.
이 예제는 MyDatatype 유형의 값이 0, 5 또는 208진수가 됨을 나타내는 구문이 유효한 예입니다.
MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
일부 MIB 컴파일러는 이 구문을 허용하지 않습니다.일반적으로 적절한 해결 방법은 크기 중 하나를 선택하고 다른 크기를 제거하는 것입니다.가장 큰 사이즈를 유지하셔야 합니다예를 들어 이전 예제는 다음과 같이 변경됩니다.
MyDatatype ::= OCTET STRING (SIZE(20))
일부 OID는 대부분의 OBJECT IDENTIFIER와 같이 SMI의 노드를 참조하지 않으므로 홀수로 간주됩니다. 그러나, 그것들은 구문적으로 유효하다.일반적인 예로는 null 개체 식별자(예: { 0})가 있습니다.일부 MIB 컴파일러는 SMI의 노드에 해당하지 않는 OBJECT IDENTIFIER를 고려하지 않습니다.다음은 이러한 컴파일러에서 문제를 일으킬 수 있는 MIB 구문의 예입니다.
zeroDotZero OBJECT IDENTIFIER ::= { 0 0 } myMIBObject OBJECT-TYPE DEFVAL { {0 0} }
해결 방법은 MIB 파일에서 이러한 유형의 참조를 제거하거나 주석 처리하는 것입니다.
SNMPv1 MIB에서 트랩은 TRAP-TYPE 매크로로 정의됩니다.SNMPv2 MIB에서 트랩은 NOTIFICATION-TYPE 매크로를 사용하여 정의됩니다.
일부 MIB 컴파일러는 구문 분석 중인 MIB 파일의 이러한 정의를 좋아하지 않습니다(이러한 매크로는 지원하지 않음).
이 경우 트랩 정의를 제거하거나 정의를 주석 처리할 수 있습니다(예: MIB 주석 구분 기호를 줄 시작 부분에 넣기).
RFC 1442~1452는 파티 기반 SNMPv2를 정의합니다. 이러한 RFC는 최신 Draft Standard RFC 1902~1908에 의해 사용되지 않습니다.
MIB 구문과 관련하여 이 두 버전의 SNMPv2 간에는 차이가 거의 없습니다.그러나 일부는 있습니다.Cisco MIB는 현재 RFC 19xx 규칙을 기반으로 합니다.
참고: 몇 년 전 Cisco MIB가 RFC 14xx 기반일 때 일부 RFC 19xx 기반 컴파일러는 CISCO-TC.my 및 PNNI-MIB.my MIB의 Unsigned32 ::= TEXTUAL-CONVENTION 줄에 대해 불만을 토로했습니다.이는 Unsigned32가 RFC 19xx의 사전 정의된 데이터 유형이기 때문입니다.이러한 이유로 Cisco는 Unsigned32에 대한 정의가 없는 이러한 MIB(CISCO-TC-NO-U32.my 및 PNNI-MIB-NO-U32.my)의 대체 버전을 가지고 이 데이터 유형에 대해 이미 알고 있는 컴파일러에 로드하곤 했습니다.더 이상 적용할 수 없습니다.
Cisco MIB, 트랩 및 아이콘을 서드파티 NMS로 로드하는 가장 효과적이고 효율적인 방법은 CiscoWorks Common Services(또는 http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility에서 독립형)의 일부로 제공되는 CiscoWorks Integration Utility(Integration Utility)를 http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml의 해당 Integration Utility Adapter와 최신 NMIDB(Network Management Integration Data Bundle)를 사용하는 것입니다. 자세한 내용은 Integration Utility 설명서를 참조하십시오.
또는 MIB 로드 및 컴파일에 대한 서드파티 NMS 설명서를 참조할 수 있습니다.이 문서에는 HP OpenView 및 IBM NetView에 대한 지침이 포함되어 있습니다.그러나 제품이 변경될 수 있으므로 HP 또는 IBM 설명서를 참조하십시오.
다음 단계에 따라 원하는 Cisco MIB를 로드합니다.
네트워크 관리 스테이션의 /usr/OV/snmp_mibs 디렉토리에 파일을 복사합니다.
HP OpenView 및 IBM NetView에서 MIB 문서를 찾는 기본 디렉토리입니다.다른 위치에 배치하는 경우 loadmib 그래픽 인터페이스에서 명시적 경로 이름을 지정합니다.
MIB에 대한 읽기 액세스 권한을 갖도록 권한을 설정합니다.
GUI 메뉴에서 Options(옵션) > Load/Unload MIBs(MIB 로드/언로드)를 선택합니다.
플랫폼 설명서의 지침에 따라 Cisco MIB를 컴파일하거나 로드합니다.
MIB 파일을 로드하려면/opt/OV/bin/xnmloadmib -load filename 명령을 실행합니다.