El 23/02/17 a las 14:42, Rommel Rodriguez Toirac escribió:
> El jueves, 23 de febrero de 2017 1:52:20 P. M. CST Rommel Rodriguez Toirac 
> escribieron:
>> El jueves, 23 de febrero de 2017 1:39:19 P. M. CST Arian Molina Aguilera
>>
>> escribieron:
>>> El 23/02/17 a las 10:24, Rommel Rodriguez Toirac escribió:
>>>> El miércoles, 22 de febrero de 2017 6:00:44 P. M. CST Arian Molina
>>>> Aguilera
>>>>
>>>> escribieron:
>>>>> El 22/02/17 a las 09:17, NetAdmin escribió:
>>>>>> El 22/02/2017 a las 08:49 a.m., Rommel Rodriguez Toirac escribió:
>>>>>>> El martes, 21 de febrero de 2017 8:50:39 P. M. CST Arian Molina
>>>>>>> Aguilera
>>>>>>>
>>>>>>> escribieron:
>>>>>>>> El 21/02/17 a las 15:00, Rommel Rodriguez Toirac escribió:
>>>>>>>>> El martes, 21 de febrero de 2017 12:35:08 P. M. CST Miguel Narbona
>>>>>>>>> Fagales
>>>>>>>>>
>>>>>>>>> escribieron:
>>>>>>>>>> Si todo funcionaba bien desde un inicio y no hiciste ningún cambio
>>>>>>>>>> representativo, como adicionar equipos , soft de monitoreo,
>>>>>>>>>> firewall etc
>>>>>>>>>> ... entonces prueba a revisar los cables desde los puntos donde
>>>>>>>>>> detectas
>>>>>>>>>> perdida de paquetes y/o hacia ... luego los switch /tarjetas ..
>>>>>>>>>> ect
>>>>>>>>>> ..
>>>>>>>>>> posteriormente y de ultimo suicidio ... (pero creo q en tu caso
>>>>>>>>>> revisando los cables debería ser suficiente )
>>>>>>>>>> saludos
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: gutl-l-boun...@jovenclub.cu
>>>>>>>>>> [mailto:gutl-l-boun...@jovenclub.cu] On
>>>>>>>>>> Behalf Of Arian Molina Aguilera
>>>>>>>>>> Sent: Tuesday, February 21, 2017 11:35 AM
>>>>>>>>>> To: Lista cubana de soporte técnico en Tecnologias Libres
>>>>>>>>>> Subject: Re: [Gutl-l] Problema con conectividad
>>>>>>>>>>
>>>>>>>>>> El 21/02/17 a las 11:31, Rommel Rodriguez Toirac escribió:
>>>>>>>>>>> El martes, 21 de febrero de 2017 11:00:44 A. M. CST Arian Molina
>>>>>>>>>>> Aguilera
>>>>>>>>>>>
>>>>>>>>>>> escribieron:
>>>>>>>>>>>> El 21/02/17 a las 09:11, Rommel Rodriguez Toirac escribió:
>>>>>>>>>>>>> El lunes, 20 de febrero de 2017 2:20:57 P. M. CST Ulises
>>>>>>>>>>>>> Gonzalez
>>>>>>>>>>>
>>>>>>>>>>> escribieron:
>>>>>>>>>>>>>> On 02/20/2017 01:53 PM, Rommel Rodriguez Toirac wrote:
>>>>>>>>>>>>>>>   ¿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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Estas teniendo un problema a de capa 2 en tu red, hay algo que
>>>>>>>>>>>>>> hace
>>>>>>>>>>>>>> que
>>>>>>>>>>>>>> el protocolo ARP no este funcionando bien, lo cual se arregla
>>>>>>>>>>>>>> al
>>>>>>>>>>>>>> hacer
>>>>>>>>>>>>>> ping pues eso refresca los mapeos de MAC a IP, es virtual el
>>>>>>>>>>>>>> servidor
>>>>>>>>>>>>>> o
>>>>>>>>>>>>>> f'isico?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> En cualquier caso la soluci'on ser'ia revisar
>>>>>>>>>>>>>> switch/hub/virtual
>>>>>>>>>>>>>> switch
>>>>>>>>>>>>>> o lo que tengas en medio. El workaround es muy sencillo, pon
>>>>>>>>>>>>>> una
>>>>>>>>>>>>>> tarea
>>>>>>>>>>>>>> en cron que haga un ping cada 10 minutos y listo ping -c 1 a
>>>>>>>>>>>>>> una ip o
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> varias y listo, eso no te va a tumbar la red y te va a
>>>>>>>>>>>>>> resolver
>>>>>>>>>>>>>> un
>>>>>>>>>>>>>> problema
>>>>>>>>>>>>>>
>>>>>>>>>>>>>   La PC como tal es un INSPUR NF5280M4 tiene 4 dispositivos de
>>>>>>>>>>>>>
>>>>>>>>>>>>> red y ya
>>>>>>>>>>>>>
>>>>>>>>>>>>>   conecté>
>>>>>>>>>>>>>
>>>>>>>>>>>>> el cable de red en otro dispositivo de red y lo configuré
>>>>>>>>>>>>> también.
>>>>>>>>>>
>>>>>>>>>> Cambié
>>>>>>>>>>
>>>>>>>>>>>>> el switch. Apagué todo (todos los servidores y todos los switch
>>>>>>>>>>>>> que
>>>>>>>>>>>>> tengo) y todavía persiste el problema.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Desde mi estación de trabajo (Kubuntu 16.04) hago ping y no
>>>>>>>>>>>>>   tengo
>>>>>>>>>>
>>>>>>>>>> ningún
>>>>>>>>>>
>>>>>>>>>>>>>   tipo>
>>>>>>>>>>>>>
>>>>>>>>>>>>> de respuesta, probé desde otras PCs (Windows 10 y Windows 7)
>>>>>>>>>>>>> hago ping
>>>>>>>>>>>>> y
>>>>>>>>>>>>> se
>>>>>>>>>>>>> demora, luego de entre 5 u 8 segundos me devuelve la primera
>>>>>>>>>>>>> respuesta
>>>>>>>>>>>>> como
>>>>>>>>>>>>> perdida, luego si hace ping normalmete; cuando ahora pruebo
>>>>>>>>>>>>> desde mi
>>>>>>>>>>>>> estación de trabjo, hace ping sin problemas.
>>>>>>>>>>>>> Se que una solución de palo sería hacer ping a alguna dirección
>>>>>>>>>>>>> de mi
>>>>>>>>>>
>>>>>>>>>> red
>>>>>>>>>>
>>>>>>>>>>>>> cada un tiempo determinado, pero es que quisiera resolver eso
>>>>>>>>>>>>> sin
>>>>>>>>>>>>> engaños.>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Cambiar la distribución no está dentro de los planes (al
>>>>>>>>>>>>>   menos
>>>>>>>>>>>>>
>>>>>>>>>>>>> por
>>>>>>>>>>
>>>>>>>>>> ahora)
>>>>>>>>>>
>>>>>>>>>>>>> pues sería una mas a mantener los repositorios con mi limitado
>>>>>>>>>>>>> ancho
>>>>>>>>>>>>> de
>>>>>>>>>>>>> banda, sin contar las especificaciones y requerimientos de
>>>>>>>>>>>>> instalación
>>>>>>>>>>>>> del gestor de bases de datos Oracle.
>>>>>>>>>>>>> Hice lo que me recomendaron con el comando ethtool y no obtuve
>>>>>>>>>>>>> ninguno
>>>>>>>>>>
>>>>>>>>>> de
>>>>>>>>>>
>>>>>>>>>>>>> las respuestas relacionadas con error por encima de cero:
>>>>>>>>>>>>>
>>>>>>>>>>>>> NIC statistics:
>>>>>>>>>>>>>       rx_packets: 9741
>>>>>>>>>>>>>       tx_packets: 43
>>>>>>>>>>>>>       rx_bytes: 859940
>>>>>>>>>>>>>       tx_bytes: 3409
>>>>>>>>>>>>>       rx_broadcast: 9362
>>>>>>>>>>>>>       tx_broadcast: 9
>>>>>>>>>>>>>       rx_multicast: 360
>>>>>>>>>>>>>       tx_multicast: 19
>>>>>>>>>>>>>       multicast: 360
>>>>>>>>>>>>>       collisions: 0
>>>>>>>>>>>>>       rx_crc_errors: 0
>>>>>>>>>>>>>       rx_no_buffer_count: 0
>>>>>>>>>>>>>       rx_missed_errors: 0
>>>>>>>>>>>>>       tx_aborted_errors: 0
>>>>>>>>>>>>>       tx_carrier_errors: 0
>>>>>>>>>>>>>       tx_window_errors: 0
>>>>>>>>>>>>>       tx_abort_late_coll: 0
>>>>>>>>>>>>>       tx_deferred_ok: 0
>>>>>>>>>>>>>       tx_single_coll_ok: 0
>>>>>>>>>>>>>       tx_multi_coll_ok: 0
>>>>>>>>>>>>>       tx_timeout_count: 0
>>>>>>>>>>>>>       rx_long_length_errors: 0
>>>>>>>>>>>>>       rx_short_length_errors: 0
>>>>>>>>>>>>>       rx_align_errors: 0
>>>>>>>>>>>>>       tx_tcp_seg_good: 0
>>>>>>>>>>>>>       tx_tcp_seg_failed: 0
>>>>>>>>>>>>>       rx_flow_control_xon: 0
>>>>>>>>>>>>>       rx_flow_control_xoff: 0
>>>>>>>>>>>>>       tx_flow_control_xon: 0
>>>>>>>>>>>>>       tx_flow_control_xoff: 0
>>>>>>>>>>>>>       rx_long_byte_count: 859940
>>>>>>>>>>>>>       tx_dma_out_of_sync: 0
>>>>>>>>>>>>>       tx_smbus: 0
>>>>>>>>>>>>>       rx_smbus: 0
>>>>>>>>>>>>>       dropped_smbus: 0
>>>>>>>>>>>>>       os2bmc_rx_by_bmc: 0
>>>>>>>>>>>>>       os2bmc_tx_by_bmc: 0
>>>>>>>>>>>>>       os2bmc_tx_by_host: 0
>>>>>>>>>>>>>       os2bmc_rx_by_host: 0
>>>>>>>>>>>>>       tx_hwtstamp_timeouts: 0
>>>>>>>>>>>>>       rx_hwtstamp_cleared: 0
>>>>>>>>>>>>>       rx_errors: 0
>>>>>>>>>>>>>       tx_errors: 0
>>>>>>>>>>>>>       tx_dropped: 0
>>>>>>>>>>>>>       rx_length_errors: 0
>>>>>>>>>>>>>       rx_over_errors: 0
>>>>>>>>>>>>>       rx_frame_errors: 0
>>>>>>>>>>>>>       rx_fifo_errors: 0
>>>>>>>>>>>>>       tx_fifo_errors: 0
>>>>>>>>>>>>>       tx_heartbeat_errors: 0
>>>>>>>>>>>>>       tx_queue_0_packets: 5
>>>>>>>>>>>>>       tx_queue_0_bytes: 387
>>>>>>>>>>>>>       tx_queue_0_restart: 0
>>>>>>>>>>>>>       tx_queue_1_packets: 1
>>>>>>>>>>>>>       tx_queue_1_bytes: 96
>>>>>>>>>>>>>       tx_queue_1_restart: 0
>>>>>>>>>>>>>       tx_queue_2_packets: 19
>>>>>>>>>>>>>       tx_queue_2_bytes: 1594
>>>>>>>>>>>>>       tx_queue_2_restart: 0
>>>>>>>>>>>>>       tx_queue_3_packets: 12
>>>>>>>>>>>>>       tx_queue_3_bytes: 504
>>>>>>>>>>>>>       tx_queue_3_restart: 0
>>>>>>>>>>>>>       tx_queue_4_packets: 1
>>>>>>>>>>>>>       tx_queue_4_bytes: 80
>>>>>>>>>>>>>       tx_queue_4_restart: 0
>>>>>>>>>>>>>       tx_queue_5_packets: 0
>>>>>>>>>>>>>       tx_queue_5_bytes: 0
>>>>>>>>>>>>>       tx_queue_5_restart: 0
>>>>>>>>>>>>>       tx_queue_6_packets: 0
>>>>>>>>>>>>>       tx_queue_6_bytes: 0
>>>>>>>>>>>>>       tx_queue_6_restart: 0
>>>>>>>>>>>>>       tx_queue_7_packets: 5
>>>>>>>>>>>>>       tx_queue_7_bytes: 342
>>>>>>>>>>>>>       tx_queue_7_restart: 0
>>>>>>>>>>>>>       rx_queue_0_packets: 5561
>>>>>>>>>>>>>       rx_queue_0_bytes: 358923
>>>>>>>>>>>>>       rx_queue_0_drops: 0
>>>>>>>>>>>>>       rx_queue_0_csum_err: 0
>>>>>>>>>>>>>       rx_queue_0_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_1_packets: 492
>>>>>>>>>>>>>       rx_queue_1_bytes: 55187
>>>>>>>>>>>>>       rx_queue_1_drops: 0
>>>>>>>>>>>>>       rx_queue_1_csum_err: 0
>>>>>>>>>>>>>       rx_queue_1_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_2_packets: 771
>>>>>>>>>>>>>       rx_queue_2_bytes: 76077
>>>>>>>>>>>>>       rx_queue_2_drops: 0
>>>>>>>>>>>>>       rx_queue_2_csum_err: 0
>>>>>>>>>>>>>       rx_queue_2_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_3_packets: 471
>>>>>>>>>>>>>       rx_queue_3_bytes: 67969
>>>>>>>>>>>>>       rx_queue_3_drops: 0
>>>>>>>>>>>>>       rx_queue_3_csum_err: 0
>>>>>>>>>>>>>       rx_queue_3_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_4_packets: 744
>>>>>>>>>>>>>       rx_queue_4_bytes: 76398
>>>>>>>>>>>>>       rx_queue_4_drops: 0
>>>>>>>>>>>>>       rx_queue_4_csum_err: 0
>>>>>>>>>>>>>       rx_queue_4_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_5_packets: 530
>>>>>>>>>>>>>       rx_queue_5_bytes: 60209
>>>>>>>>>>>>>       rx_queue_5_drops: 0
>>>>>>>>>>>>>       rx_queue_5_csum_err: 0
>>>>>>>>>>>>>       rx_queue_5_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_6_packets: 519
>>>>>>>>>>>>>       rx_queue_6_bytes: 53151
>>>>>>>>>>>>>       rx_queue_6_drops: 0
>>>>>>>>>>>>>       rx_queue_6_csum_err: 0
>>>>>>>>>>>>>       rx_queue_6_alloc_failed: 0
>>>>>>>>>>>>>       rx_queue_7_packets: 653
>>>>>>>>>>>>>       rx_queue_7_bytes: 73062
>>>>>>>>>>>>>       rx_queue_7_drops: 0
>>>>>>>>>>>>>       rx_queue_7_csum_err: 0
>>>>>>>>>>>>>       rx_queue_7_alloc_failed: 0
>>>>>>>>>>>>
>>>>>>>>>>>> cambiaste el path cord de red, cambiaste el switch??, existe
>>>>>>>>>>>> algo
>>>>>>>>>>>> especial entre ese server--switch--estación de trabajo??, no
>>>>>>>>>>>> atraviesa
>>>>>>>>>>>> ningún firewall intermedio??.
>>>>>>>>>>>>
>>>>>>>>>>>   Desde ese servidor a la red de estaciones de trabajo:
>>>>>>>>>>> servidor_pgtm --> switch --> switch --> estaciónes_trabajo
>>>>>>>>>>> He cambiado el latiguillo, el switch, he conectado el cable de
>>>>>>>>>>> red
>>>>>>>>>>> en
>>>>>>>>>>> otro
>>>>>>>>>>
>>>>>>>>>> de
>>>>>>>>>>
>>>>>>>>>>> los dispositivos de red del servidor.
>>>>>>>>>>> No existe ningún firewall, ni el SELinux está corriendo.
>>>>>>>>>>
>>>>>>>>>> veo que tienes dos switch, has probado cambiar los dos, cambiar de
>>>>>>>>>> puertos el enlace entre ambos, o el latiguillo con que se enlazan
>>>>>>>>>> los
>>>>>>>>>> mismos.??
>>>>>>>>>>
>>>>>>>>>   Al switch que está conectado ese servidor hay 5 mas y no tienen
>>>>>>>>>   ese
>>>>>>>>>   problema,>
>>>>>>>>>
>>>>>>>>> es solo con esa PC que me da ese problema y mi estación de trabajo
>>>>>>>>> la
>>>>>>>>> tengo
>>>>>>>>> conectada a ese switch también. Es decir, que comparto el mismo
>>>>>>>>> switch que
>>>>>>>>> ese servidor.
>>>>>>>>> Los otros switch que tengo son a donde se conectan las estaciones
>>>>>>>>> de
>>>>>>>>> trabajo de mi red, que hasta ahora funcionan sin problemas.
>>>>>>>>>
>>>>>>>>>   Me he dado cuenta de algo, las dirección MAC del dispositivo de
>>>>>>>>>   red
>>>>>>>>>   cambia,
>>>>>>>>>
>>>>>>>>> eso creo que no debe ser, ¿cierto?
>>>>>>>>>
>>>>>>>>>   Por ejemplo, cuando hago un arping desde mi estación de trabajo
>>>>>>>>>   (recuerden,
>>>>>>>>>
>>>>>>>>> está conectada al mismo switch), 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)
>>>>>>>>
>>>>>>>> es un servidor de virtualización o físico. todas las nic las tienes
>>>>>>>> conectado al mismo switch a la vez??, puedes ser un puerto del
>>>>>>>> switch
>>>>>>>> dañado o nic del server.
>>>>>>>>
>>>>>>>> la nic en cuestión es esta
>>>>>>>>
>>>>>>>>   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
>>>>>>>>
>>>>>>>> la mac 00:1D:09:FF:44:4B quizás corresponda con la de switch, hay
>>>>>>>> switch
>>>>>>>> de eso tp que no son buenos y no se llevan muy bien con la Capa 2,
>>>>>>>> L2.
>>>>>>>>
>>>>>>>> Según el prefix de esa mac 00:1D:09 corresponde a una tarjeta Dell,
>>>>>>>> tienes algún otro servidor con tarjeta Dell, quizás tengas un
>>>>>>>> conflicto IP.
>>>>>>>>
>>>>>>>   Tengo tres servidores Dell, pero resulta que he revisado la
>>>>>>>
>>>>>>> dirección MAC de
>>>>>>> cada uno de ellos y ninguno tiene ni esa IP, ni esa MAC.
>>>>>>>
>>>>>>>   La solución al problema en cuestión es simple, cambié la dirección
>>>>>>>
>>>>>>> IP de el
>>>>>>> servidor donde se presenta el problema y ya funciona sin lios, es
>>>>>>> decir, no
>>>>>>> pierde la conectividad, pero me quedan preguntas. ¿por que esa
>>>>>>> situación de
>>>>>>> una MAC inexistente ligada a una dirección IP? o ¿como eliminar esa
>>>>>>> MAC
>>>>>>> "fantasma" para dejar libre esa dirección IP?
>>>>>>
>>>>>> Ve a ver donde declaraste eso... algun dhcp ?
>>>>>> ______________________________________________________________________
>>>>>> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
>>>>>> Gutl-l@jovenclub.cu
>>>>>> https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
>>>>>
>>>>> busca bien puede ser una pc, laptop cualquier cosa de dell, puede tener
>>>>> activado firewall y no responder al icmp. Pero que esta en uso la ip
>>>>> esta en uso, resetea las tablas ARP de tus switches.
>>>>
>>>> " resetea las tablas ARP de tus switches." ¿como se hace eso?
>>>
>>> no dijiste que tienes switch L2, entra a dentro de ellos, o reinicíalos.
>>
>>  a raíz de este problema ese switch L2 fue uno de los que cambié mientras
>> buscaba soluciones, es decir, en este momento, el switch capa 2 esta dentro
>> de un nylon en una caja.
> 
>  Ya encontré cual era la causa del problema de la dirección IP enlazada a la 
> dirección MAC.
>  Los servidores DELL tienen en el SETUP la posibilidad de setear algo 
> relacionado con redes, donde puedes ponerle IP de la PC, puerta de enlace y 
> mascara entre otras cosas; pues bien, la dirección IP 192.168.41.4 la tenía 
> asignada uno de los servidores DELL en ese lugar, así que fue solo cambiarla 
> por la dirección real del mismo y listo.
>  Gracias a todos los que dieron su opinión y me ayudaron.
>  Por mi parte considero el hilo cerrado
> 
Muy bien.

-- 
Arian Molina Aguilera
Administrador de Redes y Servicios Telemáticos
Linux Usuario Registrado #392892
Telfs: +53(7)696-7510 ext 236
jabber: linuxc...@openmailbox.org
Brascuba Cigarrillos S.A. La Habana. Cuba.
“Nunca consideres el estudio como una obligación,
sino como una oportunidad para penetrar en el bello
y maravilloso mundo del saber. Albert Einstein”
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
              • ... Rommel Rodriguez Toirac
              • ... Ulises Gonzalez
              • ... yuniesky
              • ... Leslie León Sinclair
              • ... NetAdmin
              • ... Arian Molina Aguilera
              • ... Rommel Rodriguez Toirac
              • ... Arian Molina Aguilera
              • ... Rommel Rodriguez Toirac
              • ... Rommel Rodriguez Toirac
              • ... Arian Molina Aguilera
              • ... Manuel Mely
  • Re:... Tec. Comunicaciones Transgaviota Centro (Wilfredo Martínez Consuegra)
  • Re:... Ernesto Tur Laurencio
  • Re:... Manuel Mely

Responder a