Hola,
Si estas en tu MAC y recibes el siguiente mensaje al conectar un dispositivo USB: "no se puede abrir porque no se encuentra el elemento original" tristemente debes reiniciar el equipo con el dispositivo conectado.
Si, me parece super mal..., pero al menos funciona.
Referencia:
https://communities.apple.com/es/thread/160036481
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
sábado, 30 de diciembre de 2017
viernes, 22 de diciembre de 2017
Retrospectiva de crecimiento IPv6 durante el 2017 en LAC
Hola de nuevo,
Este es un post que ya se ha venido convirtiendo en tradición en los últimos años. Básicamente lo que busco es realizar un resumen de cambios relevantes de IPv6 para algunos países de la región. Les prometo me gustaría mencionarlos a todos pero es imposible !
En esta oportunidad voy a comenzar recordando 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.”
Adicionalmente deseo dar continuidad a una frase que utilicé el año pasado para este mismo artículo el cual se lee:
“Volviendo a la retrospectiva, creo que 2016 marcó un hito importante en cuanto al crecimiento del protocolo. Quiero decir, ya no hay vuelta atrás. Si algunos aún pensaban que IPv6 era bueno, era malo, le faltaba seguridad, robustez, todas las anteriores.., pueden tener razón :-) pero aún así su despliegue lo considero imparable.“
Debo decir con toda seriedad que mantengo esas mismas palabras. En el 2017 vimos un crecimiento en Latam bastante alto impulsado por diferentes países y por muchos proveedores. Algo diferente a lo apreciado en años anteriores
¿Que ha pasado con los países de LAC durante el 2017? [2]
Uruguay
Comienzo con este país porque lo realizado en el 2017 no tiene comparación. Siendo un país de 3.5 mm de habitantes y de 176.000 km2 su grado de penetración de IPv6 en este momento es de 30% (comenzó el año en 0%). Si revisamos el ranking mundial de penetración de IPv6, UY está de 5ta posición, y lo mejor aún, con un franco crecimiento que no parece cambiar en el corto plazo. ¡ Vamos arriba UY !.
Argentina
Seguimos en el sur. Los indicadores de Argentina tuvieron sus primeros movimientos a mediados del 2016, sin embargo hay que notar que este año duplicaron su grado de penetración de IPv6 en el usuario final, comenzaron el año con menos de 2% y finalizan con más de 6%. ¡ Felicitaciones!
Perú
Hubo una época que hablar de IPv6 en Latam era casi hablar de Perú, por varios años este país fue un icono en la región. Estuvo quieto por un tiempo y a mediados de este año se les vió otro repunte.., al menos dos operadores adicionales están trabajando con v6 lo que hizo aumentar la penetración de v6 en el usuario final de 15 % a 20%. ¡Que alegría Perú!
Brasil
No podemos terminar este artículo sin mencionar al gigante de la región, un país de más de 8.000.000 km2 y de > de 200.000.000 de habitantes. Lo interesante de IPv6 y BR es la gran cantidad de distintos actores que están moviendo la aguja. Comenzaron el año con aproximadamente 11% de IPv6 en el usuario final y están terminando con más de 22%. Un gran salto para un gran país. ¡Moito bem feito!
¿Y el promedio para todo LATAM?
El 1 de Enero de 2017 el promedio de acceso IPv6 en LATAM fue de 2.26 %, hoy en día está sobre 4.27%. Esto representa un crecimiento de 94%..., 24 puntos por arriba de lo que fue en el 2016. Cuando veo estos números siempre pienso que las personas que tengan servicios hacia al cliente en Internet tienen que considerar la gran cantidad de potenciales visitantes/usuarios en v6.
¿Y sobre el mundo de contenido/servidores?
El 2017 fue un año muy bueno en este sentido, sobre todo en el segundo semestre escuchamos de varios operadores que desplegaron IPv6 en sus Data Centers, proveedores de hosting colocaron registros AAAA en los DNS apuntando a servidores Web. Varios miles de dominios en nuestra región fueron habilitados con IPv6 en el año 2017. Creo que no podemos pedir más, solo fueron buenas noticias.
¿Qué esperar para el 2018?
No soy pitoniso pero no creo que sea muy difícil pronosticar el 2018, creo que veremos gran cantidad de operadores desplegando IPv6, veremos más IPv6 en el usuario final. Las estadísticas de acceso seguirán con un crecimiento constante y estable. Creo que tendremos un repunte también en la parte de contenido IPv6 en nuestra región, confiamos que muchos proveedores y Data Centers habilitarán IPv6 en el corto/mediano plazo.
Reciban un fuerte abrazo,
#Referencias
jueves, 14 de diciembre de 2017
Comprobado: Santa Claus SI tiene IPv6
Buenas noches,
El día de hoy me he dado cuenta que Santa (Papa Noel) SI tiene IPv6, más específicamente tiene Doble Pila (IPv4 & IPv6). Lo anterior lo digo porque indiscutiblemente Santa le llega a casi todo el mundo, sobre todo a los que tienen Internet.
Lo anterior lo digo porque no me cabe la menor duda de la ventaja de IPv6 para Santa, es la mejor forma de contactar a sus colegas en los países industrializados [1] donde absolutamente todos tienen cierto hasta bastante grado de penetración de IPv6, comenzando por Alemania con 33%, USA con 32%, Brasil, India y Francia con 21%, 23% y 22% respectivamente. Imaginense a Santa intentando comunicarse con esos países para pedir millones de regalos usando IPv4, sencillamente sería imposible. Bien por estos países que se pusieron las pilas y obtuvieron un super cliente.
Ahh, también quería contarles que me he dado cuenta lo difícil que es “perseguir virtualmente” a Santa, todos sabemos que vive en el Polo Norte, sin embargo gracias al uso de IPv6, la vasta cantidad de direcciones, el uso de direcciones IP de privacidad, no al uso de EUI-64 en las globales, quizás hasta un horroroso NAT66 me ha hecho imposible seguirlo cómodamente. Por cierto, he intentado de todo, publicidad, spam, cookies, cross site scripting, objetos embebidos y nada, definitivamente IPv6 si aumenta la privacidad. Bien por Santa !!
Luego estuve pensando sobre los renos, el trineo y el tiempo de llevar las cosas alrededor del mundo.., creo que el concepto de Santa para movilizarse a través de los agujeros espacio - temporales [2] son propensos a fallas en IPv4.., con IPv6 y un NAT66 Stateless 1-1 (NPT) si funcionaría la cosa.
Para los que no crean los agujeros espacio - temporales y apoyen más la teoría de de las nubes de relatividad [2] una vez más IPv6 es la respuesta…, para muestra un botón, todas las nubes hoy en día están en v6.
Y finalmente, si no creen en ninguna de las dos anteriores, son los que apoyan la física cuántica [nuevamente 2], la explicación -mi favorita- es más sencilla aún: Santa debe tener una red de Elfos [3 ] anycasteados en todo el mundo lo que facilita su vida y puede entregar los regalos desde allí a las casas más cercanas, esta red seguro es Dual Stack, no podemos olvidarnos de los niños que tienen IPv4 por culpa que su ISP no le pone voluntad para poner IPv6. Pobres niños.
En base a todo lo anterior, el despliegue de IPv6 es una muy buena noticia para Santa y más aún para los niños!!!.
Un fuerte abrazo y feliz navidad para todos.
Alejandro Acosta
@ITandNetworking
@LACNICLabs
viernes, 8 de diciembre de 2017
Comando oculto en Cisco. Deshabilitar negociacion de capacidad BGP
neighbor x.x.x.x dont-capability-negotiate
More info:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.html
IoT Cybersecurity
Como determinar si un string es una dirección IPv4 o IPv6 en Python3
Hola,
Escribo este post porque en varias oportunidades me han escrito como uno puede determinar si un string es una dirección IPv4 o IPv6 en Python3.
Solución
Nos apoyaremos en el módulo ipaddress de python3.
Algo tan sencillo como esto:
a='2001:db8::1'
if ipaddress.ip_address(a).version == 6:
print ('es IPv6')
else:
print ('es IPv4')
Espero te ayude,
Escribo este post porque en varias oportunidades me han escrito como uno puede determinar si un string es una dirección IPv4 o IPv6 en Python3.
Solución
Nos apoyaremos en el módulo ipaddress de python3.
Algo tan sencillo como esto:
a='2001:db8::1'
if ipaddress.ip_address(a).version == 6:
print ('es IPv6')
else:
print ('es IPv4')
Espero te ayude,
miércoles, 15 de noviembre de 2017
Reto IPv6 - Lacnic - LACTF. Resumen 2017
Se
han llevado a cabo 2 versiones del Reto LACNIC IPv6 en el 2017,
durante mayo y septiembre, con la participación de 30 personas
registradas de 7 países en ambas versiones, con 20 y 10
participantes, respectivamente, en forma individual o en grupo.
Se
integró un Comité evaluador compuesto por 5 personas reconocidas en
el tema de IPv6, todas integrantes del comité del FLIP6, cuyas
funciones han incluido:
-
Apoyar o sugerir pláticas de temas muy concretos que ayudaron a los
participantes a tener más conocimientos y herramientas, para poner y
ofrecer servicios con soporte de IPv6 en sus instituciones.
-
Revisar los reportes de pruebas realizadas por los participantes.
-
Validar el acceso y la disponibilidad de los servicios habilitados
con IPv6.
De
acuerdo a un monitoreo de los dominios de los portales web de los
participantes, se verificó si algunos ya tenían asociadas
direcciones IPv6 aunque la conectividad a los mismos no era exitosa,
por lo que fue necesario demostrar la habilitación reciente de IPv6,
el soporte de ambas versiones, y también de otros servicios que
pudieran ofrecer en producción con ambas versiones del protocolo,
cuidando los aspectos de seguridad y disponibilidad.
Todo
lo anterior sirvió de elementos (puntos) para que el comité
evaluador del Reto, pudiera tomar una decisión final de posible(s)
ganador(res) del mismo.
Adicionalmente,
se monitorearon dominios de sitios y estado de la habilitación de
IPv6 en los servicios de las aplicaciones documentados por los
participantes, antes, durante y después de la última versión de
los reportes de avances.
Usando
diferentes herramientas como “NAT64check”
(https://nat64check.ipv6-lab.net/v6score)
y comandos de conectividad como ping y traceroute. En la Fig.1 se
muestra la prueba previa realizada al portal de uno de los finalistas
de la versión 2 del Reto.
Fig.
1. Prueba previa realizada al portal de uno de los participantes del
Reto
Se
creó una sección en el Portal de IPv6 de LACNIC
(http://portalipv6.lacnic.net/reto-ipv6)
donde se incluyeron respuestas a las preguntas mostradas en la Fig.
2, del cartel promocional del Reto:
Fig.
2. Cartel promocional del Reto LACNIC IPv6
A
los participantes de ambas ediciones del Reto se les ofreció un
Webcast para aclarar dudas y recibir retroalimentación, además se
creó una cuenta de correo con la participación del Comité
evaluador.
En
los reportes de avances se les solicitó reseñar lo realizado hasta
cada momento (pruebas, reuniones con personal técnico y
administrativo, etc.) para documentar:
-
Reseña de la opción de obtención de bloque propio o usar el
proporcionado por un proveedor (ISP). Si enviaron la solicitud de
bloque al staff de LACNIC, indicando el status, y la documentación
de los trámites.
-
La indicación del grado de uso y anuncio del prefijo asignado con
resultados de pruebas y el listado de servicios con soporte de IPv6.
-
Aciertos y dificultades encontradas.
-
Avances incrementales (# de servicios y usuarios con soporte de
IPv6).
-
Capturas de pantalla que comprobaran el punto anterior.
-
En tablas con datos de los resultados de comandos como: ipconfig,
ifconfig, ping, traceroute, netstat, etc.
-
Indicación de los servicios que se ofrecieron también con IPv6.
-
Confirmación del o los dominios de los servicios.
-
Los pendientes y metas por lograr posteriormente.
Se
fijaron varias fechas a cumplir por los participantes del Reto para
el envío de una 1er. y 2a. versión del reporte de avances.
Así,
en la retroalimentación del Reto de mayo, se recibieron 3 reportes
de avance y tomando en cuenta sus aportaciones, se designaron 2
finalistas.
Por
otra parte en la 2a. versión del Reto de septiembre, se recibieron
únicamente 2 reportes de avance, por lo que la decisión de los
finalistas fue más inmediata por parte del comité evaluador.
Finalmente
después de cada premiación a los ganadores se les solicito, como
parte de los resultados esperados de los datos de los reportes, el
trabajar en un par de párrafos para publicar una nota al respecto en
la publicación de LACNIC. Donde tuvieron que resumir lo realizado y
comentar sobre la experiencia de participación en el Reto IPv6
LACNIC 2017 que incluyó lo que los impulsó a participar, los
desafíos y dificultades sobre la implementación y uso de IPv6, los
avances medibles, así como los procesos internos que se tuvieron que
realizar y superar. Por lo que se les pidió contestar a las
preguntas:
* ¿Qué
los impulsó a participar en el Reto IPv6?
*
¿Con qué desafío se encontraron en el proceso?
*
¿Qué avances ha logrado implementar su institución en relación a
IPv6?
*
¿Cree que las organizaciones son conscientes de la necesidad del
despliegue de IPv6 o todavía piensan que lo ven como algo lejano?
*
¿Cómo ha sido el proceso interno en su institución para decidir
avanzar en el despliegue de IPv6?
*
¿Cuáles son las principales dificultades a la hora de discutir
sobre la implementación de IPv6?
Reflexión
final:
Me
ha parecido una experiencia muy alentadora la participación que
espero se vaya incrementando y articulando con otras actividades
dentro de LACNIC. Todos a final de cuentas seguimos aprendiendo de
este tipo de iniciativas para mejorarlas y agregar más elementos al
Reto mismo, como el grado de complejidad pero para motivar mas la
participación, creatividad y obtener mejores resultados que se
puedan dar a conocer.
El
desafío a seguir promoviendo como una oportunidad de aplicar IPv6 en
servicios en producción por parte de las entidades participantes
miembros de LACNIC o de la región, sin lugar a dudas servirá para
incrementar aún más el uso y despliegue de IPv6, compartir
experiencias, y alentar a quienes no ven como caso de estudio y menos
de negocio el habilitar servicios también con IPv6.
Referencias:
- Introducing NAT64 Checker
https://labs.ripe.net/Members/JanZorz/introducing-nat64-checker
Autor:
Azael Fernandez Alcantara
@lactf
jueves, 24 de agosto de 2017
Google DNS --- Averiguando cual Cluster estas utilizando
(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on
August 23).
This post is being posted with his explicit permission.
I sent this out on the outage list, with a lots of good feedback sent to
me. So I
figured it would be useful to share the information on nanog as well. A couple months ago had to troubleshoot a google DNS issue with Google’s
NOC. Below
is some helpful information on how to determine which DNS Cluster you are
going to. Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8
and 8.8.4.4.
Anycast routes your DNS queries to the closes DNS cluster based on the
best route /
lowest metric to 8.8.8.8/8.8.4.4. Google has deployed multiple DNS
clusters across
the world and each DNS Cluster has multiple servers. So a DNS query in Chicago will go to a different DNS clusters than queries
from a
device in Atlanta or New York. How to get a list of google DNS Cluster’s. dig -t TXT +short locations.publicdns.goog. @8.8.8.8 How to print this list in a table format.
Script from: https://developers.google.com/speed/public-dns/faq --------------- #!/bin/bash IFS="\"$IFS" for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) do case $LOC in '') : ;; *.*|*:*) printf '%s ' ${LOC} ;; *) printf '%s\n' ${LOC} ;; esac done --------------- Which will give you a list like below. This is all of the IP network’s
that google
uses for their DNS Clusters and their associated locations. 74.125.18.0/26 iad 74.125.18.64/26 iad 74.125.18.128/26 syd 74.125.18.192/26 lhr 74.125.19.0/24 mrn 74.125.41.0/24 tpe 74.125.42.0/24 atl 74.125.44.0/24 mrn 74.125.45.0/24 tul 74.125.46.0/24 lpp 74.125.47.0/24 bru 74.125.72.0/24 cbf 74.125.73.0/24 bru 74.125.74.0/24 lpp 74.125.75.0/24 chs 74.125.76.0/24 cbf 74.125.77.0/24 chs 74.125.79.0/24 lpp 74.125.80.0/24 dls 74.125.81.0/24 dub 74.125.92.0/24 mrn 74.125.93.0/24 cbf 74.125.112.0/24 lpp 74.125.113.0/24 cbf 74.125.115.0/24 tul 74.125.176.0/24 mrn 74.125.177.0/24 atl 74.125.179.0/24 cbf 74.125.181.0/24 bru 74.125.182.0/24 cbf 74.125.183.0/24 cbf 74.125.184.0/24 chs 74.125.186.0/24 dls 74.125.187.0/24 dls 74.125.190.0/24 sin 74.125.191.0/24 tul 172.217.32.0/26 lhr 172.217.32.64/26 lhr 172.217.32.128/26 sin 172.217.33.0/26 syd 172.217.33.64/26 syd 172.217.33.128/26 fra 172.217.33.192/26 fra 172.217.34.0/26 fra 172.217.34.64/26 bom 172.217.34.192/26 bom 172.217.35.0/24 gru 172.217.36.0/24 atl 172.217.37.0/24 gru 173.194.90.0/24 cbf 173.194.91.0/24 scl 173.194.93.0/24 tpe 173.194.94.0/24 cbf 173.194.95.0/24 tul 173.194.97.0/24 chs 173.194.98.0/24 lpp 173.194.99.0/24 tul 173.194.100.0/24 mrn 173.194.101.0/24 tul 173.194.102.0/24 atl 173.194.103.0/24 cbf 173.194.168.0/26 nrt 173.194.168.64/26 nrt 173.194.168.128/26 nrt 173.194.168.192/26 iad 173.194.169.0/24 grq 173.194.170.0/24 grq 173.194.171.0/24 tpe 2404:6800:4000::/48 bom 2404:6800:4003::/48 sin 2404:6800:4006::/48 syd 2404:6800:4008::/48 tpe 2404:6800:400b::/48 nrt 2607:f8b0:4001::/48 cbf 2607:f8b0:4002::/48 atl 2607:f8b0:4003::/48 tul 2607:f8b0:4004::/48 iad 2607:f8b0:400c::/48 chs 2607:f8b0:400d::/48 mrn 2607:f8b0:400e::/48 dls 2800:3f0:4001::/48 gru 2800:3f0:4003::/48 scl 2a00:1450:4001::/48 fra 2a00:1450:4009::/48 lhr 2a00:1450:400b::/48 dub 2a00:1450:400c::/48 bru 2a00:1450:4010::/48 lpp 2a00:1450:4013::/48 grq There are IPv4 Networks: 68 IPv6 Networks: 20 DNS Cluster’s Identified by POP Code’s: 20 DNS Clusters identified by POP Code to City, State, or Country. Not all of
these are
Google’s Core Datacenters, some of them are Edge Points of Presences (POPs).
https://peering.google.com/#/infrastructure and
https://www.google.com/about/datacenters/inside/locations/ Most of these are airport codes, it did my best to get the location correct. iad Washington, DC syd Sydney, Australia lhr London, UK mrn Lenoir, NC tpe Taiwan atl Altanta, GA tul Tulsa, OK lpp Findland bru Brussels, Belgium cbf Council Bluffs, IA chs Charleston, SC dls The Dalles, Oregon dub Dublin, Ireland sin Singapore fra Frankfort, Germany bom Mumbai, India gru Sao Paulo, Brazil scl Santiago, Chile nrt Tokyo, Japan grq Groningen, Netherlans Which Google DNS Server Cluster am I using. I am testing this from
Chicago, IL
# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "173.194.94.135" <<<<<dig o-o.myaddr.l.google.com -t
"74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71"txt +short @8.8.8.8
"74.125.177.4"
Which all are Google DNS Networks in Atlanta.
74.125.42.0/24
atl
74.125.177.0/24
atl
172.217.36.0/24
atl
173.194.102.0/24
atl
2607:f8b0:4002::/48
atl
Just thought it would be helpful when troubleshooting google DNS issues.
Just thought it would be helpful when troubleshooting google DNS issues.
(one more time: this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing
list on August 23). This post is being posted with his explicit permission.
Suscribirse a:
Entradas (Atom)
Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS
En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...