Riverbed Modeler 18.9.0 버전이 지난 2월15일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.8.0 발표" 참조). 이번에도 공지가 없어서 배포된 줄도 몰랐네요. Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 3가지입니다.
- VLAN Model Enhancement - IEEE 802.1ah Support - WLAN Model Enhancement - IEEE 802.11s Support - TCP Model Enahcement - MPTCP IPv6 Support
VLAN 모델 개선 사항은 Provider Backbone Bridged Networks(IEEE 802.1ah)에 대한 지원입니다. 18.8.0 버전에서 VLAN 모델에 대한 업데이트가 시작되면서 향후 추가 구현이 예고("Riverbed Modeler 18.8.0 발표" 참조)되었던 부분들이 있었는데, Provider Backbone Bridged Networks(PBBNs)은 후속 버전에서 바로 반영되었네요. WLAN 모델 개선 사항은 Mesh networking(IEEE 802.11s)에 대한 지원입니다. 요즘 무선랜 Mesh 기능이 많이 사용되는 추세인데, Riverbed Modeler에서도 이제 지원되네요. 11a, 11b, 11e, 11g, 11p, 11n, 11ac 기술에 적용되었다고 합니다. TCP 모델에 대한 개선 사항은 MPTCP의 IPv6 지원입니다. MPTCP 자체는 18.7.1 버전("Riverbed Modeler 18.7.1 발표" 참조)에서 구현된 기능이고, 이제는 IPv6에서도 사용할 수 있게 되었다는 것입니다.
그 외에 버그 수정사항 4건중 1건으로 ICMP 모델에서 생성된 ping 패킷이 SITL 사용시 실제 패킷으로 제대로 변환되지 않는 문제가 수정되었다고 합니다. 나머지는 버그 수정사항 3건은 특별히 관심이 가는 내용이 아니라서 생략합니다.
다음은 어플리케이션 타이밍의 Duration은 200초, Inter-repetition Time은 300초이고 Repetition Pattern은 Serial일 때, Client로 노드로 전송되는 트래픽을 다시 보인 것이다.
반복되는 어플리케이션 실행(세션)이 이전 실행이 종료된후 300초의 Inter-repetition Time을 가지고 순차적으로 실행되는 것을 알 수 있다. 다음은 타이밍의 Duration은 200초, Inter-repetition Time은 300초이고 Repetition Pattern은 Concurrent일 때, Client로 노드로 전송되는 트래픽을 다시 보인 것이다.
반복되는 세션이 이전 세션의 실행 시작과 동시에 300초의 Inter-repetition Time을 가지고 실행되는 것을 알 수 있다.
"WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서는 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 환경(802.11b 11Mbps)에서 1,500Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자. 동일한 환경이므로 변조방식(CCK11)과 프로세싱 게인(0dB)은 기존의 분석과 동일하다. 1,500Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 1,500Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 192usec * 11Mbps(PLCP 오버헤드) / 8 = 1,792Bytes(14,336bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.
이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다. - BER이 2.2x10^-5 일 때: MAC 사용자 패킷 전달률 99.99%, 이 때의 SNR은 7.75dB이므로 최대 거리는 약 966M. - BER이 8.1x10^-5 일 때: MAC 사용자 패킷 전달률 92.78%, 이 때의 SNR은 7.25dB이므로 최대 거리는 약 1,024M. - BER이 1.4x10^-4 일 때: MAC 사용자 패킷 전달률 63.58%, 이 때의 SNR은 7.0dB이므로 최대 거리는 약 1,053M. - BER이 7.8x10^-4 일 때: MAC 사용자 패킷 전달률 0.01%, 이 때의 SNR은 6.25dB이므로 최대 거리는 약 1,149M.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate (bps)는 "11Mbps"로 설정한다. 트래픽은 1,500Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다. 966M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.99%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,024M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 92.78%)과는 미세한 차이가 있는 결과(전달률 약 93.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,053M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 63.58%)과는 미세한 차이가 있는 결과(전달률 약 65.25%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,149M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.01%)과는 미세한 차이가 있는 결과(전달률 약 0%)이나, 오차범위 내로 볼 수 있다.
종단 노드간에 다중경로(Multi-Path)가 존재하는 경우, 라우팅에서 유용하게 활용될 수 있음을 "다중경로 라우팅(1) - ECMP"와 "다중경로 라우팅(7) - UCMP"에서 살펴보았다. 그러면, 특정 링크 구간에 복수개의 링크가 존재하는 경우, 즉 다중링크(Multi-Link)도 라우팅에서 유용하게 활용될 수 있는지 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. 다중링크를 구성하기 위하여, R1 노드와 R2 노드간을 기존 링크와 동일한 대역폭의 링크로 추가 연결하였다.
시뮬레이션을 수행한 후 R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. "OSPF 라우팅 예제"에서의 결과와는 달리 R2 - R4 네트워크로 향하는 경로가 2개이며, 두 경로의 차이점은 R2 노드와 연결된 포트가 다른 것임(즉, 다중링크가 사용되고 있음)을 알 수 있다.
다중링크의 각 링크가 OSPF 라우팅 테이블에서 구분되어 인식되므로, 다중링크는 기존의 일반적인 다중경로와 동일하게 트래픽 부하를 분산시키는데 사용될 수 있다("다중경로 라우팅(1) - ECMP" 참조). 만약, 라우팅 프로토콜로 RIP가 사용되면, 다중링크의 각 링크가 라우팅 테이블에서 구분되어 인식될 수 없으므로 다중링크는 트래픽 부하를 분산시키는데 사용될 수 없다. 또한, OSPF가 사용되는 경우에도 다중링크의 대역폭이 서로 다르면 다중링크를 제대로 사용할 수 없다.
실제 OSPF 구현물에서는 네트워크 토폴로지 변경을 인지(즉, LSA 정보를 수신하거나 인터페이스 상태가 변경)하였을 때에도 라우팅을 위한 네트워크 토폴로지 정보(Short-path tree)를 즉시 재계산하지 않으며, 일정 시간 지연 혹은 간격을 가진 후에 재계산한다. 이 시간 지연 혹은 간격을 설정하는 방법은 제품 벤더에 따라 다르며, 다음 그림은 Riverbed(OPNET) Modeler OSPF 모델에서 제공하는 Shortest-path tree 재계산 조건 항목을 보인 것이다.
- Style: LSA Driven 방식과 Periodic 방식중에서 선택. 기본값은 LSA Driven. - Delay (seconds) : 네트워크 토폴로지 변경을 인지한 후 SPF 계산을 할 때까지의 지연 시간. - Hold Time (sedonds) : 이전 SPF 계산이후 다음 번 SPF 계산까지의 최소 간격. 따라서, 이 시간 간격보다 더 자주 SPF 계산이 일어나지는 않는다.
Fixed 모드 지터 버퍼 결과("VoIP 지터 버퍼(3) - Fixed 모드" 참조)와 Adaptive 모드 지터 버퍼의 결과("VoIP 지터 버퍼(4) - Adaptive 모드" 참조)를 비교해 보면, Adaptive 모드 지터 버퍼의 MOS 결과 값은 매우 낮다. 예를 들어 균등 분포 40ms의 네트워크 패킷 지연(시나리오3)에 대해서 60ms 크기의 Fixed 모드 지터 버퍼를 사용시 MOS 값은 약 4.2 정도인데 비해, Adaptive 모드 지터 버퍼 사용시 MOS 값은 약 3.2 정도에 불과하다.
얼핏 생각하면 Adaptive 모드는 네트워크 상태에 적응하며 계속 지터 버퍼의 크기를 변화시키므로 더 좋은 성능을 보여야 할 것 같은데, Riverbed(OPNET) Modeler 시뮬레이션 결과는 그렇지 않다. 무엇이 잘못된 것일까? 이는 시뮬레이션이 잘못되었기 때문이 아니며, 지터를 정확히 예측할 수 없기 때문에 발생하는 현상이다. 즉, Adaptive 모드에서는 현재 측정된 패킷 간격 정보로부터 앞으로 "발생할" 패킷 간격을 예측하여 지터 버퍼 크기를 변경한다. 따라서 이 예측이 틀리는 경우에는, 지터 버퍼 지연이나 지터 버퍼 패킷 손실에서 손해를 보게 된다. 현재의 IP 네트워크에서 향후에 발생할 지터를 정확히 예측한다는 것은 현실적으로 불가능한 일이다. Riverbed(OPNET) Modeler에 구현된 지터 버퍼의 Adaptive 모드 역시 예측이 틀리는 경우가 발생하며, 이러한 이유로 지터의 범위가 커지면 Adaptive 모드 사용시 MOS 값도 상당히 낮아진다.
수신 버퍼 크기는 최소 크기로부터 BDP(Bandwidth Delay Product) 크기에 도달할 때까지 일정 단위로 증가된다. 단, 링크의 대역폭 별(1Mbps이하, 100Mbps이하, 100Mbps 초과)로 지정된 최대 크기보다 커질 수는 없다. 수신 버퍼 자동 계산 모드에서 버퍼 크기 증가는 RTT 시간동안 수신한 트래픽 총량이 기준을 초과하였을 때만 이루어진다.
Riverbed(OPNET) Modeler IP 모델에서 TTL(Time-to-Live) 값 처리는 해당 패킷이 그 노드에서 사용되지 않고, 다른 노드로 포워딩된다는 것을 확인한 이후에 이루어진다. 다음 그림은 그 상관 관계를 개념적으로 표현한 것이다.
수신된 패킷은 먼저 해당 노드가 목적지인지 검사가 이루어진다("IP 패킷 목적지 검사" 참조). 만약 해당 노드가 목적지라면 패킷은 상위 계층으로 전달된다. 해당 노드가 목적지가 아니라면, TTL 값을 1만큼 감소시킨다. 감소된 TTL 값이 0이라면, 해당 패킷은 폐기된다. 감소된 TTL 값이 0이 아니라면 패킷은 이웃 노드와 연결된 인터페이스를 통해 포워딩된다.
Feasibility Condition은 DUAL 알고리즘의 일부로써, 루프를 방지하기 위한 것이다. 그런데, 사용자가 주의를 기울이지 않으면 이 기능으로 인한 결과는 혼란스러운 면이 있으므로, 결과 해석시 주의가 필요하다.
"다중경로 라우팅(8) - UCMP 라우팅 테이블"에서 EIGRP는 동일한 비용을 가지는 경로가 없을 때에도 다음 그림처럼 다중경로로 라우팅 테이블을 구성해줄 수 있음을 확인한 바 있다.
그런데, "다중경로 라우팅(8) - UCMP 라우팅 테이블"의 예제망에서 R1 <-> R3 링크의 대역폭과 R3 <-> R4 링크의 대역폭을 서로 바꾸고 시뮬레이션을 수행하면, 다음 그림처럼 라우팅 테이블에 다중경로가 구성되지 않는 것을 볼 수 있다.
얼핏 생각하면, R1 노드에서 Server 노드로 향하는 경로의 전체 Metric 값에는 변화가 없으므로(R1 <-> R3 링크와 R3 <-> R4 링크의 대역폭을 서로 바꾸기만 하였으므로) 이전의 예제와 동일한 라우팅 테이블이 구성되어야 할 것처럼 생각된다. 하지만, 시뮬레이션 결과는 예상(?)과는 다르며, 이러한 차이가 발생한 원인은 Feasibility Condition 때문이다. 즉, EIGRP에서는 전체 경로의 Metric이 동일하더라도 Next-Hop 라우터에서 목적지까지의 경로 Metric 값이 어떻게 변화하는가에 따라 다중경로가 라우팅 테이블에 사용될 수도 있고 안될 수도 있다.
