(Para acabar la semana en que hemos superado los 1000 suscriptores al feed, hoy tenemos una colaboración de Rafael García, amigo, antiguo colaborador de S2 Grupo y con extensos conocimientos y experiencia en la gestión de centros de proceso de datos, como muestra en su blog. Esperamos que les guste la entrada tanto como a nosotros; por lo demás, pasen un buen fin de semana, nosotros nos vamos hasta el lunes, aunque esporádicamente puede que aparezcamos por “el” Twitter)
Hace casi un año, el pasado 28 de Febrero de 2009 YouTube dejó de funcionar durante 2 horas. La incidencia —una incidencia de su conectividad— no se debió ni a la falta de redundancia de sus infraestructuras, ni a un fallo coordinado de todos sus proveedores, ni a un apagón simultáneo de todos sus centros de datos; ni siquiera al súbito interés simultáneo y mundial por el último vídeo de la Obama girl. YouTube dejó de funcionar debido al secuestro de parte de su direccionamiento IP por parte del operador Pakistan Telecom. ¿Secuestro? Sí, secuestro o suplantación del direccionamiento IP, algo tan antiguo como el propio protocolo BGP.
BGP4 (RFC 1771 y RFC 1772) es el protocolo que se utiliza para intercambiar tráfico entre los proveedores de servicios de Internet. Sus funciones son bastante simples: básicamente permite que los sistemas autónomos (AS) —las subdivisones organizativas que gestionan los prefijos de enrutamiento en Internet, habitualmente un ISP— comuniquen a otros sistemas autónomos cómo alcanzar redes en Internet. Específicamente BGPv4 intercambia prefijos de direcciones de Internet seguidas de los identificadores de los sistemas autónomos a través de los cuales se alcanza dicho direccionamiento. Todos los ASs intercambian esta información entre ellos asumiendo que es correcta. BGP, aunque permite implementar políticas sobre los prefijos que anuncia o deja de anunciar, no tiene ningún mecanismo para saber si la información de sus tablas de enrutamiento es válida y si realmente se la está suministrando quien debe suministrársela. Este funcionamiento se denomina confianza transitiva, vamos, que si me creo lo que me dices me estoy creyendo lo que a tí te dicen todos tus vecinos y los míos te creerán. Transitive faith podrían haberle puesto.
El AS17557 (Pakistán Telecom), siguiendo una orden del gobierno pakistaní de bloquear el acceso a YouTube, empezó a anunciar uno de los prefijos del direccionamiento de YouTube seccionando —utilizando una red más específica— el prefijo habitual utilizado por la empresa de vídeos online. Cuando la ruta se propagó a través de la red de ASs, el tráfico mundial destinado a dicha subred utilizó el camino de los ASs anunciados para la dirección más específica, siendo enviado al AS17557 en lugar de al AS de Youtube. Resulta que en la subred anunciada desde asia se ubicaban todos los servidores DNS y servidores web de YouTube.
Viendo este escenario, es fácil entender que los incidentes se hayan repetido en diversas ocasiones, incluyendo entre ellos la caída prácticamente completa de Internet el 24 de Diciembre de 2004 debido a un error del operador turco TTNET. También podéis consultar multitud de incidentes en www.renesys.com y www.datacenterknowledge.com.
Aunque hay muchas propuestas de mejora a la simplicidad de BGP, BGPv4 es casi imposible de sustituir y permanecerá en Internet todavía muchos años.
Entonces, ¿qué medidas de mejora de la disponibilidad pueden adoptarse?
Como clientes de proveedores de acceso a Internet o propietarios de ASs las soluciones pasan por utilizar bloques de direccionamiento no contiguo en nuestros servicios y en nuestros diseños de red.
Esto consiste en disponer de diversidad de proveedores de acceso a Internet con distinto direccionamiento que no pueda englobarse en un mismo prefijo de direccionamiento IP, o en caso de conectarnos a un único AS, como habitualmente hacemos, solicitar al proveedor bloques de direccionamiento no contiguo en 2 accesos físicos distintos. En este caso, nos protegemos ante la caída de un prefijo enrutando por nuestro direccionamiento secundario. Nuestros servicios críticos o sus sistemas de respaldo deben poder utilizar más de un bloque de direccionamiento público.
Evidentemente, estas medidas no nos evitan tener que pensar en la redundancia de servicios que requieren nuestras instalaciones o en exigir a nuestros proveedores los requerimientos de seguridad asociados a las instalaciones de servicios de telecomunicaciones. Un breve resumen de éstos para centros de datos de alta disponibilidad (Tier III y IV) según la norma TIA-942 son:
- Accesos físicos diversos a las instalaciones. TIA-942 especifica acometidas de acceso de servicios de telecomunicaciones por lados opuestos del edificio separadas más de 20 metros entre sí.
- Ubicaciones físicas distintas de las instalaciones de servicio de los proveedores. Los centros de mayor disponibilidad deben de contar con al menos 2 Entrance Rooms separadas más de 20 metros y con caminos de cableado redundantes entre ellos y el área principal de cableado.
- Caminos redundantes de cableado desde el área de distribución principal hasta los sistemas o áreas de distribución.
- Equipamiento de red con hardware redundante en configuración de alta disponibilidad.
Y… a esperar a que nos secuestren las IPs.
Bravo!!! Espectacular como siempre ;)