Diseñando una red con Spanning Tree (I)

      Comentarios desactivados en Diseñando una red con Spanning Tree (I)

Recientemente he atendido una incidencia de cierto calibre en una red bastante sencilla, pero que da soporte a servicios de datos y de VoIP. Ahora bien, es muy importante entender el modelo OSI para llegar a comprender y determinar que el problema se encontraba justamente en la capa 2 y concretamente, haciendo debug, que estaba en spanning tree. ¿Por qué el modelo OSI? porque la experiencia del usuario se vive por encima de la capa 7 (yo lo llamo servicio/usuario), y antes de todas ellas, existen protocolos que funcionan de una manera y de otra y que por ende se ven afectados en toda la pila… cuando uno de abajo falla. En base, por ejemplo, nos encontramos con TCP y UDP que cada uno trabaja de forma distinta:

  • TCP es orientado a conexión, y rentransmite cuando se pierden ciertos paquetes (hasta cierto límite)
  • UDP es no orientado a conexión, y no rentransmite un carajo, por lo que si los paquetes no llegan a destino… se pierden

He aquí la incidencia: Tras la implementación de la redundancia en la red, se pierden en ocasiones paquetes de VoIP con la consecuencia de que las llamadas se entrecortan… pero en cambio, no ocurre así con las conexiones de datos (correo, navegación, etc…). Haciendo un poco de auditoría y captura de paquetes vemos que existen retransmisiones de TCP a cascoporro cuando las llamadas de teléfono se ven entrecortadas… por lo que se cumple lo dicho en el párrafo anterior: la experiencia de usuario nos dice que los teléfonos van mal,  pero la causa no está en los teléfonos o la centralita, y lo que va mal realmente no son las llamadas; estas se ven afectadas por una incidencia en la capa que da soporte a las capas 3 y 4 de OSI.

Spanning Tree es un protocolo diseñado para controlar el estropicio que se puede producir en una red ethernet cuando se tienen caminos redundantes. Creo que esta frase es la más corta, clara y concisa posible para definir su función (que no su funcionamiento). He oído muchas veces “el maldito spanning tree la que me ha liado” y ante eso lo que puedo decir es que NO, Spanning Tree viene a resolver un problema, no a darlo. Si tienes problemas con Spanning Tree es por un mal diseño, o una mala configuración del mismo. Si queréis leer más, podéis buscar en la wiki, pero me comprometo a dedicar un post a explicar la base de esto.

Bueno, antes de hablar acerca de las consideraciones del diseño y de la configuración, decir que existen otras alternativas a Spanning Tree para otorgar redundancia en la red y que recomiendo y aconsejo evaluar para que, en caso de posibilidad, se huya de una topología en árbol. Estas son vPC (virtual port-channel) y LACP tradicional. Y en cualquier caso, la elección de uno de los modos de STP es fundamental, hasta el punto de que es muy conveniente conocer los diferentes fabricantes, especialmente aquellos que usan PV-STP en vez del protocolo tradicional.

Diseñando y dimensionando la red implementando Spanning Tree

Lo primero a tener en cuenta, es la red que tenemos en cuanto a su topología física y su topología lógica. Cada red es diferente, pero de esto tenemos que tener en cuenta lo siguiente:

  1. En cuanto a su topología física: Cuantos caminos redundantes existen en toda la red. Hay que determinar cuantos “bucles” de red podemos encontrarnos, puesto que de un bucle por un anillo, podemos pasar a N bucles en una topología de estrella.
  2. En cuanto a su topología lógica: Si existen VLANs, cuales, cuantas, y por donde están sus caminos redundantes. No sería la primera vez que un diseño de VLAN erroneo deja aislada parte de una vlan… por no tenerla en todos los troncales, o no usar el protocolo adecuado para Spanning Tree.

Una vez tenemos claro el diseño hasta este punto, podremos elegir qué modo de implementación de STP nos interesa más: Spanning Tree, Rapid, Multiple o en el caso de cisco, PVST, PVST+, de los cuales voy a explicar unas pequeñas diferencias:

  • STP, estándar tradicional 802.1d. Controla un máximo de 256 puertos en la topología y tiene unos retardos considerables para redes de alta criticidad
  • Rapid STP, estándar posterior. 802.1w. Controla hasta 4096 puertos en la topología y el retardo es mínimo. Soporta STP en la red.
  • Multiple STP, estándar 802.1s. Está basado en 802.1w y es capaz de realizar instancias multiples para separar VLANs y por ende separar caminos redundantes… aprovechando mejor el ancho de banda.
  • PVST y PVST+ (y sus respectivos rapid) son, en cambio, protocolos de Cisco… Cisco se dio cuenta de que en redes grandes se optimiza más el ancho de banda y se reduce el tráfico broadcast y el flooding por vlan cuando no es necesario extender las VLAN por toda la red. A veces, una VLAN tiene caminos redundantes pero está en un pequeño trozo de la red. Estos protocolos responden a esta situación y crean instancias por vlan, siendo cada una de ellas configurable por separado en todos sus parámetros. Es muy importante tener en cuenta esto cuando trabajas con Cisco y otro fabricante, puesto que la integración de STP en esta situación requiere de forzar a que toda la electrónica hable el mismo tipo de estándar… (por lógica…). Es recomendable y conveniente -y no lo digo yo, lo dice la documentación oficial de los fabricantes que se han encontrado con este problema y han querido aportar algo de luz- usar Multiple STP en este caso

Vale, ya hemos elegido nuestro estándar. En mi caso, me voy a quedar con Rapid, puesto que vamos a hablar del funcionamiento y no me parece apropiado hacerlo con el protocolo de Cisco. Así que montamos, y a configurar todos los parámetros necesarios para estabilizar el diseño que hemos hecho con nuestro flamante “Rapid STP”. Y digo, configurar… porque, realmente STP se configura solo y sin dar problemas de estabilidad. El proceso de elección del root se determina por prioridades y costos, y en caso de empates, la mac más baja del equipo y este proceso es automático una vez Spanning Tree está activo. Pero cuando STP se configura solo, no ejercemos control alguno sobre la topología. La pregunta aquí es si debemos o no hacerlo, si nos interesa o no perder tiempo en que nuestra red, o la de nuestro cliente, sea estable, y esté perfectamente dibujada según la habiamos diseñado fisica y lógicamente. Porque siempre es mejor que la red elija por nosotros que el root de STP sea un switch de acceso y no uno de core… verdad colegas networkers… (nótese la ironía).

En el próximo post, continuamos con la verdadera chicha, que ahora viene lo chungo… x)