FRR siempre te muestra "No connection to RPKI cache server."

 Situación

  FRR siempre te muestra "No connection to RPKI cache server."

Solución

  Especifica la direción fuente en el la declaración del cache RPKI. Ejemplo:

  

  rpki cache tcp 108.162.192.12 8282 source X.Y.Z.N preference 1

Voila

Versión 2 - Memes de IPv6

 

https://sovrn.co/1hznlaf

No recibes IPv6 cuando haces tethering

Situación

  No recibes IPv6 en tu computadora a pesar de que tú teléfono si tiene IPv6 provisto desde la empresa celular.

Solución

  En la parte de configuración de redes móviles --> APN revisa si "APN roaming protocol" lo tienes así

En caso afirmativo NO te funcionará.

La manera correcta es la siguiente:

  En lo personal nunca imaginé que el APN roaming protocol fuera el problema pero si lo es.

Espero sea útil.

Video: Todo lo que necesitas saber sobre los prefijos bogons

 

Hoy queremos aprender. ¿Sabes qué son los prefijos bogons y por qué representan un riesgo para tu red? En este video analizamos a fondo el concepto de prefijos bogon, su clasificación y los ejemplos más comunes tanto en IPv4 como en IPv6. Además, exploramos los principales problemas de seguridad que ocasionan (como el IP spoofing, SPAM, DDoS, etc) y te mostramos las soluciones definitivas para filtrarlos y proteger tu infraestructura de enrutamiento.

¿Correlación absurda o curiosa? IPv6 & felicidad

Luego de usar el reporte de “World Happiness Report y las estadísticas de penetración de IPv6 de google me he conseguido que existe un grado de correlación de 0.4648. Ahora bien, ¿Qué sígnifica este número?

- En estadística, la correlación se mide en una escala de -1 a 1.

- El 0 significa que no hay ninguna relación.

- El 1 significa una relación perfecta.

- El -1 es que las variables son inversamente proporcionales.

- Un valor de 0.4648 se considera una correlación moderada. Los dos datos se mueven juntos con cierta frecuencia, pero no de forma idéntica.

- Al ser un número positivo (+0.4648), la relación es directa.

- Esto significa que a mayor porcentaje de IPv6 en un país, mayor tiende a ser su puntuación de felicidad.

¿No me creen? Miren la gráfica de abajo.

¿Qué nos dice la gráfica?

Se observa que los países que logran superar el 40% o 60% de adopción IPv6 nativo casi nunca tienen niveles de felicidad críticamente bajos (pocos bajan de una puntuación de 5).

Si.., se que suena loco pero fue una tarea divertida.

¿Qué opinas?

Info

[1] World Happiness Report: 'https://files.worldhappiness.report/WHR26_Data_Figure_2.1.xlsx?_gl=1*zmm7kk*_gcl_au*MzI5Nzg1NTM4LjE3Nzg5NTQ3Mjk.'

[2] Google IPv6 stats: i'https://www.google.com/intl/en_ALL/ipv6/statistics/data/worldmap.js'

[3] Disponible en google colab aquí: https://colab.research.google.com/drive/1G8-KObej157c75lNl8kGzywWkBh1VhoW#scrollTo=87c9d1a2

fig.show() de Plotly no funciona en jupyter

Escenario:

  fig.show() de Plotly no funciona en jupyter

Solución:

  Forzar el renderizado agregando esta línea justo antes del fig.show() con pio

  Ejemplo:

import plotly.io as pio

pio.renderers.default = 'iframe' 

fig.show()

Listo!

FRR: Cómo solucionar la falta de redistribución de rutas kernel al arrancar

Si usas FRRouting (FRR), es posible que te hayas topado con un comportamiento frustrante: tras un reinicio, las rutas del kernel (como una ruta por defecto estática) no aparecen en tus anuncios de RIP o OSPF, pero si reinicias el servicio manualmente, todo funciona de maravilla.

Aquí te explicamos por qué sucede y cómo arreglarlo permanentemente.

El Problema

Al arrancar el sistema, FRR inicia sus procesos (Zebra, RIPd, etc.), pero las rutas definidas a nivel de sistema operativo no se redistribuyen a los vecinos de red. Esto interrumpe la conectividad tras un reboot y obliga a una intervención manual (systemctl restart frr), lo cual es inaceptable en entornos de alta disponibilidad.

El Motivo: La "Carrera" del Arranque

El culpable suele ser una condición de carrera (race condition) entre el gestor de red (como Netplan o systemd-networkd) y FRR.

    Renombrado de Interfaces: Herramientas como Netplan a menudo renombran interfaces durante el arranque. Si FRR arranca mientras una interfaz aún se llama eth0 pero está pasando a ser wan0, Zebra puede ignorar las rutas asociadas a esa interfaz.

    Estado "Down": Si Zebra escanea la tabla de rutas del kernel antes de que la interfaz de salida esté marcada como "UP" y operativa, RIP considera que la ruta no es válida para ser redistribuida.

    Orden de Dependencias: Por defecto, el servicio de FRR puede intentar cargar antes de que la red esté "totalmente en línea", causando que el anuncio inicial de rutas falle.

Paso a paso: La Solución

La solución definitiva consiste en ajustar la unidad de systemd para que FRR espere a que la pila de red esté completamente lista y los nombres de interfaces sean definitivos.

1. Editar la configuración del servicio

No edites directamente el archivo en /lib/systemd/system/. Es mejor usar un override:

bash

sudo systemctl edit frr.service

Usa el código con precaución.

2. Forzar la dependencia de red

En el editor que se abre, añade las siguientes líneas:

ini

[Unit]

After=network-online.target

Wants=network-online.target

Usa el código con precaución.

Esto asegura que FRR no se ejecute hasta que el sistema reporte que la red está operativa (network-online.target).

3. Recargar y verificar

Guarda los cambios y aplica la nueva configuración:

bash

sudo systemctl daemon-reload

Usa el código con precaución.

(ya aquí el problema solucionado)

4. Verificar en FRR

Asegúrate de que tu configuración de FRR tenga los comandos de depuración para confirmar que Zebra recibe las rutas tras el próximo reinicio:

vtysh

debug zebra kernel

debug rip events

show ip route

Conclusión

En sistemas modernos donde el direccionamiento y el nombrado de interfaces son dinámicos (como en la mayoría de las distros Linux actuales), el orden de arranque lo es todo. Forzar a FRR a esperar a la red garantiza que, cuando el daemon pregunte por las rutas del kernel, el sistema ya tenga la respuesta correcta lista.