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,
martes, 22 de agosto de 2017
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:
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:
- Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
- 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)
- Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
- 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)
- ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
- Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
- 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:
- No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
- Filtrar por AS_PATH de profundidad.
- 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 - Información General sobre Certificación de Recursos (RPKI)
http://www.lacnic.net/web/lacnic/informacion-general-rpki
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)
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)
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
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.
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/
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/
martes, 6 de septiembre de 2016
Ejemplo: Linux y Network Prefix Translation (NPT)
Introducción:
En este post voy a intentar explicar brevemente que es NPT, por qué es útil y finalmente dejaré un pequeño ejemplo que espero sea de utilidad.
¿Qué es NPT?
NPT por sus siglas en Inglés significa Network Prefix Translation, algunos lo podrás comparar con NAT en IPv6.., y bueno,., es medianamente cierto. Siendo la palabra “medianamente” perfectamente utilizada en la oración previa.
En NPT básicamente lo que se busca es traducir la dirección origen en un datagrama IPv6, pero particularmente la sección del prefijo de red (NET ID) dejando la parte del IID (Host ID) sin modificación.
¿Por qué hacer NPT?
Existen varias razones. Voy a mencionar solo dos.
- Estoy en una red con dos proveedores de Internet (no tengo IPs propias ni ASN), pero necesito alguna redundancia para salir a Internet. El equipo de borde en vez de realizar un NAT con sobre de carga de puertos a una sola dirección IP (con todos los problemas y limitantes que esto ocasiona) solo modifica los primeros bits del la dirección (digamos, los primeros 64 bits solo como manera de ejemplo).
- Si necesitar hacer “renumbering” de tu red pero tienes IPs del tipo ULA (u otra propia quizas) tu vida será mucho más sencillo al solo tener que modificar el traductor NPT y no hacer re-enumeración de toda la red.
Diagrama ejemplo
Configurando un equipo Linux para hacer NPT:
Los pasos para configurar NPTv6 (o NPT) en Linux son muy sencillos. Debes hacerlo tanto de paquetes salientes como de paquetes entrantes.
#From internal network to external Network
ip6tables -t nat -A POSTROUTING -d 2000::/3 -s 2001:db8:AAAA:AAAA::/64 -j NETMAP
--to 2001:db8:CCCC:CCCC::/64;
#From external network to internal network
ip6tables -t nat -A PREROUTING -s 2000::/3 -d 2001:db8:CCCC:CCCC::/64 -j NETMAP
--to 2001:db8:AAAA:AAAA::/64;
Mas info:
Y por supuesto el RFC mismo:
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...
