No tendrás configurado algún bonding en algún otro servidor?
On 02/22/17 10:32 PM, Rommel Rodriguez Toirac wrote: > El 21 de febrero de 2017 7:00:02 GMT-05:00, centos-es-requ...@centos.org > escribió: > > > >> >> Rommel hola !! >> >> Quien te puede estar causando estos problemas, es el servicio >> NetworkManager, esto debido que en las versiones de Centos o RHEL 6 >> este >> servicio de apodera del servicio network causando este tipo de >> inconvenientes. Sobre estas versiones se recomienda utilizar este >> servicio >> cuando se instala sobre ambientes gráficos o estaciones de trabajo por >> tener mas herramientas para el manejo de las redes, en ambientes de >> producción NO. O utilizas el servicio network o networkmanager. >> >> Ahora como dato, en versiones 7 de rhel y centos, el servicio >> NetworkManager pasa ocupar el puesto de amo y señor para la >> administración >> del servicio de red, deprecando el servicio network. >> >> al parámetro NM_CONTROLLED en tu configuración déjalo como "*no*" y el >> servicio des-habilitado. *chkconfig NetworkManager off* y *service >> NetworkManager stop. *Una vez realizado esto, reinicia tu servicio* >> "networking"* >> >> >> >> Ahora si no tuvieses habilitado este servicio, revisa la velocidad de >> tus >> tarjetas con el comando *ethtool* en relación a la velocidad en tus >> switches de comunicación. >> >> >> Saludos cordiales >> >> >> >> >> >> ----- >> *Arturo Diaz D.* >> *RHCE /RHCSA /VCAD* >> *Linkedin *https://cl.linkedin.com/in/arturodiazdiaz >> >> ---- >> >> El 20 de febrero de 2017, 16:08, Rommel Rodriguez Toirac >> <romme...@nauta.cu> >> escribió: >> >>> Mis saludos; >>> tengo un servidor CentOS 6.8 x86_64 (actualizado hasta hace una >> semana) en >>> el que solo lo tengo instalado y corriendo el gestor de bases de >> datos >>> Oracle 11g para 64 bit. >>> Me sucede que a veces se pierde todo tipo de conectividad con él (ni >>> responde el ping, ni tengo acceso vía ssh, ni el TNSping de Oracle >>> responde). Cuando esto sucede desde el servidor como tal hago ping a >> alguna >>> dirección IP de mi red y vuelve a existir la conectividad con este >> servidor. >>> He chequeado las trazas, pero no encuentro nada que hable de eso, ni >> de >>> que exista algún tipo de dificultad con los dispositivos de red. >>> Me he dado cuenta que desde una estación de trabajo (ya sea Windows >> XP o >>> Windows 7) al hacer ping a este servidor siempre se demora un poco >> (unos 8 >>> segundos) en obtener la primera respuesta, que siempre (en las 10 PC >> que >>> probé sucedío esto) obtengo "Tiempo de espera agotado" en ella y >> luego se >>> comunica normalmente. Si vuelves a hacer ping desde esa PC todo >> funciona >>> sin problemas y obtienes todas las respuestas sin perderse ninguna. >>> >>> C:\Users\administrator>ping pgtm.gtm.gob.cu >>> >>> Haciendo ping a pgtm.gtm.gob.cu [192.168.41.4] con 32 bytes de datos: >>> Tiempo de espera agotado para esta solicitud. >>> Respuesta desde 192.168.41.4: bytes=32 tiempo<1m TTL=64 >>> Respuesta desde 192.168.41.4: bytes=32 tiempo<1m TTL=64 >>> Respuesta desde 192.168.41.4: bytes=32 tiempo<1m TTL=64 >>> >>> Estadísticas de ping para 192.168.41.4: >>> Paquetes: enviados = 4, recibidos = 3, perdidos = 1 >>> (25% perdidos), >>> Tiempos aproximados de ida y vuelta en milisegundos: >>> Mínimo = 0ms, Máximo = 0ms, Media = 0ms >>> >>> Esta son algunas de las configuraciones que tengo relacionadas con >> red, >>> incluyendo el dispositivo de red donde tengo conectado el cable de >> red (los >>> otros tres dispositivos no están conectados). >>> >>> [root@pgtm ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 >>> DEVICE=eth0 >>> TYPE=Ethernet >>> UUID=11dcddd4-6530-457a-8d3e-01a8339fb113 >>> ONBOOT=yes >>> NM_CONTROLLED=yes >>> BOOTPROTO=none >>> HWADDR=6C:92:BF:26:C7:02 >>> IPADDR=192.168.41.4 >>> PREFIX=24 >>> GATEWAY=192.168.41.1 >>> DNS1=192.168.41.17 >>> DOMAIN=gtm.gob.cu >>> DEFROUTE=yes >>> IPV4_FAILURE_FATAL=yes >>> IPV6INIT=no >>> NAME="System eth0" >>> >>> cat /etc/hosts >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> ::1 localhost localhost.localdomain localhost6 >>> localhost6.localdomain6 >>> 192.168.41.4 pgtm pgtm.gtm.gob.cu >>> >>> [root@pgtm ~]# cat /etc/resolv.conf >>> # Generated by NetworkManager >>> search gtm.gob.cu >>> nameserver 192.168.41.17 >>> >>> [root@pgtm mail]# cat /etc/sysconfig/network >>> NETWORKING=yes >>> HOSTNAME=pgtm.gtm.gob.cu >>> GATEWAY=192.168.41.1 >>> >>> ¿Alguien que haya sufrido de lo mismo o parecido y haya solucionado? >> o >>> ¿alguien que conozca de algo que pudiera causar esta inestabilidad en >> la >>> conectividad con este servidor? o ¿alguien que conozca por donde mas >>> buscar para ver si encuentro algo que me ayude? > > Ya resolví el problema que tenía con la perdida de conectividad del > servidor, pero me queda la duda de qué causa esa situación y como eliminarla. > Les comento: > Me di cuenta de algo, las dirección MAC del dispositivo de red del servidor > en cuestión cambia. Por ejemplo, cuando hago un arping desde mi estación de > trabajo Kubuntu 16.04, miren lo que sucede: > > rommel@p6:~$ arping 192.168.41.4 > ARPING 192.168.41.4 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.653ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.683ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.622ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.631ms > ^CSent 3 probes (1 broadcast(s)) > Received 4 response(s) > > La primera respuesta viene con una dirección MAC diferente a las demás. Pero > cuando hago arping desde el mismo servidor a su misma dirección IP miren la > MAC que me contesta: > > [root@pgtm ] arping 192.168.41.4 -I eth1 > ARPING 192.168.41.4 from 192.168.41.4 eth1 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.658ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.662ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.655ms > Sent 5 probes (1 broadcast(s)) > Received 5 response(s) > > Cuando miro con ifconfig las configuraciones de los dispositivos de red, en > ningún lugar encuentro la MAC 00:1D:09:FF:44:4B > > [root@pgtm ] ifconfig > eth0 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:02 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7220000-c723ffff > > eth1 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:03 > inet addr:192.168.41.4 Bcast:192.168.41.255 Mask:255.255.255.0 > inet6 addr: fe80::6e92:bfff:fe26:c703/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:95819 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1924 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:11728605 (11.1 MiB) TX bytes:263674 (257.4 KiB) > Memory:c7200000-c721ffff > > eth2 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9C > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7120000-c713ffff > > eth3 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9D > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7100000-c711ffff > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:249609 errors:0 dropped:0 overruns:0 frame:0 > TX packets:249609 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:52090343 (49.6 MiB) TX bytes:52090343 (49.6 MiB) > > La solución fue asignarle otra dirección IP a ese servidor y todo se > resolvió; pero ¿por qué sucede eso?, ¿como eliminar el enlace entre la > dirección 192.168.41.4 y la dirección MAC 00:1D:09:FF:44:4B? y por último > ¿donde estara almacenado ese enlace, pues en este momento la dirección IP > 192.168.41.4 no está asignada a nada en mi red (ni printserver, ni switch, ni > router, ni estaciones de trabajo o servidores) y sin embargo cuando hago un > arping 192.168.41.4 obtengo respuesta? > > rommel@p6:~$ arping 192.168.41.4 > ARPING 192.168.41.4 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.631ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.691ms > ^CSent 4 probes (1 broadcast(s)) > Received 4 response(s) > > y esta es la respuesta con la nueva dirección IP en ese servidor (si se dan > cuenta coincide con la dirección MAC de eth0 que fue donde vo;ví a poner el > cable de red): > > rommel@p6:~$ arping 192.168.41.7 > ARPING 192.168.41.7 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.580ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.607ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.613ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.594ms > ^CSent 4 probes (1 broadcast(s)) > Received 4 response(s) > > > Rommel Rodriguez Toirac > romme...@nauta.cu > _______________________________________________ > CentOS-es mailing list > CentOS-es@centos.org > https://lists.centos.org/mailman/listinfo/centos-es > _______________________________________________ CentOS-es mailing list CentOS-es@centos.org https://lists.centos.org/mailman/listinfo/centos-es
