Evaluación de alternativas en la aplicación de Spanning Tree Protocol

Transcripción

1 Proyecto final de carrera: Evaluación de alternativas en la aplicación de Spanning Tree Protocol Universidad de Sevilla Escuela Superior de Ingenieros Departamento de Ingeniería de Sistemas y Automática Área de Ingeniería Telemática Autor del Proyecto: David Romero Moya Tutor del Proyecto: Rafael Mª Estepa Alonso Curso:2007/08 1

2 2

3 Índice 1 Introducción y objetivos Situación actual de la red Spanning Tree Protocol (STP) Propuestas alternativas Rapid Spanning Tree Protocol (RSTP) Multiple Spanning Tree Protocol (MSTP) Metodología Herramientas Configuración de los escenarios Configuración de las Aplicaciones y Perfiles Configuración de las Usuarios Configuración de los Servidores Configuración de los Enlaces Configuración STP Configuración RSTP Configuración MSTP Configuración Enlaces de Acceso Configuración Enlaces Trunk Consola Opnet Definición y localización de la información deseada Creación y substitución de la Consola Opnet Simulación Simulación STP Simulación RSTP Simulación MSTP Presentación de la información Resultados Resultados STP Resultados RSTP Resultados MSTP Conclusiones Referencias

4 1 Introducción y objetivos La rápida evolución a la que están sometidas las nuevas tecnoligías en el mundo de las telecomunicaciones, provoca que en periodos cortos de tiempo, las grandes o pequeñas empresas e incluso los particulares se vean obligados a renovar las tecnologías o programas que hasta ese momento utilizaban, para poder sacar el máximo provecho a los servicios que ofrecen los mismos. La motivación principal para el desarrollo de este proyecto final de carrera y por consiguiente el estudio que él mismo conlleva, es la necesidad de mejora de las infraestructuras de telecomunicaciones de la empresa Persan, promovido por su evolución tanto en tamaño y cantidad de prestaciones que demanda como en la obsoletización que sufrían sus instalaciones debido al transcurso del tiempo y de la rápida evolución en el sector de las telecomunicaciones. El estudio que se va a realizar en este proyecto tiene 2 objetivos fundamentales: el primero de ellos es el análisis de los distintos protocolos que se encargan de comunicar los conmutadores de la red, evitando la formación de bucles y controlando el exceso de tiempo tomado tanto en la creación del árbol de expansión como de reconfiguración en caso de que se produjera la caída de un enlace o la parada de un conmutador, el segundo objetivo será determinar la topología que mejores resultados, a nivel de tiempo de respuesta, ofrezca en combinación con los protocolos de encaminamiento. Los protocolos que se estudiarán y analizarán en este proyecto final de carrera son: el STP, actualmente utilizado por la empresa Persan, sus siglas significan Spanning Tree Protocol, el RSTP o Rapid Spanning Tree Protocol y el MSTP o Multiple Spanning Tree Protocol. El fundamento principal de estos protocolos es la creación, en una red compuesta por bridgets o conmutadores, de un árbol de expansión evitando de esta forma la creación de bucles y permitiendo la reconfiguración del árbol si se produjese un fallo en un enlace o en un puente. Es parte del alcance de este proyecto demostrar que tanto STP como RSTP utilizan un único árbol de expansión para toda la red con un nodo como nodo raíz del cual saldrán todas las ramas del árbol, esto provocará que si se detectara algún fallo en la red la reconfiguración del único árbol existente afectaría a todos los nodos de la red. Otra de las partes del alcance será ver el funcionamiento de MSTP, como podrá contrastarse mas adelante, se diferencia de los anteriores en el número de árboles que son configurados, ya que la metodología de este protocolo permite dividir la red en diferentes VLANs permitiendo por ejemplo la creación de un árbol por cada una de ellas, esto reduciría el tiempo de respuesta ante un fallo ya que sólo se vería afectado el árbol que perteneciera al dominio de la VLAN que haya sufrido la caída. Otro de los puntos que se van a tener en consideración en el alcance de este proyecto, es el rol que ejercen los puertos de los correspondientes conmutadores que forman la red. En posteriores apartadas se podrá analizar con detalle que dependiendo del protocolo que se esté utilizando para la configuración de la red, los puertos tomarán ciertos valores, también conocidos como estados, lo que permitirá observar una variación tanto en los tiempos de formación del árbol principal como en los tiempos de reconfiguración tras la localización de un fallo en la red. Una vez definidos y diferenciados los distintos protocolos, se podrá observar de forma práctica como influye el uso de los mismos en el tiempo de restauración de un enlace ante un fallo o simplemente en el tiempo que se tarda en crear el árbol de expansión, ya que tal y como se puede observar en las referencias [4] y [5], el tiempo del protocolo STP ronda las decenas de segundos, mientras que los tiempos entre los protocolos RSTP y MSTP son del orden de los milisegundos, quedando para estos últimos la duda de si la diferencia entre milisegundos compensa la mayor complejidad de MSTP sobre RSTP. 4

5 Para poder llevar a cabo todas las comprobaciones mencionadas en los párrafos anteriores y poder alcanzar los objetivos que se marcan, va a ser necesaria la utilización de un programa que permita la emulación de una red real con las características que en todo momento se necesiten determinar. Este programa es conocido con el nombre de Opnet, en apartadas posteriores se mostrará con todo detalle como se consigue emular la topología elegida con las variadas combinaciones y características que permiten los distintos protocolos. Para poder adquirir la información que se necesita y poder llegar a los objetivos definidos para este proyecto, no sólo será necesario el manejo de Opnet para crear y definir los escenarios oportunos, sino también el uso y la modificación de la Consola que utiliza Opnet para simular los escenarios creados. Esto será viable a través del uso de 3 herramientas. La primera de ellas es Cygwin que nos permitirá crear un entorno Linux bajo Windows, que a su vez permitirá trabajar con la segunda herramienta conocido con el nombre de Emacs. Emacs es un editor de texto del que se hará uso para poder adquirir la información de la consola de forma automatizada, y una vez adquirida la información se utilizará la última herramienta conocida con el nombre AWK. AWK es un lenguaje de programación diseñado para procesar datos basados en texto y que permitirá mostrar los resultados obtenidos de forma clara y concisa. 2 Situación actual de la red En este apartado se va a determinar la situación sobre la que el proyecto parte para poder realizar y alcanzar los objetivos propuestos. La empresa Persan está situada en una nave de un polígono industrial a las afueras de Sevilla, las dimensiones de las que hace uso son de unas 3 veces un campo de fútbol, en este espacio Persan dispone de 18 departamentos. Cada uno de los departamentos esta compuesto por trabajadores que acceden a los servicios que necesitan a través de un conmutador situado en su misma zona y que a su vez se comunica con el conmutador raíz o root, en terminología de los protocolos de encaminamiento que se van a utilizar, para poder acceder a los servidores que ofrecen los servicios demandados por los trabajadores. Los departamentos en los que está dividida la empresa Persan son: CPD, Oficinas, Envasado, Muelles, Alm. P.T.1, HDL, Soplado, Pta. Trasera, Torre, Alm. MPEE1, Taller, Depósitos, Soplado2, Muelles2, Alm. P.T.2, Alm. Automat.1, Alm. Automat.2 y Alm. MPEE2. En cada uno de ellos la distribución de los trabajadores es respectivamente: 3, 75, 10, 15, 5, 5, 5, 10, 5, 60, 15, 10, 15, 5, 10, 10 y 5 personas. Cuando la empresa Persan se pone en contacto con el Departamento de Telemática de la Escuela Superior de Ingenieros de Sevilla, los 18 conmutadores que forman su red trabajan bajo el protocolo STP y las conexiones entre departamentos son las que se muestran en la Figura 1. 5

6 Figura 1 Las líneas en rojo equivalen a las conexiones físicas entre los distintos conmutadores y los usuarios que trabajan en cada departamento se ven representados en formato de LANs. Llegados a este punto es necesario explicar el funcionamiento del protocolo STP, para poder demostrar de forma feaciente las limitaciones en las que la empresa Persan está sumergida y sobre las cuales este proyecto final de carrera trabajará para mejorar. 2.1 Spanning Tree Protocol (STP) Spanning Tree Protocol o también conocido por su acrónomo STP es un protocolo de red de la segunda capa del modelo OSI, del nivel de enlace de datos. Fue diseñado por Radia Perlman cuando estuvo trabajando para DEC. En la actualidad existen 2 tipos de versiones de STP: la original, conocida como DEC STP y la estandarizada por el IEEE, conocida también como IEEE 802.1D. Las dos versiones no son compatibles entre si, la versión que se recomienda utilizar en la actualidad y de la que se hablará en este proyecto final de carrera a partir de este momento será la estandarizada IEEE 802.1D. Su objetivo es que los conmutadores sean capaces de descubrir de forma dinámica topologías sin bucles que aseguren la conexión. STP permite activar y desactivar automáticamente los enlaces de conexión, matizar que los enlaces de conexión son parejas de puertos, uno a cada extremo, sobre los que se determina su estado, de forma que se garantice que la topología esté libre de lazos. Destacar que STP es transparente a las estaciones de usuarios. Los lazos o bucles se dan cuando existen rutas alternativas, estas rutas son necesarias para proporcionar redundancia, ofreciendo una mayor fiabilidad, dotando a la red de una alternativa para que 6

7 otro enlace sea capaz de soportar el tráfico. La necesidad de poder evitar y detectar un lazo en la creación de la topología viene dada por la falta de existencia del campo TTL (Time To Live, Tiempo de Vida) en la capa 2 a diferencia de la capa 3, lo que conlleva a un gran consumo de ancho de banda, y en muchas ocasiones a que la red quede inutilizada. STP permite solamente una trayectoria activa a la vez entre dos dispositivos de la red, pero mantiene los caminos redundantes como reserva, para activarlos en caso de que el camino inicial falle. Para poder conseguir estos servicios el protocolo STP hace uso de unas tramas denominadas Configuration Bridget Data Unit, CBPDU o simplemente BPDU, las BPDUs son mensajes encapsulados en tramas LLC y enviados a un DSAP ( ) que es interpretado por todos los puertos. El protocolo establece identificadores de puentes, ID con independencia de las direcciones MAC de sus puertos, y elige el conmutador que tiene la prioridad mas alta, el número mas bajo de prioridad numérica, como puente raíz o root. Este puente raíz establece los caminos de menor coste para toda la red, esto es posible gracias a que todos los puertos que componen un conmutador disponen de un parámetro configurable conocido con el nombre de Span Path Cost. Inicialmente, todos los conmutadores consideran que son el puente raíz, esto conlleva que cuando un conmutador se enciende envía las BPDU que contienen coste 0 y la dirección MAC de si mismo tanto en el ID de raíz como de emisor. Los puentes almacenan las mejores BPDU que recibe por el mismo puerto. Para poder determinar cual es la mejor de todas, realizan un estudio comparativo entre las que ha recibido por el mismo puerto y la suya propia. Cada conmutador reemplazará los ID de raíz mas alta por ID de raíz mas baja en la BPDU que se envían. Cuando un puente recibe una BPDU por un puerto que mejora la BPDU que él envía, deja de enviar BPDU por ese puerto. Gracias a esta característica cuando el algoritmo se ha estabilizado, sólo un puente en cada LAN, denominado puente designado, enviará BPDU en dicha LAN. Para poder calcular la BPDU que envía un puente, es necesario calcular el RootID y el coste hacia el nodo raíz, lo cual se realiza en función de las BPDU recibidas por los puertos y la suya propia. El RootID será el menor de todos los BPDU recibidos por el puente, incluyendo el suyo propio. El coste hacia el puente raíz será 0, en otro caso el coste será la suma del coste de los mejores y el coste por el que llegar hasta el puente por el que se recibió dicha BPDU. El puerto por el que se ha recibido dicha BPDU es considerado como puerto raíz. Llegado el momento en el que un puente sabe cual es su propio coste y RootID, compara su propia BPDU con la mejor recibida por cada puerto, considerándose puente designado para aquellos puertos que ofrecen una peor BPDU, y transmitiendo en consecuencia su propia BPDU por esos puertos. Los campos de datos de una BPDU son: Root ID: ID del puente raíz. Transmitting Bridget ID: ID del puente que envía la BPDU. Cost: Coste del camino de menor coste para llegar hasta el puente raíz. 7

8 Mencionar que el valor por defecto en la prioridad de un conmutador está estipulado con un valor de 32768, y que el administrador de la red puede disminuir este valor, lo que hará que el ID de ese conmutador sea más pequeño.una vez realizados los pasos anteriormente mencionados, el algoritmo STP logra realizar una topología libre de bucles convirtiendo una red física en forma de malla, en una red lógica en forma de árbol. La necesidad de mantener esta topología sin bucles y sin fallos tanto en los conmutadores como en los enlaces, hace necesaria asociar un campo a las BPDU, este campo es conocido con el nombre de message age, el cual ve incrementado su valor en cada unidad de tiempo. Cuando dicho campo alcanza un valor máximo, max age, la BPDU se descarta y el conmutador recalcula considerando que dicha BPDU no ha llegado nunca. Cuando la red está funcionando de forma normal, el puente raíz transmite de forma periódica, cada 2 segundos por defecto, una BPDU de nombre Hello Time, generada con edad 0. De la misma forma, y para que la información de que la red está funcionando de un modo correcto se expande por todo el árbol, cuando un puente recibe la BPDU del raíz, envía su propia BPDU por aquellos puertos por los que es considerado puente designado con edad 0. En el caso en el que fuera detectada una anomalía en el comportamiento de la red, transcurriría cierto tiempo hasta que todos los conmutadores que componen la red se percataran de ello, en ese transcurso de inestabilidad es necesario que ningún conmutador intente enviar ninguna BPDU con el RootID como él mismo, porque esto podría crear bucles en la topología. Para evitar este tipo de situaciones conflictivas los puertos deben de realizar transiciones entre diversos estados, tal y como se muestra en la Figura 2. En el estandar 802.1D se definen 5 estados en los que un puerto puede encontrarse: Blocking o Bloqueado: En este estado sólo se pueden recibir BPDUs. Las tramas de datos se descartan y no se actualizan las tablas ARP. Listening o de Escucha: A este estado se llega desde Bloqueo. En este estado, los conmutadores determinan si existe alguna otra ruta hacia el puente raíz. En el caso que la nueva ruta tenga un coste mayor, se vuelve al estado de Bloqueo. Las tramas de datos se descartan y no se actualizan las tablas ARP. Se procesan las BPDU. Learning o Aprendizaje: A este estado se llega desde Escucha. Las tramas de datos se descartan pero ya se actualizan las tablas de ARP, ya se aprenden las direcciones MAC. Se procesan las BPDU. Forwarding o Envío: A este estado se llega desde aprendizaje. Las tramas de datos se envían y se actualizan las tablas ARP. Se procesan las BPDU. Disabled o Desactivado: A este estado se llega desde cualquier otro. Se produce cuando un administrador deshabilita el puerto o éste falla. No se procesan las BPDU. 8

9 Figura 2 Los conmutadores que forman la red, se percatan de que existe algún tipo de fallo en ella cuando el protocolo STP provoca la entrada o la salida de alguno de sus puertos en el estado de Blocking, esta situación la hace saber a los demás conmutadores trasmitiendo por su nodo raíz una BPDU de Hello Time. Esta acción será repetida por al conmutador hasta que reciba un asentimiento. Cuando el conmutador que está conectado al anterior recibe la BPDU por su puerto designado, realiza la misma operación notificando a los demás del cambio de topología que se ha realizado en la red. Cuando la BPDU llega al nodo raíz, este comunica con una BPDU que se procede a un cambio de topología durante un periodo de tiempo igual a la suma de los parámetros fordward delay y max age. Los puentes que reciben una BPDU de cambio de topología utilizan la caché de corta duración para la tabla de reenvío hasta el momento en el que deja de recibir BPDU con la indicación de cambio de topología [1][2][4]. Los parámetros que son estipulados por el puerto raíz en el periodo de cambio de topología y que son enviados a través de las BPDU para que todos los utilicen son: Max Age: Tiempo hasta descartar una BPDU. Hello Time: Intervalos entre envíos de BPDU. Forward Delay: Tiempo que debe transcurrir en el estado de listening y learning. 9

10 A parte de los parámetros nombrados anteriormente existen otros que son configurables en los conmutadores: Bridge Priority, Port Priority, Long Cache Timer y Path Cost. De todos los mencionados en los párrafos anteriores, el único que se va a manipular en los estudios realizados en este proyecto final de carrera será el de Hello Time, el cual por defecto tiene el valor de 2 segundos y nosotros lo modificaremos a 1 segundo, modificación que se podrá comprobar en las capturas del programa Opnet. En el tiempo de adaptación que necesita el protocolo STP es donde Persan nos permite definir un objetivo para mejorar su red. El tiempo medio de establecimiento del árbol de expansión y de reacción a un fallo, de una red que basa su topología lógica en el protocolo STP es de entre 30 y 60 segundos, dependiendo de la red y teniendo en cuenta los valores por defecto de los anteriores parámetros. Esto es uno de los puntos negativos del protocolo STP que se van a subsanar en este proyecto final de carrera, permitiendo una mejora substancial a la empresa Persan [2]. 3 Propuestas alternativas Una vez vista la situación actual de la empresa Persan, y con ello las limitaciones que conlleva el uso del protocolo STP, se dispondrá a explicar de forma clara y concisa, enfocando siempre al objetivo y al alcance de este proyecto, las diferentes alternativas propuestas para substituir al protocolo STP y las herramientas necesarias que se han tenido que utilizar para ello. Aunque no haya sido uno de los objetivo de este proyecto, en el trabajo de todo Ingeniero, es necesario crear una balanza entre lo que es óptimo a nivel tecnológico y lo que es a nivel económico mas atractivo al inversor o cliente. En este caso los conmutadores que forman la red física de la empresa Persan, son capaces de soportar tanto el protocolo actual STP, como los protocolos que se proponen como alternativas a ellos, como es el caso de RSTP y el MSTP. Esto hace de esta propuesta, una propuesta muy favorable al empresario a nivel económico, y como veremos mas adelante también a nivel práctico y tecnológico. 3.1 Rapid Spanning Tree Protocol (RSTP) El protocolo RSTP está especificado en la IEEE 802.1w, es una evolución del protocolo Spanning Tree Protocol, STP. En la edición 2004 del estandar IEEE 802.1D, incorporaba IEEE 802.1t-2001 y el estandar IEEE 802.1w. Muchas de las terminologías utilizadas en el protocolo STP son principalmente las mismas en el protocolo RSTP. La mayoría de los parámetros han sido mantenidos con lo que usuarios familiarizados con 802.1D pueden rápidamente configurar el nuevo protocolo de forma sencilla. Los estados de los puertos en el protocolo RSTP han variado, ya no existen 5 tipos de estados, ahora hay 3 tipos que corresponden con los tres posibles estados de operación. Los estados Blocking, Disabled y Listening en el protocolo STP se ven fusionados en el estado Discarding del protocolo RSTP. El rol es ahora una variable que cada uno de los puertos tiene asignado. Los roles de puerto raíz y el de puerto designado se mantendrán, mientras que el de puerto bloqueado ahora pasará a ser el de backup o puerto alternativo. El algoritmo de Spanning Tree, STA, determina el rol de un puerto basándose en las BPDUs. Con la intención de simplificar los problemas, lo que hay que recordar de una BPDU es que hay siempre un método para comparar cualquiera de los dos y decidir si uno es mas adecuado que el otro. Esto se basa en el valor almacenado en la BPDU y ocasionalmente en el puerto en cual haya sido recibida. Se considera, que la información en esta sección explica los roles de los puertos con un enfoque muy práctico. 10

11 Los puertos que reciben las mejores BPDUs en un puerto se clasifican como puertos raíz. Este es el puerto mas cercano al puente raíz, en términos de coste en el trayecto. El STA selecciona un simple puente como puente raíz, de todos los que forman la red, por VLAN. El puerto raíz envía BPDUs, las cuales son mucho mas útiles que las que pueda enviar cualquier otro puente de la red. El puente raíz es el único puente en toda la red que no tiene un puerto raíz. Todos los demás puentes reciben BPDUs por al menos un puerto. Los puertos serán de carácter designado si este puede enviar la mejor BPDU en el segmente de red al cual esté conectado. Los puentes 802.1D unen juntos diferentes segmentos, tales como segmentos Ethernet, para crear un dominio perteneciente a un puente. En un segmento dado, puede haber solamente un único camino hacia el puente raíz. Si existen dos, hay un bucle en la red. Todos los puentes conectados a un segmento dado, escuchan las BPDUs de cada uno de ellos y consienten al puente que manda mejores BPDUs como puente designado para el segmento. El puerto en ese puente correspondiente es un puerto designado. Existen dos roles de puertos correspondientes al estado bloqueado de 802.1D. Un puerto bloqueado es definido como un puerto que no es designado como puerto raíz o puerto designado. Un puerto bloqueado recibe BPDUs mas importantes y necesarias de las que el manda en su propio segmento. Recordemos que un puerto necesita absolutamente recibir BPDUs con la intención de estar bloqueado. RSTP introduce estos dos roles o papeles para este propósito. Un puerto alternativo recibe BPDUs mas importantes y provechosas de otros puentes y es un puerto bloqueado. Un puerto backup recibe BPDUs mas importantes y con mayor carga de información desde el mismo puente por el que está conectado, es un puerto bloqueado. Esta distinción está realmente realizada internamente en el 802.1D. La base lógica es que un puerto alternativo proporciona un camino alternativo hacia el puente raíz por tanto puede reemplazar al puerto raíz si este falla. Por supuesto un puerto backup proporciona redundancia en la conectividad hacia el mismo segmento y no puede garantizar una conectividad alternativa hacia el puente raíz. Por lo tanto, está excluido del grupo de enlaces de subida. Una vez establecida la topología lógica de la red, las BPDU son enviadas cada Hello Time, y ya no sólo transmitidas. Con 802.1D, un nodo que no sea el nodo raíz solamente genera BPDUs cuando recibe una por su puerto raíz. De hecho, un puerto retransmite mas BPDUs de las que realmente el mismo genera. Este no es el caso de 802.1w. Un puerto ahora envía BPDUs con su correspondiente información cada Hello Time, por defecto 2 segundos, incluso si este no ha recibido ninguna de su puente raíz. En un puerto dado, si los mensajes Hello no son recibidos en unos tres tiempos consecutivos, la información del protocolo puede ser inmediatamente la de caducidad, también se puede dar el mismo caso si Max Age llega a expirar. Debido a la previa modificación del protocolo mencionada anteriormente, las BPDUs son usadas ahora como mecanismos para mantener con vida los mecanismos entre dos puentes. Un puente considera que ha perdido la conectividad con su puente vecino mas directo si este pierde tres BPDUs seguidas. Este rápido envejecimiento de la información permite determinar de forma rápida los fallos. Si un puente falla al recibir BPDUs desde un vecino, esto significa de forma muy clara que la conexión con ese vecino se ha perdido. Esto es opuesto al procedimiento que se toma en 802.1D donde el problema podía ser en cualquier parte del trayecto hacia el puente raíz. 11

12 El concepto que hace que se pueda crear el corazón del motor de la terminología conocida como BackboneFast, es la aceptación de BPDUs inferiores. El comité de IEEE 802.1w decidió incorporar un mecanismo similar en RSTP. Cuando un puente recibe información inferior de sus puertos designados o de su puerto raíz, este inmediatamente los acepta o reemplaza la información que previamente tiene almacenada. La rápida transición al estado de Forwarding es la mayor y mas importantes de las características introducidas por 802.1w [4]. El legado de la STA que esperaba de forma pasiva a la convergencia de la red antes de pasar a un puerto al estado Forwarding. El éxito de conseguir una mas rápida convergencia de la red fue un problema de modificar los parámetros por defecto, como Forward Delay y Max Age, y a menudo poner la estabilidad de la red en juego. El nuevo RSTP está capacitado para activamente confirmar que un puerto puede sin incidentes transicionar al estado de Forwarding sin tener que depender de ningún tiempo de configuración. Ahora hay realmente un mecanismo de retroalimentación que toma lugar entre los puentes RSTP. Con la intención de alcanzar una mayor velocidad en la convergencia de puertos, el protocolo cuenta con dos nuevas variables: edge port o puerto borde y link type o tipo de enlace [3]. En conclusión: los puertos raíz y los designados forman parte de la topología activa. Los puertos alternativos y de respaldo no están incluidos en la topología activa de la red. RSTP monitoriza el estado de todas las trayectorias [3]: Si una dirección activa se cae, RSTP activa las direcciones redundantes. Configura de nuevo la topología de la red adecuadamente. RSTP es una versión mejorada del STP y sus objetivos son: Disminuir el tiempo de convergencia cuando un enlace falle. De 30 ó 60 segundos a milisegundos. Soporta redes extendidas conexiones o 4096 puertos interconectados en comparación con 256 puertos conectados en STP. Compatibilidad con STP. Permite transmitir directamente desde el segundo 0, ya que sus puertos por defecto comienzan en el estado Forwarding y van modificando su estado según se forma el árbol. 12

13 3.2 Multiple Spanning Tree Protocol (MSTP) IEEE 802.1s Multiple Spanning Tree Protocol usa el concepto de LAN virtual (VLAN), el cual es una colección de múltiples LANs que se encuentran conectadas físicamente a una red compartida y operan como si todas esas redes múltiples estuvieran conectadas virtualmente como una sola LAN. MSTP permite solamente 4096 VLANs en una red debido a los 12 bits del VLAN ID definidos por IEEE 802.1Q. MSTP introduce el concepto de región y cada región dispone de su propia VLAN asignada. Una región representa un grupo de switches que tienen el mismo identificador de región y la misma VLAN asignada. Cada región dispone de sus instancias MST, multiple spanning tree. El rol de las instancias MST es optimizar la utilización de la red, mientras que las regiones MST pueden ser usadas para incrementar la escalabilidad de la red, también pueden ser utilizadas para mejorar el tiempo de reacción en caso de fallo en la red. Las regiones están conectadas directamente con una instancia central del STP. Dentro de una región MST, posiblemente haya varias instancias MST. El protocolo MSTP proporciona un máximo de 64 instancias de árbol de expansión en una región [5]. Tanto STP como RSTP utilizaban un único árbol de expansión. MSTP define árboles de expansión y mapea cada VLAN con un único árbol de expansión. Una puede tener un árbol de expansión por cada VLAN o múltiples VLANs pueden ser mapeadas en un simple árbol de expansión. Este protocolo está diseñado de tal forma, que la peor de las situaciones vinculadas con la dimensión de la red, sea tomada en cuenta para fijar los tiempos de reconstrucción del árbol de expansión en caso de fallo, que como se mencionó en el caso de STP es de 30 a 60 segundos en condiciones normales. El uso de MSTP permite la utilización de todos los enlaces que serían de lo contrario inutilizados por el árbol simple de expansión y de ese modo elimina la pérdida de ancho de ancho de banda. Sin embargo, el árbol de expansión construido en una región sigue esencialmente el protocolo RSTP y eso conlleva, de forma inherente, a que los tiempos de restauración sean los de RSTP, pero en este caso vinculados con el tamaño de la VLAN en la que nos encontramos. Además, el proceso básico de aprendizaje asocia las direcciones MAC con puertos/enlaces de tal forma que si un enlace falla causaría que los puentes irían a una reasignación de VLAN si el tráfico fuera a ser mapeado hacia un árbol de expansión alternativo [4]. Una particularidad que hay que tener en cuenta cuando hablamos de MSTP, es el uso de VLANs, lo que provoca que necesitemos etiquetar de forma distinta los mensajes pertenecientes a una VLAN o a otra, para poder discriminarlos llegado el momento. La necesidad de etiquetar los mensajes hace necesario comunicar los conmutadores de forma que dejen pasar todos los mensajes independientemente de a que VLAN pertenezcan para que la red trabaje de forma unida. Esto es posible si identificamos los enlaces/puertos entre conmutadores como enlaces Trunk, lo que nos permitirá discriminar los paquetes que nos interesen en el conmutador, dejándolos pasar por los puertos que correspondan a la VLAN deseada. Un enlace Trunk permite pasar todos los paquetes independientemente de la VLAN a la que pertenezcan, ver Figura 3, [6]. 13

14 Figura 3 El resto de enlaces/puertos serán enlaces de acceso que dejarán pasar solamente los mensajes relacionados con la VLAN a la que pertenezca, ver Figura 4 y Figura 5. Figura 4 14

15 Figura 5 Para poder introducir los roles que un puerto puede tener en MSTP es necesario introducir ciertas nomenclaturas que se realizarán de forma descriptiva. MSTP permite asignar estructuras a diferentes VLANs para poder seguir caminos separados, cada uno de ellos basado en un Multiple Spanning Tree Instance (MSTI), dentro de un Multiple Spanning Tree (MST) Regions compuesta por LANs y o puentes MST. Estas regiones y los otros puentes y LANs están conectadas en un single Common Spanning Tree (CST) [7]. MSTP conecta todos los puentes y LANs con un single Common and Internal Spanning Tree (CIST). El CIST soporta la determinación automática de cada región MST, eligiendo su máxima posible extensión. Los roles de los puertos CIST que identifican el rol en la topología activa que se utiliza por cada puerto en un puente, son: El puerto raíz, que proporciona el camino de mínimo coste desde el puente hasta el raíz CIST, siempre que el puente no sea el raíz CIST, atravesando el raíz regional, siempre y cuando el puente no sea un raíz regional. Un puerto designado, proporciona el camino con menor coste desde la LAN adjunta a través del puente hacia el raíz CIST. El puerto alternativo o backup, que proporcionan conectividad si otros puentes, puertos puente, o LANs fallan o son eliminadas. Los roles de los puertos MSTI que identifican el rol activo para cada puerto en cada puente en cada topología activa de las MSTIs dentro y en las fronteras de una región, son: El puerto raíz, que proporciona el camino de mínimo coste desde el puente hasta el raíz MSTI regional, siempre que el puente no sea el raíz regional para esta MSTI. Un puerto designado, proporciona el camino con menor coste desde la LAN adjunta a través del puente hacia el raíz regional. Un puerto master, proporciona conectividad desde la región hasta el raíz CIST que permanece fuera de la región. El puerto puente que es el puerto raíz CIST para el raíz regional CIST es el puerto master para todos los MSTIs. 15

16 El puerto alternativo o backup, que proporcionan conectividad si otros puentes, puertos puente, o LANs fallan o son eliminadas. Si el puerto no está habilitado, se le asigna el rol Disabled tanto para la CIST como para todas las MSTIs, para identificarlo de forma que no participe en ninguna operación para determinar el árbol de expansión como en ninguna topología activa de la red [7]. 4 Metodología Una vez vistas las alternativas que existen para el protocolo STP y sus ventajas sobre él, necesitamos encontrar la manera de poder plasmar estas diferencias de forma gráfica o en su defecto de forma escrita, que demuestre las ventajas de los protocolos, uno respecto del otro, las cuales han sido obtenidas de las referencias [4] y [5]. La metodología que va ha ser seguida presenta los siguientes pasos: definición de las herramientas que van a ser utilizadas, creación y configuración de los escenarios y de sus componentes, simulación de las diferentes topologías a partir de la Consola Opnet, localización y definición de la información deseada, modificación de la Consola Opnet para poder adquirir de forma automatizada los datos deseados y por último el tratado de los resultados de forma que sean intelegibles para el lector. En el primer paso de la metodología, la definición de las herramientas que van a ser utilizadas en este proyecto final de carrera comenzará con la definición de Opnet. Opnet nos permitirá alcanzar el segundo paso en la metodología permitiendo definir y configurar, de forma muy detallada, los distintos escenarios y los componentes que los formarán. De esta forma se dispondrá de todo lo necesario para alcanzar el tercer paso en la metodología, el cual consistirá en simular los escenarios creados en el paso anterior, haciendo uso de la Consola de Opnet. La Consola que utiliza Opnet por defecto no permitiría definir de forma clara, explícita y automatizada la información necesaria para determinar los objetivos de este proyecto por ello, en el primer paso de la metodología se definen de forma detallada las 2 herramientas que serán necesarias para crear la Consola Opnet que nos facilitará los resultados deseados. Antes de poder crear la Consola Opnet a nuestro antojo, es necesario parar en el cuarto paso de la metodología y localizar a la vez que se define la información que deseamos recopilar, para ello tal y como se explica posteriormente será necesario localizar tanto el módulo como el proceso sobre el cual se necesita interrogar durante la simulación. Una vez definidas las herramientas necesarias y determinada la localización de la información deseada llega el momento del quinto paso en la metodología, la modificación de la Consola Opnet a nuestro antojo. Para finalizar, en el primer paso se definió la tercera herramienta que sería necesaria para el sexto y último paso de la metodología, que consistirá en el tratado de la información, una vez capturada, para hacerla mas legible al lector del proyecto. 4.1 Herramientas Para poder implantar una nueva red física de conexiones en nuestro escenario sin tener que realizar ningún tipo de cambio en la existente, y con ello suspender las actividades de la empresa durante ese periodo, es necesario utilizar una herramienta que nos permita de forma sencilla emular el funcionamiento de los conmutadores que forman la empresa y poder variar los enlaces entre ellos lo mas cómodamente posible. Para la simulación de la red se utilizará un simulador de red conocido con el nombre de Opnet. Opnet nos permite simular gran variedad de escenarios y redes, visualizar el flujo de mensajes de datos, paquetes que se hayan extraviado, nos permite simular una caída de enlace en el instante que deseemos, etc. Proporcionando de esta forma una herramienta muy valiosa tanto para los Ingenieros que trabajen en empresas privadas como para la Universidad, que permite de forma efectiva demostrar los diferentes tipos de redes y protocolos. 16

17 Opnet facilita todo tipo de librerías que gracias a ellas se consigue la formación de redes de comunicaciones y facilitando además el estudio del desarrollo de los modelos mediante la conexión de diversos tipos de nodos utilizando diferentes tipos de enlaces, etc. Opnet se considera también un lenguaje de simulación orientado a las comunicaciones. Nos proporciona acceso al código fuente permitiendo a los programadores embarcarse en la programación para Opnet. En la actualidad no solamente es utilizada por Universidades sino también por Empresas importantes en el sector de las Telecomunicaciones, para el desarrollo de proyectos gubernamentales y también por el ejército. Una vez se ha especificado el dimensionamiento de Opnet, debemos de asegurarnos de que en nuestra simulación, Opnet realiza lo necesario para que dispongamos de información suficiente como para poder demostrar lo mencionado en párrafos anteriores. Una vez realizado el modelado de la red y ejecutada la opción de simular Opnet se trabajará bajo una consola que se crea por defecto y a la que el propio programa llama. Para poder realizar todas las operaciones que se necesiten realizar de forma automatizada es necesario hacer que Opnet lea una consola propiamente creada para este proyecto. Para ello se necesitarán 3 herramientas las cuales dependen una de la otra para su ejecución. La primera de ellas se conoce con el nombre de Cygwin. Cygwin nos permite crear un entorno Linux bajo Windows. Consta de 2 partes: Una librería (cygwin1.dll) la cual actúa como una capa que emula API Linux proporcionando substanciosas funcionalidades API Linux. Una colección de herramientas que se encargan de proporcionar un parecido y una sensación de estar trabajando bajo Linux. La segunda herramienta necesaria es conocido con el nombre de Emacs. Es un editor de texto con gran cantidad de funciones y con una gran popularidad entre programadores y usuarios técnicos. Emacs permitirá crear la consola de Opnet adecuada a los objetivos de este proyecto, ofreciendo así un script a medida. La tercera y última herramienta es AWK. AWK es un lenguaje de programación diseñado para procesar datos basados en texto, ya sean ficheros o flujos de datos. Aunque utilicemos Emacs como editor de texto, los documentos creados se guardarán con la extensión.awk, para que luego en línea de comandos dentro de Cygwin, las peticiones sean mas sencillas de ejecutar. Además AWK permitirá realizar filtros de datos, para poder representar de forma mas clara y concisa la documentación proporcionada por Opnet, sobre los procesos de interés. 4.2 Configuración de los escenarios Después de realizar los apartados anteriores estamos en disposición de entrar en materia, y proponer las diversas alternativas que mejorarán el funcionamiento de la red actualmente en funcionamiento. Las tres soluciones que se plantean tienen en común una nueva topología de red, con mayor robustez, y se ven diferenciadas en la aplicación de los protocolos STP, RSTP y MSTP. En la Figura 6 se puede observar la nueva topología que substituirá a la actualmente instalada y sobre la que se harán las simulaciones. En nuestra nueva infraestructura disponemos de 4 servidores que ofrecen a los usuarios las servicios de , FTP, VoIP y Base de Datos. Los usuarios que trabajan en cada uno de los departamentos se verán identificados, en el entorno Opnet, como LANs conectadas a los conmutadores de sus zonas. La velocidad o capacidad de los enlaces, que comunican conmutadores, usuarios y servidores, permanecerá constante al modelo actual de la red. 17

18 Figura 6 A continuación se explicará como configurar cada uno de los objetos que se encuentran en la figura superior de forma detallada Configuración de las Aplicaciones y Perfiles En toda simulación es necesario definir el tipo de aplicaciones que se desean utilizar y los perfiles de usuario que van ha ser llamados en cada localización del escenario. Los 2 objetos a los que se debe llamar para poder realizar lo mencionado anteriormente son Application Definition y Profile Definition, los cuales se pueden encontrar en la paleta de modelos y están colocados en la parte superior de la Figura 6. Con el objeto Application Definition definiremos las aplicaciones como FTP, y Base de Datos de forma que los perfiles de usuarios las utilicen con carga baja. Esto se puede configurar como se muestra en la Figura 7. En este caso se visualiza en la captura la aplicación Base de Datos, las cuatro aplicaciones se definirían de la misma forma. 18

19 Figura 7 La aplicación de VoIP se define de la forma que se muestra en la Figura 8, sin salir de los atributos de Application Definition, caracterizando de forma mas precisa las condiciones de codificación de la voz. Los valores que se encuentran en la Figura 8 siguen los valores por defecto de la codificación de voz que se puede caracterizar para la VoIP. Figura 8 19

20 Una vez se han definido las aplicaciones de las que van a hacer uso los usuarios, es necesario definir los perfiles de los mismos dentro de nuestra simulación. Para ello utilizaremos el objeto Profile Definition. Definiremos dos perfiles entre los usuarios, el perfil de Oficinista y el perfil de Ingeniero. Cada uno de los perfiles de usuarios hará uso de las aplicaciones definidas en el objeto anterior de forma periódica. Los Oficinistas harán uso de las aplicaciones de , FTP y Base de Datos, y los Ingenieros harán uso de las aplicaciones de Base de Datos y VoIP. Para poder modelar el uso de las aplicaciones por parte de los determinados perfiles de usuarios, se ha decidido identificarlos como una función de distribución de Poissón. La función de distribución de una Poissón se puede observar en la Figura 9. En una simulación bajo Opnet las aplicaciones se pueden definir como Poissóns, determinando para cada una de ellas el valor Lambda, λ. Lambda es un número real positivo, equivalente al número esperado de ocurrencias durante un intervalo dado. En nuestro caso los valores impuestos para cada una de las aplicaciones y para cada uno de los perfiles de usuarios que se han definido son: --> λ=10, FTP --> λ=1,6, VoIP --> λ=25, Base de Datos --> λ=5, Oficinistas --> λ=6, Ingenieros --> λ=8. Estos valores están tomados para un valor de t, tiempo total de simulación, de 5 minutos como se podrá comprobar en apartados posteriores cuando se muestre la consola de simulación de la que hace uso Opnet. Figura 9 Dentro del objeto Profile Definition se determinará, como se puede observar en la Figura 10, dos filas, una para los Oficinistas y otra para los Ingenieros. Los Oficinistas disponen de 3 filas y los Ingenieros de 2, una para cada aplicación de las que hacen uso, para cada una de ellas se observa que se definen valores como la duración, repetitividad y el tipo de Poissón (λ). 20

21 Figura Configuración de las Usuarios Los usuarios, como se comentó en párrafos anteriores se representan como LANs, dentro de ellas se pueden determinar el número de usuarios que las componen modificando el parámetro Number of Clients e identificar el tipo de perfil para estos usuarios añadiendo una fila al campo Supported Profiles. En nuestro caso consideramos que los 10 usuarios que componen la LAN tienen el mismo perfil, ya que no se introduce ninguna otra fila para poder definir el perfil de Ingeniero. Ver Figura 11. Mencionar que las conexiones entre trabajadores se realizan sobre enlaces de 100 Mbps, debido a esta circunstancia las LANs deben ser del tipo 100BaseT. 21

22 Figura Configuración de los Servidores Otro de los objetos necesarios para que el escenario sobre el que se realiza la simulación funcione correctamente son los servidores. Los servidores deben proporcionar los servicios que los usuarios demandan. Como se puede ver en la Figura 12, debido a las ya definidas aplicaciones lo único necesario es determinar que servidor ofrecerá que servicio determinándolo en la línea Applicacion Supported Profile. En la Figura 12 se puede observar como el servicio que se ofrece, en el servidor sobre el que se ha accedido, es el de Base de Datos con carácter Heavy, un servicio que se ha definido anteriormente como accesible a los dos perfiles existentes en nuestro escenario. Mencionar que los servidores ofrecerán tantos servicios como filas sean creadas en la tabla. 22

23 Figura Configuración de los Enlaces Tanto los enlaces que comunican una LAN como los enlaces que comunican los conmutadores con los servidores son de tipo 100Mbps, y los enlaces que comunican los conmutadores son de tipo 1Gbps. Para poder crear estos enlaces es necesario acceder a la paleta de objetos que facilita Opnet y entrar dentro de la carpeta Links. Una vez dentro se selecciona la carpeta por nombre y aparecerá en la pantalla lo que se muestra en la Figura 13. Para esta simulación se han elegido los de tipo 1000BaseX y los de 100BaseT. 23

24 Figura Configuración STP Lo único que quedaría por configurar, serían los conmutadores que forman la red. Para poder configurar un conmutador de forma que utilice el protocolo STP para crear el árbol de expansión, se debe de entrar en los atributos del conmutador y seleccionar en el campo Spannig Tree Protocol, el protocolo STP (802.1D). Para que la simulación funcione correctamente todos los conmutadores que forman la red deben de estar ejecutando el mismo protocolo de expansión. Para que la configuración de los conmutadores sea completa debemos realizar 2 cambios mas en cada uno de los puentes. El primero de ellos se comentó en apartados anteriores cuando se decidió reducir a 1 el valor del parámetro Hello Interval (seconds), esta modificación permitirá reducir el tiempo de respuesta de la nueva red a un corte o caída de algún enlace o conmutador. El segundo parámetro es el conocido como Priority, como también se explica anteriormente, cuando se introdujeron los conceptos de los protocolos, este parámetro permite determinar el conmutador que trabajará como raíz. 24

25 Por defecto es pero los conmutadores deberán cambiar su valor por: CPD --> 1, Oficinas --> 2, Envasado --> 3, Muelles --> 4, Alm. P.T.1 --> 5, HDL --> 6, Soplado --> 7, Pta. Trasera --> 8, Torre --> 9, Alm. MPEE1 --> 10, Taller --> 11, Depósitos --> 12, Soplado2 --> 13, Muelles2 --> 14, Alm. P.T.2 --> 15, Alm. Automat.1 --> 16, Alm. Automat.2 --> 17 y Alm. MPEE2 --> 18. Estas explicaciones se ilustran en la Figura 14. Figura Configuración RSTP Para la configuraciones de los conmutadores cuando se desea que el protocolo de expansión del árbol sea RSTP, se realizará el mismo cambio que en la configuración STP, pero se elegirá la opción de RSTP (802.1w) en el parámetro Spannig Tree Protocol, tal y como se muestra en la Figura 15. Para que la simulación funcione correctamente todos los conmutadores que forman la red deben de estar ejecutando el mismo protocolo de expansión. En el caso de RSTP realizar una mención especial a los parámetros que están relacionados con VLAN, los cuales están configurados con su valor inicial, el cual es nulo. Los parámetros mencionados en el apartado anterior como Hello Interval (seconds) y Priority deberán de ser configurados de la misma forma que en la configuración STP, ya que queremos que las dos redes se comporten de la misma forma únicamente variando el protocolo de expansión y con ello mejorando los tiempos de reacción. En la Figura 15 se pueden observar los cambios para un conmutador cualesquiera de la red. 25

26 Figura Configuración MSTP La configuración de los conmutadores para que ejecuten el protocolo MSTP sigue los mismos patrones que en las anteriores configuraciones. Los parámetros Hello Interval (seconds) y Priority deben de configurarse con los valores de 1 y con el valor que corresponda al puente en el que nos encontremos, respectivamente. Para que las configuraciones que se explican a continuación se puedan realizar a todos los conmutadores que forman la red, es necesario primero habilitarlos para que soporten VLANs, esto se realiza clickando sobre la pestaña Protocolos de la pantalla principal y expandir la pestaña VLAN, como se muestra en la Figura 16, una vez seleccionados los conmutadores clickar sobre la pestaña Enabled VLANs for Selected Switches. El parámetro Spannig Tree Protocol debe tomar el valor de RSTP (802.1w), pero en este caso los parámetros VLAN, dentro de los atributos del conmutador, deben de ser configurados de la siguiente forma: Scheme debe tomar el valor de Port-BaseVLAN, Spannig Tree Creation Mode debe de configurarse como Multiple y en Supported VLANs deben de crearse tantas líneas como VLAN van a poder ser requeridas por los usuarios que están conectados al conmutador correspondiente, estos pasos se ven ilustrados en la Figura 17 y Figura 18. Para poder realizar de forma mas sencilla y rápida la configuración del parámetro Supported VLANs, basta con tener seleccionado el conmutador sobre el que se desea trabajar y clickar sobre la pestaña Configure VLANs for Selected Nodes, que aparece también en la Figura

27 Figura 16 Figura 17 27

28 El número de VLANs que se van ha crear en este proyecto son 3, tal y como se ilustra en la Figura 18, y se componen de los switches que se muestran a continuación: VLAN0: CPD, Envasado, Muelles, Soplado, Depósitos y Pta Trasera. VLAN1: CPD, AlmMPEE1, AlmMPEE2, AlmAutomat2, AlmPT1 y HDL. VLAN2: CPD, Oficinas, Torre, Taller, AlmMPEE2, AlmAutomat1, AlmAutomat2, AlmPT1, AlmPT2, Soplado, Soplado2 y Muelles2. Taller, AlmAutomat1, Figura 18 En la Figura 18 se determinan dentro de un conmutador todas las VLANs, paquetes que pertenezcan a ellas, que van ha ser distribuidas por los puertos que sean de tipo Access. Si la VLAN no se encontrara en esta tabla, los puertos en estado Access las descartarían pasando únicamente por los puertos que están configurados con estado Trunk Configuración Enlaces de Acceso Los enlaces de acceso, dentro de un entorno que hace uso de VLANs, determinarán los enlaces/par de puertos por los que los flujos pertenecientes a varias VLANs se les permitirá o no su paso, siempre y cuando el conmutador que soporta esos enlaces haya sido previamente habilitado de forma correcta, para dejar pasar por sus enlaces de acceso las VLANs que le son de interés a sus usuarios. En Opnet los enlaces son por defecto configurados como tipo acceso y para poder asegurarse de que un enlace está formado por puertos con estado Access, se debe de acceder a la configuración de los puertos del conmutador dentro de los atributos del switch, y visualizar en VLAN Parameters el parámetro Port Type. 28

29 Configuración Enlaces Trunk Como ya se explicó en el párrafo dedicado al protocolo MSTP, una de las distinciones dentro de este marco era la necesidad de introducir enlaces Trunk entre los conmutadores que forman la red. Para poder configurar los enlaces como tipo Trunk, de forma sencilla, es necesario seleccionarlos y clickar sobre la pestaña Configure Selected Links as Trunks, que aparece en la Figura 16. Para comprobar que la asignación se ha realizado de forma correcta se accede a la configuración de los puertos del conmutador, dentro de los atributos del switch, y visualizar en VLAN Parameters el parámetro Port Type. Tal y como se ilustra en la Figura 19. En esta figura también se observa un parámetro dentro de Switch Port Configur con el nombre de Cost, en este caso con valor 2976, el valor de este parámetro debe de coincidir en todos los puertos de todos los switchs de la red y debe de ser 1. Figura 19 29

30 4.3 Consola Opnet Una vez que todos los objetos necesarios para la simulación están configurados, es obligatorio realizar una simulación para poder determinar los tiempos de configuración del spanning tree de los distintos escenarios, con sus respectivos protocolos de expansión de árbol, el tiempo de respuesta a la caída de un enlace y también si la configuración final ha sido correcta, determinando esto último por la no aparición de errores de simulación en la consola Opnet. Lo primero que se configura es el tiempo total que se desea simular. Se recuerda que en apartados anteriores cuando se determinaron las aplicaciones y los perfiles en forma de Poissón con su respectiva lambda, λ, se concluyó que el valor de t, intervalo de tiempo total, era de 5 minutos. Esta asignación del valor de t, se puede observar en la Figura 20, determinada en el parámetro Duration. Figura 20 Otro de los valores que es necesario determinar antes de la simulación, el cual es muy importante para la resolución automatizada del proyecto, es el campo ODB Script mode que se encuentra clickando sobre la patilla OPNET Debugger. Tal y como se ilustra en la Figura 21. La configuración de este parámetro es tan importante, debido a que cuando se termina de configurar la consola Opnet y decidimos iniciar la simulación, el simulador Opnet crea su propio fichero con extensión.scr. Este fichero es un script que la consola de Opnet lee, a medida que la simulación trascurre, ejecutando de forma secuencial los comandos que en el están escritos. La localización del script es muy importante ya que se forzará al simulador Opnet a leer un script que previamente ha sido creado, que realice de forma secuencial los comandos que se necesitan para determinar cual de los 3 protocolos es el mas rápido y robusto ante una rotura de enlace. 30

31 Para una primera simulación es necesario realizarla con el campo ODB Script mode en valor None, tal y como se muestra en la Figura 21, para poder determinar de que procesos se va a extraer la información necesaria para alcanzar los objetivos del proyecto. La existencia de mayor número de parámetros a configurar, también se puede observar en la Figura 20, pero para el proyecto en el que se trabaja no será necesaria la configuración de ningún tipo de parámetro mas. Figura 21 Una vez configurada la consola de simulación nos aparecerá la pantalla mostrada en la Figura 22. En ella podemos observar varios detalles. El primero es la línea de comandos por la cual se pueden introducir los comandos que se crean oportunos, ODB>, y la segunda curiosidad es la necesidad de hacer referencia a los objetos o procesos que se quieran acceder, modificar o cancelar, a través de sus identificadores de objeto o de proceso. Los comandos principales que se necesitan para realizar las operaciones pertinentes a la hora de adquirir la información necesaria son: objmap link: Este comando nos muestra por pantalla, todos los enlaces existentes en nuestra red y los identificadores de estos objetos. attrget # (Identificador de objeto) CONDITION : Con este comando se puede ver por pantalla, el estado del enlace con el Identificador especificado. Este comando sólo tiene validad si la simulación está en pausa. No se puede ejecutar si no se hace un break. Attrset # ( Identificadordeobjeto ) CONDITION OPC_BOOLINT_DISABLED : Este comando permite cortar el enlace con identificador especificado. promap (Identificador de proceso): Permite conocer los procesos hijos de un proceso identificado. 31

32 prodiag (Identificador de proceso): Muestra por pantalla la información actualmente almacenada en el proceso identificado. prostop (Identificador de proceso): Cuando se introduce este comando, la consola parará la simulación en el momento en el que el proceso identificado sea llamado. suspstop (Identificador de proceso): Cuando ya no sea de utilidad el comando prostop, al introducir suspstop queda deshabilitado. Figura Definición y localización de la información deseada Como se ha podido comprobar en el punto anterior, la consola de Opnet hace referencia a objetos, procesos e hijos de procesos a través de identificadores, para poder ilustrar por pantalla el contenido almacenado por los mismos. En este proyecto se parte de la necesidad de calcular los tiempos de respuesta tanto para crear el árbol de expansión como para responder a una caída de enlace, que como se ha podido comprobar se podrá forzar en la propia simulación a tiempo real. Para poder determinar estos tiempos, es necesario conocer en cada instante el valor de los estados de los puertos que formarán parte del switch que se manipule, y el tiempo que transcurre entre los cambios de estado. Por lo que el objeto sobre el que se debe de investigar es claramente los conmutadores. Si se clicka sobre on switch en el escenario se podrá observar la siguiente pantalla, ilustrada en la Figura 23. En esta figura se puede observar claramente los procesos conmutador, eth_swith, y los procesos relacionados con todos los puertos del conmutador, eth_port_rx_yy y eth_port_tx_yy. Como en este proyecto interesa la información global de todos los puertos en su conjunto, se puede determinar que el proceso que es de interés es el proceso eth_switch. Si se realiza un doble click sobre el y se miran los procesos hijos que genera en su ejecución se puede observar un proceso hijo con nombre bridge_protocol_entity, tal y como se ilustra en la Figura 24. Dentro de este proceso hijo se puede acceder a su Block de Datos, Anexo 7, en el que se puede leer de forma clara la información necesaria sobre los puertos que componen el conmutador y que permitirá determinar los valores necesarios para los cálculos pertinentes. 32

33 Figura 23 Figura 24 Una vez localizado el objeto que es de interés, con objmap se puede determinar su identificador dentro de la simulación. Una vez dentro del objeto con promap se pueden determinar sus procesos, del cual es imprescindible el conocido con el nombre de eth_switch, y una vez dentro de él se pueden conocer los identificadores de los hijos realizando de nuevo un comando promap. Conocido ya el identificador del proceso hijo lo único que faltaría sería visualizar toda la información que almacena en los instantes necesarios, para ello se realiza un prodiag del proceso hijo, que mostrará por pantalla la información de forma clara y ordenada junto al tiempo de ejecución. 33

34 4.5 Creación y substitución de la Consola Opnet Una vez conocidos los identificadores dentro del simulador Opnet, es necesario crear un script capaz de realizar operaciones como: parar la simulación cuando la consola llame al proceso deseado, la interrogación del proceso hijo del que se desee recopilar información, la ruptura de un enlace en el momento preciso, preferiblemente después de que se haya realizado la designación del árbol inicial, y la desactivación de cualquier comando, que se haya utilizado para recopilar información, una vez se tengan todos los datos deseados. Esta última operación es necesaria para que la simulación siga su curso sin que se vea detenida ni alterada. El script que se muestra en la Figura 25, será leído por la consola de Opnet de forma secuencial, como si fueran comandos introducidos por al usuario. Este script se ha creado para la simplificación de las operaciones y para poder adquirir los datos de forma totalmente automatizada. El editor de texto emacs es una de las herramientas mencionadas en los primeros apartados del proyecto. El documento está guardado con extensión awk, para su posterior manipulación con la herramienta AWK. El script es necesario que comience por BEGIN y concluya con END. Los comandos printf permiten escribir por pantalla tal y como lo haría un usuario cualquiera, los números que le preceden deben de estar en secuencia para que la consola de Opnet sea capaz de leerlos de forma seguida. El comando prostop hará que la simulación pare cada vez que se llama al proceso deseado, en este caso el proceso con identificador Los 2 primeros comandos cont son necesarios ya que al proceso al que se llama es un proceso hijo, con lo que si se le llama antes de que sea creado puede dar un error, produciendo una parada en la simulación. El primer bucle, permitirá escribir de forma continua por pantalla la información relacionada con el proceso hijo, a través del comando prodiag, en este caso con identificador El comando cont es utilizado para que la simulación no se quede estancada en el anterior comando prostop y se pueda seguir simulando. Tras este primer bucle la información recopilada permitirá determinar cual ha sido el tiempo de configuración del árbol de expansión. El valor de la variable num, es el identificador del enlace que se interrogará y cortará con los comandos correspondientes attrget y attrset. Tras estos tres comandos se visualizará, se cortará y se comprobará que el enlace está deshabilitado. El segundo bucle volverá a interrogar al proceso hijo anteriormente interrogado y se encargará de mostrar cuanto tarda el protocolo en cuestión en responder a un enlace cortado. Los dos últimos comandos deshabilitan las paradas que se realizan cada vez que se llamaba al proceso, al que hace referencia prostop, y permiten terminar de forma exitosa la simulación. Una vez que se han escrito con el editor de texto los comandos necesarios para realizar la totalidad de las operaciones sin tocar un botón, es el momento de crear el script se substituirá al originalmente usado por la consola de Opnet. Para ello debemos guardar el documento con extensión awk e introducir dentro de Cygwin el comando awk -f script_odb.awk > odb_script_scr. Tal y como se muestra en la Figura 26. De esta forma se consigue volcar el documento en un script de nombre odb_script_scr, al que cambiaremos la extensión para que sea el utilizado por la consola Opnet. La nueva consola tendrá el nombre de odb_script.scr. 34

35 Figura 25 Figura 26 La localización de la consola por defecto utilizada por Opnet dentro de la memoria del ordenador, puede variar dependiendo de donde se encuentre el escenario de la simulación guardado. Para este proyecto Opnet decide guardarlo en la carpeta Documentos Compartidos y dentro de esta en All Users. Una vez creado el script y localizada la consola por defecto, lo único que hay que realizar es su substitución e iniciar la configuración del parámetro ODB Script mode de la consola Opnet a Play, tal y como se muestra en la Figura 27, y seleccionar el parámetro ODB Script name con el valor del script creado, que en este caso es odb_script.scr. Tal y como se ilustra en la Figura

36 Figura Simulación En este apartado se van a aplicar de forma continua los pasos que se han explicado en los apartados anteriores, mostrando los resultados que son el objetivo de este proyecto final de carrera. En un primer momento se realizará una simulación sencilla configurando los conmutadores con el protocolo que corresponda y la consola de Opnet tal y como se muestra en la Figura 21. Una vez que haya finalizado la simulación de forma correcta se visualizará en una figura cada uno de los árboles de expansión que se hayan determinado por el protocolo en cuestión. Tras mostrar el árbol en una figura, se substituirá la consola de Opnet por la creada para cada uno de los protocolos, tal y como se explica en el apartado 4.5, y se configurará la consola Opnet como se muestra en la Figura 27. Una vez finalizada la simulación y tras haber recogido toda la información necesaria del proceso hijo de interés, se volverá a mostrar una figura pero esta vez con el enlace seleccionado fuera de servicio. La información al completo de la consola y del proceso puede ser accedida en los Anexos correspondientes al protocolo ejecutado Simulación STP En la Figura 28 se puede observar el árbol de expansión libre de bucles que se crea con el protocolo STP, la figura muestra los enlaces que se encuentran en funcionamiento, de color azul, los enlaces que se encuentran cortados, los mostrados con el color rojo, y el conmutador raíz o root que en este caso es el conmutador CPD. 36

37 Figura 28 Figura 29 37

38 La Figura 29 muestra como queda el estado de la red cuando el corte del enlace entre CPD ---> AlmMPEE1 se realiza. Dejando patente la reconfiguración del escenario buscando alternativa al camino caído, habilitando el enlace Torre ---> AlmMPEE Simulación RSTP La configuración para la simulación en el protocolo RSTP tiene la única diferencia con el caso del protocolo STP en la configuración de los conmutadores, tal y como se dejó patente en el apartado de Configuración RSTP. De tal forma que la simulación correcta del escenario configurado mostrará el mismo árbol de expansión que se muestra en la Figura 28, y tras el corte del enlace el que se muestra en la Figura Simulación MSTP Para poder representar el corte de enlace en el protocolo MSTP es necesario primero mostrar los árboles de expansión de cada una de las VLANs que han sido configuradas. Las VLANs creadas se pueden observar en la Figura 30 y la leyenda correspondiente a las terminologías MSTP que aparecen en las figuras de los árboles de expansión se encuentra en la Figura 31. Figura 30 Se puede visualizar de izquierda a derecha los nombres que les ha dado el autor del proyecto, los identificadores de cada una de ellas para poder trabajar con los objetos que forman la red, el color con el que van a ser representados sus árboles de expansión y si desean verse por pantalla o no. 38

39 Figura 31 En las figuras que preceden se mostrará cada uno de los árboles realizados por al protocolo MSTP. En la Figura 32 se puede ver el árbol de expansión con ID y igual a 1, en la Figura 33 se muestra la configuración del árbol correspondiente a la VLAN con ID 3 y en las dos últimas figuras, Figura 34 y Figura 35, se puede ver el árbol de la VLAN con ID 2 antes y después de cortar el enlace Soplado2 --> AlmPT2. Figura 32 39

40 Se puede observar la existencia de 3 puertos maestros conectando 2 regiones diferenciadas, 4 conmutadores que trabajan como raíces regionales y la accesibilidad a los servicios de los usuarios que se encuentran en los departamentos que forman la VLAN0, tal y como se comentó en el apartado de configuración MSTP. Figura 33 En la Figura 33, se muestra el árbol de expansión de la VLAN1, en ella se pueden observar 3 puertos master y 4 conmutadores raíz regionales. En la siguiente figura, Figura 34, se observa la configuración final del árbol de expansión de la VLAN2 antes de que se realice el corte del enlace entre Soplado2 --> AlmPT2. La selección de este enlace no ha sido al azar, ya que se pretende mostrar en el apartado de filtrado MSTP, una de las características típicas del protocolo MSTP. Es de importancia fijarse en el rol que juega el conmutador Soplado2 antes y después del corte de enlace. 40

41 Figura 34 En la Figura 34 se pueden contar un puerto maestro conectado a dos regiones, 4 conmutadores que trabajan con el rol de raíz y un nodo raíz, regional y común. Antes del corte del enlace el conmutador Soplado2, no dispone de ningún puerto con rol como raíz y está considerado como un puerto mas de la red VLAN2. Si se fija en la Figura 35 el conmutador Soplado2 cambia de rol dentro de la red MSTP y se convierte en un conmutador de carácter regional. Siendo ahora el número de conmutadores con rol regional de 5 y un nodo raíz, regional y común. La anulación del enlace no provoca, como se puede comprobar en la Figura 35, que ninguno de los departamentos que pertenecen a la VLAN2 se vea anulado de su acceso a los servicios. 41

42 Figura Presentación de la información Tras realizar una simulación utilizando la consola creada, se pueden guardar los datos mostrados por pantalla en cualquier tipo de documento. En este proyecto los documentos se guardarán en formato.txt. Estos documentos contienen todo la información almacenada por el proceso hijo al que se le ha ido interrogando en el transcurso de la simulación. Para que la lectura de los resultados obtenidos de las simulaciones se realice de forma mas clara y precisa, se decide crear filtros de texto. Estos filtros de textos creados con el programa AWK, el cual es un lenguaje que está diseñado para procesar datos basados en texto, son llamados desde la línea de comandos Cygwin. 42