«

»

Ago 30 2009

Imprimir esta Entrada

CONTRA LA AUTOCONFIGURACIÓN (parte 1)

No me mal entiendan. No tengo nada en contra del uso racional de los procesos de toma de decisiones automáticos. Son muy necesarios hoy en día y ayudan enormemente en todos los campos de la vida cotidiana en cosas tan simples como sintonizar una emisora y cosas medianamente mundanas como poner a lavar la ropa.

Mi problema con los procesos automáticos radica en su mal uso. Y sobre todo su mal uso en mi profesión de ingeniero en telecomunicaciones.  La tendencia de mucho ingeniero novel de creer que porque así lo hace la máquina es mejor y ya, es un reflejo de que esa persona está perdiendo algo de cuestionamiento crítico, no diseña, sufre de pereza mental y pide a gritos que, en un futuro cercano, a él lo controle la red.

Varios de esos procesos de toma de decisiones automáticos están apoyados por estándares de la industria y por algoritmos ampliamente divulgados, lo que nubla aún más la corta visión de bastantes colegas en la industria que se agarran a estos protocolos de forma religiosa.

Uno de estos protocolos, cuyo intento de uso debería ser solo por autorización, o con algún tipo de licencia paga, para obligar a quien quiera encenderlo en una red a pensar, es el del algoritmo Spannnig Tree o STA (A de algoritmo) o STP (P de protocolo) según el autor del libro donde lo estudien.

No voy a hacer historia. Si usted llegó hasta acá sin aburrirse ya debe saber que Spanning Tree llegó hasta nosotros como un derivado del algoritmo DEC (Digital Equipment Corporation) a principios de los años 80, para evitar que se formaran lazos cerrados o loops en redes de área local LAN de nivel 2 en el modelo OSI, y derivó en el ampliamente conocido IEEE802.1d.

Un loop en una red de datos de sebe evitar porque nos va a llevar el desempeño a cero si se presenta un brodcast colapsando toda la LAN.

Para exponer el nivel de mi frustración y por qué me siento nadando contra la corriente, me remonto a la siguiente pregunta que hice en una charla magistral ante un auditorio de Networkers hace poco menos de 5 años, con el siguiente diagrama de red, muy, muy sencillo y similar, de una oficina pequeña de cliente, en el proyector de la charla:

“¿Y porque no simplemente apagamos en los puertos de esta red el protocolo Spanning Tree?”

Caramba si se me vino el mundo encima. Ya era media charla y un par de asistentes se empezaron a ir de la sala. Otro estaba llamando a un cura a ver si yo necesitaba un exorcismo. Pero afortunadamente siempre existe la gente sin vicios mentales e inquieta, y que de forma cándida responden: “Porque se nos puede formar un loop en la red y al primer broadcast se nos cae”.

Ante la inocente y “esperada” respuesta dije en voz alta: “Aja, se nos cae, ¿Y por donde se va a formar el loop que nos va a tumbar la red LAN?”.

La misma persona de la respuesta anterior dijo: “Pero claro, es obvio, si alguien llega con un cable y lo pega a dos puertos de ese switch se cae la red”. Ajá, a ver. No nos adelantemos, mi pregunta clara y directa es: ¿En la red que está expuesta en el diagrama se va a formar un loop? Creo recordar que los que estaban saliendo alcanzaron a detener el paso.

Y como nos estamos adelantando a los acontecimientos les respondo. No. No hay forma física posible de que se forme, pero se demuestra el increíble afán por usar cosas como STP que no se necesitan en todos los casos, y este es un ejemplo de esos. Claro alguien dice que con un cable conectado a dos puertos se forma el loop y nos degrada el desempeño de la red LAN a cero. La cuestión ahora es, y les pregunto. ¿Quién sería ese “alguien”? Evidentemente alguien que, o sabe que es lo que va a hacer, o que es un completo estúpido que no identifica un broadcast storm y no sabe que eso pueda pasar. Aquí no hay término medio para este personaje porque el gran común de la gente es temerosa de meterse con equipos que no conocen, más cuando se ven costosos y mucho más aún en redes y telecomunicaciones.

Para el primer personaje es totalmente injustificable esa actitud y hasta criminalizable, y no debería estar tocando SU red LAN sin supervisión. Para el segundo personaje la duda es: ¿Porque él llegó tan lejos en SU red LAN? (nótese las mayúsculas). Si usted no tiene control de SU red. Si no tiene por lo menos una puerta con llave para entrar a los gabinetes y los racks. Si cualquiera puede ir entrando, llegando con cables en los bolsillos y pegarlos en cuanto equipo de comunicaciones se le atraviese, el problema es muchísimo más grave que usar o no Spanning Tree. Y hablando de cables, le pregunté al auditorio, ¿Creo que todos saben que no es con un patch cord UTP cualquiera que se podría hacer ese loop, cierto? En un Switch Ethernet toca con un cable cruzado del tipo EIA-568A/568B que es un tipo de cableado específico, y no con un ‘uno a uno’ o con cualesquier otro tipo de cable con conectores mecánicos RJ-45. Eso complica aún más la cosa.

En este punto le pedí, a un auditorio lleno de ingenieros de networking, que me mostraran los cables “cruzados” que tuviesen y por desgracia y para mi propia vergüenza, ninguno tenía cable cruzado. Yo si tengo el mío en mi maleta. Es parte de mi herramienta y de mí día a día. Pero descubrir que un auditorio lleno de colegas no lo tienen me entristece. Y sobre todo colegas que me estaban satanizando porque  “cualquiera” podía tumbar la red con un cable que ellos, creo yo, deberían cargar en su día a día.

Instalar un switch nivel 2 hoy en día para mucha gente es simplemente “encenderlo” y dejar que las configuraciones de fábrica hagan el resto. Pero existen demasiadas situaciones en las que los Factory default no son los indicados para el tipo de negocio que ejecuta un cliente en particular. Es la misma diferencia existente entre “atornillar y encender” versus “configurar y personalizar” la red.

Uno de los ejemplos que más me toca es el de los grandes almacenes de cadena. La gran mayoría de sistemas operativos que se ejecutan en máquinas tipo POS o terminales de punto de venta (cajeros para algunos) son sistemas operativos embebidos y hechos a la medida. Mi compañía tiene un contrato global con Microsoft y en varios modelos de sus POS instala una versión especial de “Windows CE embeded” con bastantes diferencias con respecto a las versiones Windows de escritorio o servidor. Este OS tiene la enorme ventaja de que conoce de antemano las características del hardware luego todo, incluyendo inicialización y drivers, se puede hacer cargar más rápido, y dejar el sistema operable en pocos segundos. Lo malo aquí es que, para que Spanning Tree como algoritmo decida que lo que se conectó y encendió en uno de sus puertos Ethernet es un host normal (DTE) y no otro switch (DCE), el proceso completo tarda entre 40 y 50 segundos según la marca del Switch y en ese tiempo ya el POS subió el OS con drivers, no encontró la red funcionando y quedó fuera de servicio.

Lo mismo sucede con algunas marcas de impresoras en red del tipo “carro ancho” para contabilidad que, por cuestiones de ahorro de energía, apagan todo lo “no necesario” y eso incluye el puerto Ethernet, y cuando se les envía algo a la cola de impresión del aparato, el servicio se sale de tiempo y no funciona porque sencillamente el puerto del switch no se ha inicializado. Igual con algunos sistemas de control de acceso, sistemas pasivos de alarmas y varias marcas de cámaras de red con sensores de movimiento. No hablemos de redes para automatización industrial.

Lo peor continua cuando, como parte del proceso de resolución de problemas, el respectivo ingeniero de Networking llega con su portátil, lo pega al mismo cable de red donde debería estar la alarma (o el POS o la impresora o lo que sea) y delante del dueño y del proveedor del equipo hace un PING y Oh, funciona, luego no es su switch el del problema, es el equipo X del otro proveedor el que no funciona.

Esta afirmación proviene del desconocimiento de que en el planeta tierra existen más sistemas operativos aparte de Windows, MAC y Linux, del desconocimiento de como suben los drivers en el OS Windows (cualquiera de sus sabores) [http://technet.microsoft.com/en-us/library/cc768185.aspx – Network Adapters and Protocols] del portátil o PC versus un sistema embebido y echo a la medida, y de creer que basta con ponerle dirección IP y habilitarle el TELNET al switch para darlo por bien configurado para lo que necesita el negocio del cliente. Y si el proveedor del equipo X sugiere que quiten Spanning Tree solo imaginen el resto. Claro, he visto exactamente el mismo caso desde otra óptica, en donde las nuevas máquinas funcionan bien con el viejito, olvidado, malquerido y abandonado HUB, y no con el flamante, carísimo y nuevo super switch. Aquí la conclusión es la misma. Los HUB pertenecen al Nivel 1 del modelo OSI, se deben comparar solamente con los repetidores físicos y por tanto no manejan ni entienden Spanning Tree. Solo los switches y los bridges, alambrados o inalámbricos, que manejan tramas de Nivel 2 en el modelo OSI entiende, gestionan y generan este protocolo. Pasa a ser una prueba adicional de lo acá expuesto.

En este tipo de problemas, lo aconsejable y que usualmente funciona es apagar el Spanning Tree en el puerto donde se conecta el host “especial”. Se le dice al Switch que, en ese puerto específico, siempre va a haber un DTE conectado.  Esta sola perspectiva asusta a muchos, porque obliga al orden en la documentación de red.

No todo lo que yo opinó en esta nota es negativo para STP. Lo que quiero dejar claro es que no se amerita su uso en todas, absolutamente todas las situaciones. En algunas se debe usar pero en otras donde incluso pareciese necesario, termina perjudicando el comportamiento de la red por más que si existan loops físicos reales como es el caso de los múltiples backbones en fibra inter gabinetes, para conectar switches grandes. En este tipo de casos muchos repiten al unísono y sin tan siquiera pestañear. Necesitamos IEEE802.1d porque bla, bla, bla… No. Insisto, No! 30 años después existen mejores alternativas. PVSTP, PVSTP+ y RapidSpannig Tree por nombrar solo tres. Incluso es mejor pensar en Etherchannel, LACP (Link Agregation Control Protocol) IEEE802.3ad, “agregación de puertos” o PAgP, antes que en STP.

Yo prefiero hacer el cálculo y configuración de los valores de STP por cada enlace y para los casos específicos en redes grandes teniendo en cuenta el tipo de negocio del cliente. Sobre todo porque yo soy consciente de como formo el “árbol” y los caminos dependiendo de los flujos de datos, tengo más control sobre la red y la resolución de problemas es mucho más fácil. Pero No. La típica respuesta del no diseñador de redes es que, “así no se necesite póngalo automático” y eso cuando considera responder y ese es parte de mi problema contra STP. Está tan arraigado en el sub consiente colectivo de todo ingeniero novel que por defecto ni siquiera considera el evaluar su “no” uso. Nunca. Jamás se cuestiona su efectividad. Para que inventar.

En una red de área local definida topológicamente como sistema de “lazo abierto” sin loops, con canales de conexión no redundantes, debería ser muy fácil advertir la necesidad de no ejecutar STP. Esto presenta tres ventajas evidentes e inmediatas en el desempeño general de la LAN:

  • No propagación de paquetes BPDU. Un canal más libre para datos. Algo es algo por pequeño y espaciado en segundos que sea este paquete. Pero tenga presente que se genera uno por puerto de switch con dirección destino Ethernet tipo broadcast luego debe al menos ser revisado cada vez por el host.
  • No recalculo de la estructura de caminos de STP. Esto se hace cada tres ausencias o cambios del BDPU luego va a mejorar el desempeño general delos ASIC (¹) y el del switch, enfocándolo exclusivamente a darle tránsito más rápido a los datos.
  • Disponibilidad inmediata del puerto físico para los host.

Claro está que si usted no puede dormir tranquilo y desconfía de la seguridad policiva e intrusiva en SU propia red. Siempre puede configurar los parámetros de STP en forma manual, con la enorme ventaja de que es usted quien define los pesos de cada puerto y cada switch dentro de la estructura y puede definir exactamente cual camino debe tomar el paquete de datos para ir de la estación del usuario hasta el servidor necesario para su trabajo, obteniendo de paso un control mucho mejor de su red.

¿Sigue temeroso de los broadcast storm? Colóquele a las estaciones de trabajo un filtro límite de broadcast de unos 600 por segundo. La experiencia me ha mostrado que no se necesitan más y ese valor es más que suficiente. La idea es simple, el broadcast 601 por segundo (y de ahí para arriba) no pasa. Tiene la ventaja de que el puerto no se bloquea por STP, luego si es una real “tormenta” el PC que se conecte en este puerto puede trabajar. Este parámetro no aplica a los servidores de su red LAN porque el servidor si necesita valores de filtrado de broadcast más altos. Basta decir que el valor va de la mano con la función que presta el servidor; El servidor de login corporativo debe atender a todo el mundo, mientras que los de desarrollo o contabilidad no. También los servidores tienen puertos generalmente más rápidos que el del resto de los usuarios normales de 1 o 10 gigas bps. Depende de si su red tiene o no un servidor de WINS que le entregue direcciones MAC locales a quien las solicite. Sea cual fuese el caso, estoy seguro de que usted sabe exactamente en qué puerto está conectado cada uno de sus servidores y no va a dejar que alguien llegue a SU red con un cable en el bolsillo a desconectarle ese servidor y poner allí ese cable.

Los esquemas actuales de virtualización de servidores implican afortunadamente la no configuración de STP. Usted ya sabe que hace el servidor, como opera, donde y como está conectado, luego; ¿Para qué STP en esos puertos?

Alguien me puede replicar que STP solo es importante mientras se organiza la estructura de caminos de la red. Después de estabilizada ya no importa. Falso, Mencionaba atrás en estas líneas que permanentemente se están generando paquetes de BPDU (bridge protocol data unit) por cada puerto con dirección destino broadcast. Tal vez los PC’s y host hoy en día tenga suficiente poder de cálculo para dedicarle y gastarle un par de ciclos de reloj a atender este broadcast y la degradación general de la compañía sea imperceptible, pero canales que en horario laboral viven muy utilizados si lo recienten. Por la utilización del canal y porque desperdicia ciclos de proceso de la maquina en el otro extremo. Para el caso está el canal de salida a internet. Generalmente es uno solo. Y esta en uso permanente ya sea por usuarios de aplicativos remotos, por servicios de transferencia de archivos, VoIP, teleconferencias, correo, Facebook, youtube o lo que le venga a la mente. Y si a lo anterior le tiene que sumar un broadcast cada 5 segundos de un paquete BDPU para que al final simplemente sea rechazado significa que está en mora de hacerse un favor y optimizar el desempeño general de al menos ese solo enlace.

Mi bronca no es contra un proceso automático de toma de decisiones que dice cual puerto habilitar y cual bloquear, o cual camino de datos es válido entre los usuarios y los servidores, como lo hace el protocolo Spanning Tree. Existen momentos donde se justifica y es necesario. Mi bronca es contra su mal uso en muchas situaciones en las cuales la red se comporta mejor y se tiene más control sin STP.

(¹) Aplication Specific Integrated Circuit
Be Sociable, Share!

Sobre el Autor

Leonel G. Pedroza R.

Enlace permanente a este artículo: http://www.leonelpedroza.com/2009/08/30/contra-la-autoconfiguracion-parte-1/

Deja un comentario