Diseño de LAN escalable

Siempre he tenido un gran interés por el diseño de redes y, afortunadamente, he podido dedicarme laboralmente a ello. Debido a la experiencia adquirida, a mi ilusión por la temática y con el objetivo de reflejar mis ideas en un blog en lugar de como notas mentales y/o bocetos en papeles desperdigados por libretas que al final acabo perdiendo, me he decidido a escribir esta entrada.

Principios de diseño

No pretendo ser exhaustivo ni académico, sino más bien pretendo exponer los principios que, a mi entender y por mi experiencia, creo que son los pilares clave a la hora de diseñar una red local de cierta envergadura (digamos cientos o miles de usuarios) manteniendo como objetivos la estabilidad, la escalabilidad, la eficiencia y basada en estándares. A continuación, paso a enumerarlos para exponerlos seguidamente:

• Uso de estándares y multifabricante
• Minimizar el STP.
• No superar el factor de sobresubscripción
• Usar stacking al menos en distribución.
• Limitar los dominios de fallo.
• No usar direccionamiento secundario.
• Automatización.

Uso de estándares y multifabricante

Soy de los que piensan que hay que alejarse de protocolos propietarios debido a que «te obligan» a quedarte con el fabricante. No quiero decir con ello que no nos faciliten la gestión o el mantenimiento de las redes, pero no hay que olvidarse que una red de cierta envergadura requiere de muchos dispositivos para dar conectividad y ello conlleva un gran desenbolso económico para adiquirirlos. Circunscribirse a un solo fabricante nos obliga, por un lado a aceptar el coste de su equipamiento y por otro, puede generarnos problemas de compatibilidad y/o estabilidad cuando empleamos sus protocolos. Ello sin olvirdarse que en caso de desaparecer este, podríamos quedarnos con unos dispositivos sin soporte y obsoletos. Por ello recomiendaría el uso de protocolos estándares como RSTP en lugar de Rapid-PVSTP+, VRRP en lugar de HSRP o LLDP en lugar de CDP por nombrar unos pocos.

Minimizar el STP

En mi humilde opinión, el Spannig Tree Protocol es un verdadero dolor de cabeza para todo administrador de red. Es cierto que no se puede vivir sin él (en principio) pero es el servicio de red que más impacta cuando no funcioan correctamente, y eso ocurre generalmente por:

• Fallo en la configuración en switches debido a no tener las medidas de protección adecuadas (por ejemplo loopguard o rootguard) o a un error en al configuración de este (prioridad más baja que la del propio bridge root).
• Problemas de interoperatividad como cuando se ejecuta en una misma red RSTP y PVSTP.
• Inestabilidad cuando algún switch no tiene suficientes recursos de CPU o memoria como para procesar las BPDU.

En mi experiencia, la forma más efectiva de minimizar los efectos de fayos por STP en caso de no poder eliminarlo sería:

1. Emplear el mismo STP en toda la LAN siendo mi recomendación RSTP dejando de lado los protocolos propietarios como PVSTP. De ese modo se tienen más fabricantes donde poder elegir sus dispositivos.
2. Minimizar la probabilidad de bucles permitiendo físicamente dos caminos másximos al nivel de distribución (1 bucle).
3. Emplear mecanismos de protección tales como (en términos de CISCO) portfast, root guard, loop guard y BPDU guard.

No superar el factor de sobresubscripción

Reconozco que esto lo he aprendido leyendo libros de diseño de redes ya que en la práctica nunca me he encontrado con situaciones de sobrecarga debido a un mal dimensionamiento de los enlaces. Este ratio viene dado por la experiencia de muchas redes LAN en produccción y nos indica que siguiendo esta pauta la congestión de los enlaces entre switches de distintos niveles ocurre de forma infrecuente. En caso de haber congestión, la QoS solventaría la situación momentánea. Por supuesto si la congestión ocurriese de forma frecuente, habría que ser más conservador de lo que hace este ratio.

Siguiendo esta recomendación, El factor de sobresubscripción aplicado a las redes locales, usando mis palabras, vendría a indicar la carga máxima que debe de recibir un enlace que conecta con el siguiente nivel en una estructura de conexionado jerárquica (lo llamaremos desde ahora uplink). Hablando de redes LAN, estos uplink serían los enlaces que conectan con los switches de acceso con los de distribución (cuyo ratio está fijado a 20:1) o los enlaces entre distribución y core (ratio 4:1).

Ciñéndonos a la sobresubscripción entre acceso y distribución, este no ha de superar la proporción 20:1. Es decir, el interfaz de uplink no debería sobrepasar 20 veces la capacidad de transferencia máxima de este. Por poner un ejemplo práctico: si contamos con switches con 1Gbps de uplink e interfaces de acceso a 10Mbps, este uplink debería, como máximo, soportar 20Gbps, que, pasando el valor a número de puertos Fast Ethernet, se traducce en 200 puertos. Si pensamos en switches de 48 puertos, esto se traduce que, de un uplink de 1Gbps puden colgar 4 switches de 48 puertos cada uno. Si este mismo ejemplo lo hacemos con el puerto de uplink y de acceso a 1Gbps, podríamos tener hasta 20 puertos conectados a distribución por el mismo uplink.

Basando el diseño solo en la limitación de la subscripción, estaríamos obviando la limitación impuesta por el STP en cuanto al límite máximo de 7 para el valor del diámetro.

The diameter is the number of switches connected in series from the root bridge out to the end of any branch in the tree.

Usar stacking al menos en distribución

Para mí stacking significa que dos switches en stack son vistos por los demás switches como un solo switch a todos los efectos. Este concepto es simple pero potente y permite soluciónes loop free sin requerir añadir complejidad a nivel de red a la vez que duplica el número de enlaces activos (con STP por defecto el 50% de los enlaces están inactivos para evitar bucles). Cierto es que no existe ningún protocolo estándar de stacking (o más formalmente Multi-chassis Link Aggregation MLAG) y cada fabricante implementa los suyos propios. No obstante el adquirir dos dispositivos del mismo fabricante para soportar su tecnología de stack no me parece atarse al fabricante pues siempre podrán ser reemplazados por otros equipos de otro fabricante sin afectar al resto de los switches de red.

Limitar los dominios de fallo

Inicialmente pensaba que una red a nivel 2, aun siendo conmutada, debía de tener un límite debido a la cantidad de broadcast que cada nodo añade a la red. A eso es lo que se llama dominio de broadcast, si este broadcast es elevado, este afecta a los nodos del domnio ya que han de dedicar recursos de CPU para procesar las tramas. Hoy en día dado que los protocolos que se basan en broadcast se han reducido o se han migrado a una arquitectura TCP/IP junto a la mayor potencia de procesamiento por parte de los nodos de una red, el límite por broadcast ya no es tan relevante como el de limitar el dominio de fallo de forma que se acota el dominio de nivel dos con el objetivo de limitar el impacto debido al fallo hardware o software de un uno o varios nodos de red en el dominio. Con este fin limitar un dominio de fallo, broadcast o VLAN a 1000 nodos (máscara de 22 bits) es un valor más que válido. Este concepto lo describe perfectamemnte Greg Ferro en una entrada de su blog.

No usar direccionamiento secundario

Teniendo en cuenta que es mi punto de vista, el uso de interaces secundarias es simplemente poner un parche ante un problema y no una solución a largo plazo. De hecho, en el pasado, he visto ciertos problemas al uso de este direccionamiento:

• Problemas con el direccioamiento cuando se emplea DHCP relay.
• Multiplica el trafico de broadcast.

Estos problemas se pueden solucionar escogiendo un esquema de direccionamiento mayor y empleando la asignación de direcciones dinámicamente.

Automatización

Este punto creo que es uno de los más importantes por el hecho de la complegidad de gestión para entornos con decenas o cientos de dispositivos de red. La posibilidad de aplicar configuración por lotes es una herramienta imprescindible para:

1. Mantener la coherencia de configuración entre todos los dispositivos.
2. Agilizar procesos de gestión (adición, cambio, decomisión) del equipmiento de red.
3. Reducir los tiempos de actuación en el equipamiento.

Caso práctico

A continuación he propuesto brevemente un diseño que cunple los principios anteriormente expuestos. Empecemos diciendo que se puede emplear cualquier switch de culquier fabricante que cumpla nuestros requerimientos, en caso de los switches de distribución, requerirían que fuenran del mismo fabricante para poder configurarles el MLAG. Mediante el stacking dispondríamos de todos los enlaces activos hasta distribución cumpliendo con solo disponer de un camino de redundancia. Se emplearía RSTP para evitar bucles a N2. Cada par de enlaces a distribución podría conectar grupos de hasta 6 switches de 24 puertos cada uno con el objetivo de mantener el diámetro de la red no mayor a 7 y en caso de usar switches de 48 puertos, la agrupación no debería superar los 4 switches para mantener el principio de sobresubscripción. EN cuanto las VLAN, todos los switches tendrían las mismas configuradas para facilidad de gestión y cada una de estas VAN contaría con un direccionamiento /22 como máximo que se configuraría en los switches de distribución.