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, change
d state to up
Jan 11 12:33:04 MET: %LINK-3-UPDOWN: Interface FastEthernet0/14, change
d state to up
Jan 11 12:33:05 MET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Fa
stEthernet0/13
, changed state to up
Jan 11 12:33:05 MET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Fa
stEthernet0/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.