El 21 de febrero de 2017 7:00:02 GMT-05:00, centos-es-request@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 rommelrt@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 rommelrt@nauta.cu
Insisto, tenés algo en la misma IP.
El 22/02/2017 a las 06:32 p.m., Rommel Rodriguez Toirac escribió:
El 21 de febrero de 2017 7:00:02 GMT-05:00, centos-es-request@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 rommelrt@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 rommelrt@nauta.cu _______________________________________________ CentOS-es mailing list CentOS-es@centos.org https://lists.centos.org/mailman/listinfo/centos-es
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-request@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 rommelrt@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 rommelrt@nauta.cu _______________________________________________ CentOS-es mailing list CentOS-es@centos.org https://lists.centos.org/mailman/listinfo/centos-es
El Miércoles 22/02/2017, Rommel Rodriguez Toirac escribió: [ ... ]
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:
Definitivamente tienes otro dispositivo con la IP 192.168.41.4 configurada pero que no responde a los pings (configuracion habitual de los escritorios Windows si no me equivoco).
Segun http://www.coffer.com/mac_find/ la MAC 00:1D:09:FF:44:4B corresponde a un dispositivo Dell, por si te sirve para rastrearlo.
Tienes un servidor DHCP en tu red? Probablemente este dando direcciones del rango 192.168.41.0/24 que no deberia.
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)
-
Miguel González -
Normando Hall -
Ricardo J. Barberis -
Rommel Rodriguez Toirac