He contratado un rack y ¿ahora cómo me conecto?

Eres una empresa que has ido creciendo y necesitas contratar un rack en un centro de datos para poder ahí los servidores de tu empresa y dar servicio.

¿Qué posibilidades tienes para darle conectividad a ese rack? porque es obvio que vas a necesitar algún tipo de conectividad, si contratas un rack, unas Us o incluso una sala vas a querer conectarte a ella de alguna manera.

Este tema quería tratarlo en un hilo de Twitter, pero claro, según iba pensando se me disparaban las posibilidades, así que este capítulo de hoy es un hilo de Twitter que bien ha merecido su propio audio en el podcast. De hecho el hilo en cuestión se me escapó a medio escribir y me lo tuve que cargar.

Lo primero es decidir si la conectividad va a ser pública o no, porque no todos los racks están conectados al Internet público, algunos racks son simplemente cabinas de replicación, es decir, la replicación de una cabina que está en la oficina del cliente, para evitar desastres y cosas así.

En este caso es posible que sólo queramos que la cabina sea accesible únicamente desde la oficina principal donde está la otra cabina, en este caso lo normal es contratar capacidad portadora, es decir, una conexión de 1 o 10G a un operador y que sea la únión del CPD con la oficina de la empresa. Si los requisitos son mayores siempre se puede poner una fibra oscura e iluminarla con SFPs de 40G o incluso meter CWDM o ¿por qué no? DWDM.

Y si los requisitos son más sencillos a lo mejor con un túnel sobre internet puede servir, evidentemente depende muchísimo de los requisitos de cada cliente.

También puede ser el caso que queramos tener la grabación de las cámaras de seguridad de una casa, aquí a lo mejor una VPN será suficiente.

Depende en cada caso.

Ahora, si queremos que los servicios se conecten a Internet tenemos dos opciones, tener direccionamiento propio con BGP o requerir direccionamiento del hoster. Sí, obviamente existe la posibilidad de tener direccionamiento propio pero no BGP, pero eso hablamos otro día porque no es lo normal.

Si tienes direccionamiento público y AS lo ideal es levantar un par de sesiones BGP (al menos) con un par de routers y adelante.

Si quieres direccionamiento del hoster pues tendrás que ponerte un gateway, que será un firewall, un router o similar y enrutar por ahí, obviamente el hoster también tiene que enrutar por ese equipo tu direccionamiento.

Todo está está muy bien, pero seguro que no hay nada nuevo, la gracia de esto es ¿cómo pongo los cables? pues ahí es donde está la chicha de todo esto.

Hay varias posibilidades, desde la más simple, en la cual le doy al cliente un único cable cable que une la plataforma del hoster con el firewall del cliente, el hoster configura una ruta al rango asignado al cliente hacia el firewall y el cliente una ruta por defecto a través de su firewall. Esta solución no es la mejor obviamente, para un servidor vale, pero para una infraestructura no es lo óptimo.

A partir de aquí podemos complicar esto hasta el infinito dando más seguridad y más redundancia.

Por ejemplo, si el cliente tiene un único firewall pero la posibilidad de tener dos uplinks podemos darle un LACP conectado a dos switches Nexus con VPC, de forma que si cayese un switch o uno de los cables el cliente seguiría funcionando por el otro cable, sin convergencias ni nada de nada porque el LACP seguiría funcionando, pero sólo por un puerto, cuando levantara de nuevo el enlace caído el LACP se volvería a formar con dos puertos.

Esta solución es muy limpia y a mi personalmente me gusta, ¿cómo se configura?

En el lado del hoster hay que configurar un LACP y una VLAN, y será esa VLAN la que pasemos por el LACP y el gateway para el cliente estará configurado en un interfaz VLAN que puede estar en ese mismo VPC, la pareja de switches, o en otro lado donde llegue la VLAN en cuestión.

En el lado del cliente simplemente hay que configurar un LACP para el interfaz externo.

Si el cliente quiere poner un switch será igual que si pone un servidor o un firewall, pero ¿qué pasa si quiere poner dos switches?, aquí hay que ir con cuidado y tenemos que ver si el cliente nos ofrece confianza suficiente porque sus equipos van a enviar BPDUs y van a ser capaces de bloquear puertos de Spanning Tree, así que ahí con cariño.

Pero el problema importante surge en el momento en el que el hoster poner un par de Nexus en VPC y el cliente se pone otro par de Nexus, también en VPC y tiramos un par de cables, ahí la redundancia es total, pero claro, en este tipo de escenarios puedes encontrarte que ambas parejas de VPC se ponen como root de STP en las vlans que pasan por esos cables y las vlans entre las dos parejas de switches quedan bloqueadas por spanning tree, así que es interesante definir el root de spanning tree preferiblemente en el lado del hoster.

De todos modos yo no soy nada partidario de que el cliente se conecte directamente con unos switches a nivel 2, siempre que se pueda que el cliente ponga un dispositivo de capa 3, un router o un firewall, eso es lo ideal para todas las partes.

También se puede hacer el balanceo con ECMP en BGP, simplemente poniendo varios interfaces y creando una sesión BGP de loopback a loopback usando esos enlaces, y ahí nos quitamos todo el problema de los spanning tree y de los balanceos por LACP.