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
Suscribirse a:
Entradas (Atom)
Una mejora práctica en el Transporte DNS sobre UDP en IPv6
Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...
