Bpduguard y STP como contramedida a un loop en un switch

En este post analizaremos bpduguard como contramedida a un loop o bucle en un switch.

Esta contramedida nos permite también evitar que alguien conecte un switch que hable Spanning Tree Protocol a nuestra red.

Un loop en un switch puede provocar una tormenta de broadcast en la red.

Spanning-Tree Protocol, STP, permite tener una topología redundada en una red de capa2 libre de bucles lógicos.

Vamos a provocar un loop entre dos puertos para verificar que el switch está protegiendo a la red de loops.

Vamos a analizar diferentes configuraciones para comparar el efecto del loop sobre nuestra red.


  • Caso 1: El switch tiene activo portfast bpduguard a nivel global y los puertos de acceso están en portfast.
spanning-tree mode rapid-pvst
spanning-tree logging
spanning-tree portfast bpduguard default
spanning-tree extend system-id

Configuración de los puertos donde haremos el loop:

interface FastEthernet0/13
description LOOP
switchport mode access
switchport access vlan 100
switchport nonegotiate
spanning-tree portfast
!
interface FastEthernet0/14
description LOOP
switchport mode access
switchport access vlan 100
switchport nonegotiate
spanning-tree portfast

Si conectamos el cable entre los puertos 13 y 14, veremos que no llega a levantar, se enciende el led de link pero se apaga inmediatamente.

En los logs no aparece que ha levantado el puerto y aparece el evento que nos muestra la protección del switch al loop.

Jan 11 12:02:44 MET: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port
FastEthernet0/14 with BPDU Guard enabled. Disabling port.

Jan 11 12:02:44 MET: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/14
, putting Fa0/14 in err-disable state

Si miramos el estado de los puertos, veremos que los puertos no tienen link. El puerto 14 se ha puerto en error disable.

Dejando pings continuos entre equipos del mismo switch, veremos que no hemos perdido ni un solo paquete.

Acciones a tomar:

Debemos tener configurados los switches para enviar syslog a un servidor y que éste nos envíe un correo cuando detecte los eventos que nos interesan.

Debemos también deshacer el loop o bucle. Una vez deshecho el bucle del cable, habrá que recuperar el error disable con un shutdown, no shutdown. Existe la posibilidad de realizar un error-disable recovery automático, pero para este caso, es mejor realizarlo a mano, pues previamente deberemos deshacer el bucle del cable.

Es recomendable tener desactivados los puertos de los switches que no están en uso en un entorno de producción.

En un entorno de oficinas, donde los puertos de los usuarios están activos con estaciones y teléfonos ip, es habitual que involuntariamente los usuarios hagan loops al reconectar cables y por tanto deben existir medidas de protección como bpduguard para evitar desastres.

El error más habitual de los usuarios es que conecten dos cables del switch ( dos rosetas ) a los teléfonos ip, uno en el puerto de switch del teléfono y otro en el puerto de pc. Esto provocaria un loop.

  • Caso 2: El switch tiene activo portfast bpduguard a nivel global y los puertos de acceso no tienen activo portfast.

Atención !
Aquí estamos sin la protección de portfast bpduguard sobre los puertos
En este caso, si provocamos un loop, Spanning Tree por si sólo no hace magia !
Cuidado con esta prueba, se producirá un recálculo de STP y dependiendo de nuestra topología, de la configuración total de los switches, de la velocidad de los enlaces y de si el loop es local o entre switches puede darse el caso de interrupción en la red.

Veamos que sucede provocando un loop local:

Con la misma configuración de puertos anterior a excepción del comando spanning-tree portfast, el switch iniciará la negociación de spanning-tree en dichos puertos al detectar link.

Como hemos provocado un bucle, veremos transicionar un puerto a spanning-tree blocking.

El loop será bloqueado por el switch, no perderemos paquetes y dichos puertos estarán up pero uno de ellos bloqueado.

Veamos los logs:

Jan 11 12:33:04 MET: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
Jan 11 12:33:04 MET: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
Jan 11 12:33:05 MET: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13
, changed state to up
Jan 11 12:33:05 MET: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14
, changed state to up

cisco# show spanning-tree blockedports
Name                 Blocked Interfaces List
VLAN0100             Fa0/14
cisco#show spanning-tree interface Fa0/14
Vlan                Role Sts Cost      Prio.Nbr Type
VLAN0100            Back BLK 19        128.14   P2p
  • Caso 3: Los puertos no están en portfast pero tenemos activo bpduguard en cada puerto:
 spanning-tree bpduguard enable

Sucede lo mismo que el caso 1.

Los puertos se quedan sin link y uno de ellos entra en err-disable

Jan 11 12:46:49 MET: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/14
 with BPDU Guard enabled. Disabling port.
Jan 11 12:46:49 MET: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/14
, putting Fa0/14 in err-disable state
  • Caso 4: Un usuario conecta un hub o switch no administrable detrás de un puerto y provoca un loop con nuestro switch ( dos enlaces entre el hub/switch no administrable y nuestro switch )

Partiendo de la configuración del caso 1, un puerto entrará en error disable.

  • Caso 5 : Un usuario conecta un hub o switch no administrable y provoca un loop en el hub/switch no administrable.

Partimos de la configuración del caso 1. Aquí sucede lo mismo, pero en este caso aislará al hub/switch “enemigo”, tanto si tenemos portfast y globalmente “spanning-tree portfast bpduguard default” ( caso 1 ) o si tenemos bpduguard activo a nivel de puerto con “spanning-tree bpduguard enable” ( caso 3 )

¿ por qué ? Es sencillo, al provocar un bucle en el hub/switch que nos han conectado, provocará una retransmisión de las bpdu’s y la recibiremos sobre el puerto de nuestro switch, detectará el problema y moverá el uplink con el hub/switch a err-disable.

 

 

 

 

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *