Bucle en una VLAN hace que OSPF no publique la red

Fecha: 24 de noviembre del 2021

Escenario

Este laboratorio es parte de un escenario con equipos reales y en producción bastante más complejo, pero reproducirmos aqui

la parte que interesa también con equipos reales, y que demuestra que un bucle en una VLAN (independientemente de la causa)

hace que OSPF deje de publicar la red que representa esa VLAN (192.168.2.0/24).

En el caso real el trunk es un port-channel de dos puertos, que para el caso se comporta igual, bloqueando la VLAN en cuestión en

ambos puertos, por simplicidad aqui se realizó con un trunk común.

1.- Verificacíon inicial:

1.1.- En el switch layer 3:

1.1.1.- Verificación de layer 2:

SwitchL3#sh spanning-tree int gi1/0/1

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- ----------------

VLAN0001 Desg FWD 19 128.1 P2p

VLAN0002 Desg FWD 19 128.1 P2p

SwitchL3#

1.1.2.- Verificación de layer 3:

SwitchL3#sh ip int brief

Interface IP-Address OK? Method Status Protocol

Vlan1 192.168.1.1 YES manual up up

Vlan2 192.168.2.1 YES manual up up

Vlan666 10.0.0.1 YES manual up up

SwitchL3#

1.2.- En el router remoto:

*Nov 24 13:47:18.774: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Vlan666 from LOADING to FULL, Loading Done

Router#sh ip route

---omitido---

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 10.0.0.0/30 is directly connected, Vlan666

L 10.0.0.2/32 is directly connected, Vlan666

O 192.168.1.0/24 [110/2] via 10.0.0.1, 00:00:00, Vlan666

O 192.168.2.0/24 [110/2] via 10.0.0.1, 00:00:00, Vlan666

Router#

2.- Se genera el bucle:

Como se mencionó al principio este lab es independiente de la causa del bucle, pero para los que se pregunten:

¿cómo puede ocurrir un bucle hoy en día, si todo tiene spanning-tree ? mi respuesta es “siempre hay un bucle al acecho”

- Un ejemplo muy común puede ser tener equipos que no soporten spanning-tree (todos los no administrables).

- Un ejemplo también común y aunque tengamos “todo Cisco” en un escenario de telefonía IP y en donde alguien llega

con la notebook y conecta mal (por la causa que sea) el patch (suelto en el piso) del teléfono IP (de la marca que sea)

y que la mayoría no sólo no soportan spanning-tree, sino que lo filtran...causando el tan esperado bucle ya que el switch

al no recibir su propia BPDU en los ports involucrados, simplemente no lo detecta.

Imaginen que la conexión equivocada no es directamente contra el switch sino que pueden conectarlo a un wall plate

en la pared o en el escritorio (y que este esta conectado al switch como otro puesto mas).

Esto, crean que es así y que ocurre más de lo que imaginan, pero sigamos con lo nuestro.

Al generarse el bucle tenemos este log en el switch de capa 3 que nos indica que el trunk que trae la VLAN 2 entra

en DOWN en layer 3 (debido al bloqueo en layer 2 y que es el único port en la VLAN).

SwitchL3#

*Nov 24 15:10:15.803: %LINK-3-UPDOWN: Interface Vlan2, changed state to down

*Nov 24 15:10:16.803: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to down

SwitchL3#

2.1.- Verificación en el switch de layer 3:

2.1.1.- Verificación de layer 2:

SwitchL3#sh spanning-tree int gi1/0/1

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- ----------------

VLAN0001 Desg FWD 19 128.1 P2p

VLAN0002 Back BLK 19 128.1 P2p

SwitchL3#

SwitchL3#sh int trunk

Port Mode Encapsulation Status Native vlan

Gi1/0/1 on 802.1q trunking 2

Port Vlans allowed on trunk

Gi1/0/1 1-2

Port Vlans allowed and active in management domain

Gi1/0/1 1-2

Port Vlans in spanning tree forwarding state and not pruned

Gi1/0/1 1 (no está la VLAN 2)

SwitchL3#

2.1.2.- Verificación de layer 3:

SwitchL3#sh ip int brief

Interface IP-Address OK? Method Status Protocol

Vlan1 192.168.1.1 YES manual up up

Vlan2 192.168.2.1 YES manual down down

Vlan666 10.0.0.1 YES manual up up

2.2.- Verificación en el router remoto:

Router#sh ip route

---omitido---

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 10.0.0.0/30 is directly connected, Vlan666

L 10.0.0.2/32 is directly connected, Vlan666

O 192.168.1.0/24 [110/2] via 10.0.0.1, 00:00:38, Vlan666

Router# (ya no esta la red 192.168.2.0/24)

Obviamente si tuviesemos otro puerto en el core con la VLAN 2 esta no entraría en DOWN, pero en este escenario (el real) fué así.

Hay una opción de que la VLAN quede siempre en UP en layer 3, pero que puede dar otro tipo de falsos positivos que no discutiremos hoy.

3.- Daños colaterales:

Como efecto colateral, cae el OSPF contra el vínculo al router (el enlace P2P en la VLAN 666).

Esto es momentáneo y debido a que la CPU del switch layer 3 queda exigida por el bucle (por más que sea un equipo robusto como un

Catalyst 9300 con solo las cosas de este lab conectadas).

*Nov 24 15:10:45.996: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Vlan666 from FULL to DOWN, Neighbor Down: Dead timer expired

SwitchL3#

3.1.- Verificamos:

SwitchL3#sh proc cpu

CPU utilization for five seconds: 54%/28%; one minute: 33%; five minutes: 19%

PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

1 0 15

-omitido---

*Nov 24 15:11:36.394: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Vlan666 from LOADING to FULL, Loading Done

(down de aprox 50 segundos, pero la VLAN 2 recuerden que NO se publicará hasta levantar el bucle)

3.2.- Implementación de contramedidas para evitarlo:

De las herramientas que conocemos, el storm-control pensamos que sería la mas eficaz, pero aqui vamos con otra mala noticia...

SwitchL3(config)#int gi1/0/1

SwitchL3(config-if)#storm-control broadcast level 0.01

SwitchL3(config-if)#storm-control multicast level 0.01 (en una interface de giga esto esto es 10 Mbps de bucle)

SwitchL3(config-if)#end

SwitchL3#

3.3.- Generamos bucle.

3.4.- Verificamos:

SwitchL3#sh storm-control

Key: U - Unicast, B - Broadcast, M - Multicast, UU - Unknown Unicast

Interface Filter State Upper Lower Current Action Type

----------- --------------- ----------- ----------- ------------- --------- ----

Gi1/0/1 Forwarding 0.01% 0.01% 0.00% None B

Gi1/0/1 Blocking 0.01% 0.01% 99.97% None M

SwitchL3#

SwitchL3#sh proc cpu

CPU utilization for five seconds: 56%/30%; one minute: 60%; five minutes: 34%

PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

1 0 15 0 0.00% 0.00% 0.00% 0 Chunk Manager

---omitido---

SwitchL3#

3.5.- Levantamos (abrimos) el bucle.

SwitchL3#

*Nov 24 15:46:00.474: %STORM_CONTROL-5-ABATED: A Multicast storm abated on Gi1/0/1. Packet filter does not apply on the interface.

*Nov 24 15:46:37.300: %LINK-3-UPDOWN: Interface Vlan2, changed state to up

*Nov 24 15:46:38.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed to UP

*Nov 24 15:47:22.363: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Vlan666 from LOADING to FULL, Loading Done

3.6.- Verificamos:

SwitchL3#sh proc cpu

CPU utilization for five seconds: 0%/0%; one minute: 54%; five minutes: 33%

---omitido--- |

(volvemos a la normalidad y no tocamos mas nada)

SwitchL3#

Router#sh ip route

---omitido---

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 10.0.0.0/30 is directly connected, Vlan666

L 10.0.0.2/32 is directly connected, Vlan666

O 192.168.1.0/24 [110/2] via 10.0.0.1, 00:00:00, Vlan666

O 192.168.2.0/24 [110/2] via 10.0.0.1, 00:00:00, Vlan666

Router#

Existe la posibilidad de generar un shutdown del puerto en caso de tormenta (storm) pero esto también podría ser dañino,

ya que bajaría todo el puerto y siendo un trunk bajaría todas las VLANs en él.

Existe también otro método más complejo de proteger la CPU del switch pero ya excedemos (bastante) el alcance de este

lab que era “solo” para estudiar de que un bucle en layer 2 “baja” una ruta en layer 3.

(2021) ...and there are also happy people.

Rosario, Argentina