Caso de exito – Fitel Network S.L.

Fitel Network es una compañia de Cataluña, España. La compañía ha tenido su propia red inalámbrica durante dos años contando con mil subscriptores conectados.

Al final de 2017, el equipo de Fitel empezó a implementar fibra óptica. La fibra se instaló en las principales localidades urbanas de la ciudad de Lloret de Mar. La topología que el equipo de organización técnica decidió usar es FTTH y FTTB, con tecnología GPON. Actualmente, la red esta diseñada para conectar diez mil disposistivos de fibra ONT. Los servicios que son provistos a los usuarios finales incluyen VOIP y conexiones móviles. La compañía conecta empresas y clientes residenciales que pagan una cuota mensual (recurrente) y tiene un número de clientes quienes vienen a Lloret de Mar por vacaciones y pagan los servivicios en forma prepago.

La red de Fitel fue optimizada mediante la implementación del sistema de gestión ISP Splynx, rediseñando el núcleo  de la red para pemitir un rendimiento 10G, registrando AS y un espacio de direcciones Ipv4, además de la implementación de servicios BGP para sus clientes.

«Muchas horas de trabajo, algunos días sin dormir, todos esos esfuerzos quedan recompensados por el nucleo de la red de Fitel, que esta preparado para competir con las grandes operadoras en el tráfico IP del 10G, la implementación del BGP, OSPF, servidores PPPOE, enrutamiento, implementación de políticas de seguridad y también la implementación del software para ISP. Agradecimiento especial para el equipo de SPLYNX, Alex Vishnyakov y Paul Gerhardt por su dedicación y por creer en este gran proyecto.»

Erwin Cárdenas Barrera – Director General & CEO de Fitel Network S.L.

Describamos como empezó todo y la totalidad del proceso

En la mitad de 2018, las redes de Fitel requerian que nuestro equipo instalará e implementara el software de gestión Splynx. Durante la instalación e implementación,  nos percatamos de que el router principal MikroTik CCR estaba teniendo algunos extraños problemas. Los usuarios PPPoE estaban continuamente desconectandose, los paquetes de datos se perdían y el comportamiento de los routers era inestable. Paul Gerhardt, el directivo técnico de Fitel nos pidió que investigaramos si el problema estaba siendo causado por el software Splynx, pero sabíamos que Splynx puede reconectar sesiones PPPoE solo en un caso – cuando un administrador envía COA o el comando «finalizar sesión». Nuestros ingenieros estaban al tanto de esto y empezaron a analizar el diseño de la red.

La compañía tenía instalado equipamiento Huawei MA5608 OLT, que trabajaba en modo de puente, finalizando todas las conexiones PPPoE en el router MikroTik CCR1036. Este router estaba realizando la función de concentrador y servidor NAT. Cuando la red tenía solo clientes inalámbricos y alrededor de 800 Mbps, el router actuaba correctamente, pero cuando los primeros centerares de clientes GPON se conectaron, el tráfico del router alcanzó 1,4 Gbps y los problemas empezaron.

El principal problema era que una vez al día sobre las 4pm, varios clientes reconectaban sus sesiones PPPoE, lo que causaba que la actividad de la CPU saltara del 30% al 100%, y, como resultado, el router paraba de responder a las nuevas solicitudes PPPoE. Además, empezaba a desconectar a decenas de clientes PPPoE ya conectados.

Una corta investigación de nuestro equipo mostró que la monitorización de las conexiones NAT junto un gran número de conexiones PPPoE a partir de alto tráfico causaba este problema. Ofrecimos a las redes de Fitel nuestro servicio de rediseño y optimización de red.

La topología inicial se mostraba como en la imagen provista debajo:

MikroTik CCR1036

  1. Red inalámbrica. Todos los usuarios se conectan a través de la red en puentes L2 hasta un router CCR. Los clientes tienen un equipamiento UBNT o MikroTik CPE que funciona como un puente transparente. Cada cliente tiene un TP-Link o un router MikroTik instalado en la instalación que establece la conexión PPPoE y que también conecta los disposisitivos de los usuarios finales a sus redes Wi-Fi de casa.
  2. Red de Fibra. Un router Huawei MA5608 esta conectado a un router MikroTik CCR con dos interfaces Gigabit. Las interfaces están unidas usando LACP. La compañía planeó migrar a interfaces 10G y se encontraba esperando el módulo de tarjeta.
  3. MikroTik CCR1036. El router estaba conectado via un puerto 10G al enlance ascendente con un servidor PPPoE y NAT ejecutándose en él.

Nuestro equipo tiene experiencia diseñando redes ISP para más de 10G de cargas. Hemos construído y optimizado varias redes tanto inalámbricas como de fibra y es uno de los servicios que  un cliente puede obtener de nosostros al implementar el software ISP de Splynx. El punto de central de toda la optimización  fue mudar la carga del principal router MikroTik y compartirla entre diferentes equipos. También exisitía otra razón – cambiar el router MikroTik que es un enrutamiento basado en la CPU a algún router acelerado por hardware, por ejemplo Juniper, Alcatel o Cisco.

El equipo informático de Fitel Network tenía conocimientos en MikroTik y, de por sí, cambiar la plataforma fue muy sencillo. Decidimos coger mas de un router MikroTik, añadir conmutadores para tener una topología redundante L2, y compartir la carga entre los diferentes equipos.

El resultado del rediseño y optimización es presentado en la la siguiente imágen:

 

Topología lógica creada en un sofware de visualización:

El equipamiento que fue instalado

Un router MikroTik CCR1036 que actúa como el router BGP y NAT.

Un MikroTik CRS317 de 16 puertos SFP+- conmutador de nucleo, están conectados al enlace ascendente de puertos 10G, un router BGP y los tres routers PPPoE están también conectados via puertos 10G. Por favor dese cuenta de que un mismo conmutador esta instalado cerca del primero. El segundo conmutador actúa como un apoyo en frío. Esto significa que tenía exactamente la misma configuración que el conmutador de núcleo y la misma cantidad de puertos, listo para intercambiar en caso de fallo del primer conmutador.

3x routers MikroTik CCR1036 que trabajan como servidores PPPoE donde los clientes inalámbricos y de fibra están conectados.

Un MikroTik CRS328 de 24 puertos + 4 puertos SFP, que actúa como conmutador distribuidor. A este conmutador estan conectados GPON OLT y linkeadores llegados de torres inalámbricas. Además,  los enlaces de bajada del router PPPoE estan enchufados a este conmutador.

Un router BGP anuncia prefijos públicos a Internet y traza el tráfico entre dos proveedores de Internet. Los enlaces ascendentes son líneas de 10GB. Cada router PPPoE tiene su propia red privada 172.16.x.x dede la que asignamos direcciones IP a clientes privados y prepago. Eso significa que en el router BGP hay tres rutas estáticas instaladas a estas redes – cada red al apropidado router PPPoE.

Los Servidores PPPoE estan conectados al mismo conmutador en la misma VLANs, lo cuál significa que los usuarios de las redes inalámbricas y de fibra pueden conectarse a uno de los tres servidores PPPoE al mismo tiempo. La ventaja de esta estrategia es la adaptabilidad y la tolerancia frente a los fallos. Si un router falla, los clientes pueden automáticamente reconectarse a los dos restantes routers PPPoE.

Los Routers PPPoE estan linkeados con el servidor Radius de Splynx. Cuando un cliente se conecta al router1, obtiene la IP de la reserva, que esta dedicada a este preciso router.

Otra historia diferente ocurre con las direcciones IP públicas. En ese caso, los clientes poseen direcciones IP estáticas, lo que significa que físicamente pueden conectarse a cualquier servidor PPPoE.

Para saber donde debería mandar el tráfico el router BGP, hemos activado OSPF en tres links – entre cada concentrador PPPoE y el router BGP.  Las IP PPPoE de los clientes son redistribuidas a OSPF como rutas conectadas tan pronto como se conectan a internet. Es importante marcar los filtros del enrutamiento correctamente – permitiendo solo IP públicas en una tabla de enrutamiento con /32 rutas, y todas las IP privadas no son redistribuidas al OSPF.