jueves, 2 de mayo de 2013

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



Después de sortear todos los posibles problemas que teníamos con las líneas de comunicaciones, aun no conseguimos que todo funcione con normalidad.



Ahora toca tocar mirar nuestro SonicWall que nos hace el nivel 3 y alguna cosa más.


Después de llamar al servicio técnico de SonicWall y explicarles el problemas, optan por desactivar la siguiente opción para el Oracle.


Lo que en teoría debería ayudar, corta las conexiónes Oracle a los 5 segundos. Conseguimos arreglar el problema desactivando la ayuda para Oracle. Parece ser que con versiones anteriores de Oracle era necesario, nosotros estamos usando la 10.

Por fin!!! Ya se pueden abrir conexiones Oracle sin cortes y hacer selección de funciones, consultas etc.. y todo va bien hasta....

Al rato de hacer pruebas,  al intentar hacer una instalación de Packages la conexión vuelve a cortarse, únicamente con esta opción.

Después de investigar, observamos que el IPS del SonicWall la detecta como un SQLInjectión y la bloquea,  procedemos a desactivarlo.


Con lo que cerramos el tema de problema de conectividad de los últimos días.



GoN

jueves, 25 de abril de 2013

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.

jueves, 18 de abril de 2013

Red LAN lenta

A veces llegan unos de esos momento que no te explicas porque pasan las cosas, este es uno de esos.

En una de nuestras sedes se nos cae la línea principal y empezamos a ir por la Backup (ADSL), que evidentemente es mucho más lento. Lo extraño es que al rato los usuarios de la LAN empiezan a quejarse que todo va muy lento. Lo primero que piensas es que hacen algo mal, tipico... al rato me conecto de forma remota y al intentar copiar 400Kb veo que pasan más de 3 minutos... ups!. Reviso todo lo que se me ocurre y no veo nada mal.

Curiosamente al volver a funcionar con la línea principal (F.O) todo vuelve a la normalidad. Ahora toca averiguar que ha pasado y recoger el mayor número de información para poder arreglarlo.

Me he propuesto hacer lo siguiente si vuelve a repetirse:

- Hacer un copiar y pegar entre ordenadores de la misma VLAN (por IP no por DNS)
- Hacer un copiar y pegar entre ordenadores de difierentes VLAN (por IP no por DNS)
- Hacer un copiar y pegar entre ordenadores de un mismos Switch (por IP no por DNS)
- Hacer un copiar y pegar entre ordenadores de diferentes Switch (por IP no por DNS)
- Hacer un copiar y pegar entre ordenadores de diferentes Racks (por IP no por DNS)

No estaría mal guardar la información que podamos obtener medianta un:

- Tracert (desde los PC con problemas)

- sh process cpu history


-sh log


- sh cdp neigbour
- storm-control broadcast

No sobraría echar un vistazo al servidor de eventos de algún servidor o pc afectados.



Verificar la configuración de los puertos FD o HD y las estadísticas de ese puerto con el "sh interface"



Verificar que no hay bloqueos de seguridad



Una vez descartado lo más evidente vamos a profundizar.

Al final se hicieron los siguientes cambios:

[]Verificaremos el STP.

Primero hay que asegurarse quien va a ser el root, verificamos las prioridades. Yo en el 3750 lo tengo así




En la sede que tenía el problema, tenía todos los switches con esta configuración, puede que no fuese el causante de la lentitud, pero hemos aprovechado para corregirlo, la recomendación es dejar el root con esta prioridad y al resto sin esta línea o la priority ponerla más alta, por ejemplo a 32768.

También nos dimos cuenta que en la Vlan 1, que conectaba el router contra esta sede tenia el puerto del router backup (por el que estabamos funcionando ahora) a FD y generaba algún pequeño error. Esta Vlan 1 los Switch la utilizan también para intercambiarse información. Lo ideal es no usar nunca la Vlan1, pero bueno por una serie de motivos se tubo que dejar así.

Una vez corregido esto tiramos la linea principal y el problema de lentitud no se vuelve a reproducir, parece que ya está!! sino ya os contaré.



GoN