fig.show() using Plotly does not work in jupyter

 Case:

  fig.show() using Plotly does not work in jupyter

What to do:

  Force rendering adding this line just before fig.show() using pio

  Example:

import plotly.io as pio

pio.renderers.default = 'iframe' 

fig.show()

Listo!

FRR Troubleshooting: Fixing Kernel Route Redistribution Issues on Boot

If you are running FRRouting (FRR), you might have encountered a frustrating quirk: after a system reboot, kernel routes (like a static default route) fail to redistribute into RIP or OSPF. Curiously, as soon as you manually restart the FRR service, everything works perfectly.

Here is a breakdown of why this happens and how to fix it for good.

The Problem

During a cold boot, FRR starts its daemons (Zebra, RIPd, etc.), but routes defined at the OS level aren’t being advertised to neighbors. This breaks connectivity after an automated reboot and forces manual intervention (systemctl restart frr), which defeats the purpose of an automated routing stack.

The Root Cause: The Startup "Race Condition"

The culprit is typically a race condition between your network manager (like Netplan or systemd-networkd) and the FRR service.

    Interface Renaming: Modern tools like Netplan often rename interfaces during boot (e.g., from eth0 to enp1s0). If FRR initializes while an interface is in transition, Zebra may ignore routes associated with a "missing" or "changing" interface.

    The "Up" State: If Zebra scans the kernel routing table before the physical or virtual interface is fully marked as "UP" and operational, the routing protocols (like RIP) will deem the route invalid for redistribution.

    Dependency Timing: By default, the FRR service might attempt to load before the network is "fully online," leading to a failed initial synchronization between the kernel and Zebra.

Step-by-Step Solution

The fix involves modifying the systemd unit file to ensure FRR waits until the network stack is completely ready and interface names are finalized.

1. Edit the Service Configuration

Instead of editing the file in /lib/systemd/system/ directly, use a systemd "override" to keep your changes safe during updates:

bash

sudo systemctl edit frr.service

2. Adjust Network Dependencies

In the editor that opens, insert the following lines:

ini

[Unit]

After=network-online.target

Wants=network-online.target

This tells systemd that FRR should only start after the system reports that the network is fully up and functional (network-online.target).

3. Reload and Apply

Save the file and exit the editor. Then, reload the systemd manager to pick up the changes:

bash

sudo systemctl daemon-reload

Verification

On your next reboot, you can verify that Zebra is correctly picking up the routes by checking your FRR logs or using the following debug commands in vtysh:

vtysh

debug zebra kernel

debug rip events

Summary

In modern Linux distributions where interface naming and IP addressing are dynamic, startup timing is everything. Forcing FRR to wait for the network to be "online" ensures that when the daemons ask the kernel for routes, the kernel actually has the final, stable answers ready to give.

Solved - Grader Error: Grader feedback not found in Coursera

Scenario

You receive the message "Grader Error: Grader feedback not found" in Coursera when submitting an assignment.

Solution

With the error present:

1) Click the Help button (question mark) in the upper right corner of the lab.

2) Select Get latest version and then Update Lab. This will generate a new notebook with the correct metadata.

MAC OpenVPN client is installed, but it won't run

 Scenario

You have a Mac; the OpenVPN client is installed, but it won't run. A typical scenario is that after restarting the laptop, another user logs into their profile, and then when you try to use your profile, OpenVPN simply won't open.

Solution

Run this bash script with sudo or as root:

-- cut here --

sudo launchctl bootout system /Library/LaunchDaemons/org.openvpn.client.plist

sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist

# 1. Kill all processes from any user

sudo pkill -9 -f "OpenVPN Connect"

sudo pkill -9 -f "ovpnagent"

# 2. Delete the communication file locked by the other user

sudo rm -f /var/run/agent_ovpnconnect.sock

# 3. Restart the background service

sudo launchctl kickstart -k system/org.openvpn.client

sudo launchctl enable system/org.openvpn.client

sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist

-- cut here --

I hope this was helpful.

Script to stop all Containerlab topologies and docker processes in a server

 Have you ever needed to stop all Containerlab in a server?

Is it complicated because there are so many users and so many Docker containers?

After rebooting, you still see running machines and different instances? This script is for you.

---- cut here ----

#filename: download-all-containerlab.sh

sudo containerlab destroy --all

sudo docker stop $(sudo docker ps -q --filter "label=containerlab")

sudo docker rm $(sudo docker ps -aq --filter "label=containerlab")

sudo ip link delete clab-bridge

sudo systemctl restart docker

---- cut here ----

Run: sudo bash download-all-containerlab.sh

Hopefully this is helpful

Entering rommon on a Cisco Switch from a Mac Laptop

Problem

I want to enter ROMmon on a Cisco software while connected via console. The break sequences I tried didn't work.

It didn't work for me.

On my Mac, holding the space bar for 15 seconds while booting the device didn't work, neither at 9600 nor 1200 baud. Ctrl-A + Ctrl-B nor backspace worked.

It did work for me:

Use Shift+CTRL+C during the first few seconds of booting the Cisco switch (in my case, a Cisco 4948).

I hope it helps.

Bar Chart Race 2014-2025 IPv6