Puede estar familiarizado con NetFlow, IPFIX y otros protocolos similares como J-Flow y sFlow. Estos protocolos proporcionan información útil sobre la combinación de tráfico y las comunidades de interés. Sin embargo, estos protocolos no contienen los detalles de la capa de aplicación que desean algunos administradores. Los administradores de TI necesitan una mayor visibilidad a nivel de aplicación para poder realizar Application Performance Management (APM) y solucionar problemas de la capa de aplicación. Los protocolos actuales basados en el flujo carecen de detalles de la capa de aplicación que son necesarios para realizar un análisis más profundo y solucionar problemas.
Lección de historia de NetFlow:
En la década de 1990, NetFlow versión 5 comenzó como un protocolo propietario de Cisco Systems para capturar y enviar información sobre los flujos de tráfico de red a un punto de recolección. NetFlow se puede habilitar en dispositivos de red que utilizan Cisco Press Forwarding (CEF). El dispositivo habilitado para NetFlow captura información sobre flujos de red IP que atraviesan la interfaz y envía los datos sobre los flujos en paquetes UDP a un sistema colector. El recopilador NetFlow suele ser una computadora que ejecuta el software de recopilación y análisis. NetFlow se ha vuelto muy popular en la última década y ahora hay una multitud de compañías que admiten NetFlow en sus dispositivos y muchas compañías que hacen las utilidades de recolección y análisis de NetFlow.
Debido a la sobrecarga de procesamiento adicional requerida para admitir NetFlow, no era adecuado para su uso en muchos dispositivos de red. Cisco desarrolló Sampled NetFlow, Deterministic Netflow y Random Sampled NetFlow para reducir la sobrecarga de ejecutar NetFlow en dispositivos ocupados, pero aún así obtener cierta visibilidad del tráfico. Más tarde, Cisco desarrolló Flexible NetFlow que permite enviar datos de capa 2, IPv6 y otros tipos a un recopilador.
NetFlow e IPFIX:
Cuando NetFlow comenzó a ganar popularidad, la versión 9 de NetFlow agregó detalles de flujo para redes MPLS y flujos de datos IPv6. NetFlow comenzó como un protocolo propietario de Cisco, pero fue documentado en un RFC 3954 informativo de IETF en 2004. El IETF comenzó a trabajar en el Protocolo de Internet de Información de Flujo eXport (IPFIX) en 2004. Los requisitos de IPFIX se documentaron por primera vez en RFC 3917. De hecho, NetFlow v9 fue la base del estándar IETF IPFIX. El hecho es que IPFIX y NetFlow v9 comparten muchos tipos de campo. NetFlow e IPFIX se unieron en NetFlow v10 y se estandarizaron con RFC 5101, RFC 5102, RFC 5103 y RFC 5655. El modelo de información de IPFIX se actualizó con RFC 6313. IPFIX se ha actualizado ahora en los siguientes RFC 7011, 7012, 7013, 7014 de IETF. y 7015. Muchos productos de proveedores ahora admiten IPFIX.
Otros protocolos de exportación de flujo:
Debido a que NetFlow fue visto inicialmente como un método de flujo patentado por Cisco, otros proveedores querían desarrollar sus propios protocolos o colaborar en protocolos de flujo más "abiertos" para trabajar en su propio hardware. Existen muchos otros protocolos de análisis de tráfico de red basados en el flujo y algunos solo los utiliza un único proveedor..
J-Flow v5 / v8 / v9 es un protocolo de monitoreo basado en flujo desarrollado por Juniper Networks. Se ejecuta en sus dispositivos JUNOS y J-Flow es interoperable con los colectores compatibles con NetFlow.
sFlow es otro protocolo de muestreo de paquetes que envía información sobre flujos a un recopilador. sFlow es respaldado por una organización de la industria que ayuda a impulsar la adopción del protocolo. La diferencia entre sFlow y otros protocolos de exportación de flujo es que puede realizar un muestreo de paquetes en lugar de solo una exportación basada en flujo. El muestreo de paquetes puede mejorar el rendimiento de la técnica al reducir la carga de sobrecarga en el dispositivo de red. La versión 5 de sFlow tiene un amplio soporte de proveedores.
NetStream es otro protocolo de exportación basado en flujo utilizado por 3Com / HP / Huawei.
Ericsson también tiene su propio protocolo RFlow.
Los sistemas OpenBSD pueden usar pflow (flujo de pseudodispositivo) como su método para exportar datos de flujo. pFlow es compatible con NetFlow v5 / v9 y v10 (IPFIX).
Limitaciones de los protocolos de flujo de red:
La limitación con todos los protocolos de análisis de red basados en flujo es que carecen de granularidad en el tráfico. Nada proporciona más detalles sobre el tráfico que la decodificación de protocolo real con un analizador de protocolos. Sin embargo, capturar paquetes sin procesar puede ser una carga de rendimiento en un dispositivo de red y almacenar toda esa información podría ser costoso. La captura de paquetes puede ser una opción viable para la resolución de problemas y las pruebas de corta duración, pero no es una solución sostenible para la planificación de capacidad, tendencias y análisis a largo plazo..
Además, la capacidad de realizar capturas de paquetes en muchos puntos a través de la topología de red no suele ser una opción. Configurar un mayor número de tomas de conexiones SPAN / puerto espejo podría ser imposible. No siempre tiene un conmutador de supervisión de paquetes listo o un controlador de red extensible de Cisco (XNC) que ejecuta la aplicación Monitor Manager con los conmutadores Nexus 3000 ya configurados.
Hoy también estamos experimentando una cara cambiante de la topología de TI. Los sistemas que solían estar ubicados dentro de las propias instalaciones de una empresa ahora se han trasladado a la infraestructura basada en la nube. No todas las aplicaciones están ubicadas de forma segura en el centro de datos corporativo y se accede a través de la WAN corporativa interna. Esto hace que realizar análisis de protocolo de aplicaciones basadas en la nube sea más difícil de realizar. También nos falta la capacidad de realizar capturas de paquetes en servicios basados en la nube o en plataformas de virtualización. Como resultado, muchas aplicaciones carecen de la visibilidad que necesitan para poder realizar un análisis detallado de la aplicación o solucionar problemas.
Resumen:
Las empresas necesitan mejores formas de poder comprender el tráfico de aplicaciones que atraviesa sus sistemas locales y basados en la nube. NetFlow e IPFIX son útiles, pero carecen de la granularidad de una captura de protocolo completa. Sin embargo, la captura de tráfico sin procesar puede no ser una opción según la topología. Cada vez más problemas de rendimiento relacionados con las aplicaciones requerían más visibilidad para poder solucionar problemas. Hay otros protocolos que pueden estar disponibles que nos dan la visibilidad que deseamos..
En la segunda parte de este artículo cubriremos un nuevo protocolo de análisis de flujo que proporciona esta información útil..
Scott
Únase a las comunidades de Network World en Facebook y LinkedIn para comentar temas que son lo más importante.
