개념
- 1980년대 중반, RIP의 한계 발생 (대규모의 이질적인 네트워크 사이에서)
- IETF (Internet Engineering Task Force)에서는 SPF 알고리즘에 기반을 하고 인터넷에 적용하기 위해 IP 네트워크용 알고리즘 개발
- RFC 1247 (OSPF 표준)
- RFC 2328에 정의된 OSPFv2가 나오게 됨으로써 현재는 TCP/IP 환경에서 가장 많이 사용하고 있는 라우팅 프로토콜
1) OSPF의 라우팅 계위
- OSPF는 계위(hierarchy) 구조를 취함
2) OSPF의 동작
- 처음 부팅시, HELLO 패킷의 교환을 통해 이웃한 라우터를 서로 인식 (이를 통해, 여러개의 라우터 중에서, 그 네트워크를 대표하여 경로 정보의 생성 및 분배 책임을 지는 지명(Desigated) 라우터를 선정
- OSPF 라우터는 자신의 경로 테이블에 대한 정보를 LSA(Link State Advertisement)를 통해 주기적 또는 라우터의 상태가 변화되었을 때 전송 => LSA를 통해 한 영역에 속한 모든 라우터는 같은 정보를 공유
- ABR은 AS의 백본 네트워크에 연결되어 있으므로, 다른 ABR과 영역에 대한 요약 (Summary) 정보를 주고 받으므로 AS의 토폴로지와 다른 영역에 대한 정보를 획득 => 이를 통해 자신의 영역에 속하지 않은 모든 목적지에 대한 경로를 계산할 수 있음.
3) OSPF의 특성
- 변화의 발생에 관한 정보가 RIP에 비해 신속하게 전파
- Classless IP에 기반한 프로토콜로, 라우팅 정보를 다른 라우터와 교환할 때 서브넷 마스크를 포함한 네트워크 ID를 사용
- 라우팅 정보를 인접한 라우터에 모두 전송하는 플러딩 방식을 사용 => 토폴로지에 관한 정보가 전체 네트워크상의 라우터에서 동일하게 유지
- Link-state 알고리즘으로서 라우터간에 변경된 최소한의 부분만을 교환 => 네트워크 효율 종고 확장성과 대규모 네트워크에 적용 가능 단점으론 프로토콜 자체가 복잡함
* 최단경로 라우팅 알고리즘(Dijkstra's shortest path)
- 각 노드(라우터)의 최단경로를 구하기 위해 전송측 노드에서 각 주변 노드까지의 최단 거리를 확정
-> 보내고자 하는 목적지까지의 확정된 거리(link cost)들을 다시 고려하고 비교하여 최단경로를 구함
[1] 시작 정점에서 가장 인접한 정점을 찾는다. 그 정점까지의 거리가 최단거리이다. 지금까 지 최단거리가 알려진 정점은 2개(자기자신과 지금 찾은 정점)가 된다.
최단거리가 알려진 정점들의 집합을 S라 하자.
[2] 집합 S에 포함되지 않은 정점들 중에서 시작 정점으로 부터 가장 가까운 정점을 찾는다. 이 새로운 정점은 집합 S에 바로 이웃한 정점들 중 하나일 것이다.
그 정점까지의 거리는 최단거리이며, 그 정점을 집합 S에 포함시킨다.
[3] 새로운 정점이 없을 때까지, 즉 모든 정점이 집합 S에 포함될 때까지 [2]의 과정을 반복한다.
예제1)
예제2)
* 라우터 아이디(Router-ID)
- OSPF는 아무래도 대규모 네트워크 환경에서 사용하는 경우가 많기 때문에 라우터들을 손쉽게 구분하기 위한 식별자를 사용하는데, 이를 라우터 아이디라고 함
- 라우터 아이디 선출 방법
1) 물리적인 인터페이스만 있을 경우 그 중에 IP 주소가 가장 큰 숫자
2) Loopback 인터페이스가 있을 경우 Loopback 중에 IP 주소가 가장 큰 숫자
3) 'router-id' 명령어로 지정한 숫자
- 라우터 아이디는 관리상 쉬운 숫자로 하는 것을 권장하며, 가장 주의해야할 점은 인접 라우터와 중복되면 네이버 관계를 성립할 수 없음
* OSPF의 설정
- OSPF는 프로세스 아이디를 할당하여 설정
(프로세스 아이디 : 라우터에 서로 다른 OSPF 프로세스를 구성하기 위한 번호이며, EIGRP처럼 AS주소가 아니므로 인접 라우터와 동일하지 않아도 네이버 성립)
* Loopback /32bit 라우팅 업데이트
- OSPF는 Loopback을 'a stub host'로 간주하여, IP 1개짜리 서브넷으로 처리하기 때문에 라우팅 업데이트시 서브넷 마스크를 /32로 업데이트함
=> Loopback 정보를 원래 서브넷 마스크로 라우팅 업데이트를 하기 위해서는 Loopback OSPF 네트워크 타입을 Point-to-Point로 변경하면 됨
* OSPF의 동작과정
- OSPF는 인접 라우터와 네이버를 성립
- 성립한 이후, Link-state를 관리하는 LSDB(Link State Database)정보를 네이버 라우터와 비교
- 동일한 상태를 유지하기 위해서 Link-state 업데이트 요청과 실시를 통해 LSDB 동기화를 시작
- LSDB 동기화가 시작되면, 자신의 LSDB 정보를 기반으로 SPF 알고리즘을 이용하여 최적 경로를 선출하고 라우팅 테이블에 등록
- 변화가 있을 때만 LSA(Link State Advertisement) 광고를 실시하여 Link-state 변화를 광고
(변화가 없어도, 30분에 한번씩 OSPF Area 지역으로 광고함 <= 이러한 동작을 하기 위해서는 인접 라우터와 주기적으로 Hello 패킷을 교환하여 네이버 관계를 유지)
네이버 관계를 맺는 과정 ( Down State => Init State => Two-Way State)
1) Down State
- OSPF 프로세스가 시작되어, 인접 라우터에게 Hello 패킷을 전송하지만, 아직 인접 라우터로부터 Hello 패킷을 수신하지 못한 상태
- 또는 네이버 관계가 성립된 상태에서 Dead 타이머 안에 Hello 패킷을 수신하지 못할 경우
[ Down State] "안녕하세요. 저는 13.13.1.1 입니다."
=====> Hello
[ R1 ] ----------------------------------------------- [ R3 ]
Router ID <===== X Router ID
13.13.1.1 13.13.3.3
※ Attempt State
- Non-broadcast 환경에서만 적용되는 모드
- Neighbor 명령어를 이용하여 유니캐스트로 Hello 패킷을 전송한 다음, 아직 인접 라우터로부터 Hello 패킷을 수신하지 못한 상태
2) Init State
- 네이버 라우터로부터 Hello 패킷을 수신하였으나, 자신이 전송한 Hello 패킷은 아직 네이버 라우터가 수신하지 못한 상태
(네이버 라우터로부터 수신한 Hello 패킷 네이버 항목에 자신의 라우터 아이디가 없으므로 자신이 전송한 Hello 패킷을 수신하지 못한걸로 간주)
[ Init State ] "안녕하세요. 저는 13.13.1.1 입니다."
=====> Hello (아마도 안간 듯?)
[ R1 ] ----------------------------------------------- [ R3 ]
Router ID <===== Hello (OK) Router ID
13.13.1.1 but 네이버 항목에 13.13.3.3
자신(R1)의 라우터 ID가 없음
(그래서 자신이 전송한 Hello 패킷을 수신하지 못한걸로 간주)
3) Two Way State
- 네이버 라우터와 정상적으로 Hello 패킷 교환이 완료된 양방향 통신 상태
(네이버로부터 자신의 라우터 아이디가 네이버 항목에 설정된 Hello 패킷을 수신)
- Broadcat, Nonbroadcast 환경에서는 Two-Way 상태일 때 Waiting 타이머 동안 DR/BDR 선출과정을 실시
+ DR : LSA 광고를 실시하는 대표 라우터
+ BDR : 백업 DR
+ DROTHER : DR과 BDR이 아닌 나머지
(오직 DR, BDR하고만 네이버 관계를 맺고, DROTHER끼리는 Two-Way 상태까지만 진행하고 대기)
[ Two Way State ] "안녕하세요. 저는 13.13.1.1 입니다."
=====> Hello
[ R1 ] ----------------------------------------------- [ R3 ]
Router ID <===== Hello (OK) Router ID
13.13.1.1 "안녕하세요. 저는 13.13.3.3 입니다." 13.13.3.3
DROTHER는 DROTHER들 끼리 여기까지만 진행하고 대기
'CS > 네트워크' 카테고리의 다른 글
| RIP 라우팅 프로토콜 (0) | 2024.10.13 |
|---|---|
| RIP와 OSPF (2) | 2024.10.10 |
| 라우팅 Routing (0) | 2024.10.02 |
| 라우팅 알고리즘 - 벨만포드 (Bellman-Ford), 다익스트라 (Dijkstra) (2) | 2024.10.02 |
| 네트워크 모델 - OSI 참조 모델 (0) | 2024.09.30 |