Broadcast storm control

Fecha: Sábado 25 de Junio, día de tormenta (de broadcast)

Clase: CCNA4, tema derivado de CCNASec del Jueves 23.

En un ambiente de laboratorio, conectamos varios equipos a un switch Catalyst 2960 y realizamos las siguientes pruebas:

1. Conectamos un PC al port Fa 0/1

2. Configuramos todos los puertos FastEthernet en modo portfast

3. Realizamos un loop mediante un patch cord en los ports Fa0/2 y Fa0/13

4. Generamos un broadcast en el PC de Fa0/1 mediante ipconfig /renew

5. Verificamos que el spannig-tree ajustaba el port Fa0/13 en estado de bloqueo

6. Realizamos la contraprueba conectando Fa0/13 y Fa 0/15 ajustando el port Fa0/15 en estado de bloqueo

debido al número de puerto mayor.

7. Hasta el momento, la tormenta de broadcast no podía generarse

8. Configuramos todos los puertos FastEthernet en modo bpdufilter enable (filtrado de las BPDU en forma saliente)

9. Realizamos un loop mediante un patch cord en los ports Fa0/2 y Fa0/13

10. Esta vez, desatamos la tormenta de broadcast, llevando el procesador del switch al 65%

11. Configuramos todos los puertos FastEthernet en modo storm control al 15% del BW

12. Generamos un broadcast en el PC de Fa0/1 mediante ipconfig /renew

13. Intentamos desatar la tormenta de broadcast y realizamos las correspondientes mediciones.

Errata: hasta el 28/6 figuraba Fa0/13 como bloqueado por STP en el punto 6

Datos capturados aún habilitando el modo PortFast:

Configuración final:

Switch#sh runn

---resumido---

hostname Switch

no file verify auto

spanning-tree mode pvst

interface FastEthernet0/1 (no hay configuración sobre modo de acceso: default auto, vlan 1)

spanning-tree portfast

spanning-tree bpdufilter enable (ATENCION: de esta manera no detecta su propia BPDU en forma entrante, ya)

! que en el port saliente (y hacemos un loop) no se transmiten las mismas)

---resumido---

Switch#sh proc cpu (estado normal)

CPU utilization for five seconds: 4%/0%; one minute: 4%; five minutes: 10%

Switch#sh proc cpu (al desatarse la tormenta)

CPU utilization for five seconds: 67%/34%; one minute: 36%; five minutes: 10%

---resumido---

Ejecutamos la supresión de tormentas:

Switch(config-if-range)#storm-control broadcast level 15 (portcentaje del BW total en el port)

Switch(config-if-range)#storm-control action shut

Switch(config-if-range)#^Z

1. Realizamos un loop mediante un patch cord en los ports Fa0/13 y Fa0/23

2. Generamos un broadcast en el PC de Fa0/1 mediante ipconfig /renew

00:07:14: %SW_MATM-4-MACFLAP_NOTIF: Host 001b.387e.f171 in vlan 1 is flapping between port Fa0/23 and port Fa0/13

00:07:15: %PM-4-ERR_DISABLE: storm-control error detected on Fa0/13, putting Fa0/13 in err-disable state

00:07:15: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected on Fa0/13. The interface has been disabled.

00:07:15: %PM-4-ERR_DISABLE: storm-control error detected on Fa0/23, putting Fa0/23 in err-disable state

00:07:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down

00:07:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to down

00:07:17: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to down

00:07:17: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to down

Generamos nuevamente broadcast utilizando una herramienta de flooding:

00:09:47: %PM-4-ERR_DISABLE: storm-control error detected on Fa0/1, putting Fa0/1 in err-disable state

00:09:47: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected on Fa0/1. The interface has been disabled.

00:09:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

00:09:49: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down

Switch(config)# int range fa0/1-24

Switch(config-if-range)#shut

Switch(config-if-range)#no shut

Switch(config-if-range)#^Z

Acerca del comando down-when-looped si bien ingresan los comandos, no tienen ningun efecto en el switch

Switch#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch(config-if-range)#int range fa0/1-24

Switch(config-if-range)#down-when-looped

Switch(config-if-range)#

Fuente: http://www.cisco.com/en/US/docs/ios/12_1/interface/command/reference/irddelay.html#wp1017522

down-when-looped command: To configure an interface to inform the system it is down when loopback is detected,

use the down-when-looped interface configuration command.

Syntax Description: This command has no arguments or keywords.

Defaults: Disabled

Usage Guidelines: This command is valid for HDLC or PPP encapsulation on serial and HSSI interfaces.

Backup Interfaces: When an interface has a backup interface configured, it is often desirable that the backup interface

be enabled when the primary interface is either down or in loopback. By default, the backup is only enabled if the primary

interface is down. By using the down-when-looped command, the backup interface will also be enabled if the primary

interface is in loopback.

Testing an Interface with the Loopback Command: If testing an interface with the loopback command, or by

placing the DCE into loopback, down-when-loopedshould not be configured; otherwise, packets will not be

transmitted out the interface that is being tested.

Examples: The following example configures interface serial 0 for HDLC encapsulation. It is then configured to

let the system know that it is down when in loopback mode.

Router(config)# interface serial0

Router(config-if)# encapsulation hdlc

Router(config-if)# down-when-looped

Related Commands:

Command Description

backup interface Configures an interface as a secondary or dial backup interface.

loopback (interface) Diagnoses equipment malfunctions between an interface and a device.

Foto: Dispositivo de loop de una interfaz serial

(2011) Funny girls don’t read about networking

Rosario, Argentina