viernes, 27 de enero de 2012

Preferir 6to4 sobre IPv4 en Windows 7

Introduccion:
  El dia de hoy un buen amigo me pidio que hiciera unas pruebas en una pagina Web sobre IPv6. Ocurre que en mi casa no uso tunel porque tengo 6to4 configurado sobre dd-wrt y en la oficina tengo IPv6 nativo.Como sabemos los SO tienen algun tipo de inteligencia donde deciden navegar y utilizar IPv6 dependiendo de la configuracion TCP/IP del mismo, es decir dependiendo de que lo que necesite utiliza IPv6 o IPv4. Generalmente es algo como: IPv4 tiene preferencia sobre IPv6 6to4 el cual tiene preferencia sobre IPv6 Teredo.

Problema:
  Windows 7 prefiere IPv4 sobre IPv6 cuando la direccion IPv6 corresponde a un prefijo 6to4 (2002:/16). Yo quiero que prefiriera IPv6 sobre IPv4 aun con el prefijo IPv6 6to4.

Solucion:
1. Start -> Run -> "cmd" -> "netsh" -> "interface" -> "ipv6"

2. Configurar IPv6 (6to4) como el protocolo por default en Windows
set prefix ::1/128 50 0
set prefix ::/0 40 1
set prefix 2002::/16 30 1
set prefix ::/96 20 3
set prefix ::ffff:0/96 10 4
set prefix 2001::/32 5 5

3. Si queremos volver a dejar todo original (Preferencia IPv4)
set prefix ::1/128 50 0
set prefix ::/0 40 1
set prefix 2002::/16 30 2
set prefix ::/96 20 3
set prefix ::ffff:0/96 10 4
set prefix 2001::/32 5 5

Link referencial y base de este articulo:
Win7 seems to prefer IPv4 native to IPv6/6to4 - which is not what the policy table says - which is right?

lunes, 16 de enero de 2012

Instalacion de Linux en un servidor SUN Fire

A continuacion se describe el Procedimiento para la Instalacion del Sistema Operativo Debian GNU/Linux en un
Hardware Servidor SUN Fire V210. Como sabemos, este Hadrware no dispone de Tarjeta para Salida de Video
VGA ni Puerto PS2 para Teclado. Lo que si dispone es de un Puerto Serial para Management. Este Servidor tiene
una Arquitectura SPARC de 64 Bits.

A continuacion los Pasos:

1.- Descarga de la Imagen ISO.
Debemos ir al Link http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/
y descargar al menos el CD1 de la Distro Debian para Sparc64 (con el CD1 es Suficiente para la Instalacion)
Descargamos entonces el ISO: http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/debian-6.0.3-sparc-CD-1.iso
y lo quemamos en un CD Virgen con cualquier Quemador. Siempre recomiendo quemar los CDs a baja velocidad para evitar algunos inconvenientes.
Colocamos el CD de la Imagen Debian en la Unidad CD/DVD ROM del Servidor.

2.- Ahora, debemos establecer una Conexion via Serial COM con el Servidor Sun Fire V210.
Podemos utilizar Hyperterminal, Minicom o incluse Puttytel. Establecemos una Conexión con los Parametros 9600,8,n,1 (Default). El cable a utilizar es un cable tipo Rollover (NO Crossover). Tipicamente los cables de consola de los equipos Cisco van a funcionar.

3.- Arrancamos el Servidor. El Reto es lograr que haga Boot de la Unidad de CDROM.
Para ello, hacemos lo siguiente: Cuando el Servidor este Arrancando, presionamos la Secuencia 'STOP + A'.
En un Teclado Convencional, esta secuencia es la misma que 'CTRL+SHIFT+BREAK' o 'CTRL+BREAK'.
Al hacer esto, nos aparecera el PROMPT {} Ok, cuando ello suceda hacemos lo siguiente:
{}Ok printenv auto-boot        (Para ver el Estado del Flag auto-boot)
{}Ok setenv auto-boot false    (Para Setear el Flag auto-boot en False)
{}Ok reset-all    (Reiniciamos el Sistema)

4.- Cuando el Sistema Reinicie, volvemos a Presionar 'STOP + A', y al aparecer el Prompt {}Ok lo que hacemos es
indicarle que haga Boot del CDROM, asi:
{}Ok boot cdrom
A partir de este momento comenzara el Boot del Servidor desde el CDROM. Recomiendo que se coloque a
FULL SCREEN el Hyperterminal para ver la Instalacion como si fuera una Pantalla Completa.
Desde este momento, se sigue exactamente el procedimiento de Instalacion de Debian (Usuarios, Particiones, Repositorios, etc.)

Puntos Clave:
- Descargar la Imagen ISO para SPARC 64.
- La Secuencia 'STOP + A', la cual puede ser tambien 'CTRL+BRAK' o 'CTRL+SHIFT+BREAK'.
- Colocar la Pantalla en FULL Screen.
- Si en algun Momento se Pierde la Conexion Serial (suele pasar con Puttytel), simplemente Cierre y Reabra la
Conexion Serial y Teclee cualquier Tecla para recuperar la Instalacion.
- El sistema BOOTEA del CDROM cuandl estando el PROMPT {}Ok se Teclea 'boot cdrom  (Muy Importante...!!!)

- Para que el servidor arranque de manera automatica es necesario en el prompt ok escribir lo siguiente:
auto-boot?=true  
boot-device=disk
 
 

 Espero sea util.

Manual basado en documentacion de profesor Jose Gregorio Cotua

sábado, 14 de enero de 2012

Actualizar de Android 1.5 a Android 2.1 en Samsung i5700

Situacion:
  Deseo actualizar mi samsung i5700 de Android 1.5 a 2.1

Notas:
  Keis moderno no funciona en Android 1.5 en el i5700 por ello es necesario el software: Kiesmini que se consigue en: http://www.samsung.com/ca/support/download/supportDownloadMain.do. Es muy importante realizar esta tarea porque el Market de Android no funciona correctamente con Andriod 1.5

Procedimiento:
  - Desinstalar cualquier referencia en el PC que tenga software de Samsung
  - El telefono debe estar completamente cargada (el software kiesmini puede indicar que no va a realizar la operaciones porque el telefono no tiene suficiente carga
   - Remover el SIM y la memoria SD del telefono
   - Apagar GPS y bluetooth del telefono
   - Conectar via USB (Obligatoriamente USB, no Bluetooth ni wireless) el Telefono y el PC
   - Ejecutar minikies
   - En la opcion de Menu instalar el driver USB (sino se hace el telefono no será reconocido)
   - Luego de que el telefono es reconido realizar el upgrade

  En caso de error reiniciar el telefono y estar completamente seguro que el SIM Card esta removido asi como la memoria SD.

ESTE PROCEDIMIENTO LO CORRES A TU PROPIO RIESGO. NO DOY GARANTIA DE QUE FUNCIONA. REALIZA UN BACKUP ANTES DE REALIZAR EL PROCEDIMIENTO

 

martes, 22 de noviembre de 2011

Certificacion IPv6 de Hurricane Electric

  En esta oportunidad voy a dejarles mis impresiones sobre la certificacion IPv6 que tiene Hurricane Electric en http://ipv6.he.net/certification
na primera oportunidad la habia ignorado pero en esta oportunidad la curiosidad me llamo.
  Les comento que me parece muy interesante la misma; me gusta la manera como esta organizada. Les cuento un poco:

- La certificacion se puede hacer por pasos y en varios dias. Esto da bastante comodidad.
- Para cada nivel te mandan a hacer varias "tareas" tales como: Configurar un servidor Web, de Correo, DNS, prueban conectividad a equipos tuyos etc.
- Es didactica y divertida
- Logicamente para comenzar la certificacion debes estar desde una maquina IPv6
- Existen varios niveles de certificacion: Newbie, Entusiasta, Administrator, Professional, Guru, Sage. A pesar de que me agrada la idea de varios niveles, creo que los nombres le quedan grande al nivel, por ejemplo, obtener el grado de Administrator me parece sencillo y su nombre suena casi a experto.
- Te mandan una franela/remera gratis de IPv6!!!!

  Desde mi punto de vista las personas que manejen servidores y conectividad directamente tienen una enorme ventaja sobre los que no.

Consejos previos para prepararse para la certificacion:

  - Como recomendacion, antes de comentar el examen, tengan un dominio con el cual puedan trabajar, quiero decir, que puedas crear zonas, modificar registros, etc.
  - Maquina servidor (preferiblemente Linux) con conectividad a IPv6
  - Acceso y configuracion a servicios tales como Web Server y Mail Server

Mas informacion

  - La pagina para los que esten interesados es: http://ipv6.he.net/certification/
  - En este blog hay mucha informacion sobre IPv6 sobre Linux y algunos servicios como Apache y Sendmail http://acostanetwork.blogspot.com

  Saludos y suerte a los que deseen tomar la certificacion!!.    

viernes, 21 de octubre de 2011

Verificar el origen de un prefijo BGP


Historia:
  En algunas situaciones queremos estar seguros que el prefijo BGP aprendido en nuestro router sea efectivamente originado por quien debería ser. Han ocurrido ciertas eventualidades en la historia del mundo de Internetworking donde un Sistema Autonomo ha publicado redes no debidas (ej: http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study).
  Hoy en día un poco más del 10% de los prefijos asignados por los RIRs (Lacnic, RIPE, Afrinic, ARIN y APNIC) tienen asignado un ROA (Route Origin Authorization) el cual indica de manera segura quien es el sistema autonomo asignado para publicar cierto prefijo. A lo anterior se le conoce como Resource Public Key Infrastructure (RPKI) 


Problema:
  Deseo saber cual debería ser el sistema autónomo de un prefijo especifico (por ejemplo una red aprendida por BGP). 


Solución:
  Seguramente en un futuro cercano tendremos decenas de páginas Web donde podamos consultar el sistema autonomo que debería publicar cierta red (quizás hoy en día existen y yo no las conozco), en fin, nuestro buen amigo whois nunca nos falla. En esta oportunidad nos apoyaremos en el servidor whois de bgpmon.net


  Aquí les dejo los comandos y unas salidas ejemplos:
  • ROA con problemas (
    Se esperaba el AS 17NN9 y esta siendo publicado por el 79NN))
    :


aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNN.
RPKI status:         ROA validation failed: Invalid Origin ASN, expected 17NN9

  • ROA satisfactorio:

aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNNN.
RPKI status:         ROA validation successful
  • SIN ROA (en este prefijo no podremos saber que AS debería publicarlo):
aacosta@bind:~$ whois -h whois.bgpmon.net 2800:NN::0


Prefix:              2800:NN::/32
Prefix description:  
Country code:        AR
Origin AS:           79NN
Origin AS Name:      NNNNNN
RPKI status:         No ROA found



Más información:
http://acostanetwork.blogspot.com/2011/03/historico-de-tablas-bgp-hijack-de-mi.html (Histórico de tablas BGP)
https://labs.ripe.net/Members/Paul_P_/content-serving-roas-rpsl-route-objects
http://bgpmon.net/blog/?p=414

lunes, 12 de septiembre de 2011

Ejemplos de hping

Ejemplos de hping:

Enviar paquetes TCP SYN al puerto 0 en la máquina example.com (nótese que hping  incrementara el puerto origen en 1 por cada paquete enviado):
#hping example.com-S-V  


Enviar los paquetes TCP SYN al puerto 443 en el host example.com:
#hping example.com -S-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con los flags SYN + ACK encendidos en conjunto:  
#hping example.com-S-A-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con el SYN + ACK FIN + set:  
#hping example.com -S-A-F-443 V-p  

Enviar paquetes TCP SYN cada 5 segundos en el puerto 443 en el host example.com:  
#hping example.com -S-443 V-p-i 5  

Enviar paquetes TCP SYN cada 100.000 microsegundos (es decir, cada 0,1 segundos o 10 por segundo) en el puerto 443 en el host example.com. Tenga en cuenta que se ha eliminado detallado:  
#hping example.com -S-p 443-i u100000

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada 0,01 segundos, o 100 por segundo) en el puerto 443 en el host example.com:  
#hping example.com-S-p 443-i u10000  

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada segundo de 0,01 o 100 por segundo) en el puerto 443 en el host example.com. Parar después de 500 paquetes:  
#hping example.com-S-p 443-i-c u10000 500  

Enviar paquetes UDP al puerto 111 en el host example.com (argumento - udp puede ser sustituido por -2): #hping example.com - udp-V-111 p

Enviar paquetes ICMP echo request para recibir example.com (argumento - icmp puede ser sustituido por -1): 
#hping example.com - icmp-V 

Enviar ICMP paquetes de solicitud de marca de tiempo para organizar example.com:  
#hping example.com - icmp - icmp-ts-V 

 Escaneo de puertos TCP 100 a 110 en el host example.com (argumento - el examen puede ser sustituido con -8)
#hping example.com-V - scan 100-110  

Enviar paquetes UDP falsa a partir de host de origen para recibir 192.168.1.150 example.com
#hping example.com - udp - parodia 192.168.1.150  

Enviar paquetes UDP falsa a varios de IP de origen aleatoria para recibir example.com
#hping example.com - udp - rand-fuente  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes para albergar example.com
#hping example.com-V - udp - los datos de 100  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes, pero con el contenido de payload.txt para albergar example.com (la carga útil se truncará si es menor de lo especificado por el argumento - de datos) 
 #hping example.com-V - udp - payload.txt archivo - los datos de 100


Más info:
El presente documento es una traducción con una pequeña adaptación de:
http://rationallyparanoid.com/articles/hping.html  (documento sencillo y practivo que me pareció excelente)

miércoles, 7 de septiembre de 2011

Utizando Netem. Simulando escenarios de red. Ejemplos de tc/netem

Problema:
  Deseo simular algunos escenarios de red.
    a) Simular en un salto satelital
    b) Simular perdida de paquetes

  Lo anterior es de mucha utilidad porque permite probar escenarios -casi reales-. Se pueden probar aplicaciones y conocer como se comportan ante una alta tasa de pérdida de paquetes y/o ante altos tiempos de respuesta. Otra opción es conocer el comportamiento ante pérdidad y/o RTT aleatorios y muchas otras cosas.


Solución:
  Netem (Network Emulacion) que permite simular escenarios de red muy tipicos en redes WAN, MAN y Satelitales.
   Netem es controlado con el comando tc que es parte de iproute2

Ejemplos:

a)  Simular el Round Trip Time de un salto satelital (550 ms):

# tc qdisc add dev eth0 root netem delay 550ms

Fijense del tiempo del ping antes y durante el comando (salto del 10 al 11):

[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=51.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=600 ms


b) Simular una red WAN con tiempos de mayor variación (de 100 ms - 10 ms) de manera aleatoria:

# tc qdisc change dev eth0 root netem delay 100ms 10ms

64 bytes from 8.8.8.8: icmp_seq=60 ttl=53 time=49.3 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=53 time=50.5 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=53 time=59.6 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=53 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=53 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=53 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=53 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=53 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=53 time=153 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=53 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=53 time=155 ms


c) Simular perdida % de paquetes:


 # tc qdisc change dev eth0 root netem loss 0.1%

El comando anterior ocasiona una pérdida de 1/1000 paquetes descartados de manera aleatoria

Más opciones:
Existen muchas otras opciones como:
  a) Duplicar paquetes
     # tc qdisc change dev eth0 root netem duplicate 9%


  b) Corromper (dañar) un paquete:
     # tc qdisc change dev eth0 root netem corrupt 0.1%

Mas información:
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/

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