Sin embargo para bien o para mal es imprescindible para el funcionamiento de todas las redes y los problemas que podemos tener a nivel 2, lejos de ser triviales y aburridos, pueden darnos horas y horas de entretenida depuración.
Hoy voy a contaros un incidente que tuve recientemente y que enseña que no podemos ignorar o despreciar ningún (y ningún es ningún) detalle de configuración a nivel dos.
El escenario
De forma resumida el escenario que teniamos era el siguiente:
Con la sede central a la izquierda y una delegación a la derecha
El tráfico llegaba a Catalyst 4500 de la izquierda, dos VLAN funcionando en modo SVI, es decir un “switch” con un “router” asociado, era transmitido por un radio enlace que se comportaba como un bridge y transmitido a una tarjeta switch de cuatro puertos de un Cisco 2911.
Dicho tráfico constaba de dos VLAN:
- Una de datos de usuario.
- La segunda de configuración del radioenlace remoto.
Esta segunda es el meollo del problema, porque es posible configurar el ancho de banda de transmisión y de recepción del radioenlace mediante comandos SNMP que enviamos a la antena correspondiente.
A la que envía no hay problema, se le envía el comando desde la sede central a la antena y se reconfigura.
Sin embargo reconfigurar la transmisión en sentido contrario tiene un poco más de “truco”:
En primer lugar hay que entender que lo primero que hace la reconfiguración del ancho de banda, es desconfigurar el camino de vuelta para configurar el nuevo. Por tanto durante la reconfiguración (que son varios comandos SNMP), no hay trafico de vuelta.
La antena tiene un puerto específico de gestión y no “escucha” lo que recibe por radio. Lo que se hace es que el 2911 recibe la VLAN de gestión y por una conexión directa al puerto de gestión del radioenlace, le envía los datos.
Por tanto, y aunque no haya camino de retorno, la reconfiguración es como sigue:
- Desde el sistema de gestión (no dibujado) los paquetes SNMP llegan al router del Catalyst 4500
- Este los envía por la VLAN correspondiente al radio enlace
- Llegan al switch del CPE que los pasa al router del CPE
- El router del CPE envía (no dibujado) el paquete SNMP al puerto de gestión del radio enlace
Algún avispado lector se habrá dado cuenta de un pequeño detalle, Antes de que se pueda enviar un paquete al CPE remoto, se tiene que ejecutar una petición ARP para que el Catalyst 4500 aprenda la MAC address del CPE y poder enviarle paquetes, y si no hay camino bidireccional, el CPE remoto no podrá contestar a dicha petición ARP con su MAC address.
para evitar este problema se ha configurado estáticamente la MAC del CPE en el Catalyst 4500 con la instrucción:
arp 10.10.20.1 0002.3333.ffff ARPA
Siendo 10.10.20.1 la IP del CPE y 0002.3333.ffff la MAC address asociada. Con esto se evita que se tenga que ejecutar la resolución ARP y los paquetes SNMP pueden enviarse incluso con comunicación unidireccional.
Hasta aquí, muy bien.
El problema
Se descubrió que a menudo durante la reconfiguración, el radioenlace remoto se quedaba desactivado como si no hubiera recibido todos los comandos, a pesar de que se enviaban desde el sistema de gestión.
Para complicar más las cosas había varias sedes remotas y el problema solo sucedía con algunas de ellas continuamente, a pesar de que todas tenían la misma configuración y equipamiento (incluso la misma versión de IOS).
Diagnostico
Como hemos dicho el Catalyst 4500 funciona en modo SVI, lo mismo que la interfaz del 2911 conectada al radioenlace. Esto hace que lógicamente en nuestro esquema tengamos dos switches y un bridge:
Normalmente en un entorno de switching de este tipo la situación del nodo raíz del STP (Spanning Tree Protocol) no sería importante. El STP se configura eligiendo como root cualquiera de los switches y todo funciona.
Si en ese entorno se produce un corte en el camino (radioenlace), se crean dos VLAN separadas que operan independientemente y la comunicación entre los dos segmentos no es posible:
En este caso cada segmento tiene su propio root. En un lado el Catalyst 4500 y en el otro el switch del CPE.
Cuando vuelve a recuperarse el enlace, se empiezan a enviar BPDUs bidirecionalmente y se produce un nuevo proceso de selección de root.
Esta elección retrasa unos segundos (o decimas) el establecimiento del path y la posibilidad de envío de paquetes.
Sin embargo en nuestro caso la situación es mas compleja.
Cuando sólo se quiere configurar el camino de vuelta, se envían los paquetes a la sede remota para que el radioenlace cambio su ancho de banda, y como hemos dicho, lo primero que hace es deshabilitar el camino de vuelta.
Las BPDU dejan de fluir desde el CPE al 4500 y el 4500 considera el STP interrumpido. Si el bridge root es el Catalyst 4500 (por prioridad o MAC address mas bajas), no hay problema, sigue enviando los paquetes que reciba (SNMP) y el CPE los recibe y enruta al radioenlace.
Esto es lo que permite configurar el extremo remoto del radio enlace incluso con un camino unidireccional.
Sin embargo, si el bridge root es el CPE, al dejar de recibir los BPDU el 4500, bloquea el puerto, espera que expiren los timers correspondientes y se produce una nueva elección de root. Durante ese tiempo el camino está bloqueado y hasta que el 4500 no decide que él es el nuevo bridge root, no permite el envío de paquetes, provocando la pérdida de paquetes SNMP de configuración.
Sin embargo cuando el camino de retorno se levanta, el Catalyst 4500 y el switch del CPE remoto empiezan a intercambiar BPDU y se procede a elegir un nuevo root del STP.
Por tanto si la prioridad se deja por defecto (¿porque no? podemos preguntarnos, a priori no había razón para que uno u otro fuera el raíz, o el enlace funciona o no funciona), interviene la MAC address y si la MAC address del 2911 es inferior a la del 4500, al cortarse el circuito este último considera que tiene que dejar de ser root y mientras recalcula el STP deja de enviar tráfico por esa VLAN.
Si, como pasaba en nuestro caso, son necesarios mas paquetes SNMP para completar la configuración, estos pueden intentar enviarse durante esta conmutación, no llegar y el radioenlace dejar de funcionar.
Solución
Por tanto para que funcione siempre el radioenlace, además de configurar estáticamente la MAC address del CPE remoto en el Catalyst 4500, hay que configurar a éste como root en dicha VLAN con la instrucción:
spanning-tree vlan 100 root primary
Esto evitará que el CPE se convierta el root y se produzca un bloqueo temporal de la comunicación.Añadidos
Para aquellos interesados en saber como descubrí el problema, la primera pista me la dio la aparición en los logs del Catalyst 4500 de los siguientes mensajes:
May 18 14:30:17 UTC: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 100
May 18 14:30:17 UTC: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 100: New Root Port is GigabitEthernet4/3. New Root Mac Address is
Luego tuve una divertida sesión de debug en STP, pero sólo hizo confirmar mis sospechas.
muy bueno y muy currado
ResponderEliminar