RPKI con GoRTR de Cloudflare – en Kubernetes!

RPKI con GoRTR de Cloudflare – en Kubernetes !

Hace un tiempo probé con RPKI, en esos días estaba tomando unos entrenamientos de MANRS, con RPKI podemos asegurar que los prefijos que recibimos vía BGP con de quien realmente deberían ser, en otras palabras, si por alguna razón un tercero mal intencionado se hace con un bloque de direcciones IP que no le pertenece, pero esta tiene ROA habilitado, el trabajo de RPKI es no permitir que esos bloques de direcciones IP sean insertados en nuestra tabla de enrutamiento.

https://github.com/cloudflare/gortr

Continuar leyendo «RPKI con GoRTR de Cloudflare – en Kubernetes!»

VRF en Linux con BIRD para OSPF/BGP

VRF en Linux con BIRD para OSPF/BGP.

Desde hace mucho tiempo estoy jugando con BGP, inicialmente tenía BGP en pfSense, algo sencillo y con solo algunas rutas, eso fue en los tiempos de dn42.

En el 2016 encontré una comunidad de varios entusiastas de redes al nivel de Internet y pude conseguir un ASN registrado en RIPE.

Muchas cosas han cambiado desde esos días, he aprendido y experimentado, aprender es la razón de ser de aaNetworks. Lo complicado de mi red con direcciones IP Publicas y ASN es que localmente en mi casa no hay forma posible de tener una sesión BGP y publicar los prefijos desde ahí (imagínate que CLARO te permita hacer un túnel L2TP a un router con BGP!), dependo de VPS con Linux y BIRD.

Continuar leyendo «VRF en Linux con BIRD para OSPF/BGP»

RIPE Atlas – Estado actual en República Dominicana.

RIPE Atlas – Estado actual en República Dominicana.

Para los que no saben que es RIPE Atlas, es un Proyecto de RIPE NCC, su meta es colectar información de las conexiones a Internet usando un pequeño “probe” que se coloca en la red de un usuario, empresa o proveedor de Internet. Luego este probe realiza pruebas predefinidas para colectar valores como latencia, jitter y hasta pruebas de puertos, probar si DNS está respondiendo en servidores específicos.

No es un proyecto nuevo, los primeros registros se iniciaron en el 2010. Desde entonces existen países que han recibido esto como una herramienta para mejorar, pero lamentablemente otros no lo han hecho de esa manera debido al poco apoyo recibido. Tomaremos como ejemplo Republica Dominicana.

En nuestro país actualmente tenemos registrados 49 probes de los cuales solo 15 están conectados hoy [20/10/2019]. Si miramos detenidamente podremos ver que el primer probe en DO se conecto a la red de Atlas hace 4 años y 17 días y tiene 2 años desconectado.

¿Por qué pasa esto?

Mi opinión es que luego de recibir este pequeño aparato y conectarlo a la red, el usuario no siente que esta obteniendo un beneficio y en cualquier momento decide desconectarlo porque ya entiende que no lo necesita, lamentablemente esto también pasa en empresas, si miramos la lista de probes abandonados ahí muchos que al parecer fueron registrados por una empresa o proveedor y sufrieron la misma suerte.

¿Como podemos mejorar esto?

Tenemos que comprometernos a mejorar la infraestructura de Internet, hasta el menor esfuerzo como es hospedar un probe de RIPE Atlas aporta a mejorar Internet ya que permite que instituciones con áreas dedicadas al desarrollo usen esta plataforma para realizar pruebas de conectividad y entender mejor como cambian las redes de interconexión a través de los años.

¿Qué puedo hacer luego de tener un Probe?

Con RIPE Atlas tenemos que cumplir una condición para poder hacer uso de la plataforma, tenemos que acumular créditos, estos créditos se pueden conseguir dejando nuestro probe encendido y conectado a la red para que genere crédito a nuestro favor o recibiendo una donación de otro usuario. Luego que contamos con créditos podemos crear nuestras propias métricas.

Por ejemplo, hace un tiempo cree una métrica para medir la latencia desde Republica Dominicana a los DNS Resolver de CloudFlare.

En esta conjuración solicite 20 probes, todos de Republica Dominicana, actualmente están participando solo 9.

En la pestana de Latest Results podemos ver los últimos resultados de esta métrica.

En esta pestaña podemos apreciar la cantidad de RTT y HOPs utilizados por el probe para alcanzar a 1.0.0.1 que es uno de los DNS Open Resolver de CF. Lamentablemente uno de los probe está fuera de línea.

Otra pestaña de la cual podemos sacar ventaja es Tracemon.

Esta nos entrega un mapa con los saltos que hicieron los probe para llegar a su destino final, en cada punto podemos ver IP utilizada y ASN al cual pertenece esa IP.

Esto que acabo de mostrar aquí son de las configuraciones mas sencillas que se pueden crear en la plataforma, no soy ningún experto, pero sigo intentando sacarle partido a RIPE Atlas. Actualmente tengo dos probes corriendo, uno con mi ASN ( AS207036 ) y otro detrás del ASN de CLARO.

Para cerrar, si estas interesado en hospedar un probe de manera seria y con compromiso de tenerlo conectado, contáctame, actualmente estoy registrado como Embassador en Republica Dominicana, esto quiere decir que puedo asignar probes de algunos que tengo disponible.

AS207036 – Por qué y para qué?

AS207036 – Por qué y para qué?

El título de esta entrada tiene una razón de ser.

Porque existe AS207036 ?

Simple, leyendo RFC1925 encontraremos el siguiente párrafo:

The Twelve Networking Truths, Section 2.4:

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

Operational Network:

https://aanetworks.org/

Esta es la diferencia entre correr routers en GNS3 y correr routers con un propósito, en los últimos años he operado AS207036 y cada día que pasa se vuelve parte esencial de mi red operacional, primero vamos a listar que hace AS207036.

1 – Anunciar vía BGP prefijos IPv4

2 – Anunciar vía BGP prefijos IPv6

https://bgp.he.net/AS207036

Hace unos días solicite que el CountryCode fuera cambiado de Germany (DE) a Dominican Republic (DO), ahora soy “The King of the Hill” …..

El LIR en RIPE que tengo es lo mejor!! https://asn.servperso.net/

Lo importante aquí es todo lo que puedo hacer usando esas direcciones IP de las cuales tengo total control y no dependo de NAT para tener servicios como servidores web (donde estas leyendo este post), VPN, email server y otros.

Y ya que en .DO aun no se brinda conectividad a Internet vía IPv6, tengo acceso a Internet usando direcciones IPv6.

Al final del día que he ganado con toda esta configuración y complejidad?

Experiencia!!!

LibreNMS – Exportando data a Influxdb para crear gráficos en Grafana.

LibreNMS – Exportando data a Influxdb para crear gráficos en Grafana.

Grafana es un software para crear gráficos con distintas formas y colores, lo interesante es que la data a desplegar se puede manipular de muchas maneras y puede originarse desde diferentes softwares/plataformas.

Esto no es nada nuevo, personalmente vi Grafana hace más de 4 años en un subreddit, quede impresionado e inmediatamente busque como hacer los mismo, el primero intento fue exportando data desde un pfSense para crear un heatmap con los IPs bloqueados por el firewall. Luego de un tiempo se hizo más difícil mantener los equipos enviando información a InfluxDB para graficar en Grafana y decidí detener el proyecto.

LibreNMS soporta exportar a influxDB.

Para mi sorpresa encontré que LibreNMS soportaría exportar data desde su DB en MySQL a una InfluxDB, todo era experimental y en el primero intento nada funciono.

¡En el segundo intento todo funciono a la primera, impresionante!!

Se instaló InfluxDB en el mismo equipo que tiene LibreNMS, también se instaló Grafana. Una vez ambos softwares corriendo correctamente, la configuración de LibreNMS es muy sencilla. Pero primero crearemos la base de datos para LibreNMS en InfluxDB.

CREATE DATABASE librenms
CREATE USER admin WITH PASSWORD ‘admin’ WITH ALL PRIVILEGES
CREATE USER librenms WITH PASSWORD 'admin
GRANT ALL ON librenms TO admin
GRANT READ ON librenms_db TO grafana
exit

Configuración en config.php

$config['influxdb']['enable'] = true;
$config['influxdb']['transport'] = 'http'; # Default, other options: https, udp
$config['influxdb']['host'] = '127.0.0.1';
$config['influxdb']['port'] = '8086';
$config['influxdb']['db'] = 'librenms';
$config['influxdb']['username'] = 'admin';
$config['influxdb']['password'] = 'admin';
$config['influxdb']['timeout'] = 0; # Optional
$config['influxdb']['verifySSL'] = false; # Optional

Si revisamos el documento oficial de como conectar LibreNMS con InfluxDB ( https://docs.librenms.org/#Extensions/metrics/InfluxDB/ ), se puede ver que no se ha cambiado absolutamente nada, ya sé que debería de haber cambiado por lo menos el password, eso será para otra ocasión.

Como validamos que se está exportando data a InfluxDB ¿?

Podemos conectarnos a la InfkuxDB desde la línea de comando y ejecutar un query contra la base de datos de librenms que creamos anteriormente.

$ influx
> use librenms
> show measurements

En pantalla tendremos los nombres de nuestros equipos en LibreNMS con información relacionada a sus NIC, CPU, Espacio en Disco y mucho más, básicamente todo lo que tiene LibreNMS en los gráficos, será exportado a InfluxDB.

¿Pero, si ya tengo graficos en LibreNMS, para que quiero Grafana?

En mi caso, quería crear gráficos personalizados los cuales LibreNMS aún no soporta de una manera tan sencilla como Grafana.

Un ejemplo es relacionado al “app” de ATS-Watts, usando Grafana con la data recibida desde LibreNMS puede crear gráficos que muestren el consumo diario y lo calculen para saber el precio de cada KWh consumido.

En LibreNMS tengo esto:

En Grafana tengo esto:

Otro caso es tener todas las interfaces de equipos de bordes en una misma pantalla, en LibreNMS es muy sencillo hacerlo, pero si decidimos usar Grafana, al momento de compartir esta información es mucho más fácil que con LibreNMS.

El potencial de Grafana es grande, también tenemos la posibilidad de recibir datos desde equipos que no estén en LibreNMS y mezclar esta información en gráficos de la manera que más nos guste.