반응형
지난 번에 Distance Vector Protocol의 장단점,특징을 알아보았구요....일단 이 프로토콜의 문제는 주기적인 업데이트....그것두 모든 라우팅정보를 넘김에 따라 과도한 트래픽이 발생한다는 점, 그리고 Triger Update가 늦다는 구조적 문제점 등이었습니다.
이래서 개발된 것이 OSPF (Open Short Path First)입니다.
일단 동작원리는 위의 그림과 같습니다.
일단 주위 라우터를 RIP에선 PEER라 부른 반면...(왜냐하면 동등한 입장에서 모든 라우팅 정보를 주고 받으니까요) OSPF 에서는Neighbor라 부릅니다.
이렇게 Neighbor이 형성되고 나면, LSA를 통하여 최적의 경로를 받습니다.(구성하는 것이 아닙니다.) 이러면 SPF가 구동되어 자신 나름대루 경로를 선택한 후에 이것을 라우팅 테이블에 올립니다.
RIP과는 머가 다르죠? 일단 이것은 Hop으로 결정하는 것이 아니라 Cost라 불리는 추상적인 개념을 이용합니다. 단순 hop 수가 아닌 link speed, hop, link stats등을 모두 종합한 것이죠...
또 RIP은 hop 이 한 홉 넘어가면 상대방의 상태를 알 수 없지만 OSPF는 Neighbor의 상태가 변하면 즉각, 이 사실을 알림으로서 RIP과는
비교도 안되는 Triger Update 시간을 자랑합니다.
그럼 이 OSPF는 어떤 식으로 구성이 될까요? 아까 말씀드린 대로 Neighbor의 상태를 살핀다구 했죠?
여러개의 경우 여러개의 모든 Neighbor의 상태를 살핍니다. OSPF의 또 하나 특징은 도메인 라우팅인데...이렇게 Neighbor는 한 도메인에
서만 유효 합니다.
즉, 불필요 트래픽이 도메인 밖으로 나가지를 않죠...
그 도메인에서 자신의 테이블이 어떻게 생겼고, 각 internal router들의 Neighbor정보를 받구 또 뿌려주는 넘이 DR입니다. OSPF안에서는
반드시 한개의 DR이 있어야 하며 일종의 DB서버라구 생각하시면 됩니다. 처음에 Neighbor를 맺으면 서로 비교를 하여서 한넘을 DR로 추대합니다.
그러면 이 DR은 모든 정보를 받아서 그 도메인의 라우터들에게 라우팅 정보를 뿌려줍니다. 만약, 한 라우터에 라우팅 테이블이 증가되었다면? RIP경우 이 정보를 알려주지 못하고 업데이트 시간이 되면 기존 라우팅 테이블과 동시에 전 네트워크에 뿌립니다.
OSPF는 라우터의 라우팅 테이블 변화시 Neighbor가 젤먼저 알아차립니다
이 정보를 DR에게 갈쳐주죠. 그러면 DR은 이 정보를 일괄적으로 바로 전 라우터에게 뿌립니다.
추가된 정보만 뿌리니 네트워크 부하가 줄겠죠.... 그럼 언제나 DR이 라우팅 정보를 뿌릴까요? 아닙니다.
처음 정보는 DR이 라우팅 테이블 관리를 합니다. 자신만이 라우팅 정보를 가지고 있으니까요..
이것을 Type 1 이라 합니다. 하지만 일정기간 전 네트워크에 변화 없을 경우 Type 2라 하여.. DR에게 알려주지 않구 각각의 라우터 끼리 필요한 정보를 교환합니다.
아까 경우처럼 Link에 변화가 생기면 다시 DR이 정보 뿌리고 또 Type 2가 돌고.....다시 말하면 Type1이 많은 네트워크는 라우팅이 불안한 사이트인것이죠....
이 DR이 관리하는 도메인을 AREA라 부릅니다. OSPF는 반드시 백본 area가 있어야 합니다. 백본 area를 0.0.0.0이라 부릅니다.
한 도메인에 라우터 숫자는 45~48정도를 권장합니다.
너무 커질 경우 도메인의 의미가 없어지거등요(vlan하구 비슷하다 생각하시면 됩니다.)....네트워크가 커지면 area를 한개 더 만듭니다.
여기서 문제가 있습니다. 내가 1.1.1.1 을 만든다구 되는 것이 아니라 이 1.1.1.1이 백본 네트워크로 들어가려면 반드시 백본 area를 지닌
라워터를 통해야 합니다.
이것이 ABR입니다. ABR의 백본은 0.0.0.0 area와 1.1.1.1두개를 가지고 있는 것이죠... Advance route의 대표격인 OSPF도 문제 점이 전혀 없는 것은 아닙니다. 가장 대표적인 문제중의 한개가 16bit의 Metric 이외에 여러가지 추상적인 것들의 조합인 cost값입니다.(cost가 낮은 경로가 우선순위 입니다.)
먼저 공식으론 OSPF Link Cost=100,000,000/Link Bandwidth
여기서 가장빠른 LAN인 FDDI에 cost 1을 부과하고 대역폭이 10Mbps인 ethernet에 cost 10을 부과하고 토큰링의 16Mbps 대역폭에는 6
을 부여 하였습니다.
처음에 이것은 너무도 간단한 듯 보였습니다. 하지만 이것이 만들어 질때 FDDI가 "가장 빠른 네트워크"였던 것이 문제였습니다.
지금은 PC도 10/100이 기본이고, 좋은 사이트 경우 10/100/1000Mbps를 사용합니다.
백본은 1기가 혹은 10기가를 사용하지요.....OSPF를 만들 당시 생각지도 못했던 문제가 발생을 한 것입니다.
만약 FDDI와 기가빗이 혼재한다면 OSPF는 기가빗=FDDI를 같은 대역폭으로 인지 할 것입니다.
다행스러운 사실은 이 모든 cost값은 같은 AS내에서만 중요한 파라메타라는 것이죠...
다른 AS경우는 이 cost값을 무시합니다. 그렇기에 많은 라우터가 연결되어있어도 혼재될 문제가 없는 것입니다.
또 하나의 문제점은 고질적인 CPU자원 문제입니다.
OSPF는 CPU자원을 많이 먹는 프로토콜로 지속적인 비난을 받아왔습니다.
대충 이러한 공식인데... CPU/Router/Area a [(링크수+라우터수)*log라우터수]+Summary수+External 라우터수
물론 전 이공식을 외우지 못합니다....그리고 외울필요도 읍구여 ^^;;;;
아직 제 경험적으로는 OSPF로 인해 라우터의 CPU가 상승되는 것을 본적은 없습니다.
하지만 한 Area에 많은 라우터가 존재할 때 라우터가 문제가 생긴다고들 하더군요..그리고 라우터 문제가 생길 때 주로 이 문제라고 보고서
를 많이 써봤습니다. ^^;;;;;
그럼 어떻게 해야 파워풀한 이 OSPF를 잘 사용할까요? OSPF를 잘 쓰기 위한 팁의 가장 중요포인트는 알맞은 크기의 Area관리입니다.
위의 그림처럼 적당한 크기의 Area로 자르는 것이 중요합니다. 보통 한 Area안에 45개 내외의 라우터 수를 권장합니다.
숫자가 클경우 엄청난 량의 SPF 프로세서의 동작으로 DR에 부담을 주게 된다고 하더군요(실제로 본적은 없기에..^^;;;)
제가 예전에 전국망 관공서 사이트 두군데를 갔었는데...두군데 모두 Area 0.0.0.0 한개였습니다. ^^;;; 제 생각엔 처음엔 망이 크지 않았
기에 그냥 그렇게 한것 같은데..나중에 망이크면서 Area를 나눌 생각 않고 걍 계속 같아 붙여서 그렇게 된듯 하더군요...
KT경우는 "도"별로 Area를 쪼갰습니다.
말도 많고 탈도 많은 OSPF가 이렇게 이슈화 된것은 그리 오래되질 않았습니다.
라우터로만 네트워크 구성을 하던 시절은 말이 의외로 없었죠..하지만 고용량 스위치가 나오면서(라우터 스위치) 스위치에서 라우팅 프로
토콜을 돌리게 되자 말이 많아진것이죠...
시스코에서는 OSPF의 문제점을 이슈화 시킨것이죠.....(솔찍히 wan시절 그리 많이 사용안했습니다. EIGRP가 있으니..) 왜냐면
IGRP,EIGRP가 시스코 독자 프로토콜로 잡혀있는 현실에서 다른 밴더가 사요할 수 있는 Advance routing protocol은 OSPF밖에 없었던 것
이죠...
타밴더에서는 EIGRP를 구시대적 프로토콜로 치부하는 경우가 많습니다. 표준은 OSPF이고, 더욱 강력하다라는 식이죠..물론 시스코에서
는 OSPF의 문제점을 많이 이슈화 시켰습니다.
지금은 시스코에서도 OSPF를 많이 사용합니다. 어쩔수 없는 대세죠....물론 아직 기득권이 있는 사이트에서는 EIGRP를 사용하구요...
엔지니어적 입장에서는 OSPF와 EIGRP의 장단점...솔찍히 잘 모르겠습니다. 어느게 더 존지...
저야....죽지만 않으면 최상이죠 ^^;;;;;;
한가지 확실한 것은 말이 많은 이 두가지 프로토콜다 정말로 우수한 프로토콜이고 많은 사이트에서 사용되어 오면서 수많은 패치로 인해
관리자들에게 사랑받는 프로토콜이라는 것입니다.
다만, 영업에 의해 이렇다 저렇다 말이 많을 뿐.....
출처 : 네트웍 전문가 따라잡기
출처 : http://cafe.naver.com/analysisman.cafe
반응형
