LibreNMS – Como crear una aplicación para monitorear componentes no soportados.

LibreNMS – Como crear una aplicación para monitorear componentes no soportados.

LibreNMS soporta muchos equipos y dentro de esos equipos existen componentes que también tienen soporte en la plataforma, pero que pasa cuando uno de estos componentes no existe o simplemente el grafico que necesitamos no ha sido creado.

En mi caso todo comenzó cuando agregue un ATS APC el cual tiene soporte SNMP, pero no reporta el consumo en Watts, en realidad tampoco lo reporta en el portal de administración del mismo. Pero si reporta los Amperes consumidos por la regleta en cualquiera de sus líneas de consumo.

Mi primer intento fue usando Collectd, cree un script en Bash que buscaba el OID con el valor de amperes consumidos en el árbol de SNMP y lo calculaba para obtener su equivalente en Watts. Inicialmente todo estaba de maravillas, pero luego el grafico se corrompió y dejo de reportar.

Últimamente eso me ha pasado con varios gráficos que obtenían su información de Collectd, en fin, decidí cambiar de Collectd a otra forma y al parecer la manera oficial en LibreNMS es “desarrollar” una aplicación.

Dentro de LibreNMS existen varias ubicaciones (paths) donde deben existir los componentes de la aplicación, por ejemplo, si se hace un find al nombre de una aplicación existente, se pueden ver cuáles son esas ubicaciones.

En la imagen, realizo una búsqueda del App llamado pi-hole, el autor de esta app describió lo fácil que es crear una aplicación con simplemente copiar pi-hole como base, eso fue lo que hice para resolver el monitoreo de consumo de mi ATS APC.

Nota: en la imagen se puede ver un archivo .rrd, en este caso es el resultado de los valores tomados del host resolver.aanetworks.org que cuenta con pi-Hole y tiene el App habilitado.

ATS-Watts:

Este es el nombre que le he asignado a la nueva “app” que resultó de copiar los archivos usados en la aplicación de pi-hole.

Luego de remover los valores que no necesitaba, en pi-hole se generan alrededor de 12 gráficos. En el caso de ATS-Watts, solo estaré generando uno que es el resultado de un script.

La funcionalidad de este script es colectar la información en SNMP del ATS, este ATS no cuenta con un OID donde muestre el valor en Watts, cuenta con dos valores OID donde la unión con un (.) de estos es el total de Amperes consumidos, luego los multiplica por 110 para tener los Watts.

ats-watts.inc.php:

Este es el primero componente de la aplicación, se puede ver como tomo el OID generado por el script y se asigna a las variables para ser graficadas por rrd.

Para seguir entendiendo como funciona ATS-Watts, se puede ver el resto del código en el repositorio Git que me he montado para jugar un poco y tener mejor control de algunos proyectos que tengo en mente, hello Kubernetes yaml!.

https://git.aanetworks.org/ariel/ATS-Watts

Habilitando la aplicación a un host de LibreNMS:

Una vez terminado de editar los archivos correspondientes, debemos tener la habilita de encender la nueva aplicación en el host que designemos o donde se haya habilitado el script, en mi caso el script de ats-watts.sh se habilito en el mismo servidor de LibreNMS.

 

LibreNMS – backups con Oxidized.

LibreNMS – backups con Oxidized.

Si cuentas con una red con más de dos dispositivos (router o switch), debes considerar realizar respaldos de manera automatizada a esos equipos, está de más decir que también tenemos que monitorear el comportamiento de estos equipos. Podemos monitorear valores tales como CPU, memoria, estado de las interfaces de red y cantidad de tráfico que pasa por estas, esto es solo por mencionar algunos de los objetos disponibles en un equipo de red.

Sorpresa, todo esto se puede hacer con LibreNMS.

Esta plataforma de monitoreo es un fork de Observium el cual cambio su modo de distribución a uno más cerrado y esto causo que usuarios como YO se movieran a LibreNMS. Recuerdo haber usado un paso a paso de cómo mover la data de un software al otro.

En esta entrada nos saltaremos la parte donde instalamos LibreNMS, en la página del proyecto oficial se puede encontrar esta información.

Oxidizedhttps://github.com/ytti/oxidized

Como dice su README en GitHub, este es un intento de reemplazar RANCID, en mi opinión este proyecto ha logrado su cometido, mi experiencia con RANCID no fue la más hermosa o placentera.

Debian es la distribución en la cual está instalado LibreNMS, en la sección de instalación tienen varias distros, FreeBSD y Docker. Los pasos de instalación de Debian aplican para Ubuntu.

Cuando toco instalar oxidized-web, este fallaba y al final pude determinar que faltaba g++, cuando instale Debian seleccione el mínimo de paquetes, lo extraño fue que también paso lo mismo cuando realice la misma instalación en Ubuntu.

Configurando Oxidized –

Una vez instalado los tres componentes, podemos proceder a generar una configuración por defecto la cual podemos editar más adelante. Es recomendado no ejecutar Oxidized como root, debemos crear una cuenta para este servicio.

useradd oxidized

Luego ejecutamos oxidized una vez para que sea creado el directorio y en este los archivos necesarios, aunque no usaremos algunos de ellos.

Los Outputs son una parte esencial de la configuración, debemos seleccionar Git para contar con la funcionalidad de versiones dentro de LibreNMS.

Aquí un ejemplo de configuración para Oxidized que funciona en LibreNMS, este es el usado en mi entorno actualmente.

https://gist.github.com/aredan/8e44cb0485d196020472c9c870f1a60c

En router.db no necesitamos colocar equipos, la integración de LibreNMS se encarga de eso y para que esta funcione debemos decirle a Oxidized cuál es la URL del API y crear un usuario, al mismo usuario debemos asignarle un Token para ser usado desde Oxidized.

Oxidized como servicio –

Muchas veces instalamos componentes que necesita inicializar con el sistema y este se encarga de colocar lo necesario, ya sea en init.d o en system.d, en el caso de Oxidized debemos hacerlo nosotros.

https://github.com/ytti/oxidized#extra

Para este momento debemos tener un Oxidized configurado y corriendo como servicio, ya que la manera de acceder estos respaldos será usando LibreNMS, podemos dejar oxidized-web escuchando solo en 127.0.0.1 siempre y cuando ambas plataformas están instaladas en el mismo equipo.

Configurando LibreNMS –

Usando la opción de configuración mediante Global Settings -> External Settings no funciono, ni siquiera presento errores en el log de LibreNMS, cuando introduje la configuración directamente en config.php, automáticamente apareció la opción de Oxidized en Overview -> Tools. Pasados unos minutos ya podía ver intentos de conexión desde la maquina con LibreNMS/Oxidized a los equipos de red que fueron definidos en la configuración de Oxidized.

$config['oxidized']['enabled'] = TRUE;
$config['oxidized']['url'] = 'http://127.0.0.1:8888';
$config['oxidized']['features']['versioning'] = true;
$config['oxidized']['group_support'] = true;
$config['oxidized']['default_group'] = 'default';
$config['oxidized']['reload_nodes'] = true;
$config['oxidized']['group']['os'][] = array('match' => 'nxos', 'group' => 'nxos');
$config['oxidized']['group']['os'][] = array('match' => 'ios', 'group' => 'ios');
$config['oxidized']['group']['os'][] = array('match' => 'fortigate', 'group' => 'fortinet');
$config['oxidized']['group']['os'][] = array('match' => 'routeros', 'group' => 'routeros');

En las últimas cuatro líneas están definidos los equipos que quiero que LibreNMS compare contra Oxidized, por lo menos así lo entendí yo.

 

 

Aquí algunas capturas de pantalla de LibreNMS accediendo a los respaldos realizados por Oxidized.

 

IPv6 en la casa, al estilo Homelab!

Hablar de IPv6 es como tirarle piedras a la Luna. Estuve cerca??

nota: esto no es un tutorial, es solo una descripción del enredo al cual llamo “Conexión IPv6”.

Ahora en serio, no voy a decir que en .DO no se está haciendo nada, a nivel residencial y a nivel empresarial creo que menos. Pero en el ámbito educativo podemos ver a PUCMM como el número uno en .DO con relación a conectividad IPv6, creo que al menos el 70% de sus servicios son accesibles vía IPv6, y esto lo digo por el simple hecho de que he intentado usar esos servicios y responden.

Vamos al tema, ya que los proveedores no se han decidido a llevar IPv6 a las casas, tuve que salir a buscar IPv6 por mi cuenta. Ya desde hace años estaba jugando con el “nuevo” direccionamiento gracias a un túnel, TunnelBroker de Hurricane Electric para ser exacto. Y el problema con este era que mi dirección IPv4 en la casa no es fija y sé que tienen un método para poder establecer el túnel con direcciones dinámicas pero ya era un poco complicado simplemente mantener el túnel, además de esto se sumó que servicios como Netflix comenzaron a bloquear esas direcciones IPv6 de HE cuando detectaban que eran parte de TunnelBroker.

Después de un tiempo sin tener conectividad de IPv6 de juguete en la casa me topé con que podía hacerme de un numero autónomo (ASN) y de un IPv6 PA.

Let’s the game begins!!

 

Según HE, soy mi propio ISP.

 

Lo primero fue registrar una organización en RIPE:

Luego realizar el proceso necesario para la asignación de ASN, para esto tenemos que enviar copias de documentos personales al LIR.

 

En este punto ya tenemos el numero autónomo (ASN) que es el pilar de todo el proceso que realizaremos más adelante. Nos toca conseguir un /48 de IPv6 para poder anunciarlo, cualquier asignación más grande de 48 será filtrada por los proveedores de upstream, puede ser que tu peer directo la deje pasar pero es posible que sea filtrada más adelante y no llegue al DFZ de IPv6.

Yo adquirí un /44 con SnapServ del cual solo estoy anunciando un /48 por el momento.

https://www.snapserv.ch/pricing.html

 

Pasemos inventario:

Tenemos número autónomo.

Tenemos direcciones IPv6 para anunciar.

 

Ahora necesitamos routers donde realizar las configuraciones de lugar y que todo este enredo funcione!

En mi caso fue bastante fácil ya que tenía equipos haciendo BGP con otros routers desde hace tiempo gracias a DN42.net, inicialmente lo que hice fue detener el proceso Quagga(BGPd), editar el archivo de configuración y cambiar 64635 -> 207036, reiniciar el proceso y listo!

En caso de ser desde cero, lo primero sería instalar un motor de enrutamiento dinámico (en el caso que sea Linux el router) o habilitar/configurar esta funcionalidad en el router o router que planeemos usar.

Linux – he decidido usar Quagga por la similitud que tienen con el CLI de Cisco.

Mikrotik RouterOS – en la casa tengo varios de estos equipos que soportan BGP.

 

Como se conectan estos equipos y pueden establecer una sesión BGP?

VPN!

En mi caso particular al estar usando el mismo ASN en todos los nodos, estos deben tener la habilidad de alcanzarse mutuamente, quiere decir que deben estar en Mesh. La primera vez que intente esto lo hice usando OpenVPN, que desastre, tenía que establecer alrededor de 6 túneles en cada máquina con Debian. Buscando alternativas me encontré con Tinc, muy buen software con el que dure bastante tiempo en uso hasta que me topé con Zerotier.

https://www.zerotier.com/

Usando zerotier puedo tener una VPN tipo mesh. En otras palabras, mi VPN funciona como un Switch Layer 2. Todas las maquinas tienen un IP de la misma subred y así puedo hacer sesiones BGP entre ellas sin tener que conectarlas directamente.

 

Y así termine con direcciones IPv6 accesibles globalmente en los equipos de mi casa. Pensé que este artículo terminaría como un paso a paso pero me di cuenta de que este enredo es más complicado de lo que pensé. En los próximos días dividiré cada sección y si podre crear un paso a paso.

 

Default Rule NDP – VMware NSX.

Siguiendo con las pruebas de IPv6 en NSX, he notado que una vez tenemos el Manager corriendo y al menos un Controller, si vamos a Firewall -> General, tenemos tres reglas creadas por defecto. En mi caso me ha llamado la atención una llamada Default Rule NDP la cual tiene un Action = Allow.

 

 

Primero, que es NDP?

Es un protocolo usado en IPv6, este opera en el Network Layer (Capa 3 del modelo OSI). Una de las tareas importantes es que este protocolo es el encargado de encontrar (descubrir) otros nodos en el mismo segmento (link).

A mi entender esta es la razón del porque esta regla está en la parte de General cuando entramos a Firewall, la primera prueba que hice fue cambiar el Allow por Block y automáticamente la VM en el cluster que está preparado para NSX y al cual esta política le aplica dejo de alcanzar TODOS los demás host en el mismo link layer. Por ejemplo, si quisiera hacer lo mismo en IPv4 dentro de NSX tendría que crear una regla en la parte de Ethernet tal vez usando la MAC de la VM que no quiero que genere tráfico a ningún otro hosts.

Personalmente pienso que esto no debería ser una política creada por defecto y más bien una opción habilitada en el mismo servicio de Firewall, se puede dar el caso que por equivocación se coloque una regla que interfiera con la comunicación NDP más arriba de esta por defecto y automáticamente tendremos un mal día.

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.