NetFlow es una función que se introdujo en los enrutadores Cisco alrededor de 1996 y que brinda la capacidad de recopilar tráfico de red IP a medida que ingresa o sale de una interfaz. Al analizar los datos proporcionados por NetFlow, un administrador de red puede determinar aspectos como el tráfico de origen y destino, la clase de servicio y las causas de la congestión. Una configuración típica de monitoreo de flujo (que utiliza NetFlow) consta de tres componentes principales: [1]
Los enrutadores y conmutadores que admiten NetFlow pueden recopilar estadísticas de tráfico IP en todas las interfaces donde NetFlow está habilitado y luego exportar esas estadísticas como registros NetFlow hacia al menos un recopilador NetFlow, generalmente un servidor que realiza el análisis de tráfico real .
La versión 5 del estándar Cisco NetFlow define un flujo como una secuencia unidireccional de paquetes que comparten siete valores que definen una clave única para el flujo: [2]
Tenga en cuenta que la interfaz de salida, el siguiente salto de IP o los siguientes saltos de BGP no son parte de la clave y pueden no ser precisos si la ruta cambia antes de que expire el flujo o si el equilibrio de carga se realiza por paquete.
Esta definición de flujos también se utiliza para IPv6, y se utiliza una definición similar para los flujos MPLS y Ethernet .
Las implementaciones avanzadas de NetFlow o IPFIX como Cisco Flexible NetFlow permiten claves de flujo definidas por el usuario.
Una salida típica de una herramienta de línea de comandos de NetFlow ( nfdumpen este caso) al imprimir los flujos almacenados podría verse así:
Fecha de inicio del flujo Duración Protocolo Dirección IP de origen: Puerto Dirección IP de destino: Puerto Paquetes Bytes Flujos 01-09-2010 00:00:00.459 0.000 UDP 127.0.0.1:24920 -> 192.168.0.1:22126 1 46 1 01-09-2010 00:00:00.363 0.000 UDP 192.168.0.1:22126 -> 127.0.0.1:24920 1 80 1
El enrutador generará un registro de flujo cuando determine que el flujo ha finalizado. Esto se logra mediante el envejecimiento del flujo: cuando el enrutador detecta tráfico nuevo para un flujo existente, restablece el contador de envejecimiento. Además, la finalización de la sesión TCP en un flujo TCP hace que el enrutador expire el flujo. Los enrutadores también se pueden configurar para generar un registro de flujo en un intervalo fijo incluso si el flujo aún está en curso.
Los registros NetFlow se exportan tradicionalmente mediante el Protocolo de datagramas de usuario ( UDP ) y se recopilan mediante un recopilador NetFlow. La dirección IP del recopilador NetFlow y el puerto UDP de destino deben configurarse en el enrutador de envío. Un valor común es el puerto UDP 2055, pero también se pueden utilizar otros valores como 9555 o 9995, 9025, 9026, etc.
Por razones de eficiencia, el enrutador tradicionalmente no lleva un registro de los registros de flujo ya exportados, por lo que si se descarta un paquete NetFlow debido a una congestión de la red o a una corrupción de paquetes, todos los registros que contiene se pierden para siempre. El protocolo UDP no informa al enrutador de la pérdida para que pueda volver a enviar los paquetes. Esto puede ser un verdadero problema, especialmente con NetFlow v8 o v9 que pueden agregar muchos paquetes o flujos en un solo registro. La pérdida de un solo paquete UDP puede causar un gran impacto en las estadísticas de algunos flujos.
Por este motivo, algunas implementaciones modernas de NetFlow utilizan el protocolo de transmisión de control de flujo ( SCTP ) para exportar paquetes, con el fin de brindar cierta protección contra la pérdida de paquetes y asegurarse de que se reciban las plantillas de NetFlow v9 antes de exportar cualquier registro relacionado. Tenga en cuenta que TCP no sería adecuado para NetFlow porque un orden estricto de los paquetes provocaría un almacenamiento en búfer excesivo y demoras.
El problema con SCTP es que requiere interacción entre cada recopilador NetFlow y cada enrutador que exporta NetFlow. Puede haber limitaciones de rendimiento si un enrutador tiene que lidiar con muchos recopiladores NetFlow y un recopilador NetFlow tiene que lidiar con muchos enrutadores, especialmente cuando algunos de ellos no están disponibles debido a fallas o mantenimiento.
Es posible que SCTP no sea eficiente si NetFlow debe exportarse hacia varios recopiladores independientes, algunos de los cuales pueden ser servidores de prueba que pueden dejar de funcionar en cualquier momento. UDP permite una replicación simple de paquetes NetFlow mediante tomas de red o duplicación L2 o L3. Un equipo simple sin estado también puede filtrar o cambiar la dirección de destino de los paquetes UDP de NetFlow si es necesario. Dado que la exportación de NetFlow casi solo utiliza enlaces de red troncal, la pérdida de paquetes a menudo será insignificante. Si ocurre, será principalmente en el enlace entre la red y los recopiladores NetFlow.
Todos los paquetes NetFlow comienzan con un encabezado dependiente de la versión, que contiene al menos estos campos:
Un registro de NetFlow puede contener una amplia variedad de información sobre el tráfico en un flujo determinado.
La versión 5 de NetFlow (una de las versiones más utilizadas, seguida de la versión 9) contiene lo siguiente:
Para los flujos ICMP , el puerto de origen es cero y el campo de número de puerto de destino codifica el tipo y código del mensaje ICMP (puerto = tipo ICMP * 256 + código ICMP) [ cita requerida ] .
Los campos de número de sistema autónomo (AS) de origen y destino pueden informar el AS de destino (último AS de la ruta AS) o el AS vecino inmediato (primer AS de la ruta AS) según la configuración del enrutador. Pero el número de AS será cero si la función no es compatible, la ruta es desconocida o no está anunciada por BGP, o el AS es el AS local. No hay una forma explícita de distinguir entre estos casos.
La versión 9 de NetFlow puede incluir todos estos campos y, opcionalmente, puede incluir información adicional, como etiquetas de conmutación de etiquetas multiprotocolo (MPLS) y direcciones y puertos IPv6 .
Al analizar los datos de flujo, se puede crear una imagen del flujo y el volumen de tráfico en una red. El formato de registro NetFlow ha evolucionado con el tiempo, de ahí la inclusión de números de versión. Cisco mantiene detalles de los diferentes números de versión y el diseño de los paquetes para cada versión.
NetFlow generalmente se habilita por interfaz para limitar la carga en los componentes del enrutador involucrados en NetFlow o para limitar la cantidad de registros de NetFlow exportados.
NetFlow generalmente captura todos los paquetes recibidos por una interfaz IP de ingreso, pero algunas implementaciones de NetFlow usan filtros IP para decidir si NetFlow puede observar un paquete.
Algunas implementaciones de NetFlow también permiten la observación de paquetes en la interfaz IP de salida, pero esto debe usarse con cuidado: todos los flujos desde cualquier interfaz de ingreso con NetFlow habilitado a cualquier interfaz con NetFlow habilitado podrían contarse dos veces.
El estándar NetFlow fue diseñado para procesar todos los paquetes IP en una interfaz. Pero en algunos entornos, por ejemplo en las redes troncales de Internet, esto era demasiado costoso debido al procesamiento adicional requerido para cada paquete y a la gran cantidad de flujos simultáneos.
Cisco introdujo NetFlow muestreado en Cisco 12000 , y ahora se utiliza en todos los enrutadores de alta gama que implementan NetFlow.
Solo se procesa un paquete de n , donde n , la frecuencia de muestreo, está determinada por la configuración del enrutador.
El proceso de selección exacto depende de la implementación:
Algunas implementaciones tienen métodos más complejos para muestrear paquetes, como el muestreo por flujo en Cisco Martinez Catalyst.
La frecuencia de muestreo suele ser la misma para todas las interfaces, pero se puede ajustar por interfaz para algunos enrutadores. Cuando se utiliza NetFlow muestreado, los registros de NetFlow se deben ajustar para el efecto del muestreo: los volúmenes de tráfico, en particular, ahora son una estimación en lugar del volumen de flujo medido real.
La frecuencia de muestreo se indica en un campo de encabezado de la versión 5 de NetFlow (la misma frecuencia de muestreo para todas las interfaces) o en registros de opciones de la versión 9 de NetFlow (frecuencia de muestreo por interfaz).
NetFlow fue implementado inicialmente por Cisco y descrito en un documento "informativo" que no estaba en la vía de estándares: RFC 3954 – Exportación de servicios NetFlow de Cisco Systems versión 9. El protocolo NetFlow en sí ha sido reemplazado por Internet Protocol Flow Information eXport ( IPFIX ). Basado en la implementación de NetFlow versión 9, IPFIX está en la vía de estándares de IETF con RFC 5101 (obsoleto por RFC 7011), RFC 5102 (obsoleto por RFC 7012), etc., que se publicaron en 2008.
Muchos otros proveedores además de Cisco ofrecen una tecnología de monitoreo de flujo de red similar. NetFlow puede ser un nombre predominante en el área de monitoreo de flujo, debido a la participación dominante de Cisco en el mercado de la industria de redes. Se cree que NetFlow es una marca registrada de Cisco (aunque a marzo de 2012 no figura en la lista de marcas registradas de Cisco [3] ):
Además, la colección de software flow-tools [5] permite procesar y gestionar las exportaciones de NetFlow desde los enrutadores Cisco y Juniper. [6]
NetFlow Security Event Logging , que se presentó con el lanzamiento de los productos Cisco ASA 5580, utiliza campos y plantillas NetFlow v9 para ofrecer de manera eficiente telemetría de seguridad en entornos de alto rendimiento. NetFlow Security Event Logging escala mejor que syslog y ofrece el mismo nivel de detalle y granularidad en los eventos registrados. [ cita requerida ]
La recopilación de datos de NetFlow mediante sondas independientes de NetFlow es una alternativa a la recopilación de datos de enrutadores y conmutadores. Este enfoque puede superar algunas limitaciones de la monitorización de NetFlow basada en enrutadores. Las sondas se conectan de forma transparente al enlace monitorizado como un dispositivo pasivo mediante el puerto TAP o SPAN del dispositivo.
Históricamente, la monitorización de NetFlow es más sencilla de implementar en una sonda dedicada que en un enrutador. Sin embargo, este enfoque también tiene algunas desventajas:
La forma más sencilla de solucionar los inconvenientes mencionados anteriormente es utilizar un dispositivo de captura de paquetes en línea frente al enrutador y capturar toda la salida NetFlow del enrutador. Este método permite almacenar una gran cantidad de datos NetFlow (normalmente, datos de muchos años) y no requiere reconfigurar la red.
La recopilación de NetFlow desde sondas dedicadas es ideal para la observación de enlaces críticos, mientras que NetFlow en enrutadores proporciona una vista de toda la red del tráfico que se puede utilizar para planificación de capacidad, contabilidad, monitoreo de rendimiento y seguridad.
NetFlow fue originalmente una tecnología de conmutación de paquetes de Cisco para enrutadores Cisco, implementada en IOS 11.x alrededor de 1996. Originalmente era una implementación de software para Cisco 7000, 7200 y 7500, [19] donde se pensó como una mejora sobre el Cisco Fast Switching vigente en ese momento. Netflow fue inventado por Darren Kerr y Barry Bruin [20] de Cisco (patente estadounidense n.° 6 243 667).
La idea era que el primer paquete de un flujo creara un registro de conmutación NetFlow. Este registro se utilizaría entonces para todos los paquetes posteriores del mismo flujo, hasta la expiración del flujo. Solo el primer paquete de un flujo requeriría una investigación de la tabla de rutas para encontrar la ruta coincidente más específica. Esta es una operación costosa en las implementaciones de software, especialmente las antiguas sin base de información de reenvío . El registro de conmutación NetFlow era en realidad una especie de registro de caché de ruta, y las versiones antiguas de IOS todavía se refieren a la caché NetFlow como ip route-cache .
Esta tecnología era ventajosa para las redes locales, especialmente si una ACL debía filtrar parte del tráfico, ya que solo el primer paquete de un flujo debía ser evaluado por la ACL. [21]
La conmutación NetFlow pronto resultó ser inadecuada para enrutadores grandes, especialmente enrutadores troncales de Internet, donde la cantidad de flujos simultáneos era mucho más importante que en las redes locales, y donde cierto tráfico causa muchos flujos de corta duración, como las solicitudes del Sistema de nombres de dominio (cuyo puerto de origen es aleatorio por razones de seguridad).
Como tecnología de conmutación, NetFlow fue reemplazado alrededor de 1995 por Cisco Express Forwarding . Esta tecnología apareció por primera vez en los enrutadores Cisco 12000 y luego reemplazó a la conmutación NetFlow en el IOS avanzado de Cisco 7200 y Cisco 7500.
A partir de 2012, las tecnologías similares a la conmutación NetFlow todavía se utilizan en la mayoría de los cortafuegos y enrutadores IP basados en software. Por ejemplo, la función conntrack del marco Netfilter que utiliza Linux .