Networking Azure

Peering Manager on Ubuntu 24.04 on Azure User Guide

| Product: Peering Manager on Ubuntu 24.04 LTS on Azure

Overview

This image runs Peering Manager 1.10.4, the open source source of truth for BGP peering, on Ubuntu 24.04 LTS. Peering Manager models your autonomous systems, BGP groups, direct peering sessions, Internet exchanges and routers, keeps them in sync with PeeringDB, and generates router configuration from templated routing policies. It exposes everything through a full REST API, so network engineers can document, manage and automate their external BGP peering from one authoritative platform.

cloudimg delivers Peering Manager fully installed and reverse proxied behind nginx, with the gunicorn application server, the background request queue worker, PostgreSQL 16 and Redis 7 already configured and managed by systemd, so a complete peering management platform is operational within minutes of launch.

What is included:

  • Peering Manager 1.10.4 installed from the official release into /opt/peering-manager, running in a dedicated Python virtual environment
  • PostgreSQL 16 as the primary database and Redis 7 as the task queue and cache backend
  • gunicorn serving the Django application on 127.0.0.1:8001, fronted by nginx on port 80
  • A background request queue worker (peering-manager-rq.service) for configuration generation and PeeringDB synchronisation
  • Five systemd units enabled and active: postgresql, redis-server, peering-manager, peering-manager-rq and nginx
  • Secure by default: no administrator account and no shared secret ship in the image. On first boot a unique Django secret key, a unique database password, a unique administrator account and a REST API token are generated and written to a root only file
  • A fully patched Ubuntu 24.04 LTS base with unattended security upgrades enabled
  • 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is the recommended size for evaluation and small deployments; for larger fabrics choose a size with more memory. NSG inbound: allow 22/tcp from your management network and 80/tcp for the web interface. Peering Manager serves plain HTTP on port 80; for production or shared access, terminate TLS in front of it with your own domain (see the final step).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Peering Manager by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name peering-manager \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

# Open the HTTP port so you can reach the web interface
az vm open-port --resource-group <your-rg> --name peering-manager --port 80 --priority 900

Step 3 - Retrieve the per VM admin credentials

Nothing secret is baked into the image. On the very first boot, a one shot service (peering-manager-firstboot.service) generates a fresh Django secret key, a fresh database password, a unique administrator account and a REST API token, all unique to your instance. It writes them to /root/peering-manager-credentials.txt, readable only by root. SSH in as azureuser and read them:

$ sudo cat /root/peering-manager-credentials.txt
# Peering Manager - generated on first boot by peering-manager-firstboot.service.
# These credentials are unique to THIS VM. Store them somewhere safe.

peering_manager.url=http://20.55.10.42/
peering_manager.admin.user=admin
peering_manager.admin.pass=Xq7pR2mK9wU4nZ8vB3hL6yD1
peering_manager.api.token=8f3c1e0a9b2d4c6e8f0a1b2c3d4e5f60718293a4

# Canonical keys consumed by the cloudimg smoke verifier + guide substitution:
PEERING_MANAGER_ADMIN_PASSWORD=Xq7pR2mK9wU4nZ8vB3hL6yD1
PEERING_MANAGER_API_TOKEN=8f3c1e0a9b2d4c6e8f0a1b2c3d4e5f60718293a4

The peering-manager-firstboot.service one shot is ordered before the application services, so the web UI only ever starts once every per VM secret has been generated. The values above are an example; your instance will have its own unique credentials.

The peering-manager first boot service is enabled and its script header describing the per VM secret rotation

Step 4 - Confirm the services are running

Check that PostgreSQL, Redis, the Peering Manager application, the request queue worker and nginx are all active:

sudo systemctl is-active postgresql redis-server peering-manager peering-manager-rq nginx

All five report active. gunicorn binds to loopback only (127.0.0.1:8001) and nginx publishes the interface on port 80:

sudo ss -tlnp | grep -E ':80 |:8001 '

The five Peering Manager services reporting active and the listening ports, nginx on 80 and gunicorn on 127.0.0.1:8001

Step 5 - Confirm the web endpoints

The sign in page is public and returns 200. Peering Manager requires authentication for everything else, so an anonymous request to the application is redirected to the login page and the REST API returns 403 without a token. This is the secure default.

curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://localhost/login/

curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://localhost/

curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://localhost/api/peering/autonomous-systems/

The login page returning 200, an anonymous request redirected to login, and the REST API returning 403 without a token

Step 6 - Sign in to the web UI

Browse to http://<vm-ip>/ and sign in as admin with the password from /root/peering-manager-credentials.txt. Peering Manager opens on the login page.

The Peering Manager sign in page served on port 80

After signing in you land on the home dashboard, with panels summarising your autonomous systems, BGP groups, Internet exchanges, sessions and routers. The screenshots in this guide show Peering Manager populated with a small set of example objects; a freshly deployed instance starts empty and ready for you to model your own peering.

The Peering Manager home dashboard after signing in, showing peering summary panels

Step 7 - Model your peering: autonomous systems and Internet exchanges

Under Autonomous Systems you record every network you peer with, keyed by ASN, along with its name, IRR AS-SET, maximum prefix limits and routing policies. Peering Manager can enrich each entry from PeeringDB and track how many direct and IX sessions you have with it.

The Autonomous Systems list showing example peer networks with their ASN, name and session counts

Under Internet Exchanges you record the exchange fabrics you connect to, each fronted by your own affiliated autonomous system. From there you attach the IX peering sessions you establish across each fabric.

The Internet Exchanges list showing an example exchange fronted by the affiliated autonomous system

Step 8 - Use the REST API

Peering Manager exposes a complete REST API under /api/. Use the token from /root/peering-manager-credentials.txt in the Authorization: Token <token> header to call any endpoint. Read the token into a shell variable and query your autonomous systems:

TOKEN=$(sudo grep '^PEERING_MANAGER_API_TOKEN=' /root/peering-manager-credentials.txt | cut -d= -f2-)
curl -s -H "Authorization: Token $TOKEN" -o /dev/null -w 'HTTP %{http_code}\n' http://localhost/api/peering/autonomous-systems/

The authenticated call returns 200; the same call with no token returns 403, proving the per VM token is doing the work:

$ curl -s -H "Authorization: Token $TOKEN" http://<vm-ip>/api/peering/autonomous-systems/
count=6
 - AS2906 Netflix
 - AS13335 Cloudflare
 - AS15169 Google
 - AS16509 Amazon
 - AS32934 Meta

$ curl -s -H "Authorization: Token $TOKEN" http://<vm-ip>/api/peering/internet-exchanges/
count=1
 - AMS-IX

The REST API returning the example autonomous systems and Internet exchanges when called with the per VM token

You can create additional API tokens from Admin > API Tokens in the web UI, each scoped to a user and optionally read only.

Step 9 - Enable HTTPS with your own domain

Peering Manager ships on plain HTTP on port 80 so it works immediately. For production, point a DNS record at the VM's public IP, add the hostname to ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS in /opt/peering-manager/peering_manager/configuration.py, and terminate TLS with a certificate. A common approach is to obtain a certificate with certbot and reverse proxy through nginx, or to place Azure Application Gateway in front of the VM. Restart the application after editing the configuration:

$ sudo systemctl restart peering-manager peering-manager-rq

Administration and support

The Peering Manager manage.py command is wrapped for convenience: run sudo peering-manager-manage <command> (for example sudo peering-manager-manage createsuperuser to add another administrator). The application configuration lives in /opt/peering-manager/peering_manager/configuration.py, and Peering Manager and its request queue worker are managed with sudo systemctl restart peering-manager peering-manager-rq.

This image is a repackaged open source software product with additional charges for cloudimg support services. Our engineers provide 24/7 support for deployment, upgrades, TLS termination, LDAP and SSO integration, API automation and scaling. Peering Manager is a trademark of its respective owner; use of the name here is purely to identify the software this image packages.