show ip ospf neighbor 명령은 양방향 상태에서 중단된 인접 디바이스를 나타내는 이유는 무엇입니까?

다운로드 옵션

PDF (202.4 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (111.8 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (141.8 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2005년 8월 10일

문서 ID:13683

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 show ip ospf neighbor 명령이 양방향 상태로 중단된 인접 디바이스를 표시하는 이유를 설명합니다. 또한 컨피그레이션 팁을 제공합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

OSPF가 인접 디바이스를 구성하는 방법

이 토폴로지에서는 모든 라우터가 이더넷 네트워크를 통해 OSPF(Open Shortest Path First)를 실행하고 있습니다.

다음은 R7 및 R8에서 show ip ospf neighbor 명령의 샘플 출력입니다.

R7# show ip ospf neighbor

Neighbor ID     Pri       State           Dead Time   Address         Interface
170.170.3.4       1       2WAY/DROTHER    00:00:34    170.170.3.4     Ethernet0
170.170.3.3       1       2WAY/DROTHER    00:00:34    170.170.3.3     Ethernet0
170.170.3.8       1       FULL/DR         00:00:32    170.170.3.8     Ethernet0
170.170.3.2       1       FULL/BDR        00:00:39    170.170.3.2     Ethernet0

R8# show ip ospf neighbor

Neighbor ID     Pri       State           Dead Time   Address         Interface
170.170.3.4       1       FULL/DROTHER    00:00:37    170.170.3.4     Ethernet0
170.170.3.3       1       FULL/DROTHER    00:00:37    170.170.3.3     Ethernet0
170.170.3.7       1       FULL/DROTHER    00:00:38    170.170.3.7     Ethernet0
170.170.3.2       1       FULL/BDR        00:00:32    170.170.3.2     Ethernet0

R7은 DR(Designated Router) 및 BDR(Backup Designated Router)에서만 전체 인접성을 설정합니다. 다른 모든 라우터에는 양방향 인접성이 설정되어 있습니다. 이는 OSPF의 정상적인 동작입니다.

라우터가 네이버 hello 패킷에서 자신을 볼 때마다 양방향 통신을 확인하고 네이버 상태를 양방향으로 전환합니다. 이때 라우터는 DR 및 BDR 선택을 수행합니다. DR과 BDR이 선택되면 두 라우터 중 하나가 DR 또는 BDR인 경우 라우터가 인접 디바이스와 완전한 인접성을 형성하려고 시도합니다. OSPF 라우터는 데이터베이스 동기화 프로세스를 성공적으로 완료한 라우터와 완전히 인접합니다. OSPF 라우터가 링크 상태 정보를 교환하여 동일한 정보로 데이터베이스를 채우는 프로세스입니다. 이 데이터베이스 동기화 프로세스는 두 라우터 중 하나가 DR 또는 BDR인 경우에만 두 라우터 간에 실행됩니다.

라우터가 DR 또는 BDR을 사용하여 전체 인접성을 형성하는 이유는 무엇입니까?

OSPF는 대규모 네트워크의 요구 사항에 초점을 맞추어 설계되었습니다. 모든 라우터가 서로 연결된 모든 라우터와 인접성을 형성할 경우 네트워크를 통해 많은 수의 LSA(Link-State Advertisement)가 전송됩니다. n이 브로드캐스트 네트워크에 연결된 라우터 개수이면 n * (n-1) / 2 네이버 쌍이 있습니다. 모든 네이버 쌍이 데이터베이스를 동기화하려고 하면 LSA의 양이 매우 큽니다. 이 시나리오에서는 라우터가 LSA를 주변의 모든 이웃에 플러딩하고, 그 인접 이웃에 플러딩하는 등의 순서로 플러딩됩니다. 이 네이버 다이어그램에서 볼 수 있듯이 각 라우터가 각 네이버와 데이터베이스를 동기화해야 하는 경우 각 라우터는 4개의 인접성을 설정해야 합니다.

OSPF는 DR과 BDR을 사용하여 네트워크의 모든 라우터 쌍 간의 동기화를 방지합니다. 이렇게 하면 DR 및 BDR에만 인접성이 형성되고 네트워크를 통해 전송되는 LSA 수가 줄어듭니다. 이제 DR과 BDR만 네 개의 인접성을 가지며 다른 모든 라우터에는 두 개의 인접성이 있습니다. 따라서 NBMA(Point-to-Multipoint Network over nonbroadcast Multiaccess) 미디어의 허브에 있는 라우터를 DR/BDR로 구성해야 합니다. 자세한 내용은 NBMA Mode over Frame Relay에서 OSPF 실행 문제 문서를 참조하십시오.

라우터를 구성하여 DR 또는 BDR이 될 수 없는 경우가 있습니다. ip ospf priority #interface 하위 명령을 사용하여 OSPF 우선순위를 0으로 설정하여 이 작업을 수행할 수 있습니다. 두 OSPF 인접 디바이스 모두 OSPF 인터페이스 우선순위를 0으로 설정하면 전체 인접성 대신 양방향 인접성을 설정합니다.

아래 토폴로지는 예를 제공합니다. Frame Relay를 통해 3개의 라우터가 연결됩니다. 프레임 릴레이 인터페이스는 브로드캐스트로 정의되지만 주 네트워크에 다시 연결된 라우터만 DR이 될 수 있습니다. 나머지 두 라우터는 인터페이스 우선 순위가 0으로 설정되어 있으므로 DR 또는 BDR이 될 수 없습니다. 비록 그들은 이웃이 되지만, 그들은 단지 양방향 주에 도달한다.

이 토폴로지의 네이버 테이블은 다음과 같습니다.

DRother1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.9.5       1   FULL/DR         00:00:30    170.170.9.5     Serial0.5
170.170.10.8      0   2WAY/DROTHER    00:00:38    170.170.9.8     Serial0.5
DRother1#

위 그림에서 DRother1 라우터는 DRother2 라우터와 양방향 인접성을 설정합니다.