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