barra de menu

martes, 17 de noviembre de 2015

Capítulo 3: Spanning Tree

Como ya sabemos, cuando un switch recibe una trama con una mac de destino desconocida, enviará el tráfico por todos los puertos excepto por el que ha recibido la trama.

Si esto nos sucede en una red con enlaces redundantes se puede producir un bucle (loop) y que los switches no paren de inundar la red.



Estos bucles pueden empeorar drásticamente el rendimiento de la red. Para evitar estos bucles se creó el protocolo Spanning-Tree (IEEE 802.1D)

Spanning-Tree (STP) es un protocolo que previene los bucles y calcula la mejor ruta en topologías con enlaces redundados. Cuando hay un cambio en la topología, el STP recalcula la ruta.

Spanning-Tree ha evolucionado a lo largo del tiempo. Ahora tenemos:

RSTP: Rapid Spanning-Tree

VSTP: VLAN Spanning-Tree

MSTP: Multiple Spanning-Tree




CONCEPTOS Y DEFINICIONES

Todos los switches que participan en el árbol STP tienen un único "Bridge ID".

Bridge ID: identificador único. Es una combinación de la mac y la prioridad STP que configuramos.

Root Bridge: Switch que tenga el "Bridge ID" más bajo.

Root Port: El puerto de cada switch que está más cerca del Root Bridge.

Root Path Cost: Es el coste para llegar al Root Bridge. 

Port Cost: Cada interfaz tiene un coste asignado predefinido: El valor por defecto en una interfaz       que sea de 1 Gigabit Ethernet es de 20000. Este es un valor configurable (1-200000000).

Una vez que el Root Bridge ha sido determinado, el resto de switches que no son Root, calculan el coste hasta el Root Bridge. El puerto con menos coste en estos switches será el root port. 

Designated Bridge: Es un switch que representa el segmento LAN.

Port ID: Un identificador único para cada puerto del switch.

Designated Port: El puerto designado para enviar las BPDU'S en la parte LAN.

Bridge Protocol Data Unit (BPDU): son paquetes usados entre switches para el protocolo STP. 

Cuando hay varios switches en un segmento LAN, el que tenga menor coste hacia el Root Bridge será el designated bridge. Si existieran dos switches con el mismo coste para llegar al root, el switch que tenga el Bridge ID más bajo será el designated bridge. Si también coinciden en el bridge id, será el ID del puerto por donde se llega al root. 


ESTADO DE LOS PUERTOS

Hay 4 estados de puerto:

Blocking (bloqueando): el puerto descarta todos los paquetes y solo oye para BPDU's. No está activo en la topología.

Listening (escuchando): el puerto descarta todos los paquetes y solo oye para BPDU's. El puerto está cambiando de estado y será activo.

Learning (aprendiendo): el puerto descarta todos los paquetes y solo oye para BPDU's. El puerto está cambiando de estado y el switch empieza a aprender direcciones mac.

Forwarding (enviando): el puerto envía y recibe datos y BPDU's. El puerto se queda en este estado hasta que haya un cambio en la topología y continua aprendiendo direcciones mac.

También podemos deshabilitar el puerto para el protocolo STP. Este puerto no participa en el árbol STP aunque envíe tráfico si se recibe por otro puerto no deshabilitado y que pertenezca a la misma vlan.




TIPOS DE BPDU

Tenemos 2 tipos de BPDU:

    - Configuración BDPU (TCN ACK): determina el árbol topológico del STP. Lleva la info del root bridge elegido, el root port de cada switch, los "designated port" de cada segmento físico y el bloqueo de los enlaces redundantes.

    - TCN BPDU: informa de un cambio en la topología STP.




Cuando STP inicia en una red, los dispositivos empiezan a mandar BPDU's por todos los puertos para indicar a los demás switches o bridges que quieren ser candidatos a ser el root. Cada dispositivo usa las BPDU's para formar el árbol y asignar los roles a los puertos. Una vez convergido el árbol, el root bridge enviará las "configuración BDPU" periódicamente (por defecto es cada 2 segundos).

INTERCAMBIO DE BPDU'S

Los equipos están constantemente intercambiando bdpu's. Cada bridge construye su propia configuración basándose en las BPDU's que le llegan.

Elección del Root Bridge:

La elección del Root Bridge se hace en base al Bridge ID (BID), que es un número que combina la dirección mac con una prioridad configurable del puerto. El switch mira primero a la prioridad y el que la tenga más baja será el Root. Si coincide con algún o algunos equipos de la red, entra en juego la mac siendo elegida las más baja.

Roles de Puerto y Estado:

Una vez elegido el Root Bridge, aquellos equipos que no son el Root empiezan a calcular el coste para llegar a este. Esto determina el rol del puerto. Y el rol del puerto determina su estado.

Todos los puertos del Root tendrán el rol de Designated y el estado de Forwarding.

En los equipos que no son el Root Bridge, el puerto con menor coste hacia el Root Bridge, tendrá el rol de "root port" y el estado de "Forwarding". Si un equipo tiene uno o varios puertos con el mismo coste, el "root port" será el que tenga un ID de puerto más bajo, es decir, se prefiere el ge-0/0 al ge-0/1.

Coste de los enlaces


Luego el STP asiginará el rol de "Designated" al puerto con menos coste (después del root port). Si hay empate se resuelve igual que con el root port. Este puerto también estará el estado de "Forwarding". 

Los demás puertos que no son ni root ni designated estarán en blocking. En el estado de bloqueo, los puertos no envían BPDU's, pero si las reciben.



Una vez asignados los roles y los puertos, el árbol STP converge.

STP usa tiempos específicos cuando cambian de estado los puertos. La convergencia de STP dura entre 30 y 50 segundos: 2x Forwarding Delay (15x2=30) + Max Age Timer (20)

Cuando hay un fallo en la red, STP recalcula y vuelve a converger:


Una vez que los switches que no son el root bridge han cambiado el tiempo de espera de la mac (age timer) por el tiempo más corto de espera (15 segundos por defecto), borra todas las entradas de la tabla mac para las que no haya recibido un "update". Todas estas entradas deberán ser asociadas otra vez siguiendo el proceso normal de aprendizaje de macs.

La solución, cuando hay un cambio de topología, no es eficiente, pues si tarda en converger 50 segundos, habrá muchos servicios que dejen de funcionar. Por ello, con el tiempo se hizo una mejora del protocolo creando uno nuevo: RSTP.



RSTP (RAPID SPANNING-TREE)


Este protocolo está definido en la IEEE 802.1w e incorporado a la 802.1D en 2004. Introduce una serie de mejoras sobre el STP.

El tiempo de convergencia es menor. RSTP identifica los enlaces Point-To-Point y cuando caen, no ejecuta los tiempos de espera sino que transita al link alternativo inmediatamente.

ROLES DE PUERTO

A parte del root port y el designated port que ya tenía STP, añade 3 más RSTP:

Edge Port: Es un puerto que conecta a la LAN sin ningún switch conectado. Siempre en Forwarding.

Alternate Port: provee un camino alternativo hacia el root bridge. Es como un root port de backup. Bloquea el tráfico mientras reciba BDPU's superiores de un switch vecino. Está siempre en "discarding" pero recibe las BPDU's.

Backup Port: Provee un camino alternativo hacia un segmento de red (solo en switches designated). Bloquea el tráfico siempre que tenga un "alternate" funcionando. Es una especie de backup del puerto alternate.



ESTADO DE PUERTOS EN RSTP 

Cuando una interfaz está "deshabilitada" administrativamente en RSTP, esta no participa ni en STP y RSTP pero inunda las BPDU's que reciba y que pertenezcan a la misma vlan y hace funciones básicas de bridging como asociar direcciones mac en la tabla bridge.



RSTP utiliza menos estados de puerto que STP pero cumpliendo las mismas funciones como podemos ver en el cuadro.

BPDU's en RSTP 

Utiliza las BPDU's igual que STP pero le añade una característica a las BPDU de configuración (TCNA) y es que cumplen la función de "keepalive" monitorizando a los vecinos. De esta manera se da cuenta de un cambio en la topología antes que STP. Si no recibe una BPDU en 3 intervalos de tiempo de "hello" (por defecto son cada 2 segundos), asume que ha perdido conectividad y actualiza el árbol. 

La diferencia es que serían 6 segundos (2x3) y en STP puede llevar hasta 50 segundos.

Las interfaces ethernet trabajando en "full duplex" se consideran enlaces Punto-a-Punto (P2P) y por eso transitan a forwarding sin esperar el intervalo de tiempo.


Las interfaces ethernet trabajando en "half duplex" se consideran enlaces de medio compartido (shared LAN) y estas tienen que esperar el intervalo de tiempo.


RSTP es totalmente compatible con STP. Si RSTP recibe una BPDU del tipo STP la trata en modo STP. Si un switch STP recibe una RSTP BPDU, la descarta.



Una de las grandes diferencias entre ellos es que los puertos root y edge de RSTP transitan inmediatamente a forwarding sin tener que esperar los 30 segundos de STP hasta que llega al estado de forwarding (15'' listening + 15'' learning).

Cuando un puerto está en transición en STP, esto causa un cambio de topología. Sin embargo, en RSTP se reduce el número de cambios de topología ya que solo envía TCN's cuando cambia el estado en un puerto "non-edge" a forwarding, que normalmente son los puertos que conectan con otro switch. 

Cuando un puerto transita hacia el estado de "discarding" no se generan en los TCN's que llevarían a un cambio de topología y recálculo de esta.

Cuando hay un cambio en la topología, el dispositivo que inicia el cambio envía TCN's por todos los puertos que tenga en "designated" y por el root port también. Como el resto de switches reciben los TCN's no tienen que esperar los intervalos de tiempo y directamente hacen un "flush" de las direcciones mac de la tabla bridge (borra las entradas y empieza a aprender otra vez las direcciones). Hay dos excepciones: no hace flush de las direcciones mac que haya aprendido por los puertos "edge" y tampoco hace flush de las direcciones del puerto por donde recibe los TCN's.

El fallo se mira desde la perspectiva del switch 3


El fallo se mira desde la perspectiva del switch 3


CONFIGURACIÓN RSTP Y COMPROBACIÓN



Para comprobar el protocolo:




Si quisieramos algo más detallado habilitamos un traceoption (debug para Cisco)

set protocols rstp traceoptions file name X
set protocols rstp traceoptions flag all



PROTECCIÓN DE BPDU's

Si en nuestra red alguien conecta un switch (rogue switch) a un puerto de alguno de estos switches, este podría participar en el árbol STP y cambiar nuestra topología llegando a crear búcles. 

Para protegernos de esto, aseguramos las interfaces para que si reciben una BPDU, directamente se deshabilita el puerto y deja de enviar bdpus. El puerto se queda en estado de "blocking". Hay veces que no podemos deshabilitar esa interfaz y, como solución, configuraremos la opción "drop" que descartará las bpdus pero seguirá enviando tráfico. Estas interfaces no tienen que tener habilitada ninguna opción de STP para poder configurar "drop".




Para comprobar STP:

show spanning-tree interface

También podemos comprobarlo en el log del equipo:



PROTECCIÓN DEL ROOT BRIDGE


Todos los puertos del root bridge tienen que estar en estado "designated". Si alguno de los puertos cambia a "root port", es decir, ha recibido una BPDU superior y nuestra topología se puede ver afectada. 

Para protegernos de esto y que nuestra elección de root bridge no se vea afectada, podemos habilitar la protección del root en los puertos:



Si el puerto recibe una BPDU superior, el switch pasará este puerto al estado de "blocking". De esta manera prevenimos que otro switch se quiera coger el rol de "root bridge". Una vez que deja de recibir BPDU's superiores, el puerto vuelve a pasar por los estados de listening, learning, forwarding.

En el ejemplo vemos que también aseguramos puertos en el switch2 para que no sean un root port.

Cuando el "root protection" es habilitado en una interfaz, este es aplicado a todas las instancias STP que haya en ese puerto.

Es importante saber que el "bdpu protection" y el "root protection" no pueden configurarse en la misma interfaz.


Para comprobar STP:






No hay comentarios:

Publicar un comentario