El jueves, 23 de febrero de 2017 1:39:19 P. M. CST Arian Molina Aguilera escribieron: > 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.
a raíz de este problema ese switch L2 fue uno de los que cambié mientras buscaba soluciones, es decir, en este momento, el switch capa 2 esta dentro de un nylon en una caja. -- 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
