Este documento resume los resultados de dos experiencias prácticas sobre diseño y evaluación de redes usando OPNET. La primera experiencia analiza el impacto del tráfico de red en los tiempos de respuesta HTTP y uso de CPU. La segunda experiencia compara el tráfico HTTP y de base de datos con diferentes configuraciones de firewall y VPN.

1. 1
Diseño y Evaluación de Redes usando OPNET
Miguel Ruiz M.
miguel.ruiz.13@sansano.usm.cl
Cristian Ulloa F.
cristian.ulloa.13@sansano.usm.cl
Santiago, 17 de Junio de 2013
Resumen
Esta experiencia práctica consta de dos partes: en el primer laboratorio
se abordan los conceptos básicos de redes para implementar una LAN,
al mismo tiempo que se tienen en consideración usuarios, servicios y
ubicación de los nodos de la red.
El segundo laboratorio está asociado a la implementación de firewalls y
VPNs, evaluando su rol dentro del contexto de seguridad en redes
públicas compartidas, como lo es Internet.
Palabras claves: diseño, evaluación, simulación, redes, opnet
1. Introducción
En las telecomunicaciones existen metodologías las cuales nos indican las pautas que se deben de seguir o qué
procesos se deben de cumplir para implementar una infraestructura de redes. Dada la naturaleza teórica de
estos modelos, existe una gran posibilidad que la implementación real tenga muchas diferencias con lo
planificado y esto se traduzca en retrasos o incluso fracasos de proyectos. Afortunadamente hoy en día
contamos con herramientas adicionales para aminorar el riesgo, siendo una de ellas la simulación de escenarios
posibles.
Desde hace algún tiempo los simuladores (en cualquiera de los campos ingeniería, física, biología, etc.) han
ayudado a las organizaciones a la toma de decisiones para saber posibles comportamientos, utilizando equipos
informáticos son de gran aplicación en el ámbito de la ingeniería. En ella se puede ver características
propiedades, comportamientos, etc. El propósito de un simulador es plasmar en una herramienta de software
alguna realidad, para de esta manera los resultados obtenidos explotarlos de alguna manera.
En el campo de las redes de telecomunicaciones existen herramientas con el propósito de diseñar redes, simular
datos y analizarlos. Tal es el caso de OPNET, que proporciona un entorno virtual de red que modela el
comportamiento de una red por completo, incluyendo sus pasarelas (routers), conmutadores (switches),
protocolos, servidores y aplicaciones en red.
OPNET es de gran utilidad ya que permite diagnosticar problemas de una forma eficiente, validar cambios en la
red antes de implementarlos y prever el comportamiento de la red ante futuros escenarios como crecimiento de
tráfico, fallos de red, entre otros beneficios.

2. 2. Detalles de la experiencia
A continuación se presentan los resultados obtenidos en el desarrollo de las experiencias.
2.1 Experiencia 1
Tiempo utilizado: 4 Hrs.
1) Al estudiar los tiempos de respuesta promedio para solicitudes HTTP en condiciones normales de tráfico de
red (Figura 1, valor azul), podemos mencionar que los resultados no superan los 0.02 segundos, y
transcurrido el minuto 7 de simulación, los valores
de la experiencia.
Al aumentar el tráfico en la red (Figura 1
observa que el tiempo de respuesta promedio crece
ligeramente, con valores que oscilan entre 0.02 y 0.035
segundos aproximadamente (el valor inicial de este
tramo es el promedio del escenario sin tráfico). Las
respuestas toman más del doble de tiempo en recorrer
la red, lo que representa una degradación de
rendimiento superior al 100%.
Podemos concluir que cualquier incre
de red es directamente proporcional al aumento en el
tiempo promedio de respuesta de las solicitudes HTTP.
Otro ítem que se analizó fue el uso promedio de CPU
para un servidor Web (Figura 2). En condiciones de
tráfico normales (azul), el uso de CPU no sobrepasa el
0.25%. Si el tráfico de red se incrementa (rojo)
observamos un menor uso de CPU, con un promedio
cercano al 0.23%.
Figura 2 - Uso de CPU en Servidor Web
Fuente: OPNET
2. Detalles de la experiencia
A continuación se presentan los resultados obtenidos en el desarrollo de las experiencias.
Al estudiar los tiempos de respuesta promedio para solicitudes HTTP en condiciones normales de tráfico de
1, valor azul), podemos mencionar que los resultados no superan los 0.02 segundos, y
transcurrido el minuto 7 de simulación, los valores se estabilizan y permanecen casi constantes hasta el fin
Figura 1, valor rojo) se
observa que el tiempo de respuesta promedio crece
ligeramente, con valores que oscilan entre 0.02 y 0.035
ximadamente (el valor inicial de este
tramo es el promedio del escenario sin tráfico). Las
respuestas toman más del doble de tiempo en recorrer
la red, lo que representa una degradación de
Podemos concluir que cualquier incremento en el tráfico
de red es directamente proporcional al aumento en el
tiempo promedio de respuesta de las solicitudes HTTP.
Otro ítem que se analizó fue el uso promedio de CPU
). En condiciones de
tráfico normales (azul), el uso de CPU no sobrepasa el
0.25%. Si el tráfico de red se incrementa (rojo)
de CPU, con un promedio
Podemos inferir que esta leve variación obedece al
hecho que en una red sin tráfico, los paquetes recorren
más rápido la red y las solicitudes se encolan más
rápido en el servidor web
recursos para atender dichos
En la Figura 3 podemos observar que el ratio promedio
de paquetes HTTP enviados es cercano a 4 por
segundo en una red saturada; en condiciones normales
de red este valor se incrementa ligeramente (4,25
paquetes/segundo).
Figura 1 - Tiempo promedio de respuesta para solicitudes HTTP
en segundos.
en Servidor Web (% Promedio).
2
A continuación se presentan los resultados obtenidos en el desarrollo de las experiencias.
Al estudiar los tiempos de respuesta promedio para solicitudes HTTP en condiciones normales de tráfico de
1, valor azul), podemos mencionar que los resultados no superan los 0.02 segundos, y
se estabilizan y permanecen casi constantes hasta el fin
Podemos inferir que esta leve variación obedece al
hecho que en una red sin tráfico, los paquetes recorren
más rápido la red y las solicitudes se encolan más
rápido en el servidor web, con mayor asignación de
dichos requerimientos.
podemos observar que el ratio promedio
de paquetes HTTP enviados es cercano a 4 por
segundo en una red saturada; en condiciones normales
de red este valor se incrementa ligeramente (4,25
Tiempo promedio de respuesta para solicitudes HTTP
. Fuente: OPNET

3. 2) Al realizar las pruebas con los escenarios de red con
y sin carga, se puede establecer que el uso promedio de
CPU fue mayor para el escenario de red sin carga
(Figura 6). El retardo en la transmisión de paquetes es
menor, por lo que las peticiones llegan más rápido
muchas se encolarán en el lado del servidor, que
mostrará tiempos de inactividad de CPU menores.
Para el caso del escenario de red con carga, el retardo
en recibir los paquetes por parte del servidor
tiene “tiempo” suficiente para responder las solicitudes
sin mayor esfuerzo (incremento en el uso promedio de
CPU).
Figura 3 - Tráfico HTTP (solicitudes/sec). Fuente: OPNET
Figura 4 - Tiempo promedio (seg.) para tráfico HTTP
enviado. Fuente: OPNET
Dado que la infraestructura
expedito y no se ocupa al
el cliente HTTP y la validación del estado de los
paquetes HTTP son más rápidas. Esto permite al Web
Server enviar más paquetes por unidad de tiempo.
También podemos concluir que el servidor Web es
capaz de procesar una mayor ca
por segundo a menor carga en la red
El último elemento a analizar ser
Ethernet (Figura 5). Con un tráfico normal de red
niveles de latencia se estabilizan tras los 10 minutos y
no superan los 0,00100 segundos.
mayor congestión, podemos observar que la latencia
se incrementa en un 100%, es decir, se
directa relación entre la latencia y el
las pruebas con los escenarios de red con
y sin carga, se puede establecer que el uso promedio de
CPU fue mayor para el escenario de red sin carga
l retardo en la transmisión de paquetes es
menor, por lo que las peticiones llegan más rápido y
muchas se encolarán en el lado del servidor, que
mostrará tiempos de inactividad de CPU menores.
Para el caso del escenario de red con carga, el retardo
en recibir los paquetes por parte del servidor implica que
tiene “tiempo” suficiente para responder las solicitudes
sin mayor esfuerzo (incremento en el uso promedio de
(solicitudes/sec). Fuente: OPNET
Tiempo promedio (seg.) para tráfico HTTP
enviado. Fuente: OPNET
Figura 5 – Demora a nivel Ethernet (segundos).
Fuente: OPNET
Figura 6 - Uso de CPU (% Promedio). Fuente: OPNET
3
Dado que la infraestructura posee un tráfico más
100%, la comunicación con
el cliente HTTP y la validación del estado de los
paquetes HTTP son más rápidas. Esto permite al Web
Server enviar más paquetes por unidad de tiempo.
También podemos concluir que el servidor Web es
capaz de procesar una mayor cantidad de solicitudes
por segundo a menor carga en la red (Figura 4).
último elemento a analizar será la latencia a nivel
Con un tráfico normal de red, los
encia se estabilizan tras los 10 minutos y
no superan los 0,00100 segundos. En un escenario de
podemos observar que la latencia
rementa en un 100%, es decir, se comprueba la
directa relación entre la latencia y el tráfico de red.
Demora a nivel Ethernet (segundos).
Fuente: OPNET
Uso de CPU (% Promedio). Fuente: OPNET

4. 3) Estudiando el uso de CPU en los escenarios de red con carga: 3 servidores
los servicios (Figura 8), se puede apreciar que el servidor que ofrece todos los servicios presenta una carga
mucho mayor a nivel HTTP.
En el caso del uso de CPU del servidor de archivos, éste
presentó un peak pero posteriormente su consumo se
redujo en un 75% aprox. Una situación similar se observó
con el servidor de base de datos, ya que redujo su
consumo a medida que pasaba el tiempo de
cual permitió que el servidor concentre recursos en
atender las peticiones HTTP (incrementan el uso de CPU
al pasar el tiempo).
Se puede establecer que la suma de uso de CPU de los
tres servidores no es proporcional al uso de CPU del
servidor que entrega todos los servicios.
4) Al aumentar la velocidad de los enlaces
las paginas HTTP por segundo se reducen de forma considerable
segundo. A mayor velocidad de los enlaces, menor es el retardo de transmisión y por
global (Figura 10). Observamos una
mayor capacidad.
Figura 7 – Uso de CPU, Servidores Web, de
Figura 9 – Tiempo promedio para respuestas HTTP en
segundos. Fuente: OPNET
Estudiando el uso de CPU en los escenarios de red con carga: 3 servidores (Figura 7)
se puede apreciar que el servidor que ofrece todos los servicios presenta una carga
En el caso del uso de CPU del servidor de archivos, éste
presentó un peak pero posteriormente su consumo se
redujo en un 75% aprox. Una situación similar se observó
con el servidor de base de datos, ya que redujo su
consumo a medida que pasaba el tiempo de simulación, lo
cual permitió que el servidor concentre recursos en
incrementan el uso de CPU
de uso de CPU de los
tres servidores no es proporcional al uso de CPU del
idor que entrega todos los servicios.
l aumentar la velocidad de los enlaces (valores en rojo) se puede apreciar que los tiempos de respuestas de
e reducen de forma considerable (Figura 9), acercándose a valores de 0.01
segundo. A mayor velocidad de los enlaces, menor es el retardo de transmisión y por
. Observamos una mejora considerable en el desempeño de la red,
Figura 8 – Uso CPU todos los servicios
Fuente: OPNET
Uso de CPU, Servidores Web, de Archivos y Base de Datos Fuente: OPNET
Figura 10 - Demora promedio a nivel E
Fuente: OPNET
Tiempo promedio para respuestas HTTP en
segundos. Fuente: OPNET 4
(Figura 7) y 1 servidor con todos
se puede apreciar que el servidor que ofrece todos los servicios presenta una carga
se puede apreciar que los tiempos de respuestas de
acercándose a valores de 0.01
segundo. A mayor velocidad de los enlaces, menor es el retardo de transmisión y por consecuencia el retardo
desempeño de la red, al configurar enlaces de
CPU todos los servicios en una sola máquina.
Fuente: OPNET
Archivos y Base de Datos Fuente: OPNET
Demora promedio a nivel Ethernet en segundos.
Fuente: OPNET

5. 2.2 Experiencia 2
Tiempo utilizado: 18 hrs.
1) Los resultados expuestos a continuación hacen referencia al uso de un firewall que bloquea las
de DB, pero una VPN facilita el acceso entre Sales A y el Router D (detrás del firewall).
En la Figura 11, el firewall tiene bloqueado la conexión a la base de datos, por lo que no existe actividad
asociada. Si el acceso es mediante VPN, la regla del firewall es omitida y la actividad se realiza dentro de un
contexto normal. Algo muy distinto se observa e
la base de datos. Tampoco existe VPN configurad
eliminamos la restricción en el firewall.
2) A continuación realizaremos una comparación entre el tráfico HTTP
de los clientes (Sales A y B).
En el escenario de solo firewall, éste tiene bloqueado la conexión a la base de datos, por lo que no existe
actividad asociada desde Sales A y Sales B, impidiendo el tráfico hacia el servidor. En el escenario de firewall
más VPN para Sales A, el tráfico hacia la
conexión VPN permite que Sales A llegue al servidor de forma segura [5], sin embargo el tráfico para el caso del
escenario sin firewall y firewall con VPN es mayor y constante si se compara con
Figura 11 - Tráfico DB para Sales A
Fuente: OPNET
Figura 13
Los resultados expuestos a continuación hacen referencia al uso de un firewall que bloquea las
de DB, pero una VPN facilita el acceso entre Sales A y el Router D (detrás del firewall).
, el firewall tiene bloqueado la conexión a la base de datos, por lo que no existe actividad
acceso es mediante VPN, la regla del firewall es omitida y la actividad se realiza dentro de un
Algo muy distinto se observa en la Figura 12, ya que el firewall sigue bloqueando la conexión a
la base de datos. Tampoco existe VPN configurada para “Sales B”, por lo que la conexión sólo es factible si
eliminamos la restricción en el firewall.
A continuación realizaremos una comparación entre el tráfico HTTP y de base de datos, desde la perspectiva
escenario de solo firewall, éste tiene bloqueado la conexión a la base de datos, por lo que no existe
actividad asociada desde Sales A y Sales B, impidiendo el tráfico hacia el servidor. En el escenario de firewall
más VPN para Sales A, el tráfico hacia la base de datos resulta exitoso Sales A (
conexión VPN permite que Sales A llegue al servidor de forma segura [5], sin embargo el tráfico para el caso del
escenario sin firewall y firewall con VPN es mayor y constante si se compara con el al tráfico de HTTP.
Sales A en bytes/sec.
Fuente: OPNET
Figura 12 - Tráfico DB para Sales B en bytes/sec.
Fuente: OPNET
Figura 13 - Tráfico HTTP Sales B y Sales A. Fuente: OPNET
5
Los resultados expuestos a continuación hacen referencia al uso de un firewall que bloquea las conexiones
de DB, pero una VPN facilita el acceso entre Sales A y el Router D (detrás del firewall).
, el firewall tiene bloqueado la conexión a la base de datos, por lo que no existe actividad
acceso es mediante VPN, la regla del firewall es omitida y la actividad se realiza dentro de un
el firewall sigue bloqueando la conexión a
a para “Sales B”, por lo que la conexión sólo es factible si
y de base de datos, desde la perspectiva
escenario de solo firewall, éste tiene bloqueado la conexión a la base de datos, por lo que no existe
actividad asociada desde Sales A y Sales B, impidiendo el tráfico hacia el servidor. En el escenario de firewall
base de datos resulta exitoso Sales A (Figura 13) dado que la
conexión VPN permite que Sales A llegue al servidor de forma segura [5], sin embargo el tráfico para el caso del
el al tráfico de HTTP.
Tráfico DB para Sales B en bytes/sec.
OPNET

6. 3) El efecto del firewall y de la VPN con respecto al tiempo de respuesta
base de datos está representado por los siguientes gráficos.
Es posible establecer que la configurac
para los servicios HTTP y BD, dado que los paquetes además de ser
donde además son analizados (Figura 15
La diferencia de tiempos de respues
con firewall (Figura 16).
Figura 15 - Tiempo respuesta DB. Fuente: OPNET
Figura 14
El efecto del firewall y de la VPN con respecto al tiempo de respuesta para páginas HTTP y de consultas a la
base de datos está representado por los siguientes gráficos.
s posible establecer que la configuración de Firewall más VPN está asociada a un mayor
ado que los paquetes además de ser cifrados o descifrados
Figura 15)
La diferencia de tiempos de respuesta tanto para HTTP y DB es mucho menor si consideramos sólo el
Tiempo respuesta DB. Fuente: OPNET Figura 16 - Tiempo respuesta HTTP. Fuente: OPNET
Figura 14: Tráfico HTTP Sales B y Sales A. Fuente: OPNET
6
para páginas HTTP y de consultas a la
ión de Firewall más VPN está asociada a un mayor tiempo de respuesta
cifrados o descifrados pasan por el firewall
ta tanto para HTTP y DB es mucho menor si consideramos sólo el escenario
Tiempo respuesta HTTP. Fuente: OPNET

7. 4) Al escenario anterior, se solicita configurar la red para que las bases de datos en el servidor sólo sean
accesibles a Sales A y que los sitios webs sólo sean vistos por Sales B. Esta configuración se denomina
Q4_DB_Web.
La solución propuesta (Figura 17)
Router E y desde Sales B al Router
bloqueadas. El firewall 2 (FW_HTTP) sólo permite acceso entrante tipo HTTP mientras que el firewall 3
(FW_DB), es exclusivo para tráfico DB. Finalmente el R
Figura 1
Figura
Al escenario anterior, se solicita configurar la red para que las bases de datos en el servidor sólo sean
y que los sitios webs sólo sean vistos por Sales B. Esta configuración se denomina
) contempla en total 3 firewalls y 2 conexiones de VPN (desde Sales A al
C). En el firewall 1 (FW1), las conexiones asociadas a HTTP y DB han sido
bloqueadas. El firewall 2 (FW_HTTP) sólo permite acceso entrante tipo HTTP mientras que el firewall 3
para tráfico DB. Finalmente el Router D canaliza el tráfico hacia el servidor
Figura 18 - Configuración de VPN para Sales A y Sales B.
Fuente: OPNET
Figura 17 – Diagrama de red Q4_DB_Web. Fuente: OPNET
7
Al escenario anterior, se solicita configurar la red para que las bases de datos en el servidor sólo sean
y que los sitios webs sólo sean vistos por Sales B. Esta configuración se denomina
contempla en total 3 firewalls y 2 conexiones de VPN (desde Sales A al
C). En el firewall 1 (FW1), las conexiones asociadas a HTTP y DB han sido
bloqueadas. El firewall 2 (FW_HTTP) sólo permite acceso entrante tipo HTTP mientras que el firewall 3
co hacia el servidor.

8. Se puede apreciar en la Figura 19
Sales B es permitido solo para HTTP.
Figura 19 – Tráfico de DB y HTTP para Sales A y B. Fuente: OPNET
Figura 20 – Configuración de FW1, FW_DB y FW_HTTP.
como el tráfico desde Sales A es permitido solo para BD y el tráfico desde
Sales B es permitido solo para HTTP.
Tráfico de DB y HTTP para Sales A y B. Fuente: OPNET
Configuración de FW1, FW_DB y FW_HTTP. Fuente: OPNET
8
como el tráfico desde Sales A es permitido solo para BD y el tráfico desde

9. 9
3. Conclusiones
Al optimizar el diseño de una red buscamos maximizar su rendimiento, teniendo en cuenta las restricciones de
costos y los servicios que deben entregarse a diferentes tipos de usuarios. La optimización debe realizarse
periódicamente para asegurar los rendimientos esperados al mismo tiempo que se garantiza un uso correcto de
los recursos de red.
Se identificaron ciertas variables durante el estudio a nivel de red en cuanto al uso de Firewall y VPN’s que
afectan de gran forma al rendimiento de la red. Éstas corresponden a: velocidad del enlace, cercanía de nodos,
uso de la red, cantidad de servicios que se ofrecen en un host determinado, entre otros. Pudimos comprobar
empíricamente el funcionamiento de los firewalls y las VPN que permiten contar con servicios, comunicaciones y
redes seguras, aspecto muy relevante cuando se utilizan redes compartidas o públicas.
En lo que respecta a algunos resultados interesantes, el escenario que presenta mayor tiempo de respuesta
promedio es el que contempla Firewall y el uso de VPN. Esto ocurre porque la VPN PPTP [2] usa un canal de
control sobre TCP y un túnel GRC (Generic Routing Encapsulation) para encapsular los paquetes PPP. Los
paquetes de viajan cifrados y encapsulados mediante este túnel punto a punto, por lo que existe un overhead
asociado a estas prácticas.
Como vimos anteriormente, la incorporación de alguna tecnología para mejorar los niveles de seguridad a nivel
de red (Firewall o VPN) puede traer efectos secundarios en lo que respecta al rendimiento pero que fácilmente
se pueden detectar con simuladores como OPNET.
OPNET permite estudiar problemas de latencia o congestión, evaluar componentes y cómo abordar el diseño o
cambio de arquitectura de red, con resultados muy cercanos a los reales y sin una inversión considerable, más
allá del tiempo utilizado.
4. Referencias
[1] Network Simulation Experiments Manual. Morgan Kaufmann; 3rd edition (April 13, 2011)
[2] PPTP, Wikipedia.
[3] Compare VPN Protocols - PPTP vs L2TP vs OpenVPN
[4] OPNET Modeler Manual. OPNET (2004)
[5] Protocolo PPTP, RFC2637 .
[6] Virtual Private Networks, RFC2685.