< the skull

OPENBGPD: SPEAKING LIKE A REAL ROUTER
=====================================
2026-06-28

There are tools you look at for the first time and think, “okay, this seems
important, but important to whom?” OpenBGPD is one of them. The name already
gives away half of it: it is the BGP daemon born in OpenBSD. The problem is that
this sentence, by itself, says nothing to someone who does not spend the whole
day living inside routing, ASN, and peering.

So I will translate it once and for all: it is software that lets any machine
speak BGP, the protocol networks use to exchange routes with each other. It is
not for hosting a website, and it is not a reverse proxy, VPN, or firewall with
a pretty panel. It lives in a much lower layer. Its job is to tell other
routers, “to reach these IPs, the path goes through here.”

That changes the scale of the conversation. Nginx, Docker, VPS, domain names:
all of that is application and service territory. BGP is already the gear that
lets the entire internet know where traffic should go. Another floor of the
building.

First: what is BGP?
===================

BGP is the Border Gateway Protocol, the protocol autonomous networks use to
exchange routing information with each other. An autonomous network, or AS, is a
network large enough to have its own identity on the internet, identified by a
number called an ASN. Providers, datacenters, carriers, universities, IXPs,
large companies: this is the world they all live in.

The internet is not a magical cloud; it is a giant agreement between networks.
Each one announces the IP blocks it knows, the paths it accepts, the ones it
prefers, and the ones it does not want at any price. BGP is the language these
networks use to negotiate all of this.

Think of it as GPS for big routers. Except instead of saying “turn right in 300
meters,” it says “this prefix is reachable through this AS, along this path,
under these rules.”

OpenBGPD is the free implementation of BGP made by the OpenBSD people. It came
with the same mindset as the project itself: lean code, configuration you can
actually read, privilege separation, and a genuine concern not to become a
monster.

In practice, it turns an ordinary Unix machine into a BGP router. It can run on
OpenBSD itself, and there is also a portable version that compiles on FreeBSD
and on some Linux distributions.

That is the good part: you do not need a carrier-grade router that costs a
fortune to study or operate BGP in certain scenarios. You can take an ordinary
machine, put a serious system on it, and make it participate in the routing
conversation.

What it is not
==============

It is worth being direct here, because this is where a lot of people get excited
for the wrong reason. OpenBGPD will not “make your site faster,” and you also do
not install it on a random VPS and receive global redundancy as a free bonus.

It does not replace Nginx, Traefik, Pangolin, Cloudflare Tunnel, FRP, WireGuard,
or pfSense, because those are different problems. OpenBGPD handles announcing
and receiving routes by talking to neighboring routers through BGP. If you do
not have a BGP neighbor, an ASN, your own IP prefix, or a lab set up, it simply
has no one to talk to.

It is an aviation radio without an airplane. The device may be excellent, but it
makes no sense sitting on your desk.

The first case is learning. If you like infrastructure, OpenBSD, and networks,
building a lab with OpenBGPD is one of the best ways to understand how the
internet works under the hood. You create private ASNs, simulate providers,
announce prefixes, drop a link, and watch the routing reorganize itself.

The second case is real network operation. Then we are talking about a company
with its own ASN, an allocated IPv4 or IPv6 block, transit with a carrier,
peering at an IXP, that kind of environment. In that scenario, OpenBGPD can be
the daemon holding the BGP sessions and applying routing policies.

The third is a route server, especially at an internet exchange point. Version
9.0 improved efficiency in handling Adj-RIB-Out, which matters in large route
server deployments at IXPs. In practice: when you need to calculate and deliver
many routes to many participants, memory and efficiency stop being details and
become matters of survival.

The pieces that matter are few. bgpd is the daemon, the process that runs and
maintains the sessions. bgpd.conf is the configuration file, where you define
your AS, the router ID, the neighbors, the announced networks, the filters, and
the policies. And bgpctl is the command-line tool used to check session status,
inspect routes, and administer the service.

That simplicity is one of the project’s charms. Instead of throwing you into a
maze of modes, submodes, and commands that feel inherited from an extinct
civilization, OpenBGPD tries to keep the file readable. It is still BGP, so it
is not a toy, but it also does not insist on being impenetrable.

Imagine you have ASN 64512 and the block 203.0.113.0/24. Your provider uses ASN
64500, and its router responds at 198.51.100.1. A conceptual configuration would
look roughly like this:

AS 64512router-id 192.0.2.1network 203.0.113.0/24

neighbor 198.51.100.1 { remote-as 64500 descr "Provider 1"}

Do not copy this thinking it is a production configuration, because it is not.
Those blocks are for documentation, and a real configuration needs filters,
authentication when it makes sense, import and export policy, prefix validation,
RPKI depending on the case, limits, and common sense. BGP without filters is an
open datacenter door with you sleeping beside it.

BGP is powerful because it changes the path traffic takes, and that is exactly
why it is dangerous when used carelessly. A wrong announcement can make your
network disappear from the map, send traffic to the wrong place, break
connectivity, and, in ugly cases, leak routes to people who should not even see
them.

That is why the heart of a decent BGP configuration is not “the session came
up.” Bringing up the session is only the beginning of the story. What truly
matters is what you accept, what you announce, to whom you announce it, and
under which conditions. Filtering here is basic hygiene. Anyone running BGP
without filters is not being an old-school hacker; they are being irresponsible.

It is the difference between playing in a lab and operating on the real
internet. In the lab, making mistakes is learning. In production, mistakes
become incidents.

OpenBSD has a very particular culture. It does not try to please everyone; it
prefers to do fewer things, but with clarity and predictability. OpenBGPD
inherited that entire personality.

The configuration tends to be direct, the daemon was designed with privilege
separation, and the project takes input validation and lean code seriously. That
does not mean it is magical or invulnerable; it means it was made by people who
understand that network software spends all day exposed to garbage coming from
outside.

And for routing, that matters a lot. A BGP daemon is not a little program hidden
in a corner: it talks to other systems, receives updates, processes attributes,
decides routes, and influences real traffic. The attack surface and the possible
damage are too large to tolerate hacks.

Honestly, I would not start putting OpenBGPD on an application VPS just because
it looks nice. That is decorating infrastructure with the wrong tool. For
GoToSocial, Pixelfed, Lemmy, Nginx, Docker, reverse proxy, and web services in
general, it does not enter the conversation.

Now, to study real routing, yes, I would absolutely use it. I would set up two
or three OpenBSD VMs, each with a private ASN, create fictional prefixes, bring
up BGP sessions between them, and test filtering. Then I would drop one link,
bring up another, play with local-pref to prefer a route, manipulate AS path,
and apply communities. That is where things get fun.

And it would make sense again if one day the operation had its own ASN, an IPv6
block, more than one provider, or a presence at an exchange point. At that
moment, OpenBGPD stops being a curiosity and becomes a real candidate for the
network edge.

OpenBGPD against the fetish of complexity
=========================================

One thing I like about this kind of project is how it breaks the idea that
serious infrastructure needs to be noisy, full of dashboards, buttons, plugins,
and marketing. Sometimes the right tool is a small daemon, a clear configuration
file, and a command that shows the state of things.

That is very OpenBSD. No fireworks, no “revolutionary AI-powered routing
platform.” It is serious software doing a serious job, and honestly, that is a
relief. Not everything needs to become a SaaS with a mascot and an Enterprise
plan.

OpenBGPD seems boring until it clicks that it is handling one of the most
important parts of the internet: the decision of where packets go.

The no-nonsense summary
=======================

OpenBGPD is a free implementation of BGP-4 born in the OpenBSD ecosystem. It
lets an ordinary machine exchange routes with other systems that speak BGP, and
it is used for edge routing, multihoming, peering, IXPs, route servers, and
network labs.

It is not for hosting a website, speeding up WordPress, replacing a reverse
proxy, or solving common VPS headaches. If you do not have an ASN, a prefix, a
BGP neighbor, or a lab set up, it will be more of a study object than an
immediately useful tool.

But as study material, it is excellent, because studying OpenBGPD is studying
the internet underneath. Not the internet of posts, videos, and pretty panels,
but the real one: routes, policy, announcements, filters, and a pile of
technical decisions almost nobody sees and everyone uses.

The smart path is not trying to put this into production; it is building a lab.
Three OpenBSD VMs are enough. One is your AS, another is a provider, and the
third is a second provider or a customer. You create documentation prefixes,
bring up the sessions, announce routes, and use bgpctl to follow what is
happening.

From there, you raise the level: filters, then policy, then route preference,
then intentional failure, then IPv6. When you can explain the path of a route
without copying from a tutorial, then you have started to truly understand BGP.

That is the point. OpenBGPD is not a button-clicking tool; it is a tool for
understanding and operating an important layer of the network. Anyone who only
wants to put a service online can safely ignore it. Anyone who wants to know how
the internet breathes from the inside should take a careful look.

Quick table
===========

Question

Direct answer

What is it?

A free BGP daemon originating from OpenBSD.

What is it for?

Exchanging routes with other routers and systems that speak BGP.

Is it useful for a regular VPS?

Almost never.

Do I need an ASN?

For real use on the internet, generally yes.

Is it good for studying?

Very much. It is great for a routing lab.

Does it replace a firewall, proxy, or VPN?

No. It belongs to another layer of the problem.

Sources consulted
=================

OpenBGPD, official page: https://www.openbgpd.org/

OpenBGPD, project goals: https://www.openbgpd.org/goals.html

OpenBGPD, official manuals: https://www.openbgpd.org/manual.html

RFC 4271, Border Gateway Protocol 4: https://www.rfc-editor.org/rfc/rfc4271

OpenBGPD 9.0 announcement:
https://www.mail-archive.com/announce@openbsd.org/msg00576.html

Article written in June 2026.


< the skull