네트워크 시뮬레이션 공방

"다중경로 라우팅(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초로 훨씬 많은 시간이 소요되었음을 알 수 있다.

Riverbed(OPNET) Modeler TCP 모델에서는 TCP 가속  기능을 제공하는데, 여기에는 TAO(TCP Accelerated Open)와 Piggyback FIN이 포함된다(WAN 가속에서도 TCP 가속이라는 표현을 사용하지만, 이것과는 완전히 다른 개념이다). 다음 그림은 Riverbed(OPNET) Modeler TCP 가속 속성 설정창을 보인 것이다.

각 속성항목의 용도는 다음과 같다.
- Accelerated Open : TAO 사용 여부를 지정. 기본값은 Disabled.
- Send FIN with Data : Piggyback FIN 사용 여부를 지정. 기본값은 Disabled.

Adaptive 모드 지터 버퍼는 고정 크기의 지터 버퍼를 사용하지 않고, 현재의 VoIP 패킷 간격에 맞추어 지터 버퍼의 크기를 계속 변경해가면서 사용하는 방식이다. Fixed 모드 지터 버퍼와의 비교를 위해서 동일한 시험망("VoIP 지터 버퍼(3) - Fixed 모드" 참조)에서 지터 버퍼 설정만 변경하여 Adaptive 모드 지터 버퍼의 효과를 확인해보았다.
음성 코덱은 G.711을 사용하였으며, 네트워크에서의 패킷 지연은 균등(uniform) 분포 함수를 사용하여 None(시나리오 1), 20ms(시나리오 2), 40ms(시나리오 3), 60ms(시나리오 4) 범위로 설정하였다.
Adaptive 모드 지터 버퍼의 파라미터는 "Minimum Value: Default", "Maximum Value: 80", "Sliding Mean Coefficient: 0.5", "Buffer Sizing Interval: 100"으로 설정하였다.

다음 그림은 각 시나리오별로 지터 버퍼 크기를 관찰한 결과이다. x축은 시간이며, y축은 측정된 지터 버퍼 크기이다. 지터 버퍼의 크기가 시간에 따라 계속 변하고 있으며, 네트워크에서의 패킷 지연 변화폭이 증가할수록(즉, 지터가 커질수록) 평균적인 지터 버퍼 크기 역시 증가하고 있는 것을 알 수 있다.

다음 그림은 각 시나리오별 MOS 값 결과를 나타낸 것이다. x축은 시간이며, y축은 측정된 MOS 값이다. 모든 시나리오에 대해서 동일한 지터 버퍼를 사용하고 있음에도 불구하고 Adaptive 모드 지터 버퍼 사용시에는 최악의 경우(시나리오 3, 4)에도 일정 수준의 MOS 값이 유지되는 것을 알 수 있다.

그런데, Fixed 모드 지터 버퍼의 결과("VoIP 지터 버퍼(3) - Fixed 모드" 참조)와 비교해보면, Adaptive 모드 지터 버퍼의 MOS 결과 값은 매우 낮다. 그 원인에 대해서는 이후에 별도의 글에서 다루도록 하겠다.

"OSPF 메시지(3) - Encapsulation"에서 살펴본 것처럼, OSPF Hello 메시지는 멀티캐스트 주소를 사용하여 전달된다. 하지만, 이 멀티캐스트 패킷들은 단일 홉내에서만 사용되며, 다음 홉으로는 전달되지 않는다.
시뮬레이션을 통해 이를 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 시험망 구조인데, R1 노드에서 R2 노드로 보내는 Hello Interval을 1초로 수정한 것이다.

다음 그림은 수정된 시험망 시나리오에서의 R1 --> R2 링크 트래픽 유통량을 기존의 시험망 시나리오와 비교한 것이다. 약 10배 정도로 트래픽이 증가하였으며, 이는 Hello 메시지 발생량이 10배로 증가(Hello Interval이 10초에서 1초로 축소됨)한 것을 고려하면 타당한 결과인다.

이제 R2 --> R4 링크의 트래픽 유통량을 두 시나리오간에 비교해보면 다음 그림과 같다. 전반적인 트래픽 유통량은 두  시나리오간에 동일함을 알 수 있으며, 이는 R1 노드에서 R2 노드 로의 Hello 메시지 발생량 증가가 R2 노드에서 R4 노드로의 Hello 메시지 발생량에 영향을 미치지 않았음을 의미한다.

즉, Hello 메시지는 다중 홉 너머로 Flooding되지 않는다.

디맨드 모델에 의한 백그라운드 트래픽 부하가 허브와 연결된 링크에서는 정상적으로 관찰되지 않는 제약점이 있다는 것은 "Background Traffic의 영향(9) Demand Model과 허브"에서 살펴보았다. 하지만, 이 경우에는 중간 경유 링크 구간에서만 트래픽이 관찰되지 않는 것이었으므로 상대적으로 오해가 소지가 적었다. 이번에는 허브에 단말들이 연결되어 있는 경우에 결과 해석상에 어떠한 주의점이 필요한지 살펴보기로 하자.
다음은 허브 노드를 지나는 트래픽 효과를 관찰하기 위하여 구성한 예제망이다. "Background Traffic의 영향(9) Demand Model과 허브"에서 사용한 예제망을 변경한 것으로, R4 노드를 삭제하고 Server 노드와 동일한 단말 노드를 추가하고 Hub 노드에 연결해주었다.

시뮬레이션을 수행한 후 Client 노드에서 Server 노드로 향하는 디맨드 트래픽의 라우팅 경로를 확인해보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조) 그런데, 라우팅 경로가 표시되기는 하지만, 일부 오류가 있는 것으로 표현되는 것을 알 수 있다. 또 표시된 라우팅 경로도 우리가 원한 Server 노드로뿐만 아니라 Server_2 노드로의 경로도 포함되어 있다.

이 시험망에서 라우팅 경로에 오류가 있는 것처럼 보이는 것은 연결된 모드 링크로 트래픽을 복사/전송하는 허브 노드의 특성때문이며, 트래픽이 백그라운드 모드이기 때문은 아니다. 즉, 디맨드 트래픽 모델을 이더넷 허브 노드가 포함된 시험망에 사용했을 때에는 디맨드 트래픽에 대한 정확한 라우팅 경로 확인이 어렵다.(실제 장비의 특성때문이므로, Riverbed Modeler(OPNET)의 버그라고 볼 수는 없을 것 같다.)

쿼드런트(Quadrant)는 GRP("GRP 개요" 참조)에서 가장 핵심적인 개념이며, 대상 노드의 위치 정보에 대한 측정 단위라고 볼 수 있다. 즉, 같은 쿼드런트에 속한 노드인지의 여부에 따라 저장하는 위치 정보의 의미가 달라진다.

1) 동일한 쿼드런트에 속한 노드 : 대상 노드의 좌표값을 위치 정보로 사용
2) 동일한 쿼드런트에 속하지 않은 노드 : 대상 노드가 속한 쿼드런트의 좌표값을 위치 정보로 사용

다음 그림은 이러한 개념을 그림으로 표현한 것이다. 1번 노드를 기준으로 살펴보았을 때, 2번 노드는 1번 노드와 동일한 쿼드런트 A에 속한 노드이므로 2번 노드의 직접 좌표값이 저장된다. 3번 노드와 4번 노드는 1번 노드와 달리 쿼드런트 B에 속한 노드이므로 3번 노드와 4번 노드의 직접 좌표값 대신 쿼드런트 B의 좌표값이 저장된다.

다만, 실제로는 쿼드런트가 계층적으로 존재하므로 좀 더 복잡한 양상을 보이게 된다. 쿼드런트의 계층적 개념에 대해서는 별도의 글에서 다시 살펴보도록 하겠다.

AODV에서는 이웃을 찾아내고 이웃과의 관계를 유지하기 위해서 Route Request(RREQ), Route Reply(RREP), Route Error(RERR), Route Reply Acknowledgment(RREP-ACK), Hello 메시지를 사용한다. 다음 그림은 Riverbed(OPNET) Modeler AODV 모델에서 사용하는 패킷 포맷과 Options 필드에 실리는 정보를 나타낸 것이다.

그림에서 알수 있듯이, 각 메시지 별로 다른 패킷을 사용하지 않고 하나의 공통 AODV 패킷 포맷을 사용한다. 대신 각 메시시별로 Options 필드에 실리는 구조체의 내용을 달리하여 서로 다른 메시지 정보를 수용한다.
AODV 패킷 포맷임에도 UDP 헤더 필드가 포함되어 있는 것은 "AODV 프로토콜 계층 구조"에서 설명하였듯이 AODV 메시지가 UDP를 사용함[1]에도 불구하고, AODV 프로세스 모델이 UDP 모듈 상위가 아닌 IP 모듈에 직접 구현되어 있기 때문이다.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.

EIGRP는 bandwidth, load, delay, reliability 정보를 종합적으로 사용하여 Metric을 계산("EIGRP 메트릭" 참조)할 수 있도록 개발되었지만, 실제로는 대부분의 경우에 있어 load나 reliablity 항목은 사용되지 못하고 bandwidth와 delay 항목만이 사용된다[1].

형식상으로는 delay 항목이 추가로 사용되는 것만으로도 링크의 대역폭(bandwidth) 정보만을 사용하여 cost를 계산하는 OSPF("OSPF에서의 링크 비용" 참조)와는 차별화되어 보이기도 한다. 하지만, 여기에서의 delay는 인터페이스 전송 속도에 의해 지정[2]되는 것이므로, 실제로는 거의 동일하다.
"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 EIGRP로 변경하여 EIGRP의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 EIGRP에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 89,344, R4 - Server 네트워크에 대한 Metric은 91,904임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP("다중경로 라우팅(1) - ECMP" 참조) 때문이다.)
"EIGRP 메트릭"에서 설명하였듯이 EIGRP는 bandwidth, load, delay, reliability, mtu 정보로부터 계산된 값을 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크 2개로 구성된 경로의 Metric은 89,344, DS3(44.746Mbps) 링크 2개와 Fast Ethernet(100Mbps) 링크 1개로 구성된 경로의 Metric은 91,904로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 89,344가 되며, R1-> R2-> R4 ->(Server) 경로의 Metric은 91,904가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R2 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R2 -> R4 경로, 또는 R1 -> R3 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 EIGRP의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번째 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 91,904임을 확인할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R2 -> R4)인 것을 알 수 있다.

즉, 기본적으로 EIGRP는 경로의 bandwidth와 delay 항목 정보로부터 계산된 Metric을 기반으로 라우팅 경로를 선정하며, Metric이 더 작은 경로가 존재하면 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다. 따라서, EIGRP에 의해 선정된 경로는 OSPF에 의해 선정된 경로와 동일("OSPF 라우팅 예제" 참조)한 경우가 많다.

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

[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt

Riverbed(OPNET) Modeler TCP 모델은 시뮬레이션에서 사용된 TCP 연결들을 사용자가 확인할 수 있도록 화면상에 정보를 출력하는 기능을 제공한다. 이러한 기능은 실제 TCP 구현물에서는 제공되지 않는 것으로, 시뮬레이터이기에 가능한 부분이다. (굳이 비교 대상을 찾자면 Windows나 Linux에서 제공하는 netstat 명령어와 유사한 면이 있다.) 다음 그림은 사용자가 TCP 연결 정보 출력 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

"TCP Windows Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 사용하여 시뮬레이션을 수행한 후, 화면에 출력되는 TCP 연결 정보를 살펴보면 다음과 같다.

FTP 연결(포트 20번 사용)이 100.0초에 설정되어 시뮬레이션이 끝날때까지 사용된 것을 쉽게 확인할 수 있다.

어제(6월29일) Riverbed Modeler 18.6.1 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.6.0 발표" 참조). Release note에는 6월 26일로 표기되어 있습니다만, 공식적인 업데이트 발표는 어제 있었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 주요 내용은 기존 모델들에 대한 기능 업데이트입니다.

- SDN Model Enhancements
- OSPF Model Enhancements
- WLAN Model Enhancements

SDN(Software-Defined Networking) 모델은 직전의 Riverbed Modeler 18.6.0 버전("Riverbed Modeler 18.6.0 발표" 참조)에서 추가된 모델인데, 이번에도 새로운 기능들이 다수 반영되었습니다. Port status monotoring and reporting, Recovery of TCP conneciton, Seding "Echo Request" message, Version negotiation 등의 기능입니다.
OSPF 모델의 개선 사항은 LSA의 주기적 재생성과 유효시간이 경과한 LSA 정보의 삭제입니다. 이 기능은 주로 SITL 모듈을 통한 실장비와의 연동시 필요한 것이며, 이 기능이 활성화되기 위해서는 OSPF simulation efficiecny 옵션이 꺼져 있어야 합니다.
WLAN 모델의 개선 사항은 Block-ACK 메커니즘을 위한 "next expected sequence number" 기능이 반영되었다는 것입니다. 이 기능은 IEEE 802.11 표준의 2012년 버전에서 소개된 것인데, 이제 Riverbed Modeler에도 구현되었다고 합니다.

이외에 버그 수정도 4건 포함되었습니다만, 현재 관심이 가는 내용이 아니라서 생략합니다.