Networking Tips
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
jueves, 13 de agosto de 2026
viernes, 31 de julio de 2026
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.
viernes, 24 de julio de 2026
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.
domingo, 17 de mayo de 2026
¿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
miércoles, 29 de abril de 2026
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!
jueves, 2 de abril de 2026
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.
domingo, 29 de marzo de 2026
Solución a: "Grader Error: Grader feedback not found" en coursera
Situación:
Se recibe "Grader Error: Grader feedback not found" en coursera al enviar una tarea
Solución
Con el error presente
1) Haz clic en el botón de Help (signo de interrogación) en la esquina superior derecha del laboratorio.
2) Selecciona Get latest version y luego Update Lab. Esto generará un notebook nuevo con los metadatos correctos.
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...
-
Necesidad Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...