Por defecto los switches envían broadcast por todos los puertos. Son como pruebas para descubrir la topología y los posibles búcles.
El protocolo STP envía BPDU's (Bridge Protocol Data Unit) cada 2 segundos a través de cada uno de los puertos. Usa la dirección multicast:
01-80-C2-00-00-00
Existen 2 tipos de BPDU:
- Configuration BPDU: Lowest root bridge ID, lowest sender bridge ID and lowest sender port ID and lowest patch cost to root brdige (lowest=más bajo)
- Topology Change Notification BPDU: TCN cuando hay un cambio de topología y TCA como acknowledge del root bridge
La BPDU tiene los siguientes campos:
La prioridad tiene un valor entre 0 y 61440, siendo la configuración por defecto 32768. Los valores incrementan a base de 4096 debido a que se utilizan 4 bits en este campo.
La topología está determinada por 3 variables:
- Una dirección mac única asociada para cada switch
- El coste del camino (path cost) para llegar al Root Bridge de cada puerto
- Una dirección mac única asociada para cada puerto de cada switch
Un ejemplo:
 |
| R = Root; D = Designated; B = Blocking |
 |
| Ojo que no es lo mismo tipos de puerto que estados de puerto. En esta IOS solo se ve el estado (STS). En otra puedes ver el campo Role, el tipo de puerto |
Aquí vemos todos los switches tienen la prioridad por defecto y en caso de empate vemos como el switch con la mac más baja se acaba convirtiendo en el ROOT BRIDGE.
TIPOS DE PUERTO
El switch que toma el rol de ROOT BRIDGE tendrá todos los puertos en "designated"
Tenemos 3 tipos:
- Root Port: es el que se usa para llegar al ROOT BRIDGE, el que menos coste tiene.
- Designated Port: el puerto que envía tramas. Hay uno por segmento.
- Blocking/Non-designated: es donde el árbol del STP finaliza
En el ejemplo de arriba vemos el puerto que se queda en "blocking" debido a que tiene la mac más alta ese switch (y porque todos tiene la misma prioridad).
Por lo tanto, habrá un puerto que como Root en cada switch que no es el ROOT BRIDGE. Los demás estarán en designated a no ser que uno de ellos quede como "blocking" para evitar los búcles.
El switch que es root tendrá todos sus puertos en designated con un coste de 0.
El switch que es root tendrá todos sus puertos en designated con un coste de 0.
ESTADOS DE PUERTO
Cada puerto del switch tendrá un estado dependiendo de su rol y de la convergencia de la red.
Tenemos 5 estados de puerto:
- Blocking: no envía ni recibe datos pero si recibe las BPDU's, por si tiene que cambiar. No aprende direcciones mac por este puerto.
- Listening: no envía ni recibe datos pero envía y recibe las BPDU's, es un estado transitorio. Sin embargo, es aquí cuando se decide que estado de puerto tendrá (root o designated)
- Learning: no envía ni recibe datos pero si recibe y envía las BPDU's, es un estado transitorio.
- Forwarding: envía y recibe datos y BPDU's.
- Disable: ni envía ni recibe datos ni BPDU'S
Ni blocking ni Disable son contados cuando el algoritmo STP se ejecuta
El switch con el Bridge ID más bajo será el elegido. En caso de empate será el que tenga la dirección mac más baja.
La dirección mac que utiliza es la "base ethernet". Se puede ver con un show version
- Forwarding: envía y recibe datos y BPDU's.
- Disable: ni envía ni recibe datos ni BPDU'S
Ni blocking ni Disable son contados cuando el algoritmo STP se ejecuta
CÓMO STP ELIGE EL MEJOR CAMINO
El primer paso que se da es el de elegir el ROOT BRIDGE. Cuando los switches arrancan asumen que son el Root Bridge. La elección se basa en el Bridge ID, que es un número único para cada switch. Los switches intercambian BPDU's y se elige.
El Bridge ID está compuesto de los 6 bytes de la dirección mac y 2 bytes de la prioridad. Cuanto más baja, mejor.
La prioridad está compuesta por :
La prioridad está compuesta por :
- Bridge Priority: de 0 a 61440 en incrementos de 4096 (32768 por defecto)
- Extend System ID: de 0 a 4095 (coincide con el número de vlan,no se suele modificar)
El switch con el Bridge ID más bajo será el elegido. En caso de empate será el que tenga la dirección mac más baja.
La dirección mac que utiliza es la "base ethernet". Se puede ver con un show version
Importante recordar que cada VLAN de cada switch tendrá un Bridge ID diferente.
El show del SW3 del gráfico anterior:
|
| Vemos la prioridad por defecto (32768), el Bridge ID, el Root ID, el coste, etc. |
Una vez que se ha elegido el Root Bridge en el segmento, cada switch que
no es root bridge busca el camino con menos coste para llegar a este.
Aquí es donde el switch elige el ROOT PORT. Esta elección se basa en los
costes que le asigna el protocolo STP a los diferentes tipos de enlace.
Estos costes se van acumulando a lo largo del camino hasta llega al
Root Bridge. Se mide con el ancho de banda:
En caso de empate en el coste será elegido el enlace con el Bridge ID más bajo.
Y si continua el empate, es decir, dos puertos del mismo switch, será el puerto con el número menor, es decir, preferirá la Fa0/0 a la Fa0/1
Finalmente elegirán los puertos Designated, que son los puertos que tienen menor coste para llegar al root en ese segmento y, también se elegirán los puertos en blocking.
Resumen de la elección del Root Port:
 |
Resumen de la elección del Root Port:
- Menor coste para llegar
- Bridge Id más bajo
- Puerto más bajo
En una red no podemos dejar que la elección del Root Brdige sea aleatoria. El switch central (CORE) deberá cumplir este rol. Para ello, simplemente modificamos la prioridad y nos aseguraremos que sea ese el equipo que haga de Root Brdige. Tendremos que hacerlo con cada VLAN:
switch(config)#spanning-tree vlan X priority X
Las prioridades que podemos configurar son:
También podemos configurarlo con roles:
switch(config)# spanning-tree vlan X root primary
El root primary nos baja la prioridad a 24577 para la vlan 1
El root secondary nos baja la prioridad a 28763 para la vlan 1
Si después configuramos otro equipo como "root primary", bajará 4096 de la actual que tiene el root primary para hacerse él con el rol.
Sin embargo, si en nuestro escenario un switch es configurado manualmente con una prioridad más baja, estas dejan de tener efecto y sería el nuevo equipo el que tomara el rol de Root Bridge.
Podemos configurar algo de las BPDU's.
- Hello Time: por defecto 2 segundos envía una BPDU
- Forward Delay: el tiempo que está en el estado de Learning.15s
- Max Age: configurado en la BPDU por el root. 20 segundos
Si modifcamos estos parametros, deberemos hacerlo en el Root Bridge.
switch(config)#spanning-tree vlan X priority X
Las prioridades que podemos configurar son:
0000 = 0
0001 = 4096 0010 = 8192 0011 = 12288 0100 = 16384 0101 = 20480 0110 = 24576 0111 = 28672 1000 = 32768 default 1001 = 36864 1010 = 40960 1011 = 45056 1100 = 49152 1101 = 53248 1110 = 57344 1111 = 61440 |
También podemos configurarlo con roles:
switch(config)# spanning-tree vlan X root primary
switch(config)# spanning-tree vlan X root
secondary
El root primary nos baja la prioridad a 24577 para la vlan 1
El root secondary nos baja la prioridad a 28763 para la vlan 1
Si después configuramos otro equipo como "root primary", bajará 4096 de la actual que tiene el root primary para hacerse él con el rol.
Sin embargo, si en nuestro escenario un switch es configurado manualmente con una prioridad más baja, estas dejan de tener efecto y sería el nuevo equipo el que tomara el rol de Root Bridge.
Podemos configurar algo de las BPDU's.
- Hello Time: por defecto 2 segundos envía una BPDU
- Forward Delay: el tiempo que está en el estado de Learning.15s
- Max Age: configurado en la BPDU por el root. 20 segundos
Si modifcamos estos parametros, deberemos hacerlo en el Root Bridge.
PVST (PER VLAN SPANNING-TREE)
Ya todos lo equipos tienen añadida esta característica. Simplemente crea una instancia STP para cada VLAN. Si hacemos un "show spanning-tree" veremos cada una de las instancias.
Un Root Bridge tiene que ser elegido por cada VLAN
Una característica importante es que la prioridad para el bridge cambia: se le añade el número de la VLAN. Es decir, la prioridad por defecto es 32768 pero para las VLAN:
- VLAN 1: 32768+1 = 32769
- VLAN 10: 32768+10 = 32778
Como podemos elegir modificando la prioridad el equipo que cumplirá el rol de ROOT, podemos seleccionar un equipo diferente para cada VLAN. Esto nos ayuda a balancear la carga del tráfico.
Existe un problema con STP. Los tiempos de espera en los estados del puerto pueden sumar hasta 50 segundos hasta que el puerto llega al estado de forwarding.
Para evitar esto con PC's, Servidores, equipos finales conectados al puerto se creo el PortFast: es una solución para que el puerto no espere los 50 segundos cuando recalcula STP. Lo que hace es no contar con los timers de STP y el puerto pasa al estado de forwarding mucho más rápido. Para configurarlo hay que hacerlo a nivel de interface:
switch(config-if)#spanning-tree portfast
Para evitar esta espera se inventó el RSTP para los enlaces trunk y la convergencia global.
También tenemos a nivel global dos opciones configurables más pensadas para los enlaces entre switches:
- Uplink Fast: rápida
convergencia de los uplink groups, que son un conjunto entre el root
port y una serie de blocking port para proveer una alternativa por si falla
el root port
- Backbone fast: rápida
convergencia en el backbone. Le llega una BPDU inferior de un enlace
que no tiene conectado pero la descarta.
- (config)#spanning-tree uplinkfast
- (config)#spanning-tree backbonefast
RAPID SPANNING-TREE PROTOCOL (RSTP)
Se especifica en la IEEE 802.1w. Reduce el tiempo de convergencia prácticamente a 0 segundos y proporciona redundancia de fallos. Mejora el algoritmo de STP. Es totalmente compatible con STP.
En STP solo el Root Bridge genera BPDU'S y los demás las reenvía. En RSTP, sin embargo, cada equipo genera una BPDU cada 2 segundos, por defecto, a modo de keepalive.
El puerto queda invalidado (age out) cuando llega a 3 veces el hello, es decir, 6 segundos (Max Age, que en STP eran 20). Después de este tiempo, si no se ha recibido BPDU, toda la información expira y vuelve a calcular el algoritmo, es decir, empieza la reconvergencia.
El Max Age también se puede usar en para la compatibilidad con STP.
Si enfrentamos dos equipos, uno con RSTP y el otro con STP veremos que nos lo indica el comando show spanning-tree:
Si enfrentamos dos equipos, uno con RSTP y el otro con STP veremos que nos lo indica el comando show spanning-tree:
Cualquier cambio en los puertos trunk se notifica a través de BPDU's de tipo TC. Usa un bit especial en la BPDU para señailzar el cambio de topología. Esto causa el vacío de la tabla de macs. Por eso es importante configurar los puertos edge.
Nota: comando a nivel de interface --> carrier delay
En RSTP le estado de los puertos ha cambiado:
 |
| En RSTP ahora solo tenenos discarding, learning and forwarding. |
También ha cambiado ligeramente los tipos de los puertos:
- Root Port: igual que STP
- Designated Port: igual que STP
- Alternate Port: alternativa para llegar al Root Bridge por si el Root Port falla. Este puerto actúa como si tuviera Uplinkfast habilitado. Su estado siempre será el de Discarding.
- Alternate Port: alternativa para llegar al Root Bridge por si el Root Port falla. Este puerto actúa como si tuviera Uplinkfast habilitado. Su estado siempre será el de Discarding.
- Backup Port: es el enlace de backup (non-designated) dentro del segmento. Si falla el Alternate Port, este coge su rol. Su estado siempre será el de Discarding.
 |
| Si cae el root port del switch2, utilizará el backup port |
Si un equipo no tiene Alternate Ports (a lo mejor están caídos) y se cae su Root Port, el equipo se declara Root Bridge y empieza el proceso otra vez. Esto tiene truco porque si Root Port pero no Alternate, si se cae el enlace con el Root Brdige, por mucho que quiera ahora serlo él, como no tiene camino alternativo haci a el Root Brdge, no afectará a la topología, eso sí, si tenemos bien configurados nuestros puertos edge.
En RSTP, solo los puertos "non-edge" pueden generar un cambio de topología. La perdida de conectividad ya no es considerada como un cambio en la topología. Solo los puertos non-edge hacen el proceso de sincronización. Insisto, muy importante para la reconvergencia que los puertos edge estén configurados como tales.
Los puertos "non-edge" podemos dividirlos en 2 tipos:
En RSTP, solo los puertos "non-edge" pueden generar un cambio de topología. La perdida de conectividad ya no es considerada como un cambio en la topología. Solo los puertos non-edge hacen el proceso de sincronización. Insisto, muy importante para la reconvergencia que los puertos edge estén configurados como tales.
Los puertos "non-edge" podemos dividirlos en 2 tipos:
- Point-To-Point -> Puertos Full Duplex
- Shared -> Puertos en Half Duplex. No tendríamos rápida convergencia.
(config-if)#spanning-tree link-type point-to-point
(config-if)#spanning-tree link-type shared
Para configurar RSTP:
switch(config)#spanning-tree mode rapid-pvst
Edge Port: es como el PortFast. Le decimos que hay un equipo final. Transita inmediatamente a Forwarding y no genera TCN si cambia su estado. Sin embargo, si en este puerto se recibe una BPDU, se quita el estado de "edge" y genera un TCN.
(config-if)#spanning-tree portfast edge
Tenemos otras características que tienen que ver con la convergencia heredadas de STP y que ya vienen incluídas en RSTP:
- Uplink Fast: rápida convergencia de los uplink groups, que son un conjunto entre el root port y una serie de block port para proveer una alternativa por si falla el root port
- Backbone Fast: rápida convergencia en el backbone. Le llega una BPDU inferior de un enlace que no tiene el conectado pero calcula el camino más corto.
Documento de Cisco sobre RSTP
Para asegurarnos una rapidísima convergencia, es mejor delegar la detección a los protocolos que moitorizan los enlaces físicos, como UDLD, BFD, etc. No tener mucha reduncia y una red pequeña también ayuda.
No siempre STP o RSTP se ajustan a las necesidades de nuesra topología. En enlaces de larga distancia la convergecia puede ser muy lenta. Existen otro protocolos para dar soluciones diferentes como REP (Resilient Ethernet Protocol) que se usa en redes MetroEthernet. En topología en anillo tampoco son efeicientes.
MULTIPLE SPANNING-TREE (MST)
El estandar IEEE es el 802.1s. Deriva del protocolo inicial MISTP de Cisco . Combina lo mejor de PVST y STP. La idea principal es que puede agrupar varias VLANS para una misma instancia STP. Reduce la carga de proceso en el switch pero es más complejo de configurar.
Es compatible con CST y con PVST+. El CST Root debe estar dentro del dominio de MST, si no fallará.
Es compatible con CST y con PVST+. El CST Root debe estar dentro del dominio de MST, si no fallará.
La BPDU tiene un campo más: el MST
La configuración se basa en regiones donde metemos los switches de la red que queremos que participen en el proceso MST. Pensad en las regiones como si fueran AS (Sistemas Autónomos de BGP).
Hay que configurar:
Hay que configurar:
- MST Region (32 bytes)
- Revision number (2 bytes)
- Asociar la VLAN a la instancia MST
Estos 3 parámetros conforman un "hash" que irá en cada trama, en el payload. No va en las BDPU'S. Si analizamos la trama con Wireshark es el campo MST Config Digest.
Obviamente, para pertenecer a la misma región, los switches deben tener configurado el mismo nombre de Región. Y deben coincidir sus asociaciones de vlan que funcione correctamente. Por cierto, también se considera otra región diferente si está conectado a un switch con 802.1D.
Obviamente, para pertenecer a la misma región, los switches deben tener configurado el mismo nombre de Región. Y deben coincidir sus asociaciones de vlan que funcione correctamente. Por cierto, también se considera otra región diferente si está conectado a un switch con 802.1D.
Las regiones se dividen en dos:
El coste de los puertos aumenta automáticamente. Y el Extension System ID ahora coincide con el número de MST. Usará por defecto el comando spanning-tree pathcost method long
En cada region, si lo miramos desde el punto de vista de STP básico, tendremos un Root Bridge para la region MST al que se le denomina como CIST Regional Root y, luego habrá un Root Bridge para todo el dominio que será el CIST Root. La elección de estos roles se basa en la misma que STP, tanto a nivel intra-regional como inter-regional: el Bridge ID más bajo, gana.
Cuando las regiones no son iguales, es decir, se interconectan, debemos planificar bien cuáles son los límites de las regiones (boundaries). A los puertos que interconectan regiones MST se les llama Boundary Ports.
- Intra-Region:
- Los detalles de la región solo se conocen dentro de ella
- La asociación de VLAN'S a STPI's(instancia de STP) es manual
- Las VLANS que no se definan se agrupan en la CIST (MST 0)
- Inter-Region:
- Los detalles entre las regiones no se conocen
- Las regiones se ven entre ellas como "virtual bridges"
- Simplifica el cálculo
El coste de los puertos aumenta automáticamente. Y el Extension System ID ahora coincide con el número de MST. Usará por defecto el comando spanning-tree pathcost method long
En cada region, si lo miramos desde el punto de vista de STP básico, tendremos un Root Bridge para la region MST al que se le denomina como CIST Regional Root y, luego habrá un Root Bridge para todo el dominio que será el CIST Root. La elección de estos roles se basa en la misma que STP, tanto a nivel intra-regional como inter-regional: el Bridge ID más bajo, gana.
Cuando las regiones no son iguales, es decir, se interconectan, debemos planificar bien cuáles son los límites de las regiones (boundaries). A los puertos que interconectan regiones MST se les llama Boundary Ports.
Para configurarlo MST a nivel global:
switch(config)#spanning-tree mode mst - habilitamos MST
Si solo habilitamos mst y no configuramos nada más, todas las vlans se asociarán a las MST 0. Esto nos puede ser útil en un escenario de MLAG:
Si entre estos equipos etamos pasando,por ejemplo, 100 vlans, en un cambio de topología tendría que hacer los 1000 cáĺculos, pero si metemos a los 3 equipos en las mst 0, no los haría, ya que el Root Port para llegar al Root Brdige seguiría siendo sobre el mismo enlace.
Un Bridge MST tiene que gestionar al menos dos instancias:
- 1 Internal Spanning-Tree (IST) -> la IST 0 o en ios MST 0
- 1 o más Multiple Spanning-tree Instances (MSTIs)
En cada región, MSTP mantiene varias IST. La IST 0 (en IOS MST0) es especial, es el STP que corre dentro de una región MST. Las demás instancias se numeran de la 1-4094
La IST 0 es la única que envía y recibe BPDU'S. Toda la información restante sobre spanning-tree va en las MSTP BPDU'S, que son las que llevan toda la información de todas las instancias, por lo que el tráfico de BPDU'S se reduce drásticamente.
Todas las instancias dentro de la región comparten los tiempos del protocolo, pero cada una tiene su propia topología, como por ejemplo el Root Bridge.
Por defecto, todas las vlan se asignan a las IST 0 (en IOS es MST0).
Las demás instancias MST son locales, es decir, la instancia MST 10 de la Región 10 es independiente de la instancia MST10 de la region 20.
Los roles serían:
- CIST Root: el root para toda la red
- CIST Regional Root: el root para la región
- MSTI Root Regional Root: el root para esa instancia en la región
El rol de CIST Root y el CIST Regional Root lo cumplirá el mismo equipo en una de las regiones, en la que tiene el CIST Root, obviamente.
 |
| Diferente terminología de MST |
Recordad que también tendríamos el rol típico de Root Bridge de STP normal, para los
Para una configuración más detallada:
switch(config)#spanning-tree mst X priority 8192 - para cambiar la prioridad
switch(config)#spanning-tree mst configuration - aquí entramos en el modo config
switch(config-mst)#revision X
switch(config-mst)#name XXX
switch(config-mst)#instance X vlan X, X - añadimos VLANS a la instancia
switch(config-mst)#instance X cost
switch(config-mst)#instance X port-priority
Para manipular la elección del CIST Root:
switch(config-mst)#instance X priority
switch(config-mst)#instance X root primary/secondary
switch#show spanning-tree instance X
switch#show spanning-tree mst configuration
Podemos incluso usar el comando bandwidth a nivel de interface para modificar costes.
Una cosa a tener en cuenta es que cada vez que asociamos una vlan a una instancia MST, el hash se recalcula. Va a ser menos de un segundo pero hay que saberlo.
Otra característica es que VTP version 3 soporta MST.
Documento de Cisco sobre MST
LABORATORIO STP
LABORATORIO MSTP
ideas sueltas sin un ejemplo solido , igual se agradece
ResponderEliminarEs teoría Morpheo. Si quieres ejemplos sólidos debes ir a la sección de Laboratorios o, también puedes montarte tus propios laboratorios. Si es para practicar SPT, te recomiendo el PacketTrace de Cisco que es más configurable que en GNS3. Saludos.
ResponderEliminar