4 de septiembre de 2008

STP en switches Cisco Catalyst

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.
Estas características o limitaciones del protocolo han sido sucesivamente mejoradas en sucesivas revisiones; algunas de ellas estándar, otras, propietarias de Cisco

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
PVSTP+
  • Per VLAN Spanning Tree Protocol Plus.
  • Implementación propietaria de Cisco.
  • Semejante a PVSTP, pero para operar sobre enlaces troncales 802.1Q.
RSTP (IEEE 802.1w)
  • 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.
RPVSTP+
  • 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.

43 comentarios:

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

    STP 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

    ResponderEliminar
  2. s/50 minutos/50 segundos/

    ResponderEliminar
  3. 50 segundos.
    Ya está corregido el texto. Gracias.

    ResponderEliminar
  4. Este blog es excelente.

    De lo mejor que me he encontrado en la red.

    ¡Felicitaciones!

    ResponderEliminar
  5. Realmente gracias por compartir conocimientos de networking. Blog muy interesante. Recomendadisimo

    ResponderEliminar
  6. Oscar, te felicito por tu blog. Me sirvio mucho para obtener la certificación CCNA.
    Realmente exelente!

    saludos

    ResponderEliminar
  7. falta un comando imprescindible:
    spanning-tree vlan 'id de la vlan' root primary(secundary)
    con esto cambiamos la prioridad del switch para que sea el root primario o secundario.

    ResponderEliminar
  8. Amigo.
    Ese 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.

    ResponderEliminar
  9. Hola que tal

    Una pregunta a que te refieres con "Implementación estándar" lo mencionas en varios protocolos.

    Saludos
    R762

    ResponderEliminar
  10. Utilizo "implementación estándar" como alternativa a "implementación propietaria".
    Por 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.

    ResponderEliminar
  11. Ok, gracias .....

    Saludos
    R762

    ResponderEliminar
  12. Muy claro y muy buen material

    ResponderEliminar
  13. Hola Oscar, y una pregunta al tema de STP, mas concretamente en RPVST (spanning-tree mode rapid-pvst).
    Entiendo 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.

    ResponderEliminar
  14. Primero.
    Portfast 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.

    ResponderEliminar
  15. Yeyi.
    La 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.

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

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

    ResponderEliminar
  17. Yeyi
    Ese 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.

    ResponderEliminar
  18. 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 ???

    ResponderEliminar
    Respuestas
    1. Creo que el término más ajustado sería decir que no es una best practice.
      Port 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.

      Eliminar
    2. 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 ??

      Eliminar
    3. Andrés.
      Lo 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

      Eliminar
  19. 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.
    Si 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?

    ResponderEliminar
    Respuestas
    1. 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.
      Como 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.

      Eliminar
    2. 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?

      Eliminar
    3. Mantener STP por lo que mencioné, por seguridad.
      Si 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.

      Eliminar
    4. 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.

      Eliminar
    5. Disculpa, 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.

      Eliminar
  20. Las 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.

    ResponderEliminar
    Respuestas
    1. Amigo, 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?
      Inicialmente 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?

      Eliminar
    2. 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.

      Eliminar
  21. La 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.

    ResponderEliminar
    Respuestas
    1. Bien. 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.
      En 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.

      Eliminar
  22. 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.

    ResponderEliminar
    Respuestas
    1. 1. El root bridge se integra prioridad.MAC.
      2. 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.

      Eliminar
    2. 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.

      Eliminar
    3. Es muy simple, si revisas la etiqueta del equipo, documenta la MAC asignada al switch en sí mismo. Esa es la que utilizará STP.

      Eliminar
    4. ¿A que te refieres con la etiqueta del equipo?

      Eliminar
    5. Pues a una etiqueta que has de encontrar en la parte posterior o inferior del gabinete del switch.

      Eliminar
  23. Pero, ¿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?

    ResponderEliminar
    Respuestas
    1. Eso lo podrías averiguar por tí mismo ejecutando el comando. Como decís, show version te muestra la MAC raíz asignada al switch.
      Ahora, 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.

      Eliminar
    2. 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

      Eliminar
  24. Oscar, 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?

    Saludos y gracias!

    ResponderEliminar
    Respuestas
    1. Matías.
      Quizá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.

      Eliminar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.