Error "no se puede abrir porque no se encuentra el elemento original"

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

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,

@ITandNetworking @LACNICLabs

#Referencias

1. https://es.wikipedia.org/wiki/Retrospectiva
2. http://stats.labs.lacnic.net/IPv6/graph-access.html

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

[1]  http://www.actividadeseconomicas.org/2012/06/top-10-de-los-paises-mas.html

[2] http://www.bbc.com/mundo/noticias/2014/12/141220_navidad_papa_noel_entrega_regalos_jp

[3] https://www.papanoelenlaponia.com/los-elfos-de-santa-2

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,

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:

- Sección del Reto en el Portal de IPv6 de LACNIC (http://portalipv6.lacnic.net/reto-ipv6)

- Introducing NAT64 Checker

https://labs.ripe.net/Members/JanZorz/introducing-nat64-checker

Autor:

Azael Fernandez Alcantara

@lactf

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 

txt +short @8.8.8.8

"74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71" 

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

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

Prueba de ping MUY sencilla con IPv6. Comparativa IPv4 - IPv6 haciendo ping a la loopback

Hola,
  Recientemente estuve haciendo unas pruebas de ping a las direcciones de loopback de Windows, Linux y MAC.
  Si haces ping6 a tu loopback (digamos 1000 paquetes) con Windows o Linux, IPv6 es más rápido.
  Ahora intenta lo mismo en MAC (El Capitan).., IPv6 es 20-25% más lento.
  Hice lo mismo en varios dispositivos y le pedí a varios amigos que hicieran la misma prueba. Todos obtuvieron el mismo resultado


MAC:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.037/0.098/1.062/0.112 ms
--- ::1 ping6 statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.058/0.120/0.194/0.027 ms



Linux:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 98999ms
rtt min/avg/max/mdev = 0.015/0.021/0.049/0.007 ms

--- ::1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99013ms
rtt min/avg/max/mdev = 0.019/0.031/0.040/0.004 ms


Windows 10:

Ping statistics for ::1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


Ping statistics for 127.0.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 4ms, Average = 0ms


Esto es todo,

Manera muy sencilla de incrementar el volumen de un archivo mp3. Utilizando Lame en Linux o MAC

Objetivo: 

    Incrementar el volumen de un archivo de audio 

Que necesito: 

   lame 

Instalación: 

   apt-get install lame

 o 

   brew install lame 

Ejemplo: 

  #lame --scale 2 archivo-orignal.mp3 archivo-con-volumen-incrementado.mp3 

 Listo!!

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción

 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.

 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.

Situación identificada

  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.

  Lo anterior puede deberse a diversas razones:

• El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
• Por ahorro de CPU
• Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
• Por simplicidad y sencillez

 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.

Problema

  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.

¿Por qué?

  Imaginemos la siguiente situación:

1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)

Diagrama:

  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.

Recomendación

 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:

1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
2. Filtrar por AS_PATH de profundidad.
3. Crear los ROAs respectivos a los prefijos (RPKI).

Algunos ejemplos (Cisco like)

1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002

neighbor 10.0.0.1 remote-as 65001

neighbor 10.0.0.1 route-map FILTRO-IN in

!

ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24

!

route-map FILTRO-IN permit 10

match ip address prefix-list REDESCHICAS

!

2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):

router bgp 65001

neighbor 10.0.0.2 remote-as 65002

neighbor 10.0.0.2 route-map ASFILTER-IN in

!

ip as-path access-list 5 permit ^[0-9]+_$

ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$

!

route-map ASFILTER-IN permit 10

match as-path 5

!

Mas información

• Demostración de secuestro de prefijo  1/2: https://www.youtube.com/watch?v=X5RNSs8y8Ao&t=39s
• Demostración de secuestro de prefijo 2/2: https://www.youtube.com/watch?v=m51WtuEZOKI
• BGP Prefix-Based Outbound Route Filtering
  http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgporf.html
• Ejemplo de configuración de BGP con dos prestadores de servicio diferentes (conexiones múltiples)
  http://www.cisco.com/cisco/web/support/LA/7/75/75930_27.html
• Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/certificacion-de-recursos-rpki
• Información General sobre Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/informacion-general-rpki

Autores

- Dario Gomez

- Alejandro Acosta (@ITandNetworking)

3 recomendaciones al construir el registro SOA en DNS

Hola, 

  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:

  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):

@ IN SOA localhost. root.localhost. (

     1 ; Serial

604800 ; Refresh

 86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

   De manera muy breve y explicándolo de manera muy entendible: 

El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona

Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 

Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar

Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA

Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN

Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:

  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 

  7.11. A zone's SOA SERIAL should never be set to zero (0) due to

   interoperability" ...............

Consejo 2: 

  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the

          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:

   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone

          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:

- https://tools.ietf.org/html/rfc2136
- https://www.ietf.org/rfc/rfc1912.txt

- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

The best Buy vps bitcoin from eldernode.com
Where to order pain Relief without prescription
you can buy bitcoin vps from eldernode

Host your website on the fastest servers in Chicago, USA. Hundreds of features you need. Chicago Shared Hosting Easy On-boarding & Simple Website Transfer to our Platform
카지노사이트