Mostrando entradas con la etiqueta tcpip. Mostrar todas las entradas
Mostrando entradas con la etiqueta tcpip. Mostrar todas las entradas

martes, 28 de enero de 2025

¿Qué historia hay detrás de las famosas máscaras de red?

Introducción

¿Recuerdas cuando estabas aprendiendo de máscaras de red? Seguro llegaste a pensar: “no sirven para nada”, “no las voy a necesitar”, “¿por qué inventaron esta locura?”. Además de sacarte una sonrisa espero convencerte de la enorme importancia que tienen en el gigantesco ecosistema de Internet.


Objetivo

Este blog post resume la historia y los hitos relacionados detrás de los conceptos de máscara de red en el mundo de IPv4. Comenzamos la historia en un mundo donde no existían las clases (plano-flat), pasamos por un mundo classful y finalizamos en un Internet totalmente classless (CIDR). La información se basa en extractos de los RFC 790, 1338 y 1519, junto con hilos de correo electrónico de la lista de correo ‘Internet-history’.


¿Sabes lo que es la máscara de red?

Asumo que si llegaste a este documento si lo sabes :-) pero aquí va un mini concepto: una máscara de red se utiliza para ubicar y dividir un espacio de dirección de red y una dirección de host, en otras palabras, indica al sistema cuál es el esquema de particionamiento de subred.


¿Cuál es el propósito de la máscara de red?

Enrutamiento: Los enrutadores utilizan la máscara de red para determinar la porción de red y encaminar correctamente los paquetes.

Subnetting: Las máscaras de red se utilizan para crear redes más chicas.

Aggregación: Las máscaras de red permiten la creación de prefijos más grandes.


¿Siempre han existido las máscaras de red?

No, muy interesantemente no siempre existió la máscara de red, al comienzo las redes IP eran planas (flat) y siempre asumían 8 bits para la red y 24 bits para el host. En otras palabras, el primer octeto era la red, y los 3 octetos restantes corresponden al host. Otro aspecto llamativo es que hace muchos años también recibía el nombre de bitmask o solo mask (aún utilizado ampliamente).


Lo anterior conlleva a que no siempre existieron las clases (A, B, C, D)

Las clases no existieron hasta la aparición del RFC (septiembre 1981) de Jon Postel, es decir, incluso era una época antes de classless y classful.

La introducción del sistema classful fue impulsada por la necesidad de acomodar diferentes tamaños de red, ya que el ID de red original de 8 bits era insuficiente (256 redes). El sistema classful fue un intento de abordar las limitaciones de un espacio de direcciones plano, aunque este también tenía limitaciones de escalabilidad. En el mundo de las clases la máscara de red era implícita.


Las clases tampoco solucionaron todo

Si bien el sistema classful fue una mejora sobre el diseño original (plano), no era eficiente. Los tamaños fijos de los espacios de red y hosts de las direcciones IP llevaron al agotamiento del espacio de direcciones, especialmente con el creciente número de redes que eran más grandes que una Clase C, pero más pequeñas que una Clase B. Lo anterior llevó al desarrollo del enrutamiento Inter-Dominio Sin Clases (Classless Interdomain Routing – CIDR), que utiliza máscaras de subred de longitud variable (Variable Length Subnet Mask – VLSM).




Extracto del RFC 790

¿Sabías que no siempre la máscara se escribió con bits continuos encendidos de izquierda a derecha?

Al comienzo en la máscara de red no debía “encenderse” bit a bit de izquierda a derecha, es decir, mascaradas como: 255.255.192.128 era completamente válidas. Esta configuración era aceptada por routers (IMPs -los primeros routers-) y diferentes sistemas operativos, entre ellos los BSDs y SunOSs antiguos. Es decir, hasta comienzos de los 90’s aún era posible tener máscaras de red de bits no continuos.

¿Por qué se decidió que los bits luego fueran obligatoriamente encendidos de izquierda a derecha?

Existieron varias razones, la principal tiene que ver con enrutamiento y el famoso concepto “longest match” que conocemos donde el router selecciona la ruta cuya máscara de subred sea la más larga que coincida con la dirección de destino del paquete. Es decir, si los bits no son continuos se crea una complejidad computacional muy alta. En resumen: eficiencia.

Desde esa época ya se agotaban direcciones IPv4

El agotamiento de recursos IPv4 no es algo nuevo, incluso en la primera sección del RFC 1338 en su numeral uno hace referencia al agotamiento de la Clase B indicando que la Clase C es demasiado pequeña para muchas organizaciones, y la Clase B es demasiado grande. Esto ocasionó una presión sobre el espacio de direcciones Clase B, agotando la misma. Y no solo eso, el mismo RFC en el numeral 3 cita textualmente: “Eventual exhaustion of the 32-bit IP address space” (1992).

CIDR aborda las soluciones de ayer, que se convirtieron en los problemas de ese momento

Al momento de crear las clases se crearon más redes lo que conlleva a más prefijos y a su vez mayor consumo de memoria y CPU. Por ello en septiembre de 1993 en el RFC 1519 apareció el concepto de CIDR, trayendo consigo soluciones a algunas situaciones, entre ellas, poder hacer supernetting (es decir, poder apagar bits de derecha a izquierda) e intentar reducir la cantidad de prefijos de red. Es importante destacar que el RFC 1338 también mantuvo conceptos similares.

Finalmente, la notación de prefijo (/nn) también aparece gracias a CIDR lo que se hace posible una vez más gracias a la continuidad de los bits encendidos y apagados de la máscara de red.

En resumen, el objetivo de CIDR era enlentecer el crecimiento de las tablas de enrutamiento y buscar ser más eficientes en la utilización del espacio de direcciones IP.



Timeline


Conclusiones

El concepto de máscara de red ha evolucionado notablemente desde su origen, desde su no-existencia en un esquema plano (flat), luego rígido a un modelo flexible con CIDR. Inicialmente, las redes classful y las máscaras discontinuas generaban ineficiencia y problemas de escalabilidad a medida que Internet crecía.

Un cambio clave fue la exigencia de continuidad en los bits encendidos, lo que simplificó el proceso de selección de rutas y permitió a los routers operar más eficientemente.

Este documento informativo resalta los hitos clave y las motivaciones detrás de la evolución del direccionamiento IP y enfatiza la importancia de comprender el contexto histórico para apreciar plenamente la arquitectura actual de Internet.

Referencias

RFC https://datatracker.ietf.org/doc/html/rfc1338
RFC https://datatracker.ietf.org/doc/html/rfc1380
RFC https://datatracker.ietf.org/doc/html/rfc1519
RFC https://datatracker.ietf.org/doc/html/rfc790
Hilo de la lista de correo de ISOC “Internet History” llamado “The netmask”: https://elists.isoc.org/pipermail/internet-history/2025-January/010060.html

jueves, 23 de febrero de 2023

El juego del dominó y TCP/IP

En mi vida, al igual que muchas personas, tengo varias pasiones: familia, trabajo, deporte; y en este último incluyo el hermoso juego del dominó. Hace unos 25 años alcancé mi mejor nivel en este juego, participé de varios torneos (ganando algunos pocos) y la guinda de la corona, obtuve un 6to lugar en un torneo nacional. Adicionalmente, menciono que vengo de una familia con alguna herencia de fanáticos del dominó, como lo eran dos tíos, mi padre y mi hermano.

Jugar dominó es una de las cosas más lindas entre familia, amigos y no tan amigos. Ahora bien, ¿en qué se parece el juego del dominó al protocolo TCP/IP? Alguno quizás ya debe estar pensando “Alejandro ahora sí se volvió loco”; quizás no me volví loco, probablemente ya lo estaba.

Pero ese no es el punto, te demostraré que TCP/IP y el dominó tienen mucho en común.

Los protocolos TCP/IP según IBM [1] lo definen como:

“Los protocolos son conjuntos de normas para formatos de mensaje y procedimientos que permiten a las máquinas y los programas de aplicación intercambiar información. Cada máquina implicada en la comunicación debe seguir estas normas para que el sistema principal de recepción pueda interpretar el mensaje.”

Suena interesante…, pero probablemente aún no veas qué tiene que ver con el dominó, y  sigues pensando que es una locura. ¡A no desesperar, ya vamos a llegar!

Y el Dominó (según chatgpt):

“El juego de dominó es un juego de mesa en el que los jugadores utilizan fichas con números en ambos extremos para colocarlas en un tablero. El objetivo del juego es colocar todas las fichas antes que los demás jugadores. La comunicación entre los jugadores en el juego de dominó se basa en la estrategia y en la planificación. Los jugadores deben comunicar qué fichas tienen y qué fichas pueden jugar, y deben trabajar juntos para encontrar la mejor manera de colocar las fichas en el tablero. Además, los jugadores deben estar atentos a las jugadas de los demás jugadores y adaptar su estrategia en consecuencia. En resumen, la comunicación en el juego de dominó es esencial para el éxito del equipo y para ganar el juego.”

Ahora, pensemos un poco macro, a estas alturas podemos apreciar que en ambos hay piezas que deben ser enviadas/jugadas, y las mismas deben mantener un orden para poder alcanzar una comunicación exitosa. Además, en ambos hay estrategia y planificación para lograr el objetivo, en uno se conectan las piezas y en el otro dispositivos, ¿ya comencé a convencerte?

Ahora hablemos de comunicación y el Dominó en parejas, y es aquí donde está el corazón del tema al que quiero llegar.

Independiente del estilo de dominó que cada uno juegue (Cubano, Latino, Méxicano, Chileno, etc) “el dominó en parejas” es un juego de comunicación, no es diferente a una red de datos. Un jugador tiene que comunicarse con su pareja (A → B, B → A) para indicarle qué piezas tiene o no.

Igualmente, ¿cómo me comunico si una de las reglas es no poder hablar?. Allí está la grandeza de los buenos jugadores, al igual que TCP/IP -y cualquier otro protocolo de comunicación- hay que seguir ciertas reglas.

Luego de mis tres décadas de experiencia en ambos mundos, aquí les dejo lo que considero los principales jugadas en el ecosistema del dominó en parejas y su contraparte en TCP/IP:

La salida en el dominó

La salida en el dominó (primera pieza que coloca el salidor) es idéntica a un SYN Packet de TCP (y más específicamente es un SYN con payload al estilo TCP Fast Open).  Esta es una comparación hermosa, porque la salida en el dominó por parejas *siempre* lleva información, generalmente se refiere al palo (número) que uno más desea. TCP Fast Open (una lindura del mundo de TCP) se encuentra definido en el RFC 7413 y su principal objetivo es poder enviar información en el primer paquete con en el que comienza toda comunicación TCP (SYN)

La pensada (double ACK)

Se considera payload no necesario en algunas redes pero puede valer la pena. La “pensada” de un jugador indica explícitamente que el jugador tiene más de una pieza del “palo” (número) jugado; con ello, el jugador está comunicando eficientemente información a su compañero quien debe darse notar estas pensadas, es muy similar a aquellos servidores y redes donde se configuran dispositivos para enviar más de un ACK en TCP (acuso de recibo)

Pasar (packet dropped)

En TCP al perder un paquete se entra en la fase de “Congestion Avoidance”, allí disminuye en un 50% la ventana TCP y por ende la velocidad de transmisión. Nada más similar al pasar en dominó; claro, aquí se entra en etapa de pánico, sobre todo cuando hay mucho que transmitir.

La versión

En el mundo de IP estamos acostumbrados a IPv4 e IPv6, en el dominó la única diferencia es que la versión va del 0 (blancas) al 6. (si, si, ciertamente existen Dominoes hasta 9, toda regla tiene su excepción ;-) 

Pensar en falso

TCP Half-Open, ¿se recuerdan?, es cuando en el saludo de tres vías (SYN, SYN+ACK, ACK) se queda en la mitad del saludo (ojo, este es el concepto moderno, en honor a la verdad no respeta RFC 793). También es comúnmente utilizado para realizar ataques de DoS.

Tamaño de la carga (Total Length)

Cuando vamos levantando nuestras fichas en dominó, ¿cuántos -puntos- cargué?.

La dirección origen y el destino

Aquí nos encontramos específicamente en el mundo de capa 3. Este es un caso muy interesante donde, al igual que en redes de comunicación, un host se comunica con algún otro. Lo mismo sucede en el dominó, es decir,  algunos paquetes pueden ir orientados al compañero; sin embargo, en algunos casos se puede orientar a los oponentes según la necesidad (ejemplo, cuando se busca “tal palo”).

Pensar en cada jugada

 Bufferbloat es una situación muy particular pero a su vez ocurre con mucha frecuencia. Básicamente son situaciones donde los hosts (principalmente middlewares al estilo, routers, firewalls, Switches) agregan delay (cargando los buffers) al momento de conmutar los paquetes. Lo anterior crea latencia y jitters innecesarios. Por favor, si administras redes no dejes de revisar si sufres de bufferbloat..

Trancar la partida/mano

 Es el momento donde ya es imposible jugar alguna pieza de dominó, y en TCP/IP supone la caída de la red, por lo que tampoco se puede enviar ningún paquete.

Consecuencias de la buena y mala comunicación

En dominó en pareja, al igual que en cualquier protocolo de red, comunicarse bien o mal trae sus consecuencias. Si uno tiene buena comunicación en el dominó alcanzará -muy seguramente- la victoria. Si la comunicación *no* es buena, el resultado será la pérdida del partido. En TCP/IP si la comunicación es buena se establecerá la conexión correctamente y se entregarán los datos. Si la comunicación es mala, obtendremos datos corruptos y/o el no establecimiento de la conexión.

Doble Cabeza

En el dominó se entiende que tienes doble cabeza cuando llevas la última pieza de dos números diferentes. ¿Con qué se puede comparar? Con TCP Multipath (MPTCP), definido en el RFC 8684.que permite operar conexiones por diferentes caminos. Es  por ello que MPTCP ofrece redundancia y eficiencia en el ancho de banda a consumir.

¿Aún no los convencí? Bueno, tengo una oportunidad más a ver si lo logro.

A continuación les presento un modelo capa a capa entre TCP/IP vs dominó

Modelo TCP/IP (+ capa de usuario)Modelo Dominó
UsuarioJugador
AplicaciónConstruir la jugada
TransporteSeleccionar la ficha/piedra
RedTomar las piedras
EnlacePiedras/Fichas
FísicaColocar en la mesa la ficha

Un paquete en el modelo TCP/IP se construye desde las capas superiores a las inferiores (posteriormente se inyecta a la red, etc), lo recibe el host destino y lo procesa “a la inversa”, desde la capa física hasta la aplicación. En el modelo dominó, ocurre exactamente igual: el jugador arma su jugada, selecciona su ficha/piedra, la toma para luego inyectarla en el juego.

Conclusión

La comparación entre el juego de dominó en parejas y el protocolo de comunicación TCP/IP puede parecer extraña al principio. Sin embargo,  si observamos con atención, podemos encontrar similitudes, En el dominó  existen dos jugadores que actúan como emisores y receptores de información, ya que cada uno tiene su propio conjunto de fichas y deben comunicarse entre sí para decidir qué ficha jugar en cada turno. Del mismo modo, en TCP/IP existen dispositivos que actúan como emisores y receptores de información.

Estos contrastes ilustran cómo a menudo pueden existir similitudes entre sistemas aparentemente disímiles, y que comprender estas semejanzas pueden ser útiles para entender conceptos complejos y ver las cosas desde una perspectiva diferente.

miércoles, 11 de abril de 2018

Identificando servidores DNS IPv6 Open Resolvers

Introducción

Como muchos de ustedes saben, tener servidores DNS Open Resolvers es muy negativo, tanto para el que deja el servicio abierto como para la seguridad en Internet en general.
Este tipo de servidores se utilizan como vector de ataques de DDoS por amplificación ya que a partir de un mensaje de consulta de pequeño tamaño, se puede obtener una respuesta mucho mayor. De esta manera, ese servidor DNS se convierte en un amplificador de tráfico muy potente ya que sus consultas amplificadas pueden dirigirse a una IP específica, la cual recibiría todo ese volumen de tráfico, ocasionándole indisponibilidad de sus servicios. Para este ataque ni siquiera es necesario que el hardware esté controlado por el atacante.
Este es un problema que en WARP nos preocupa porque hemos recibido mucho reportes de incidentes relacionados a esta vulnerabilidad. Por esta razón en conjunto con el área de I+D estamos llevando a cabo un proyecto con el objetivo de conocer el estado actual de la región, identificar los open resolvers y de forma proactiva alertar y recomendar una posible corrección de la configuración de este servicio.

Identificando un DNS Open Resolvers en IPv6 (DNS abiertos)

Identificar servidores Open Resolvers o servidores DNS abiertos en el mundo de IPv4 es muy sencillo, debido a la poca longitud del espacio de IPv4 (2**32).
En el mundo de IPv6 es imposible poder verificar cada una de las direcciones IP y ejecutar una prueba de Open Resolver. Dicha prueba puede durar miles de años.

¿Cómo se identifica un DNS Open Resolver?

Un servidor DNS recursivo solo debería responder consultas (queries) a todos los clientes que se encuentren dentro de su misma red y debería rechazar cualquier otra que provenga de fuera. Por ejemplo, los servidores DNS del ISP ACME solo deberían responder a consultas de sus propios clientes, a más nadie.
La identificación se hace realizando una consulta de un nombre de dominio a los servidores DNS. En caso que el servidor DNS responde con una respuesta válida, entonces es considerado Open Resolver. Si por el contrario, devuelve un rechazo (Query refused) o sencillamente hace timed out se encuentra bien configurado, por lo que no es un Open Resolver.

¿Cómo se consiguen los resolvers de IPv6?

LACNIC administra un servidor que puede ser llamado: Root Server Reverso, específicamente la letra “D”, es decir, d.ip6-servers.arpa. Gran cantidad de consultas a direcciones IP reversas de la región de LACNIC pasan a través de este servidor, en líneas generales este servidor SOLO recibe consultas de servidores DNS. Aquí es donde obtienen las direcciones IPv6 de los DNS que realizan consultas.

Procedimiento & Algoritmo

    1. En el servidor actualmente se realiza una captura de 2.5 millones de paquetes con el filtro del puerto 53 y destinados únicamente a la dirección IP de dicho equipo.
    2. De la captura anterior se ubican solo direcciones IPv6 origen (se eliminan paquetes mal formados, errores, etc). Se desprecia menos de 1% de los paquetes
    3. De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
    4. Un script toma cada dirección IPv6 del listado del punto 3, y realiza una consulta a la dirección www.lacnic.net hacia esa dirección, verifica recursividad y el estado de la respuesta.
    5. En caso de ser un Open Resolver dicha dirección IP quedará registrada para su posterior análisis y notificación a la organización responsable de ese recurso.

Diagrama de bloques

Vista de los Resultados

Conclusiones Primarias

Para esta primera instancia, observamos aproximadamente unos 33,514 registros de consultas realizadas al Root Server Reverso “D” administrado por LACNIC.
Luego de analizar estos primeros datos obtenidos, observamos que la región más afectada por servidores open resolver sería la de APNIC con el 19.23% de los datos obtenidos para esa zona. Para la región de Ripe obtuvimos la mayor cantidad de información, curiosamente el porcentaje de servidores mal configurados es casi insignificante (0.93%).
En lo que respecta a nuestra región detectamos 39 open resolvers (4.56%) de los 817 registros recolectados, donde existen solo 3 casos que la dirección IP se repite más de una vez.

Estudios similares

Referencias

Para leer sobre Open Resolvers se recomienda este link: https://www.certsi.es/blog/dns

Realizado por:

Dario Gomez & Alejandro Acosta


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

miércoles, 23 de septiembre de 2015

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

¿Qué historia hay detrás de las famosas máscaras de red?

Introducción ¿Recuerdas cuando estabas aprendiendo de máscaras de red? Seguro llegaste a pensar: “no sirven para nada”, “no las voy a necesi...