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? -- Rommel Rodriguez Toirac Administrador de redes ONAT Guantánamo Tel: 21327444 ext 120 ______________________________________________________________________ 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
