plataforma web para unificar la administracion de … · servers: los servidores poseen variadas...
TRANSCRIPT
UNIVERSIDAD TECNICA FEDERICO SANTA MARIADEPARTAMENTO DE ELECTRONICA
VALPARAISO - CHILE
“ PLATAFORMA WEB PARA UNIFICAR LAADMINISTRACION DE EQUIPOS Y SERVICIOS
DE REDES DE COMPUTADORES ”
DAVID SAMUEL RODRIGUEZ ALBORNOZ
MEMORIA DE TITULACION PARA OPTAR AL TITULO DE
INGENIERO CIVIL TELEMATICO.
Profesor Guıa: Agustın Gonzalez Valenzuela.
Profesor Correferente: Nicolas A. Jara Carvallo.
25 de Junio de 2012
A mis Padres por su incondicional apoyo, y su
forma de impartir una disciplina de oro.
A mis abuelos, el gran Tata Enrique, y mis
abuelitas Bili y Alola que no pudieron
estar f�sicamente, pero siempre las tengo a
mi lado, al igual que al legendario abuelito
Samuel. A mis padrinos, T�a Ten y T�o
Lucho, grandes exponentes de la familia.
A mis hermanos, que ayudaron a forjar mi
esp�ritu para no convertirme en una mala
oveja. A todos mis familiares que siempre
creyeron en mi capacidad. A mis
profesores, companeros, amigos, vecinos,
novia. Gracias a todos, hoy despego como
un hombre nuevo.
“PLATAFORMA WEB PARA UNIFICAR LAADMINISTRACION DE EQUIPOS Y SERVICIOS DE
REDES DE COMPUTADORES”
Memoria para optar al tıtulo de Ingeniero Civil Telematico
DAVID SAMUEL RODRIGUEZ ALBORNOZ
Profesor Guıa: Agustın Gonzalez Valenzuela
Profesor Correferente: Nicolas A. Jara Carvallo
25 de Junio de 2012
Resumen
La motivacion de este proyecto es resolver el problema que existe en materia de con-
figuracion de equipos y servicios de red, la falta de uniformidad. Al no existir un estandar
de configuracion, distintos fabricantes desarrollan soluciones de hardware que se configu-
ran de una forma especial y que llevan a precisar de manuales especiales o capacitaciones
para configurar equipos.
Este proyecto busca unificar la forma en que los administradores de red interactuan
con los equipos y servicios de redes a traves de una plataforma web unica que permita rea-
lizar operaciones de administracion y control independiente del fabricante de los equipos.
Ademas se busca que la plataforma sea facilmente escalable, a diferencia de las aplicacio-
nes actuales. Otro objetivo es lograr una arquitectura que permita admitir nuevos modulos
y tecnologıas independiente del lenguaje de programacion en la cual fueron desarrolladas.
Para lograr tal nivel de escalabilidad, la arquitectura se basa en un middleware orien-
tado a mensajes, que permite comunicacion asıncrona entre procesos que se encuentran
II
implementados en lenguajes distintos por medio de colas de mensajes. Gracias a esto,
se logra desligar al servidor web de las aplicaciones de bajo nivel, permitiendo que las
capacidades de la plataforma se basen en llamados a servicios. La comunicacion entre
servidor web y servicios se realiza mediante el estandar de mensajerıa SOAP. Los servicios
encargados del control de los
equipos de red utilizan un protocolo de comunicacion remota para ingresar los parame-
tros de configuracion enviados por el usuario terminal ( o administrador ) desde la interfaz
web.
Finalmente, se logro como resultado una solucion que, por medio de la interaccion
entre un usuario administrador y la pantalla de un computador personal o smarthphone,
logra configurar y administrar equipos de red de distintos fabricantes y modelos de forma
rapida y unificada por medio de una misma interfaz web.
Palabras Clave: Uniformidad, Plataforma web, middleware orientado a mensajes,
administrar equipos de red.
III
“WEB PLATFORM TO UNIFY THE ADMINISTRATION OFCOMPUTER NETWORKING DEVICES AND SERVICES”
Undergraduate thesis for the degree of Ingeniero Civil Telematico
DAVID SAMUEL RODRIGUEZ ALBORNOZ
Guide Professor: Agustın Gonzalez Valenzuela
Coreferential Professor: Nicolas A. Jara Carvallo
25 de Junio de 2012
Abstract
The motivation of this proyect is to solve the existing problem in terms of network
devices and services configuration, the lack of uniformity. Because there isn't a standard
configuration, different hardware manufacturers develop solutions that are configured by
special ways and require special manuals and capacitation to set up the devices.
This project seeks to unify the way that network administrators interact with network
devices and services through a single web platform that allows management operations
and control, independent of the manufacturer of the devices. It is also sought that the
platform be easily scalable, unlike current applications. Another objective is to achieve
an arquitecture that allows support for new modules and technologies independent of the
programming language in which they were developed.
To achieve this level of scalability, the architecture is based on a message-oriented
middleware, which enables asynchronous communication between processes that are im-
plemented in different languages through message queues. Thanks to this, it is possible to
decouple the web server from the low level applications, allowing the platform capabilities
be based on service calls. The communication between web server and services is done
through the standard SOAP messaging. The services responsible for monitoring network
devices use a remote communication protocol to enter the configuration parameters
IV
sended by the terminal user (or administrator) from the web interface.
Finally, a solution was achieved which, by means of the administrator user interaction
and personal computer or smartphone, manages to configure and administrate network
devices from different manufacturers and models quickly and unified through a single
web interface.
Keywords: Uniformity, web platform, message-oriented middleware, manage net-
work devices.
V
Glosario
WIND: Web Interface for Network Devices.
XML: Extensible Markup Language.
STOMP: Simple Text Oriented Message Protocol.
HTTP: Hyper Text Trasfer Protocol.
HTML: HyperText Markup Language.
TCP: Transmission Control Protocol.
PHP: PHP Hypertext Preprocessor.
SOAP: Simple Object Access Protocol.
JMS: Java Message Service.
ActiveMQ: Active Message Queue.
Servidor Apache: Servicio contenedor de documentos HTML para su entrega mediante
requerimientos realizados con el protocolo HTTP.
API: Application Programming Interface.
UML: Unified Modeling Language.
Indice general
Resumen II
Abstract IV
Glosario VI
1. Introduccion 11.1. Equipos que operan en una red de computadores . . . . . . . . . . . . . 11.2. Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. WIND - Web Interface for Network Devices . . . . . . . . . . . 51.3.2. Esquema basico de la solucion . . . . . . . . . . . . . . . . . . 6
2. Estado del Arte 82.1. Herramientas de administracion/control . . . . . . . . . . . . . . . . . . 8
2.1.1. Java Device Manager . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2. Cisco Security Device Manager (SDM) . . . . . . . . . . . . . . 9
2.2. Herramientas de administracion . . . . . . . . . . . . . . . . . . . . . . 10
3. Tecnologıas Involucradas 123.1. Servidor de aplicaciones HTTP Apache . . . . . . . . . . . . . . . . . . 123.2. Framework Jquery/JQueryUI/Jquery Mobile . . . . . . . . . . . . . . . . 133.3. Middlewares y servidores de aplicaciones . . . . . . . . . . . . . . . . . 13
3.3.1. ActiveMQ - Un Middleware Orientado a Mensajes . . . . . . . . 153.4. Bibliotecas y Frameworks necesarios . . . . . . . . . . . . . . . . . . . . 173.5. Virtualizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.1. Dynamips/Dynagen . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2. Tunctl - UML Utilities . . . . . . . . . . . . . . . . . . . . . . . 19
VII
Indice general (Indice general)
4. Diseno de la Solucion 224.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1. Protocolo Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.2. Protocolo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.3. Protocolos Openwire y STOMP . . . . . . . . . . . . . . . . . . 27
5. Implementacion 295.1. Comunicacion entre Procesos . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1. Funcionamiento de los procesos Wind y Agente en la arquitectura 305.1.2. Generacion de requerimientos por parte del servidor web. . . . . 35
6. Verificacion de resultados y objetivos. 386.1. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. Soporte de equipos y caso de uso . . . . . . . . . . . . . . . . . . . . . . 40
7. Conclusiones y Trabajo Futuro 457.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Referencias 47
A. Arranque de la Plataforma WIND 49A.1. Servidor Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.2. Middleware Apache ActiveMQ . . . . . . . . . . . . . . . . . . . . . . . 50
B. Instalacion de bibliotecas y equipos de prueba 51B.1. Agregando extencion STOMP a PHP . . . . . . . . . . . . . . . . . . . . 51B.2. Virtualizacion de equipos CISCO . . . . . . . . . . . . . . . . . . . . . . 52
C. Configuraciones Especiales 53C.1. Archivo de configuracion ActiveMQ . . . . . . . . . . . . . . . . . . . . 53C.2. Configuracion de Routers Virtualizados . . . . . . . . . . . . . . . . . . 54
VIII
Indice de figuras
1.1. Modelo ISO/OSI. Capas de red en que operan los dispositivos. . . . . . . . . . 2
1.2. Diseno del logotipo de la aplicacion . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Diagrama basico de la solucion. . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Screenshot del programa Java Device Manager. . . . . . . . . . . . . . . . . 9
2.2. Screenshot del programa Cisco Security Device Manager. . . . . . . . . . . . 9
3.1. Taxonomıa de un Middleware. . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Logotipo del Middleware ActiveMQ. . . . . . . . . . . . . . . . . . . . . . 15
3.3. Consola web ActiveMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Ejemplo generico. Cuatro subredes conectadas mediante un bridge. . . . . . . . 19
3.5. Escenario de pruebas usando las tecnologıas descritas. . . . . . . . . . . . . . 20
4.1. Arquitectura detallada de la solucion propuesta. . . . . . . . . . . . . . . . . 22
4.2. Estructura de un mensaje SOAP. . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Ejemplo de un requerimiento SOAP. . . . . . . . . . . . . . . . . . . . . . . 26
4.4. Ejemplo de una respuesta SOAP ante la request enviada. . . . . . . . . . . . . 27
5.1. Ejemplo ilustrativo de un proceso Wind creando cola de mensajes en el broker. . 31
5.2. Ejemplo de mensaje SOAP recibido en la cola. . . . . . . . . . . . . . . . . . 32
5.3. Estructura XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IX
Indice de figuras (Indice de figuras)
5.4. Mensaje SOAP para solicitud de colas de tipo Routers. . . . . . . . . . . . . . 35
6.1. Escritorio servidor Wind Ubuntu 10.04. . . . . . . . . . . . . . . . . . . . . 39
6.2. Protocolos conectores STOMP y Openwire. . . . . . . . . . . . . . . . . . . 39
6.3. Consola web ActiveMQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4. Portal interfaz web Wind para la seleccion de tipos de equipos. . . . . . . 41
6.5. Lista de equipos disponibles. . . . . . . . . . . . . . . . . . . . . . . . . 41
6.6. Pagina de control de Router Cisco, modelo c7200, id=1080. . . . . . . . . . . 42
6.7. Pop-up de control de interfaces del Router seleccionado. . . . . . . . . . . . . 43
6.8. Configuracion de la interfaz FastEthernet 1/0. . . . . . . . . . . . . . . . 43
6.9. Ventana de Interface Status. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1. Screenshot consola Ubuntu 10.04. . . . . . . . . . . . . . . . . . . . . . . . 50
X
Capıtulo 1
Introduccion
Las redes de computadores hoy en dıa significan un pilar fundamental en las comu-
nicaciones globales, y transportan �ujos de informacion por todo el planeta. Para formar
una red de computadores es necesario utilizar herramientas de hardware y software que
facilitan esta labor. Las herramientas de hardware utilizadas en una red, como cualquier
aparato electronico, cuentan con una vida util y un comportamiento que no esta ajeno a
las probabilidades de fallas. Es por eso que la labor de los administradores de red y los in-
genieros es tan importante, ayudan a salvaguardar la salud de los equipos, la informacion
traficada a traves de ellos y ademas a desarrollar soluciones de tipo software que ayuden
en esta tarea.
1.1. Equipos que operan en una red de computadores
Dentro de la materia de Redes de Computadores, existe un modelo descriptivo, organi-
zado en capas, que ayuda a comprender que procesos se llevan a cabo en la comunicacion
entre las distintas entidades que operan en una red. Este modelo se muestra en la figura
1.1 y recibe el nombre de modelo ISO/OSI:
1
1.1 Equipos que operan en una red de computadores (Introduccion)
Figura 1.1: Modelo ISO/OSI. Capas de red en que operan los dispositivos.(Computer Networking, 6e James F. Kurose - Keith W. Ross)
Dentro de la familia de dispositivos que pueden existir en una red de computadores,
destacan:
Routers: Los routers son elementos que permiten transportar paquetes de informacion
a traves de una red. Los routers estan sujetos a algoritmos propiamente tales que
le permiten dialogar con routers vecinos y determinar la ruta mas adecuada para
transportar la informacion. En el ambito de redes, se dice que un router opera en la
capa 3 del modelo OSI.
Firewalls: Los cortafuegos ayudan en el ambito de la seguridad para frenar o establecer
un obstaculo ante trafico indeseado o malicioso que intenta penetrar en la red.
2
1.1 Equipos que operan en una red de computadores (Introduccion)
Hub: Los HUB son dispositivos que se asemejan a un “splitter” de corriente, es decir,
replican el trafico entrante en todas sus salidas (broadcast).
Switches: Los switches permiten extender la red mediante la conmutacion de paquetes.
Similar a un HUB pero inteligente, ya que reconoce direcciones MAC y por lo tanto
puede tomar la decision de puertos de salida (no broadcast).
Opera en capa de enlace del modelo OSI (aunque tambien existen los switches de
capa 3).
Servers: Los servidores poseen variadas funciones, entre muchas otras, la funcion de
alojar la informacion de la red.
En el universo de la administracion de redes, hay ciertos elementos que hay que tener
en cuenta a la hora de operar con estos dispositivos, por ejemplo, todos los dispositivos
de red pertenecen a un fabricante que implementa sus funcionalidades de acuerdo a los
estandares propietarios de la empresa donde se fabricaron. Ademas todos funcionan de
manera diferente y por ende, se administran de una forma especial. Por ello muchas veces
se requiere de capacitaciones especiales para los trabajadores que operan con ellas, lo cual
converge a una necesidad de “homogeneidad” de las interfaces de control de los dispositi-
vos. Todos los dispositivos de red requieren en algun momento de la atencion presencial y
no remota del administrador de red, y esto es algo inevitable. Los dispositivos estan vincu-
lados con entidades tanto de software como de hardware, y ademas otros elementos fısicos
como por ejemplo, los cables de par trenzado. Existen herramientas web que usualmente
son utilizadas para administrar los equipos de red.
3
1.2 Problema (Introduccion)
1.2. Problema
Para operar con equipos de red, ya sean routers, firewalls o servidores entre otros, es
necesario tener conocimientos previos y especializados, ya que al no existir un estandar
de configuracion, cada fabricante disena arquitecturas y comandos de manera distinta para
operar los equipos.
Generalmente estos comandos de configuracion para cada equipo son ingresados a
traves de una linea de comandos o bien cada equipo cuenta con una interfaz grafica pro-
pia de configuracion, o una solucion de software que permita conectarse a esa maquina
para poder configurarla de manera sencilla, soluciones que suelen funcionar solo para ese
modelo o fabricante en particular.
Las empresas desarrolladoras de equipos de red como por ejemplo Cisco, suelen adap-
tar sus productos y tecnologıas a los nuevos requerimientos tanto de los usuarios como
de las empresas que proveen servicios (VTR, Claro, Entel, etc.). Los sistemas de confi-
guracion de los equipos Cisco cambian de acuerdo a estos requerimientos, por lo que un
determinado modelo Cisco no necesariamente dispone del mismo esquema sintactico para
configurarse como modelos anteriores o posteriores a el.
Resumiendo, los problemas detectados y como se enfrenta el problema de configura-
cion son:
1. No Existe un estandar de configuracion para los equipos de diferentes fabricantes, lo
cual requiere conocimientos especializados para configurar equipos de un fabricante
determinado.
2. La falta de uniformidad en los comandos para gestionar equipos de un mismo fabri-
4
1.3 Propuesta (Introduccion)
cante pero con distintas versiones de sistema operativo.
3. Usualmente la terminal de configuracion de lo equipos es a traves de un CLI ( Com-
mand line interface ), lo cual para usuarios mas inexpertos pueda resultar engorroso
de operar.
4. Las soluciones orientadas a la configuracion de equipos de red basadas en interfaces
graficas actuales no funcionan para todos los fabricantes de equipos.
1.3. Propuesta
Se propone disenar una plataforma web, en la cual se puedan agregar equipos de red
de distintos modelos y fabricantes, y configurarlos a traves de una interfaz visual, que sea
visible tanto desde un computador de escritorio, como desde un dispositivo movil, como
un smartphone o tablet. La idea de esto es unificar la forma en la que el usuario configura
los equipos, y abre las puertas para que un usuario con menor conocimiento de equi-
pos de un fabricante determinado pueda configurarlos de la misma manera que los demas.
Ademas de esto, facilitar el trabajo para los administradores mas experimentados agregan-
do la comodidad de poder configurar estos dispositivos sin tener que estar conectandose
a la consola de control de cada equipo, y utilizando aparatos que no requieran del uso de
cables, un ejemplo de ello, configurar un set o rack de equipos a traves de la pantalla de
un ipad o iphone.
1.3.1. WIND - Web Interface for Network Devices
WIND ( Web Interface for Network Devices ) es el nombre de la aplicacion propuesta
que pretende unificar los estilos de configuracion y monitoreo de equipos de red.
5
1.3 Propuesta (Introduccion)
Figura 1.2: Diseno del logotipo de la aplicacion
( Creado usando el programa Inkscape en Ubuntu 10.10 )
La version preliminar que se pretende generar dispone de algunas pocas opciones
genericas de configuracion para 2 modelos de equipos de red, con una arquitectura basa-
da en un middleware orientado a mensajes, aplicacion web basado en html-javascript-php
para la vista y la generacion de requerimientos por parte del usuario cliente, aplicaciones
java de bajo nivel para manejar las peticiones del usuario, la conexion con los equipos de
red que se quieren administrar y la interpretacion de los requerimientos generados por el
usuario para traducirlos a comandos y acciones sobre estos equipos.
1.3.2. Esquema basico de la solucion
La arquitectura basica de la solucion es mostrada en la figura 1.3:
Figura 1.3: Diagrama basico de la solucion.
6
1.3 Propuesta (Introduccion)
Para la realizacion de este proyecto se estudiaron las siguientes tecnologıas de las cuales
se daran detalles mas adelante:
ActiveMQ: Message Broker que permite la comunicacion de procesos mediante
mensajes de texto.
JqueryMobile: Framework para aplicaciones web javascript para equipos moviles
y de escritorio.
Dynagen/Dynamips: Simulador de escenarios y equipos de red Cisco.
Bibliotecas de Java para soporte de comunicaciones con ActiveMQ.
Bibliotecas de Java Commons para el soporte de variados protocolos de red (Telnet).
Protocolos SOAP, Telnet, OpenWire, STOMP.
Otro de los puntos que ataca esta propuesta, es crear un producto que sea lo suficien-
temente modular para que pueda ser reutilizado usando la misma logica para administrar
otro tipo de dispositivos o para usarse en otro tipo de negocios, como por ejemplo:
Redes de sensores
Aprovisionamiento de usuarios
Domotica
GUI's Web de diversos programas ( Ej: GUI Matlab Web )
etc.
7
Capıtulo 2
Estado del Arte
Actualmente en Chile y el mundo existen herramientas de administracion de equipos
de red pagados y open-source. Todos son instalables y algunos estan integrados en los
mismos equipos.
2.1. Herramientas de administracion/control
A continuacion se mostraran algunas herramientas que ofrecen soluciones de adminis-
tracion/control y bajo que condiciones opera segun cada fabricante.
2.1.1. Java Device Manager
Controlador y gestionador de dispositivos de red. Este software open-source facilita la
configuracion de equipos NORTEL para que el usuario no tenga que lidiar con el terminal
del mismo. Hasta donde se sabe esta aplicacion no tiene soporte web, y requiere de su
instalacion en Microsoft Windows.
8
2.1 Herramientas de administracion/control (Estado del Arte)
Figura 2.1: Screenshot del programa Java Device Manager.
2.1.2. Cisco Security Device Manager (SDM)
SDM es la herramienta desarrollada por Cisco, que cumple exactamente con los pun-
tos que ataca este proyecto, pero solamente para sus equipos. Es un applet accesible a
traves del navegador. Actualmente viene instalado por defecto en los equipos nuevos de
Cisco. Ofrece una alta capacidad de configuracion para los equipos, como por ejemplo,
las configuraciones de interfaces de red.
Figura 2.2: Screenshot del programa Cisco Security Device Manager.
9
2.2 Herramientas de administracion (Estado del Arte)
2.2. Herramientas de administracion
Otras herramientas destacadas que se alejan del objetivo principal del proyecto pero
que tambien cumplen rol de administracion a traves de la web son:
Nagios: Sistema de monitorizacion muy potente que permite identificar problemas tan-
to de hardware como de software. Permite detectar problemas para ası mitigar los
efectos que pueda tener dentro de una empresa u organizacion. Suele utilizarse para
administrar la salud de los equipos de red.
PRTG - Paessler Router Traffic Grapher : Software que permite la monitorizacion de
redes de manera segura y permite controlar traficos de entrada y salida de diferentes
dispositivos de red que soporte protocolo SNMP. Dentro de las posibilidades destaca
la integracion de datos historicos para realizar analisis de ancho de banda durante
dıas, semanas o anos entre otros. Actualmente PRTG es pagado y tambien cuenta
con una aplicacion para dispositivos moviles.
Cacti: Cacti es una aplicacion web escrita en PHP. Permite el despliegue de graficos
en tiempo real, y esta orientado al monitoreo del estado de equipos (temperatura,
voltaje, velocidad, trafico, etc.).
Pandora FMS: Otro software de codigo abierto para monitorizar sistemas, aplicaciones
y servicios. Tambien tiene soporte de base de datos para realizar analisis historicos.
En las ultimas versiones se incluyeron soportes y consolas web para Smartphones.
Con respecto a todo lo mencionado y a las tecnologıas existentes, lo que este proyecto
intenta agregar es el concepto de control a traves de una interfaz comoda y minimalista,
que unifique los estilos de configuracion de los equipos de red independiente de la marca/-
modelo y de la sintaxis de configuracion que esto conlleva, ofreciendo opciones basicas
10
2.2 Herramientas de administracion (Estado del Arte)
que sean comunes para todos los equipos, y en la medida que el usuario requiera nuevas
funcionalidades estas puedan ser agregadas sin necesidad de crear una nueva aplicacion,
manteniendo la plataforma.
Ademas, se busca que la arquitectura de la plataforma Wind permita agregar nuevos
equipos a la lista de configuraciones junto con los que ya se encuentran en el sistema, sin
la necesidad de detener la plataforma.
11
Capıtulo 3
Tecnologıas Involucradas
3.1. Servidor de aplicaciones HTTP Apache
El servidor apache es una tecnologıa de codigo abierto para las plataformas Unix,
Microsoft Windows y Macintosh entre otras que implementa protocolo HTTP. Apache
es utilizado principalmente para el envıo de paginas web a traves de Internet en caso
de recibir peticiones de documentos HTML que aloja en su servidor. Apache suele estar
integrado a otras tecnologıas. Una de estas integraciones es conocida como LAMP:
Linux: Plataforma/Sistema operativo.
Apache: Servidor Web.
Mysql: Gestor de base de datos.
Php: Lenguajes de programacion.
12
3.2 Framework Jquery/JQueryUI/Jquery Mobile (Tecnologıas Involucradas)
3.2. Framework Jquery/JQueryUI/Jquery Mobile
Jquery es un framework javascript1 que ofrece una API completa que simplifica enor-
memente el desarrollo de aplicaciones web. Ofrece dentro de otras opciones, el manejo
de estilos dinamicos, generacion de contenido dinamico a traves de ajax y mucho mas.
Ademas de esto, Jquery-UI utiliza las potencialidades de la API de Jquery para crear inter-
faces visuales unicas y �uidas, que sacan el mayor provecho del navegador web utilizado.
Jquery Mobile es un framework de desarrollo orientado a aplicaciones web-moviles,
creado a partir de los anteriores Jquery/JqueryUI. Ofrece un sistema unificado basado en
HTML5 para la mayorıa de las plataformas moviles existentes ( IOS, Android, BlackBerry,
WindowsPhone, etc. ), es �exible y ofrece elementos visuales prefabricados facilmente
modificables y una variada cantidad de funciones para manejar eventos propios de los
dispositivos moviles.
3.3. Middlewares y servidores de aplicaciones
Dentro del mundo de los servicios en materia de redes, son conocidos los servidores
de aplicaciones. Los servidores de aplicaciones son una componente de una red de compu-
tadores que tiene la tarea de ejecutar ciertas aplicaciones cuando el usuario lo requiera. Un
ejemplo son los comunmente conocidos servidores web.
Un servidor de aplicaciones integra en la mayorıa de los casos un Middleware, un
software que permite la interaccion entre aplicaciones de software o hardware indepen-
dientes. Los Middleware se situan entre la capa de aplicacion y la capa de red del modelo
1Javascript: Lenguaje de programacion ejecutado del lado del cliente, a diferencia de PHP que que lohace en el servidor
13
3.3 Middlewares y servidores de aplicaciones (Tecnologıas Involucradas)
OSI y ofrecen una abstraccion de software y comunicacion, lo que resulta ideal para gene-
rar soluciones distribuidas. Originalmente fue concebido para la interaccion de software
entre arquitecturas nuevas con otras plataformas mas antiguas o entre sistemas operativos
heterogeneos.
Figura 3.1: Taxonomıa de un Middleware.
Algunos Middleware destacados dentro de la categorıa de integracion de la figura 3.1 son:
Orientados a Procesos: Utilizan comunicacion sıncrona entre procesos. Opera remota-
mente mediante un cliente-stub y un servidor-skeleton. Basicamente, el stub encap-
sula el mensaje que se desea enviar al servidor, el cual contiene los parametros con
el metodo al cual se quiere acceder y que previamente esta creado en el servidor-
skeleton. El skeleton desencapsula, lee los parametros del metodo al cual se esta in-
vocando, realiza la peticion para correr el metodo, acepta el resultado retornado por
la funcion invocada y escribe el valor retornado de regreso al stub.
Orientados a objetos: Este tipo de middleware es una extension del anterior, ya que so-
porta comunicacion asıncrona y transacciones distribuidas. Java RMI es un ejemplo,
ya que permite la invocacion remota de objetos contenidos en otra maquina virtual
de java. Otros casos de Middleware orientados a objetos son JavaBeans, DCOM, y
CORBA.
14
3.3 Middlewares y servidores de aplicaciones (Tecnologıas Involucradas)
Orientados a mensajes: Usualmente llamados MOM ( Middleware Oriented Message).
En este caso la comunicacion entre aplicaciones se efectua mediante publicacion/-
subscripcion de mensajes. Un cliente puede publicar mensajes en una cola contenida
en el servidor MOM (MessageBroker). Los clientes que esten subscritos a dicha co-
la recibiran el mensaje enviado por el publicador. El servidor MOM se asegura de
que el mensaje sea entregado a sus subscriptores, por lo que se podrıa ver al servidor
como un cartero.
3.3.1. ActiveMQ - Un Middleware Orientado a Mensajes
ActiveMQ es un broker de mensajes open source bajo la licencia de Apache. Acti-
veMQ fue concebido para ser multiplataforma, tanto por la parte de sistemas operativos,
como de los lenguajes que puede manejar, esto implica que puede realizarse una comuni-
cacion entre procesos que fueron creados a partir de lenguajes de programacion distintos
u otros paradigmas. ( ej. comunicacion php/java, c++/java, delphy/java , etc ). ActiveMQ
permite la comunicacion indirecta y asıncrona entre procesos y asegura la entrega de los
mensajes, incluso, si uno de los procesos receptores no esta disponible en el momento en
que un mensaje les fue enviado.
Figura 3.2: Logotipo del Middleware ActiveMQ.
Apache ActiveMQ implementa todas las funcionalidades de JMS ( Java Message Ser-
vice ), una API creada por Sun Microsystems para la utilizacion de colas de mensajes entre
15
3.3 Middlewares y servidores de aplicaciones (Tecnologıas Involucradas)
aplicaciones, y cumple el rol de JMS Provider, encargado de manejar las sesiones y colas
creadas en este sistema. JMS implementa 2 modelos de comunicacion:
1. Punto a Punto: Comunicacion basica entre 2 clientes, el cliente que envıa el men-
saje y el que esta dispuesto a recibirlo. El cliente productor envıa los mensajes a una
cola FIFO2 que hace referencia al cliente consumidor.
2. Modelo Publicador/Subscriptor: Modelo enfocado a varios clientes, donde algu-
nos clientes son publicadores de informacion, tambien llamados ”topicos”, y por
otro lado los clientes que son consumidores de estos topicos. A diferencia del mo-
delo anterior, varios clientes puede consumir un topico en particular. Similar al con-
cepto de modelo Uno a Muchos en materia de bases de datos.
ActiveMQ provee las bibliotecas necesarias para conectarse a cualquier aplicacion Ja-
va y C++ a traves del protocolo de conexion nativo de ActiveMQ, OpenWire.
Otros clientes pueden implementar de una manera mas sencilla la conexion con el
middleware mediante el protocolo de conexion STOMP 3 con la limitacion de que este
protocolo no permite la utilizacion de todas las potencialidades que Openwire ofrece, solo
implementa el modelo basico de creacion de colas y consumidores, no es posible crear
colas de mensaje temporales u otras operaciones mas complejas en el broker. ActiveMQ
posee una interfaz web para administrar las colas creadas en el broker, lo cual facilita el
desarrollo de aplicaciones basados en clientes ActiveMQ y la depuracion de los mensajes
que se envıan a traves del broker. Entrega informacion detallada de cuales son las co-
las que actualmente tienen consumidores, cuantos mensajes han encolado y cuantos han
despachado, si existen mensajes pendientes, etc.
2First in, first out: Logica de colas de eventos donde el primer evento en llegar, es el primero en atenderse.3Simple (or Streaming) Text Oriented Message Protocol
16
3.4 Bibliotecas y Frameworks necesarios (Tecnologıas Involucradas)
Figura 3.3: Consola web ActiveMQ .
3.4. Bibliotecas y Frameworks necesarios
Para la realizacion de este proyecto, fueron necesarias las siguientes bibliotecas y fra-
meworks:
Bibliotecas de conexion ActiveMQ openwire-java.
Bibliotecas de conexion ActiveMQ stomp-php.
Bibliotecas de utilidades Apache-Commons ( necesario para la utilizacion de fun-
ciones Telnet en java ).
Bibliotecas necesarias para la utilizacion de Framework Jquery Mobile.
Framework de programacion en java NetBeans.
Otras opciones y configuraciones adicionales del broker ActiveMQ se encuentran ex-
plicadas en el Anexo C.
17
3.5 Virtualizacion (Tecnologıas Involucradas)
3.5. Virtualizacion
Para la creacion del proyecto fue necesario utilizar ciertas herramientas que permitie-
ran virtualizar equipos de hardware e interfaces de red reales, de tal forma de que no se
dependiera de un espacio fısico de trabajo y fuera mas sencilla la realizacion de pruebas sin
causar accidentes en estos. Durante la busqueda de una herramienta de virtualizacion se
encontro la existencia de 2 que, funcionando en conjunto, ofrecen la posibilidad de montar
los sistemas operativos de routers Cisco, estas herramientas son Dynamips y Dynagen.
3.5.1. Dynamips/Dynagen
Dynamips : Es un simulador de router Cisco creado por Christophe Fillot. Permite cargar
imagenes de IOS4 Cisco y simular su ejecucion en el ordenador.
Segun las palabras de su propio creador, este simulador de equipos Cisco se creo con
el objetivo de:
Ser usado como una plataforma de formacion y estudio, para lograr familiari-
zarse con los dispositivos de Cisco.
Realizar pruebas de las caracterısticas especiales de los IOS de Cisco.
Comprobar configuraciones de forma rapida para implementar sin riesgos en
routers reales.
Evidentemente, este simulador no pretende remplazar a los enrutadores reales, pero
sirve de practica para quienes quieran rendir los examenes de certificacion CCNA/C-
CNP/CCIE.4Cisco IOS o Internetwork Operating System, es el software que utiliza la gran mayorıa de los routers y
switches de Cisco.
18
3.5 Virtualizacion (Tecnologıas Involucradas)
Dynagen: Por otra parte, Dynagen es un front-end basado en texto que utiliza ”hyper-
visor”, modo de comunicacion con Dynamips. La gran utilidad de Dynagen es que
permite agregar facilmente nuevas IOS con sus configuraciones iniciales respecti-
vas, y ofrece una sintaxis simple para interconectar routers, bridges, ethernet swit-
ches, etc. Tambien es posible ejecutar telnet hacia los routers montados con la inter-
faz de dynagen.
3.5.2. Tunctl - UML Utilities
Tunctl es una herramienta del paquete UML Utilities del sistema operativo Linux
Ubuntu 10.10 ( en otras distribuciones tambien esta disponible ) que permite hacer bridges
o puentes de red logicos. Un bridge es un sistema de capa 2 del modelo OSI, que permite
la interconexion de segmentos de red, permitiendo la transferencia de datos de una red
hacia otra sin necesidad de un router.
Figura 3.4: Ejemplo generico. Cuatro subredes conectadas mediante un bridge.
Opera mediante una tabla de direcciones MAC que son detectadas en cada segmento de
la red dividida, y cuando uno de los nodos desea enviar un dato hacia otro nodo, el bridge
copia la trama a las otras subredes, las cuales eliminan o filtran dicha trama en caso de no
tener esa subred como destino.
19
3.5 Virtualizacion (Tecnologıas Involucradas)
Gracias a Tunctl es posible crear interfaces TUN/TAP. Estas permiten virtualizar inter-
faces de red que se comportan como una tarjeta de red, permitiendoseles asignar direccion
ip y mascara de subred.
Y ahora, ¿ De que nos sirve Tunctl , las interfaces virtuales y los simuladores de
IOS Cisco ?. Como se explico en el punto anterior, Dynagen permite el crear una confi-
guracion de red a partir de las IOS cargadas sobre Dynamips, y tambien, permite realizar
conexiones logicas entre interfaces de red de los routers montados virtualmente ( para el
caso de Cisco, interfaces FastEthernet/Ethernet ) y las interfaces virtuales ( TUN/TAP )
que hallamos creado en la maquina donde se este ejecutando Dynamips/Dynagen.
Gracias a todas estas herramientas y tecnologıas, se dispone de todo lo necesario para
realizar pruebas de conexion con equipos virtuales y el desarrollo de la aplicacion pro-
puesta.
El siguiente diagrama muestra un posible escenario de pruebas, ver figura 3.5:
Figura 3.5: Escenario de pruebas usando las tecnologıas descritas.
20
3.5 Virtualizacion (Tecnologıas Involucradas)
Como muestra la figura 3.5, a traves de Dynamips, se virtualizan 2 router Cisco, mode-
los c7200 y c3620 respectivamente, y mediante tunctl dos interfaces de red virtuales, tap0
y tap1, conectados a la interfaz f0/0 de los router por medio de una conexion logica usando
Dynagen. Junto a esto, los servicios web y el middleware ActiveMQ para la comunicacion
entre interfaz web y las aplicaciones a desarrollar en el proyecto.
21
Capıtulo 4
Diseno de la Solucion
4.1. Arquitectura
La arquitectura Wind consta de 3 partes clave, la parte de creacion de requerimientos
por parte del usuario a traves de la interfaz web (Capa Vista / Generacion de requerimien-
tos), la parte de procesos y equipos, y el intermediario de los mensajes entre la interfaz
web y los equipos a administrar, del cual esta encargado ActiveMQ (Core). La arquitectura
propuesta se muestra en la figura 4.1:
Figura 4.1: Arquitectura detallada de la solucion propuesta.
22
4.1 Arquitectura (Diseno de la Solucion)
Los modulos involucrados en la arquitectura son:
Dispositivos terminales: Son los equipos que el usuario administrador utilizara para el
control de los equipos de red. Pueden ser dispositivos moviles y equipos de escrito-
rio, como un computador personal, pc, notebooks, smarthphones, etc.
Servidor Apache: Encargado de alojar la interfaz web y todo lo relacionado con capa
vista. Incluye modulos para la creacion de mensajes y conexion con ActiveMQ.
ActiveMQ Message Broker: A grandes rasgos, ActiveMQ es un intermediario entre la
interfaz visual web y los equipos de red. El analogo de ActiveMQ es un “cartero”,
acumula cartas con mensajes y los envıa a los destinatarios que corresponda.
Agente: Proceso encargado de informar que equipos y servicios de red se encuentran
disponibles actualmente en el sistema.
Procesos Wind: Desde una perspectiva de alto nivel, un proceso Wind es el representante
de un equipo de red. Por lo cual se entiende que por cada equipo nuevo que se
quiera integrar al sistema, existira un nuevo proceso Wind. Ademas tienen la tarea
de interpretar todos los mensajes que tengan como destino el equipo del cual son
representantes y comunicarle el mensaje que fue recibido en un lenguaje que ellos
entiendan.
Equipos: Son los componentes de red que se desean administrar y controlar.
Esta arquitectura tiene la caracterıstica de que permite agregar nuevos equipos sin
necesidad de detener el funcionamiento de los que ya se encuentran integrados en la pla-
taforma web de configuracion, ya que funcionan de manera independiente y dependen
solamente del intermediario de mensajes ActiveMQ.
23
4.2 Protocolos (Diseno de la Solucion)
Los detalles sobre la comunicacion entre ActiveMQ y los distintos procesos involucra-
dos se encuentran explicados a mas bajo nivel en el capıtulo 5.
4.2. Protocolos
Para poder llevar a cabo la comunicacion entre distintos dispositivos y procesos que se
ejecutan en la arquitectura de la solucion, es necesario tener claro el concepto de protocolo.
Protocolo de comunicacion es un conjunto de reglas y secuencias de mensajerıa que se
lleva a cabo para entablar una relacion entre entidades que, en este caso conforman una
red.
Como es de esperar, para poder llevar a cabo esta propuesta, es necesario establecer
que reglas y metodos de comunicacion, asociadas a un protocolo, son necesarios para hacer
que el sistema ofrezca una modularidad tal que permita integrar dispositivos de cualquier
tipo.
4.2.1. Protocolo Telnet
Telnet es un protocolo que permite a los usuarios acceder a dispositivos de forma
remota usando conexion TCP. Se encuentra estandarizado a traves de la norma RFC 0854-
0855. Telnet se basa en el concepto de “Terminal Virtual de Red “ (NVT, Network Virtual
Terminal) , que es un dispositivo imaginario que ofrece una representacion intermedia de
un terminal, que tiene el objetivo de eliminar la necesidad ( tanto de parte del usuario
cliente que desea entablar la comunicacion, como del servidor que se desea controlar y
que proporciona el servicio de conexion ) de guardar informacion de las caracterısticas del
terminal y las convenciones asociadas a su manejo.
24
4.2 Protocolos (Diseno de la Solucion)
Para poder utilizar Telnet en la consola de comandos, se utiliza Telnet seguido de la
direccion ip de la maquina con la cual se desea trabajar. Se recomienda utilizar Telnet solo
en ambientes locales, ya que la informacion enviada por la red no es encriptada y viajan
como texto plano.
En la arquitectura de la solucion, se utiliza el protocolo Telnet para comunicar los
procesos Wind y los equipos de red que se desean administrar localmente.
4.2.2. Protocolo SOAP
El protocolo SOAP ( Protocolo simple de acceso a objetos ) es un protocolo estandar
auspiciado por la w3c. SOAP esta basado en XML, y fue concebido para el intercambio
de objetos estructurados en arquitecturas distribuidas a traves de cualquier protocolo de
transporte ( como por ejemplo HTML, SMTP, JMS, etc ). SOAP es un protocolo derivado
de XML-RPC, protocolo de llamados a procedimientos remotos.
SOAP fue disenado para entregar informacion minuciosa acerca de que se esta envian-
do, en cambio XML-RPC, fue disenado para ser sencillo pero lo hace menos ductil. Por
dar un ejemplo, SOAP admite entre otras cosas, el tipo de codificacion de caracteres (
UTF-8, UTF-16, etc ).
El mensaje SOAP se estructura en base a 3 elementos basicos, SOAP Envelop, SOAP
Header, SOAP Body, ver figura 4.2:
25
4.2 Protocolos (Diseno de la Solucion)
Figura 4.2: Estructura de un mensaje SOAP.
SOAP Envelope : Es la envoltura del mensaje ( sobre ). Todos los mensajes parten
desde este elemento raız.
SOAP Header: La cabecera del mensaje, usado para enviar informacion adicional
sobre el contenido del mensaje (tipos de datos definidos por la aplicacion entre
otros). Su uso no es obligatorio.
SOAP Body: Es el cuerpo del mensaje que contiene lo que se desea enviar.
Un ejemplo de mensajerıa SOAP se muestra en la figura 4.3 (en este ejemplo el header
fue omitido):
Figura 4.3: Ejemplo de un requerimiento SOAP.
26
4.2 Protocolos (Diseno de la Solucion)
Basicamente el mensaje se traduce en que se solicita informacion de una persona de-
terminada, y una respuesta a dicho requerimiento podrıa ser como se muestra en la figura
4.4:
Figura 4.4: Ejemplo de una respuesta SOAP ante la request enviada.
Este proyecto escoge SOAP como estructura principal de la mensajerıa entre la interfaz
web y los procesos que estan a cargo de la comunicacion con los equipos de red (sabiendo
que la comunicacion entre interfaz web y estos procesos es indirecta, ya que los mensajes
son entregados a los destinatarios por ActiveMQ). Si bien no se aprovechan todas las
bondades y funcionalidades que este protocolo pueda brindar, se utiliza para otorgar mayor
escalabilidad a la aplicacion y pueda lograrse de una manera estandar agregar nuevas
capacidades tanto de seguridad como de los servicios futuros que puedan integrarse a
la plataforma.
4.2.3. Protocolos Openwire y STOMP
Tanto Openwire como STOMP son comunmente llamados “wire protocols”. Permi-
ten establecer conexiones con el broker ActiveMQ para el envıo de mensajes JMS. Esta
arquitectura utiliza SOAP/JMS para mensajerıa entre servidor Web-broker y aplicaciones
Java-ActiveMQ.
27
4.2 Protocolos (Diseno de la Solucion)
Openwire es el protocolo de comunicacion nativo de ActiveMQ y esta disenado para
un completo control sobre el broker, ademas de tener un alto rendimiento y utilizar de
mejor manera los recursos de la red. Existen bibliotecas Java que utilizan este protocolo,
como tambien en C++. Openwire es un protocolo complejo, transforma objetos a arreglos
de bytes y viceversa. Cada arreglo de bytes recibe el nombre de “command”. Cada uno de
estos sirve para realizar una operacion especifica en ActiveMQ, como establecer sesiones,
creacion de colas, manejo de recursos, etc.
A diferencia de Openwire, STOMP ( Simple Text Oriented Messaging Protocol o Pro-
tocolo simple de mensajerıa orientada a texto ) es un protocolo basado en envıo de men-
sajes en texto plano y no ofrece el nivel de control sobre el broker que ofrece Openwire,
pero a cambio de eso ofrece mayor simpleza y permite un rapido desarrollo de clientes
que usan este protocolo.
La mensajerıa utilizada por Stomp para establecer conexiones y enviar mensajes es la
siguiente:
CONNECT: Establecer conexion con el broker.
SUBSCRIBE/UNSUBSCRIBE: subscribirse/desubcribirse a una cola del broker.
SEND: Enviar mensajes de texto a una determinada cola del broker.
ACK: Aviso de mensaje exitosamente recibido.
DISCONNECT: Desconexion del broker.
STOMP es utilizado como protocolo de conexion entre el servidor web y el broker Acti-
veMQ, a traves de modulos desarrollados en PHP que implementan esta mensajerıa.
28
Capıtulo 5
Implementacion
En este capıtulo se explicaran como operan los metodos y funciones clave implemen-
tados en los distintos lenguajes para operar con el middleware ActiveMQ y de que forma
este logra comunicar finalmente la interfaz web con los servicios implementados en Java
para la administracion de equipos de red.
Basado en la arquitectura propuesta y los elementos re�ejados en ella, el proceso de
implementacion acarrea:
La estructura de los requerimientos SOAP que el usuario terminal genera desde la
interfaz web.
Como el servidor web y las aplicaciones se conectan con el broker de mensajes
ActiveMQ.
La logica de los mensajes que seran enviados a los procesos que estan a cargo de los
equipos de red y como responden estos procesos a los mensajes luego de ejecutar
las acciones sobre el equipo del cual estan a cargo.
29
5.1 Comunicacion entre Procesos (Implementacion)
5.1. Comunicacion entre Procesos
ActiveMQ esta basado en JMS ( Java Message Service ) como logica de comunicacion
entre pares, por lo cual, la creacion de mensajes por parte del usuario de la plataforma web
como del servicio que maneja los mensajes ( procesos Wind ) se basaran en una logica de
colas de mensajes.
ActiveMQ cumple el rol de proveedor de sistema de mensajes JMS, y es el encargado
de administrar las colas de mensajes. Sobre estas colas existen los conceptos de:
Message Consumers ( Consumidores ) : Encargados de extraer los mensajes de
una determinada cola a la cual estan subscritos.
Message Producers ( Productores ): Encargados de crear e insertar mensajes en
una determinada cola.
Gracias al modelo de productor-consumidor y a que ActiveMQ soporta conexiones
a traves de protocolos STOMP ( para implementaciones PHP ) y Openwire( Java ), es
posible establecer comunicacion indirecta entre la interfaz web y los procesos Wind que
controlan los equipos de red.
5.1.1. Funcionamiento de los procesos Wind y Agente en la arquitec-
tura
Asumiendo que el broker de mensajes esta en funcionamiento, uno de los objetivos de
cada proceso Wind ( Wind.java ), es crear una cola de mensajes en el broker ( de acuerdo
a sus parametros de entrada ) que haga referencia al equipo del cual esta a cargo.
Los parametros principales que un proceso Wind requiere como argumento son:
30
5.1 Comunicacion entre Procesos (Implementacion)
Type: Relacionado con el tipo de dispositivo (ej: Routers, Firewalls, Switches, etc).
Manufacturer: Fabricante del dispositivo (ej: Cisco, 3Com, Nortel, Dell, etc).
Model: Modelo del dispositivo.
ID: Identificador del equipo.
IP: Direccion Ip del equipo a administrar.
Argumentos adicionales estan asociados al password de Telnet/Root de los equipos o
a nombres de usuario en caso de que los equipos los manejen.
El nombre de la cola asociada al equipo quedara re�ejada en el broker con la siguiente
estructura:
1 / queue / Type : M a n u f a c t u r e r : Model : ID
Figura 5.1: Ejemplo ilustrativo de un proceso Windcreando cola de mensajes en el broker.
Una vez creada, el proceso Wind pasa a convertirse en un consumidor de esta cola, por
lo que cualquier mensaje que llegue a esta sera inmediatamente extraıda e interpretada por
el proceso. Los mensajes recibidos usan el estandar SOAP. Las funciones u operaciones
recibidas estaran contenidas en el body del mensaje SOAP, ver figura 5.2:
31
5.1 Comunicacion entre Procesos (Implementacion)
Figura 5.2: Ejemplo de mensaje SOAP recibido en la cola.
Los Tags que contienen el nombre de la funcion que se quiera ingresar a los equipos
de red pueden poseer n argumentos ( ejemplos de argumentos estan re�ejados el la figura
como arg1 y arg2).
Los procesos Wind disponen de un documento XML donde se especifica que pasos de-
ben seguir de acuerdo a la funcion y argumentos contenidos en el mensaje SOAP recibido
y dependiendo del modelo del equipo que estan administrando por medio de Telnet.
Un ejemplo de la estructura de dicho documento XML se muestra en la figura 5.3:
Figura 5.3: Estructura XML
Como puede verse en este ejemplo, la es-
tructura del documento XML consta de un
elemento raız llamado funciones, que contie-
ne una lista nodos de nombre funcion1, fun-
cion2, etc. Cada uno de estos nodos que re-
presentan las funciones, contienen sub-nodos
de nombre modelo1, modelo2, etc. En pa-
labras simples, cada funcion se ejecutara de
manera distinta dependiendo del modelo.
Para el caso de este proyecto, se entiende que los pasos senalados en este ejemplo
32
5.1 Comunicacion entre Procesos (Implementacion)
en realidad representan los comandos a ingresar por medio de Telnet a la consola del
equipo modelo-X. Estos comandos o pasos, en determinados casos, pueden contener otros
elementos ( tags ) asociados a argumentos requeridos por el comando. Por dar un ejemplo,
si se desea configurar una interfaz de red, es de esperar que el mensaje SOAP recibido
contenga 3 argumentos mınimos junto a la funcion de configuracion correspondiente:
El nombre de la interfaz de red que quiera configurar
La direccion ip que se le quiere asignar a dicha interfaz de red.
La mascara de subred.
Si el proceso Wind se encuentra con tags en los pasos leıdos de una determinada fun-
cion contenida en el XML, asume que esos parametros estaran incluidos con el mismo
nombre en el mensaje SOAP recibido.
Para que una aplicacion en Java realice una conexion con ActiveMQ para realizar
operaciones de creacion de colas y envıo de mensajes utiliza principalmente 2 objetos:
ConnectionFactory: Objeto usado para entablar la comunicacion con el proveedor
de sistema de mensajes (en este caso ActiveMQ), y establecer sesiones de produc-
tores o consumidores sobre una determinada cola de destino.
Destination: Objeto que permite la creacion de colas de destino y hace referencia
a las mismas.
Estos objetos son la base de la comunicacion entre aplicaciones Java y el broker Ac-
tiveMQ por medio del protocolo nativo Openwire. Para poder establecer conexiones con
java solo se requiere instanciar el objeto ActiveMQConnectionFactory con la direccion
33
5.1 Comunicacion entre Procesos (Implementacion)
del broker como argumento y el puerto donde se atenderan las conexiones que usen el
protocolo Openwire, por ejemplo a traves de un cliente Java:
1 c o n n e c t i o n F a c t o r y =
new Act iveMQConnec t ionFac to ry ( ” t c p : / / l o c a l h o s t :61616 ” ) ;
3 c o n n e c t i o n = c o n n e c t i o n F a c t o r y . c r e a t e C o n n e c t i o n ( ) ;
c o n n e c t i o n . s t a r t ( ) ;
A partir del objeto connection es posible crear nuevas sesiones para instanciar destinos,
productores y consumidores.
Para crear una cola de nombre Routers: CISCO:C7200:1080:
s e s s i o n = c o n n e c t i o n . c r e a t e S e s s i o n ( ) ;
2 d e s t i n a t i o n = s e s s i o n . c r e a t e Q u e u e ( ” R o u t e r s : CISCO : C7200 :1080 ” ) ;
Una vez creado el objeto destination, podemos crear productores o consumidores que
envıen o consuman mensajes de esta cola del broker. Para crear un consumidor de mensa-
jes en java se hace de la siguiente forma:
MessageConsumer consumer = s e s s i o n . c r e a t e C o n s u m e r ( d e s t i n a t i o n ) ;
2 consumer . s e t M e s s a g e L i s t e n e r ( t h i s ) ;
La clase donde se crea el consumidor debe agregar la interfaz MessageListener para
implementar el metodo “onMessage(Message msg)”. Si un mensaje llega a la cola de la
cual el objeto consumer es consumidor, inmediatamente se ejecutara el metodo onMessage
con el mensaje recibido como argumento, el cual se interpreta como SOAP para realizar las
operaciones que la clase estime conveniente. Para el caso de los procesos Wind, el metodo
onMessage esta implementado especıficamente para crear una conexion Telnet con los
equipos del cual estan a cargo para la insercion de comandos ( leıdos del documento
XML segun el modelo del equipo ) en la consola de estos. Para el caso del Agente (
ActiveMQAgent.java ), el metodo onMessage esta implementado para manejar mensajes
34
5.1 Comunicacion entre Procesos (Implementacion)
SOAP relativos a consultas, especıficamente sobre que colas se encuentra disponibles en
el broker. Un ejemplo de una consulta de colas SOAP recibido por el Agente se muestra
en la figura 5.4:
Figura 5.4: Mensaje SOAP para solicitud de colasde tipo Routers.
El metodo onMessage del Agente interpreta este requerimiento como la ejecucion de
la funcion getQueues con argumento “Routers”, la cual retorna las colas de tipo Routers
que existen en el broker.
Para poder comunicar resultados, tanto de las operaciones Telnet ejecutadas por los
procesos Wind como del Agente informante de colas, se requiere de una cola a la cual
responder en el broker para que posteriormente el mensaje sea consumido desde esta por
los metodos PHP del servidor web y formateado para su despliegue en la interfaz web. Esta
cola debe estar incluida en la cabecera de los requerimientos emitidos desde el servidor
web con el nombre de reply-to.
5.1.2. Generacion de requerimientos por parte del servidor web.
Como se menciono en el punto anterior, el proceso Agente es el encargado de infor-
marle al servidor web a traves de ActiveMQ los equipos disponibles para administrar. Lo
que se gana con esto es, mas alla de seleccionar el equipo sobre el cual se quieran realizar
35
5.1 Comunicacion entre Procesos (Implementacion)
operaciones, es seleccionar una cola que hace referencia a un equipo determinado y que
es un proceso Wind determinado.
Para crear los modulos de conexion entre el servidor web y ActiveMQ se utiliza el
lenguaje interpretado PHP. Se escoge este lenguaje debido a que permite a los progra-
madores crear aplicaciones complejas con una curva de aprendizaje relativamente corta.
Asumiendo que PHP cuenta con las extensiones STOMP, para conectarse al broker Acti-
veMQ, primero hay que crear el objeto conector STOMP ( similar al ConnectionFactory
en java ) con la direccion del broker ActiveMQ y el puerto donde se atenderan conexiones
que usen protocolo STOMP:
$stomp = new Stomp ( ” t c p : / / l o c a l h o s t :61613 ” ) ;
Este objeto implementa metodos para la subscripcion a colas y el envıo de mensajes a
una cola determinada. Para la creacion de mensajes SOAP se instancia la clase soapObject
contenida en soapObj.php y se invoca el metodo createMsg() con el Tag ( nombre funcion
) a enviar en el body, los argumentos del Tag y el contenido en caso de utilizarlo.
Por ejemplo, los pasos para consultar al Agente que colas de tipo Routers existen en el
sistema, por medio de PHP es el siguiente:
1. Primero se crea el mensaje SOAP con el tag getQueues con contenido Routers:
1 $soapObj = new SoapObjec t ( ) ;
$soap msg =
3 $soapObj−>c rea t eMsg ( ” ge tQueues ” , ” t y p e = ' i n f o ' ” , ” R o u t e r s ” ) ;
2. Acabamos de crear un mensaje SOAP con el siguiente Tag contenido en el body del
mensaje :
1 <ge tQueues t y p e = ' i n f o '>R o u t e r s< / ge tQueues>
36
5.1 Comunicacion entre Procesos (Implementacion)
3. Finalmente el mensaje esta preparado para su envıo a una determinada cola del bro-
ker. El mensaje getQueues esta dirigido al Agente (con nombre de cola ActiveM-
Queue ):
1 $stomp−>send ( ” ActiveMQueue ” , $soap msg , $ h e a d e r ) ;
Los mensajes son creados y enviados desde el servidor web por medio del protocolo
STOMP usando clientes PHP STOMP, pero la orden de emision del mensaje es gatillada
por los distintos eventos que el usuario terminal ( que utiliza un PC o dispositivo movil)
pueda generar a traves de la interfaz web ( capa vista ).
Los eventos son atrapados usando bibliotecas de javascript jquery y transformados a
requerimientos HTTP, usando metodos GET y POST para la solicitud y envıo de parame-
tros al servidor.
Independiente de como este disenada la interfaz web y que framework javascript se
utilice para atrapar eventos, lo relevante es que los requerimientos HTTP y parametros
enviados por POST o GET a los procesos PHP del servidor web para la creacion de los
mensajes SOAP, sean consecuentes con lo que los procesos Wind ( Wind.java ) esperan
encontrar en el documento XML para realizar las operaciones sobre los equipos.
37
Capıtulo 6
Verificacion de resultados y objetivos.
En este capıtulo se revisara como se cumplen los objetivos planteados de acuerdo a
algunos casos de uso que corroboren lo que se explico en la parte de implementacion y
diseno de la solucion.
Los objetivos planteados son:
1. Implementacion de un Servidor contenedor de Aplicaciones con middleware orien-tado a mensajes.
2. Brindar tecnologıa necesaria para el control de al menos 2 tipos de fabricantes dis-tintos o 2 modelos distintos de un mismo fabricante por medio de una interfaz web.
3. Reportar el estado de operacion de equipos y servicios a traves de la interfaz web.
4. La plataforma web admitira acceso tanto vıa dispositivos moviles como computadorpersonal.
Para corroborar los objetivos se revisaran capturas de pantalla y casos de uso con que
re�ejen el correcto funcionamiento de la plataforma.
38
6.1 Middleware (Verificacion de resultados y objetivos.)
6.1. Middleware
El servidor que contara con las aplicaciones Java y middleware orientado a mensajes
cuenta con sistema operativo Ubuntu 10.04. Seguido este mismo se levanta el servicio
de middleware, se corrobora esto a traves del navegador Mozilla Firefox con la siguiente
URL donde se levanta el administrador web del broker http://localhost:8161/
admin:
Figura 6.1: Escritorio servidor Wind Ubuntu 10.04.
Ademas el middleware ActiveMQ debe soportar los protocolos conectores tanto de
conexiones Openwire ( para aplicaciones Java), como conexiones STOMP provenientes
del servidor Web ( PHP ), se puede comprobar esto en la pestana Connections de la
interfaz web, ver figura 6.2:
Figura 6.2: Protocolos conectores STOMP y Openwire.
39
6.2 Soporte de equipos y caso de uso (Verificacion de resultados y objetivos.)
6.2. Soporte de equipos y caso de uso
La interfaz web, en conjunto con el servidor Apache, tiene que ser capas de recopilar
informacion de que equipos ( asociados a una cola de procesos Wind ) hay actualmente
en el sistema y brindar soporte para 2 modelos distintos de equipos de una misma marca
o bien 2 marcas distintas de un tipo de equipo en particular.
Para este caso, se implemento la solucion para brindar soporte a 2 modelos de Routers
Cisco, la razon de ello se debe a que dynamips y dynagen permiten virtualizar solamente
modelos de equipos Cisco, aunque si se realizaron pruebas exitosas de conexion y coman-
dos con equipos 3Com reales usando la misma plataforma a bajo nivel usando java y php
en el laboratorio de Administracion de Redes de Telematica.
Como ya se explico en el capıtulo de virtualizacion, usaremos dynagen/dynamips junto
con tunctl para levantar equipos virtuales Cisco modelos c7200 y c3620. Luego de esto y
habiendo ejecutado el Agente y los procesos Wind para cada equipo, podemos corroborar
la presencia de las colas de los 3 procesos en la consola web de ActiveMQ, mostradas en
la figura 6.3:
Figura 6.3: Consola web ActiveMQ.
Veamos un caso de uso desde un dispositivo terminal iPad, que abarque desde la se-
leccion de un equipo Router para configurar la direccion ip de una de sus interfaces de red
40
6.2 Soporte de equipos y caso de uso (Verificacion de resultados y objetivos.)
( asumiendo que previamente se levanto algun proceso Wind desde el lado del servidor y
que el broker de mensajes ActiveMQ se encuentra ejecutandose junto al Agente).
La figura 6.4 muestra el portal de inicio
de la interfaz web Wind. Los modulos ja-
vascript corriendo en el dispositivo permi-
ten capturar eventos al presionar una de las
etiquetas.
Para el caso de este ejemplo selecciona-
remos la etiqueta “Routers”. Esto gati-
llara el envıo de un mensaje SOAP al
Agente consultando la lista de equipos en
el sistema. Figura 6.4: Portal interfaz web Wind parala seleccion de tipos de equipos.
Figura 6.5: Lista de equipos disponibles.
Una vez recibida la respuesta del Agente, la
interfaz visual despliega en el equipo una lis-
ta de botones con los dispositivos de red dis-
ponibles a configurar. Los 2 modelos (C7200
y C3620 de Cisco ) soportados por la aplica-
cion se encuentran disponibles para su admi-
nistracion y configuracion como se muestra
en la figura 6.5.
Presionaremos el primero de la lista (CISCO:C7200:1080) un router Cisco modelo
c7200 con identificador 1080 (este identificador es utilizado para diferenciar este router
con otro del mismo modelo).
41
6.2 Soporte de equipos y caso de uso (Verificacion de resultados y objetivos.)
Figura 6.6: Pagina de control deRouter Cisco, modelo c7200, id=1080.
La figura 6.6 muestra que la pagina desplegada entrega informacion con 3 pestanas de
estado y un menu de funcionalidades que estan soportadas para ejecutar en este dispositivo
( options menu ).
Cada pestana de estado esta encargada de entregar cierta informacion:
1. Interface Status: Relacionado con el estado de las interfaces fastEthernet del equipo.
2. Memory: Memoria utilizada en el equipo.
3. General Status: Estados relacionados a temperaturas y voltajes.
Continuando con el ejemplo, presionaremos el boton Interface Configuration. Esto
hara que se muestre un pop-up, mostrado en la figura 6.7, con las opciones de seleccion
de interfaz a configurar y los parametros que se desean establecer:
42
6.2 Soporte de equipos y caso de uso (Verificacion de resultados y objetivos.)
Figura 6.7: Pop-up de control deinterfaces del Router seleccionado.
Desde aca es posible seleccionar cualquier interfaz ( llamadas FastEthernet ) del router y
configurarla.
Para comprobar el correcto funcionamien-
to de la interfaz web, seleccionamos la in-
terfaz FastEthernet 1/0 y le asignamos la
direccion ip 192.168.10.1 con mascara 24.
Figura 6.8: Configuracion de la interfazFastEthernet 1/0.
43
6.2 Soporte de equipos y caso de uso (Verificacion de resultados y objetivos.)
Luego aplicamos los cambios y volveremos a la pantalla de estados y opciones del
router seleccionado.
Finalmente, el nuevo estatus de la interfaz FastEthernet 1/0 puede observarse en la
ventana Interface Status:
Figura 6.9: Ventana de Interface Status.
Como pudo comprobarse en el caso de uso, los objetivos que abarcan desde el fun-
cionamiento del middleware hasta la administracion de al menos 2 equipos de red, con
algunas funcionalidades generales, se encuentran cubiertos. Futuras funcionalidades no
dependen del desarrollo a bajo nivel, solo basta con agregarlas al XML para que nuevos
mensajes SOAP emitidos desde el servidor Apache (que contiene la pagina web y los
modulos de conexion con el broker ActiveMQ ) puedan ser interpretados por los proce-
sos Wind que interpretaran cualquier paso como un argumento de la sesion Telnet con el
equipo del cual estan a cargo.
44
Capıtulo 7
Conclusiones y Trabajo Futuro
7.1. Conclusiones
Existen muchas alternativas y caminos para crear una solucion a un problema de ad-
ministracion como el que se planteo en este trabajo, pero el gran desafıo, fuera de com-
pletar el desarrollo de esta, era encontrar una manera de que la arquitectura de la solucion
permitiera una modularidad tal, que fuera facil la integracion de nuevas herramientas y
tecnologıas.
Atacando este objetivo, los middleware ayudan de manera impresionante, permitiendo
el desarrollo de diversas aplicaciones aparte de la planteada, ya que la libertad de escoger
cualquier paradigma de programacion y lenguaje, ademas del uso de protocolos conocidos
y no propietarios ( STOMP y Openwire ), abre un gran camino hacia soluciones distribui-
das y complejas.
Gracias al estudio de la mensajerıa basada en SOAP, se logra una solucion de estructu-
45
7.2 Trabajo Futuro (Conclusiones y Trabajo Futuro)
ramiento de mensajes estandarizado y que trae ventajas como: no estar asociado a ningun
lenguaje ( acentuando el hecho de que los middleware no se encuentran ligados a un solo
lenguaje ), no esta atado a ningun protocolo de transporte ya que basicamente es un texto
XML y cualquier protocolo capaz de transmitir texto puede con el, y tambien, por el hecho
de ser estandarizado, cualquier desarrollador que requiera realizar un escalamiento de la
arquitectura de la solucion sabe que la mensajerıa esta basada en SOAP y trabajara con
eso sin tener que depender de protocolos propietarios.
Si bien la solucion final resuelve el problema de unificacion de administracion en equi-
pos de red (Cisco,3com,etc), la arquitectura permite que, manteniendo el middleware y el
servidor Apache, pueda utilizarse para otro tipo de negocios basados en web, e incluso,
si los equipos soportan protocolo Telnet, se mantenga todo igual y solo se modifiquen y
establezcan parametros entre el XML usado por los procesos Wind para interpretar los
mensajes recibidos y los mensajes SOAP enviados desde el servidor Apache.
7.2. Trabajo Futuro
La version final a la cual se llego funciona correctamente, pero existe un problema
grande de seguridad y una limitacion en la cantidad de usuarios que pueden operar con la
plataforma, por lo cual es importante en trabajos futuros:
Brindar soporte para mas administradores de red, ya que actualmente la plataforma
esta pensada para ser usada por uno solo.
Sistema de autenticacion de usuario.
Seguridad basada en SSL.
Mejoras de interfaz visual.
46
Referencias
[1] STOMP:http://stomp.fusesource.org/index.html
[2] STOMP-ActiveMQ:http://activemq.apache.org/stomp.html
[3] Dynamips/Dynagen Tuturial:http://dynagen.org/tutorial.htm
[4] Apache ActiveMQ Proyect:http://activemq.apache.org/
[5] TCP:http://www.cicei.com/ocon/gsi/tut_tcpip/index.html
[6] CISCO:http://www.cisco.com/
[7] W3C Validation Service :http://validator.w3.org/
[8] W3C Soap:http://www.cisco.com/
[9] NetBeans:http://netbeans.org/
[10] CISCO:http://www.cisco.com/
[11] STOMP-PHP:http://php.net/manual/es/book.stomp.php
[12] OpenWire:http://activemq.apache.org/openwire.html
[13] JqueryMobile:http://jquerymobile.com/
[14] Tunctl:http://tunctl.sourceforge.net/
[15] UML-Utilities:linux.about.com
[16] Apache Commons:http://commons.apache.org/
[17] TelnetExamples:twitt88.com
47
Referencias (Referencias)
[18] StackOverFlow:http://stackoverflow.com/
[19] James F. Kurose, Keith W., “Computer Networking”, 6e, Addison-Wesley, 2012
[20] Java Device Manager Fuente Screenshot
[21] CISCO SDM http://www.netralized.com
[22] Middleware:Taxonomıa Middlewares
[23] Bridge:Fuente diagrama
48
Anexos A
Arranque de la Plataforma WIND
En este anexo se explica todo lo necesario para la ejecucion de la plataforma WIND.
Para archivos de configuracion e instalacion de bibliotecas necesarias, ir al Anexo B.
A.1. Servidor Apache
La interfaz web y las aplicaciones PHP fueron montadas en un PC con sistema opera-
tivo Linux Ubuntu 10.04. El servidor contenedor de paginas web escogido fue Apache2.
Para su instalacion y ejecucion en ubuntu los pasos a seguir en consola de comandos son:
1 $ sudo ap t−g e t i n s t a l l apache2
$ sudo ap t−g e t i n s t a l l php5 l i b a p a c h e 2 −mod−php5 php5−gd php5−dom
3 $ sudo / e t c / i n i t . d / apache2 r e s t a r t
Por defecto Apache2 almacena sus paginas web en el directorio /var/www donde de-
berıan ir todos los archivos php y html. La interfaz web se encuentra contenida en la
carpeta WWW/WIND, por lo cual se tiene que copiar su contenido donde Apache2 lea el
index.html, para este caso, /var/www.
49
A.2 Middleware Apache ActiveMQ ( Arranque de la Plataforma WIND )
A.2. Middleware Apache ActiveMQ
ActiveMQ no requiere instalacion, la carpeta “ANEXO/apache-activemq-5.6.0”, con-
tiene todo lo necesario para su ejecucion, solo basta con ejecutar dentro de la carpeta ya
senalada el siguiente comando:
1 $ b i n / a c t i v e m q s t a r t
Si todo sale bien, se levantara el broker en el servidor de manera local.
Figura A.1: Screenshot consola Ubuntu 10.04.
ActiveMQ esta desarrollado en Java, por lo cual si no es encontrada la PATH de Java
se requiere agregar esta variable de entorno de la siguiente forma:
Ejecutar como root: vi /.bashrc
1 $ sudo v i ˜ / . b a s h r c
Agregar al final del archivo las siguientes lineas:
1 JAVA HOME= ” r u t a JDK de j a v a ”
e x p o r t JAVA HOME
3 PATH=$PATH : $JAVA HOME/ b i n
e x p o r t PATH
Eso es todo, solo falta reiniciar o simplemente abrir un nuevo terminal. Para probar si todo
va bien, ejecutar :
$ echo $JAVA HOME / / p a r a v e r i f i c a r s i s e c r e o e l j a v a home
2 $ echo $PATH / / p a r a v e r i f i c a r s i e s t a en l a p a t h
50
Anexos B
Instalacion de bibliotecas y equipos de
prueba
B.1. Agregando extencion STOMP a PHP
Si PHP esta instalado, es posible agregar bibliotecas directamente para no realizar
includes dentro de cada archivo donde se utilizaran las funciones de estas.
Para poder instalar extensiones se requiere el programa PEAR. Este programa tiene
una dependencia, la cual debemos instalar de la siguiente forma:
$ sudo ap t−g e t i n s t a l l php5−dev
2 $ sudo ap t−g e t i n s t a l l php−p e a r
Ahora para instalar la extension stomp-php, necesitamos copiar el archivo stomp-
1.0.3.tgz del CD al disco duro del equipo donde queremos instalarla y ejecutamos:
51
B.2 Virtualizacion de equipos CISCO ( Instalacion de bibliotecas y equipos de prueba )
sudo p e a r i n s t a l l stomp −1 . 0 . 3 . t g z
Luego de terminar nos dira que agreguemos extension=stomp.so al archivo php.ini
contenido en la carpeta /etc/php5/apache2/ y /etc/php5/cli/, abrimos el archivo y agrega-
mos:
1 [STOMP Connec to r ]
e x t e n s i o n =stomp . so
B.2. Virtualizacion de equipos CISCO
Para poder virtualizar equipos, primero es necesario tener instalado uml-utilities, para
ello ejecutar en el terminal de Ubuntu:
$ sudo ap t−g e t i n s t a l l uml− u t i l i t i e s
Finalizado este proceso ya es posible crear interfaces de red virtuales y asignarles ip.
Con ellas, conectaremos a traves de dynagen estas interfaces tap a las interfaces FastEt-
hernet 0/0 de los routers a emular ( c7200 y c3620 de cisco ).
Ahora, para levantar los equipos y realizar todas las conexiones necesarias para trabajar
con los routers, solo basta con entrar a la carpeta Routers ( contenida en el CD, copiar a
disco duro antes de correr los scripts ) y ejecutar:
1 $ . / r o u t e r s . sh
Para terminar la ejecucion de todo, simplemente en la consola de dynagen escribir “exit”.
Esto finalizara el proceso de emulacion, pero las interfaces de red virtuales seguiran crea-
das, para eliminarlas ejecutar dentro de la carpeta Routers:
1 $ . / k i l l r o u t e r s . sh
52
Anexos C
Configuraciones Especiales
C.1. Archivo de configuracion ActiveMQ
El archivo de configuracion de ActiveMQ (activemq.xml) se encuentra en la ruta
apache-activemq-5.6.0/conf/. Este archivo contiene solo 2 modificaciones con respecto
a la version original incluida por defecto en el software. La primera relacionada con la
especificacion de los protocolos de conexion a utilizar (STOMP y OpenWire):
1 < t r a n s p o r t C o n n e c t o r s>
< t r a n s p o r t C o n n e c t o r name=” openwi re ” u r i =” t c p : / / 0 . 0 . 0 . 0 : 6 1 6 1 6 ” />
3 < t r a n s p o r t C o n n e c t o r name=” stomp ” u r i =” stomp : / / 0 . 0 . 0 . 0 : 6 1 6 1 3 ” />
< / t r a n s p o r t C o n n e c t o r s>
Y una polıtica para eliminar colas que no estan siendo usadas por mas de 5 segundos
en el broker:
<p o l i c y E n t r y queue =”>” g c I n a c t i v e D e s t i n a t i o n s =” t r u e ”
i n a c t i v e T i m o u t B e f o r e G C =”5000”/>
53
C.2 Configuracion de Routers Virtualizados (Configuraciones Especiales)
Para acceder a la consola web, la url por defecto es localhost:8161.
C.2. Configuracion de Routers Virtualizados
Configuracion previa para router Cisco modelo c7200:
1 Router>e n a b l e
Ro u t e r # con f t
3 Ro u t e r ( c o n f i g ) # l i n e v t y 0 4
Ro u t e r ( c o n f i g− l i n e ) # password c i s c o
5 Ro u t e r ( c o n f i g− l i n e ) # e x i t
Ro u t e r ( c o n f i g ) # e n a b l e password c i s c o
7 Ro u t e r ( c o n f i g ) # i n t e r f a c e F a s t E t h e r n e t 0 / 0
Ro u t e r ( c o n f i g− i f ) # i p a d d r e s s 1 0 . 1 0 0 . 1 0 0 . 1 2 5 5 . 2 5 5 . 2 5 5 . 0
9 Ro u t e r ( c o n f i g− i f ) # no shutdown
Configuracion previa para router Cisco modelo c3620:
1 Router>e n a b l e
Ro u t e r # con f t
3 Ro u t e r ( c o n f i g ) # l i n e v t y 0 4
Ro u t e r ( c o n f i g− l i n e ) # password c i s c o
5 Ro u t e r ( c o n f i g− l i n e ) # e x i t
Ro u t e r ( c o n f i g ) # e n a b l e password c i s c o
7 Ro u t e r ( c o n f i g ) # i n t e r f a c e F a s t E t h e r n e t 0 / 0
Ro u t e r ( c o n f i g− i f ) # i p a d d r e s s 1 9 2 . 1 6 8 . 2 . 1 2 5 5 . 2 5 5 . 2 5 5 . 0
9 Ro u t e r ( c o n f i g− i f ) # no shutdown
54