sábado, 6 de marzo de 2010

Wireless en Linux para Compaq Presario V6000

Objetivo:
La Compaq presario V6000 en su tarjeta WiFi viene con el chipset BCM4311. Hasta ahora nunca he instalado una distribucion Linux la cual me reconozca dicha tarjeta luego de la instalacion del sistema operativo. Por ello les dejo este pequeno resumen. En mi caso utilice Mandriva 2010 kernel 2.6.31.

Archivos necesarios:

b43-fwcutter-012-1mdv2010.0.x86_64.rpm
broadcom-wl-4.150.10.5.tar.bz2

Procedimiento:

1) Asegurarse el chipset de la tarjeta wireless:

lspci -vnn | grep -i wire

2) export FIRMWARE_INSTALL_DIR="/lib/firmware"

3) tar xjf broadcom-wl-4.80.53.0.tar.bz2
4) cd broadcom-wl-4.80.53.0/kmod
5) sudo ../../b43-fwcutter-012/b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o

Probablemente necesites reiniciar, o realizar un /etc/init.d/network stop/start. Si estas en la interfaz grafica puedes ir a "Configure your computer --- Network & Internet --- Set up a new network interface ---- Wireless"

La interfaz sera reconocida como wlan0 pero recuerda que puede variar

Links relevantes
- rpmfind
- Linux Wireless

Eso es todo!

Como medir el ancho de banda de un enlace

Introduccion:
En repetidas oportunidades nos vemos en la necesidad de medir el ancho de banda de algun enlace, ya sea el mismo una red LAN, WAN, MAN utilizando satelite, microondas, fibra, etc y no sabemos como.
Para los conocedores del area tambien es comun que la gente de transmision nos indiquen que el enlace a nivel de capa 2 esta perfecto que no hay errores ni perdidas y que las pruebas de BERT salieron sin errores. Sin embargo al momento de probar dicho enlace con un router y transportando IP nos vemos con inconvenientes. Ahora bien, algo que es muy cierto es que el cliente tiene la ultima palabra, si el cliente dice que ve errores y/o que la aplicacion no funciona hay que revisar.


Objetivo
:
Vamos a medir el ancho de banda y calidad de un enlace. Cuando me refiero a enlace puede ser la comunicacion en un enlace WAN, entre dos equipos en una misma LAN. Para estas pruebas el medio fisico (wireless, satelite, fibra, microondas) es irrelevante.

Software necesario:
Linux y/o Windows
Iperf

Como hacer el estudio:
Vamos a basar nuestro estudio en el programa Iperf. Wikipedia en su pagina en Ingles define Iperf como un programa moderno para probar redes que es capaz de crear stream TCP y UDP y mide el ancho de banda de la red donde se ejecutan. Iperf fue realizado en C++
Iperf es un programa cliente - servidor por ello es necesario instalar el programa en al menos dos dispositivos. El mismo programa funciona tanto cliente como servidor. Su comportamiento varia segun las opciones que utilicemos al momento de ejecutarlo.
Una ventaja de Iperf es que hacemos la prueba en capa 3, es decir en IP, con Iperf podemos probar TCP y UDP y con distintos programas de paquete. Esto es sensacional.

Procedimiento:
Es necesario dos equipos donde uno es cliente y el otro sera el servidor. Por default Iperf mide el ancho de banda desde el cliente al servidor (sin embargo existe una opcion de medicion bi-direccional)

Ejemplos utiles:

1) Prueba mas basica. Opciones por default.
Lado server:

[root@monitor-2 root]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

Lado cliente:

[root@pemon ~]# iperf -c 10.1.1.1
------------------------------------------------------------
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.2 port 51096 connected with 10.1.1.2 port 5001
[ 3] 0.0-10.0 sec 84.4 MBytes 70.8 Mbits/sec

2) Vamos a probar un Megabit entre el cliente y el servidor durante 15 segundo en paquetes UDP.
Lado server:
iperf -s -u

Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1. -t 15 -u

3) Realizar una prueba de 2 Megabits de envio simultaneo entre el cliente y el servidor de paquetes UDP por 15 segundos
Lado server:
iperf -s -u

Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1 -t 15 -u -d -b 2000000

{SUPRIMI UN POCO DE LA SALIDA}
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.180 ms 0/ 2553 (0%)
[ 3] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.011 ms 0/ 2553 (0%)

Vamos a estudiar rapidamente el comando del cliente:
* con el -t 15 le indicamos 15 segundos
* -u que fuese UDP
* -d que fuese dual (envio y recepcion a la misma vez)
* -b 2000000 = 2 Mbits

Vamos a estudiar la salida tambien:
El intervalo fueron 15 segundos, se transfirio 3.58 Megabytes, el ancho de banda son 2 Mbits, el jitter es de 0.180 ms, se perdieron 0 datagramas de 2553 datagramas lo que representa 0 % de perdida

Recomendaciones:
Personalmente me agrada hacer mis estudios con Iperf utilizando UDP por diversas razones:
- Puedo indicar el ancho de banda
- No tengo inconvenientes con el Windows Size y/o perdida de algun acknowledge me baje drasticamente el Ancho de Banda
- Con la prueba de UDP yo mismo puedo calcular el impacto de las perdida de paquetes (imaginen la diferencia de perdida de paquetes (o errados) entre una red Wireless y una red cableada..

Salida del comado iperf --help para su referencia:

[root@monitor-2 root]# iperf --help
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]

Client/Server:
-f, --format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, --interval # seconds between periodic bandwidth reports
-l, --len #[KM] length of buffer to read or write (default 8 KB)
-m, --print_mss print TCP maximum segment size (MTU - TCP/IP header)
-p, --port # server port to listen on/connect to
-u, --udp use UDP rather than TCP
-w, --window #[KM] TCP window size (socket buffer size)
-B, --bind bind to , an interface or multicast address
-C, --compatibility for use with older versions does not sent extra msgs
-M, --mss # set TCP maximum segment size (MTU - 40 bytes)
-N, --nodelay set TCP no delay, disabling Nagle's Algorithm
-V, --IPv6Version Set the domain to IPv6

Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon

Client specific:
-b, --bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, --client run in client mode, connecting to
-d, --dualtest Do a bidirectional test simultaneously
-n, --num #[KM] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a bidirectional test individually
-t, --time # time in seconds to transmit for (default 10 secs)
-F, --fileinput input the data to be transmitted from a file
-I, --stdin input the data to be transmitted from stdin
-L, --listenport # port to recieve bidirectional tests back on
-P, --parallel # number of parallel client threads to run
-T, --ttl # time-to-live, for multicast (default 1)

Miscellaneous:
-h, --help print this message and quit
-v, --version print version information and quit

[KM] Indicates options that support a K or M suffix for kilo- or mega-

The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_, such as IPERF_BANDWIDTH.

Report bugs to


Links utiles:
http://www.noc.ucf.edu/Tools/Iperf/
http://sourceforge.net/projects/iperf/
http://en.wikipedia.org/wiki/Iperf

miércoles, 3 de marzo de 2010

Revisar el estado de las conexiones BGP via SNMP en un router Cisco

Objetivo:
Revisar el estado de las conexiones BGP en un router Cisco via SNMP

Procedimiento:
El procedimiento es muy sencillo, basicamente lo que se necesita es realizar un snmpwalk al siguiente OID: 1.3.6.1.2.1.15.3.1.2
Por ejemplo:
snmpwalk -v1 10.2.3.4 -c public 1.3.6.1.2.1.15.3.1.2

La salida que obtendremos será algo así:
SNMPv2-SMI::mib-2.15.3.1.2.10.6.7.8 6
SNMPv2-SMI::mib-2.15.3.1.2.10.8.9.8 3
SNMPv2-SMI::mib-2.15.3.1.2.10.11.33.44 1
SNMPv2-SMI::mib-2.15.3.1.2.10.14.55.44 6

En la salida anterior podemos ver que existen 4 sesiones BGP creadas hacia los IPs: 10.6.7.8, 10.8.9.8, 10.11.33.44 y 10.14.55.44 (las mismas que veremos al hacer un show ip bgp nei). De esta salida lo que necesitamos revisar es el último número del lado derecho y comparar dicho valor con la siguiente tabla:

1 : idle
2 : connect
3 : active
4 : opensent
5 : openconfirm
6 : established

Por ejemplo, en la salida anterior los peer 10.6.7.8 y 10.14.55.44 se encuentran en estado established.

Links importantes:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.2.1.15.3.1.2

lunes, 1 de marzo de 2010

Comando snmpget para tomar tabla arp de Router o Switch Cisco

Objetivo: Tomar por snmp la tabla ARP de un router Cisco Solución: El OID para tomar la tabla arp del router Cisco es: .1.3.6.1.2.1.17.4.3.1.1 sin embargo para poder consultar toda la tabla arp es conveniente hacer un snmpwalk de la siguiente manera: Con Linux el siguiente comando es suficiente: snmpwalk 192.168.127.129 -c public .1.3.6.1.2.1.17.4.3.1.1 La salida del comando es por stdout y por ello podemos luego realizar algún tipo de filtro luego de pasarlo por un pipe de manera sencilla. Por ejemplo para buscar una MAC que sabemos que contiene parte del string 51 AB podemos hacer lo siguiente: snmpwalk 192.168.127.129 -c public .1.3.6.1.2.1.17.4.3.1.1 | grep "51 AB" Suerte!

martes, 23 de febrero de 2010

Realizar un ping en un equipo Cisco con SNMP. Script en bash

Objetivo:
Desde un equipo con Linux indicarle a un Routero LAN Switch Cisco que realice un ping a un destino

Motivo:
Pueden existir diversos motivos para realizar la tarea mencionada. Por ejemplo en este momento necesito revisar si en la tabla arp de un equipo se encuentra una MAC en especifico y no tengo acceso desde mi NMS.

Software necesario:
net-snmp
snmp-devel

Configuración del router Cisco:
Para llevar a cabo dicha tarea es necesario tener acceso RW vía SNMP al router. Por ejemplo en modo configuracion:
#snmp-server community acostanetwork RW

Script en Linux:
#!/bin/sh
###### We've chosen 333 at random. 333 will be the row instance to use for this particular
###### ping experiment. After the ping, the row will be deleted.
###### This keeps the table clean. Router_Source is the dns name of the device we are
###### working with, and public is its RW community string. The values for
###### ciscoPingEntryStatus status are as follows (see Ping MIB):

###### 1 - active
###### 2 - notInService
###### 3 - notReady
###### 4 - createAndGo
###### 5 - createAndWait
###### 6 - destroy

#DECLARACION DE LAS VARIABLES
COM="epale" #SNMP Community name
PINGER_ROUTER="10.3.4.5"
IP_TO_PING="0A 00 00 01" #The IP address to ping should be define in HEX
PACKET_COUNT=20
PACKET_SIZE=100

###### We will clear out any previous entries by setting ciscoPingEntryStatus = 6 (destroy)

snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.16.333 integer 6
###### We start building the row by setting ciscoPingEntryStatus = 5 (createAndWait)
echo

snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.16.333 integer 5

echo
echo "###### Now let's set the characteristics of the ping #######"

###### Only the first three sets below are REQUIRED. The rest have default
###### values.

#Set ciscoPingEntryOwner = any_name
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.15.333 s anyname

#Set ciscoPingProtocol = 1 = ip (see CISCO-TC-V1SMI.my CiscoNetworkProtocol)
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.2.333 i 1

#Set ciscoPingAddress = #.#.#.#--take Remote_Dest's ip & convert each octet to hex
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.3.333 x "$IP_TO_PING"
#Set the packet count to 20 (ciscoPingPacketCount)
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.4.333 i $PACKET_COUNT

#Set the packetsize to 100 (ciscoPingPacketSize)
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.5.333 i $PACKET_SIZ

echo
echo "##### Now let's verify that the ping is ready to go and launch it #######"

#Get ciscoPingEntryStatus and make sure it is now equal to 2. This means
# notInService which indicates that we're ready to go.

snmpget -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.16.333

# Set ciscoPingEntryStatus = 1 to tell it to activate.

snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.16.333 integer 1

#Let's wait two seconds before looking the results
sleep 2

echo
echo "##### Let's look at the results. #####"

snmpwalk -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1

echo

echo "##### Now that we've gotten the results, let's destroy the row #####"
snmpset -c $COM $PINGER_ROUTER .1.3.6.1.4.1.9.9.16.1.1.1.16.333 integer 6



Funcionamiento:
- Declarar las variables de manera correcta al comienzo del script
- Notese que existe un sleep en el script. Este sleep sirve para esperar 2 segundos antes de continuar a ver los resultados. Es importante debido a que si se ejecuta el script sin la pausa el router probablemente no tendrá tiempo de tener los resultados.
- Recomiendo (pero no es necesario) instalar los MIBs ubicados en: http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&mibName=CISCO-PING-MIB

Ejemplo de resultado (con MIBs compilados):
CISCO-PING-MIB::ciscoPingProtocol.333 1
CISCO-PING-MIB::ciscoPingAddress.333 "0A 00 00 01 "
CISCO-PING-MIB::ciscoPingPacketCount.333 20
CISCO-PING-MIB::ciscoPingPacketSize.333 100
CISCO-PING-MIB::ciscoPingPacketTimeout.333 2000
CISCO-PING-MIB::ciscoPingDelay.333 0
CISCO-PING-MIB::ciscoPingTrapOnCompletion.333 2
CISCO-PING-MIB::ciscoPingSentPackets.333 20
CISCO-PING-MIB::ciscoPingReceivedPackets.333 20
CISCO-PING-MIB::ciscoPingMinRtt.333 1
CISCO-PING-MIB::ciscoPingAvgRtt.333 1
CISCO-PING-MIB::ciscoPingMaxRtt.333 1
CISCO-PING-MIB::ciscoPingCompleted.333 1
CISCO-PING-MIB::ciscoPingEntryOwner.333 "anyname"
CISCO-PING-MIB::ciscoPingEntryStatus.333 1
CISCO-PING-MIB::ciscoPingVrfName.333 ""

He colocado en negrillas e itálicas algunos valores importantes

Link importantes:


Espero sea de tu utilidad, suerte,

Compilar MIBs en Linux. Paso a Paso

Objetivo:
Instalar MIBs en Linux. En el presente caso utilizaremos unos MIBs de Cisco sin embargo el procedimiento es el mismo para cualquier otro MIBs.

Software necesario:
Necesitamos instalar net-snmp en nuestro equipo Linux. En mi caso con Mandriva:
urpmi snmp-devel

Tambien vamos a necesitar la linea devel de net-snmp:
urpmi lib64net-snmp-devel


y


rpm-build, es decir,
urpmi rpm-build

Procedimiento:
1) Averiguar donde SNMP almacena los repositorios MIBS:
net-snmp-config --default-mibdirs

2) Bajar los MIBS que queremos implementar. En este caso hay que tener mucho cuidado con los MIBS bajados en Internet, es importante que sean archivos de texto y que en la parte superior solo tengan comentarios y luego (como primera linea válida) contenga algo similar a: CISCO-RHINO-MIB DEFINITIONS ::= BEGIN" y la última linea debe decir END.
En el siguiente ejemplo bajaremos los siguientes MIBs:
ftp://ftp.cisco.com/pub/mibs/v2/CISCO-RHINO-MIB.my
ftp://ftp.cisco.com/pub/mibs/v2/CISCO-SMI.my

3) Copiar los MIBS en alguno de los directorios resultantes de: net-snmp-config --default-mibdirs
Por ejemplo:

cp /tmp/CISCO-*.my /usr/share/snmp/mibs

4) Ubicar el archivo de configuración global para snmp (no snmpd!)
Para mandriva: /etc/snmp/snmp.local.conf y agregar al final del archivo las siguientes lineas:

mibs +CISCO-RHINO-MIB
mibs +CISCO-SMI

5) Probar que los MIBs recien instalados funcionen:

[root@localhost ~]# snmptranslate -IR -On ciscoLS1010ChassisFanLed
.1.3.6.1.4.1.9.5.11.1.1.12

Comentarios:
Existe más de una manera de realizar la compilación de los MIBs en Linux, sin embargo yo solo quise mostrar una manera práctica, rápida y funcional de como realizar la tarea.

Links importantes:
El articulo arriba descrito es la suma de mi experiencia y de la traducción y resumen del articulo: http://www.net-snmp.org/wiki/index.php/TUT:Using_and_loading_MIBS

lunes, 22 de febrero de 2010

Realizar estudios de performance sobre un DNS Server

INTRODUCCION:

Recientemente tuve la necesidad de realizar algún estudio sobre el funcionamiento de dos servidores DNS los cuales soy responsable por su administración. Mis dudas
eran relacionadas al performance de los servidores.
En el mundo de los DNS el performance se mide de dos maneras:
* Throughput (numero de queries por segundo que el DNS Server es capaz de manejar)
* Latencia (tiempo de resolución de los queries)

En base a lo anterior uno mismo puede contruir unos scripts y apoyandonos en el comando DIG obtener gran información. Sin embargo durante mi investigación y
a través de una lista conseguí dos herramientas que pueden realizar un excelente estudio: dnsperf y resperf (http://www.nominum.com/services/measurement_tools.php)

OBJETIVO
Realizar y evaluar el performance de un DNS Server

SOFTWARE NECESARIO:
En mi caso hice todas las pruebas sobre un DNS Server en mandriva las herramientas sobre mandriva.
Software adicional: dnsperf y resperf. Se puede conseguir: http://www.nominum.com/services/measurement_tools.php
GNUplot

INSTALACION

wget ftp://ftp.nominum.com/pub/nominum/dnsperf/1.0.1.0/dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
tar -zxvf dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
cd dnsperf-1.0.1.0-1
rpm -ivh dnsperf-1.0.1.0-1.i386.rpm
urpmi gnuplot (MUY RECOMENDADO para generar unas gráficas más adelantes)

Los archivos binarios quedaran instalados en:
/usr/local/nom/bin

DOCUMENTACION:
Luego de la instalación del paquete existe una excelente documentación en formato pdf ubicada en:

/usr/local/nom/doc/dnsperf


FUNCIONAMIENTO:
En fin, basicamente lo que ambos programas hacen es tomar una enorme lista (un archivo de texto) donde existen miles de dominios separados por el tipo de query (A, AAAA, PTR, TXT, etc), lo envia a un servidor DNS (indicado por linea de comando) y luego empieza a recabar información para finalmente ofrecer un resumen de los resultados.
El archivo de texto puede ser editado, cambiado, modificado, etc por uno mismo sin inconveniente (archivo original: queryfile-example-100thousand).

EJEMPLOS:
Vamos a nombrar dos diferentes comandos con los cuales podemos hacer una evaluación. Recomiendo ampliamente leer la documentación oficial antes de proseguir. Estas herramientas consumen alto procesamiento de CPU, consumo de memoria y ancho de banda. Es muy sencillo saturar un servidor y dejarlo fuera de linea con estas herramientas. Adicionalmente hay que tener mucho cuidado con diversos firewalls que pueden encontrarse
en el medio entre el DNS Server y el cliente que ejecuta la aplicación.
Aquí van los ejemplos:

Comando 1: resperf
  • Ejemplo 1-1:
Query de 100000 consultas al DNS Server de localhost con un máximo de 100 consultas por segundo:

./resperf -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 100

Ejemplo de la salida:

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
^C
[root@localhost bin]# ./resperf -s 127.0.0.1 -d queryfile-example-100thousand -m 100

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
[Status] Testing complete

Statistics:

Queries sent: 2999
Queries completed: 2985
Queries lost: 14
Ran for: 100.000002 seconds
Maximum throughput: 98.000000 qps
Lost at that point: 2.00%



  • Ejemplo 1-2:
Query de 100000 consultas al DNS Server de localhost con un máximo de 10 consultas por segundo pero con un reporte en una página Web:

./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 10
Ejemplo de la página Web:




  • Ejemplo 1-3:
Query de 100000 consultas al DNS Server de localhost con un máximo de 100000 consultas por segundo pero con un reporte en una página Web:
./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig


Comando 2: dnsperf

Ejemplo 2-1:
Ejecutar 3 queries maximos al servidor localhost con un histograma de 20 por 10 segundos:

./dnsperf -d ../examples/dnsperf/queryfile-example-100thousand -q 3 -H 20 -l 10 -s 127.0.0.1

Salida del comando anterior:

[root@localhost bin]# ./dnsperf -d queryfile-example-100thousand -q 10 -H20 -l 10

DNS Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Processing input data
[Status] Sending queries (to 127.0.0.1)
[Status] Testing complete


Statistics:

Parse input file: multiple times
Run time limit: 10 seconds
Ran through file: 144 times

Queries sent: 870 queries
Queries completed: 870 queries
Queries lost: 0 queries

Avg request size: 37 bytes
Avg response size: 161 bytes

Percentage completed: 100.00%
Percentage lost: 0.00%

Started at: Mon Feb 22 18:17:43 2010
Finished at: Mon Feb 22 18:17:53 2010
Ran for: 10.105866 seconds

Queries per second: 86.088614 qps

Latency: Min: 0.000284 s; Max: 1.121552 s; Avg: 0.111007 s; StdDev: 0.169328

Response latency distribution (total 870 responses):

Latency Success Fail |
<>= 1.000s 8 0 |#

Legend:

##### = success responses (RCODE was NOERROR or NXDOMAIN)
----- = failure responses (any other RCODE)


Ejemplo 2-2:

Ejecutar 20 queries maximos al servidor localhost con un histograma de 4 por 20 segundos con una cantidad máxima de 25 queries por segundo:
./dnsperf -d queryfile-example-100thousand -q 20 -H4 -l 20 -Q 25

Suerte, espero sea de tu utilidad

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...