네트워크 시뮬레이션 공방

다음 그림은 Riverbed(OPNET) Modeler ICMP 모델에서 사용하는 패킷 포맷과 fields 필드에 실리는 정보를 나타낸 것이다.

ip_icmp 패킷은 ICMP 메시지를 위한 컨테이너 패킷이며, 실제 ICMP 메시지는 echo_packet 필드에 실린다. 어떤 ICMP 메시지가 실려있는지는 fields 필드에 실려있는 IpT_Icmp_Packet_Fields 구조체의 message_type 정보를 통해 구분할 수 있다. 이러한 구조는 다양한 ICMP 메시지들을 공통으로 사용하는 단일 ICMP 패킷을 통해 처리하기 위한 의도인 것으로 생각된다.
하지만, "ip_icmp 프로세스 모델"에서 살펴보았듯이 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2]중 Echo/Echo Reply 메시지만 사용되므로, 실제적으로는 이 구조가 특별한 의미를 가지지 못하고 사용자들에게 혼란을 주는 면이 있다.

[1] RFC 792, "Internet Control Message Protocol", IETF, 1981. 
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Riverbed(OPNET) Modeler에서 ICMP 메시지에 대한 실질적인 처리는 ip_icmp 프로세스 모델에서 담당한다. 다음은 ip_icmp 프로세스 모델의 FSM을 보인 것이다.

request_gen 스테이트에서는 Echo Request 메시지(Ping 요청에 사용)를 생성시키는 기능을 담당한다.  request_rcvd 스테이트에서는 해당 노드가 목적지인 Echo Request 메시지에 대한 응답으로 Echo Reply 메시지를 생성하는 기능을 수행한다. reply_received 스테이트에서는 수신된 Echo Reply 메시지 정보를 처리하는 기능을 수행한다.
즉, Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2] 중 Echo Request와 Echo Reply 메시지만 처리된다.

[1] RFC 792, "Internet Control Message Protocol", IETF, 1981. 
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

ICMP 패킷 역시 다른 IP 패킷과 동일하게 목적지 검사("IP 패킷 목적지 검사" 참조)와 TTL 처리("IP 패킷 TTL 처리" 참조) 절차를 거친다. IP 패킷 목적지를 검사한 결과 해당 노드가 목적지이고 IP 패킷의 프로토콜 타입이 ICMP이면, 해당 IP 패킷은 ICMP 패킷을 담당하는 프로세스로 전달된다.
다름 그림은 이러한 ICMP 패킷에 대한 처리 절차를 나타낸 것이다.

"라우팅/포워딩 테이블 예제(1) - RIP"에서 살펴본 포워딩 테이블 정보는 Riverbed(OPNET) Modeler 내부에서 다음 그림과 같은 구조로 저장된다.

종단 노드간에 다중경로(Multi-Path)가 존재하는 경우, 라우팅에서 유용하게 활용될 수 있음을 "다중경로 라우팅(1) - ECMP"와 "다중경로 라우팅(7) - UCMP"에서 살펴보았다. 그러면, 특정 링크 구간에 복수개의 링크가 존재하는 경우, 즉 다중링크(Multi-Link)도 라우팅에서 유용하게 활용될 수 있는지 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. 다중링크를 구성하기 위하여, R1 노드와 R2 노드간을 기존 링크와 동일한 대역폭의 링크로 추가 연결하였다.

시뮬레이션을 수행한 후 R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. "OSPF 라우팅 예제"에서의 결과와는 달리 R2 - R4 네트워크로 향하는 경로가 2개이며, 두 경로의 차이점은 R2 노드와 연결된 포트가 다른 것임(즉, 다중링크가 사용되고 있음)을 알 수 있다.

다중링크의 각 링크가 OSPF 라우팅 테이블에서 구분되어 인식되므로, 다중링크는 기존의 일반적인 다중경로와 동일하게 트래픽 부하를 분산시키는데 사용될 수 있다("다중경로 라우팅(1) - ECMP" 참조).
만약, 라우팅 프로토콜로 RIP가 사용되면, 다중링크의 각 링크가 라우팅 테이블에서 구분되어 인식될 수 없으므로 다중링크는 트래픽 부하를 분산시키는데 사용될 수 없다. 또한, OSPF가 사용되는 경우에도 다중링크의 대역폭이 서로 다르면 다중링크를 제대로 사용할 수 없다.

Riverbed(OPNET) Modeler IP 모델에서 TTL(Time-to-Live) 값 처리는 해당 패킷이 그 노드에서 사용되지 않고, 다른 노드로 포워딩된다는 것을 확인한 이후에 이루어진다. 다음 그림은 그 상관 관계를 개념적으로 표현한 것이다.

수신된 패킷은 먼저 해당 노드가 목적지인지 검사가 이루어진다("IP 패킷 목적지 검사" 참조). 만약 해당 노드가 목적지라면 패킷은 상위 계층으로 전달된다. 해당 노드가 목적지가 아니라면, TTL 값을 1만큼 감소시킨다. 감소된 TTL 값이 0이라면, 해당 패킷은 폐기된다. 감소된 TTL 값이 0이 아니라면 패킷은 이웃 노드와 연결된 인터페이스를 통해 포워딩된다.

Riverbed(OPNET) Modeler IP 모델에서 수신된 패킷을 상위 계층으로 전달하는 경우는 기본적으로 패킷의 목적지가 해당 노드일 때, 브로드캐스트 패킷일 때, 해당 노드가 속한 멀티캐스트 그룹의 패킷일 때이다.
다음 그림은 그 판단 절차를 논리적으로 표현한 것이다.

EIGRP에서 제공하는 UCMP에서는 Traffic Share 속성을 추가로 사용하여 로드 밸런싱(부하 분산)을 더 세밀하게 조정할 수 있음을 "다중경로 라우팅(9) - UCMP에서의 로드 밸런싱"에서 살펴보았다. 이번에는 Traffic Share 방법으로 Balanced 방식을 선택했을 때와 Minium 방식을 선택했을 때 동작이 어떻게 차이나는지 예제를 통해 확인해보도록 하자.
다음 그림은 Traffic Share 방법간의 차이를 비교하기 위하여, "다중경로 라우팅(7) - UCMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. R1 노드와 R4 노드 사이에 R5 노드를 배치하고 R1 <-> R2, R2 <-> R4 링크와 동일한 대역폭을 가지는 링크로 연결하였다.

Traffic Share 방법이 Minimum 방식일 경우와 Balanced 방식일 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. Minimum 방식일 때에는 최소 metric 값을 가지는 2개의 경로만 사용되었지만, Balanced 방식일 때에는 최소 metric 비용을 가지는 경로를 포함하여 3개의 경로가 사용되었음을 확인할 수 있다.

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

Minimum 방식일 때에는 대역폭이 큰(즉, 최소 metric 값을 가지는) R1 -> R2 링크와 R1 -> R5 링크로만 트래픽이 분산되었지만, Balanced 방식일 때에는 대역폭이 작은(즉, 비용이 큰) R1 -> R3 링크로도 일부 트래픽이 분산되었음을 확인할 수 있다.

다중 경로 라우팅을 통한 로드 밸런싱(부하 분산)은 Load Balancing Options 속성값을 통해 조정할 수 있음을 "다중경로 라우팅(3) - 로드 밸런싱"에서 살펴보았다. EIGRP를 통한 UCMP("다중경로 라우팅(7) - UCMP" 참조)에서는 여기에 한가지 속성을 추가로 사용할 수 있는데, 그것은 Traffic Share이다. Traffic Share 속성의 선택 가능한 값은 다음과 같다.

- Balanced : Traffic Share 속성의 기본값이며, metric 값에 비례하여 다중 경로별로 트래픽을 분배하는 방법이다.

- Minimum : 최소 metric 값을 가지는 경로들에 대해서만 트래픽을 균등하게 분배하는 방법이다. 즉 Minimum은 metric 값이 동일한 경로가 존재하는 경우에만 로드 밸런싱 효과가 있으며, 다중 경로의 metric 값이 다른 경우에는 로드 밸런싱 효과는 없다.

Traffic Share 방법이 Balanced 방식인지 Minimum 방식인지는, Load Balancing Options이 Destination-Based
방식인지 Packet-Based 방식인지에 종속되지 않는다.

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

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

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