1. OSPF 개요 - 01

OSPF를 쓰는 이유

- 다양한 기능이 있음

- Area로 인해 상세 라우팅이 다른 Area로 전달되지 않아 안정성이 있다.

- Stub Area라는 축약기능을 통해 라우팅 테이블을 최소화 할 수 있다.
  물론, Summary 기능도 있으나 Stub은 연속되지 않은 라우팅을 축약할 수 있다. (Default-Origin)

- 표준 라우팅 프로토콜임

 

---

OSPF의 Neighbor

- ospf는 neighbor와 adjacent neighbor 두 종류가 있음

- adjacent는 '인접한' 이라는 뜻이지만, 라우팅 정보를 교환하는 neighbor를 뜻함

- 그 라우팅 정보는 LSA(Link Statement Advertisement)라고 불림. 

  그래서 라우팅을 광고(Advertisement)한다 라고 표현함

- LSA를 교환하고 이 정보를 토대로 SPF(Short Path First) or Dijkstra 알고리즘을 이용하여 최적 경로를 계산함

- 계산 된 최적경로는 다른 라우팅 프로토콜과 경합하여 라우팅 테이블에 인스톨

 

---

기본 설정법

router ospf [Process Num] router-id [ip address] network [ip address] [wildmask] [area num]  **논브로드캐스트를 위한 neighbor 설정은 제외한다

router ospf [Process Num]

- 스위치 혹은 라우터 내에서 여러개의 ospf를 구분하기 위함.

- 보통 1개만 사용함

 

router-id [ip address]

- OSPF 도메인 내에서 식별자 역할을 함

- 보통 라우터 ID는 루프백으로 설정함.

   OSPF는 라우팅 정보를 보낸 라우터와 이 정보를 생성한 라우터 정보도 같이 보내기에 변동되지 않는 주소를 사용함

 

- 라우터ID를 설정하지 않으면 루프백 IP를 자동으로 라우터ID로 설정함

- 또 루프백 IP가 없는 경우, 해당 장비의 OSPF가 활성화된 인터페이스 중 가장 높은 IP를 자동으로 라우터ID로 잡는다. 

  (ex. 192.168.1.1/24, 192.168.2.1/24 중 192.168.2.1/24가 라우터ID가 된다)

- 물론 루프백 IP가 여러개 있는 경우라면 이 또한 가장 높은 IP를 자동으로 잡게 된다

- 정리하면 라우터 ID 수동 설정 > 루프백 IP(가장 높은 IP) > OSPF 활성 인터페이스 IP (가장 높은 IP)

- 라우팅 ID를 재설정 하기 위해선 프로세스 클리어가 필요하다 ( clear ip ospf process )

 

network [ip address] [wildmask] [area num] 

- OSPF에 포함시킬 대역을 설정함 (광고할 대역)

- 간혹 오해하는 경우가 있는데, 인터페이스에 ip router ospf 1 area 0 과 같이 입력하는 것은 이 인터페이스에 설정된 IP를 광고하겠다는 의미가 아님. 해당 인터페이스에 OSPF를 활성화 하고 Hello 및 LSA 송신을 하겠다는 의미

- 물론 redistribute를 통해서도 ospf에 특정 라우팅을 포함시킬 수 있다

 

switch(config)# router ospf 1
switch(config-router)# router-id 10.0.0.1
switch(config-router)# capability opaque-lsa
switch(config-router)# network 10.0.0.0/24 area 0
switch(config-router)# exit
switch(config)# interface vlan 10
switch(config-if)# ip address 10.0.0.1/24
switch(config-if)# ip router ospf 1 area 0

---

OSPF의 패킷 종류

Hello

- OSPF 네이버 형성을 위한 패킷. 헬로 패킷 송/수신 하여 네이버를 맺고 유지시킨다. 특정 시간동안 헬로 패킷을 받지 못한 경우 네이버는 끊김

- Router ID, Area Num, Autentication, Subnet,  Hello/Dead Timer, Stub Area Flag, Router Priority(P to P에선 안씀), DR, BDR, Neighbor List 가 포함됨.

** 빨간색이 필수. 일치하지 않으면 네이버 성립이 되지 않음

- Authentication는 인증에 대한 내용으로 암호화 알고리즘(ex. MD5)과 패스워드는 동일해야함. 

  (개 당연한 얘기임. 단방향 암호화 방식인 MD5로 암호화한 값을 서로 비교하는건데 알고리즘 다르면 ㅈㅈ쳐야함)

 

DDP (Database Description Packet)

- LSA를 생성/수신한 내용을 데이터베이스에 저장(Link State Database)

- 자신이 가지고 있는 DB 디스크립션(DDP) 정보를 보내 변동사항만 업뎃받음

 

LSR ( Link State Request )

- 상대의 DDP를 받고 나한테 없는 정보면 달라고 구걸하기 위한 패킷

 

LSU ( Link State Update)

- LSR을 받았거나 토폴로지 변화가 발생했을때 업뎃치기 위한 용도

- LSA를 나르는 역할을 

 

LS ACK ( Link State ACKnowledgment )

- Link State Advertise와 약자가 같아서 불쌍하게 LS ACK라고 불리운다.

- 위의 메시지들을 받고 응 잘 받았어 라고 대답하기 위한 메시지

 

---

OSPF Neighbor 수립 과정

- Hello 패킷을 보내고 받음. 받은 Hello Packet 내에 Neighbor List에 내 Router ID가 있는지 확인

- 있으면 Neighbor로 간주함

- Show ip ospf neighbor 로 확인가능

- 최초 구성시에는 Hello 패킷에 자신의 라우터 ID만 기입되어 있음. 멀티캐스트 224.0.0.5를 OSPF가 활성화된 인터페이스로 보내게 되고, 이 메시지를 수신받은 인접 라우터는 그 라우터ID를 자신의 Neighbor List에 추가함

** 논브로드 캐스트 네트워크는 유니캐스트

---

DR/BDR

- Point to Point에서는 사용하지 않는 개념

- Multi Access 환경(ex. Broadcast)에서 모든 OSPF 라우터들이 서로에게 LSA 날리고 ACK 날리다보면 대환장 파티가 열리게 됨

- 그래서 이 메시지들을 중개해줄 대가리(DR 라우터)가 필요함

- DROTHER는 변경점이 생기면 DR에게 LSA를 보냄(224.0.0.6), DR은 LSA를 DROTHER들에게 보냄 (224.0.0.5) 

- DR이 변경점이 생기면 그대로 224.0.0.5로 LSA를 보냄.

- 결국 DROTHER는 224.0.0.5만 받고, DR/BDR은 224.0.0.5, 224.0.0.6 둘다 받음

- DROTHER끼리는 Neighbor이나 Adjacent Neighbor는 아니다

- show ip ospf neighbor 명령어에는 Adjacent Neighbor(DR/BDR)과 Neighbor(DROTHER)가 모두 포함된다

  (물론, P to P에서는 DR/BDR을 선출하지 않고 인접한 라우터간에 LSA를 교환하므로 Adjacent Neighbor이다)

 

 

 

DR/BDR 선출

- 인터페이스의 우선순가 가장 높은 라우터가 DR이 됨(0-255)

- 우선순위 0은 선출에서 제외됨

- ip ospf priority 0 과 같이 설정 가능

- 우선순위가 동일(Default 1)하면 라우터 ID가 가장 짱짱한 놈이 DR이 됨. 그 다음이 BDR이 됨. 나머진 DROTHER.

- DR 선출과정은 Wait Time 40초(Dead Time 동일) 동안 진행됨. 이후에 ospf 설정한 친구는 아쉽게도 대빵이 되지 못함

  (읔가 독수리 타법으론 불가능 ㅠ)

- 루프백으로 라우터 ID를 설정을 하게 될텐데, 최초 설계 과정에서 루프백 IP를 잘 설계 해야함

- 나중에 우선순위를 조정하면 Process를 Clear 를 해줘야함. 그래야함. (ex. Clear ip ospf process 1)

 

---

OSPF 네이버 상태변화

down 

- hello packet을 보냈으나 나는 못받은 상태

- full 상태에서도 데드타임(p to p/broad 40초)간 헬로 못받으면 down으로 변경됨

 

init

- 반대로 나는 hello packet을 받았는데, 상대가 내 hello packet을 못받은 상태

- 수신 받은 hello packet의 Neighbor List 중 내 라우터 id가 없는 경우임

 

two-way 

- 서로 hello packet을 받았으며, Neighbor List에 내 라우터 id가 있는 경우

- 이 단계에서 DR/BDR 선출이 이뤄짐 (모두 hello를 받았기에)

- 데드주기와 동일한 wait time이 진행되고 이때가 레알 춘추전국시대임

- 이 과정에서 시간을 오래 잡아먹지 않으려면 p to p나 p to multi p가 정신건강에 이로움

- DROTHER는 two-way에서 멈추게 됨. DR/BDR 선출이 끝나면 exstart로 넘어가는듯함 (feat. ChatGPT)

 

exstart

- DR/BDR로 선출된 라우터들은 exstart로 상태가 변경됨

- 물론 point to point의 라우터들도 exstart로 변경됨

- 이 과정에서 헷갈리는 내용이 master/slave 선출 및 DDP 시퀀스 번호 결정단계라는 점임

- master/slave는 앞서 선출한 DR/BDR과는 개념이 다름

- Router ID가 높은 라우터가 Master 나머지가 slave가 되어, Master가 Slave에게 DDP를 전달하고 Slave는 LSU를 보냄

- 브로드캐스트라서 더 헷갈릴텐데 Point to Point도 Router ID에 따라서 한쪽이 Master 한쪽이 Slave가 된다

- DDP 시퀀스 넘버는 DDP의 버전이라고 생각하면 되며 해당 패킷이 교환되면 버전은 증가(Default 1)

 

exchange

- DDP 패킷 전송이 이뤄지는 단계

- DDP 패킷 내용과 DB의 내용이 상이할 경우 LSR을 보내기 위해 기록함

- 상이 하지 않는다면 바로 full로 감

 

loading

- 리스트를 토대로 LSR을 보냄.

- LSR을 받은 DR/BDR 혹은 Point to Point Peer 라우터는 LSU에 LSA 정보를 담아서 보냄

 

full

- 정보교환이 완료되어 모든 adjacent neighbor간 DB가 일치되는 감격스러운 순간 

 

모든 상태변화는 순서대로 일어나진 않는다.

그래도 약간의 순서는 있다

다시 말하지만 네트워크 타입에 따라서, 상황에 따라서 꼭 이 순서로 진행되진 않는다.

 

down > init > two-way > exstart > exchange > loading > full

---

논브로드캐스트에 대한 상태변화

논브로드는 neighbor를 직접 설정하므로 2-way 단계가 없다고 한다.

논브로드를 해본적이 없어서 모르겠다. 앞으로도 해볼 수 있을지 모르겠다

 

아 참고로 논브로드 캐스트는 x.25, Frame Relay, ATM 등으로 특정 회사에서는 경험할 수 있겠지만, 

일반적인 회사에서는 Ethernet을 사용하므로 경험하긴 어려울 것 같다

 

attemp

- 논브로드에서 neighbor로 설정한 네이버에게 헬로 못받은 상태

- 네이버와 연결 끊긴 상태에서도 attemp로 떨어짐

 

attemp > init > exstart > exchange > loading > full

---