Problema
Después de la instalación del ktranslate
Monitoreo de red agente, tienes problemas para recopilar la telemetría del flujo de red.
Fondo
ktranslate
devuelve la telemetría de flujo sin procesar recopilada, sin editar ninguna carga útil del paquete. Hay varios tipos de flujo admitidos de fábrica, siendo los más destacados NetFlow v5, NetFlow v9, sFlow e IPFIX.
Toda la telemetría del flujo de red se almacena en el tipo de evento KFlow. Puedes consultar esto directamente en NRQL. Si este tipo de evento está ausente, eso indica que su cuenta no está recibiendo los datos.
FROM KFlow SELECT *
Solución
El agente ktranslate
solo puede recopilar un tipo de plantilla de flujo configurada por el argumento -nf.source en tiempo de ejecución, cuyo valor predeterminado es auto
. Esto le indica ktranslate
que espere cualquier plantilla de NetFlow v5
| NetFlow v9
| sFlow
| IPFIX
para que pueda traducir los paquetes. Un problema común es configurar ktranslate
para que escuche un tipo específico de plantilla de flujo y luego exportar otro tipo al agente. Debe ejecutar un contenedor separado para cualquier plantilla que no esté cubierta por auto
.
Otro error común aquí es exportar su telemetría de flujo a un agente ktranslate
, mientras apunta a múltiples puertos como destino. En este escenario, necesita ejecutar varios agentes ktranslate
, cada uno configurado con un valor diferente para -nf.port en tiempo de ejecución (el valor predeterminado es 9995
). Es posible que también necesite actualizar la configuración del exportador de flujo en sus dispositivos de red de origen para apuntar a su puerto específico.
Cada proveedor tendrá su propia documentación sobre cómo configurar correctamente sus dispositivos para la exportación de flujos de red. Las versiones más avanzadas como NetFlow v9
, IPFIX
y sFlow
tienen opciones que permiten al administrador personalizar los campos que se recopilan y exportan. Editarlos puede deshabilitar efectivamente la capacidad de procesar correctamente los registros de flujo por parte de ktranslate
.
Los siguientes campos son required:
- Protocolo (Número de tipo de campo:
4
): protocolo de capa 4 - Dirección de origen (número de tipo de campo:
8
,27
): dirección IPv4 o IPv6 de origen - Puerto de origen (número de tipo de campo:
7
): puerto TCP/UDP de origen - Dirección de destino (Número de tipo de campo:
12
,28
): dirección IPv4 o IPv6 de destino - Puerto de destino (Número de tipo de campo:
11
): puerto TCP/UDP de destino
- Recepción de interfaz (número de tipo de campo:
10
): índice SNMP para la interfaz de ingreso - Transmisión de interfaz (número de tipo de campo:
14
): índice SNMP para la interfaz de salida
- Bytes delta (número de tipo de campo:
1
) - Bytes delta - Bytes totales (número de tipo de campo:
85
) - Bytes totales - Bytes de salida (Número de tipo de campo:
23
) - Bytes de salida - Octetos del iniciador (número de tipo de campo:
231
): bytes del iniciador - Octetos de respuesta (número de tipo de campo:
232
): bytes de respuesta
- Paquetes delta (número de tipo de campo:
2
): paquetes delta - Paquetes totales (Número de tipo de campo:
86
) - Paquetes totales - Paquetes de salida (Número de tipo de campo:
24
) - Paquetes de salida - Paquetes iniciadores (número de tipo de campo:
298
): paquetes iniciadores - Paquetes de respuesta (número de tipo de campo:
299
): paquetes de respuesta
- ToS (Número de tipo de campo:
5
) - Tipo de servicio - AS de origen (Número de tipo de campo:
16
): número del sistema autónomo BGP de origen - AS de destino (Número de tipo de campo:
17
): número del sistema autónomo BGP de destino - AS de origen del mismo nivel (Número de tipo de campo:
129
): número del sistema autónomo BGP de origen del mismo nivel - AS de destino del mismo nivel (Número de tipo de campo:
128
): número del sistema autónomo BGP de destino del mismo nivel
Sugerencia
ktranslate
De forma predeterminada, todos los registros de flujo son Direction: ingress
a menos que el registro utilice explícitamente un valor de egress
. Esto cubre varias situaciones en las que los registros de flujo se envían sin el campo Direction
.
Cada proveedor tendrá su propia documentación sobre cómo observar los contadores de exportación de flujo a través de la CLI/UI de su dispositivo. La falta de crecimiento del contador en el dispositivo indica que la exportación de flujo no está configurada correctamente en el dispositivo.
Tanto el contenedor docker como las opciones de implementación del servicio Linux para ktranslate
utilizan la red del host para recibir datos en el puerto asignado. Para validar que el host reciba los registros de flujo, puede usar la utilidad tcpdump para crear un archivo de captura de paquetes (.pcap
) que luego puede investigar en Wireshark.
La ejecución de este comando configurará tcpdump
para capturar cada paquete entrante en todas las interfaces del host y escribirá el resultado en un archivo en el directorio actual:
$sudo tcpdump -s 0 -i any -w dump_capture.pcap
Tenga en cuenta que puede agregar varios argumentos a tcpdump; el elemento más importante aquí es el archivo de salida que puede usar para analizarlo más adelante. Generar los resultados en STDOUT
crea un valor limitado para los propósitos actuales.
Una vez que tenga este archivo, la siguiente sección le mostrará cómo analizar los resultados.
Sugerencia
Uno de los problemas más comunes encontrados es una regla de configuración de red/firewall que bloquea los paquetes desde los dispositivos de red de origen al host de destino ktranslate
. Si no obtiene ningún resultado con la utilidad tcpdump
, el mejor lugar para comenzar a resolver los problemas es confirmar las reglas de su red y la configuración de iptables
.
Siga estos pasos para utilizar Wireshark para inspeccionar el archivo de captura de paquetes.
Inicie la aplicación Wireshark y abra el archivo de captura de paquetes
La vista inicial muestra todos los paquetes capturados, pero para el análisis de flujo deberá configurar la aplicación para que los decodifique correctamente. Usando el menú, navegue hasta Analyze > Decode As...
, lo que abre una nueva ventana emergente.
En la ventana emergente, haga clic en el ícono más (+
) en la parte inferior izquierda, lo que agregará una nueva fila al panel. La opción inicial en la columna Current
es (none)
. Haga clic aquí para abrir un menú desplegable y luego seleccione CFLOW
para NetFlow
y IPFIX
, o sFlow
para sFlow
paquetes. Haga clic en OK
en la parte inferior derecha para volver a la UI principal.
Sugerencia
Este menú está ordenado alfabéticamente con distinción entre mayúsculas y minúsculas. La opción sFlow
se encuentra al final de la lista.
En la UI principal, debería poder ver CFLOW
| sFlow
paquetes ahora identificándolos en la columna Protocol
. La aplicación del filtro de visualización (cflow or sflow)
aislará automáticamente los paquetes que necesita de cualquier otra cosa que pueda estar en el archivo de captura.
Las siguientes secciones describen cómo inspeccionar cada tipo de paquete.
NetFlow
y los protocolos IPFIX
utilizan un enfoque de plantilla donde el administrador puede identificar qué campos recopilar, de una lista de opciones estándar. El análisis de estos paquetes se realiza para garantizar que se capturen los campos obligatorios para ktranslate
.
En la UI principal de Wireshark, haga clic para seleccionar un único paquete CFLOW
y luego expanda la sección titulada FlowSet n
, donde n
es un número entero que identifica un registro de flujo singular en un paquete. Luego expandirá el subgrupo Flow n
para analizar los campos de este registro de flujo.
Sugerencia
También puede hacer clic en el enlace Template Frame
del paquete para acceder a un paquete capturado que contiene la plantilla para todos los flujos desde este dispositivo.
Debido a las diferencias de protocolo entre sFlow
y los protocolos más tradicionales NetFlow/IPFIX
, existen diferentes campos para analizar.
En la UI principal de Wireshark, haga clic para seleccionar un único paquete sFlow
y luego expanda la sección titulada InMon sFlow
. Los siguientes campos deben estar presentes:
Campo | Descripción |
---|---|
Versión de datagrama | La versión de este paquete sFlow. |
Tipo de dirección del agente | IPv4 (1) o IPv6 (2) |
Dirección del agente | Dirección IP desde la que se exportan los flujos. Aquí es donde tienes configurado tu exportador de flujo. |
ID de subagente | En sFlow v5, puede ejecutar múltiples procesos de exportación. Este es su identificador único. |
Secuencia de números | La cantidad de paquetes sFlow enviados por el dispositivo agente. |
SysUptime | Tiempo desde la última vez que se reinició el dispositivo del agente. |
NúmMuestras | El recuento de muestras de sFlow contenidas en el paquete actual. |
Al expandir un subgrupo titulado Flow sample
se mostrarán estos campos adicionales:
Campo | Descripción |
---|---|
Empresa | Este campo anota la configuración empresarial de sFlow personalizada que el administrador puede habilitar opcionalmente al configurar sus exportaciones de sFlow. ( |
Tipo de muestra de sFlow | Esta es la designación del tipo de muestra que se utiliza cuando una empresa personaliza sus exportaciones de sFlow. Puede encontrar definiciones en la documentación de sFlow. |
Longitud de la muestra | Longitud de la muestra, en bytes. |
Secuencia de números | El valor del contador aumenta cada vez que el agente toma una muestra. |
Tasa de muestreo | Se muestrean 1 de cada |
Conjunto de muestras | Total de paquetes posibles que podrían haberse muestreado, incluidos los paquetes muestreados reales. |
Paquetes caídos | Número de paquetes que se descartaron debido a limitaciones de recursos. |
Interfaz de entrada | SNMP ifIndex de la interfaz desde la que llegó el paquete. |
Registro de flujo | Número de registros muestreados contenidos en esta muestra. |
Sugerencia
Este mismo patrón, sin el paso Decode as...
, se puede aplicar para validar la recepción de datos de captura syslog y SNMP.