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.
-- 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
