Pasamos a utilizar el nuevo enlace de fibra óptica

Durante el curso 2012/2013 se están llevando a cabo varias mejoras en la infraestructura de red del centro, como son:

• Se están migrando y actualizado los servicios web que ofrecemos (página del centro, moodle, blog, microblogging y wiki) a un nuevo servidor con mayor capacidad y tolerancia a fallos. En el momento de escribir esto la mayoría de aplicaciones ya están migradas, únicamente falta el wiki y el microblogging. Además, en esta máquina estrenamos un servicio nuevo: nuestra propia nube!
• Se ha actualizado por completo la electrónica de red de Fast Ethernet a Gigabit Ethernet. En los armarios de conexiones se han substituido los viejos equipos (de diferentes marcas y modelos) por equipos homogéneos. De manera que además de ganar en rendimiento se simplifica su gestión.
• Se están instalando puntos de acceso Wi-Fi en nuevas aulas.
• Se ha instalado un nuevo enlace de fibra óptica que substituye al viejo router ADSL Cisco 1700 de la XTEC.

 

Si bien todos estos puntos suponen mejoras en diferentes aspectos de lo que quiero hablar es del último punto. Y esto es porque al pasar a utilizar la nueva infraestructura han sucedido algunas peripecias que pueden tener cierto interés técnico para mis alumnos.

Un poco de historia

A lo largo del tiempo la red del centro ha ido creciendo y evolucionando. Si nos fijamos en el acceso a Internet un resumen de la evolución puede ser:

1. Pasamos a tener un acceso mediante un router Cisco 1700 que utiliza dos líneas ADSL y cuenta con IP estática en Internet para que se puedan alcanzar nuestros servidores
2. La LAN del centro se subdivide en VLANs para las diferentes aulas y departamentos. Se monta un proxy-cache (Squid) interno que además ofrece DNS, DHCP y NTP a los equipos del centro.
3. Se monta una infraestructura WiFI, la XEiLL, con su propio servidor (Squid, DHCP, DNS, OpenVPN con otros centros, etc...)
4. Con el aumento de número de aulas, uso intensivo del acceso a Internet y la llegada de los portátiles del proyecto 1x1 el ancho de banda disponible para acceder a Internet es claramente insuficiente. El proyecto 1x1 acaba instalando tres nuevos routers ADSL (domésticos) y nosotros contratamos otros tres para ampliar el ancho de banda.

 

Llegados al punto 4, la gestión del acceso a Internet se enfrenta a varios retos:

• Maximizar el rendimiento y eficacia en el acceso a Internet
• Evitar que la sobrecarga de conexiones desde un aula o departamento deje sin servicio al resto del centro
• Permitir accesos de todo tipo (que no sean FTP/HTTP/HTTPS), ya que desde nuestras aulas se realizan prácticas en las que se precisan este tipo de conexiones a Internet

Estos objetivos son, en gran medida, irreconciliables. Por ejemplo para mejorar el rendimiento al navegar y evitar problemas de saturación lo más sencillo es permitir únicamente conexiones que pasen por Squid. Pero esto no permitirá desde las aulas utilizar P2P, hacer SSHs al exterior o realizar prácticas con SMTP/POP3/IMAP.

Además, y por si no era poco entretenido tratar de garantizar un acceso razonable a Internet desde el centro, hay que añadir que los 6 ADSLs (3 del proyecto 1x1 y 3 contratados por nuestra parte) utilizan líneas de muy mala calidad y pierden/recuperan sincronismo varias veces al día (lo que normalmente en casa no ocurre nunca). De manera que hay que monitorizar su estado para utilizar únicamente los que están 'vivos'.

Bueno, pues el puzle estaba resuelto de la siguiente manera: Galadriel, que es el equipo en el que concentramos la gestión de los accesos a Internet:

• Puede alcanzar al router de la XTEC (192.168.0.1) y a través de él salir a Internet. Por este router es por el que llegan las peticiones desde Internet para nuestro centro (Web: TCP 80 y 443, SSH) y por este router es por el que se responden dichas peticiones.
• Puede alcanzar los 6 routers ADSL adicionales (192.168.2.1 -> 192.168.2.6). Por estos routers se satisfacen los accesos desde el centro al exterior.
• Monitoriza el estado de los 6 routers ADSL adicionales (el de la XTEC no suele fallar), dejando de utilizar aquellos que pierden sincronismo y vuelve a utilizarlos cuando lo ganan. Consiguiendo una bonita tolerancia en el acceso a Internet que no me hubiera molestado en implementar de no ser necesaria.
• No todos los routers ADSL suplementarios tienen la misma capacidad así que en el balanceo de carga se utilizan pesos.
• Se distingue entre dos clases de tráfico: prioritario y no prioritario. Se considera tráfico prioritario a las peticiones realizadas por la propia Galadriel. Esto es, peticiones HTTP/HTTPS de Squid, o del DNS o NTP. Se considera tráfico no prioritario a aquellas conexiones que son reenviadas a través de Galadriel (y que no son http, porque estas son redirigidas para utilizar Squid en modo transparente). Es decir el P2P y cualquier otra conexión que se realice desde las aulas al exterior será tráfico no prioritario.
• Se impone un límite al número de conexiones reenviadas a través de Galadriel para cada VLAN.
• Se realiza traffic shaping para garantizar que el tráfico prioritario no se verá frenado por el tráfico no prioritario. Y que todo el ancho de banda no consumido por el tráfico prioritario estará disponible de forma agregada para el no prioritario. Esta política de colas se implementa router a router para cada uno de los 6 disponibles.

 

Todo esto en la práctica conlleva unas deficiencias que no se pueden solventar. Por ejemplo:

1. Realizar el balanceo de carga entre 6 routers ADSL implica que al establecer una nueva conexión con el exterior se escogerá uno de los routers disponibles (en función de la capacidad y su peso). El tráfico de dicha conexión únicamente utilizará ese router, así que en nada se beneficia de la capacidad disponible en los otros. Con una sola conexión no ganamos nada al tener varios routers pero cuando hay varias conexiones sí. Por ejemplo el P2P permite descargar un fichero a través de varias conexiones así que en ese caso se hará uso de los diferentes routers y la velocidad de descarga agregada aumentará. De hecho no hace falta P2P para aprovechar los 6 routers, dado el número de ordenadores y personas que navegan de forma habitual por Internet en el centro (y dado que no todos visitan la misma web) los ADSLs tienen trabajo.
2. Como ya he dicho los 6 enlaces ADSL fallan más que una escopeta de feria. Lo único que Galadriel puede hacer es monitorizar su estado y quitarlos/ponerlos en la lista de routers vivos. Pero como las pérdidas de sincronismo son impredecibles nos encontramos con que cuando un router deja de funcionar todas las conexiones que lo estaban utilizando quedan cortadas. Cuando la aplicación lo detecte podrá establecer una nueva conexión que saldrá a través de uno de los routers disponibles, pero esto lleva su tiempo y lleva a que el usuario perciba un errático y molesto comportamiento.
3. Complejidad, el principio KISS salta por los aires y el mantenimiento se vuelve más exigente.

 

Llega la fibra óptica

Pues sí, finalmente en el curso 2012-2013 llega a nuestro centro un nuevo enlace de fibra óptica simétrico de 100Mbps que substituye al viejo router ADSL de la XTEC (el mencionado Cisco 1700). Este enlace no nos conecta directamente con Internet sino con la red de la XTEC/Anella Científica, donde se aplica una serie de filtrado de salida y de entrada antes de alcanzar Internet. Por supuesto cuenta con una IP estática que permite alcanzar nuestros servidores.

El ancho de banda que nos proporciona es variable y está lejos de los 100Mbps simétricos (sobre todo en el canal de subida) pero aún así es mucho mejor que las líneas ADSL (por lo menos no es intermitente :-).

 

 

 

 

 

 

Pero con la nueva conexión también nos encontramos:

• La XTEC utiliza los servicios de BrightCloud en un filtro web que bloquea el acceso desde el centro a muchas páginas
• Bloqueo de puertos al acceder desde el centro hacia el exterior
• Seguramente se esté realizado traffic shaping en el acceso a Youtube, no va fluído (http://www.youtube.com/my_speed#)

 

Después de dar una pocas vueltas, acabamos encontrando a la persona que atiende nuestras demandas y todos estos puntos están solucionados. Ahora, lo peor estaba por llegar...

Smaug el dragón

Smaug el dragón llegó sin aviso, quemó la ciudad del valle y mató o ahuyentó a todos los enanos que vivían en la montaña solitaria. Como cualquiera entiende, si los enanos de Erebor hubieran tenido algún aviso de que Smaug venía a por su tesoro hubieran trabajado para fortificar aún más su reino y la historia hubiera sido otra.

Un dragón siempre es temible pero que te pille desprevenido acaba por zanjar cualquier cuestión.

¿Cuál ha sido nuestra sorpresa inesperada? Descubrir que Google (y el resto de buscadores conocidos, si es que existen) dejan de mostrar entre sus resultados nuestras páginas.

Y ¿cuándo se descubre esto? pues cuando es tarde y el daño ya está hecho. Porque el enlace de fibra no solo tenía bloqueos desde el instituto hacia el exterior. También existían bloqueos desde el exterior hacia el instituto, donde están alojados los servidores. Y estos filtros eran mucho más selectivos. Bien que se veía nuestra web desde casa o el móvil, pero aquellos crawlers que nos visitaban con tanta frecuencia dejaron de hacerlo.

Googlebot dejó de visitarnos, y esto ocurre porque se ha cansado de hacerlo sin que le contestemos. Pues en cada intento de visita el filtro le impide el acceso a nuestras webs. Esto quedó clarísimo al comprobar si Googlebot tiene problemas al acceder a nuestro robots.txt.

Una vez aplicado el filtro a Googlebot se le deniegan el 100% de los accesos a nuestros servidores, para él no existimos. Se cansa de esperar y finalmente dejamos de aparecer en sus búsquedas. Se puede comprobar que al eliminar el bloqueo todo vuelve a la normalidad.

Esta fué la sorpresa con la que apareció nuestro dragón y esta es la desolación que provocó:

Un valle en el que nuestra página no aparece en los resultados de Google, y por lo tanto nadie la encuentra. ¿Nadie? Bueno, sí aquellos que recuerdan su dirección o aquellos que utilizan buscadores como Yandex o Baidu. Un buscador ruso y uno chino a los que no bloquearon y por lo tanto seguían visitándonos y mostrando nuestra web entre sus resultados.

¿Y por qué querría alguien bloquear a Googlebot? pues esa misma pregunta me hice yo durante un buen tiempo. Confieso que la primera idea que pasó por mi cabeza fue la relación Telefónica - César Alierta. Por si no lo saben el presidente de la compañía sostiene que puesto telefónica conecta a mucha gente a Internet, y estas personas utilizan los servicios de Google, pues Google debe pagar a Telefónica.

Si no lo han acabado de entender es mejor que lo explique él mismo...

Aunque pensándolo bien tal vez alguien deseara ahorrar un poco de preciado ancho de banda bloqueando el tráfico de las arañitas de los buscadores sin pensar en las consecuencias. Es verdad que nos visitan mucho, aquí está un fragmento de la estadística generada por nuestro awstats para el mes del desastre.

Pero también es verdad que hacen un trabajo fantástico y no aparecer en los resultados de búsqueda es un grave problema para nuestra web. Como ejemplo la estadística de accesos a nuestra web indica que es mayor la cantidad de visitas que recibimos a través de las búsquedas que aquellas que acceden directamente a nuestra web porque recuerdan su dirección. El tráfico de referencia corresponde a aquellas visitas que nos llegan siguiendo algún enlace.

Así que finalmente disfrutamos:

• de mayor velocidad y estabilidad en el acceso a Internet sin tener que utilizar varios ADSLs
• de mayor ancho de banda de subida, de manera que la respuesta de nuestros servidores a las peticiones desde Internet es mucho más ágil
• de la gracia de volver a aparecer en los resultados de búsqueda ya que Googlebot (y otros) nos visitan sin problemas

 

Y para celebrarlo he cambiado las reglas de iptables en Hobbiton, nuestra pasarela para la WiFi, de manera que ahora se permite un nuevo cupo de conexiones con destino al puerto TCP 5222 (XMPP) sin que estas se incluyan en el cupo de conexiones no prioritarias (P2P y otras cosas que no son DNS, NTP, HTTP/HTTPS) y por lo tanto se pueda utilizar Google Talk, Whatsapp y similares desde la WiFi sin los problemas de congestión que sufríamos.