[OSPF] OSPF 동작방식, Neighbor 수립 과정

Network/OSPF

[OSPF] OSPF 동작방식, Neighbor 수립 과정

chan10 2025. 4. 13. 21:24

OSPF Neighbor 종류

OSPF Neighbor
OSPF 네이버(Neighbor)는 서로 OSPF Hello 패킷을 주고받아 존재를 인식한 라우터를 의미합니다.
Neighbor가 되려면 OSPF 네이버 성립 조건(Area ID, Hello Timer 등)이 일치해야 합니다
OSPF Adjacency
OSPF Adjacency(인접 관계)는 Neighbor 중에서 LSDB를 동기화하여 라우팅 정보를 공유할 수 있는 관계입니다.
ExStart → Exchange → Loading → Full 단계를 거쳐 LSDB가 완전히 동기화된 상태입니다.
네트워크 내의 모든 OSPF 라우터가 Neighbor가 될 수 있지만, 라우팅 정보를 공유하는 관계(Adjacency)는 아닐 수 있습니다.
Adjacency 상태가 되는 경우
- Point-to-Point(P2P) 링크에서는 모든 Neighbor가 Adjacency가 됩니다.
- Broadcast 네트워크에서는 DR(Designated Router) 및 BDR(Backup DR)과만 Adjacency가 형성됩니다.

즉, OSPF Neighbor는 기본적인 이웃 관계지만, OSPF Adjacency는 라우팅 정보를 실제로 교환하는 관계입니다.

OSPF 네이버 성립 조건

OSPF 네이버 관계가 형성되려면 아래 조건이 모두 일치해야 합니다.

조건	설명
Router ID 중복 없음	OSPF Area 내에서 동작하는 라우터는 서로 Router ID가 서로 달라야 합니다. (중복된 Router ID가 있을 경우 LSDB가 계속 업데이트 되어 Routing Table이 계속 변경 됩니다.)
Area ID 및 Area Type 일치	OSPF 네이버는 같은 Area ID 및 Area Type(Stub or NSSA)이 동일해야 합니다.
서브넷(Subnet) 일치	두 장비 인터페이스의 IP Subnet이 동일해야 합니다.
MTU Size 일치	OSPF는 단편화를 지원하지 않기에 MTU 사이즈가 동일해야 합니다.
Hello 및 Dead Timer 일치	Hello Interval과 Dead Interval 값이 일치해야 합니다.
네트워크 타입(Network Type) 호환	OSPF 네트워크 유형(Broadcast, Non-Broadcast, Point-to-Point 등)이 맞아야 합니다. (DR /BDR 활성화/비활성화 조건 일치)
Authentication(인증) 설정 일치 (선택적)	OSPF 인증을 사용할 경우, 같은 인증 방식과 비밀번호를 사용해야 합니다.

OSPF 네이버 관계 형성 과정

OSPF 네이버 관계는 여러 상태를 거쳐 형성됩니다. Adjacency Neighbor (DR/BDR)일 경우와 일반적인 OSPF Neighbor(DROTHER)는 서로 다른 단계를 통해 수립됩니다.

상태	설명
Down	- OSPF Hello 패킷을 인접 라우터에게 전송하나 응답 패킷을 수신하지 못한 상태 - 인접 라우터에게 Dead Interval 시간(기본적으로 Dead Interval = 4*Hello Interval) 내에 hello 패킷을 수신하지 못했거나 - 수동으로 구성된 neighbor가 컨피그레이션에서 제거되는 즉시 Full에서 Down 상태로 변경 됨
Attempt	- NBMA(Non Broadcast Multi Access) 네트워크에서만 발생 - OSPF neighbor를 수동으로 지정하여 Hello 패킷을 특정 대상에게 전송 - Hello에 대한 응답 패킷을 상대방으로 부터 수신하지 못한 상태
Init	- 상대 라우터에게 Hello 패킷을 수신한 상태 - 상대 라우터의 Hello 패킷을 받았지만, 본인의 Router ID가 포함되지 않음 (일방적인 인식) - 라우터가 인접 디바이스로부터 hello 패킷을 수신할 경우 유효한 hello 패킷을 수신했음을 알리기 위해 해당 hello 패킷에 발신자 라우터 ID를 나열해야 합니다.
2-Way	- 상대 Hello 패킷에 본인의 Router ID가 포함되며 서로 Neighbor 관계를 인식한 상태 (양방향 인식 완료) - Multi-access 네트워크(Broadcast/NBMA)에서는 DR/BDR 선출이 진행됨 - DROTHER일 경우 해당 상태가 최종 단계
ExStart	- DR/BDR이 있는 환경에서는 선출 과정 진행, LSDB 동기화를 위해 Master/Slave 결정 - DBD(Database Description) 패킷을 교환할 준비
Exchange	- DBD 패킷을 주고받아 LSDB에 있는 LSA 목록을 요약하여 공유 - OSPF는 Sequence Number 정보를 이용하여 해당 정보의 최신화 여부 확인
Loading	- 없는 LSA에 대해 LSR(Link State Request)을 neighbor에게 보냄 - 최신 LSU(Link State Update) 패킷 응답을 통해 LSDB 동기화
Full	- OSPF Adjacency neighbor 관계 형성이 완료된 상태 - 모든 라우터와 네트워크 LSA가 교환되며 라우터의 LSDB가 완전히 동기화 된 상태

OSPF Neighbor(DROTHER) : 2-Way(양방향 인식)상태에서 네이버 관계가 형성됩니다.

Adjacency Neighbor (DR/BDR) : DR/BDR 선출 뒤 LSDB 동기화 후 라우팅 정보를 완전히 공유하고 Full 상태에서 정상적인 네이버 관계가 형성됩니다.

[R3]
R3#show ip ospf neighbor
Neighbor ID    Pri      State        Dead Time Address        Interface   Area
1.1.1.1         1       FULL/BDR     00:00:34  10.10.13.1     Vl 13       0
2.2.2.2         1       FULL/DROTHER 00:00:34  10.10.24.2     Vl 24       0
4.4.4.4         1       FULL/DR      00:00:34  10.10.24.4     Vl 24       0

[R4]
R4#show ip ospf neighbor
Neighbor ID    Pri      State        Dead Time Address        Interface   Area
2.2.2.2         1       FULL/DROTHER 00:00:34  10.10.24.2     Vl 24       0
3.3.3.3         1       FULL/BDR     00:00:34  10.10.24.3     Vl 24       0

DROTHER 라우터가 여러개인 경우 아래와 같이 2WAY 상태에서 유지됩니다.

OSPF 패킷 교환 과정

OSPF 네이버가 형성되고 LSDB가 동기화되는 과정에서 패킷들이 사용되는 흐름

Hello 패킷 전송하여 OSPF 네이버 관계를 형성합니다.
DBD 패킷 교환하여 서로의 LSDB 상태를 비교합니다.
LSDB 상태 비교 후 LSR 패킷을 보내 부족한 LSA 요청합니다.
LSU 패킷을 통해 요청받은 LSA 정보를 전달합니다.
LSAck 패킷을 보내 수신을 확인합니다.

[참고사이트]

https://white-polarbear.tistory.com/30

https://www.cisco.com/c/ko_kr/support/docs/ip/open-shortest-path-first-ospf/13685-13.html

저작자표시 (새창열림)