OSPF(Open Shortest Path First) 라우팅 프로토콜은 RFC 2328 OSPF Version 2 에 의해 정의됩니다.이 백서의 목적은 조직이 OSPF 설계 계획에 대해 OSPF 구축을 검증하고, 의도된 설계와 장기적인 일관성을 보장하기 위해 OSPF 구축을 정기적으로 감사할 수 있도록 구성 관리 절차를 구현할 수 있는 절차 프레임워크를 제공하는 것입니다.
이 백서에서는 ITU-T 정의 FCAPS(결함, 컨피그레이션, 회계/인벤토리, 성능, 보안) 모델의 컨피그레이션 관리 기능을 중점적으로 다룹니다.컨피그레이션 관리는 ITU-T M.3400에 의해 정의되며, 이를 통해 NE(네트워크 요소)에 대한 제어, 식별, 데이터 수집 및 데이터 제공 기능을 제공합니다.
이 백서에서 제공하는 정보는 아래에 설명된 몇 가지 주요 섹션에 나와 있습니다.
OSPF Background 섹션에서는 OSPF 구축의 중요한 측면에 대한 배경 정보를 포함하여 OSPF에 대한 기술적 개요를 제공합니다.
Process Definitions 섹션에서는 OSPF 컨피그레이션 관리를 수행하는 데 사용되는 프로세스 정의에 대한 개요를 제공합니다.프로세스 세부 정보는 목표, 성능 지표, 입력, 출력 및 개별 작업에 대해 설명합니다.
Task Definitions(작업 정의) 섹션에서는 세부 프로세스 작업 정의를 제공합니다.각 작업은 목표, 작업 입력, 작업 출력, 작업을 수행하는 데 필요한 리소스, 태스크 시행자에 필요한 작업 기술 등의 측면에서 설명합니다.
Data Identification 섹션에서는 OSPF에 대한 데이터 식별에 대해 설명합니다.데이터 식별은 정보의 출처 또는 위치를 고려합니다.예를 들어, 정보는 SNMP(Simple Network Management Protocol) MIB(Management Information Base), Syslog 생성 로그 파일 또는 CLI(Command Line Interface)에서만 액세스할 수 있는 내부 데이터 구조의 시스템에 포함되어 있습니다.
이 문서의 Data Collection 섹션에서는 OSPF 데이터 수집을 설명합니다.데이터 수집은 데이터 위치와 밀접한 관련이 있습니다.예를 들어 SNMP MIB 데이터는 트랩, RMON(Remote Monitoring) 경보 및 이벤트 또는 폴링과 같은 여러 메커니즘에 의해 수집됩니다.내부 데이터 구조에서 유지 관리하는 데이터는 자동 스크립트 또는 수동으로 시스템에 로그인하여 CLI 명령을 실행한 다음 출력을 기록하는 사용자에 의해 수집됩니다.
데이터 프레젠테이션 섹션에서는 데이터가 보고서 형식으로 표시되는 방법의 예를 제공합니다.데이터가 식별되고 수집되면 분석됩니다.이 문서에서는 OSPF 컨피그레이션 데이터를 기록하고 비교하는 데 사용할 수 있는 보고서의 예를 제공합니다.
Commercial 및 Public Internet Monitoring Tools, SNMP Polling Data 및 Example Data Collection Algorithms 섹션은 OSPF 컨피그레이션 관리 절차를 구현하기 위한 툴 개발에 대한 정보를 제공합니다.
OSPF는 단일 자동 시스템 내에서 사용하도록 설계된 내부 게이트웨이 프로토콜입니다.OSPF는 RIP(Routing Information Protocol)와 같은 라우팅 프로토콜에서 발견되는 거리 벡터 또는 Bellman-Ford 기술과 비교하여 링크 상태 또는 SPF(shortest-path first) 기반 기술을 사용합니다. 개별 LSA(link-state advertisements)는 OSPF 라우팅 도메인(예: 전체 자동 시스템)의 일부를 설명합니다.이러한 LSA는 라우팅 도메인 전체에 플러딩되어 링크 상태 데이터베이스를 형성합니다.도메인의 각 라우터에는 동일한 링크 상태 데이터베이스가 있습니다.링크 상태 데이터베이스의 동기화는 안정적인 플러딩 알고리즘으로 유지됩니다.링크 상태 데이터베이스에서 각 라우터는 최단 경로 트리를 계산하여 라우팅 테이블을 구축하며 트리의 루트는 계산 라우터 자체입니다.이 계산을 흔히 Dijkstra 알고리즘이라고 합니다.
LSA는 작고 각 LSA는 OSPF 라우팅 도메인의 작은 부분, 특히 단일 라우터, 단일 트랜짓 네트워크 환경, 단일 영역 간 경로 또는 단일 외부 경로에 대해 설명합니다.
이 표에서는 OSPF의 주요 기능을 정의합니다.
기능 | 설명 |
---|---|
인접성 | OSPF 라우터 쌍이 인접해지면 두 라우터는 OSPF 데이터베이스 교환 패킷 형식으로 데이터베이스 요약을 교환하여 링크 상태 데이터베이스를 동기화합니다.그런 다음 인접 라우터는 신뢰할 수 있는 플러딩 알고리즘을 통해 링크 상태 데이터베이스의 동기화를 유지합니다.직렬 회선으로 연결된 라우터는 항상 인접해 있습니다.멀티 액세스 네트워크(이더넷)에서 네트워크에 연결된 모든 라우터는 DR(Designated Router) 및 BDR(Backup Designated Router) 모두에 인접합니다. |
지정된 라우터 | 모든 멀티 액세스 네트워크에서 DR을 선택하면 네트워크의 로컬 환경을 설명하는 네트워크 LSA가 시작됩니다.플러딩 프로세스 중에 DR에서 LSA를 보내고 받는 방식으로 네트워크의 모든 라우터가 링크 상태 데이터베이스를 동기화하기 때문에 플러딩 알고리즘에서도 특수한 역할을 합니다. |
지정된 라우터 백업 | 현재 DR이 사라지면 다중 액세스 네트워크에서 BDR이 선택되어 DR의 전환 속도가 빨라집니다.BDR이 인계되면 LAN(Local-Area Network)에서 인접성 프로세스를 거치지 않아도 됩니다. 또한 BDR을 사용하면 DR이 사라지기 전에 DR이 없을 때 안정적인 플러딩 알고리즘을 진행할 수 있습니다. |
비 브로드캐스트 다중 액세스 네트워크 지원 | OSPF는 PDN(Frame Relay public data network)과 같은 네트워크를 LAN처럼 처리합니다.그러나 이러한 네트워크에 연결된 라우터가 처음에 서로를 찾기 위해서는 추가 컨피그레이션 정보가 필요합니다. |
OSPF 컨피그레이션 관리 영역 | OSPF를 사용하면 자동 시스템을 영역으로 분할할 수 있습니다.이렇게 하면 영역 내의 라우팅이 영역 외부의 모든 정보로부터 보호되도록 라우팅 보호 수준이 한층 강화됩니다.또한 자동 시스템을 영역으로 분할하면 CPU 주기 측면에서 Dijkstra 절차의 비용이 절감됩니다. |
가상 링크 | 가상 링크의 컨피그레이션을 허용하면 OSPF는 자동 시스템의 영역 레이아웃에 대한 토폴로지 제한을 제거합니다. |
라우팅 프로토콜 교환 인증 | OSPF 라우터가 라우팅 프로토콜 패킷을 수신할 때마다 패킷을 추가로 처리하기 전에 선택적으로 인증할 수 있습니다. |
유연한 라우팅 메트릭 | OSPF에서 메트릭은 아웃바운드 라우터 인터페이스에 할당됩니다.경로 비용은 경로의 구성 요소 인터페이스의 합계입니다.라우팅 메트릭은 기본적으로 링크의 대역폭에서 파생됩니다.시스템 관리자가 지연, 대역폭, 비용과 같은 네트워크 특성의 조합을 표시하도록 지정할 수 있습니다. |
동일 비용 다중 경로 | 목적지에 대한 최상의 비용 경로가 여러 개 있을 경우 OSPF는 이를 찾아 사용하여 공유 트래픽을 대상으로 로드합니다. |
가변 길이 서브넷 지원 | 각 알려진 대상으로 네트워크 마스크를 전달하여 가변 길이 서브넷 마스크를 지원합니다. |
Stub 영역 지원 | 메모리가 부족한 라우터를 지원하기 위해 영역을 stub로 구성할 수 있습니다.외부 LSA는 stub 영역 내부 및 전체에 플러딩되지 않습니다.stub 영역의 외부 목적지로 라우팅하는 것은 기본값만을 기반으로 합니다. |
프로세스 정의는 목적을 충족하거나 목표를 달성하기 위해 상담원이 수행하는 일련의 연결된 작업, 활동 및 변경 사항입니다.
프로세스 제어는 효율적이고 효율적인 방식으로 프로세스를 수행하는 것을 목표로 하는 계획 및 규제 프로세스입니다.
그래픽으로 아래 그림에 나와 있습니다.
이 프로세스의 결과는 조직에서 정의한 운영 규범을 준수해야 하며 비즈니스 목표를 기반으로 합니다.프로세스가 규범 집합에 부합할 경우 반복, 측정, 관리 및 비즈니스 목표에 도움이 될 수 있으므로 프로세스가 효과적이라고 간주됩니다.활동이 최소한으로 수행되면 그 과정이 효율적이라고 간주된다.
프로세스는 다양한 조직 경계를 포괄합니다.따라서 프로세스 정의를 담당하는 단일 프로세스 소유자가 있어야 합니다.소유자는 프로세스가 효과적이고 효율적인지 확인하고 보고하는 데 중점을 둡니다.프로세스가 유효하거나 효율적이지 못하면 프로세스 소유자가 프로세스를 수정합니다.프로세스 수정은 변경 제어 및 검토 프로세스에 의해 제어됩니다.
프로세스 정의를 위한 방향과 범위를 설정하기 위해 프로세스 목표가 설정됩니다.목표는 프로세스의 효율성을 측정하는 데 사용되는 메트릭을 정의하는 데 사용됩니다.
이 프로세스의 목표는 의도된 설계에 대해 OSPF 구현의 구축된 컨피그레이션을 검증하고 OSPF 구축을 주기적으로 감사하는 메커니즘을 제공하는 프레임워크를 제공하여 의도된 설계와 관련하여 시간이 지남에 따라 일관성을 보장하는 것입니다.
프로세스 성과 표시기는 프로세스 정의의 효과를 측정하는 데 사용됩니다.성과 지표는 측정 가능하고 정량화할 수 있어야 합니다.아래 나열된 성능 표시기는 숫자이거나 시간별로 측정됩니다.OSPF 컨피그레이션 관리 프로세스에 대한 성능 지표는 다음과 같이 정의됩니다.
전체 프로세스를 순환하는 데 필요한 시간.
사용자에게 영향을 주기 전에 OSPF 문제를 사전에 탐지하기 위해 필요한 실행 빈도.
프로세스 실행과 관련된 네트워크 로드입니다.
프로세스에서 권장하는 수정 작업 수입니다.
프로세스의 결과로 구현된 해결 조치 수입니다.
해결 조치를 이행하는 데 필요한 시간.
해결 조치를 이행하는 데 필요한 시간.
해결 조치의 백로그.
OSPF 관련 문제로 인한 다운타임입니다.
시드 파일에서 추가, 제거 또는 수정된 항목 수입니다.이것은 정확성과 안정성의 표시이다.
프로세스 입력은 프로세스의 기준 및 전제 조건을 정의하는 데 사용됩니다.프로세스 입력을 식별하면 외부 종속성에 대한 정보가 제공되는 경우가 많습니다.OSPF 컨피그레이션 관리와 관련된 입력 목록은 아래에 나와 있습니다.
OSPF 설계 문서
SNMP 폴링에 의해 수집된 OSPF MIB 데이터
Syslog 정보
프로세스 출력은 다음과 같이 정의됩니다.
이 문서의 데이터 프레젠테이션 섹션에 정의된 OSPF 컨피그레이션 보고서
OSPF 컨피그레이션 권장 사항 - 수행할 수정 작업
다음 섹션에서는 OSPF 컨피그레이션 관리와 관련된 초기화 및 반복 작업을 정의합니다.
초기화 작업은 프로세스를 구현하는 동안 한 번 실행되며 프로세스의 각 반복으로 실행되어서는 안 됩니다.
필수 구성 요소 작업을 확인하는 과정에서 작업 중 하나가 구현되지 않았거나 이 절차의 요구 사항을 효과적으로 처리할 수 있는 충분한 정보를 제공하지 않는 것으로 확인되면 프로세스 소유자가 이 사실을 문서화하고 관리자에게 제출해야 합니다.아래 표에는 사전 요구 사항 초기화 작업이 요약되어 있습니다.
필수 구성 요소 작업 | 설명 |
---|---|
작업 목표 및 입력 |
|
작업 출력 | 작업 출력은 필수 구성 요소 작업의 상태에 대한 상태 보고서입니다.지원 작업 중 비효과적이라고 판단되는 작업이 있으면 프로세스 소유자는 지원 프로세스를 업데이트하도록 요청을 제출해야 합니다.지원 프로세스를 업데이트할 수 없는 경우 이 프로세스에 미치는 영향을 평가합니다. |
작업 역할 | 네트워크 엔지니어 기술 집합 |
OSPF 컨피그레이션 관리 프로세스에서는 네트워크 검색 기능의 필요성을 제거하기 위해 시드 파일을 사용해야 합니다.시드 파일은 OSPF 프로세스가 관리하는 라우터 집합을 기록하며, 조직의 변경 관리 프로세스와 조율하기 위한 초점으로 사용됩니다.예를 들어 새 노드가 네트워크에 입력되면 OSPF 시드 파일에 추가해야 합니다.보안 요구 사항으로 인해 SNMP 커뮤니티 이름을 변경한 경우 이러한 수정 사항을 시드 파일에 반영해야 합니다.아래 표에는 시드 파일 생성 프로세스가 요약되어 있습니다.
프로세스 | 설명 |
---|---|
작업 목표 | OSPF 구성 관리 소프트웨어를 초기화하는 데 사용할 시드 파일을 만듭니다.시드 파일의 형식은 OSPF 컨피그레이션 관리 프로세스를 구현하는 데 사용되는 리소스에 따라 달라집니다.사용자 정의 스크립트가 개발되면 시드 파일의 형식은 소프트웨어 설계에 의해 정의됩니다.NMS(네트워크 관리 시스템)를 사용하는 경우 시드 파일의 형식은 NMS 설명서에 의해 정의됩니다. |
작업 입력 |
|
작업 출력 | OSPF 컨피그레이션 관리 프로세스에 대한 시드 파일입니다. |
작업 리소스 |
|
작업 역할 |
|
반복적인 작업은 프로세스의 각 반복과 함께 실행되며, 성능 지표를 개선하기 위해 해당 빈도를 결정 및 수정합니다.
시드 파일은 OSPF 컨피그레이션 관리 프로세스를 효과적으로 구현하기 위해 중요합니다.따라서 시드 파일의 현재 상태를 능동적으로 관리해야 합니다.시드 파일의 내용에 영향을 주는 네트워크의 변경 사항은 OSPF 컨피그레이션 관리 프로세스 소유자가 추적해야 합니다.
프로세스 | 설명 |
---|---|
작업 목표 |
|
작업 입력 |
|
작업 출력 |
|
작업 리소스 |
|
작업 역할 |
|
OSPF 스캔을 실행하는 데 사용되는 두 단계는 다음과 같습니다.
데이터를 수집하는 중입니다.
데이터를 분석하고 있습니다.
프로세스 사용 방법에 따라 이 두 단계의 빈도는 달라집니다.예를 들어 이 프로세스를 사용하여 설치 수정 사항을 확인할 수 있습니다.이 경우 데이터 수집은 변경 전후에 실행되며 변경 후 데이터 분석이 수행되어 변경의 성공을 확인합니다.
이 프로세스를 사용하여 OSPF 컨피그레이션 관리 설계 레코드를 확인하는 경우 데이터 수집 및 분석 빈도는 네트워크의 변경 속도에 따라 달라집니다.예를 들어 네트워크에 상당한 변화가 있을 경우 설계 검증이 일주일에 한 번 수행됩니다.네트워크에 변화가 거의 없는 경우 설계 검증이 한 달에 한 번 이상 수행되지 않습니다.
OSPF 컨피그레이션 관리 보고서의 형식은 OSPF 컨피그레이션 관리 프로세스를 구현하는 데 사용되는 리소스에 따라 달라집니다.다음 표에서는 권장 맞춤형 개발 보고서 형식을 제공합니다.
보고서 | 형식 |
---|---|
작업 입력 | OSPF 컨피그레이션 관리 보고서는 이 문서 내의 데이터 프레젠테이션 섹션을 참조하십시오. |
작업 출력 | 스캔 보고서와 논리적 설계 레코드 간에 문제가 발견되면 어떤 항목이 올바르고 잘못된 것인지 결정해야 합니다.잘못된 항목을 수정해야 합니다.설계 레코드 또는 네트워크 변경 주문을 수정해야 할 수 있습니다. |
작업 리소스 |
|
작업 역할 |
|
다음 표에서는 OSPF 컨피그레이션 관리에 적용할 수 있는 데이터에 대해 설명합니다.
데이터 | 설명 |
---|---|
OSPF 영역 | 라우터의 연결 영역을 설명하는 정보는 다음과 같습니다.
|
OSPF 인터페이스 | 다음과 같이 OSPF의 관점에서 하나의 인터페이스에 대해 설명합니다.
|
OSPF 네이버 상태 | OSPF 인접 디바이스에 대해 설명합니다.
|
Cisco는 현재 RFC 1253 OSPF 버전 2 MIB를 지원합니다 .RFC 1253에는 OSPF에 대한 SNMP 트랩 정의가 포함되어 있지 않습니다.OSPF MIB의 최신 버전은 RFC 1850 OSPF 버전 2입니다 .SNMP 트랩은 RFC 1850에서 OSPF에 대해 정의됩니다.RFC 1850은 Cisco의 OSPF MIB 구현에서 지원되지 않습니다.
자세한 내용은 이 문서의 SNMP 폴링 데이터 섹션을 참조하십시오.
어떤 플랫폼 및 코드 버전에서 지원되는 MIB의 최종 목록은 Cisco Network Management Software 페이지를 참조하십시오.
이 프로시저에 필요한 RMON 특정 데이터가 없습니다.
일반적으로 Syslog는 다양한 기술에 대해 서비스별 메시지를 생성합니다.syslog 정보는 결함 및 성능 관리에 더 적합하지만 여기에 제공된 정보는 참조입니다.Cisco 디바이스에서 생성된 OSPF Syslog 정보의 예는 OSPF 오류 메시지를 참조하십시오.
기능별 전체 시스템 메시지 목록은 메시지 및 복구 절차를 참조하십시오.
이 버전의 OSPF 컨피그레이션 관리 절차에서는 CLI 데이터가 필요하지 않습니다.
아래 표에서는 SNMP 데이터 수집의 다양한 구성 요소를 정의합니다.
SNMP 데이터 구성 요소 | 정의 |
---|---|
일반 SNMP 구성 | SNMP 컨피그레이션 모범 사례에 대한 일반 정보는 SNMP 구성을 참조하십시오. |
서비스별 SNMP 컨피그레이션 | 이 절차에는 서비스별 SNMP 컨피그레이션이 필요하지 않습니다. |
SNMP MIB 요구 사항 | 위의 데이터 식별 섹션을 참조하십시오. |
SNMP MIB 폴링 수집 | SNMP 폴링된 데이터는 hp OpenView와 같은 상용 시스템 또는 사용자 지정 스크립트로 수집됩니다.수집 알고리즘에 대한 자세한 내용은 이 문서의 데이터 수집 알고리즘 예 섹션을 참조하십시오. |
SNMP MIB 트랩 수집 | Cisco 디바이스에서 지원되는 현재 버전의 OSPF MIB는 SNMP 트랩을 지원하지 않습니다.이 절차에 필요한 SNMP 트랩이 없습니다. |
이 버전의 프로시저에 필요한 RMON 컨피그레이션 및 데이터가 없습니다.
일반 syslog 구성 지침은 이 문서의 범위를 벗어납니다.자세한 내용은 단일 내부 네트워크를 통한 Cisco Secure PIX Firewall 구성 및 문제 해결을 참조하십시오.
OSPF 특정 요구 사항은 다음 명령을 사용하여 인접 디바이스 변경 사항을 syslog 메시지로 로깅하도록 OSPF 라우터를 구성하여 해결됩니다.
OSPF_ROUTER(config)# ospf log-adj-changes
일반적으로 Cisco IOS CLI는 NE에 포함된 원시 정보에 대한 가장 직접적인 액세스를 제공합니다.그러나 CLI 액세스는 이 절차에 정의된 글로벌 컨피그레이션 관리보다 트러블슈팅 절차 및 변경 관리 활동에 더 적합합니다.CLI를 통한 액세스는 대규모 네트워크 관리를 위해 확장되지 않습니다.이러한 경우에는 자동화된 정보 액세스가 필요합니다.
이 버전의 OSPF 컨피그레이션 관리 절차에서는 CLI 컨피그레이션 및 데이터가 필요하지 않습니다.
다음은 OSPF 영역 보고서의 예제 형식입니다.보고서의 형식은 상용 NMS의 기능(사용하는 경우) 또는 사용자 지정 스크립트의 설계된 출력에 의해 결정됩니다.
영역 | 데이터 필드 | 마지막 실행 | 실행 |
---|---|---|---|
영역 ID #1 | 인증 | ||
SPF 실행 | |||
ABR 수 | |||
ASBR 수 | |||
LSA 수 | |||
LSA 체크섬 | |||
주소 오류 | |||
라우팅 폐기 | |||
경로를 찾을 수 없음 | |||
영역 ID #n | 인증 | ||
SPF 실행 | |||
ABR 수 | |||
ASBR 수 | |||
LSA 수 | |||
LSA 체크섬 | |||
주소 오류 | |||
라우팅 폐기 | |||
경로를 찾을 수 없음 |
다음은 OSPF 인터페이스 보고서의 예제 형식입니다.실제로 보고서 형식은 상용 NMS의 기능(사용하는 경우) 또는 사용자 지정 스크립트의 설계된 출력에 의해 결정됩니다.
영역 | 장치 | 인터페이스 | 데이터 필드 | 마지막 실행 | 실행 |
---|---|---|---|---|---|
영역 ID #1 | 노드 ID #1 | 인터페이스 ID #1 | IP 주소 | ||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
인터페이스 ID #n | IP 주소 | ||||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
노드 ID #n | 인터페이스 ID #1 | IP 주소 | |||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
인터페이스 ID #n | IP 주소 | ||||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
영역 ID #n | 노드 ID #1 | 인터페이스 ID #1 | IP 주소 | ||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
인터페이스 ID #n | IP 주소 | ||||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
노드 ID #n | 인터페이스 ID #1 | IP 주소 | |||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 | |||||
인터페이스 ID #n | IP 주소 | ||||
영역 ID | |||||
관리 상태 | |||||
OSPF 상태 | |||||
메트릭/비용/타이머 |
다음은 OSPF 네이버 보고서의 예제 형식입니다.실제로 보고서 형식은 상용 NMS의 기능(사용하는 경우) 또는 사용자 지정 스크립트의 설계된 출력에 의해 결정됩니다.
영역 | 장치 | 네이버 | 데이터 필드 | 마지막 실행 | 실행 |
---|---|---|---|---|---|
영역 ID #1 | 노드 ID #1 | 네이버 ID #1 | 라우터 ID | ||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
네이버 ID #n | 라우터 ID | ||||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
노드 ID #n | 네이버 ID #1 | 라우터 ID | |||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
네이버 ID #n | 라우터 ID | ||||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
영역 ID #n | 노드 ID #1 | 네이버 ID #1 | 라우터 ID | ||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
네이버 ID #n | 라우터 ID | ||||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
노드 ID #n | 네이버 ID #1 | 라우터 ID | |||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 | |||||
네이버 ID #n | 라우터 ID | ||||
라우터 IP 주소 | |||||
주/도 | |||||
이벤트 | |||||
리탄스 케 |
syslog 정보의 수집 및 처리, 일반 SNMP MIB 변수의 수집 폴링을 지원하는 상용 툴이 있습니다.
이 절차에서 정의한 대로 OSPF 구성 관리를 지원하는 상용 또는 공용 인터넷 모니터링 툴은 알려져 있지 않습니다.따라서 로컬 사용자 지정 스크립트 및 절차가 필요합니다.
개체 이름 | 개체 설명 |
---|---|
ip경로 대상 | 경로의 대상 IP 주소입니다.값이 0.0.0.0인 항목은 기본 경로로 간주됩니다.단일 대상에 대한 여러 경로가 테이블에 나타날 수 있지만 이러한 여러 항목에 대한 액세스는 사용 중인 네트워크 관리 프로토콜에 의해 정의된 테이블 액세스 메커니즘에 따라 달라집니다.::= { ipRouteEntry 1 } 개체 식별자 = 1.3.6.1.2.1.4.21.1.1 |
ip경로 마스크 | ipRouteDest 필드의 값과 비교되기 전에 대상 주소와 논리적 마스크를 나타냅니다.임의 서브넷 마스크를 지원하지 않는 시스템의 경우 에이전트는 다음 마스크 네트워크 중 하나를 사용하여 해당 ipRouteDest 필드의 값이 클래스 A, B 또는 C 네트워크에 속하는지 여부를 결정하여 ipRouteMask 값을 구성합니다.
참고: 모든 IP 라우팅 하위 시스템은 이 메커니즘을 암시적으로 사용합니다. ::= { ipRouteEntry 11 } 개체 식별자 = 1.3.6.1.2.1.4.21.1.11 |
ip경로NextHop | 이 경로의 다음 홉의 IP 주소입니다.브로드캐스트 미디어로 인식되는 인터페이스에 바인딩된 경로의 경우 이 필드의 값은 인터페이스의 에이전트 IP 주소입니다.::= { ipRouteEntry 7 } 개체 식별자 = 1.3.6.1.2.1.4.21.1.7 |
ipRouteIfIndex | 경로의 다음 홉에 도달하는 로컬 인터페이스를 고유하게 식별하는 인덱스 값입니다.이 인터페이스는 IfIndex 값으로 식별되는 인터페이스와 같습니다.::= { ipRouteEntry 2 } 개체 식별자 = 1.3.6.1.2.1.4.21.1.2 |
개체 이름 | 개체 설명 |
---|---|
ipAdEntIf인덱스 | 항목에 적용할 수 있는 인터페이스를 고유하게 식별하는 인덱스 값입니다.이 인터페이스는 IfIndex 값으로 식별되는 인터페이스와 같습니다.::= { ipAddrEntry 2 } 개체 식별자 = 1.3.6.1.2.1.4.20.1.2 |
ip수신 주소 오류 | IP 헤더의 IP 주소가 엔터티의 잘못된 대상 필드이므로 삭제된 입력 데이터그램 수입니다.이 카운트에는 잘못된 주소(0.0.0.0) 및 지원되지 않는 클래스 주소(클래스 E)가 포함되어 있습니다. IP 게이트웨이가 아니고 데이터그램을 전달하지 않는 엔터티의 경우 대상 주소가 로컬 주소가 아니므로 카운터에 삭제된 데이터그램이 포함됩니다.{ ip 5 } 개체 식별자 = 1.3.6.1.2.1.4.5 |
ipRoutingDiscards | 폐기된 유효한 라우팅 항목 수입니다.이러한 엔트리를 폐기하는 한 가지 가능한 이유는 다른 라우팅 엔트리에 대한 버퍼 공간을 확보하기 위해서입니다.{ ip 23 } 개체 식별자 = 1.3.6.1.2.1.4.23 |
ipOutNo경로 | 목적지로 전송할 경로를 찾을 수 없으므로 폐기된 IP 데이터그램 수입니다.{ ip 12 } 개체 식별자 = 1.3.6.1.2.1.4.12 |
개체 이름 | 개체 설명 |
---|---|
ospf영역ID | 영역을 고유하게 식별하는 32비트 정수입니다.영역 ID 0.0.0.0은 OSPF 백본에 사용됩니다.::= { ospfAreaEntry 1 } 개체 식별자 = 1.3.6.1.2.1.14.2.1.1 |
ospf인증 유형 | 이 영역에 대해 지정된 인증 유형입니다.추가 인증 유형은 영역별로 로컬로 할당할 수 있습니다.기본값은 0. ::= { ospfAreaEntry 2 } 개체 식별자 = 1.3.6.1.2.1.14.2.1.2 |
OSPF실행 | 이 영역의 링크 상태 데이터베이스를 사용하여 영역 내 경로 테이블을 계산한 횟수입니다.개체 식별자 = 1.3.6.1.2.1.14.2.1.4 |
ospf영역BdrRtrCount | 이 영역 내에서 연결할 수 있는 총 ABR 수입니다.처음에는 기본값인 0이며 각 SPF 패스에서 계산됩니다.::= { ospfAreaEntry 5 } 객체 식별자 = 1.3.6.1.2.1.14.2.1.5 |
ospfASBdrRtrCount | 이 영역 내에서 연결할 수 있는 총 ABSR 수입니다.처음에는 0(기본값)이며 각 SPF 패스에서 계산됩니다.::= { ospfAreaEntry 6 } 객체 식별자 = 1.3.6.1.2.1.14.2.1.6 |
ospf영역LSACount | 영역의 링크 상태 데이터베이스에 있는 총 LSA 수(외부 LSA를 제외).기본값은 0. ::= { ospfAreaEntry 7 } 개체 식별자 = 1.3.6.1.2.1.14.2.1.7 |
ospf영역LSACksum합계 | 영역의 링크 상태 데이터베이스에 포함된 LSA의 LS 체크섬을 서명하지 않은 32비트 합계입니다.이 합에는 외부(LS 유형 5) LSA가 제외됩니다.이 합계를 사용하여 라우터의 링크 상태 데이터베이스가 변경되었는지 확인하고 두 라우터의 링크 상태 데이터베이스를 비교할 수 있습니다.기본값은 0. ::= { ospfAreaEntry 8 } 개체 식별자 = 1.3.6.1.2.1.14.2.1.8 |
개체 이름 | 개체 설명 |
---|---|
OspfIfIp주소 | OSPF 인터페이스의 IP 주소입니다.개체 식별자 = 1.3.6.1.2.1.14.7.1.1 |
OspfIf이벤트 | OSPF 인터페이스의 상태가 변경되었거나 오류가 발생한 횟수입니다.개체 식별자 = 1.3.6.1.2.1.14.7.1.15 |
OspfIf상태 | OSPF 인터페이스 상태입니다.개체 식별자 = 1.3.6.1.2.1.14.7.1.12 |
개체 이름 | 개체 설명 |
---|---|
OSPFnbrIp주소 | 이 네이버의 IP 주소입니다.::= { ospfNbrEntry 1 } 개체 식별자 = 1.3.6.1.2.1.14.10.1.1 |
ospfNbrAddressLessIndex | IP 주소가 없는 인덱스의 인터넷 표준 MIB에서 해당 IfIndex 값.행 생성 시 인스턴스에서 파생될 수 있습니다.::= { ospfNbrEntry 2 } 개체 식별자 = 1.3.6.1.2.1.14.10.1.2 |
ospfNbrRtrId | IpAddress로 표시되는 32비트 정수로, 자동 시스템에서 인접 라우터를 고유하게 식별합니다.기본값은 0.0.0.0. ::= { ospfNbrEntry 3 } 개체 식별자 = 1.3.6.1.2.1.14.10.1.3입니다. |
ospfNbrState | 인접 디바이스와의 관계 상태입니다.상태는 다음과 같습니다.
|
ospfNbr이벤트 | 인접 디바이스 관계가 상태를 변경했거나 오류가 발생한 횟수입니다.기본값은 0. ::= { ospfNbrEntry 7 } 개체 식별자 = 1.3.6.1.2.1.14.10.1.7 |
ospfNbrLSRetransQLen | 재전송 대기열의 현재 길이입니다.기본값은 0. ::= { ospfNbrEntry 8 } 개체 식별자 = 1.3.6.1.2.1.14.10.1.8 |
이 보고서를 조사하는 동안, 원형 'C' 프로그램이 개발되었다.oscan이라는 프로그램은 Visual C++ 버전 5.0과 함께 Microsoft Developer Studio 97을 사용하여 작성되었습니다. SNMP 함수 API(응용 프로그래밍 인터페이스)를 제공하는 두 개의 특정 라이브러리가 있습니다. 이러한 라이브러리는 snmpapi.lib 및 mgmtapi.lib입니다.
Microsoft API에서 제공하는 함수는 세 가지 주요 범주로 그룹화되고 아래 표에 나열되어 있습니다.
상담원 기능 | 관리자 기능 | 유틸리티 기능 |
---|---|---|
SnmpExtensionInitExtensionInitEx SnmpExtensionQuery SnmpExtensionTrap | SnmpMgrClose SnmpMgrGetTrap SNMPMgrOidToStr SnmpMgrOpen SnmpMgrRequest SNMPMgrStrToOid SnmpMgrTrapListen | SnmpUtilMemAlloc SNMPutilMemFree SNMPutilMemReAlloc SNMPutilOidAppend SNMPutilOidCmp SNMPutilOidCpy SNMPUtilOidFree SNMPUtilUtilPrintAsnUntilSnmpVarVarIntlIntlInspt bindCopy SNMPutilVarBindListCopy SNMPutilVarBindFree SNMPutilVarBindListFree |
다음은 Microsoft API를 캡슐화한 샘플 프로토타입 코드입니다.
SnmpWalkStrOid
SNMP워크asnOid
snmpWalkVarBind
snmpWalkVarBindList
이러한 기능은 OSPF 구성 데이터를 유지 관리하는 데 사용되는 다양한 SNMP MIB 테이블에 대한 액세스를 허용하는 일반 API를 제공합니다.액세스할 테이블의 OID(개체 식별자)는 테이블 특정 콜백 함수와 함께 oscan API로 전달됩니다.콜백 함수에는 테이블에서 반환된 데이터에 대해 작동하는 인텔리전스가 있습니다.
첫 번째 작업은 oscan 프로그램의 대상이 될 노드 목록을 작성하는 것입니다."디바이스 검색" 문제를 방지하려면 스캔할 노드를 식별하는 데 시드 파일이 필요합니다.시드 파일은 IP 주소 및 SNMP 읽기 전용 커뮤니티 문자열 등의 정보를 제공합니다.
oscan 프로그램은 라우터에서 수집한 SNMP 정보를 저장하기 위해 여러 내부 데이터 구조를 유지해야 합니다.일반적으로 수집되는 각 SNMP MIB 테이블에 대한 내부 데이터 구조가 있습니다.
Main load node array based on information in the seed file. while more entries in the node array start SNMP session for this node collect IP route table for this node collect OSPF area table for this node collect OSPF Neighbor table for this node collect sysName for this node collect OSPF Interface table for this node end SNMP session for this node end while
이 작업 중에 라우터의 CPU를 오버로드하기 쉽기 때문에 SNMP를 사용하여 IP 경로 테이블에 액세스하는 동안 주의해야 합니다.따라서 oscan 프로그램은 사용자 구성 가능한 지연 매개변수를 사용합니다.이 매개변수는 각 SNMP 요청 사이에 지연을 제공합니다.대규모 환경에서는 정보를 수집하는 데 소요되는 총 시간이 매우 중요할 수 있습니다.
경로 테이블에는 관심 있는 4가지 정보가 포함되어 있습니다.
ip경로 대상
ip경로 마스크
ip경로NextHop
ipRouteIfIndex
경로 테이블은 ipRouteDest로 인덱싱됩니다.따라서 SNMP get-request에서 반환되는 각 개체는 OID에 ipRouteDest가 추가됩니다.
object ipRouteIfIndex는 IP 주소 테이블(ipAddrTable)에 인덱싱하는 정수입니다. ipAddrTable은 ipAdEntAddr 개체(인터페이스의 IP 주소)를 사용하여 인덱싱됩니다. 인터페이스의 IP 주소를 가져오려면 4단계 프로세스가 필요합니다.
라우팅 테이블에서 ipRouteIfIndex를 수집합니다.
패턴 일치를 위해 ipRouteIfIndex를 사용하여 ipAddrTable에 액세스합니다.
패턴이 발견되면 OID를 문자열로 변환하고 인터페이스의 IP 주소가 될 마지막 네 개의 점으로 구분된 십진수 필드를 수집합니다.
인터페이스의 IP 주소를 다시 IP 경로 테이블에 저장합니다.
IP 경로 테이블에 액세스하기 위한 일반 알고리즘은 아래와 같습니다.이때 ipRouteIfIndex의 정수 값만 저장됩니다.프로세스 후반부에서 인터페이스 정보를 수집할 때 ipAddrTable에 액세스되고 나머지 정보가 수집되어 내부 IP 경로 테이블에 배치됩니다.
OID List = ipRouteDestOID, ipRouteMaskOID, ipRouteNextHopOID, ipRouteIfIndexOID; For each object returned by SNMP route table walk Sleep // user configurable polling delay. check varbind oid against OID list if OID is ipRouteDestOID add new entry in the internal route table array if OID is one of the others search internal route array for matching index value store information in array
수집된 정보는 아래 라우터 CLI의 익숙한 출력과 유사한 표로 표시됩니다.
ROUTE TABLE ********************************************************** Destination Mask GW Interface 10.10.10.4 255.255.255.252 10.10.10.5 10.10.10.5 10.10.10.16 255.255.255.252 10.10.10.6 10.10.10.5 10.10.10.24 255.255.255.252 10.10.10.25 10.10.10.25 10.10.10.28 255.255.255.252 10.10.11.2 10.10.11.1 10.10.10.36 255.255.255.252 10.10.10.6 10.10.10.5 10.10.11.0 255.255.255.0 10.10.11.1 10.10.11.1 10.10.13.0 255.255.255.0 10.10.11.2 10.10.11.1
OSPF 영역 테이블의 정보 수집은 OSPF 영역 테이블(ospfAreaTable)을 스캔하고 반환된 대로 데이터를 처리하여 수행됩니다.ospfAreaTable에 대한 인덱스는 osfpAreaId입니다.ospfAreaId는 IP 주소와 동일한 점으로 구분된 십진수 형식으로 저장됩니다.따라서 ipRouteTable 및 ipRouteIfIndex를 처리하고 검색하는 데 사용된 동일한 서브루틴을 여기에서 다시 사용할 수 있습니다.
이 섹션에는 OSPF 영역 테이블에 실제로 없는 여러 데이터 항목이 포함되어 있습니다.예를 들어 ipInAddrErrors, IpRoutingDiscards 및 ipOutNoRoute 객체는 MIB-2 정의에 있지만 OSPF 영역과 연결되지 않습니다.이러한 객체는 라우터와 연결됩니다.따라서 이러한 카운터는 영역의 각 노드에 대한 값을 영역 카운터에 추가하여 영역 메트릭으로 사용됩니다.예를 들어 OSPF 영역 보고서에서 경로 없음 때문에 삭제된 패킷 수는 실제로 해당 영역의 모든 라우터에서 폐기한 패킷의 합계입니다.영역의 라우팅 상태를 전체적으로 볼 수 있는 상위 레벨 메트릭입니다.
OID List = ipInAddrErrorsOID, ipRoutingDiscardsOID, ipOutNoRouteOID, areaIdOID, authTypeOID, spfRunsOID, abrCountOID, asbrCountOID, lsaCountOID, lsaCksumSumOID; For object returned from the SNMP walk of the Area Table Sleep // user configurable polling delay. check varbind oid against OID list. if OID is ospfAreaId add new entry in the internal route table array if OID one of the others search internal array for matching index value store information in array end of for loop get ipInAddrErrors, ipRoutingDiscards, ipOutNoRoute add values to overall Area counters
수집된 정보는 아래 ASCII 테이블로 표시됩니다.
AREAS ********************************************************** AREA = 0.0.0.0 AREA = 0.0.0.2 authType = 0 authType = 0 spfRuns = 38 spfRuns = 18 abrCount = 2 abrCount = 1 asbrCount = 0 asbrCount = 0 lsaCount = 11 lsaCount = 7 lsaCksumSum = 340985 lsaCksumSum = 319204 ipInAddrErrors = 0 ipInAddrErrors = 0 ipRoutingDiscards = 0 ipRoutingDiscards = 0 ipOutNoRoutes = 0 ipOutNoRoutes = 0
네이버 테이블의 인덱스는 두 값입니다.
ospfNbrIpAddr—ospfNbrIpAddr은 인접 디바이스의 IP 주소입니다.
ospfNbrAddressLessIndex - ospfNbrAddressLessIndex는 다음 두 값 중 하나일 수 있습니다.
IP 주소가 할당된 인터페이스의 경우 0입니다.
IP 주소가 할당되지 않은 인터페이스의 경우 인터넷 표준 MIB의 IfIndex로 해석됩니다.
인덱스에는 두 개의 값이 있으므로, 반환된 OID에 추가된 추가 정보에 대해 이전에 사용된 알고리즘을 조정해야 합니다.이 조정 후 ipRouteTable 및 ipRouteIfIndex를 처리하고 검색하는 데 사용된 동일한 서브루틴을 여기에서 다시 사용할 수 있습니다.
OID List = ospfNbrIpAddrOID, ospfNbrAddressLessIndexOID, ospfNbrRtrIdOID, ospfNbrStateOID, ospfNbrEventsOID, ospfNbrLSRetransQLenOID, For object returned from the SNMP walk of the Neighbor Table Sleep // user configurable polling delay. check varbind OID against OID list. if OID matches ospfNbrIpAddr add new entry in the internal neighbor table array if OID matches one of the others search array for matching index value store information in array
수집된 정보는 아래 ASCII 테이블로 표시됩니다.
NEIGHBORS ************************************************************ NEIGHBOR #0 NEIGHBOR #1 Nbr Ip Addr = 10.10.10.6 Nbr Ip Addr = 10.10.11.2 Nbr Rtr Id = 10.10.10.17 Nbr Rtr Id = 10.10.10.29 Nbr State = 8 Nbr State = 8 Nbr Events = 6 Nbr Events = 30 Nbr Retrans = 0 Nbr Retrans = 0