viernes, 8 de junio de 2012

10a. Edición FLIP6. LACNIC XVII. QUITO - ECUADOR RESUMEN


Hola todos,
Es un placer para mi escribir en esta oportunidad y contarles mis
impresiones de la 10a. edición del FLIP6 (Foro Latino Americano de
IPv6) en la ciudad de Quito - Ecuador durante los días 6-7 de Mayo de
2012.

Debo reconocer que al comienzo estaba preocupado por el desafío, pero
una vez finalizado el evento, he quedado sumamente satisfecho y con
muchísimo entusiasmo para seguir trabajando por la difusión de IPv6 en
Latinoamérica y Caribe.

El evento tuvo una duración de 7 horas divididos en dos días, contando
con una asistencia de unas 400 personas en total, que se apreciaba con
el lleno en todo momento del salón. Un aspecto significativo que
muestra la calidad alcanzada por el FLIP6 es el hecho de que luego de
los horarios previstos de finalización de la actividad la gente
continuaba en la sala, un claro indicador del interés en la temática
de IPv6 y a su vez de la calidad de los ponentes. Otro hecho
importante fueron la cantidad de preguntas realizadas por diferentes
asistentes, incluso a la hora que se debía finalizar la actividad. No
menos importante fue el alto porcentaje de participantes remotos vía
Webcasting (sobre las 50 personas en cada dia de evento FLIP).

Lo anterior estuvo acompañado por una gran difusión vía Twitter,
Facebooks y listas de correo. Ejemplo de ello es un mensaje en Twitter
que decía algo como “IPv6 es la estrella de LACNIC XVII”.

En líneas generales, me atrevo asegurar que todo funcionó
correctamente, con muy buenas y claras presentaciones, expositores de
muy alta calidad.

Una mención especial al comité evaluador LACTF quienes tuvieron la
importante labor de seleccionar los trabajos presentados en la 10a.
edición del FLIP6.

A continuación un breve resumen de cada una de las ponencias:

Fernando Gont - First Hop Security in IPv6:
Fernando expuso sobre uno de los factores de seguridad a considerar al
momento de implementar IPv6. Parte de la labor de LACTF es también
apoyar no solo la difusión de IPv6, sino también la implementación de
IPv6 bien realizada. Gracias por insistir en la seguridad de redes.

Augusto Espín (Vice-Ministro MINTEL Ecuador) - IPv6 en Ecuador
           El Ing Augusto Espín habló sobre el estado de IPv6 en
Ecuador, ¿por qué?, retos, tiempos y otros temas muy interesantes del
sector gobierno en cuanto a IPv6. Esperamos ver más avances en futuros
FLIPs.

Antonio Moreiras (NIC.br) - Resumen semana IPv6:
           Antonio nos ofreció un resumen de los resultados de la
semana IPv6 acontecida en Febrero de 2012 en Brasil, muy buenos sus
resultados. Felicitaciones y que sigan más iniciativas de este estilo.

Carlos Egas (Escuela Politécnica Nacional de Quito) - Estudio y
análisis del estado actual de la implementación de IPv6 en los
proveedores de servicios de Internet en Ecuador
          El Ing Carlos nos presentó estadísticas muy interesantes y
reveladores sobre el estado de los ISPs en Ecuador. Muy valiosos
resultados, gracias por compartirlos.

Antonio Moreiras (NIC.br) - RIPE 501:
           Antonio Moreiras nuevamente expuso pero esta vez sobre un
muy importante documento que está realizando nuestros amigos de RIPE,
muy importante conocer esta información para todos.

Jordi Palet (Consulintel/6Deploy) - IPv6 en gobiernos y resultados:
           Jordi, con su acostumbrado estilo de enseñar y transmitir
información brindó un rápido repaso pero muy importante sobre los
avances en la implementación en algunos países y gobiernos. Mil
gracias por compartir esta información con nosotros. Te esperamos para
compartas nuevos avances.

Dr. Rafael Sandoval (Asesor MINTIC) - IPv6 en Colombia:
           El Dr Rafael Sandoval resumió brevemente el estado de IPv6
en Colombia, ¿por qué?, planes e información concernientes a los
próximos pasos del gobierno Colombiano en cuanto a la implementación
de IPv6 en el país del vallenato y de la cumbia. Ojalá tengamos la
oportunidad de conocer los avances en los próximos meses y/o años.

Marcus Grando (Terra Networks Brasil) - Experiencia de Terra en IPv6
           El Ing Marcus hizo una exposición muy buena exponiendo
ambos sabores (lo bueno y lo malo) al momento de implementar IPv6 en
Terra. ¡Mucha suerte para los Juegos Olímpicos!

Arturo Servín (LACNIC) - Los 7 pecados capitales al implementar IPv6
           Arturo Servin hizo una inusual presentación realizando una
analogía entre los pecados capitales y los posibles errores en IPv6.
¡Muchas gracias por una presentación tan agradable!

 Y por supuesto, no podemos dejar a un lado a nuestros invitados:

Invitado especial: Cameron Byrne de T-Mobile con “IPv6-only services:
a mobile provider's perspective”
           Cameron Byrne expuso de una manera muy sencilla su
experiencia en cuanto a la implementación de IPv6 en T-Mobile. Cómo lo
obtuvieron con cero Capex, qué esperan ellos en el futuro y por qué lo
realizaron. Gracias por compartir tu experiencia.


Keynote:  Fred Baker de Cisco Systems con “Bringing up IPv6 and taking
down IPv4”
           El Keynote de FLIP fue el Ing. Fred Baker quien ostenta un
largo y destacado CV por lo que solo solo voy a señalar que ha sido
Chair de la IETF y actualmente es chair del v6ops WG de la IETF. Su
presentación, muy enriquecedora, nos mostró un escenario futurista,
cuando IPv6 pueda ser considerado más importante que IPv4. Un
agradecimiento enorme a Fred por su excelente ponencia.


En definitiva, espero no se pierdan la próxima edición del FLIP6 el
año que viene que seguramente estará cargado de muchas nuevas ideas e
información.

Para finalizar una pequeña cita para que siga la evolución informática
y con ello IPv6:

 “No temo a los ordenadores; lo que temo es quedarme sin ellos”
— Isaac Asimov



Att.
Alejandro Acosta
Moderador LACTF/FLIP6 2012
http://blog.acostasite.com
Twitter: @lactf

jueves, 7 de junio de 2012

El mejor telefono celular!!. Combinando lo mejor de Android, Blackberry y Symbian

Hola,
  En este post deseo plasmar mi humilde opinion luego de haber tenido telefonos Android, Blackberry y Symbian. Lo que quiero indicar son algunas cosas que he visto en los equipos que creo que son negativas, otras regulares y otras muy buenas.
  Uno como usuario a veces suen'a con el telefono perfecto. No dudo que muchas de las cosas que menciono ustedes no las compartan, quizas tienen otras en mente, quizas consiguieron solucion a alguna a la cual yo hago mencion.
  En fin, esta es mi lista, ojala algunos fabricantes las lean y piensen en todo ello.

1) Me parece sumamente bueno que los Blackberry y los Android (al menos el Samsung) se cargue la bateria cuando esta conectado via USB al computador, lastima que el Nokia con Symbian no lo hace.

2) Luego de mucho buscar, no consegui la manera de que Android se bloqueara de tal manera que si introducias 10 veces la clave erronea formateara el dispositivo

3) Cuando logre que se bloqueara el Android, lamentablemente era condicionado al apagarse la pantalla, me parece conveniente que sean funciones diferentes.

4) Me parece muy malo que el Blackberry pida usuario y clave cada vez que se quiere usar el App World. La tienda de Nokia y Android son muy buenas.

5) Es pesima la idea que en Blackberry cuando uno quiere enviar un correo trae el directorio completo, incluso de los contactos sin email registrado

6) De igual manera que el punto anterior Blackberry trae todos los contactos cuando se quiere enviar un SMS, incluso si el contacto no tiene numero telefonico registrado

7) Muy malo que Blackberry no tenga aplicacion para convertir el telefono en un Access Point

8) Muy malo que para convertir el Android en Access Point hay que seguir primero el procedimiento de conseguir accesso root

9) Excelente la aplicacion JoikuSpot en Symbian para convertir el Nokia en un AP.

10) Muy malo que en Android y en Blackberry el telefono lee el correo todo el dia, todos los dias.

11) Que bueno que en Symbian (incluso en Mail for Exchange) se puede escoger el horario e incluso dias que uno desee que sincronice el correo. Incluso se puede indicar la periocidad de la tarea (cada 15 min, 30 min, 1 hora, 4 horas, 12 horas y hasta manual)

12) En Symbian se puede indicar que si el grado de la bateria ha llegado a cierto limite no utilice las funciones de email. En mi caso si la bateria llega a 20% deja de sincronizar el correo.

13) La integracion del Android con los email populares es sumamente buena, ni se diga con gmail!!

14) La integracion de las aplicaciones en Blackberry es sumamente buena, la manera como un SMS se puede enviar por PIN, Whatapp, email, etc es increible. Incluso en Twitter y en Facebook

15) La integracion de funciones copy/paste son muy buenas en Symbian, regulares en Android y malas en Blackberry

16) El Bluetooth del Blackberry es muy malo, casi nunca me sirve cuando deseo enviar fotos entre dispositivos Bluetooth

17) Me parece fantastico el indicador del blackberry, mientras se carga tu puedes saber el nivel de la carga. En Nokia el indicador de bateria se "llena" y "vacio" y tu no tienes idea del nivel de la bateria.
 
18) Es fantastico que en Nokia el bloqueo con clave viene en dos fases, primero se bloquea el teclaro y posteriomente es que es necesaria la clave para desbloquearlo. En Blackberry si lo proteges con clave siempre es necesaria para desbloquear el equipo. Con ello quiero decir que Symbiam el primer bloqueo es solo teclado.

19) Es increiblemente subdesarrollado (por colocar un adjetivo) que el Blackberry no sincronice elementos enviados.

------
Saludos, probablemente en un futuro estare agregando otras cosas a esta lista. Son bien recibidos tus comentarios.



lunes, 28 de mayo de 2012

Inter-VLAN Bridging. Bridge entre dos VLANs. Cisco

Hola,
  El día de hoy tuve la necesidad de unir dos VLANs que me estaban entregando dos proveedores Metroethernet, para esta solución puede ser que exista más de una solución y/o una solución diferente. Les dejo la que me funcionó a mi:

  Escenario:
- Proveedor A: VLAN 10
- Proveedor B: VLAN 25
- Subnet de prueba: 10.22.1.176/29
- Ambas proveedores llegan a un LAN Switch Cisco
- El Inter-VLAN Bridging se hace un router Cisco 7200

  Topología:

  LAN Switch Cisco ---- (vlan 10) Proveedor A
                                  |-- (vlan 25) Proveedor B
                                  | -- (vlan trunk) Cisco Router


  Solución:

a) Paso 1:
   Para al topología planteada -quizás no es necesario en otra topología- es importante manejar Trunking entre el LAN Switch y el Router Cisco. Incluso, el LAN Switch puede manejar correctamente trunking hace el proveedor A y B sin afectar el funcionamiento de esta solución.

Lado del LAN Switch



interface FastEthernet0/3
 description Hacia Router cisco
 switchport mode trunk
end


Lado Router:



interface GigabitEthernet0/1
 no ip address
 media-type rj45
 speed auto
 duplex auto
 negotiation auto
end

interface GigabitEthernet0/1.10
 description  Hacia Proveedor A
 encapsulation dot1Q 10
end

interface GigabitEthernet0/1.25
 description  Hacia Proveedor B
 encapsulation dot1Q 25
end


b) Paso 2:

   Ahora bien, los comandos que hacen "la magia" del Bridging entre las dos VLANs son - SOLO DEL LADO DEL ROUTER -:


!START HERE


bridge irb


interface BVI1

 ip address 10.22.1.179 255.255.255.248
!



interface GigabitEthernet0/1.10
 description  Hacia Proveedor A
 encapsulation dot1Q 10
 bridge-group 1
end

interface GigabitEthernet0/1.25
 description  Hacia Proveedor B
 encapsulation dot1Q 25
 bridge-group 1
end


bridge 1 protocol ieee
bridge 1 route ip


!END HERE


  La única limitante (son en algunos escenarios) que puedo apreciar en la configuración anterior es aquella donde el proveedor no permita configurar alguna dirección IP en el router Cisco. Notese que en el ejemplo existe una interfaz virtual BVI (Bridge Group Virtual Interface) la cual es una subred utilizada dentro de las VLANs (VID 10 y VID 25)


Espero sea de alguna utilidad para alguien,


Más información:
Understanding Issues Related to Inter-VLAN Bridging
Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature



sábado, 26 de mayo de 2012

Como instalar un root server local (DNS).

Hola,
  Recientemente en algunas listas de discusión que sigo se hablaba sobre instalar un servidor DNS root server local, en fin, me llamó la curiosidad y lo hice solo por razones académicas.
  He escuchado que esto de alguna manera puede mejorar el performance de alguna red, sobre todo en el mundo de los ISPs, sin embargo, en lo personal no lo veo necesario, lo dejo al criterio de cada uno de ustedes.
 
Laboratorio:
  - Dos servidores y un cliente: Un servidor con Ubuntu, otro con Mandriva, el cliente también fue Mandriva. Donde:
    * Servidor Mandriva como Root Server (Nombre Z, IP=192.168.127.68)
    * Servidor Ubuntu como Servidor DNS recursivo (IP=192.168.127.86)

Primero:
    1) Logicamente probar que el servidor recursivo funcione correctamente
    2) Posteriormente, editar el archivo db.root de Ubuntu y dejar algo similar a:


;
.                        3600000  IN  NS    Z.ROOT-SERVERS.NET.
Z.ROOT-SERVERS.NET.      3600000      A     192.168.127.68
; End of File

  Notese que realmente lo que hice fue eliminar los root servers tradicionales y agregar las lineas correspondientes a Z.ROOT-SERVERS.NET (Z es el nombre del mi root server y 192.168.127.68 es la dirección). 
  Logicamente sin haber más hints de root server, el servidor recursivo se verá forzado a utilizar Z como root server.

Nota:
  En /var/log/syslog luego de reiniciar BIND puedes conseguir una línea similar a la siguiente:
May 25 19:05:16 ubuntu named[4953]: checkhints: extra NS 'Z.ROOT-SERVERS.NET' in hints

Segundo:
  Aqui es donde realmente instalamos el root server en el servidor Mandriva (que realmente es muy sencillo).
  1) Bajar el archivo root.zone de: http://www.iana.org/about/popular-links/
  2) En el archivo /etc/named.conf del root server hay que modificar el siguiente renglón:

  zone "." {
        type hint;
        file "/etc/bind/db.root";
};

  Por:

zone "." {
        type master;
        file "/etc/bind/root.zone";
};

 El archivo root.zone debe estar ubicado en el directorio correspondiente, en mi caso fue en /var/lib/named/var/named/, posteriormente hay que reiniciar y ya. En el root server ni siquiera hay que estar pendiente de recursividad y esas cosas porque este tipo de servidor tradionalmente no debe ni necesita hacer esta operación.

Tercero:
  Probar desde el cliente:

[root@localhost ~]# dig blog.acostasite.com

; <<>> DiG 9.8.0-P4 <<>> blog.acostasite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26771
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;blog.acostasite.com.           IN      A

;; ANSWER SECTION:
blog.acostasite.com.    0       IN      CNAME   cf-protected-blog.acostasite.com.
cf-protected-blog.acostasite.com. 300 IN A      108.162.198.198
cf-protected-blog.acostasite.com. 300 IN A      108.162.195.100

;; AUTHORITY SECTION:
acostasite.com.         172800  IN      NS      bob.ns.cloudflare.com.
acostasite.com.         172800  IN      NS      leah.ns.cloudflare.com.

;; Query time: 199 msec
;; SERVER: 192.168.127.86#53(192.168.127.86)
;; WHEN: Fri May 25 19:34:24 2012
;; MSG SIZE  rcvd: 152


Mas información:


  Espero haya sigo útil.





   

martes, 22 de mayo de 2012

cannot connect to X server despues de hacer SSH

Hola,
  Este es un post sumamente corto y espero que sea útil para alguien.

Problema:
  Luego de hacer SSH al momento de intentar ejecutar una aplicación que necesite X se recibe el mensaje "cannot connect to X server".
 
Solucion:
   Editar el archivo /etc/ssh/ssh_config  y ubicar la linea que indica:


#   ForwardX11no

y cambiarla por

   ForwardX11  yes

   Listo!, no es necesario reiniciar nada, solo realiza nuevamente el ssh y ejecuta tu aplicación X.


Espero sea útil,

Suerte,





jueves, 26 de abril de 2012

Completar el nombre de dominio en Linux

Introduccion:

  Este es un post muy corto, sencillo pero muy útil.

  El dia de hoy un amigo mio me preguntó como hacía para que su estación Linux completara el FQDN al momento de resolver un nombre, por ejemplo el quería escribir www y que su estación con linux buscara www.acostasite.com

Solución:
  La solución es sumamente sencilla, lo unico que hay que hacer es editar el archivo /etc/resolv.conf y colocar el parametro domain dentro del mismo. Recordemos que este archivo es donde se especifican los servidores DNS que utilizará Linux
  Por ejemplo, supongamos que yo deseo hacer ping a host blog dentro de blog.acostasite.com:

1) En /etc/resolv.conf debe haber algo como:


nameserver 8.8.8.8
domain acostasite.com

2) Posteriormente con solo hacer referencia a blog dentro un shell o en cualquier sitio del OS el mismo OS intentará ubicar el host blog, sino lo consigue colocará de manera automatica el sufijo acostasite.com

Ejemplo de la salida:

[root@localhost ~]# ping blog -n
PING cf-protected-blog.acostasite.com (173.245.61.138) 56(84) bytes of data.
64 bytes from 173.245.61.138: icmp_req=1 ttl=57 time=135 ms
64 bytes from 173.245.61.138: icmp_req=2 ttl=57 time=136 ms
64 bytes from 173.245.61.138: icmp_req=3 ttl=57 time=135 ms
64 bytes from 173.245.61.138: icmp_req=4 ttl=57 time=135 ms


Notese que en el ping yo solo escribí "blog" y el OS completó automaticamente acostasite.com (la opción "-n" solo evita el rdns de la respuesta)


Eso es todo!, espero sea útil,



martes, 17 de abril de 2012

Como deshabilitar IPv6 en Mandriva & RedHat

Situación:
  Deseo deshabilitar IPv6 en mi distribución Linux

Solución:
  Hay dos soluciones que pueden ser implementadas:
  • OPCION 1: Deshabilitar IPv6 solo en una interfaz en especifico
   a) Editar el archivo: /etc/sysconfig/network-scripts/ifcfg-
   b) Al final del mismo colocar: IPV6INIT=no

  Luego subir y bajar la interfaz, por ejemplo:
   c) #ifdown eth0; #ifup eth0

  • OPCION 2: Deshabilitar IPv6 en todo el sistema operativos
    a) Editar /etc/modprobe.conf y agregar:

      alias ipv6 off
      alias net-pf-10 off
      options ipv6 disable=1


     b) Editar el archivo /etc/sysconfig/network y agregar:
     NETWORKING_IPV6=no

  Reiniciar todo lo relacionado con networking (por ejemplo con /etc/rc.d/network restart)

Espero haya sido útil,

Solución a: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Problema:   Containerlab devuelve un error similar: Error: eth0 interface name is not allowed for R2 node when network mode is not set to no...