Retrospectiva sobre el crecimiento de IPv6 durante el 2019 en Latinoamerica y Caribe

Muy buenos días Lista, 

  Existe un refrán que estoy seguro todos conocen: “El hombre es un animal de costumbre”, por sexto diciembre consecutivo estamos entregando una retrospectiva sobre IPv6 en nuestra querida región.

  Costumbre es sinónimo de consuetudinario, es decir, estamos casi que rozando la ley en estos mensajes, espero no se me olvide el año que viene !

  Y bueno, 6to año, hablando de IPv6 tengo que intentar explayarme.

  De igual manera como he hecho en otras oportunidades, comencemos repasando 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.”

  Y les aseguro que al leer este concepto, no me viene a la cabeza ningún otro mejor adjetivo que pueda enmarcar lo que deseamos expresar aquí.

  Por ser 6to año y celebrando IPv6 cubriremos los TOP 6 países de nuestra región.

  Voy a indicar los 6 pasos que tomé:

1. Ubicar los TOP 6 países de nuestra región es cada vez más sencillo, hoy en día vamos a: https://stats.labs.lacnic.net/IPv6/ipv6ranking.html 
2. Hacemos click sobre el checkbox LACNIC
3. Luego entramos a: https://stats.labs.lacnic.net/IPv6/graph-access.html 
4. Repasamos 1 a 1 cada país obtenido en el paso anterior
5. En algunas oportunidades hacemos click en “Per ASN” correspondiente al país
6. Listo !, a escribir

 Los TOP 6 países con su respectivo % de penetración de IPv6 en el usuario final son (para comienzos de diciembre 2019):

1 UY 38.27

2 GF 35.61

3 MX 31.96

4 BR 28.69

5 TT 20.26

6 PE 18.53

  Hablemos de cada caso:

1. Uruguay (UY), el segundo país más chico de Sur América (luego de Surinam) dice muy presente cuando se trata de penetración de IPv6 y velocidad a Internet, es líder en ambos rubros en nuestra región, casi 40 de cada 100 uruguayos ya cuentan con IPv6 -y la velocidad promedio de bajada en el móvil es sobre los 20 Mbps-. Un gran aplauso.

2. Guyana Francesa (GF), casa de “Le Centre Spatial Guyanais” conocido como la  Guiana Space Centre donde muchos países Europeos utilizan este centro espacial para sus lanzamientos, y algo similar hicieron con IPv6, le pusieron un cohete ! . Nuestras gráficas indican que comenzó su despliegue a comienzos de Abril 2019 y a las dos semanas tenían 20% de IPv6 y a las 5 semanas cerca de 35.61%, mientras escribimos estas líneas sigue creciendo. Nuestras felicitaciones.

3. México (MX), conocido por muchas cosas pero entre otras por su celebración del día de los muertos, sin embargo le están diciendo al mundo que en IPv6 están muy vivos :-)   , ya habían comenzando 2019 con 24% de penetración de IPv6 y en el transcurso del 2019 tuvieron un crecimiento superior al 30%. Por cierto, también son el exportador más grande del mundo en cerveza y parece que quieren exportar IPv6.  Vamos arriba México

4. Brasil (BR), haciendo honor a su slogan (motto) “Ordem e Progresso” (order and progress) han hecho precisamente lo mismo con IPv6. Durante el 2019 Brasil incrementó en un 10% su penetración de IPv6 llegando a 30.22%. Nada mal para el país más grande la región y 5to en el mundo. Nuestros respetos.

5. Trinidad y Tobago (TT), cuna del instrumento musical “Steel Pan” (tambores metálicos), digno representante caribeño en despliegue IPv6 implementa el protocolo con buen ritmo para no quedarse atrás. TT se posiciona en 5ta posición en la región ofreciendo IPv6 a 1 Trinitario cada 5 personas, creo que quieren correr a la velocidad de Hasely Crawford (el Usain Bolt Trinitario en 1976)

6. Perú (PE), lo primero que se me viene a la cabeza es su gastronomía, Machu Picchu y los Inca, pero solo quiero decir que su despliegue IPv6 es casi tan alto como su famoso lago Titicaca, el más alto del mundo. Perú desde hace varios años es icono de despliegue de IPv6 en la región y nos contenta mucho verlos aún como líderes en este rubro. Para el momento que se escribe estas líneas, el país cuenta con un poco más de 18% de penetración de IPv6.  Que continúen el despliegue con un Pisco sour :-)

¿Y el promedio de Latam?

Ya hace un año explicamos que anteriormente en LACNIC publicabamos un promedio simple (media aritmética) del promedio IPv6 en nuestra región. Hoy en día estamos publicando una *media aritmética ponderada* en base a la población de los países, población de LAC y grado de penetración de IPv6 en el país, esto nos lleva a un valor más real de usuarios de Internet con IPv6 en nuestra región.  

La penetración de IPv6 en el usuario final en LATAM está en 19.50%, un número nada mal pero aún por debajo de la media mundial (29%) [2]. Recordemos que país que no implemente IPv6 corre el riesgo de quedarse aislado. Vamos LAC !!

¿Alguna mala noticia en el 2019?

Lastimosamente tenemos una pero mejor que el año pasado.

Una de las mediciones que hacemos en LACNIC es ubicar sitios Web con ccTLDs de nuestra región e identificar si tienen IPv6, posteriormente estudiamos si estos sitios apuntan a una dirección IP asignada por LACNIC [7].

En el 2017 teníamos que el 33.9% de estos sitios con IPv6 apuntaban a direcciones asignadas por LACNIC. Para el diciembre del 2018 solo 19%. Interesantemente este 2019 volvimos a 33.2% de sitios Web en LAC que apuntan a direcciones IP asignadas por LACNIC.

Esperemos que para el 2020 este valor aumente, si se puede !.

Pronóstico para el año que viene.

Realizar pronósticos siempre ha sido algo muy complicado, creo que nosotros como personas de ciencia nos basamos más en hechos reales, en números. Sin embargo equivocarse con IPv6 hasta cierto punto no es difícil, IPv6 seguirá creciendo, el despliegue aumentará en nuestra región. Un hecho que pienso que está ocurriendo es que ya los clientes están atentos de saber si el ISP soporta IPv6, en caso negativo buscan otro ISP y listo, ahora todos los países ya cuentan con proveedores con IPv6. El tema de los túneles ya viene en bajada desde hace muchos años, habiendo dicho eso comienza una etapa verdadera de pérdida de clientes si el proveedor no ofrece IPv6. Una vez más veremos crecimiento en redes IPv6 Only tales como Data Centers.

 Reciban un fuerte abrazo,

Alejandro Acosta,

@ITandNetworking

[1] https://es.wikipedia.org/wiki/Retrospectiva

[2] https://www.google.com/intl/es/ipv6/statistics.html

[3] https://facts.uk/18-felicitous-facts-about-french-guiana/

[4] https://www.swedishnomad.com/interesting-facts-about-mexico/

[5] https://www.telegraph.co.uk/travel/destinations/south-america/brazil/articles/brazil-fascinating-facts/

[6] https://www.destinationtnt.com/blog/17-interesting-facts-any-visitor-should-know-about-trinidad-and-tobago/

[7] https://stats.labs.lacnic.net/IPv6/reports/current-websites-lac-with-aaaa.html

Configurando una sesión BGP entre dos loopbacks con IPv6 - ebgp multihop y captura de wireshark

En el video se muestra como configurar una sesión BGP entre dos enrutadores Cisco IOS. Se realiza con ebgp multihop y se muestra captura de paquetes con Wireshark

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

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

Carta de IPv4 (masculino) a IPv6 (femenino) en el día de los enamorados

Hola mi IPv6,
 Quiero comenzar esta carta con mi orgullosa longitud de 32 bits en el datagrama, hasta ahora es lo mejor que tengo y lo que me ha dado energía durante casi 4 hermosas décadas. Hoy en día cuando escucho de tus 128 bits no sé si amarte u odiarte, suenas muy poderosa, ¿es bueno o es malo?

 Entonces en las noches, cuando el tráfico baja reflexiono sobre mi pasado, me doy cuenta que hasta haces unas décadas yo era muy feliz, era el único en la red, cuando salía de un sitio llegaba al otro _enterito_, los routers me querían y los firewalls ni hablar, nunca me detenían. Los últimos años las cosas han cambiado mucho, me da miedo salir.., cada vez que salgo alguien en el camino cambia todo mi ser, literalmente una dolorosa mutación, la gente cree que es divertido, para nada. Luego llego a un destino donde digo ser quien no soy, me responden como si fuera quien no soy y luego para regresarme a veces ni consigo el camino de retorno, y si lo consigo, me vuelven a mutar a mi ser original, pobre de mí, doble dolor.  Pero eso no es todo, cuando salgo espero que en la vía no la agarren conmigo, de vez en cuando me detienen, me desechan silenciosamente o me rechazan enviando a un primo mío a donde mi dueño a decirle que no llegué (si, además se llevan un dedo mío como fe de vida), lo más triste es que sé que más nunca volveré a escuchar de mi primo, evidentemente no me quieren. Ahora bien, cuando siento que logré todo, llego al destino, estoy súper contento pero no.., me entero que mi dueño se molesta, lo escucho decir que el audio no sirve, que el video no anda, que la VPN tal cosa, etc, etc.. ¡Entonces ocurre lo peor, me reinician!!, esto si es espantoso, siempre creen que esto va a funcionar, ouch, y ni hablar de cuando esto se vuelve un círculo vicioso. Ah!, casi se me olvida, ni que decir de cuando quieren dividirme en pedacitos durante el camino, menos mal que tu no pasas por esto!

 Volviendo a mi reflexión, el otro día nos conseguimos, ¿te recuerdas?, salimos simultáneamente de la casa, íbamos muy felices los dos, al comienzo casi agarrados del campo _version_,  tu parecías apurada, yo veía como te alejabas en el camino, que lindo tu campo _dirección_ _destino_, ibas de router en router sin mirar atrás, llegaste mucho antes que yo, luego ví la respuesta venir cuando yo apenas iba, sorprendente!!!, al principio me sentí un poco triste pero luego pensé en nuestro dueño, wow, que felicidad para él!, ahora sí está más contento, es más productivo, hace las cosas más rápido, en las mañana antes duraba 1 hora en la computadora, creo que contigo lo hace todo en 45 minutos. Bien!.  Además conecta dispositivos todo el tiempo, y con estos último si es verdad que ni me considera.

 Pero no quiero que mi amor quede en lo virtual, desde la fibra hasta el satélite, desde la microonda hasta el Wifi quiero expresarte mis campos verdaderos. Ningún otro protocolo podrá comprenderte tanto como yo, por ello la intensidad de nuestra señal nos mantendrá unidos por muchos años. No importa cuántos paquetes se dropeen o cuantos checksum vengan malos (ups, tu no tienes checksum, bueno, me entiendes), solo contigo quiero estar. Un secreto que no le he dicho a nadie es mi deseo de una colisión de vez en cuando :-).

  Cuando se que vamos a salir juntos, no solo me pongo mi mejor ropa, me afeito, me arreglo, y justo antes de salir pongo mi campo TTL al máximo, así pienso que aumento las probabilidades de conseguirme contigo, y si por mucha casualidad entramos en un routing loop, yuuppiiii. Caso contrario cuando se que no viajas conmigo, muy triste cuando salgo solo, por suerte se que es temporal, cada día es más común encontrarnos, te veo más veces, escucho más de ti, te leo en todos lados.

  Definitivamente 128 parece ser mejor 32, una matemática muy simple, pero quiero que estés orgullosa de mi, afortunadamente no puedo quejarme, siento que he hecho un buen trabajo, conecté un planeta completo, he logrado cosas impensables, no quiero imaginarme como será contigo, veo un mundo más completo, más ecológico, más productivo y con un mejor nivel de vida. Me alegra mucho pensar en todo esto!!.

 Antes de terminar la carta quería comentarte que me encuentro cansado, desde hace muchos años me han venido operando en todas partes y los mejores profesionales, me han hecho cirugías, operaciones, trasplantes y muchas otras cosas, creo que no aguanto mucho más, ¡déjenme como estoy ahorita por favor!

 Ahora necesito yo que reflexionen los demás, ya estoy viejo, no soy el mismo, ando más lento, las nuevas generaciones vienen mejoradas, hay que darles espacio, paquetes más rápidos, más manejables, con mayor escalabilidad. ¿Cómo puedo yo competir contra 128?

 Por eso, mi querida IPv6, ahora que escribo todo esto, quiero decirte: eres el futuro. ¡Feliz día de San Valentín!

  Quien te quiere mucho y te desea lo mejor


____________
Tu paquetito de 32 bits

Monitoreando IPv4 e IPv6 con sFlow

Introducción

 

Este primer artículo tiene como objetivo presentar de manera práctica cómo monitorear tráfico de una interfaz de red con doble pila configurada (Dual-Stack), IPv6 e IPv4, a través de la tecnología sFlow.

 

sFlow es una tecnología de muestreo de paquetes que se puede implementar en una amplia gama de dispositivos desde equipos de capa 2 hasta equipos de alto desempeño como enrutadores de core. Debido a la incorporación de redes de alta velocidad, el muestreo de paquetes ha sido ampliamente reconocido como la solución más escalable, precisa y completa para el monitoreo de redes.

 

Si bien la metodología de muestreo de paquetes está incrustada dentro del elemento de red (por ejemplo, el enrutador o switch), el análisis de tráfico se realiza realmente en un equipo diferente, normalmente un servidor. Esto permite mayor escalabilidad y capacidad de respuesta en tiempo real sin afectar el desempeño de los enrutadores, especialmente a altas velocidades de tráfico.

 

Los diferentes componentes del sistema sFlow: son el generador sFlow, el agente sFlow, y el colector sFlow:

 

• El generador de sFlow es el elemento de red que genera muestras de tráfico. La toma de muestras de paquetes se realiza típicamente en hardware para proporcionar un rendimiento a velocidad de cable (wire-speed).
• El agente sFlow es un proceso de software que se ejecuta como parte del software de gestión de red dentro del elemento de red.  Los agentes sFlow en enrutadores y switches en toda la red envían continuamente un flujos de datagramas sFlow a un colector sFlow centralizado. Los contadores de interfaz y las muestras de flujo se combinan en datagramas sFlow, que requieren muy poco procesamiento. Los datos se empaqueta en datagramas sFlow, que se envían de inmediato en la red. Esto reduce al mínimo la carga en la memoria y procesador de los agentes sFlow .
• El software colector de sFlow analiza los datagramas recibidos de cada agente sFlow y los presenta en tiempo real, permitiendo la vista de los flujos de tráfico de toda la red. Varias soluciones de colectores y software analizador de sFlow están disponibles comercialmente, así como en software libre.

 

La definición de flujos de tráfico a través de esta tecnología se puede realizar de numerosas maneras. Tradicional implica una clave en que el flujo se define como una secuencia unidireccional de tramas que comparten los siguientes valores:

 

• Dirección MAC de origen
• Dirección MAC de destino.
• Tipo de Ethernet.
• VLAN y prioridad.
• Dirección IPv6 ó IPv4 de origen.
• Dirección IPv6 ó IPv4 de destino.
• Puerto UDP o TCP de origen.
• Puerto UDP o TCP de destino.
• Protocolo IP (IPv4), Next header (IPv6).
• Interfaz (SNMP inputifindex, outputifindex).
• Tipo de servicio IP.
• Tipo de queries DNS.
• Entre otras.

 

Cuáles son los beneficios

 

El establecimiento de sFlow nos permite contar con una visibilidad completa y en tiempo real de toda la infraestructura de red, coadyuvando entre muchas cosas:

 

• Monitoreo de la red, servidores, servicios, ataques e intrusiones desde una sola consola.
• Identificar fácilmente las redes, computadoras, servidores y puntos de almacenamiento.
• Supervisar el rendimiento de la telefonía IP, videoconferencias, almacenamiento, cómputo , entre otros dispositivos de red.
• Identificar la congestión y garantizar la calidad del servicio.
• Identificar los recursos sobre utilizados y mejorar su eficiencia.
• Analizar la distribución de contenidos por Multicast.
• Analizar e implementar ingeniería de tráfico en redes MPLS.
• Monitoreo de VLAN, QinQ, redes Metroethernet, etcétera.
• Detectar asimetrías en el enrutamiento.
• Analizar la conveniencia al momento de interconectar nuevos peers.
• Asegurar cuotas de tráfico discriminado a través de la capa de aplicación.
• Inspeccionar y dar seguimiento de usuarios.

 

Qué necesitamos

 

Como objeto de esta demostración se requerirá de los siguientes recursos:

 

1. Equipo enrutador o switch con soporte de sFlow.
2. Servidor Linux de la plataforma de su preferencia.
3. La instalación de un colector de sFlow dentro del servidor Linux, en particular el colector llamado sFlow-RT, consulte:http://www.inmon.com/products/sFlow-RT.php
4. Un equipo de cómputo con navegador web.

 

 

Para obtener una lista de colectores disponibles, consulte:

http://www.sflow.org/products/collectors.php

 

El estándar, de la industria, sFlow se encuentra actualmente en la versión 5. Para obtener más información, consulte:

http://www.sflow.org

 

 

Cuáles son los pasos que tenemos que seguir

 

1. Como primer paso realizaremos la configuración del enrutador, para ello utilizaremos como ejemplo un enrutador MLXe-4 de la marca Brocade con la versión de sistema operativo  5.5.0T165.

     a. Desde línea de comando (CLI) ejecutaremos las siguientes instrucciones, en modo de configuración global :

       i. Habilitar sFlow en el equipo:

 

         R1(config)# sflow enable

       ii. Configurar la dirección IPv6 ó IPv4 del servidor que tendrá el rol de colector sFlow y a donde se enviará los      datagramas de sFlow:

R1(config)# sflow destination 192.168.105.33

ó

R1(config)# sflow destination ipv6 FE80::AA8E:F8FF:FE73:B700

iii. Es importante configurar los intervalos o frecuencia en la que se enviarán los datagramas de sFlow (definida en segundos):

R1(config)# sflow polling-interval 10

iv. Otro parámetro importante de la configuración es el denominador de muestreo, que es de 1/N, es decir, por cada N número de tramas que pasan por una interfaz se tomará una sola, esta muestra será registrada y enviada al colector de sFlow. Este valor dependerá de la velocidad del puerto al que será configurado (para más información consultar las recomendaciones del fabricante):

R1(config)# sflow sample 512

 

b. Desde CLI ejecutaremos el siguiente comando, en modo de configuración dentro de la interfaz de red que nos interesa monitorear:

R1(config-if-e10000-4/4)# sflow forwarding

 

La configuración final quedará de la siguiente manera:

 

sflow enable

sflow destination 192.168.105.33

sflow polling-interval 10

sflow sample 512

!

interface ethernet 4/4

port-name ISP1

enable

sflow forwarding

!

 

2. Una vez realizado el paso 1, el enrutador comenzará enviar los datagramas de sFlow al colector de flujos. El siguiente paso es configurar el software sFlow-RT para que pueda analizar el tráfico, por lo que será necesario entrar al siguiente URI (servidor en que instalamos el colector):

 

http://192.168.105.33:8008/flow/html

1. 1. Para comenzar a obtener los valores de download y upload que pasan por nuestra interfaz troncal recién habilitada con sFlow, configuraremos los siguientes parámetros dentro de la interfaz web del colector de flujos, particularmente dentro del apartado Flows, llenando el siguiente formulario web:
      i. Name: IPv6stack
      ii. Keys: stack
      iii. Value: bytes
      iv. Filter: stack=eth.ip6.tcp|stack=eth.ip6.udp|stack=eth.ip6.icmp6
   2.  

      Presionamos el botón Submit.
       
   3. De la misma manera agregaremos otro registro en el formulario para el stack IPv4:
      i. Name: IPv4stack
      ii. Keys: stack
      iii. Value: bytes
      iv. Filter: stack=eth.ip.tcp|stack=eth.ip.udp|stack=eth.ip.icmp
   4.  

      y finalmente presionamos el botón Submit.
       
      Nota:
      El parámetro value puede ser configurado con cualquier de los siguientes atributos: frames (frames per second), bytes (Bytes per second), requests, duration.
       
      El resultado final quedará de la siguiente manera:

1. 5. Una vez configurado los flujos, podemos dar un click al registro IPv6stack o IPv4stack y comenzaremos observar en tiempo real los Bytes por segundo que están pasando por la interfaz de acuerdo al stack seleccionado, mostrando los siguientes resultados:

 

Para poder observar gráficas en tiempo real a través del sFlow-RT, en nuestro navegador deberemos colocar los siguientes URI:

 

http://192.168.105.33:8008/metric/ALL/sum:IPv6stack/html

 

http://192.168.105.33:8008/metric/ALL/sum:IPv4stack/html

Con esto concluimos la configuración básica de sFlow, ahora podemos identificar cuántos Bytes por segundo están pasando por la interfaz de red, de la misma manera podemos configurar más flujos con diferentes value por ejemplo frames, para obtener las tramas por segundo que pasan por la misma. Por último, si nos interesa conocer los top senders de las direcciones IPv6 ó IPv4, podemos configurar más flujos en el colector, por ejemplo:

 

Name: IPv6topsender

Keys: ip6source,ip6destination,ip6nexthdr

Value: bytes

 

finalmente presionamos el botón Submit. Con el cual obtendremos la lista de las direcciones que más descargan o suben información en IPv6 ó IPv4, en este caso por ejemplo el protocolo IPv6:

En posteriores artículos se compartirá cómo:

Generar históricos de la información, así como gráficas personalizadas a través de CACTI, InfluxDB o programación con Python y RRDTools; en base a valores obtenidos por las open northbound APIs del colector sFlow-RT.  

Desarrollar aplicaciones SDN con Python, sFlow-RT y OpenFlow 1.3, para detener, redireccionar o dar calidad de servicio al tráfico que pasa por switches y/o enrutadores mediante una controladora SDN, a partir de eventos detectados por un colector de sFlow.

 

Autor: Jaime Olmos

Revisado: Alejandro Acosta, Azael Fernández y José Luis Gaspoz.