OSPF Code O (동적 라우팅)

다음과 같은 네트워크 구성에 OSPF를 적용해 보겠다.

 

OSPF는 적용 방식이 2가지이다. R1과 R2에 각각 다르게 적용해 보겠다.

 

R1의 명령어는 다음과 같다.

 

다음은 명령어에 대한 설명이다.

 

번호	커맨드	설명
①	router ospf [Process-ID]	OSPF의 프로세스 값을 입력한다. (제일 아래쪽 설명 있음)
②	router-id [IP address format]	라우터의 ID 값을 입력한다. (제일 아래쪽 설명 있음) 생략이 가능하다.
③, ④	network [IP address] [wildcardmask] area [area number]	광고할 라우터에 연결된 정보를 입력하는 명령어이다. OSPF는 Classless routing이기 때문에, 클래스의 네트워크 주소를 모두 입력하여야 한다. OSPF는 Subnetmask 대신 Wildcardmask를 사용한다. 해당 주소의 prefix는 /24이기 때문에 0.0.0.255를 입력한다. area 명령 뒤에 영역 번호를 입력한다.

 

R2의 명령어는 다음과 같다. R2에는 R1과 다른 방식으로 명령어를 입력하였다.

 

R1의 명령어에서 1번과 2번을 보면, Wildcard mask의 자리에 원래 IP 주소의 prefix와 일치하는 "0.0.0.255" 대신에 "0.0.0.0" 입력한 것을 알 수 있다. Wildcard mask에서는 0은 해당 자리를 검사하는 명령어이기 때문에, 0.0.0.0은 모든 자리를 일치하는지 검사하는 의미로 입력한 하나의 IP 주소만 통신할 수 있도록 하는 것이다. 그러나 R2는 원래 연결되어 있는 대역대의 모든 주소와 통신이 가능하다. 이 이유는 Wildcard mask를 위와 같이 입력하여도 기존 라우터에 IP 주소를 넣어줄 때, 서브넷 마스크와 함께 주소를 입력하였기 때문에, 라우터는 해당 주소의 정보를 이미 알고 있어 통신이 가능한 것이다. R1 라우터에 입력한 방식같이 Wildcard mask를 직접적으로 입력하면 실수가 발생할 확률이 높다. 그러나 이 방식을 사용하면 라우터가 알아서 인식하기 때문에 실수를 줄일 수가 있어 이 방식으로 사용하는 것이 더 좋을 수 있다. (수천만 원에 라우터가 비싼 값을 하는 이유인가 보다.)

 

양쪽 명령어를 입력하면 로딩이 완료되었다는 의미로, 다음과 같은 정보가 자동으로 나타난다.

 

해당 명령어들을 입력한 이후 라우팅 테이블을 확인하면 다음과 같다. (R1에서의 정보만 확인하겠다.)

 

붉은색 밑줄 친 부분에 대한 정보는 다음과 같다.

 

정보	의미
O	코드명은 "O"이며, ①번 표시인 OSPF를 나타내고 있다.
192.168.20.0/24	192.168.20.0 대역대의 정보를 수신하고 있음을 나타낸다.
[100/65]	OSPF 프로토콜은 관리자 거리 값(AD 값)이 110이다. OSPF에서 Metric 값은 Bandwith(대역폭)을 이용하여 산출하는 "Cost" 값이다.
via 1.1.1.2	어디에서 넘어온 정보인지 나타내는 것으로 1.1.1.2 라우터에서 온 것임을 확인할 수 있다.

 

OSPF에서 라우터에서 광고를 서로 주고받을 수 있는, 연결된 이웃 라우터의 정보를 확인하는 명령어는 "show ip ospf neighbor" 명령어이다.

 

Router-id가 1.1.2.2인 R2 라우가 연결되어 있는 것을 확인 가능하다.

 

마지막으로 Debug 정보를 확인하며 다음과 같다.

 

RIP와 같이 느리게 정보가 나타나지 않고 금방 정보가 나타난다. 그리고 붉은색 밑줄을 보면 224.0.0.5로 Multicast 통신을 하는 것을 알 수 있다.

---

Process-ID

라우터는 굉장히 고가의 장비이기 때문에 여러 회사에서 한 라우터를 함께 구입하여 공동으로 사용할 경우가 발생할 경우가 있다. 한 라우터는 여러 개의 OSPF 프로세스를 운용할 수 있는데, 이는 여러 개의 OSPF 데이터 베이스를 사용한다는 것이다. 쉽게 말해서, 한 개의 라우터를 마치 여러 대의 라우터 기기처럼 나눠서 쓸 수 있다는 것이다. (물리적으로 1대이나 논리적으로 여러 대 사용하는 것) 따라서 분리해서 사용할 때, 각각 사용하는 OSPF를 서로 구분하여 사용 가능하도록 만들어주는 ID가 "Process-ID"이다.

 

예를 들어, A 회사는 라우터의 OSPF 홀수 번호만 사용하고, B 회사는 OSPF 짝수 번호만 사용하도록 약속하여 서로 한대의 라우터를 분리하여 사용할 수 있을 것이다.

 

OSFP의 프로세스 ID는 내부 ID이다. 외부에서 이 정보는 광고가 되는 정보가 아니며, 내부에서 안쪽에 있는 OSPF를 서로 식별하도록 할 때 사용하는 것이다. 따라서 다른 라우터에서 OSPF의 프로세스 ID를 동일하게 사용하여도 광고되는 것이 아니기 때문에 충돌 등과 같은 문제는 발생하지 않는다. 프로세스 ID는 운용상의 편리성을 위해 서로 동일하게 사용하는 것이 좋다.

 

router ospf process-ID가 가질 수 있는 수의 범위는 다음과 같다.

 

즉 라우터 1대를 65535대까지 나누어 사용 가능하다는 것이다. (물론 라우터의 트래픽 과부하 때문에 저 정도로 많이 나누어 사용하는 것을 불가능하다.)

---

Router-ID

그러나 Process-ID와 달리 router-id는 다른 라우터에게 광고가 되는 정보로 통신하는 양쪽의 router-id가 동일할 경우 충돌이 발생한다. 이것은 라우터 자체를 나타내는 라우터의 "이름"이다.

 

router-id는 입력하지 않을 경우 자동으로 선출된다. 이 때 자동으로 선출되는 기준은 다음과 같다.

 

수동 입력 → Loopback IP → 실제 IP

선출 순서

 

기존 Loopback IP는 자기 자신을 의미하는 IP 주소였다. 그러나 여기에서 Loopback ID는 조금 다른 의미로 가상 대역대를 뜻하며, 테스트 용으로 사용하는 IP이다. 원래 IP를 부여하기 위해서는 컴퓨터 게이트웨이 등이 필요하다. 그러나 Loopback IP를 사용할 경우, 이런 것들이 필요 없이 생성 가능하여 테스트할 수 있도록 만들어 준다.

 

Loopback IP와 실제 IP에서 router-id는 등록된 것 중 클래스가 높은 순으로 IP 주소를 선출한다. (C → B → A 클래스 순)

 

router-id가 선출되는 것을 확인해 보겠다. 다음과 같은 OSPF로 연결된 네트워크 구성이 존재한다. (모든 라우터는 Area 0 영역 안에 있는 네트워크이다.)

 

 

---

실제 IP 선출

라우터 R1, R2, R3에 다음과 같이 명령을 입력하였다.

 

R1
R2
R3

 

위의 명령어에서는 router-id는 입력하지 않았다. router-id를 확인하는 명령어는 "show ip ospf"이다.

R1의 router-id는 다음과 같이 선출되었다.

 

현재 Loopback IP 및 직접적인 IP를 설정하지 않았기 때문에 router-id는 R1 라우터의 실제 IP 주소인 1.1.1.1로 설정되었다.

 

---

Loopback IP 선출

다음은 Loopback 주소를 설정하는 과정이다.

 

루프백 IP 주소를 입력하는 명령어는 "interface loopback [번호]"이다. ① 번을 보면 lookback 주소를 최대 2,147,483,647개 (약 21억 개)를 생성할 수 있다. 따라서 ②번과 같이 lookback 0번을 생성하였다. ③을 보면 통로가 바로 열리는 것을 확인할 수 있다. Loopback 주소는 가상 주소이기 때문에 다른 라우터의 설정과 연결에 관계없이 통로가 열리게 된다. (no shutdown 명령 필요 X) ④번과 같이 Loopback 주소로 10.10.10.10/24를 입력하였다.

 

이후 다시 router-id를 살펴보면 다음과 같다.

 

아직까지 변화가 없는 것을 확인할 수 있다. 이는 프로세스를 다시 구성하지 않았기 때문이다. 때문에 OSPF 프로세스를 재시작해 주어야 한다. 명령어는 "clear ip ospf process"이다. 명령어 입력 후 "yes" 입력해 주어야 재시작이 된다.

 

재시작 이후 다시 router-id를 확인해보겠다.

 

아직도 동일한 것을 확인할 수 있다.

 

프로세스 재시작을 통해서도 변화가 없다면, 마지막 수단으로 Router을 재시작하여야 한다. 라우터에 수정사항이 생겨 이를 반영하는 것에 있어서 프로세스 재시작과 라우터 재시작 중 선택할 때, 어느 경우에 변화가 적용되는지는 기준이 복잡하기 때문에 라우터를 재시작하면 무조건 반영이 되겠지만, 프로세스 재시작을 먼저 해보고 변화가 없다면 선택한다. (라우터가 재부팅되면서 생기는 공백시간은 누구도 메꿀 수가 없기 때문에 라우터 재시작은 최후의 수단으로 남겨 두어야 한다.)

 

라우터의 running-config 정보를 startup-config에 저장 후 재시작 하겠다.

 

router-id를 다시 확인하면, loopback IP 주소로 변경된 것을 확인할 수 있다.

 

그런데 Loopback IP를 통하여 테스트 등을 진행할 때, 수신받는 다른 라우터에서는 해당 IP가 루프백인지 아닌지 확인을 어떻게 할까? 실제 Loopback IP를 R1에서 광고하도록 해보겠다.

 

이후 R3에서 라우팅 테이블을 확인해보겠다.

 

Loopback IP를 입력할 때, C 클래스(/24)로 서브넷팅 시켰으나 라우팅 테이블을 보면 Loopback IP를 /32로 받고 있는 것을 볼 수 있다. 이는 대역대 라우팅이 아닌 "호스트 라우팅"을 하고 있는 것이다. 즉 /32는 해당 IP 주소 오직 하나만을 받는다는 의미이다. 이는 현실에서 불가능하기 때문에 라우터는 이 주소를 Loopback IP로 인식할 수 있는 것이다.

 

---

수동 입력된 IP 선출

이제 router-id를 수동 입력해 보겠다.

 

직접적인 연결을 설정하니 "Reload or use "clear ip ospf process" command , for this to take effect"라고 해당 설정을 적용하기 위해서 라우터 재부팅 또는 프로세스 재시작을 하라고 안내문이 (친절하게) 나타난다.

 

라우터 프로세스 재시작을 하고 다시 설정 창을 확인하면 다음과 같다.

 

수동으로 입력한 100.100.100.100으로 변경된 것을 확인할 수 있다. 이와 같이 프로세스 재시작으로 변경이 적용되는 경우도 있기 때문에 프로세스 재시작을 먼저 해보고 되지 않으면, 라우터 재부팅을 시작한다.

 

라우터 id는 IP 주소 형식과 동일하며 약 42억 9000천만 개의 IP 주소 모두를 사용 가능하다.

 

R2에서 연결된 OSPF로 연결된 라우터 정보를 확인하면 다음과 같이 router-id가 적용된 것을 알 수 있다.