Comencemos con el punto 1
1- La tarjeta de red no funciona correctamente
Este es un problema visible, que logramos determinar al ver las estadísticas en el comando “ifconfig”
Aqui un ejemplo real de la tarjeta (hemos cambiado la IP solamente)
ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:6E:C1:3A:8A
inet addr:zzzz.xxxx.yyyy.wwww Bcast: zzzz.xxxx.wwww.223 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1875602 errors:0 dropped:0 overruns:0 frame:0
TX packets:2232760 errors:208 dropped:0 overruns:0 carrier:465
collisions:30 txqueuelen:1000
RX bytes:258344392 (246.3 Mb) TX bytes:2444720372 (2331.4 Mb)
Interrupt:10 Base address:0xf000
De toda esa información, lo más preocupante son dos errores:
carrier:465 errores. Esto normalmente significa que la portadora en el cable que conecta al equipo con el switch, está fallando y está dando errores. Puede deberse normalmente la causa a:
* el cable está dañado,
* el cable está viejo,
* la conexión de los puntos del cable tiene falsos contactos o
* el puerto del switch o de nuestra tarjeta de red están malos
collissions: 30. En un ambiente de red donde se maneje todo a base de switches (lo 100% comun en este momento en las redes) el servidor no debe tener ninguna colisión, por lo tanto hay que aclarar con el datacenter para que no nos pongan en un hub, sino en un switch decente que no genere colisiones.
Sin embargo, no es nuestra opinión que este es el problema por el que el servidor no responde, aunque puede ser un elemento que agudice la crisis, al tenerse que repetir paquetes, descartar paquetes, en fin trabajar con una red poco amiga. En todo caso, pedimos al proveedor que:
1. cambie el cable de red, y verifique que no tenga falsos contactos, y que tenga las medidas mínimas o máximas permitidas para cables 10baseT
2. De no funcionar el cable, que por favor, verifique que el server esté conectado a un switch y no a un hub y que el puerto del switch esté bueno. En todo caso que nos cambien de puerto para verificar
De no trabajar ninguno de estos dos arreglos, les solicitamos que manteniendo los dos cambios anteriores, procedan a cambiar la tarjeta.
3. Para poner las cosas peores, el proveedor no obedece a lo que le decimos (estamos en un ambiente de administración remota, el servidor en norteamérica nosotros en Ecuador) sino que procede a directamente cambiar la tarjeta de red por una 3com que supuestamente es mucho mejor.
El resultado del cambio fue que los paquetes con errores por causa de portadora (carrier) llegaban a ser casi los mismos que el total de paquetes procesados, lo que empeoró el asunto y nos demostró (?) indirectamente que parece que la tarjeta anterior no era la problemática sino que hay algo en el cable o el puerto. Posteriormente vuelven a poner la tarjeta realteck, realizan estos cambios a la vez (punto 1 y 2) y el problema de errores por carrier y colisiones se va.
Resumen para este punto: no se deben permitir colisiones en las tarjetas de red, ni errores de carrier. Cualquier otro error puede ser normal y deberse a condiciones propias de la red, y es más los otros errores a veces ocurren en ambientes de servidores congestionados o con muchos días activos (15, 30 o más días). Pero los errores por carrier siempre deben estar en 0 o muy cerca de cero si la máquina lleva varias semanas en funcionamiento (a veces pasa que falla la luz por un microcorte y sí falla el carrier pero uno o dos errores). Lo que no es normal es que una máquina con 10 o 30 minutos de funcionamiento ya tenga errores de carrier.