Falla de Switch Cisco
De vez en cuando encuentro a alguien que quiere deshabilitar Spanning Tree Protocol (STP) en sus conmutadores LAN. Esta es una mala idea. Considere la topología LAN típica a continuación:
Los dos switches de acceso están troncalizados, y el Switch1 mantiene una troncal al enrutador local. Todos los puertos de acceso están asignados a la VLAN 10. Un diseño ciertamente simplista pero válido. Observemos lo que ocurre cuando se introduce una conexión de capa dos redundante entre los dos conmutadores de acceso, primero con STP habilitado y luego sin él.
En el primer escenario, STP se deja a su configuración predeterminada, con una excepción: el Switch1 se ha configurado manualmente como la raíz STP para mayor claridad.
Switch1# show spanning-tree summary
Switch is in pvst mode
Root bridge for: VLAN0001, VLAN0010
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001 0 0 0 1 1
VLAN0010 0 0 0 1 1
---------------------- -------- --------- -------- ---------- ----------
2 vlans 0 0 0 2 2
Ahora imagine que, después de reorganizar algunos muebles de oficina, los usuarios finales han cableado erróneamente dos caídas de cables. (Tenga en cuenta que los switches habilitados con Auto-MDIX más nuevos formarán un enlace incluso con un cable normal sin cruce). El puerto F0/19 en el switch1 se ha conectado a F0/8 en el switch2, formando un bucle de capa dos dentro de la VLAN 10.
Con STP habilitado, esto no es un problema; la conexión redundante se marca como una ruta alternativa a la raíz en el Switch2 y posteriormente se bloquea para evitar un bucle de conmutación:
Switch2# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 10
Address 000f.345f.1680
Cost 19
Port 1 (FastEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 000e.8316.f500
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Root FWD 19 128.1 P2p
Fa0/8 Altn BLK 19 128.8 P2p
Esto hace una red feliz. Pero ahora probaremos qué sucede si un administrador negligente deshabilita STP.
Switch1(config)# no spanning-tree vlan 10
Switch2(config)# no spanning-tree vlan 10
Cuando se vuelve a hacer una conexión redundante, inmediatamente recibimos notificaciones de aleteo de la dirección MAC:
%SW_MATM-4-MACFLAP_NOTIF: Host 001d.60b3.0184 in vlan 10 is flapping between
port Fa0/8 and port Fa0/1
Estos son desencadenados por la tormenta de transmisión interminable iniciada por cada emisión de capa dos (como una solicitud ARP) desde cualquier host en la VLAN. Como STP no está presente, ninguno de los switches puede detectar el bucle de conmutación. Las tramas Ethernet no tienen concepto de TTL, por lo que circulan por el circuito sin fin.
Podemos confirmar la ocurrencia de una tormenta de difusión examinando los contadores de tráfico en cualquiera de los enlaces entre conmutadores:
Switch2# show interfaces f0/1
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000e.8316.f501 (bia 000e.8316.f501)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 57/255, rxload 57/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 22566000 bits/sec, 13031 packets/sec
5 minute output rate 22569000 bits/sec, 12969 packets/sec
4655802 packets input, 1003268438 bytes, 0 no buffer
Received 4654349 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 4637 multicast, 0 pause input
0 input packets with dribble condition detected
4609557 packets output, 1003475840 bytes, 5676 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
5676 output buffer failures, 0 output buffers swapped out
Puede observar que el rendimiento observado es solo aproximadamente el 20% de la velocidad máxima (22 de 100 Mbps). Esto se debe a que el rendimiento promedio se calcula en un intervalo de cinco minutos por defecto, y la captura anterior se tomó aproximadamente un minuto después de la tormenta. (Como un aparte, el intervalo predeterminado de cinco minutos se puede modificar con el <code>load-interval</code>comando en la configuración de la interfaz).
Uno podría sentirse tentado a argumentar que una red es invulnerable a este efecto si se usan enlaces enrutados entre todos los conmutadores de acceso. Incorrecto. Todavía es posible que se produzca un bucle de capa dos si se realizan dos o más conexiones erróneas (frente a solo la de este ejemplo).
En pocas palabras: STP existe por una razón. Déjalo ser.
