GoBGP on Ubuntu 24.04 on Azure User Guide

Overview

GoBGP is a fast, open source implementation of BGP from the osrg project. It runs as a single daemon, gobgpd, that you drive either from a plain-text TOML configuration file or programmatically over a gRPC API, with a companion CLI, gobgp, for everyday operation. It speaks BGP to your routers as a peer, learns and advertises routes, and can act as a route server, a route reflector, an edge speaker or a route injector that pushes prefixes into your network from software.

A bare BGP daemon has nothing to show on its own, so the cloudimg image ships a complete, self-contained, provably-working BGP reference deployment on the one VM:

• A primary gobgpd (AS 65001) — the daemon you drive with gobgp — with its gRPC API bound to 127.0.0.1:50051 only.
• A demo peer gobgpd (AS 65002, gRPC 127.0.0.1:50052) that it peers with over a pair of internal loopback-range addresses (10.255.255.1 and 10.255.255.2).
• A real eBGP session between them, authenticated with a per-VM TCP-MD5 key, that reaches ESTABLISHED, with routes propagating and an import policy filtering.

The moment the VM boots, gobgp neighbor shows an ESTABLISHED session and gobgp global rib shows real routes — so you can see BGP working before you point the daemon at your own routers.

What is included:

• GoBGP 4.7.0 (the gobgpd daemon and gobgp CLI) at /usr/local/bin, pinned to the official upstream release binary and verified by SHA-256
• A primary gobgpd (AS 65001) driven over gRPC on 127.0.0.1:50051
• A demo peer gobgpd (AS 65002) on 127.0.0.1:50052, authenticated with a per-VM TCP-MD5 key
• A demonstrated import policy (reject-blackhole) that drops 198.51.100.0/24
• Per-VM TCP-MD5 key generated at first boot, at /root/gobgp-credentials.txt (root-only)
• Secure by default: the gRPC API is bound to loopback, and BGP listens only on the internal demo link — nothing on eth0
• Runs as the unprivileged gobgp system account with only the two capabilities it needs
• 24/7 cloudimg support

Deploying on Azure

Launch the image from the Azure Marketplace on a Standard_B2s (or larger) VM. GoBGP is lightweight; Standard_B2s (2 vCPU / 4 GB) is ample for the reference deployment and for a modest production route server. SSH in as azureuser with the key you selected at launch:

ssh azureuser@<vm-ip>

On first boot the appliance generates this VM's unique TCP-MD5 session key, renders both gobgpd configurations, brings the reference deployment up, and proves the session establishes and the policy filters before it writes its first-boot sentinel. No two VMs ever share a key, and the captured image contains no key at all.

Step 1: The Authenticated eBGP Session is ESTABLISHED

gobgp neighbor lists the daemon's peers and their session state. The demo peer (10.255.255.2, AS 65002) is Establ. gobgp neighbor <address> shows the full session detail — the negotiated capabilities, timers and local ASN:

gobgp neighbor
gobgp neighbor 10.255.255.2

The session only reaches ESTABLISHED because both ends share this VM's TCP-MD5 key.

Step 2: Routes Propagate

gobgp global rib shows the daemon's routing table. The primary has learned 192.0.2.0/24 from the demo peer and originates 203.0.113.0/24 itself. Query the demo peer's gRPC endpoint with -p 50052 to see the reverse direction — it has learned 203.0.113.0/24 from the primary:

gobgp global rib -a ipv4
gobgp -p 50052 global rib -a ipv4

Step 3: The Import Policy Filters

The primary applies an import policy, reject-blackhole, that drops 198.51.100.0/24. The Adjacency RIB In (adj-in) shows what was actually received from the peer — including 198.51.100.0/24 — while the global RIB in Step 2 does not contain it, because the policy rejected it:

gobgp neighbor 10.255.255.2 adj-in -a ipv4
gobgp policy

Step 4: Secure by Default

The gRPC API is bound to 127.0.0.1 (:50051 for the primary, :50052 for the demo peer), and the BGP listeners are bound to the internal demo addresses only — nothing is exposed on the VM's routable interface. This VM's TCP-MD5 key lives only in /root/gobgp-credentials.txt, readable by root alone:

sudo ss -lntH | awk '{print $1, $4}' | grep -E '127.0.0.1:5005|10.255.255'
sudo grep -v '^#' /root/gobgp-credentials.txt

Peering With Your Own Routers

The primary daemon's configuration is at /etc/gobgp/gobgpd.conf. To peer with your own routers, add your public address to local-address-list, add a [[neighbors]] block for each router, then restart the daemon. A minimal example:

[global.config]
  as = 65001
  router-id = "<your-router-id>"
  local-address-list = ["<this-vm-private-ip>"]

[[neighbors]]
  [neighbors.config]
    peer-as = <remote-as>
    neighbor-address = "<remote-peer-ip>"
    auth-password = "<a-shared-md5-key>"

Open TCP 179 to those peers in your Azure Network Security Group, then apply the change with sudo systemctl restart gobgpd.

You can also drive everything at runtime over gRPC without editing the config — for example, inject a route with gobgp global rib add <prefix> -a ipv4, or add a neighbor with gobgp neighbor add <ip> as <asn>. Full command help is available with gobgp --help and gobgp <command> --help.

Managing the Service

sudo systemctl status gobgpd
sudo journalctl -u gobgpd -n 50 --no-pager

The demo peer (gobgpd-peer.service) and the demo-route injector (gobgp-demo-routes.service) exist purely to make the shipped image a working reference deployment. Once you have configured your own peers you can disable them if you prefer a clean single-daemon setup with sudo systemctl disable --now gobgpd-peer.service gobgp-demo-routes.service.

Support

Every cloudimg deployment ships fully patched with unattended security updates enabled, and includes 24/7 cloudimg support. For help with this image, contact support through the Azure Marketplace listing or at cloudimg.co.uk.