Un protocolo ineludible en la implementación de redes conmutadas es STP (Spanning Tree Protocol). Es un protocolo estándar (IEEE 802.1d), desarrollado inicialmente para administrar enlaces redundantes en redes conmutadas utilizando bridges. El protocolo inicial presenta 2 limitaciones importantes:
- La administración de redundancia se hace definiendo una topología activa y bloqueando los enlaces redundantes. La primer consecuencia de este proceso es la imposibilidad de aprovechar completamente el ancho de banda instalado realizando balanceo de tráfico, como ocurre con las rutas redundantes en el enrutamiento IP.
- Por otra parte, en el caso de un fallo, un puerto STP demora 50 segundos en pasar del estado de blocking al de forwarding. Estos tiempos de convergencia son muy altos para las redes actuales.
Port Fast
- Feature propietario de Cisco.
- Permite acelerar los tiempos de habilitación de un puerto al momento de conectar una terminal a una boca de un switch.
- Sólo se habilita en puertos de acceso.
- Si la interfaz recibe una BPDU de STP, pasa inmediatamente al estado de blocking, y a operar en el modo normal de STP.
- Switch(config)#interface fastEthernet 0/1
Switch(config-if)#spanning-tree portfast - Switch(config)#spanning-tree portfast default
PVSTP
- Per VLAN Spanning Tree Protocol
- Implementación propietaria de Cisco.
- Genera una instancia de STP para cada VLAN.
- Utiliza enlaces troncales ISL.
- Permite distribuir el tráfico de las diferentes VLANs generando diferentes topologías activas.
- Switch(config)#spanning-tree mode pvst
- Per VLAN Spanning Tree Protocol Plus.
- Implementación propietaria de Cisco.
- Semejante a PVSTP, pero para operar sobre enlaces troncales 802.1Q.
- Implementación estándar.
- Mejora notablemente los tiempos de convergencia del protocolo.
- Incluye una funcionalidad semejante a port fast, denominada port edge.
- Mantiene compatibilidad con STP.
- Implementación de RSTP propietaria de Cisco.
- Genera una instancia de RSTP para cada VLAN creada.
- Utiliza enlaces troncales IEEE 802.1Q.
- Switch(config)#spanning-tree mode rapid-pvst
MSTP (IEEE 802.1s)
- Implementación estándar de RSTP.
- Genera hasta 16 instancias de RSTP.
- Se deben asociar las VLANs a las instancias creadas.
- Utiliza enlaces troncales IEEE 802.1Q.
- Es menos exigente en procesamiento y reduce el número de actualizaciones que se envían.
Los switches Catalyst 2960 implementan por defecto PVSTP+ y permiten configurar port fast, RPVSTP+ y MSTP.
Enlaces de referencia:
¿Tenés alguna información o referencia adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta.
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta.
un punto importante es comprender como STP elige a un Switch como Root del arbol STP, y los diferentes estados por los cuales transitara el proceso de bloqueo y habilitacion de los puertos en entornos LAN con STP, y sus variantes, habilitado dado que a la hora de detectar fallos ocurre que al desconocer esos conceptos se presuponen condiciones erroneas y se demora en la resolucion de los problemas.
ResponderBorrarSTP no necesariamente necesita un switch potente, pero si necesita un switch ubicado estrategicamente, dado que ese switch tendra la "vision" completa del proceso STP. (pregunta recurrente en los foros)
STP es muy util para conexiones desde puertos del Switch hacia estaciones de trabajo u otros dispositivos, pero esta contra-indicado en entornos con switches en cascada o "back-to-back" dado que puede generar bucles indefinidos entre los puertos up-link vinculantes.
comandos utiles:
----------------
* show spantree vlan_id — muestra el estado actual del arbol stp segun la ID de VLAN (desde la perspectiva del switch en el cual se implemento este comando)
* show spantree summary - brinda un resumen de los puertos stp conectados, por VLAN.
* show spantree statistics - brinda info estadistica.
* show spantree backbonefast - permite conocer si la funcion BackboneFast Convergence, esta habilitada.
* show spantree blockedports— informa sobre los puertos que estan en estado de bloqueo.
* show spantree portvlancost— muestra el costo de ruta de las VLAN's sobre un puerto. esto es util dado que STP elige su puerto root de STP por el costo del mismo salvo que se haya modificado manualmente la seleccion de la prioridad.
* show spantree uplinkfast— muestra los parametros UplinkFast.
My two cents! =o)
Saludos Cordiales!
Mike
s/50 minutos/50 segundos/
ResponderBorrar50 segundos.
ResponderBorrarYa está corregido el texto. Gracias.
Este blog es excelente.
ResponderBorrarDe lo mejor que me he encontrado en la red.
¡Felicitaciones!
Realmente gracias por compartir conocimientos de networking. Blog muy interesante. Recomendadisimo
ResponderBorrarOscar, te felicito por tu blog. Me sirvio mucho para obtener la certificación CCNA.
ResponderBorrarRealmente exelente!
saludos
falta un comando imprescindible:
ResponderBorrarspanning-tree vlan 'id de la vlan' root primary(secundary)
con esto cambiamos la prioridad del switch para que sea el root primario o secundario.
Amigo.
ResponderBorrarEse comando es el que permite, en implementación de pstp, modificar la prioridad de STP para manipular la elección del root bridge. Es necesario y aplica a ese caso.
Hola que tal
ResponderBorrarUna pregunta a que te refieres con "Implementación estándar" lo mencionas en varios protocolos.
Saludos
R762
Utilizo "implementación estándar" como alternativa a "implementación propietaria".
ResponderBorrarPor ejemplo, MSTP es una implementación estándar de RSTP aprovechando la división de VLANs, mientras que RPVST es una implementación propietaria de Cisco del mismo RSTP.
Ok, gracias .....
ResponderBorrarSaludos
R762
Muy claro y muy buen material
ResponderBorrarHola Oscar, y una pregunta al tema de STP, mas concretamente en RPVST (spanning-tree mode rapid-pvst).
ResponderBorrarEntiendo que los puertos en modo acceso deben ser portfast, y entiendo que deben serlo todos, es decir, incluso los conectados directamente a cores (root). Pero que me dices de "link-type point-to-point"?, deberia tenerlo configurado todos los puertos troncales?, incluido los de los cores?.
Gracias de antemano y enhorabuena por este sitio.
Primero.
ResponderBorrarPortfast en los puertos de acceso es decir puertos que tienen conectado un equipo terminal. Los puertos que van hacia los core (que conectan con otro dispositivo STP) no se configuran con portfast.
Segundo.
Cuando trabajás con RSTP en cualquiera de sus formas, cuando el protocolo trabaja en contextos que no son point-to-point puede definir diferentes estados de puerto (bakcup, por ejemplo). Esa opción la utilizás cuando a un segmento de red se conectan varios dispositivos STP, pero no deseás que se haga elección de puertos alternativos.
Yeyi.
ResponderBorrarLa definición de core o acceso se refiere a posición que ocupa un dispositivo dentro de la topología y participación en los flujos de tráfico dentro de la red. Eso no impacta directamente en STP.
PortFast es un feature que cambia la operación por defecto de STP en los puertos de acceso, haciendo que al momento de iniciar la operación lo hagan en estado de forwarding y no de blocking. Esto ahora tiempo en el acceso de las terminales a la red, ya que no hay transición de STP.
PortFast es un feature que se activa en puertos de acceso, no en puertos troncales o de backbone. Esto es independiente de si un equipo es core o no.
Por otra parte, la definición de point-to-point no es de los switches, sino de los enlaces. Y esto depende de cómo se desea que opere STP en esos enlaces.
Ninguno de estos 2 features es obligatorio para la operación de STP, sino que son parte del ajuste o tunning de la operación del protocolo. Si se implementan mal, obviamente, generarán problemas en la operación regular.
Bien, Oscar, parece entonces que lo estoy haciendo mal, con el point-to-point, ya que todos los puertos de switches que conectan con switches los tengo configurados como point-to-point.
ResponderBorrarme dan muchos errores cuando existen cambios de topologia STP, algunos switches con ios antigua desactivan ciertas bocas por keepalive:
.Mar 7 13:02:27: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on Gi
gabitEthernet0/1.
.Mar 7 13:02:27: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in er
r-disable state
No se si esto tiene mucho que ver con STP, parece que no, se que se puede desactivar el keepalive, pero no termino de entender por que lo dan.
Seguiré investigando, he intentado activar algun debug de spanning tree, pero son demasiados mensajes los que recibo, no se como realizar alguna especie de filtro a estos.
Por donde piensas que debería empezar?, Saludos y perdona por la desorganizacion de la informacion.
Yeyi
ResponderBorrarEse tipo de errores puede ser provocado por una mala configuración de STP.
Para poder dar una respuesta seria, habría que tener una visión completo de la red y su configuración. Lo que te sugeriría como método simple es que limpies la configuración avanzada de los puertos; la red operando con su configuración por defecto (esto es si vlans, si troncales, no portfast, no tunning de stp), verifiques que todo opera correctamente, y luego vayas implementando paso a paso y verificando.
Una posible causa de esos errores es STP, pero hay que ver todo para dar una respuesta seria.
Hola buenas tardes Oscar Gerometta un gusto saludarte tengo una duda, porque no es aconsejable configurar el PORFAST en puertos que esten configurados como TRUNK ???
ResponderBorrarCreo que el término más ajustado sería decir que no es una best practice.
BorrarPort Fast tiene el objetivo de acelerar la disponibilidad de los puertos de acceso cambiando el modo en que levanta un puerto por defecto, de blocking a forwarding.
Esto permite ganar 30 segundos en el proceso de negociación del puerto, y que por lo tanto la terminal esté más rápidamente en condiciones de generar y recibir tráfico sobre la red.
Sobre un puerto troncal, que por definición debería estar permanentemente up, esto no significa ninguna ventaja.
Gracias Oscar por la explicacion, fijate que hace como 4 meses compramos en la empresa donde trabajo un core catalyst 4,500 y 5 switches 2960 pero necesito un manual de como configurar las alertas en el CISCOWORKS LMS 4.0 tendras algun manual o un link en donde me pueda orientar de como inicializar dicho programa ??
BorrarAndrés.
BorrarLo que necesitarías son los manuales y guías que vienen con el LMS.
Te paso algunos enlaces al respecto:
http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_lan_management_solution/4.0/user/guide/configuration_management/lms_config.pdf
http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_lan_management_solution/4.0/user/guide/inventory_mgmt/inventoryug.pdf
http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6504/ps6528/ps11200/deployment_guide_c07-618226.html
Una duda Oscar si yo tengo un router con un modulo de switch de 8 puertos y le conecto un catalyst 3560, configuro dos vlanes entre ellos en acceso, entiendo que no hay riesgo de bucles, aunque por detrás tenga mas switches. Podría tener un bucle por detrás, pero no esa conexión entiendo, aunque cambiara esa conexión a troncal puesto que solo hay un enlace físico.
ResponderBorrarSi tengo los puertos en acceso entiendo que no tendría sentido configurar STP entre la tarjeta de 8 puertos y el catalyst, pero y ¿si estuvieran en troncal sería buena idea? ¿Pueden bloquearse en este ejemplo los puertos aunque estén en acceso?
No me termina de quedar claro como sería la conexión, pero supongo que se trata de 2 VLANs en ambos switches (el módulo y el 3560), y ambos switches conectados entre sí utilizando puertos de acceso de cada una de las VLANs.
BorrarComo cada VLAN es un dominio de broadcast diferente, y adicionalmente los switches Catalyst implementan por defecto PVSTP+, allí no habrá bucles, pues hay un solo enlace para cada VLAN.
Sin embargo no es recomendable desactivar STP, ni en ese caso ni en ningún otro, por una cuestión de seguridad. STP es el único mecanismo que tenemos para prevenir la formación de bucles de layer 2 que es devastadora para los switches. Por este motivo no se recomienda desactivar STP, sino pasar los puertos de acceso a modo portfast.
Pero si no hay riesgo de bucle en ese enlace ¿porque no desactivar STP? Además ¿habría diferencia en el comportamiento de STP y en la posibilidad de bucles si el enlace fuese troncal y tuviese otro router al mismo swtich, de la misma forma para tener redundancia usando HSRP?
BorrarMantener STP por lo que mencioné, por seguridad.
BorrarSi no hay bucles, STP no molesta, y si inadvertidamente o ex profeso en algún momento se generara uno, STP evitaría una saturación de los switches. Entonces creo que la pregunta es otra ¿por qué querés sacarlo? ¿por qué no aplicar una best practice?
Respecto del troncal, la pregunta creí que había quedado respondida: 2 VLANs son 2 dominios de broadcast independientes, y consecuentemente 2 árboles de STP independientes también. Es lo mismo solo que sobre un único enlace físico.
En lo que hace a redundancia aplicando HSRP, eso ya complica más la topología y el diseño y habría que ver bien qué es lo que se está haciendo.
Pues sería crear una SVI por cada vlan en los módulos de 8 puertos, e irían conectadas al catalyst 3560, y configuraría el hsrp en las SVI, de esa forma hay redundancia, pero creo que sigue sin haber riesgo de bucles.
BorrarDisculpa, pero sigo sin comprender tu objetivo. ¿Cuál es el propósito de configurar HSRP entre SVIs que están en un mismo dispositivo? Eso no da redundancia de gateway físico, ni de dispositivo de salida, ni de enlace de salida. Es decir, no tendrías redundancia real.
BorrarLas SVIS no está en el mismo dispositvo van al mismo switch de capa2, pero estan en distintos routers. Esto es yo tengo un router con dos SVIs y otro router con las mismas SVIs para tener redundancia configuro HSRP y se conectan a un switch de capa2. O aunque haya una sola SVI un cable del módulo del primer router al siwtch de capa2 (ponte que es un 2960 en vez de un 3560) y otro cable del módulo del 2º router al mismo 2960. Tengo redundancia sin riesgo de bucles, por eso lo de desactivar STP al menos entre el 2960 y los routers. Espero haberme explicado mejor.
ResponderBorrarAmigo, lo que no queda claro es cuál es la implementación real. ¿tienes 2960 o 3560? ¿porqué estás terminando en un módulo de switching y no en puertos LAN del router?
BorrarInicialmente hablaste de 1 ISR con un modulo de switching de 8 puertos. Pero ahora son 2 routers, cada uno con un modulo.
¿Cuál es la implementación real?
Termino en un modulo de switch porque se implemento asi creo que se hizo asi para tenerla flexibilidad en un de poder conectar maquinas directamente a los módulos por si en un momento dado no se podia poner un switch o se hacia innecesario por tener muy pocos equipos, aunque pueda parecer poco logico el caso es q esta asi.
BorrarLa implementación real son dos ISR serie cada uno con un módulo de switching de 8 puertos, conectados a un switch de capa 2, es un 3560 pero solo funciona en capa 2, no se utiliza como router, es un switch, por eso te hablaba luego de un 2960 para evitar la idea de que el 3560 se esté usando como router, solo se utiliza como switch, al que conecto ordenadores y teléfonos.
ResponderBorrarBien. Retomando entonces el hilo inicial: deshabilitar STP en esos puertos layer 2 no trae ningún beneficio y entraña el riesgo de que accidentalmente se genere un bucle. Consecuencia: si son puertos de acceso aplicar PortFast.
BorrarEn esa topología, si no se quiere utilizar STP ente el switch y el router, la mejor solución es pasar el 3560 a que opere en capa 3, y se rutee la salida hacia los routers.
Finalmente, se puede aplicar HSRP, pero no tendrá limitaciones en su implementación pues hay un único punto de fallo en el medio, que es el switch 3560. Sería más efectivo que el 3560 estuviera ruteando, pues así al menos podría balancear tráfico entre las 2 rutas de salida.
Consejo: sin cambiar los dispositivos, rediseñar la solución. La implementación de ese rediseño puede llevar pocas horas y hará la red más estable y performante.
Cuando se calcula el root bridge y otras cosas se utiliza la direccion Mac del Switch, pero por ejemplo un switch de 24 puertos tiene 24 direcciones Mac, al igual que un router con 3 puertos tiene 3 direcciones Mac. Cuando se estudia el CCNA se habla de que cada tarjeta de red tiene una dirección Mac. Por eso entiendo que los dispostivos con varias interfaces (routers o switches o hubs) tarjetas de red tienen varias direcciones Mac.
ResponderBorrar1. El root bridge se integra prioridad.MAC.
Borrar2. Los puertos de un switch capa 2 no son semejantes a la interfaz de un router. No son en sí mismos origen ni destino de tráfico, sólo puertas de tránsito. Por lo tanto no requieren identificador de capa 2, 3 o 4.
3. Las placas de red y las interfaces de los routers sí son origen o destino de tránsito, por lo que sí requieren identificadores.
4. El plano de management de los switches Catalyst sí es origen o destino de tránsito. De ahí que cuentan con una IP de management.
Finalmente, para cubrir diferentes propósitos, los switches Catalyst tienen asignado un rango de direcciones MAC que se asignan a cada interfaz virtual que se crea, como es el caso de la interfaz VLAN 1 (de management por defecto).
Respondiendo a tu frase final, switches o hubs no tienen tarjetas de red, sino puertos, que no requieren ID de ningún tipo.
Sí, pero por ejemplo para el cálculo del STP si la prioridad es la de por defecto, decide la direccion MAC del Switch , pero ¿cuál?. Los puertos de los switches dices que no requieren identificador, pero si te fijas en cualquier catalyst cada uno de sus puertos físicos tiene una MAC.
BorrarEs muy simple, si revisas la etiqueta del equipo, documenta la MAC asignada al switch en sí mismo. Esa es la que utilizará STP.
Borrar¿A que te refieres con la etiqueta del equipo?
BorrarPues a una etiqueta que has de encontrar en la parte posterior o inferior del gabinete del switch.
BorrarPero, ¿no se puede ver a través de la línea de comandos, cual es la mac asignada al switch, con un show version o algo parecido?
ResponderBorrarEso lo podrías averiguar por tí mismo ejecutando el comando. Como decís, show version te muestra la MAC raíz asignada al switch.
BorrarAhora, y para aclarar el propósito de este intercambio. ¿Para qué querés saber previamente la MAC del switch?
En el caso de los switches Catalyst es de poco utilidad porque implementan por defecto PVSTP+, y en consecuencia tienen un Bridge ID por cada VLAN, y ese BID se forma a partir de la MAC asignada a la VLAN que podés verificar con el comando show spann.
Por ese motivo, se define el root por diseño y en la implementación se procede a configurar la prioridad.
De acuerdo no sabía que para PVSTP+ utiliza la de la Vlan. Pero de todas maneras no viene mal saber la mac raíz. Gracias
BorrarOscar, que tal, una consulta de mstp se puede tener un rootbridge con 2 regiones y tener 3 switches con una region y otros 3 con otra region pero siempre apuntando al mismo rootbridge?
ResponderBorrarSaludos y gracias!
Matías.
BorrarQuizás te entienda mal, pero creo que se confunden 2 conceptos.
Una región es un conjunto de dispositivos que comparten una misma política de gestión MSTP.
Un root bridge es la base del árbol de STP que se forma por cada instancia de MSPT, no por cada región. Típicamente tendremos una única región, en la que corren múltiples VLANs que se agrupan en instancias de MSTP, y cada instancia tendrá su propio root bridge. Por supuesto que las diferentes instancias pueden tener su root bridge en el mismo dispositivo.
Estimado Oscar:
ResponderBorrarTengo una duda, he estado estudiando esta parte del STP, pero mi duda es:
Cuales son las diferencias entre PVST+, RSTP, STP, PVST. He estudiado y ya sé como sacar el Root Bridge, Designed Ports, Root Port, etc pero solo con STP.
Cual es la diferencia de este con los demás?
Saludos!
Mario.
BorrarEn primer lugar, el post que referencio a continuación tiene una síntesis de las variantes de STP:
http://librosnetworking.blogspot.com/2008/09/stp-en-switches-cisco-catalyst.html
En segundo lugar, el siguiente documento de Cisco completa la información y las guías de configuración:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_53_se/configuration/guide/2960scg/swstp.html
Que diferencia se presenta en los protocolos STP,RSTP, yMSTP entre las tecnologías CISCO y 3COM ?
ResponderBorrarLos protocolos que mencionas son todos estándares definidos por la IEEE, por lo tanto no hay diferencias entre fabricantes respecto a los protocolos en sí mismos.
BorrarLas diferencias son a nivel de producto: ¿cuáles de estos protocolos se soportan? ¿cuáles son las modalidades de configuración? ¿cuáles son los parámetros que se permite ajustar? Y esto varía no solo entre fabricantes, sino también entre productos de un mismo fabricante.
Hola, tengo un 6500 con PVST y un 6800 con RPVST. ¿Alguna incompatibilidad?
ResponderBorrarThnx!
En principio no hay incompatibilidad entre diferente modos de STP ya que está asegurado el formato uniforme de la información. El posible problema es que no se tenga la mejor performance posible ya que en el 6500 no se están aprovechando algunas características de RSTP.
Borrar¿Cuál es el motivo para no configurar RPVST en el 6500?
oscar hasta ahora no entiendo el uso de prioridad de puerto 128.x y el uso del comando en modo Interfaz spanning-tree vlan 1 port-priority 20 , si con los parametros de costo e0/0=100 , f0/0=19 ,g0/0=4 ya se puede configurar los roles de puertos ,nos puede dar un ejemplo simple
ResponderBorrarMorpheo
BorrarEl costo del puerto impacta en el costo total de la ruta hacia el root-bridge y por lo tanto es un parámetro de uso general en la red ya que su impacto depende de la ruta misma.
La prioridad, en cambio, es un parámetro exclusivamente local para impactar en la elección del puerto raíz. Por ejemplo, cuando un dispositivo tiene más de un camino de igual costo hacia el switch raíz. En ese caso puedes utilizar el costo para forzar la elección del puerto de tu preferencia en ese switch, sin impactar en el costo general de la ruta.
Oscar si en una topologia existen switch cisco y no cisco; cual de todos lo protocolos se deben usar para evitar bucles?
ResponderBorrarCarlos
BorrarLa respuesta rápida es MSTP.
Sin embargo es necesario tener en cuenta que en el caso de STP todas las versiones disponibles son compatibles entre sí. Esto es, independientemente del modo elegido la estructura de los BPDUs y del BID es siempre la misma, lo que asegura que cualquier dispositivo puede utilizar la información en las BPDUs generadas por cualquier switch.
Además, en todos los casos, una instancia de STP denominada CSTP está corriendo siempre para asegurar la compatibilidad entre todos los miembros del segmento de red en cuestión.
De esta manera, lo mejor y más simple sería utilizar MSTP. Pero también es posible utilizar diferentes variantes sin que se generen bucles, pero en ese caso la definición de la topología activa será más complicada.
gracias Oscar; y los protocolos que no se podrían usar en una topologia mixta serían RPVSTP+ y PVSTP+ al ser propietarios de Cisco?
BorrarCarlos
BorrarComo comenté antes, dado que está asegurada la compatibilidad todo dependerá del diseño de la red y la distribución de los diferentes switches.
Oscar gracias por su aporte en este mundo de la interconexion de redes.
ResponderBorrarMe queda una duda de dos características de STP de las cuales aun no me queda claro en que escenario o conexto se debe configurar
Oscar que pasa si en un switch tiene STP y en otro esta RSTP y en otro escenario que pasa si en un switch tiene RSTP y en otro esta MSTP
ResponderBorrarCuando en un mismo dominio de broadcast hay diferentes versiones de STP (lo que no es el escenario ideal) la topología libre de bucles está asegurada por una instancia de CSTP que asegura la compatibilidad en toda la red.
BorrarAdemás, esta compatibilidad está asegurada en el intercambio de información por una misma estructura de BPDU, un único modo de cálculo de los costos y un formato compatible de BID.
Hola. Si quisiera utilizarlo solo para que me quede siempre en funcionamiento un enlace punto a puto. Como debería ser la configuración? Es decir, tengo dos enlaces punto a punto, los cuales quisiera conectar para tener de respaldo uno en caso que se caiga el principal (actualmente uno esta desconectado para evitar el loop). Como podria jhacerlo?? Es necesario que este activo en todos los switch? Solo se puede configurar en el switch de cada punta del enlace?
ResponderBorrarAguardo Comentarios.
Saludos.
Gastón
BorrarDesconozco la topología sobre la que estás trabajando.
En general, en switches LAN corporativos, STP se encuentra activo por defecto en todos los puertos. Con lo que opera siempre bloqueando los posibles bucles a menos de que por configuración se haya anulado su operación.