Agregando un APC ATS AP7750 al Homelab.

A mis manos acaba de llegar un AP7750 (Gracias ebay) esta cosa pesa más de 10 libras!

Desde hace tiempo buscaba un equipo APC tipo PDU, bueno en realidad buscaba un PDU con puerto de monitoreo donde pudiera ver Amps o Watts consumidos. El ATS hace gran parte de lo que necesito y otras que no necesitaba.

Output Current: 4.0 Amps …. ouch!

 

Lo primero que he intentado es sacar métricas de este vejestorio. Lamentablemente estamos hablando de un equipo con más de 10 años de fabricación y que ya APC ha declarado EOL, en el área de SNMP solo soporta v1 y no sé si esta es la razón por la cual no me está mostrando los Amps en LibreNMS.

Lo interesante es que si hago un snmpwalk encuentro el OID con el valor de Amps consumidos, seguiré investigando ya que necesito saber el consumo en Amps que esta cosa llamada Homelab está usando.

Aquí una captura de la información generada en LibreNMS la cual no es muy útil aun.

Capturando paquetes en ESXi para diagnosticar errores en flowAnalyzer.

He estado investigando por qué cuando se envían datos IPFIX desde un vDS en vSphere el proceso que supone que recibe estos paquetes simplemente muere y reinicia sus operaciones, nada de la información enviada por el vDS se registra en los Index de Kibana.

Sometí un ticket al desarrollador de flowAnalyzer y quien a su vez me solicito un PCAP de los datos generados, en Linux esto se consigue con tcpdump, en Windows con Wireshark pero en ESXi ¿?

Que tenemos a disposición en ESXi para crear un PCAP?

Tenemos pktcap-uw!

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051814

Entonces, para capturar este tráfico habilite IPFIX (NetFlow) nuevamente en sus respectivos lugares y luego ejecute:

pktcap-uw –uplink vmnic2 -o /vmfs/volumes/ADAPTEC-232GB-JBOD/vmnic2.pcap

nota: actualmente el ESXi donde estoy generando las pruebas tiene un vDS con dos uplink a diferentes Switches, uno de los swtiches está apagado y por esto solo estoy capturando datos en el vmnic2.

Esta es la configuración de IPFIX (NetFlow):

Aquí una captura de pktcap capturando tráfico:

Esperemos que la causa del problema este entre los paquetes capturados!

Enviando flow data desde vSphere vDS a flowAnalyzer.

Desde el punto de vista de los equipos de red físico estamos corriendo un PROBE y enviando esa información al COLLECTOR. Ahora le toca al ambiente virtual!

vSphere vDS (Distributed Switch) soporta la funcionalidad de NetFlow. Habilitando esta opción en nuestros vDS podremos ver información de red que posiblemente no paso por el PROBE que corre en el inter-vlan router o el router de borde. Por ejemplo, tráfico de una VM en 10.0.0.0/24 a otra VM en el mismo rango de red no llegara a los routers y por esto no lo veremos en en flowAnalyzer.

Así habilitamos Netflow en el vDS:

  1. habilitamos la funcionalidad en el vDS:

 

  1. habilitamos en cuales PortGroup queremos capturar trafico:

 

Inicialmente configure el probe para NetFlow 9, en la versión 5.1 en adelante soporta IPFIX. asi que cambie el puerto y pude ver el trafico llegando al colector.

Lamentablemente, el PROBE en vDS envía datos que el template en el colector no los tiene y esto hace que el proceso muera y reinicie, esto quiere decir que la información no llega al index de Kibana.

 

Investigare como puedo agregar los valores para inciar el proceso nuevamente. stay tunned!

Analizando tráfico con Netflow – pmacct – flowAnalyzer.

Además de usar LibreNMS en aaNetworks, desde hace tiempo tenía la idea de usar NetFlow [https://en.wikipedia.org/wiki/NetFlow], esta configuración está al borde de OverKill en un home network, pero qué más da!

 Flow Exporter: por el momento cuento con cinco equipos que cumplen con esta tarea, lo exportadores o probe como son mejor conocidos son los encargados de agregar los paquetes en flows y exportarlos al equipo central el cual se usara para hacer visualización de la información exportada.

Equipos cumpliendo esta tarea son:

zapp – Mikrotik RB493AH: RouterOS tiene la funcionalidad de capturar paquetes y enviarlos como flow ya sean v5, v9 o IPFIX, en mi caso está configurado para v9.

 

elzar – Ubuntu 17.04.

vul – Debian Jessie.

leela – Debian Stretch.

fry – Debian Stretch.

En el caso de Debian, existen varias opciones para tener la funcionalidad de PROBE, algunas son directamente en el kernel otras son aplicaciones que usan libcap, en mi caso me decidí por una aplicación llamada pmacct (ni idea como se pronuncia) la cual cuenta con un PROBE y muchas otras funcionalidades que en una entrada futura hablare de ellas.

Flow Collector: esta es la plataforma/aplicación responsable de recibir los flows que fueron generados en los PROBE, esta es la parte difícil, muchas de estas plataformas/aplicaciones son de pago. La razón, sencilla, los PROBE ya vienen en los routers asi que solo faltaría el Collector y dependiendo de la calidad del software que se use para colectar se verán los beneficios de tener NetFlow.

En mi caso he implementado una aplicación no tan conocida, tope con ella en un sub-reddit. flowAnalyzer es una combinación de varias aplicaciones las cuales forman el Colector y la aplicación de Análisis. Esta plataforma está basada en ELK, esta es la ventaja, luego que tenemos información generada en los probe importadas en un index de Kibana, podemos generar cualquier tipo de gráficos con información importada en el index.

En el caso de flowAnalyzer, los colectores son el producto del creador de la plataforma, estos colectores fueron desarrollados específicamente para esta tarea usando Python como lenguaje.

En esta tabla se pueden apreciar las versiones de flow soportadas y sus respectivos puertos.

 

Discover: esta es una sección típica de Kibana, aquí podemos ver casi en real-time todo lo que fue indexado y procesado por ElasticSearch y Kibana. Partiendo de este punto crearemos visualizaciones para luego crear dashboards.

La siguiente captura muestra todo el tráfico relacionado a la categoría Web que ha pasado por Vul.