Apunte de Spanning Tree Protocol (Teoría de las Comunicaciones)
Archivo:Back.png [[Teoría de las Comunicaciones}}
El Spanning-Tree Protocol es un protocolo de sincronización entre switches/bridges situados en el nivel 2 de la jerarquía OSI. El objetivo es acordar entre todos los bridges una topología (lógica) única y sin ciclos.
STP en la teoría
El algoritmo consta de tres partes y requiere que cada router tenga un ID y pueda saber el estado de cada puerto conectado a él. Las partes son:
- Se elige el bride con ID más chico como root
- Cada bridge calcula el camino más corto hacia el root y marca el puerto correspondiente como "root port".
- Para cada LAN todos los bridges conectados a el deben acordar cual de ellos será el designado. Para hacerlo intercambian paquetes llamados BPDUs. El bridge designado será, en orden de preferencia:
- El más cercano al root
- El más cercano y con menor ID en caso de que sea necesario desempatar.
STP en la práctica
Los bridges se sincronizan enviándose paquetes llamados BPDUs que contienen:
- ID del emisor
- ID del que el emisor piensa que es el root
- Distancia del emisor al root
Para entender mejor como se dividen las partes del algoritmo y como termina convergiendo aplicaremos el algoritmo sobre la siguiente topología y veremos la reacción de los bridges.
Al principio todos los bridges se creen root, por lo tanto preparan BPDUs que dicen eso y lo envían por todos sus puertos para avisarle a los bridges adyacentes. En la siguiente figura los bridges root están marcados de color rojo y los puertos del root también.
En la "primera oleada" los paquetes de los bridges adyacentes llegan. Ahora, si un bridge considera que un paquete que llegó es mejor al suyo cambia su estado. Un paquete es considerado mejor cuando:
- El root ID recibido es menor
- El root ID es igual pero la distancia al root es menor
- El root ID y la distancia son iguales pero el ID del emisor es menor
En la figura vemos como quedaría ahora el estado de cada bridge. Estan marcados en rojo los "root ports" que son los puertos de cada bridge que apuntan al root. Para entender mejor los casos anteriormente mencionados vamos a ver donde se dieron en nuestra red.
Los bridges 24, 92 y 12 recibieron un paquete del bridge número 3, vieron que existe un bridge con número menor estricto que ellos por lo tanto cambian su estado y fowardean lo recibido por los puertos que no recibieron el paquete. Más adelante veremos como reaccionan los bridges de más abajo.
Los bridges de la segunda línea (los de más abajo) todavía no recibieron el paquete del bridge número 3, por lo tanto sólo mejoraron un poco lo conocido dentro de su alcance. El bridge 7 sabe que el 5 es mejor que él (e ignoró el paquete del bridge 92 por ser mucho peor que él). El bridge número 4 todavía no se vió superado y se cree el rey del mundo.
En la próxima iteración los paquetes del bridge 3 llegan a la línea de abajo y se estabiliza la selección del root.
Es importante ver que durante esta segunda iteración no produjeron paquetes nuevos los bridges que cambiaron su estado durante la primera iteración (de la primera línea) sino que fowardearon el paquete proviniente del bridge número 3. Con esto me refiero a que, por ejemplo, el bridge número 12 no generó un paquete y lo envió por su root port. Si lo hubiera hecho habríamos tenido problemas graves de convergencia en cuanto a los puertos designados que es lo que vamos a ver ahora.
Notar que no tiene fowardear algo que acabamos de aprender (un mejor estado) por un root port ya que cualquier cosa que venga de un root port va a ser mejor o igual a lo que ya tenemos y en todo caso los que puedan recibir el paquete que quiero mandar también ya recibieron el mandado anteriormente por el root.
En la figura de arriba se marcó en color azul los puertos designados. Estos puertos son los que cada bridge cree que tiene que fowardear. El próximo paso es bloquear algunos de estos puertos para convertir el grafo en un árbol.
Los bridges envían paquetes hacia las LANs (no por los root ports sino por los designados) y escuchan a los demás bridges.
- Si reciben un root ID igual pero una distancia menor al root bloquean este puerto y dejan que el otro bridge se encargue de mandar los mensajes desde y hacia esa LAN. En este paso ya no deberia haber paquetes circulando con root ID menor al mío (porque dijimos que ya habíamos acordado un root). Sin embargo si este fuera el caso simplemente se procede como antes y en la próxima iteración quedaremos listos para sincronizar los puertos designados.
- Si reciben un root ID y una misma distancia se desempata con el menor ID del emisor.
En la siguiente figura podemos ver como quedan asignados los puertos:
Finalmente al converger el algoritmo se tiene un árbol y todos los bridges están sincronizados. Cada un intervalo de tiempo se generan paquetes con información para mantener la asignación y estar atentos a los cambios.
