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
 Índice
1 Introducción y objetivos..................................................................................................................4

2 Situación actual de la red................................................................................................................5

2.1 Spanning Tree Protocol (STP)........................................................................................6

3 Propuestas alternativas.................................................................................................................10

3.1 Rapid Spanning Tree Protocol (RSTP)........................................................................10

3.2 Multiple Spanning Tree Protocol (MSTP)...................................................................13

4 Metodología....................................................................................................................................16

4.1 Herramientas...................................................................................................................16

4.2 Configuración de los escenarios....................................................................................17

4.2.1 Configuración de las Aplicaciones y Perfiles.................................................18

4.2.2 Configuración de las Usuarios........................................................................21
4.2.3 Configuración de los Servidores.....................................................................22
4.2.4 Configuración de los Enlaces..........................................................................23
4.2.5 Configuración STP..........................................................................................24
4.2.6 Configuración RSTP........................................................................................25
4.2.7 Configuración MSTP.......................................................................................26
4.2.7.1 Configuración Enlaces de Acceso....................................................28
4.2.7.2 Configuración Enlaces Trunk..........................................................29

4.3 Consola Opnet.................................................................................................................30

4.4 Definición y localización de la información deseada...................................................32

4.5 Creación y substitución de la Consola Opnet...............................................................34

4.6 Simulación.......................................................................................................................36

4.6.1 Simulación STP................................................................................................36

4.6.2 Simulación RSTP.............................................................................................38
4.6.3 Simulación MSTP............................................................................................38

4.7 Presentación de la información.....................................................................................42

5 Resultados......................................................................................................................................43

5.1 Resultados STP...............................................................................................................43

5.2 Resultados RSTP............................................................................................................45

5.3 Resultados MSTP............................................................................................................48

6 Conclusiones...................................................................................................................................49

7 Referencias.....................................................................................................................................50

3
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
 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
 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
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 (01000010) 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
 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
 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
 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
 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
 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.

○ 2048 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
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
 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
 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
 ● 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
 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 Email, 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
 Figura 6

A continuación se explicará como configurar cada uno de los objetos que se

encuentran en la figura superior de forma detallada.

4.2.1 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,
Email 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
 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
 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 Email, 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: Email --> λ=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
 Figura 10

4.2.2 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
 Figura 11

4.2.3 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
 Figura 12

4.2.4 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
 Figura 13

4.2.5 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
 Por defecto es 32768 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 14

4.2.6 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
 Figura 15

4.2.7 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 16.

26
Figura 16

Figura 17

27
 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, Taller, AlmAutomat1,

AlmAutomat2, AlmPT1 y HDL.

● VLAN2: CPD, Oficinas, Torre, Taller, AlmMPEE2, AlmAutomat1,

AlmAutomat2, AlmPT1, AlmPT2, Soplado, Soplado2 y Muelles2.

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.

4.2.7.1 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
4.2.7.2 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
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
 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
 ● 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 22

4.4 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
 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
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 1380. 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 2438. 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
 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 27.

35
 Figura 27

4.6 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.

4.6.1 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
Figura 28

Figura 29

37
 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 --->
AlmMPEE1.

4.6.2 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 29.

4.6.3 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
 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
 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
 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
 Figura 35

4.7 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
 El número de filtros es 3, uno para cada protocolo de expansión, y son invocados de
la siguiente forma: para el protocolo STP, awk -f filtro_STP.awk -v SALIDA =
"filtrado_de_STP.txt" -v PUERTOS = 4 STP_escenario_definitivo.txt, para el protocolo
RSTP, awk -f filtro_RSTP.awk -v SALIDA = "filtrado_de_RSTP.txt" -v PUERTOS = 4
RSTP_escenario_definitivo.txt y para el protocolo MSTP, awk -f filtro_MSTP.awk -v
SALIDA = "filtrado_de_MSTP.txt" -v PUERTOS = 3 MSTP_escenario_definitivo.txt.

El primer documento con extensión awk es el filtro que va ha ser aplicado, el campo
SALIDA es donde se guardará toda la información que sea de interés desechando la
información que no sea relevante para los tiempos de respuesta, el campo PUERTOS
permite al filtro saber de cuantos puertos dispone el conmutador para controlar sus estados,
los roles y con ello el tiempo que transcurre de un cambio a otro y para finalizar, el último
documento con extensión .txt es el documento a filtrar.

5 Resultados

Una vez adquirida la información y mostrado los diversos filtros que se han creado se pasará
a filtrar en su totalidad por el filtro correspondiente a cada protocolo, mostrando de forma exacta los
tiempos tanto de realización del árbol de expansión como de recuperación ante un corte de cada uno
de los protocolos. La información filtrada puede ser visualizada en los Anexos correspondientes.

5.1 Resultados STP

Destacar que tras haber filtrado la información del Anexo 1, con el filtro STP,
Anexo 8, se puede comprobar en al Anexo 4 como el protocolo STP tarda 4,0000271369
segundos en pasar del estado LISTENING al estado FORWARDING, permitiendo de esta
forma a todos los puertos del conmutador transmitir información de usuario. La última
transición se puede visualizar en la Figura 36.La relación del tiempo transcurrido para pasar
de los estados LISTENING --> LEARNING, 2 segundos, y LEARNING -->
FORWARDING, otros 2 segundos, están directamente relacionados con el valor del
parámetro Hello Time configurado en todos los switches que componen la red. 1 segundo de
transmisión y 1 segundo de recepción.

Figura 36

43
 En la Figura 36, perteneciente al filtrado de la información se puede observar la
última transición de los puertos P0,P2 y P3 que pasan del estado LEARNING al último
estado FORWARDING. En estos estados los puertos permanecen hasta que finaliza la
simulación o hasta que un enlace o conmutador caiga.

Esta caída de enlace se ve forzada por los comandos introducidos en la consola

creada de Opnet. Los comandos y el tiempo de corte se pueden visualizar en la Figura 37.
En esta figura se pueden observar varios comandos: el primero de ellos es el comando
attrget que como se explico en apartados anteriores muestra el estado del enlace con
identificador 92, en este caso el que se desea cortar, la respuesta de Opnet es ENABLED
determinando que el enlace se encuentra en funcionamiento, el segundo comando es attrset
que como ya se explicó permite cortar el enlace que en este caso tiene el identificador 92 y
el último comando permite asegurarse de que la última instrucción ha tenido éxito y se ha
logrado cortar el enlace deseado, como se puede comprobar el enlace se encuentra
DISABLED. Esto se produce en el instante de tiempo 4,9200652368 segundos.

Tras la ruptura del enlace el puerto que se encontraba en funcionamiento y que

estaba ligado al enlace, PO, pasa al estado DISADLED, y el puerto que se encontraba en
estado BLOCKING, P1, pasa a estar en estado LISTENING. El tiempo que tarda el
protocolo STP en permitir al puerto P1 en transmitir datos de usuario es de 4,00001904
segundos, tal y como se muestra en la Figura 38.

Figura 37

44
 Figura 38

5.2 Resultados RSTP

La información del proceso hijo interrogado se puede encontrar de forma completa,

tal y como lo muestra la consola Opnet, en el Anexo 2. Tras filtrar la información con el
filtro RSTP, Anexo 9, se puede comprobar, en el Anexo 5, que la filosofía de la que hacen
uso los protocolos STP y RSTP es diferente. Por un lado STP considera no aptos los
puertos para la transmisión de información de usuario hasta que no se demuestre lo
contrario, de hay que se necesite pasar por varios estados antes de llegar al estado
FORWARDING. La filosofía del protocolo RSTP es totalmente distinta en el sentido de
que para el todos los puertos deben de transmitir información de usuario, estando en el
estado FORWARDING desde el instante 0, hasta que se demuestre lo contrario.

En la Figura 39, perteneciente a un fragmento del Anexo 5 correspondiente al

filtrado de la información, se puede observar como todos los puertos comienzan en el
estado FORWARDING y con rol Designated.

Figura 39

45
 El escenario de la Figura 28, tiene la peculiaridad de que la conexión AlmMPEE1 --
> Taller se caracteriza de forma distinta por los dos switches. Para AlmMPEE1 debe de
pasar por todos los estados correspondientes antes de llegar al FORWARDING de forma
permanente, ya que en un primer momento el puente AlmMPEE1 se ha dado cuenta que el
puente Taller le da el valor de BLOCKING y rol Alternate.

En la Figura 40 se puede observar como en el segundo 0,0000527463 todos los

puertos se encuentran en su estado definitivo menos el puerto P3 que pertenece al enlace
AlmMPEE1 --> Taller, y con roles o bien de Root, como en el caso del P0, o bien en
Designated como en los casos P2 y P3. Este dato demuestra una de las ventajas que
proporciona RSTP con respecto a STP.

Figura 40

En la Figura 41 se observa que el puerto P3 tarda 4,0000652368 segundos en llegar

al estado FORWARDING. Dejando el tiempo de configuración del árbol de expansión con
el protocolo RSTP a 4,0000652368 segundos.

Figura 41

Para poder conocer el tiempo de respuesta del protocolo RSTP se toma la decisión
de cortar el enlace en el segundo 4,4001223568 de simulación, tal y como se puede ver en
la Figura 42. Tras este corte el conmutador reacciona cambiando los estados y los roles de
los puertos P0 y P2 a DISABLED, Disabled y a FORWARDING, Root respectivamente en
exactamente 0,0000114937 segundos, tal y como se muestra en la Figura 43.

46
Figura 42

Figura 43

47
5.3 Resultados MSTP

Tras haber simulado el escenario ejecutando el protocolo MSTP, la información

substraída, a través de interrogar el proceso hijo del conmutador Soplado2, de la consola
Opnet se encuentra en el Anexo 3 y la información filtrada por el filtro MSTP se puede
observar en el Anexo 10. En el Anexo 3 se puede visualizar tanto la información específica
de los puertos para CIST, como la información específica de los puertos para MSTI 1
sirviendo para VLAN2. En el Anexo 6 la información que se muestra es la información
relacionada con MSTI sirviendo a la VLAN2.

El tiempo en el que el árbol de expansión se ve realizado se puede comprobar por

en la Figura 44, en la que se puede observar como tras comenzar todos los puertos en el
estado FORWARDING y con rol Designated, el protocolo MSTP tarda 3,0000347306
segundos en pasar el puerto P3 a estado BLOCKING y rol Alternate. Dejando los otros dos
puertos, P0 y P1, en estado FORWARDING y con rol Root y Designated respectivamente.
Esto se puede visualizar también en la Figura 44.

Figura 44

El corte del enlace entre Soplado2 y AlmPT2 se realiza en el instante 5,7400652688

segundos tal y como se muestra en la Figura 45. Este corte de enlace provoca que el puente
Soplado2 cambie de rol en la red MSTP, convirtiéndose en un conmutador regional.

48
 Figura 45

En la Figura 46 se muestra que el protocolo MSTP reacciona al corte de enlace en

0,00001904 segundos pasando el puerto P0 de FORWARDING a DISABLED y el puerto
P3 de BLOCKING a FORWARDING.

Figura 46

49
6 Conclusiones

Tras haber realizado de forma completa los objetivos que se marcaron para este proyecto
final de carrera y comparados los resultados que han sido recopilados en el transcurso del mismo,
las conclusiones sobre que protocolo entre STP, RSTP y MSTP es mas eficiente en terminos de
temporales a la hora de establecer el árbol inicial de expansión, se deja claramente desbancado al
protocolo STP con respecto a los protocolos RSTP y MSTP, ya que los 4 segundos que tarda en
permitir a los puertos transmitir información de los usuarios está muy por encima de las milésimas
de segundo que tardan los protocolos RSTP y MSTP en permitir esta misma acción.

Esta diferencia se produce claramente por las diferentes filosofías tomadas por los
protocolos ya que para STP los puertos no son fiables de producir un bucle en el árbol hasta que se
demuestre lo contrario, en cambio para los protocolos RSTP y MSTP la filosofía con los puertos es
totalmente inversa considerando que los puertos son fiables hasta que se demuestra la contrario. Por
otra parte hay que diferenciar lo comentado en las líneas anteriores con el tiempo que tardan los
protocolos RSTP y MSTP en crear su árbol de expansión, tal y como se muestra en los apartados
anteriores el tiempo que tarda el protocolo RSTP en definir por completo los estados de los puertos
es de 4 segundos y el tiempo tomado por MSTP es de 3 segundo, dejando claramente por delante al
protocolo MSTP en este aspecto.

Otro de los temas que se ha abarcado, en este proyecto final de carrera, es el tiempo de
reacción de los protocolos ante una caída de enlace, en este caso provocada. Para esta situación el
protocolo STP tarda 4 segundos en reaccionar y volver a establecer los estados definitivos a sus
puertos, por contra RSTP tarda exactamente 0,0000114937 segundos en realizarlo y MSTP
0,00001904 segundos volviéndose a quedar obsoleto el protocolo STP con respecto a los protocolos
RSTP y MSTP. La decisión entre RSTP y MSTP viene determinada por: la independencia que
ofrece MSTP al definir VLANs que reaccionan de forma independiente ante problemas surgidos en
sus dominios versus la globalización que ofrece RSTP creando un único árbol de expansión y la
complejidad que conlleva el protocolo MSTP versus la sencillez que aporta RSTP.

7 Referencias

[1]. Asignatura de 5º Curso de Telecomunicaciones, Redes de Ordenadores de la Escuela Superior

de Ingenieros, Profesores: Rafael Estep y Juan A. Ternero.

[2]. Understanding Spanning Tree Protocol (802.1D), Cisco.

[3]. Understanding Rapid Spanning Tree Protocol (802.1w), Cisco,

http://kbase:8000/paws/servlet/ViewFile.

[4]. Distributed Restoration Method for Metro Ethernet, HACNet Lab, Southern Methodist
University Dallas, Texas, USA. IEEE Computer Society (ICNICONSMCL´06).

[5]. Optimizing QoS Aware Ethernet Spanning Trees, Department of Telecomunications and Media
Informatics Budapest University of Technology and Economics. IEEE 2005.

[6]. Understanding Multiple Spanning Tree Protocol (802.1s), Cisco.

[7]. The Multiple Spanning Tree Protocol (MSTP), IEEE Standards Draft.

50
Anexos

Los anexos a los que se ha ido haciendo referencia en el transcurso del proyecto, se
encuentran accesibles en el CD que acompaña a la documentación escrita del proyecto. En el
siguiente párrafo se explican de forma clara los contenidos de cada uno de ellos.

En los Anexos 1, 2 y 3 se encuentra almacenada toda la información sin filtrar que la

Consola Opnet, creada para este proyecto, recoge de las simulaciones de los protocolos STP, RSTP
y MSTP, respectivamente.

En los Anexos 4, 5 y 6 se encuentra almacenada toda la información filtrada que la Consola

Opnet, creada para este proyecto, recogió de las simulaciones de los protocolos STP, RSTP y
MSTP, respectivamente.

En el Anexo 7 se puede observar el Block de Diagnóstico de un proceso hijo perteneciente

al modulo de un switch. En él se encuentra toda la información necesaria para alcanzar los objetivos
de este proyecto por ello es el proceso que se interroga en las simulaciones de los distintos
protocolos.

En los Anexos 8, 9 y 10 se pueden visualizar los filtros de los protocolos STP, RSTP y
MSTP, respectivamente, utilizados para presentar de forma clara la información almacenada en los
Anexos 1, 2 y 3, la cual está almacenada en los Anexos 4, 5 y 6.

51
52