Oracle se corta. Sonicwall por medio en la MPLS. Parte 1 de 2.

Después de casi 5 días de constantes problemas parece que hemos encontrado nuestro problema de desconexiones de Oracle. Aquí relataré lo sucedido desde el punto de vista del departamento de sistemas-comunicaciones. Se notará por lo poco que puedo aportar en la parte de Oracle.

Tenemos una delegación nueva que conectar a nuestra MPLS, lo normal es conectar un F.O como línea principal y un ADSL de Backup, cada una conectada a un switch diferente, para así conseguir la alta disponibilidad en routers, lineas, conmutadores de proveedor de línea,  tramos físicos de cableado y tecnologías diferentes.

En este caso, por la prisas, nuestro proveedor no nos puede entregar a tiempo la F.O y empezamos a trabajar con el backup que es ADSL 4MB con 10% garantizado.

La nueva sede tiene un rango de IP: A.B.C.0 y nosotros queremos cambiarlo por el Z.X.Y.0 con lo que nuestra MPLS debe saber direccionar, por lo menos durante un tiempo, estos dos rangos.

Después de muchos problemas y configuraciones la solución acabó siendo la siguiente:

En nuestro router del proveedor de la línea, en la sede, debería dejar:

La nueva sede será la zona IP Z.X.Y.0 /24 y le pondremos la ip virtual Z.X.Y.250.2 /24  (se moverá entre la conexión principal y secundaria) y la física Z.X.250.4 /24  para el Backup.

Nuestro proveedor debería  enrutar la red A.B.C.0/24 y la red Z.X.Y.0/16 a la Z.X.250.1 y propagar esta ruta estática por la MPLS. La  Z.X.250.1 será nuestro host (router, switch de Nivel 3, en este caso un SonicWall) que haga de GW en la sede, que está conectado directamente al router del proveedor.

Nos aparecen muchos problemas con la MTU de la nueva línea. Para localizarlos e informar a nuestro proveedor, estudiamos el comportamiento de la línea en función al envió de paquetes de tamaños diferentes, usaremos un "ping -f -l tamaño_paquete IP"

El ping funciona sin problemas, pero ciertas aplicaciones más sensibles a que todo no esté perfecto se desconectan, así que empezamos buscar cuando nos empieza a fragmentar.

Vemos que nos deja pasar paquetes hasta 1434, entre 1434 y 1472 no nos contesta a ping, a partir de 1474 nos informa que es necesario fragmentar. Así que lo mejor es que el proveedor lo arregle. Estos ping se han hecho contra un host dentro de la red y el router de Colt, para poder descartar nuestra electrónica de red.

Con lo anterior conseguimos que el proveedor nos arregle el problema de la MTU.

En el siguiente post explicaré como los problemas siguen saliendo pero ahora el culpable es el SonicWall que nos hace de puerta de enlace de nuestra electrónica de red.