VPSs y mas.

domingo, 29 de diciembre de 2019

Retrospectiva sobre el crecimiento de IPv6 durante el 2019 en Latinoamerica y Caribe

Muy buenos días Lista, 
  Existe un refrán que estoy seguro todos conocen: “El hombre es un animal de costumbre”, por sexto diciembre consecutivo estamos entregando una retrospectiva sobre IPv6 en nuestra querida región.
  Costumbre es sinónimo de consuetudinario, es decir, estamos casi que rozando la ley en estos mensajes, espero no se me olvide el año que viene !


  Y bueno, 6to año, hablando de IPv6 tengo que intentar explayarme.


  De igual manera como he hecho en otras oportunidades, comencemos repasando el concepto de retrospectiva [1]


“Retrospectiva (del latín: retrospectare) es una enumeración y
celebración de eventos ya ocurridos, y normalmente organizada y
presentada al final del año, en algún medio de difusión (generalmente
televisión o radio), aunque también puede abarcar un período mayor del
anual.”


  Y les aseguro que al leer este concepto, no me viene a la cabeza ningún otro mejor adjetivo que pueda enmarcar lo que deseamos expresar aquí.


  Por ser 6to año y celebrando IPv6 cubriremos los TOP 6 países de nuestra región.


  Voy a indicar los 6 pasos que tomé:
  1. Ubicar los TOP 6 países de nuestra región es cada vez más sencillo, hoy en día vamos a: https://stats.labs.lacnic.net/IPv6/ipv6ranking.html 
  2. Hacemos click sobre el checkbox LACNIC
  3. Repasamos 1 a 1 cada país obtenido en el paso anterior
  4. En algunas oportunidades hacemos click en “Per ASN” correspondiente al país
  5. Listo !, a escribir


 Los TOP 6 países con su respectivo % de penetración de IPv6 en el usuario final son (para comienzos de diciembre 2019):
1 UY 38.27
2 GF 35.61
3 MX 31.96
4 BR 28.69
5 TT 20.26
6 PE 18.53



  Hablemos de cada caso:
  1. Uruguay (UY), el segundo país más chico de Sur América (luego de Surinam) dice muy presente cuando se trata de penetración de IPv6 y velocidad a Internet, es líder en ambos rubros en nuestra región, casi 40 de cada 100 uruguayos ya cuentan con IPv6 -y la velocidad promedio de bajada en el móvil es sobre los 20 Mbps-. Un gran aplauso.


  1. Guyana Francesa (GF), casa de “Le Centre Spatial Guyanais” conocido como la  Guiana Space Centre donde muchos países Europeos utilizan este centro espacial para sus lanzamientos, y algo similar hicieron con IPv6, le pusieron un cohete ! . Nuestras gráficas indican que comenzó su despliegue a comienzos de Abril 2019 y a las dos semanas tenían 20% de IPv6 y a las 5 semanas cerca de 35.61%, mientras escribimos estas líneas sigue creciendo. Nuestras felicitaciones.


  1. México (MX), conocido por muchas cosas pero entre otras por su celebración del día de los muertos, sin embargo le están diciendo al mundo que en IPv6 están muy vivos :-)   , ya habían comenzando 2019 con 24% de penetración de IPv6 y en el transcurso del 2019 tuvieron un crecimiento superior al 30%. Por cierto, también son el exportador más grande del mundo en cerveza y parece que quieren exportar IPv6.  Vamos arriba México


  1. Brasil (BR), haciendo honor a su slogan (motto) “Ordem e Progresso” (order and progress) han hecho precisamente lo mismo con IPv6. Durante el 2019 Brasil incrementó en un 10% su penetración de IPv6 llegando a 30.22%. Nada mal para el país más grande la región y 5to en el mundo. Nuestros respetos.


  1. Trinidad y Tobago (TT), cuna del instrumento musical “Steel Pan” (tambores metálicos), digno representante caribeño en despliegue IPv6 implementa el protocolo con buen ritmo para no quedarse atrás. TT se posiciona en 5ta posición en la región ofreciendo IPv6 a 1 Trinitario cada 5 personas, creo que quieren correr a la velocidad de Hasely Crawford (el Usain Bolt Trinitario en 1976)


  1. Perú (PE), lo primero que se me viene a la cabeza es su gastronomía, Machu Picchu y los Inca, pero solo quiero decir que su despliegue IPv6 es casi tan alto como su famoso lago Titicaca, el más alto del mundo. Perú desde hace varios años es icono de despliegue de IPv6 en la región y nos contenta mucho verlos aún como líderes en este rubro. Para el momento que se escribe estas líneas, el país cuenta con un poco más de 18% de penetración de IPv6.  Que continúen el despliegue con un Pisco sour :-)


¿Y el promedio de Latam?
Ya hace un año explicamos que anteriormente en LACNIC publicabamos un promedio simple (media aritmética) del promedio IPv6 en nuestra región. Hoy en día estamos publicando una *media aritmética ponderada* en base a la población de los países, población de LAC y grado de penetración de IPv6 en el país, esto nos lleva a un valor más real de usuarios de Internet con IPv6 en nuestra región.  
La penetración de IPv6 en el usuario final en LATAM está en 19.50%, un número nada mal pero aún por debajo de la media mundial (29%) [2]. Recordemos que país que no implemente IPv6 corre el riesgo de quedarse aislado. Vamos LAC !!



¿Alguna mala noticia en el 2019?
Lastimosamente tenemos una pero mejor que el año pasado.
Una de las mediciones que hacemos en LACNIC es ubicar sitios Web con ccTLDs de nuestra región e identificar si tienen IPv6, posteriormente estudiamos si estos sitios apuntan a una dirección IP asignada por LACNIC [7].
En el 2017 teníamos que el 33.9% de estos sitios con IPv6 apuntaban a direcciones asignadas por LACNIC. Para el diciembre del 2018 solo 19%. Interesantemente este 2019 volvimos a 33.2% de sitios Web en LAC que apuntan a direcciones IP asignadas por LACNIC.
Esperemos que para el 2020 este valor aumente, si se puede !.




Pronóstico para el año que viene.
Realizar pronósticos siempre ha sido algo muy complicado, creo que nosotros como personas de ciencia nos basamos más en hechos reales, en números. Sin embargo equivocarse con IPv6 hasta cierto punto no es difícil, IPv6 seguirá creciendo, el despliegue aumentará en nuestra región. Un hecho que pienso que está ocurriendo es que ya los clientes están atentos de saber si el ISP soporta IPv6, en caso negativo buscan otro ISP y listo, ahora todos los países ya cuentan con proveedores con IPv6. El tema de los túneles ya viene en bajada desde hace muchos años, habiendo dicho eso comienza una etapa verdadera de pérdida de clientes si el proveedor no ofrece IPv6. Una vez más veremos crecimiento en redes IPv6 Only tales como Data Centers.



 Reciban un fuerte abrazo,




Alejandro Acosta,
@ITandNetworking



miércoles, 4 de diciembre de 2019

Python3: Una solucion a UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)

Situación:

  Al ejecutar un script en python3 se recibe un error similar a:


UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)


Solución:

  El problema viene dado (tal como lo explica el mensaje) por manejo de strings y unicode, muy seguramente el código contiene algún tipo de carácteres en  
español, portugués, árabe u otro idioma no cubierto por ASCII

  Si lees en Internet hay DECENAS de maneras de solucionar esto, yo solo voy a mencionar una que funciona y es MUY sencilla.

  Si te encuentras en Linux o MAC es tan sencillo como colocar esto antes de ejecutar tu script (dentro de bash):




export PYTHONIOENCODING=utf8


  Lo que se esta haciendo es declarar la variable de entorno PYTHONIOENCODING a utf8, python3 al ser ejecutado utilizará esta variable como encoding y tu problema será resuelto.

  Claro, pudieses colocar dicha variable al entrar a tu sesión, o dentro de un script en bash que posteriormente llame a tu .py, etc, etc.

Suerte, espero haya sido útil.

 

jueves, 31 de octubre de 2019

Una mirada al uso de BGP AS_SET en la DFZ

Introducción:
   Como algunos de ustedes saben, en BGP existe un argumento llamado AS-SET, en muchas nomenclaturas lo conseguiremos como route-aggregation.

¿Qué es BGP AS-SET?
  El AS-SET en pocas palabras lo que permite es agregar/sumarizar varias rutas en un prefijo más grande. Como muchas cosas, tiene ventajas (reducir el tamaño de la tabla global BGP) y además tiene inconvenientes (prevenir loops y validación de origen RPKI).

¿Por qué el estudio?
  Para el momento que se escriben estas líneas (Octubre 2019), en IETF existe un draft (que pensamos se convertirá en estándar) donde se propone que AS-SET pase a ser obsoleto. El draft puede se conseguido en: https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/?include_text=1

  Si este draft pase a ser RFC eventualmente los fabricantes van a dejar de soportar AS-SET y puede existir (pero no pensamos que ocurra) algún riesgo de perder algunos prefijos & ASs en la tabla global

Origen de la data para el presente estudio
Se utilizó las tablas BGP de Potaroo.net. Se pueden obtener en: 
  IPv4: http://bgp.potaroo.net/as2.0/bgptable.txt

Para la información sobre los recursos se utilizó los APIs de RIPE. 

Fecha del estudio
  Mes de Octubre de 2019

Estudios realizados 
  1. Buscar AS que hagan AS_SET
  2. Buscar prefijos que sean sometidos a AS_SET

¿Cómo se identifica un AS-SET en la tabla BGP?
  Identificar AS-SET puede variar según el vendor/fabricante del software que realiza BGP.
  Para el presente estudio utilizamos la tabla BGP publicada por Potaroo.net, la misma es una salida BGP del comando “show ip bgp” de Cisco.
  En la salida del comando se puede apreciar líneas similares a:

* i2001:QWER::/32    QWER:300::6     0 152 0 65412 65001 {65002,65003} 

  La salida anterior se puede leer:
  1. AS 65002 realiza al menos un anuncio BGP
  2. AS 65003 realiza al menos un anuncio BGP
  3. AS 65001 Realiza AS-SET y anuncia el prefijo 2001:cd8::/32 (una supernet de los prefijos recibidos por 65002 y 65002)
  4. 65412 hace tránsito a los AS anteriores sin embargo no es relevante para este estudio

   Gracias a las llaves ( { } ) es sencillo ubicar quien hace el AS-SET 


Resultados generales:

Tabla #1 Resumen General


IPv4
IPv6
Prefijos en la tabla
803999
77438
Prefijos sometidos a AS-SET
387
26
ASs únicos haciendo AS-SET
128
20
ASs haciendo AS-SET en IPv4 e IPv6
7
7





Resultados específicos por RIR:



IPv4
IPv6
  RIPE ASs
52
9
  RIPE Prefijos  
111
9
  ARIN ASs
50
5
  ARIN Prefijos
127
10
  APNIC ASs  
11
4
  APNIC Prefijos
46
8
  AFRINIC ASs
1
0
  AFRINIC Prefijos
7
0
  LACNIC ASs
14
2
  LACNIC Prefijos
96
7




Colocando la lupa sobre LACNIC

Datos específicos sobre LACNIC (IPv4):

Resumen:
.- 96 prefijos únicos a los cuales se les hace AS-SET
.- Existen prefijos de LACNIC anunciados por ASs de RIPE, ARIN y LACNIC
.- Se consiguió un AS de LACNIC que realiza AS-SET de prefijos de ARIN
.- Conseguimos 14 ASs haciendo AS-SET


Datos específicos sobre LACNIC (IPv6):

Resumen:
  • Se obtuvieron 7 prefijos
  • 2 AS diferentes que se consiguieron haciendo AS-SET
  • Hubo un caso interesante donde el mismo prefijo se le hace AS-SET desde 2 ASs diferentes y además uno es de LACNIC y el otro de RIPE
  • Prefijos de LACNIC son anunciados por ASs de LACNIC, RIPE y/o ARIN
  • ASs de LACNIC no hacen AS-SET de prefijos no-LACNIC 



Referencias:

jueves, 10 de octubre de 2019

Configurando una sesión BGP entre dos loopbacks con IPv6 - ebgp multihop y captura de wireshark

En el video se muestra como configurar una sesión BGP entre dos enrutadores Cisco IOS. Se realiza con ebgp multihop y se muestra captura de paquetes con Wireshark


jueves, 4 de julio de 2019

Por fin, RRL en BIND por defecto - con ejemplo

Historia

Al parecer este es un post que tuve que haber hecho hace mucho, sin embargo hoy recién es que lo veo funcionando correctamente


Introducción

Si el lector se parece un poco a mí, quizás sea de esas personas que tiene MUCHOS años esperando el soporte de Response Rate Limiting en Bind9. Buenas noticias!, ya existe !.


¿Qué es RRL en DNS?

RRL se refiere a Response Rate Limit. De una manera resumida es una técnica para minimizar ataques de amplificación que son muy comunes en el mundo de DNS. Hoy en día es muy recomendado en servidores autoritativos pero puede servir en recursivos.


Situación


Deseo instalar Bind9 vía apt (apt-get) y tener soporte de RRL (Response Rate Limiting). Algo que me extraña es que en teoría debería tener soporte por defecto luego del 9.10, sin embargo verán que este ejemplo está en 9.9.5)


Pasos:


El día de hoy, con Ubuntu 14.04 (si, bastante viejo) hice un upgrade de Bind9, probé RRL y todo anduvo perfecto. 

1) Actualizar bind9
   apt-get –only-upgrade install bind9
2) Chequeo la versión:
   root@my:~/SCRIPTS# apt-cache policy bind9
      bind9:
      Installed: 1:9.9.5.dfsg-3ubuntu0.19


3) Configurar RRL en bind9. Un sencillo ejemplo:


   rate-limit {
      responses-per-second 1;
   };



(favor notar que puse "1".., solo para probar que el feature realmente sirva)
4) Reiniciar bind vía rndc o el servicio (service bin9 restart)


   #service bind9 restart

Comprobar

Debido a que dejamos una sola consulta por segundo, es tan sencillo como ir a otro equipo, tener varios terminales abiertos y hacer muchos dig simultáneamente de algún dominio/zona autorizada. Si todo sale bien, en el log verás algo como:


Jul 4 11:47:55 my named[8317]: limit responses to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:55 my named[8317]: client 10.112.225.51#11257 (exp.example.com): rate limit slip response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:56 my named[8317]: client 10.112.225.51#7921 (exp.example.com): rate limit drop response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Mas info:
https://kb.isc.org/docs/aa-00994
https://whatis.techtarget.com/definition/DNS-amplification-attack