OSPF 네이버 상태 이해

소개

이 문서에서는 라우터가 인접 디바이스와 완전히 인접해지기 전에 OSPF 인접성이 몇 가지 상태 변경을 거치는 경우를 설명합니다. 

사전 요구 사항

요구 사항

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

사용되는 구성 요소

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

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

표기 규칙

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

배경 정보

OSPF 인접성이 형성되면 라우터가 네이버와 완전히 인접하기 전에 여러 상태 변경을 거치게 됩니다. 이러한 상태는 OSPF RFC 2328, 섹션 10.1에 정의되어 있습니다. 상태는 Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading 및 Full입니다. 이 문서에서는 각 상태에 대해 자세히 설명합니다.

OSPF 인접성

아래로

첫 번째 OSPF 네이버 상태입니다. 즉, 이 네이버에서 어떤 정보(hello)도 수신되지 않았지만, 이 상태에서도 hello 패킷을 네이버로 전송할 수 있습니다.

완전히 인접한 인접 디바이스 상태에서 라우터가 RouterDeadInterval 시간(기본적으로 RouterDeadInterval = 4*HelloInterval) 내에 인접 디바이스로부터 hello 패킷을 수신하지 않거나 수동으로 구성된 인접 디바이스가 컨피그레이션에서 제거되면 인접 디바이스 상태가 Full에서 Down으로 변경됩니다.

시도

이 상태는 NBMA 환경에서 수동으로 구성된 네이버에만 유효합니다. 시도 상태에서 라우터는 폴링 간격마다 인접 디바이스로 유니캐스트 hello 패킷을 전송합니다. 이 인접 디바이스로부터 데드 간격 내에 Hello가 수신되지 않았습니다.

초기화

이 상태는 라우터가 인접 디바이스로부터 hello 패킷을 수신했지만, 수신 라우터 ID가 hello 패킷에 포함되지 않았음을 나타냅니다. 라우터가 인접 디바이스로부터 hello 패킷을 수신할 경우 유효한 hello 패킷을 수신했음을 알리기 위해 해당 hello 패킷에 발신자 라우터 ID를 나열해야 합니다.

2방향

이 상태는 두 라우터 간에 양방향 통신이 설정되었음을 나타냅니다. 양방향이란 각 라우터에 다른 라우터의 hello 패킷이 표시됨을 의미합니다. 이 상태는 hello 패킷을 수신하는 라우터가 received hello packet neighbor(수신된 hello 패킷 인접 디바이스) 필드 내에서 자체 라우터 ID를 볼 때 구현됩니다. 이 상태에서 라우터는 이 네이버와 인접할 것인지 여부를 결정합니다. 브로드캐스트 미디어 및 비 브로드캐스트 다중 액세스 네트워크에서 라우터는 전용 라우터(DR) 및 백업 전용 라우터(BDR)로만 가득 차서 다른 모든 네이버와 양방향 상태를 유지합니다. Point-to-Point 및 Point-to-Multipoint 네트워크에서 라우터는 연결된 모든 라우터로 가득 차게 됩니다.

이 단계가 끝나면 브로드캐스트 및 비 브로드캐스트 다중 액세스 네트워크에 대한 DR 및 BDR이 선택됩니다. DR 선택 프로세스에 대한 자세한 내용은 DR 선택을 참조하십시오.

참고: init 상태의 인접 디바이스에서 DBD(Database Descriptor) 패킷을 수신하면 양방향 상태로 전환될 수도 있습니다.

Exstart(시작)

DR 및 BDR이 선택되면 라우터와 해당 DR 및 BDR 간에 교환 링크 상태 정보의 실제 프로세스가 시작될 수 있습니다.

이 상태에서 라우터와 해당 DR 및 BDR은 기본-보조 관계를 설정하고 인접성 형성을 위한 초기 시퀀스 번호를 선택합니다. 라우터 ID가 더 높은 라우터가 기본 라우터가 되어 교환을 시작합니다. 따라서 순차 번호를 늘릴 수 있는 유일한 라우터입니다. 논리적으로 가장 높은 라우터 ID를 가진 DR/BDR이 이 프로세스의 기본 ID라고 결론을 내릴 수 있습니다. DR/BDR 선택은 가장 높은 라우터 ID가 아니라 라우터에 더 높은 우선순위가 구성되어 있기 때문일 수 있습니다. 따라서 DR이 보조 역할을 할 수 있습니다. 또한, 1차/2차 선거는 인접 디바이스 단위로 이루어집니다.

교환

교환 상태에서 OSPF 라우터는 DBD(Database Descriptor) 패킷을 교환합니다. 데이터베이스 설명자는 LSA(링크 상태 알림) 헤더만 포함하고 전체 링크 상태 데이터베이스의 내용을 설명합니다. 각 DBD 패킷에는 보조 패킷에 의해 명시적으로 확인되는 기본 패킷에 의해서만 증가할 수 있는 시퀀스 번호가 있습니다. 라우터는 또한 이 상태의 링크 상태 요청 패킷과 링크 상태 업데이트 패킷(전체 LSA를 포함)을 전송합니다. 수신된 DBD의 내용을 라우터 링크 상태 데이터베이스에 포함된 정보와 비교하여 인접 디바이스에서 새로운 또는 그 이상의 현재 링크 상태 정보를 사용할 수 있는지 확인합니다.

로드 중

이 상태에서 링크 상태 정보의 실제 교환이 발생한다. DBD에서 제공하는 정보를 기반으로 라우터는 링크 상태 요청 패킷을 전송합니다. 그런 다음 인접 디바이스는 요청된 링크 상태 정보를 링크 상태 업데이트 패킷에 제공합니다. 인접해 있는 동안 라우터가 오래되거나 손실된 LSA를 수신하는 경우 해당 LSA에 대한 링크 상태 요청 패킷을 전송합니다. 모든 링크 상태 업데이트 패킷이 승인됩니다.

전체

이 상태에서 라우터는 완전히 서로 인접해 있습니다. 모든 라우터와 네트워크 LSA가 교환되며 라우터의 데이터베이스가 완전히 동기화됩니다.

Full은 OSPF 라우터의 일반 상태입니다. 라우터가 다른 상태에서 중단될 경우 인접성이 형성될 때 문제가 있음을 나타냅니다. 이에 대한 유일한 예외는 2방향 상태이며, 이는 방송망에서는 정상이다. 라우터는 NBMA/브로드캐스트 미디어에서 DR 및 BDR로 FULL 상태를 구현하고, 포인트-투-포인트 및 포인트-투-멀티포인트와 같은 잔여 미디어에서 모든 네이버로 FULL 상태를 구현합니다.

참고: 세그먼트의 모든 라우터에서 FULL 상태를 달성하는 DR 및 BDR은 DR 또는 BDR에서 명령을 입력할 때 FULL/DROTHER show ip ospf neighbor 를 표시할 수 있습니다. 즉, 인접 디바이스가 DR 또는 BDR이 아니지만 명령을 입력한 라우터가 DR 또는 BDR이므로 인접 디바이스가 FULL/DROTHER로 표시됩니다

관련 정보

• OSPF 네이버 문제 설명
• show ip ospf neighbor 명령이 초기화 상태의 인접 디바이스를 표시하는 이유는 무엇입니까?
• show ip ospf neighbor 명령은 양방향 상태에서 중단된 네이버를 표시하는 이유는 무엇입니까?
• OSPF Neighbors가 Exstart/Exchange 상태에 머물러 있는 이유는 무엇입니까?
• OSPF 문제 해결
• OSPF 지원 페이지
• Cisco 기술 지원 및 다운로드