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


martes, 22 de agosto de 2017

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,

jueves, 10 de agosto de 2017

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

jueves, 23 de marzo de 2017

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.
Articulo BPG.png

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



Autores
- Dario Gomez
- Alejandro Acosta (@ITandNetworking)

lunes, 30 de enero de 2017

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:
- 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
카지노사이트

domingo, 1 de enero de 2017

Como la navidad puede dañar una red (experiencia real, BTW adoro la navidad)

Hola,
  En este oportunidad voy a contar una experiencia que tuve unos años atrás. Creo que esta vivencia me vino a la cabeza luego de enterarme del Arbol de Navidad controlado por IPv6 [1]

Introducción:
  Alrededor del año 2011 estuve trabajando en una oficina donde ese mismo año se había instalado una red LAN la cual mediante un pequeño enlace DSL llegaba al core de la red de la organización y además se conectaba a Internet.

Sobre el comportamiento general de la red
  Transcurrían los meses desde Junio a Diciembre y la red funcionaba perfectamente, los usuarios satisfechos con el rendimiento, velocidad, aplicaciones entre otros.

Sobre la topología:
  La oficina (ramal) se conectaba mediante un enlace DSL propio (utilizando los mismos pares de cobre de unas lineas telefónicas del edificio), los modems DSL tenían un puerto UTP el cual conectábamos a un LAN Switch Cisco moderno. Como comentario adicional, también manejábamos algunas VLANs para algunos servicios (VoIP).
  La oficina contaba con una cámara de seguridad HD la cual transmitía a un servidor central ubicado en el core de la red (no en la misma oficina).

_______       __________       __________
|Oficina | ---- Enlace DSL   | ---- | Core Office   |
|_____|       |_________ |      |__________|




La llegada de la navidad
  Al igual que en la mayoría de las oficinas y hogares, en la oficina se decidió colocar su respectivo árbol de navidad en la entrada, justo en la puerta principal.
  El árbol fue adornado con sus respectivos ornamentos navideños tales como: bambalinas, micro arbolitos, casitas, cascanueces, estrellas y por supuesto sus luces a lo largo del árbol que titilaban constantemente.


¿Qué ocurrió y como la navidad "dañó" la red?
  Las cámaras mencionabas anteriormente se encontraban apuntando hacia la entrada de la oficina y al igual que muchas otras cámaras y sistemas de CCTV solo transmitían los cambios de la imagen (o lo que es mismo cuando había algún movimiento) al servidor central, es decir, si no habían cambios de pixels en donde apuntaba la cámara, el consumo de ancho de banda era mínimo o casi nulo. Favor recordar que el receptor de la imagen era un servidor central ubicado al otro extremo del enlace DSL y no propiamente en la oficina donde se instaló el árbol.

Para finalizar:
  Entendiendo que un enlace DSL no es de muy alta velocidad y las cámaras son HD el problema puntualmente fue que colocaron el árbol de navidad con sus luces intermitentes junto a la entrada de la oficina, por ende la cámara alcanzaba el mismo haciendo que tuviese que transmitir constantemente al servidor central los cambios de la imagen, es decir, cualquier movimiento en el árbol tal como las luces intermitentes!.

Saludos,

[1] http://ipv6tree.bitnet.be/
[2] Imagen tomada de: http://www.publicdomainpictures.net/pictures/60000/velka/christmas-tree-by-the-fire-place.jpg




martes, 27 de diciembre de 2016

Un Poema de redes

Inspirado en un poema Andrew Myers [1] que a su vez fue inspirado por otro de Edward Gorey [2]

Muy bien por Amanda quien sabe mucho de ancho de banda,
excelente por Bartolo quien conoce muy bien el protocolo,
maravilloso el Chacal que levantó la troncal,
lástima David que pierde varios bits,
increíble “Ese” quien pasó el IDS,
horroroso Franciel que olvidó su clavel,
muy mal por Gerardo quien presenta retardo,
super por el Host anfitrión que armó la interconexión,
hay que enseñarle a Isabel lo que es un decibel,
y convencer a Janet quien aún usa Telnet!,
qué pasará con Karina quien la conexión termina,
y cambiarle a Luisito que tiene un firewallcito,
Bien por Megan que sabemos tiene muchos megas,
suerte para Nestor que montó un route reflector,
Que desastre para Otto quien tiene el enlace roto,
que pena por Pilar que se quedó sin datos en el celular,
Bravo por Quintal que aprobó Digital,
Privilegiado Ramón quién sabe mucho de GPON,
Bondadoso Salvador quien salvó el servidor,
Fabuloso por Trinidad que siempre piensa en escalabilidad,
Formidable por Ulises quien conectó muchos países,
lamento que Vidal no pensó en seguridad,
Estupendo para Wan quien honró su nombre y diseñó la WAN,
Incomparable Xan que armó la LAN,
Magnífico por Yanet quién desarrolló la extranet,
que pena por Zack que ya no le queda espacio en el rack.



[1] https://andrumyers.wordpress.com/2014/12/12/gashlycode-tinies/
[2] https://www.brainpickings.org/2011/01/19/edward-gorey-the-gashlycrumb-tinies/








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