BGP and OSPF on Keenetic: Dynamic Routing for ISP Failover and Home Labs

When static routing is not enough

In most home and small office networks routes are simple: all traffic goes to a single provider, and rare exceptions are set with static routes. But when there are several routers, failover links and tunnels between sites, manually maintained routes become a nuisance: they must be changed with every network update, and they do not reconverge automatically on link failure.

Dynamic routing protocols solve this automatically: routers exchange information about networks and rebuild routes themselves when things change.

BGP and OSPF: how they differ

BGP (Border Gateway Protocol) — an inter-autonomous-system routing protocol that underpins Internet connectivity. In small networks it is used to exchange routes between sites over VPN tunnels and to connect to two providers with your own address space. BGP runs over TCP (port 179), neighbors are configured explicitly, and route decisions are made by policies rather than by link “speed”.

OSPF (Open Shortest Path First) — an intra-network protocol. Routers discover neighbors themselves, build a shared map of the network and select the shortest path based on interface costs. On link failure routes are recalculated without administrator involvement, so OSPF is convenient for multiple routers in an office or connected sites.

How it works on Keenetic

In the official list of components for KeeneticOS 5.x there are no BGP or OSPF protocols. Dynamic routing on Keenetic is brought up via OPKG/Entware — an environment that allows installing Linux packages on a router to a USB drive or, on models with KeeneticOS 3.7 and newer, to internal storage. The Entware installer archive is chosen by the router CPU architecture: mipsel, mips or aarch64.

How to get BGP and OSPF on Keenetic: four ways

1. BIRD from Entware — ready-made packages

The Entware repository contains BIRD 2 and BIRD 3 for all Keenetic architectures (as of September 2026 — bird2 version 2.18). This is a modern routing daemon with support for BGP and OSPF, installable with one command:

opkg update
opkg install bird2 bird2c

The package places configuration in /opt/etc/bird.conf and the start script in /opt/etc/init.d/S70bird, and birdc is a console for viewing status. A minimal configuration for one eBGP neighbor over a tunnel looks like this:

router id 10.255.0.2;

protocol device { }

protocol direct {
    ipv4;
    interface "br0";          # LAN segment: verify the name with the ip -4 addr command
}

protocol kernel {
    ipv4 {
        export where source = RTS_BGP;   # to kernel — only routes from BGP
    };
}

filter lan_out {
    if net ~ [ 192.168.10.0/24 ] then accept;
    reject;
}

filter from_upstream {
    if net ~ [ 10.0.0.0/8{8,24}, 172.16.0.0/12{12,24} ] then accept;
    reject;
}

protocol bgp upstream {
    local 10.255.0.2 as 65010;
    neighbor 10.255.0.1 as 65001;
    ipv4 {
        import filter from_upstream;
        export filter lan_out;
    };
}

For most tasks on Keenetic this is the best option: the package is ready-made, the daemon is lightweight, and the filter syntax is flexible. Downside — BIRD’s syntax is not like Cisco’s; you’ll need to get used to it.

2. Quagga from Entware — ready-made packages, but outdated

The same repository also contains Quagga 1.2.4 with separate daemons zebra, bgpd, ospfd and the vtysh shell, whose syntax is similar to Cisco and FRR:

opkg install quagga-zebra quagga-bgpd quagga-vtysh

Configuration is in /opt/etc/quagga/ (zebra.conf, bgpd.conf), startup is /opt/etc/init.d/S50quagga: the script starts the daemons for which a configuration file exists. The Quagga project is no longer developed — the last changes in its repository are dated February 2018 — so for new installations this is a fallback option.

3. FRR — only custom build

There are no ready-made FRR packages in the Entware repository for any architecture, and the command opkg install frr will not work. There is a build recipe for FRR 10.4.1 in the Entware sources, but it was ported from OpenWrt without adaptation: paths /etc/frr and /usr/sbin, init script in OpenWrt format. On Keenetic all third-party software lives in /opt, so the recipe needs to be adjusted before building. How to do this and what to consider is described in the practical article “BGP on Keenetic”.

4. FRR on a separate machine next to the router

The most reliable way: run FRR on a small Linux server, virtual machine or mini-PC in the same network, and leave the internet connection, NAT and a static route to that node on the Keenetic. FRR is installed from the distribution packages there, updates normally and does not depend on the router’s flash.

General caveats

• Routes in the kernel. An external daemon writes routes directly into the Linux kernel routing table, while KeeneticOS manages routing itself and does not know about them: they are not visible in the web interface. Keenetic documentation does not describe this arrangement, so after each change check ip route to ensure routes are in place and traffic follows them.
• BGP password (TCP MD5). Session authentication by password requires TCP MD5 support in the router kernel. Whether it exists in your model’s kernel is unknown in advance — test on a bench; inside a protected tunnel you can do without the password.

Where it makes sense

• Connecting multiple sites via VPN. Offices are connected with WireGuard or GRE tunnels, and BGP or OSPF automatically informs neighbors about new subnets. Add a network at one office — the others learn it without manual routes.
• Multiple routers inside a network. OSPF automatically chooses an alternate path if one of the links between routers fails.
• Lab testbed. Learn BGP and OSPF alongside VyOS, MikroTik or Cisco equipment on an inexpensive router.

Where you can do without them

For two providers without your own addresses and an autonomous system number, BGP is not needed. Keenetic can maintain multiple connections with priorities and a Ping Check feature: if the primary channel fails the router will automatically switch to a backup. How channel failover to the Internet is implemented and when BGP is truly necessary is described in the article “Channel failover: Internet access”.

If serious routing is expected in the network, it is more reliable to move it to a separate Linux server or virtual machine with FRR (option 4), leaving the router with the Internet connection and NAT.

Limitations and security

• Performance. The routing daemon runs on the router CPU. That’s enough for exchanging a dozen internal routes, but not for the full Internet routing table.
• Do not open TCP 179 to the Internet. BGP neighbors should be established inside tunnels or the local network, and the port should be closed on the external interface by a firewall.
• Filter routes. Accept from a neighbor only the expected networks and advertise only your own — otherwise a mistake on one site can propagate everywhere.
• Store configuration separately. Entware package settings live outside the main router configuration and are not restored with it.

Conclusion

Keenetic does not replace a corporate router, but for a small distributed network or a training lab dynamic routing via Entware is sufficient. The main thing is to understand that this is an additional environment layered on top of the router system: it must be configured, updated and backed up separately.