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:

LAN

 

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.

LAN2

 

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

 

 

LAN3

 

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.

LAN4

 

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.