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