지난 포스팅에서는 OSPF가 어떤 프로토콜이고 어떻게 동작하는지를 알아보았습니다.
그럼 오늘은 실제로 OSPFv2를 운영하기 위해서 무엇을 염두해야 하는지 알아보겠습니다.
네트워크 유형
프로토콜 관점에서 두 가지 네트워크 유형이 있습니다.
- 지점간 네트워크: 두 개의 피어만 링크에 위치합니다. 인터페이스가 지점간(Point-to-Point) 링크로 구성이 되면, OSPF는 하나의 인접 장치(Neighbor)가 인터페이스상에 있을 것임을 알고 있습니다. PPP 시리얼 링크가 이러한 종류의 예시가 될 것입니다.
- 브로드캐스트 네트워크: 두 개 이상의 피어가 링크에 있을 수도 있습니다. 인터페이스가 브로드캐스트 네트워크로 구성이 되면, OSPF는 인터페이스상에 두 개 이상의 인접 장치(Neighbor)가 검색될 수 있다는 것을 인지합니다.
ArubaOS-CX에서 인터페이스는 기본적으로 브로드캐스트 네트워크 유형으로 구성되지만, “ip ospf network” 명령어를 사용하여 변경할 수 있습니다.
Switch(config)# interface <interface-ID>
Switch(config-if)# ip ospf network {broadcast | point-to-point}사용 중인 네트워크 유형을 확인하려면 “show ip ospf interface” 명령어를 사용합니다.
실제로 동일한 브로드캐스트 도메인에 여러 라우터가 있는 경우가 아니라면, 지점 간 네트워크 유형으로 스위치간 링크를 구성하는 것이 더 좋습니다.
※ 참고: 네트워크 유형은 이더넷이 고유한 Layer 2 프로토콜로 완전히 수용되지 않았을 때 사용된 개념입니다.
그 당시에는 링크의 양쪽 끝에 하나의 장치만 있을 수 있는 직렬 통신이 더 자주 사용되었습니다. 이것이 Point-to-point 네트워크 유형의 개념으로 이어졌습니다.
하지만, 이더넷은 동일한 브로드캐스트 도메인에 여러 장치가 연결될 수 있도록 설계되었습니다. 이것이 결국 브로드캐스트 네트워크 유형의 개념으로 이어졌습니다.
※ 참고: OSPF는 NBMA(Non-Broadcast Multiaccess)란 네트워크 유형을 사용할 수도 있습니다. 이 네트워크는 여러 장치(다중 액세스)를 지원할 수 있지만, 브로드캐스트 기능은 지원하지 않습니다. Frame Relay 장치가 이러한 네트워크 유형의 장치입니다. 이러한 유형은 최신 네트워크 환경에서 더 이상 사용하지 않습니다.
브로드캐스트 네트워크의 확장성 문제
OSPF 피어간에 교환할 수 있는 정보의 양은 중간 규모 이상의 기업 네트워크에서 많을 수 있습니다.
브로드캐스트 네트워크 유형에서는 각 라우터에 여러 피어가 있을 수 있기 때문에 이 값이 쉽게 증가할 수 있습니다. 이는 각 OSPF 피어에 대해 수백개 또는 수천개의 경로를 계산되어야 할 때, 라우터의 성능에 영향을 줄 수 있게 됩니다. 즉, 이러한 문제에 대한 솔루션이 필요하게 됩니다.
OSPF는 브로드캐스트 도메인에서 지정 라우터(Designated Router, DR)를 선택하여 이러한 확장성 문제를 해결합니다. 이 장치는 나머지 장치와 완전히 이웃 상태(full neighbor state)를 유지합니다. 즉, 데이터베이스가 서로 피어간 서로 교환되는 것을 의미합니다.
그러나 지정되지 않은 라우터는 서로 데이터베이스 정보를 교환하지 않습니다. 이것은 도메인의 각 라우터가 처리해야 하는 정보의 양을 줄이는데 도움이 됩니다.
고가용성(High Availablity)를 유지하기 위해서, 백업 지정 라우터(Backup Designated Router, BDR)를 지정하여 단일 지점으로 인한 장애를 방지할 수 있습니다. 이 장치 또한 브로드캐스트 네트워크의 모든 장치와 함께 전체 상태를 유지합니다. 그러나 기본 DR에 문제가 생겨 더 이상 사용할 수 없는 경우에만 정보를 제공(advertise)합니다.
지정 라우터(DR)와 백업 지정 라우터(BDR)
위에서 얘기한 것처럼, 브로드캐스트 네트워크에서 OSPF 라우터는 두 개 이상의 피어와 이웃 관계를 형성할 것으로 예상합니다. 이 상황은 잠재적으로 봤을 때 굉장히 비효율적일 수 있습니다. 토폴로지 변경이 있을 때마다 LSA가 브로드캐스트 도메인에서 플러딩되고 또 다시 플러딩 될 수 있기 때문입니다.
이러한 문제의 해결책은 브로드캐스트 도메인 안에서 피어간 상호 작용을 조정하는데 도움이 되는 단일 접점 포인트인 지정 라우터(DR)를 선택하는 것입니다. 브로드캐스트 도메인의 다른 모든 OSPF 피어와 완전한 인접성 (full adjacency)을 형성해서 LSA를 수신하고 플러딩 할 수 있게 됩니다.
DR에 장애가 발생할 경우에는 백업 지정 라우터(BDR)가 인계되도록 합니다. BDR 역시 DR 및 브로드캐스트 도메인의 다른 모든 피어와 완전한 인접성(full adjacency)를 형성합니다.
DR이나 BDR로 선택되지 않은 나머지 라우터들은 DROTHER의 레이블로 지정됩니다. 이러한 라우터들은 DR 및 BDR과만 완전한 인접성을 형성하게 됩니다. 이로서 앞서 얘기했던 비효율성에 대한 문제가 해결됩니다.
브로드캐스트 도메인에 3개의 라우터가 있든 30개의 라우터가 있든 상관없이 DROTHER 라우터는 DR과 BDR, 2개의 피어하고만 인접성(adjacency)을 형성하면 됩니다.
그림으로 다시 정리해볼까요? 좀 더 이해가 쉬울 것입니다.
DROTHER 중 하나가 자신의 다른 인터페이스 중 하나에서 토폴로지 변경을 감지하게 됩니다.
브로드캐스트 도메인의 모든 라우터와 통신할 필요 없이 DR과 BDR하고만 통신하게 됩니다. 따라서 목적지 IP주소 224.0.0.6을 사용하여 멀티캐스트 LSA 메시지를 보내게 됩니다. 해당 IP주소는 “DR과 BDR 주목하세요” 목적으로 예약된 주소입니다.
DR이 정상적으로 동작하고 있기 때문에 이 패킷을 수신합니다. 그리고 토폴로지 데이터베이스를 업데이트하고 다른 모든 Non-DR(DROTHER)에게 목적지 224.0.0.5주소를 사용하여 멀티캐스트 LSA 메시지, “모든 DROTHER 주목! 새로운 정보가 있습니다.”를 알립니다.
지정 라우터(DR) 선정
DR과 BDR 선정은 인터페이스 할당된 우선 순위 값을 기반으로 이뤄지고, 가장 높은 우선 순위 값이 선택됩니다.
동점일 경우에는 Router-ID가 높은 라우터가 DR이 됩니다.
AOS-CX는 우선 순위 값과 관련하여 아래와 같은 특정 규칙을 따릅니다.
- 기본(Default) 우선 순위 값은 1입니다.
- 우선 순위 값으로 지정 가능한 범위는 0부터 255 사이입니다.
- 우선 순위 값이 0이면 라우터가 DR 선택에 참여하지 않음을 의미합니다.
다음과 같이 인터페이스 레벨에서 이러한 구성을 수행할 수 있습니다.
Switch(config)# interface <interface-ID>
Switch(config-if)# ip ospf priority <priority-value>우선 순위 값과 선택된 DR을 확인하려면, “show ip ospf interface” 또는 “show ip ospf neighbors” 명령어를 사용하면 됩니다.
OSPF 영역(Area)
OSPF에서 영역(Area)이란 동일한 링크 상태 데이터베이스(LSDB)를 공유하는 OSPF 라우터 그룹을 말합니다.
모든 라우터는 어떤 영역의 일부여야만 합니다.
큰 네트워크를 여러 영역으로 분할하면, 각 라우터의 LSDB의 크기가 줄어들고 CPU 사용률이 낮아지면서 전반적으로 네트워크 안정성이 높아집니다. 이는 영역의 각 라우터가 해당 영역에 대한 토폴로지만 유지해야 하기 때문입니다.
예를 들어, 아래 그림에서 SW1과 SW2, 그리고 SW3은 전체 토폴로지에 대해 알 필요가 없으며, Area 10 토폴로지에 대해 알면 됩니다.
라우터 SW1과 SW2는 “내부 라우터(Internal Router)”라고 하며 모든 인터페이스가 하나의 영역 안에 있게 됩니다. 내부 라우터가 해당 영역 밖으로 라우팅해야 하는 경우 단순히 패킷을 영역 경계 라우터(Area Border Router, ABR)로 전달합니다. ABR은 두 개 이상의 영역에 연결된 라우터를 말합니다. SW3은 Area 10에 두 개의 인터페이스가 연결된 Area 10에 대한 ABR입니다. 그리고 Area 0에 두 개의 인터페이스가 또 연결되어 있습니다.
모든 영역은 특별한 백본 영역인 Area 0에 연결 되어야만 합니다. 이 영역은 계층 구조에서 가장 중요한 영역이기 때문에 이중화 설계가 되어야 합니다. 따라서 Area 10은 0이 아닌 다른 영역에 직접 연결할 수 없습니다. 2개의 비백본(nonbackbone)영역 간의 통신은 반드시 Area 0를 통해서만 통신해야 합니다.
Area 0에 인터페이스가 있는 라우터를 백본 라우터(Backbone Router)라고 하고, 위 그림에서 SW4, SW5, SW6는 모든 인터페이스가 단일 영역 Area 0에 있기 때문에 내부 라우터이기도 합니다. 그래서 내부 백본 라우터(Internal Backbone Router)라고 부르기도 합니다.
인터페이스에 영역을 할당하기 위해서는 Area ID를 인터페이스에 할당해야 합니다. Area ID는 32비트 길이의 IP주소와 같이 dot-decimal 표기법이나 십진수 표기법으로 표시합니다. AOS-CX는 두 가지 표기법 모두 지원합니다.
OSPF LSA Type (LSA 1)
OSPF 라우터는 OSPF 라우팅 도메인에서 각기 다른 목적과 범위를 가진 다양한 유형의 LSA(Link State Advertisement)를 생성합니다. 각 LSA에는 라우터가 알리고자 하는 네트워크 영역을 설명한 링크 상태 식별자(Link State Identifier)가 포함되어 있습니다.
자, 그럼 LSA 유형별로 한 번 알아볼까요?
LSA type 1의 목적은 라우터가 자신을 알리는 것입니다. 때문에 LSA Type 1은 “라우터 LSA” 라고 부르기도 합니다.
우리가 방으로 들어가서 사람들에게 자기 소개를 하는 것과 같다고 생각하면 됩니다.
"안녕하세요. 제 이름은 루바루바입니다."
마찬가지로 라우터는 LSA Type 1을 사용하여 다음과 같이 자신을 소개합니다.
"안녕하세요. 저는 RID 10.1.100.1이며, 동작 중인 인터페이스가 3개 있고 이 OSPF Area에 참여하고 있습니다."
LSA Type 1에서 공유되는 정보는 Link Type 마다 다르다는 것이 중요합니다.
서로 다른 Link Type이 구성될 때, 서버 스위치에서 어떤 정보를 공유할지 생각해야 합니다.
네트워크 유형을 정의하는 것 외에도 OSPF는 두 가지 다른 개념인 Link Type도 정의합니다.
Link Type은 주로 OSPF 라우터의 인터페이스 또는 이웃(Neighbor)를 설명하는데 사용됩니다.
- Stub Link: 인터페이스에서 OSPF가 활성화되어 있고 인터페이스에 OSPF 이웃(Neighbor)가 없는 경우에 사용됩니다. 예를 들어 Loopback 인터페이스는 Stub 네트워크로 간주됩니다.
- Transit Link: 2개 이상의 OSPF Neighbor가 있는 브로드캐스트 네트워크에서 사용됩니다.
- Point-to-Point Link: 지점간 네트워크에서 사용되는 링크로, OSPF Neighbor 항목이 하나만 있어야 합니다.
※ 참고: Link Type은 네트워크 ID와 링크에 있는 Neighbor의 수를 설정한 결과입니다.
예를 들어, 네트워크 유형이 point-to-point라면 링크에 라우터가 한 개만 있다는 것을 알 수 있습니다.
아니면, 네트워크 유형이 브로드캐스트로 설정되면 Stub 또는 Transit Link Type이 사용됩니다. Neighbor가 없는 경우에는 Stub, Neighbor가 하나 이상이라면 Transit Link Type이 됩니다.
AOS-CX에서는 “show ip ospf lsdb”의 명령어를 사용하여 정보를 확인할 수 있습니다.
위 토폴로지 그림에서 Core-1 스위치는 해당 영역에 3개의 라우터가 있음을 알 수 있습니다. 이는 나중에 강력한 트러블슈팅 명령어로 사용될 수 있습니다.
네트워크 구성도에는 라우터가 5개 있다고 표시되지만, 실제 명령어로 확인했을 때 3개만 표시된다면 문제가 있다는 것을 바로 알 수 있게 됩니다.
LSA Type 1 메시지 분석 예시
자, 그럼 서로 다른 Link Type으로 구성되어 있을 때, Server Switch의 LSA Type 1 Advertisement에서 공유한 정보를 확인해볼까요?
Port 1:
- Link Type: 브로드캐스트
- RID: 10.0.100.0
- Link ID: 10.1.1.1 - DR의 인터페이스
- Data: 10.1.1.1 - 인터페이스의 IP주소
Port2:
- Link Type: Point-to-Point
- RID: 10.0.100.0
- Link ID: 10.1.100.2 - 피어의 RID
- Data: 10.1.2.1 - 인터페이스의 IP주소
Port 47:
- Link Type: Stub
- RID: 10.0.100.0
- Link ID: 10.20.0.1
- Data: 255.255.240.0 - 서브넷 마스크
자, 그럼 Core-1과 Core-2 관점에서 정보를 분석해볼까요?
먼저 Stub Link Type에는 Subnet과 Mask가 포함되며, 이 정보는 SPF 알고리즘을 로컬에서 실행하여 목적지까지 도달하기에 충분합니다.
그리고 P2P 인터페이스는 피어의 라우터 ID와 사용되는 로컬 인터페이스 정보를 포함합니다. Core-1 관점에서 링크의 세부 정보가 완전하지 않으면 Core-1은 링크에 있는 다른 피어의 데이터가 필요합니다.
이 정보는 Core-1이 Core-2로부터 LSA Type 1을 수신할 때 알려질 것입니다. 양쪽으로부터 정보를 받게 되면 Core-1도 SPF 알고리즘을 실행할 수 있습니다.
마지막으로 브로드캐스트 인터페이스에는 라우터 ID의 IP주소만 포함되지만, 이 경우에 LSA Type 1을 사용하여 서브넷 정보가 포함되지 않게 됩니다. 결국 SPF 알고리즘을 실행할 수가 없게 됩니다.
이 경우에는 어떻게 해결해야 할까요?
바로 LSA Type 2를 사용하는 것입니다.
AOS-CX에서는 “show ip ospf lsdb” 명령어를 사용하여 이 정보를 확인할 수 있습니다.
OSPF LSA Type 2
LSA Type 2는 DR과 BDR이 선택된 브로드캐스트 Network Type Link가 있을 때 사용됩니다.
지점간(Point-to-Point) 네트워크 유형의 라우터는 LSA Type 2를 생성하지 않습니다. 이 경우에 Link-state ID는 지정 라우터(DR)의 IP주소입니다. 라우터가 DR인 네트워크를 알리기 때문에 이러한 LSA를 네트워크 LSA라고 합니다.
위 그림은 Wireshark를 사용하여 LSA안에 포함된 Netmask가 있는 패킷을 캡쳐한 화면입니다.
이 정보로 LSA Type 1에서 누락된 정보가 확인되면서 이제 SPF 알고리즘을 실행할 수 있게 됩니다.
“show ip ospf lsdb” 명령어를 통해 나온 결과물에서 Network Link State Advertisement 섹션은 DR 목록을 보여줍니다.
경로 선정
모든 라우터가 성공적으로 LSA(Link State Advertisement)와 LSU(Link State Update)를 교환하고 나면 모두 동일한 LSDB(Link-state Database – 토폴로지 데이터베이스)를 갖게 됩니다. LSDB는 모든 경로와 라우터의 목록들이며, 이러한 라우터와 링크들이 어떻게 연결되어 있는지 저장합니다. 즉, 모든 경로에 대한 목록을 갖고 있게 됩니다.
이제 라우터는 SPF(Shortest Path First) 알고리즘인 Dijkstra 알고리즘을 실행하여 각 목적지 서브넷에 대한 최상의 경로를 찾아야 합니다. 가장 좋은 경로는 비용이 가장 낮은 경로이며, 비용은 대역폭을 기반으로 합니다.
따라서, 단일 서브넷에 대한 경로가 여러 개 있는 경우, OSPF는 누적 비용이 가장 낮은 경로, 즉 가장 빠른 경로를 선택합니다.
위 그림의 토폴로지를 살펴볼까요? Core-1에는 목적지 서브넷 10.20.0.0/22에 도달하는 두 가지 경로가 있습니다.
각 경로의 비용을 결정하려면, 각 링크에 표시된 값을 더하기만 하면 됩니다.
- Core-2를 Next-hop으로 사용할 경우: 비용은 50 + 100 = 150
- Server-Swtich를 Next-hop으로 사용할 경우: 비용은 100 = 100
즉, Server-Switch를 Next-hop으로 사용한 경로가 가장 저렴하기 때문에 해당 경로가 라우팅 테이블에 추가됩니다.
OSPF 컨버전스
OSPF 라우팅 컨버전스를 위해서는 두 가지 요소가 있습니다.
- 토폴로지 변화 Detect (탐지)
- 경로 Recalculate (재계산)
토폴로지 변경 탐지는 OSPF에서 두 가지 방식으로 지원됩니다.
첫 번째는 가장 빠른 방법인 물리적 인터페이스의 장애 또는 상태 변경입니다.
그리고 두 번째는 OSPF Hello 타이머의 시간 초과(timeout)입니다. Hello 패킷에 대한 데드 타이머(dead timer)가 초과하도록 패킷이 도착하지 않으면 OSPF Neighbor에 문제가 있다고 간주합니다. 기본적으로 데드 타이머는 OSPF Hello 패킷의 타이머 값의 4배입니다. 기본 Hello 타이머가 10초이기 때문에 40초가 지나도록 도착하지 않으면 데드 타이머가 초과되고 장애로 인식합니다.
변경이 감지되면, OSPF 영역의 모든 라우터에 LSA를 보내서 토폴로지 변경을 알립니다.
그림처럼 Core-1과 Server Switch간 링크에 장애가 발생하면, Server Switch와 Core-1은 이 장애를 감지합니다.
링크가 UP 상태에서 DOWN 상태로 변경되고, Server Switch와 Core-1은 토폴로지 변경 LSA를 발생시킵니다.
그런 다음, SPF 알고리즘을 실행하여 10.20.0.0/22와 같이 영향을 받는 모든 네트워크에 대한 최상의 경로를 다시 계산합니다.
여기서 Server Switch는 변경 없이 직접 연결된 경로를 사용하지만, Core-1의 경우에는 다시 경로를 계산하여 기존 Server Switch로 가는 경로 대신 Core-2를 통해 지나가는 경로를 사용하게 됩니다.
여기서 Core-2는 변경 사항에 대한 LSA를 수신하지만, 이 경우에는 다시 계산할 필요는 없습니다.
각 라우터는 장애를 탐지한 후에 경로에 대한 재계산을 수행합니다. 다시 말해 모든 라우터는 Dijkstra(SPF) 알고리즘을 사용하여 모든 경로를 재계산하게 됩니다.
패시브 인터페이스
OSPF 구성에는 논리적으로나 물리적 인터페이스에서 프로토콜을 활성화하는 작업이 필요합니다.
따라서 라우터는 LSA를 생성하여 서브넷을 다른 라우터에 알릴 수 있게 됩니다. 즉, 라우터가 모든 OSPF를 지원하는 인터페이스에서 주기적으로 Hello 메시지를 보낸다는 것입니다.
하지만, 어떤 경우에는 이것이 불필요할 수 있습니다. 예를 들어 해당 서브넷에 호스트만 있는 경우입니다. 다른 네트워크 장치가 없음에도 라우터는 계속적으로 OSPF 패킷을 보냅니다. 호스트 장비는 OSPF 멀티캐스트 224.0.0.5나 224.0.0.6 패킷에 응답하지 않습니다. 단순히 링크 내에 대역폭을 낭비할 뿐입니다. 또한, 악의적인 사용자가 링크에 있다면 네트워크에 대한 정보를 배우고 잠재적으로 공격을 준비할 수도 있습니다.
이에 대한 솔루션으로 호스트 대면(host-facing) 라우터 인터페이스를 수동으로 구성하는 것입니다.
인터페이스가 수동(Passive)이면, 해당 인터페이스에서 OSPF 패킷을 주고받는 것을 중지합니다. 그러나 다른 경로에는 그 인터페이스에 대한 광고를 계속합니다.
그림에서 Core-1은 Hello 패킷을 10.1.0.0/16 네트워크로 보내지 않지만, Core-2에는 알립니다. Core-2 역시 10.2.0.0/16 네트워크에 대해서 Core-1에게만 알립니다.
AOS-CX에서는 인터페이스 Context에서 “ip ospf passive” 명령어를 사용하여 패시브 인터페이스를 활성화할 수 있습니다.
Switch(config)# interface <interface-ID>
Switch(config-if)# ip ospf passiveOSPF 구성 실전 예제
그럼 지금까지 배운 내용을 토대로 실제 AOS-CX 스위치에서 어떻게 구성하는지 볼까요?
1. OSPF 프로세스 활성화
Switch(config)# router ospf <process-ID>2. Router ID 구성
Switch(config-ospf-1)# router-id <a.b.c.d>3. OSPF Area ID 생성
Switch(config-ospf-1)# area <area-ID>4. 인터페이스에서 OSPF 활성화
Switch(config-if)# ip ospf <process-ID> area <area-ID>5. Network Type 설정
Switch(config-if)# ip ospf network {broadcast | point-to-point}6. OSPF 비용 설정 (optional)
Switch(config-if)# ip ospf cost <cost-value>이렇게 OSPFv2에 대해 간단하게 알아보았습니다.
굉장히 기본적인것만 짚고 넘어갔음에도 생각보다 긴 포스팅이었네요.
OSPF는 실제 필드에서 가장 많이 사용하는 라우팅 프로토콜이기 때문에 관련된 용어와 기술, 트러블슈팅 방법에 대해서 반드시 꼭 알아야 하는 부분입니다. 조금은 어렵고 복잡하지만 놓치고 갈 수는 없는 기술입니다.
이제 ACSA 교육 과정이 얼마 남지 않았습니다. 이제는 관리나 운영 관련된 내용으로 마무리해볼게요.
