OSPF 인접한 라우터 문제 해결

소개

이 문서에서는 OSPF(Open Shortest Path First) 인접 디바이스가 완전히 인접한 방식과 관련된 일반적인 문제를 설명합니다.

사전 요구 사항

요구 사항

이 문서에서는 IP 라우팅 프로토콜 및 OSPF 라우팅 프로토콜에 대한 기본적인 지식이 필요합니다. IP 라우팅 프로토콜에 대한 자세한 내용은 How to Configure Basic IP Routing을 참조하십시오. OSPF에 대한 자세한 내용은 OSPF(Open Shortest Path First) 지원 페이지를 참조하십시오.

사용되는 구성 요소

이 문서의 정보는 다음과 같은 소프트웨어 및 하드웨어 버전을 기준으로 합니다.

• OSPF는 Cisco 2900 Series 및 Layer 3 스위치와 같은 모든 라우터에서 구성할 수 있습니다.

• OSPF는 Cisco IOS^® Software 릴리스 10.0 이상에서 지원됩니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

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

배경 정보

OSPF 인접성이 성공적으로 형성되면 OSPF 인접 디바이스가 FULL 인접 디바이스 상태를 갖습니다. 인접성의 형성을 검사하려면 명령을debug ip ospf adj입력합니다. debug 명령을 입력하기 전에 Debug 명령에 대한 중요 정보를 참조하십시오.

인접성

라우터가 네이버라는 사실만으로는 링크 상태 업데이트 교환을 보장할 수 없습니다. 링크 상태 업데이트를 교환하려면 인접성을 형성해야 합니다. 인접성은 이러한 교환에 대한 매개변수가 협상된 후 라우팅 정보를 교환하는 라우터에 의해 형성된 고급 형태의 네이버십입니다. 라우터는 링크 상태 데이터베이스에서 보기를 동기화하면 FULL 인접성 상태에 도달합니다.

인터페이스 유형은 인접성의 형성 방법에 중요한 역할을 합니다. 예를 들어, Point-to-Point 링크의 인접 디바이스는 항상 인접 디바이스가 되려고 하는 반면, 이더넷과 같은 브로드캐스트 미디어에 연결된 라우터는 인터페이스의 인접 라우터 하위 집합으로만 인접 디바이스가 될 수 있습니다.

라우터가 네이버와 인접성을 형성하면 링크 상태 데이터베이스의 전체 복사본을 교환하는 것으로 시작합니다. 그러면 네이버는 링크 상태 데이터베이스의 전체 복사본을 라우터와 교환합니다. 여러 네이버 상태가 통과되면 라우터가 완전히 인접해집니다.

네이버 상태

OSPF 인접 디바이스의 상태를 확인하려면 show ip ospf neighbor 명령을 사용합니다. 이 명령의 출력은 다음 중 하나를 나타냅니다.

• 전혀 없음

• state = down

• 상태 = init

• 상태 = exstart

• state = exchange

• 상태 = 양방향

• 상태 = 로드 중

다른 OSPF 상태도 있지만 여기에 표시된 상태는 show ip ospf neighbor 명령 출력에 가장 많이 표시됩니다. 모든 OSPF 네이버 상태에 대한 자세한 내용 및 설명은 OSPF 네이버 상태를 참조하십시오.

상태 표시 안 함

명령이 show ip ospf neighbor 아무 것도 표시하지 않거나 관심 있는 특정 네이버에 대해 아무 것도 표시하지 않으면 이 라우터가 해당 네이버에서 "유효한" OSPF HELLO를 받지 못했습니다. 이는 OSPF가 네이버에서 HELLO 패킷을 수신하지 않았거나 매우 기본적인 온전성 검사에 실패한 HELLO 패킷을 수신했음을 의미합니다.

다음 사항을 확인하십시오.

• 인터페이스가 로컬 라우터와 인접 라우터의 라인 프로토콜과 함께 가동 중입니까? 명령을show interface입력하여 인터페이스 상태를 확인합니다.

• 다음 그림과 같이 인접 라우터 간의 IP 연결을 확인합니다.

  • 인접 디바이스가 명령에ping응답합니까? 인접 라우터에서 해당 인터페이스에 할당된 IP 주소를 ping합니다. 동일한 IP 주소에 명령을traceroute입력하고 대상에 도달하는 데 두 홉 이상이 걸리지 않는지 확인합니다.

  • 명령을 입력하면 인접 디바이스가ping 224.0.0.5응답합니까? (224.0.0.5는 OSPF HELLO가 전송되는 IP 주소입니다.)

  • 인바운드 액세스 목록 또는 한 네이버에서 다른 네이버로 IP 패킷을 전달하는 것을 금지할 수 있는 다른 디바이스(예: 스위치)를 확인합니다.

• OSPF는 사용자 인터페이스 및 인접 라우터의 인터페이스에서 모두 활성화되어 있습니까? 확인하려면 명령을 show ip ospf interface 입력합니다.

• OSPF는 로컬 또는 인접 라우터의 인터페이스에 대해 패시브로 구성됩니까? HELLO show ip ospf interface 패킷이 인터페이스 외부로 전송되어야 하는지 확인하려면 명령을 입력합니다. 활성 OSPF 인터페이스에는 다음과 유사한 행이 표시됩니다.

  Router#show ip ospf interface 
  GigabitEthernet0/0 is up, line protocol is up 
  Internet Address 10.1.1.1/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 10.1.1.1, Network Type BROADCAST, Cost: 1
  Topology-MTID Cost Disabled Shutdown Topology Name
  0 1 no no Base
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 10.1.1.2, Interface address 10.1.1.2
  Backup Designated router (ID) 10.1.1.1, Interface address 10.1.1.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  oob-resync timeout 40
  Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 1 msec, maximum is 1 msec
  Neighbor Count is 1, Adjacent neighbor count is 1 
  Adjacent with neighbor 10.1.1.2 (Designated Router)
  Suppress hello for 0 neighbor(s)

• 인접 라우터에 서로 다른 라우터 ID가 있는지 확인합니다. 라우터 ID는 OSPF 네트워크의 각 라우터를 식별하는 데 사용됩니다. 동일한 라우터가 있는 라우터는 서로 보낸 HELLO를 무시하며 인접하지 않습니다. 명령 출력의 첫 번째 show ip ospf 행에는 각 라우터의 현재 라우터 ID가 표시됩니다.

• 다음 HELLO 매개변수가 네이버 인터페이스에서 일치하는지 확인합니다.

  • OSPF area number(OSPF 영역 번호) - 확인할 show ip ospf interface interface-name 명령을 입력합니다.

  • OSPF 영역 유형(예: stub 또는 NSSA) - 확인할 명령을 show ip ospf 입력합니다.

  • Subnet and subnet mask(서브넷 및 서브넷 마스크) - 확인할 show interface 명령을 입력합니다.

  • OSPF HELLO and Dead timer values(OSPF HELLO 및 Dead 타이머 값) - 확인하려면 show ip ospf interface interface-name 명령을 입력합니다.

• 문제가 지점 간 링크(예: PPP 또는 HDLC[High-Level Data Link Control])에 있고 이 라우터 쌍 사이에 둘 이상의 병렬 링크가 있는 경우 라인이 제대로 연결되었는지 확인합니다. 한 라우터의 인터페이스 Serial0/0을 인접 라우터의 인터페이스 Serial0/0과 연결하고 Serial1/0을 인접 라우터의 인터페이스 Serial1/0과 연결하려고 계획했지만 실수로 교차하여 각 라우터의 Serial0/0을 다른 라우터의 Serial1/0과 연결했다고 가정합니다. 명령에서 ping 이러한 문제를 발견할 수 없지만 OSPF에서 인접성을 설정하지 못합니다. CDP(Cisco Discovery Protocol)에서 제공하는 정보를 사용하여 올바른 디바이스 상호 연결을 확인합니다. 원격 디바이스의 show cdp neighbor interface-name 이름 및 PortID가 네트워크 설계와 일치하는지 확인하려면 명령을 입력합니다.

참고: OSPF 인접성은 보조 네트워크가 아닌 기본 네트워크에서만 형성됩니다.

이러한 검사가 모두 확인되었지만 명령이 show ip ospf neighbor 여전히 아무것도 표시하지 않은 경우 문제가 그리 흔하지 않으며 Cisco TAC에 문의하여 도움을 받을 수 있습니다.

네이버 다운 상태

HELLO 패킷의 수신을 통해 동적으로 검색된 인접 디바이스는 OSPF 프로세스에 의해 삭제될 경우 중단 상태로 돌아갈 수 있습니다. 예를 들어, OSPF가 Dead 타이머 간격보다 긴 시간 동안 인접 디바이스로부터 HELLO 패킷을 수신하지 않는 경우 다운 상태는 해당 인접 디바이스에 대해 일시적입니다. 상위 상태로 발전하거나 알려진 네이버의 테이블에서 삭제됩니다. 이것은 "잊혀진" 이라고  알려져 있습니다.

일반적으로 중단 상태로 표시된 네이버는 명령을 사용하여 수동으로 neighbor 구성되었습니다. 수동으로 구성된 인접 디바이스는 항상 OSPF 인접 디바이스 테이블에 있습니다. OSPF가 수동으로 구성된 네이버에서 HELLO 패킷을 수신하지 않은 경우 또는 이전 데드 타이머 간격 동안 네이버에서 HELLO 패킷을 수신하지 않은 경우, 수동으로 구성된 네이버가 다운된 것으로 나열됩니다. 

참고: 이 neighbor 명령은 다음 네트워크 유형에서 직접 연결된 인접 디바이스에 대해서만 구성할 수 있습니다.

- NBMA(Non-Broadcast MultiAccess) 네트워크 - 명령으로 구성된ip ospf network non-broadcast인터페이스.
- Non-Broadcast Point-to-Multipoint 네트워크 - 명령으로 구성된ip ospf network point-to-multipoint non-broadcast인터페이스.

인접 디바이스가 down 상태인 경우 인접 라우터가 up 상태이고 활성 상태이며 이 인터페이스에서 OSPF에 대해 올바르게 구성되어 있는지 확인합니다. 및 명령을 사용하여 라우터 간의 ping 연결을 traceroute 테스트합니다. 이 명령을 사용하여 인접 라우터의 OSPF 인접 디바이스 테이블을show ip ospf neighbor확인하고 이 문서의 앞부분에 있는 No State Displayed 섹션에 나열된 것과 동일한 컨피그레이션 확인 작업을 수행합니다.

초기화 상태의 네이버

init 상태는 라우터가 네이버에서 HELLO 패킷을 수신하지만 양방향 통신이 설정되지 않았음을 나타냅니다. Cisco 라우터는 HELLO 패킷의 Neighbor 필드에 init(또는 그 이상) 상태인 모든 네이버의 라우터 ID를 포함합니다. 네이버와 양방향 통신을 설정하려면 라우터가 네이버 HELLO 패킷의 Neighbor 필드에서 고유한 라우터 ID를 수신해야 합니다. 자세한 예와 설명은 Why Does the show ip ospf neighbor Command Revest Neighbors in the Init State(show ip ospf neighbor 명령이 초기화 상태의 인접 디바이스를 표시하는 이유)를 참조하십시오.

양방향 상태의 네이버

2-way 상태는 라우터가 인접 디바이스 HELLO 패킷의 Neighbor 필드에서 고유한 라우터 ID를 수신했음을 나타냅니다. init 상태의 인접 디바이스에서 DBD(Database Descriptor) 패킷을 수신하면 2-way 상태로 전환됩니다. OSPF 네이버 2-way 상태는 브로드캐스트 및 NBMA(Non-Broadcast MultiAccess) 네트워크에서 우려의 원인이 아닙니다. 2-way 상태에 대한 설명은 Why Does the show ip ospf neighbor Command Revest Neighbors Stuck in 2-way State(show ip ospf neighbor 명령이 2-way 상태에서 중단된 인접 디바이스를 표시하는 이유)를 참조하십시오.

Exstart 또는 Exchange 상태의 인접 디바이스

exstart 또는 exchange 상태의 OSPF 인접 디바이스가 DBD 패킷 교환을 시도합니다. 라우터와 해당 인접 디바이스는 기본 및 보조 관계를 형성합니다. 인접성은 이 상태를 지나 계속되어야 합니다. 그렇지 않을 경우 DBD 교환에 MTU(최대 전송 단위) 불일치 또는 예기치 않은 DBD 시퀀스 번호 수신 등의 문제가 발생합니다. 자세한 내용은 Why Are OSPF Neighbors Stuck in Exstart/Exchange State?를 참조하십시오.

Neighbor in Loading 상태

로딩 상태에서 라우터는 링크 상태 요청 패킷을 전송합니다. 인접 라우터에서 오래되거나 누락된 LSA(링크 상태 알림)를 수신하는 경우, 라우터는 LSA를 요청하기 위해 링크 상태 요청 패킷을 전송합니다. 이 상태 이상으로 전환되지 않는 인접 디바이스는 손상된 LSA를 교환할 수 있습니다. 이 문제는 일반적으로 %OSPF-4-BADLSA 콘솔 메시지와 함께 발생합니다. 이 문제는 일반적이지 않으므로 Cisco TAC에 문의하십시오.

OSPF 네이버 문제의 일반적인 이유

이 표에는 OSPF 인접 디바이스가 인접성을 형성하려고 할 때 문제가 발생하는 이유와 문제를 확인하는 데 사용할 수 있는 몇 가지 명령이 나열되어 있습니다.

참고: OSPF 인접성 설정 시 MTU 확인을 방지하려면 인터페이스 컨피그레이션 모드에서ip ospf mtu-ignore명령을 구성할 수 있습니다. 그러나 MTU 확인을 우회하는 대신 인터페이스 컨피그레이션을 검토하여 MTU 불일치를 수정하는 것이 좋습니다.

관련 정보

• PRI, BRI 또는 다이얼러 인터페이스에서 OSPF 폼 인접성이 없는 이유는 무엇입니까?
• show ip ospf neighbor 명령은 무엇을 나타냅니까?
• OSPF over Frame Relay 하위 인터페이스의 초기 컨피그레이션
• 비 브로드캐스트 링크를 통한 OSPF의 초기 컨피그레이션
• Point-to-Point 링크를 통한 OSPF의 초기 컨피그레이션
• 브로드캐스트 미디어를 통한 OSPF의 초기 컨피그레이션
• Cisco 기술 지원 및 다운로드