Peering Manager Ubuntu 24.04

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a 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.

Configure the network security group (NSG) to allow inbound 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 Step 9).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Peering Manager by SecureAnyCloud, and select Create.

On the Basics tab, 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).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:peering-manager-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name peering-manager \
  --image sac1647283583153:peering-manager-ubuntu-24-04:default:latest \
  --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.

The service writes them to /root/peering-manager-credentials.txt, which only root can read. SSH in as azureuser and read the file:

$
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 sac smoke verifier + guide substitution: PEERING_MANAGER_ADMIN_PASSWORD=<set-at-first-boot> PEERING_MANAGER_API_TOKEN=<set-at-first-boot>

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

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 web interface on port 80. Confirm the listeners:

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

Step 5 - Confirm the web endpoints

The sign-in page is public and returns 200. Peering Manager requires authentication for everything else. 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/

Step 6 - Sign in to the web UI

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

You land on the home dashboard, with panels that summarise your autonomous systems, BGP groups, Internet exchanges, sessions and routers. A freshly deployed instance starts empty, ready for you to model your own peering. The example objects in this guide are sample data.

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

Open Autonomous Systems to record every network you peer with, keyed by ASN. Each entry holds 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.

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

Step 8 - Use the REST API

Peering Manager exposes a complete REST API under /api/. To call any endpoint, send the token from /root/peering-manager-credentials.txt in the Authorization: Token <token> header. Read the token into a shell variable, then 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, which shows that the per-VM token is doing the work. Example responses:

$ 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

To create additional API tokens, open Admin > API Tokens in the web UI. Each token is scoped to a user and can be read-only.

Step 9 - Enable HTTPS with your own domain

Peering Manager ships on plain HTTP on port 80 so that 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, then 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 you edit 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. Restart Peering Manager and its request queue worker with sudo systemctl restart peering-manager peering-manager-rq.

This image is a repackaged open-source software product, with additional charges for SecureAnyCloud 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, and the name is used only to identify the software this image packages.

Deploy on Azure

Launch Peering Manager 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