El 21/02/17 a las 16:36, Rommel Rodriguez Toirac escribió: > El martes, 21 de febrero de 2017 3:00:26 P. M. CST Rommel Rodriguez Toirac > escribieron: >> 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) > > > Estuve haciendo cambios en la configuración del dispositivo de red donde > tengo > conectado el latiguillo para eliminar que sea manejado por NetworManager y me > encontré con algo un poco curioso y raro. > Usé el comando setup de CentOS, eliminé los otros cuatro dispositivos de red, > y le asigné los valores correspondientes al que voy a usar y al darle Guardar > me dijo que la dirección IP 192.168.41.4 ya estaba siendo usada por 00:1D: > 09:FF:44:4B pero esa MAC no la tengo en ningún lugar. > Pregunta: ¿cual pudiera ser el motivo de que esté enlazado esa dirección IP > con una MAC que ya no existe?, ¿como poder eliminar esa MAC? > > en el correo anterior te mande a decir que esa mac corresponde a un equipo DELL, mira a ver que equipos de esa marca tienes en tu red. Me llamo la atención tu correo anterior, ya había dicho que era posible un conflicto ip, en linux suele pasar esas cosas y no nos alerta visual como en el winshit.
-- 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
