VPSs y mas.

martes, 30 de marzo de 2010

Clave por defecto de root en Ubuntu

Situacion:
Luego de instalar Ubuntu no puedo entrar como root ni hacer un "su" al usuario. El resto de los usuarios funcionan bien

Explicación:
Luego de la instalación, por defecto Ubuntu viene con el usuario root bloqueado, esto se puede verificar en /etc/shadow y ver el signo de exclamación (!) en el usuario root

Solución:
Existen muchas maneras de solucionar la situación. La más sencilla y funcional:

$sudo -i
#passwd root
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Luego de esto el usuario root quedará habilitado

Suerte!

jueves, 25 de marzo de 2010

Utilizando DNSTOP

Objetivo:
Utilizar correctamente DNSTOP

Software utilizado:
Distribución Mandriva
DNSTOP (http://www.rpmfind.net/linux/rpm2html/search.php?query=dnstop&submit=Search+...)

Ejecutando dnstop:
La manera de ejecutar dnstop es: comando interface. Por ejemplo

# dnstop {interface-name}
# dnstop eth0
# dnstop wlan0

Una salida tipica es:

Queries: 53 new, 391 total Thu Mar 25 13:04:37 2010

Sources Count %
--------------- --------- ------
200.xx.xx.5 137 35.0
200.xx.xx.2 46 11.8
200.xx.xx.253 24 6.1
190.xx.xx.2 21 5.4
200.xx.xx.140 18 4.6
200.xx.xx.30 12 3.1
200.xx.xx.141 11 2.8
200.xx.xx.118 10 2.6
200.xx.xx.186 10 2.6
10.xx.xx.162 8 2.0
200.xx.xx.138 8 2.0
200.xx.xx.6 6 1.5

Ahora bien, dnstop no solo genera la salida anterior sino que puede generar MUCHA más información, todo es cuestión de saberlo utilizar.
Por ejemplo, puedes ejecutar dnstop con el siguiente comando:
#dnstop -l 3 eth1

Durante la ejecución presiona el numero "1" o "2" o "3". Podrás ver hasta 3 niveles de resolución de nombres y así saber que nombres generalmente resuelven tus clientes.

Otra opción muy interesante es el tipo de query sobre el DNS Server (A, AAAA, PTR, etc). Para ello durante la ejecución presiona "t".

Opciones típicas de dnstop:

 s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names ! - with Sources
2 - 2nd level Query Names @ - with Sources
3 - 3rd level Query Names # - with Sources
4 - 4th level Query Names $ - with Sources
5 - 5th level Query Names % - with Sources
6 - 6th level Query Names ^ - with Sources
7 - 7th level Query Names & - with Sources
8 - 8th level Query Names * - with Sources
9 - 9th level Query Names ( - with Sources
^R - Reset counters
^X - Exit

? - this

Links:
Este articulo es una traducción y adaptación de experiencia propia de: http://www.cyberciti.biz/faq/dnstop-monitor-bind-dns-server-dns-network-traffic-from-a-shell-prompt/

jueves, 18 de marzo de 2010

Comportamiento de mi blog de visitas antes y despues del terremoto de Chile

Objetivo:
Analisis muy rapido y por encima sobre el comportamiento de trafico a Internet antes de despues del terremoto de Chile (en base a mi modesto Blog).

Como todos sabemos, el 27 de Febrero de 2010 un fuerte sismo sacudió nuestro país hermano Chile, por ello, me preguntaba en estos días que habrá pasado durante esos días y si el acceso al presente blog había variado durante dichas fechas.

Como comentario, mi blog actuamente (Marzo 2010) tiene casi 1000 mensuales provenientes principalmente de países donde habla español.

Por lo anterior, lo que hice fue apoyarme en Google Analytics y construir el pequeño resumen que vemos a continuación:

Premisas:
* Solo se tomó visitas que provienen de Chile
* Las visitas son de lunes a viernes (no se incluyen fines de semana)


Tabla resumen:
































Semana VisitasObservación
15-19 de Febrero242 Semanas antes del
terromoto
22-26 de Febrero26Semana anterior al
terromoto
1 - 5 Marzo15Semana siguiente al
terromoto
8 - 12 MarzoAprox 292 Semanas posterior
al terremoto




Resumen:
Podemos ver que desde Chile el presente blog lo visitan entre 25-30 personas a la semana.
La semana siguiente al terromoto hubo una caída de visitas de 45%
A las 2 semanas del terremoto las visitas se regularizaron

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!