How to bypass "Error: Nexthop has invalid gateway" when adding routes on Linux

I was having issues to add a route to my Linux home lab virtualization host, and it was not working and was instead outputting that error all the time. I guess that had something with the actual complexity of my home lab architecture, especially how my VMs had access to the interned and how I was accessing them from the Internet.

davidassigbi@hp-elitebook:~$ ip route 
default via 10.188.0.1 dev wlo1 proto dhcp metric 600 
10.10.10.0/24 dev enp0s25 proto kernel scope link src 10.10.10.2 metric 100 
10.188.0.0/16 dev wlo1 proto kernel scope link src 10.188.197.57 metric 600 
169.254.0.0/16 dev mybridge scope link metric 1000 
192.168.1.0/24 via 192.168.1.5 dev mybridge 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 

davidassigbi@hp-elitebook:~$ sudo ip route add 100.96.1.0/24 via 192.168.1.1 dev mybridge 
Error: Nexthop has invalid gateway.

davidassigbi@hp-elitebook:~$ ip a show mybridge
4: mybridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:5a:99:6e:19:87 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.5/24 brd 192.168.1.255 scope global mybridge
       valid_lft forever preferred_lft forever
    inet6 fe80::b85a:99ff:fe6e:1987/64 scope link 
       valid_lft forever preferred_lft forever

davidassigbi@hp-elitebook:~$ sudo brctl show mybridge
bridge name    bridge id        STP enabled    interfaces
mybridge        8000.ba5a996e1987    no        vnet1
                            vnet4
                            vnet6

And the final solution was to add the onlink argument, which according to the ip route man page says it forces the kernel to assume the interface is directly connected to the system while it actually is not.

davidassigbi@hp-elitebook:~$ sudo ip route add 100.96.1.0/24 via 192.168.1.1 dev mybridge  onlink

Resources:

• https://man7.org/linux/man-pages/man8/ip-route.8.html : look up the onlink on the page
• https://unix.stackexchange.com/a/644486 : a question on stackexchange discussing the same issue