네트워크 시뮬레이션 공방

UCMP(Uneual-Cost Multi-Path), 또는 Unequal-Cost Load Balancing[1]는 는 비용이 다른 여러 개의 경로들을 동시에 라우팅에 사용하는 것이다. 즉, ECMP("다중경로 라우팅(1) - ECMP" 참조)에서는 동일한 비용(Cost)을 가지는 경로가 여러개 존재해야만 트래픽 부하 분산이 가능하지만, UCMP에서는 동일한 비용(또는 메트릭)을 가지는 경로가 없을 때에도 트래픽 부하 분산이 가능하다.
"EIGRP 메트릭 변량"에서 언급하였듯이 EIGRP에서는 UCMP를 지원하며, Riverbed(OPNET) Modeler EIGRP 모델에도 구현되어 있다. 다음 그림은 EIGRP에 의한 UCMP 라우팅 동작을 확인하기 위하여, "다중경로 라우팅(1) - ECMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. Client 노드에서 Server 노드로 향하는 2개 경로(Client -> R1 -> R2 -> R4 -> Server 경로와 Client -> R1 -> R3 -> R4 -> Server 경로)의 비용(즉, 메트릭)이 차이가 나도록 만들기 위해서, R1 <-> R3 링크의 대역폭을 다른 링크들보다 작아지도록 변경하였다.

UCMP가 사용되지 않은 경우와 사용된 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. UCMP가 사용되지 않은 경우에는 하나의 경로만 사용되었지만, UCMP가 사용되는 경우에는 2개의 경로가 모두 사용되었음을 쉽게 관찰할 수 있다.

트래픽이 실제로 분산되었음을 확인하기 위하여 R1 -> R2 링크와, R1 -> R3 링크의 트래픽 유통량을 살펴보면 다음 그림과 같다.

UCMP가 사용되지 않은 경우에는 대역폭이 큰(즉, 비용이 작은) R1 -> R2 링크로 모든 트래픽이 전달되었지만, UCMP가 사용되는 경우에는 대역폭이 작은(즉, 비용이 큰) R1 -> R3 링크로도 일부 트래픽이 분산되었음을 확인할 수 있다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html

이 블로그의 많은 글에서 라우팅 테이블과 포워딩 테이블을 구분없이 사용하고 있다. 하지만, 엄밀하게 말하자면 Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블은 구분된다. (Riverbed(OPNET) Modeler의 라우팅/포워딩 테이블 구분은 얼핏보면 일반적인 라우팅/포워딩 테이블 개념[1, 2, 3]과 조금 달라보이기도 한다. 하지만, 근본적으로는 동일한 개념이라고 생각된다.) Riverbed(OPNET) Modeler에서 라우팅 테이블은 각 라우팅 프로토콜이 생성/관리하는 정보이며, 포워딩 테이블은 각 라우팅 프로토콜로부터 정보를 넘겨받아 IP 계층에서 생성/관리하는 정보이다. 이 관계를 그림으로 표현하면 다음과 같다.

그림에서 알 수 있듯이 라우팅 테이블과 포워딩 테이블은 완전히 분리되어 별도로 저장된다. 하지만, 대부분의 경우 포워딩 테이블에는 라우팅 테이블에 저장된 내용과 동일한 정보가 저장된다. 이 블로그에서 라우팅 테이블과 포워딩 테이블을 구분하지 않고 혼용하는 이유는 이 때문이다. (사실, Riverbed(OPNET) Modeler 내부에서 조차도 라우팅 테이블과 포워딩 테이블 용어를 정확히 구분하지 않고 혼용하는 경우가 있다.)

[1] https://en.wikipedia.org/wiki/Routing_table
[2] https://en.wikipedia.org/wiki/Routing_table#Forwarding_table
[3] http://nenunena.tistory.com/52

"다중경로 라우팅(4) - 동일 목적지 예제"와 "다중경로 라우팅(5) - 다수 목적지 예제"에서 살펴본 것처럼, 트래픽 로드 밸런싱 효과는 Packet-Based 방식이 더 좋다. 하지만, 실제 통신망에서 Packet-Based 방식은 거의 사용되는지 않는데, 그 주된 이유는 Packet Reordering으로 인한 부작용 때문이다.
다음 그림은 Packet-Based 방식의 로드 밸런싱에서 발생하는 Packet Reordering 현상을 확인하기 위하여, "다중경로 라우팅(1) - ECMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. R1 <-> R2 링크의 delay는 50ms, R1 <-> R3 링크의 delay는 40ms로 설정하였으며, TCP 트래픽을 발생시키기
위하여 FTP를 사용하여 20MBytes 크기의 파일이 Client 노드에서 Server 노드로 전송되도록 설정해주었다.

다음 그림은 Destination-Based와 Packet-Based 방식을 적용하였을 때, Server 노드에 수신된 IP 패킷의 종단간 지연을 비교한 것이다. Destination-Based 방식에서는 약 51ms로 일정한 종단간 지연을 가지지만, Packet-Based 방식에서는 약 46ms ~ 47ms로 유동적인 지연을 가진다. 이러한 차이가 발생하는 이유는 Destination-Based 방식에서는 하나의 링크(R1 -> R3)로 모든 트래픽이 전달되지만, Packet-Based 방식에서는 지연이 다른 두 개의 링크(R1 -> R2, R1 -> R3)로 트래픽이 전달되기 때문이다.

Packet-Based 방식을 사용했을 때 상대적으로 작은 종단간 지연을 가지므로 성능면에서 더 유리할 것으로 생각할 수도 있지만, 다중 경로로 인해 종단간 지연이 유동적이라는 것은 실제로는 심각한 문제를 야기한다. 다중 경로로 인해 종단간 지연이 유동적이게 되면, 송신된 패킷의 순서가 뒤바껴서 수신(Packet Reordering)되는 현상이 발생한다. 이는 TCP 재전송을 유발시키며, 전체적인 TCP 전송 성능을 크게 떨어뜨리게 된다. 다음 그림은 Destination-Based와 Packet-Based 방식을 적용하였을 때, TCP 계층에서의 트래픽 전달 성능을 비교한 것이다. Destination-Based 방식에서의 전송 속도는 약 5.1Mbps(= 630 Kbytes/sec)인데 비해, Packet-Based 방식에서의 전송속도는 약 1Mbps(=125Kbytes/sec)로 Destination-Based 방식에서의 20% 수준밖에 되지 않는다.

Packet-Based 방식에서의 이렇게 낮은 전송 속도는 TCP 재전송에 의한 것임은 다음 그림처럼 송신측(이 예제에서는 Client 노드)의 TCP 재전송 횟수를 통해 확인할 수 있다. Destination-Based 방식에서는 재전송이 발생하지 않으므로 해당 결과가 관찰되지 않는다.

다음 그림은 FTP 계층에서 파일 전달을 수행하는데 걸린 시간을 비교한 것이다. Destination-Based 방식에서는 약 52초가 걸린데 비해, Packet-Based 방식에서는 약 181초로 훨씬 많은 시간이 소요되었음을 알 수 있다.

목적지 노드가 동일한 경우에 Destination-Based 방식과 Packet-Based 방식의 로드 밸런싱이 어떤 차이를 보이는지에 대해서는 "다중경로 라우팅(4) - 동일 목적지 예제"에서 살펴보았다. 이번에는 목적지 노드가 다수인 경우(즉, 서비스 플로우들의 목적지가 다른 경우)에 대해서 살펴보겠다.
다음은 10개의 트래픽 플로우가 라우팅 경로가 중첩되는 다수의 목적지 노드로 향하는 경우의 예제망 구조
이다("다중경로 라우팅(1) - ECMP"의 예제망에서 확장). Client 노드에서 Server_1 ~ 10 노드로 향하는 트래픽 플로우는 "다중경로 라우팅(4) - 동일 목적지 예제"와 유사하게 100초마다 하나씩 트래픽을 발생시키도록 설정하였다(이는 트래픽 증가에 따른 로드 밸런싱 효과를 관찰하기 위해서이다).

로드 밸런싱이 Destination-Based 방식인 경우와 Packet-Based 방식인 경우에 Client 노드로부터 Server_1 ~ 10 노드로의 트래픽 전달 경로를 비교해보면 다음 그림과 같다. Destination-Based 방식인 경우 개별 트래픽 플로우는 하나의 라우팅 경로를 통해서만 전달되지만, 전체 트래픽 플로우 관점에서는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다. Packet-Based 방식인 경우 각 트래픽 플로우는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다.

R1 -> R2 링크와 R1 -> R3 링크의 트래픽유통량을 살펴보면 다음 그림과 같다.

두 방식 모두 다중 경로(R1 -> R2, R1 -> R3 링크)로 트래픽이 분산되었다. 하지만, Destination-Based 방식인 경우 다중 경로로 분산된 트래픽의 양이 불균등한 반면, Packet-Based 방식인 경우 다중 경로로 균등하게 분산되었음을 확인할 수 있다. 즉, 라우팅 경로가 중첩되는 다수 목적지에 대해서는 Packet-Based 방식보다 공평성이 떨어지기는 하지만, Destination-Based 방식도  로드 밸런싱 효과가 있다("다중경로 라우팅(3) - 로드 밸런싱" 참조).

다중경로 라우팅시에 로드 밸런싱을 위해 Destination-Based 방식과 Packet-Based 방식중에서 하나를 선택할 수 있음을 "다중경로 라우팅(3) - 로드 밸런싱"에서 살펴보았다. 이 두 가지 방식이 실제로 어떤 차이점을 보여주는지 예제망을 통해 살펴보기로 하자. 먼저, 트래픽 플로우들의 목적지가 동일한 경우이다.
다음은 10개의 트래픽 플로우가 하나의 목적지 노드로 향하는 경우의 예제망 구조이다("다중경로 라우팅(1) - ECMP"의 예제망에서 확장). Client 노드에서 Server 노드로 향하는 트래픽 플로우는 10개가 겹쳐진 것이며,
100초마다 하나씩 트래픽을 발생시키도록 설정하였다(이는 트래픽 증가에 따른 로드 밸런싱 효과를 관찰하기 위해서이다).

로드 밸런싱이 Destination-Based 방식인 경우와 Packet-Based 방식인 경우에 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 비교해보면 다음 그림과 같다. Destination-Based 방식인 경우 각 트래픽 플로우는 하나의 라우팅 경로를 통해서만 전달되며, 목적지가 같으므로 동일한 경로(이 예제에서는 R1 -> R2 -> R4)가 사용되는 것을 알 수 있다. Packet-Based 방식인 경우 각 트래픽 플로우는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)되는 것을 알 수 있다.

R1 -> R2 링크와 R1 -> R3 링크의 트래픽유통량을 비교해보면 다음 그림과 같다.

Destination-Based 방식인 경우 모든 트래픽이 같은 경로(이 예제에서는 R1 -> R3 링크)를 통해 전달된 반면, Packet-Based 방식인 경우 다중 경로(R1 -> R2, R1 -> R3 링크)로 트래픽이 균등하게 분산되었음을 확인할 수 있다. 즉, 동일 목적지에 대해서는 Destination-Based 방식은 로드 밸런싱 효과가 전혀 없으며, Packet-Based 방식만이 효과가 있다("다중경로 라우팅(3) - 로드 밸런싱" 참조).

다중경로 라우팅을 통한 로드 밸런싱(부하 분산)을 Riverbed(OPNET) Modeler로도 시뮬레이션할 수 있음은 "다중경로 라우팅(1) - ECMP"에서 살펴보았다. 로드 밸런싱 방법은 Load Balancing Options 속성값을 설정하여 변경할 수 있으며, 선택 가능한 값은 다음과 같다.

- Destination-Based: Load Balancing Options의 기본값이며, 목적지 주소별로 경로를 배분하는 방법이다. Packet reordering 등 다중 경로 사용으로 인한 부작용이 없는 장점이 있지만, 로드 밸런싱 효과가 확실히 보장되지 않는 단점이 있다.

- Packet-Based: 패킷별로 경로를 배분하는 방법이다. 로드 밸런싱 효과가 확실하다는 장점이 있지만("다중경로 라우팅(1) - ECMP"에서 사용한 예제가 로드 밸런싱 효과를 쉽게 관찰하기 위하여 Packet-Based로 시험한 것이다), packet redordering 등의 부작용이 발생하는 단점이 있다.

ECMP가 사용되면 다중 경로를 통해 트래픽이 분산됨은 "다중경로 라우팅(1) - ECMP"에서 트래픽 유통량을 통해 살펴보았다. 여기에서는 이러한 경우에 라우팅 테이블이 어떻게 구성되는지를 확인해 보도록 하자. 사용된 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

ECMP가 사용되지 않은 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다("라우팅 경로 확인하기" 참조). Server 노드가 속한 서브네트워크로 향하는 경로가 하나 뿐인 것을 알 수 있다.

ECMP가 사용되는 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. Server 노드가 속한 서브네트워크로 향하는 경로가 두 개인 것을 알 수 있다.

ECMP(Equal-Cost Multi-Path)는 동일한 비용(Cost)을 가지는 여러 개의 경로들을 동시에 라우팅에 사용하는 것[1, 2]이며, Riverbed Modeler(OPNET)에도 구현되어 있다. 다중경로를 사용하는 주된 이유중 하나는 트래픽 부하 분산(로드 밸런싱)때문이다. 다음 그림은 ECMP 라우팅 동작을 확인하기 위하여, "라우터 배치 순서와 라우팅 경로 선정"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다.

ECMP가 사용되지 않은 경우와 사용된 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. ECMP가 사용되지 않은 경우에는 하나의 경로만 사용되었지만, ECMP가 사용되는 경우에는 2개의 경로가 모두 사용되었음을 쉽게 관찰할 수 있다.

트래픽이 실제로 균등하게 분산되었음을 확인하기 위하여 R1 -> R2 링크와, R1 -> R3 링크의 트래픽 유통량을 살펴보면 다음 그림과 같다.

ECMP가 사용되지 않은 경우에는 R1 -> R2 링크로 모든 트래픽이 전달되었지만, ECMP가 사용되는 경우에는 R1 -> R2, R1 -> R3 링크로 트래픽이 분산되었음을 확인할 수 있다.

[1] RFC 2991, "Multipath Issues in Unicast and Multicast Next-Hop Selection", IETF, Nov. 2000.
[2] RFC 2992, "Analysis of an Equal-Cost Multi-Path Algorithm", IETF, Nov. 2000.

Riverbed(OPNET) Modeler IP 모델은 링크 트래픽 부하에 대한 기록을 내부적으로 가지고 있으며, 이렇게 기록된 정보는 IGRP나 EIGRP에서 메트릭을 계산하는데 사용된다.
링크 트래픽 부하에 대한 정보는 두 가지 형태로 기록되는데, 하나는 bit 단위고 다른 하나는 bps 단위이다. 주의해야 할 점은, 이 부하의 측정 주기는 시뮬레이션 시작시점부터 해당 시점까지의 전기간이라는 것이다. 즉, 해당 순간의 링크 부하 또는 링크 사용률에 기반하여 어떠한 동작을 수행하는 목적에 사용하기에는 적합한 정보가 아니며, 별도의 정보를 따로 기록하여 사용하는 편이 낫다.

다음 그림은 동일한 토폴로지상에 배치된 두 단말사이의 라우팅 경로를 비교하여 나타낸 것이다. 그런데, 사용된 모델 및 파라미터가 모두 동일한데도 불구하고, 두 시나리오에서 선정된 라우팅 경로가 서로 다른 것을 알 수 있다.

왜 이런 차이가 발생한 것일까? 그 이유는 두 시나리오에서 토폴로지를 그릴 때, 라우터의 배치 순서가 달랐기 때문이다. 시나리오1에서는 R2를 R3보다 먼저 배치하였고, 시나리오2에서는 R3를 R2보다 먼저 배치하였다. 먼저 배치되었다고 해서 라우팅 경로가 항상 해당 라우터 쪽으로 설정되는 것은 아니다. 다만, 라우팅 프로토콜이 동일한 시간에 동작한다면 먼저 생성(instancing)된 라우터의 라우팅 프로토콜 메시지가 먼저 발생하고(동일한 시간에 발생한 event들도 발생 순서에 따라 처리되는 것은 discrete event simulation의 특성이다), 이웃 라우터에도 먼저 도착하여 처리되므로 동일한 비용을 가지는 경로 들중에서는 우선적으로 선택되는 것이다.