Deployment guide

GoBGP

Overview

GoBGP is a fast, open-source implementation of BGP from the osrg project. It runs as a single daemon, gobgpd, which you drive from a plain-text TOML configuration file or programmatically over a gRPC API. A companion CLI, gobgp, handles everyday operation.

GoBGP peers with your routers, 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. This SecureAnyCloud image therefore ships a complete, self-contained BGP reference deployment on one VM: a primary gobgpd that you drive over gRPC on 127.0.0.1:50051, and a demo peer gobgpd on 127.0.0.1:50052. As soon as 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 you get:

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), 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 on 127.0.0.1:50052), authenticated with a per-VM TCP-MD5 key
A real eBGP session between the two daemons over a pair of internal loopback-range addresses (10.255.255.1 and 10.255.255.2). The session reaches ESTABLISHED, routes propagate and an import policy filters.
A demonstrated import policy (reject-blackhole) that drops 198.51.100.0/24
A per-VM TCP-MD5 key generated at first boot and stored in the root-only file /root/gobgp-credentials.txt
Secure defaults: the gRPC API is bound to loopback, and BGP listens only on the internal demo link, with nothing on eth0
The daemon runs as the unprivileged gobgp system account with only the two capabilities it needs
24/7 SecureAnyCloud support

Deploying on Azure

Launch the image from the Azure Marketplace on a Standard_B2s (or larger) VM. GoBGP is lightweight, and Standard_B2s (2 vCPU / 4 GB) is ample for the reference deployment and for a modest production route server.

When the VM is running, connect as azureuser with the SSH key you selected at launch:

ssh azureuser@<vm-ip>

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

Confirm the authenticated eBGP session is ESTABLISHED

Run gobgp neighbor to list the daemon's peers and their session state. The demo peer (10.255.255.2, AS 65002) shows Establ.

Run gobgp neighbor <address> for the full session detail: the negotiated capabilities, timers and local ASN.

gobgp neighbor gobgp neighbor 10.255.255.2

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

Check that routes propagate

Run gobgp global rib to see 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. The demo peer has learned 203.0.113.0/24 from the primary.

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

Verify the import policy

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

gobgp neighbor 10.255.255.2 adj-in -a ipv4 gobgp policy

Confirm the secure defaults

The gRPC API is bound to 127.0.0.1 (:50051 for the primary, :50052 for the demo peer). The BGP listeners are bound to the internal demo addresses only, so nothing is exposed on the VM's routable interface.

This VM's TCP-MD5 key lives only in /root/gobgp-credentials.txt, which only root can read. Verify the listeners and the key with:

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 and 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 configuration file. For example, inject a route with gobgp global rib add <prefix> -a ipv4, or add a neighbor with gobgp neighbor add <ip> as <asn>. Run gobgp --help or gobgp <command> --help for full command help.

Managing the service

Check the daemon's status and read its recent log with:

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 only to make the image a working reference deployment. After you configure your own peers, you can disable them for a clean single-daemon setup with sudo systemctl disable --now gobgpd-peer.service gobgp-demo-routes.service.

Support

Every SecureAnyCloud deployment is patched at build time, ships with unattended security updates enabled and includes 24/7 SecureAnyCloud support. For help with this image, contact support through the Azure Marketplace listing or at secureanycloud.com.

Deploy on Azure

Launch GoBGP on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure