Barrapunto

Es posible que la culpa no sea enteramente de los proxy-caches. En octubre se produjo un gran cacao en el punto neutro de España, Espanix (lugar de interconexión de ISPs) ya que su arquitectura se vio desbordada debido al aumento brutal de conexiones y duplicaciones de velocidad, haciendo que se perdieran paquetes, afectando especialmente a las líneas de Telefónica. Espanix nos pasó un documento sobre el estado por entocnes pero ignoro como está el tema ahora. Al menos nuestros clientes han dejado de quejarse (nuestro ISP, Colt Telecom, decidió enrutar directamente las conexiones de Telefónica para evitar problemas), pero te pego el documento por si sirve de algo (me la estoy jugando por publicarlo), al menos que la gente sepa de donde han venido/vienen parte de sus problemas.

1. Introducción

        Este documento tiene como finalidad reflejar la actual arquitectura implementada en Espanix así como la evolución, tanto en tráfico como en diseño, experimentada en los últimos tiempos.

        Igualmente, se hace incapié en algunas dificultades y problemas detectados por el equipo técnico de Espanix que condicionan el actual diseño de Espanix así como la operativa del día a día.

2. Arquitectura de Espanix

        Los ENTERASYS MATRIX E7 han sido el medio común de conmutación del tráfico en la LAN de EspaNix desde Octubre de 2000.

        Desde el momento de su implantación se han demostrado como dos Gigaswitches estables, no dando indisponibilidad alguna en los casi cinco años de vida, y resultando una pieza fiable en la conmutación del tráfico en EspaNix.

        Durante este periodo, han surgido múltiples incidencias menores que han afectado a diversos miembros. Siempre se ha comprobado que el medio común no era el responsable directo de los incidentes menores surgidos, lo que ha hecho que desde EspaNix, con el beneplácito de los miembros, los MATRIX E7 hayan sido considerados hasta la fecha como un medio común fiable.

        Igualmente, al disponer los Matrix E7 de hasta 7 slots con capacidad de conmutación distribuida (cada slot dispone de su propio motor de conmutación y su propia gestión), han permitido la escalabilidad de Espanix durante todos estos años.

        Los Matriz E7 disponen de cuatro generaciones de slots, siendo la cuarta y más moderna la que convive en el chassis de los MATRIX E7 de EspaNix.

        Recientemente, y tras el gran incremento del tráfico conmutado experimentado en Espanix, fue necesario ampliar la arquitectura de Espanix con dos nuevos switches de conmutación.

        La inserción de estos nuevos elementos de conmutación vino determinada por la necesidad de proporcionar conectividad 10G a miembros de Espanix que habían experimentado un crecimiento tan grande en su tráfico, que hacía inviable cualquier modelo de crecimiento basado en conectividad 1G.
3. Evolución del tráfico

        En los últimos dos años, con el incremento de tráfico cursado por la mayoría de miembros en general, y de Telefónica Data, AUNA y ONO en particular, el tráfico en EspaNix ha pasado de 7 Gbps a 45 Gbps de pico, lo cual consolida a Espanix como el tercer nodo europeo por tráfico conmutado.

Yearly' Graph (1 Day Average):

Max In: 36.4 Gb/s Average In: 25.5 Gb/s Current In: 36.4 Gb/s
Max Out: 36.9 Gb/s Average Out: 25.8 Gb/s Current Out: 36.9 Gb/s

                                Daily' Graph (5 Minute Average)

Max In: 45.0 Gb/s Average In: 37.1 Gb/s Current In: 42.6 Gb/s
Max Out: 45.4 Gb/s Average Out: 37.6 Gb/s Current Out: 43.1 Gb/s

        El número de migraciones de FastEthernet a GigabitEthernet también ha crecido exponencialmente alcanzando la cifra de 44 conexiones Gigabit Ethernet y 30 conexiones FastEthernet.

4. Necesidad de un protocolo de agregación de puertos

        Como se puede apreciar en la arquitectura de Espanix, la unión entre los swtiches de conmutación de diferentes fabricantes (Enterasys y Cisco) se realiza mediante un agregado de enlaces de 1G.
        Inicialmente se contemplaron dos altenativas:
• unión mediante un agregado de enlaces de 1G
• unión mediante un enlace 10G

        Agregado de enlaces 1G
        En la esta opción, es imprescindible la utilización de un protocolo de agregación de puertos que permita distribuir uniformemente la carga de tráfico entre todos los enlaces. Como es sabido, el protocolo 802.3ad se ha constituido para proporcionar mayores ancho de banda y redundancia en las redes actuales. De esta forma, dos equipos de red pueden interconectarse con múltiples enlaces. Sin este protocolo, todos los enlaces a excepción de uno estarían cortados por Spanning Tree, siendo esta la única forma de tener una red estable. El protocolo de agregación de enlace permite establecer varios enlaces activos simultáneos entre estos nodos.
        De esta forma, cuando llega un paquete, debe existir un algoritmo que permite decidir a través de cuál enlace debe enviarse dicho paquete. Habitualmente se escoge un parámetro propio de dicho paquete y se realiza una función CRC del mismo,asignándole al resultado la pertenencia a uno de los enlaces. El protocolo prevé asisimismo la caída de un enlace, de forma que el resto de ellos pasan a incorporar el tráfico que anteriormente transportaba dicho enlace.
Se optó por el protocolo LACP (802.1ad) por ser el único protocolo soportado por ambos fabricantes.

        En las pruebas realizadas por el equipo técnico de Espanix, se detectó que el tráfico se balanceaba perfectamente en el sentido Cisco --> Enterasys mientras que en el otro sentido sentido, el balanceo no era uniforme y no seguía un patrón concreto.

        Las conclusiones de dichas pruebas fueron que ambos fabricantes implementaban diferentes algoritmos de balanceo de tráfico. Se centró el estudio en los algoritmos implementados por el E7 de Enterasys, que a raíz de las pruebas, demostraban no comportarse según lo esperado.

        El las versiones actuales de software de los Enterasys E7 se pueden elegir 3 tipos de algoritmos de salida:
– da-sa: el puerto de salida es seleccionado en función de la dirección MAC origen (SMAC) y de la dirección MAC destino (DMAC).
– dip-sip: el puerto de salida es seleccionado en función de la dirección IP (SIP) origen y de la dirección IP destino (DIP).
– round-robin: el puerto de salida es seleccionado en función del “tiempo” en el que entren los flujos en el equipo. Este método es totalmente aleatorio.

        De esta forma, cuando se configura el primer algoritmo (da-sa), se calcula el CRC de las direcciones MAC fuente y destino, y se elige el enlace a través del que se envía el paquete. Obviamente, todos los paquetes con las mismas direcciones físicas fuente y destino se enviarán a través del mismo enlace.

        La segunda opción es exactamente igual a la primera, pero el cálculo se hace con las parejas IP Origen y Destino. De la misma forma, todos los paquetes con idénticas IP Origen y Destino se enviarán a través del mismo enlace.

        Estadísticamente, cuando el número de flows es suficientemente grande (definiendo un flow como una pareja SMAC/DMAC o SIP/DIP según el caso), los enlaces transportarán aproximadamente la misma cantidad de tráfico. Obviamente si el número de flows no es suficientemente alto, (y si algunos flows transportan mucho más tráfico que otros), es posible que el tráfico no esté balanceado, sino que algún enlace transporte más tráfico que otros.

        Las pruebas realizadas demostraban que ninguno de estos algoritmos funciona correctamente en la arquitectura implementada en Espanix. Ambos algoritmos provocan pérdidas de paquetes en cuando se configuran, apuntando alguna limitación hardware de las propias tarjetas.
        Para poder averiguar la causa real de esas pérdidas, era preciso disponer de visibilidad de la arquitectura interna de las tarjetas, la cual, sólo puede proporcionar el fabricante.

        La información remitida por el fabricante refleja que cada tarjeta presenta tres procesadores dedicados al establecimiento de flows, teniendo cada uno de ellos una capacidad máxima de 64.000 flows. Cuando se alcanza la máxima capacidad, el procesador simplemente descarta la entrada más antigua e incorpora la más reciente. Este proceso implica determinado tiempo de cálculo y puede afectar al tráfico que se conmuta. Si se alcanzan los 64.000 flows de forma puntual, el tráfico no se verá afectado (o lo hará de forma imperceptible para el usuario). Si este límite se alcanza constantemente, el impacto puede ser más severo.

        En el escanario actual de Espanix, especialmente tras el notable crecimiento de tráfico experimentado, esa limitación se alcanza continuamente haciendo inviable la aplicación de esos algoritmos.

        Por tanto, la única solución válida es implementar el algoritmo round-robin. Este algoritmo no toma la decisión de balanceo en función de información de flujos por lo que la elección del enlace a utilizar es totalmente aleatoria. Esto provoca que ante enlaces temporalmente congestionados, el algoritmo tome la decisión de asignarle un nuevo flujo (existiendo otros enlaces vacíos de tráfico) que desborda la capacidad del enlace, produciendo pérdidas de paquetes.

        Como solución totalmente provisional, el equipo de Espanix monitoriza la congestión de los enlaces que constituyen el agregado LACP. Cuando se detecta saturación de algún enlace se reconfigura el algoritmo para forzar la reasignación de flujos.

        Enlace 10G

        Otra posible alternativa, sería la utilización de un enlace 10G para la unión entre los Enterasys y el Cisco. Con la información remitida por el fabricante, se constata que los enlaces 10G funcionan internamente como una agregación de enlaces de 1 Gigabit, siendo válidas todas las consideraciones hechas hasta este momento.

5. Conclusión

        En el documento se ha expuesto el actual problema que sufre Espanix de pérdidas puntuales de tráfico en el agregado LACP que une el switch Enterasys con el switch Cisco.

        Se han presentado también, las dos posibles soluciones que se presentaban teóricamente: mejora del algotimos de balanceo o unión mediante enlace 10G.

        A raíz de lo expuesto, se concluye que ambas soluciones no son válidas. Por tanto, la única solución viable para solventar la pérdida de paquetes sería la sustitución de las matrices de conmutación Enterasys E7 por otros equipos que no presenten ninguna limitación hardware y con una implementación de algoritmos de balanceo según lo esperado.