Networking Azure

IXP Manager on Ubuntu 24.04 on Azure User Guide

| Product: IXP Manager 7.3.1 on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of IXP Manager 7.3.1 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. IXP Manager is the open source platform that operates an Internet Exchange Point, developed by INEX and in production at over 250 exchanges worldwide.

It manages members and their peering ports, IXP LAN and VLAN addressing, patch panels and colocated equipment. It generates route server, route collector and switch configuration, builds IRRDB based prefix and AS path filters, publishes peering matrices and peer to peer traffic statistics, exports the IX-F member list, and gives every member a self service portal for their own ports, sessions and graphs.

The image installs the pinned upstream release tag v7.3.1 from the official IXP Manager repository, following the procedure in the project's own Ubuntu 24.04 installer. The full stack is wired together at build time and the database schema is migrated and seeded, so the first page you reach is a working sign in rather than an installer.

Security by design — no baked login credential. Nothing usable ships in the image. On first boot ixp-manager-firstboot.service generates a fresh Laravel application key, a fresh MySQL password and a fresh superuser password, all unique to your VM, and writes them to /root/ixp-manager-credentials.txt (mode 0600, root only). The build time secrets are overwritten with random values that are generated, used once and discarded, so no image and no person holds a working credential for your machine.

Security by design — two factor authentication is compulsory. IXP Manager enforces 2FA on superuser accounts. Your first sign in is required to enrol an authenticator app before anything else renders. No 2FA enrolment ships in the image, so the second factor is genuinely yours alone (see Step 5).

Security by design — only the web tier is reachable. MySQL is bound to 127.0.0.1 and memcached to the loopback only, so the database and cache are never exposed off box. Apache refuses to serve the .env file that holds your secrets.

A placeholder IXP identity you replace. So the application is immediately functional, the image ships a clearly marked placeholder identity (shortname EXAMPLE, ASN 65535, which is a reserved ASN and deliberately not a real exchange's). Step 8 walks you through replacing it with your own.

What is included:

  • IXP Manager 7.3.1 (pinned upstream release tag), a Laravel 12 application

  • Apache 2.4 + PHP 8.4 + MySQL 8.0 + memcached, configured and enabled

  • Database schema migrated and seeded with the upstream reference data (router vendors, IRRDB sources, contact groups)

  • Per VM secret generation on first boot — application key, database password and superuser password

  • Compulsory two factor authentication on the superuser account, with no enrolment baked into the image

  • The upstream task scheduler cron entry installed and running

  • Unattended security upgrades left enabled

Prerequisites

  • Active Azure subscription, SSH public key, VNet + subnet in the target region

  • Subscription to the IXP Manager listing on Azure Marketplace

  • Network Security Group rules allowing TCP 22 for administration and TCP 80 for the web portal, both restricted to your own management network

  • An authenticator app (any TOTP app, such as Google Authenticator, 1Password or Aegis) to complete the compulsory 2FA enrolment at first sign in

Recommended virtual machine size: Standard_B2ms (2 vCPU, 8 GB RAM) for a production exchange. Larger exchanges collecting sflow and generating many route server configurations should use Standard_D2s_v5 or larger.

Step 1: Deploy from the Azure Portal

Search IXP Manager in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 22 and TCP 80 from your management network only. Do not expose the portal to the whole internet until you have completed Step 9 and put TLS in front of it.

Step 2: Deploy from the Azure CLI

RG="ixp-prod"; LOCATION="eastus"; VM_NAME="ixp-manager"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/ixp-manager-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard

Step 3: First boot

On the first boot the VM generates every secret it needs. ixp-manager-firstboot.service runs once, before Apache starts serving, and:

  1. rotates the MySQL password and rewrites .env in lock step,
  2. resolves the VM's reachable address from Azure IMDS and sets APP_URL,
  3. generates a fresh Laravel APP_KEY and rebuilds the configuration cache,
  4. rotates the superuser password,
  5. writes everything to /root/ixp-manager-credentials.txt and drops a sentinel so it never runs again.

Give it about thirty seconds after the VM reports running, then confirm the whole stack is up.

Step 4: Confirm the stack is running

systemctl is-active apache2.service mysql.service memcached.service ixp-manager-firstboot.service

All four report active. ixp-manager-firstboot.service is a oneshot unit with RemainAfterExit=yes, so active means it completed successfully.

systemctl reports apache2, mysql, memcached and ixp-manager-firstboot all active, and the firstboot unit status shows it ran once and exited successfully with the credentials written

Confirm the component versions and that the sign in page is being served:

php -v | head -1
sudo mysql -N -B -e 'SELECT VERSION();'
sudo php /srv/ixpmanager/artisan --version
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1/login

php reports 8.4.23, MySQL reports 8.0.46, artisan reports Laravel Framework 12.63.0 and a curl of the local login page returns HTTP 200

Read your per VM credentials. This file is mode 0600 and readable only by root:

sudo cat /root/ixp-manager-credentials.txt

the credentials file lists the portal URL, the admin username, the generated admin password, and the database name, user and generated password, with a note that sign in is by username and not email address

IXP Manager signs in by username, not by email address. The username is admin; the password is the ixpmanager.admin.pass value above and is unique to your VM.

Step 5: First sign in and compulsory 2FA enrolment

Browse to http://<vm-ip>/ and sign in with the username and password from Step 4.

the IXP Manager sign in page asking for a username and password, served over the VM public address

Because IXP Manager enforces two factor authentication for superusers, the first thing you see after signing in is the 2FA enrolment page, and nothing else renders until you complete it. Scan the QR code with your authenticator app, enter the six digit code it shows plus your password, and click Enable 2FA.

the Security Two Factor Authentication page explaining that 2FA is compulsory for this account, with a QR code to scan and fields for the one time code and the account password

No 2FA enrolment is baked into the image, so the secret behind that QR code is generated on your VM and known only to you. Store your authenticator recovery method safely: with 2FA enforced, losing it means losing portal access.

Once enrolled you land on the IXP Manager dashboard.

the IXP Manager admin dashboard showing overall member numbers and aggregate traffic graphs, with the full IXP member actions and IXP admin actions navigation in the sidebar

The aggregate traffic graphs are marked DUMMY. That is IXP Manager's built in placeholder: real graphs appear once you point the statistics backend at your own switches, which is outside the scope of a single VM image.

Step 6: Review the seeded reference data

The build migrates the schema and seeds the upstream reference data, so the application is populated and usable straight away:

sudo mysql -t ixpmanager -e "SELECT 'infrastructure' AS entity, COUNT(*) AS rows_ FROM infrastructure UNION ALL SELECT 'members (cust)', COUNT(*) FROM cust UNION ALL SELECT 'router vendors', COUNT(*) FROM vendor UNION ALL SELECT 'IRRDB sources', COUNT(*) FROM irrdbconfig UNION ALL SELECT 'contact groups', COUNT(*) FROM contact_group UNION ALL SELECT 'users', COUNT(*) FROM user;"
ss -tln | grep -E ':(80|3306|11211)\s'

a table showing one infrastructure, one member, eighteen router vendors, thirteen IRRDB sources, four contact groups and one user, and ss showing MySQL on 127.0.0.1:3306, memcached on the loopback and Apache on port 80

Note that MySQL and memcached listen on the loopback only — only Apache on port 80 is reachable from off the VM.

The placeholder member is visible in the portal under Members:

the Members List page showing the seeded Example Internet Exchange Point member with AS65535, a mandatory peering policy, internal infrastructure type and normal status

Step 7: Explore the exchange management features

The Infrastructures page defines the physical and logical exchange fabrics your members connect to:

the Infrastructures List page showing the seeded EXAMPLE infrastructure marked as the primary infrastructure

VLANs carry the IXP peering LANs, each with its IPv4 and IPv6 addressing that IXP Manager allocates to member ports:

the VLANs List page listing the peering VLAN defined for the seeded infrastructure

The peering matrix is the view members use to see who peers with whom across the exchange:

the peering matrix page showing the grid of members against members for the exchange

Step 8: Replace the placeholder IXP identity with your own

The image ships a placeholder identity so the portal works immediately. Replace it with your exchange's real details in .env:

sudo grep -E '^IDENTITY_|^APP_NAME' /srv/ixpmanager/.env

Edit the values (site name, legal name, city, country, support and billing contacts, corporate URL), then rebuild the configuration cache and reload Apache so the change takes effect:

sudo php /srv/ixpmanager/artisan config:cache
sudo systemctl reload apache2

The exchange entity itself, its ASN and its infrastructures are managed in the portal under IXP Admin Actions, not in .env. Update the seeded EXAMPLE infrastructure and the placeholder member to match your exchange, or delete them once you have created your own.

Step 9: Put TLS in front of the portal

The image serves plain HTTP on port 80 so it works the moment it boots. IXP Manager handles member data and superuser sessions, so put TLS in front of it before you expose it beyond your management network. Point a DNS name at the VM, then obtain a certificate and let the client update the Apache virtual host:

sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d ixp.your-domain.example

Then set APP_URL in /srv/ixpmanager/.env to the https:// name, run sudo php /srv/ixpmanager/artisan config:cache, and reload Apache. Restrict the Network Security Group so port 80 and 443 are reachable only from the networks that need the portal.

Step 10: The task scheduler

IXP Manager runs its periodic work through the Laravel scheduler, which the image installs as a system cron entry:

cat /etc/cron.d/ixpmanager

This runs artisan schedule:run every minute as www-data, which is what upstream requires. Leave it in place.

Step 11: Administration and upgrades

Run any IXP Manager or Laravel command through artisan:

sudo php /srv/ixpmanager/artisan list --raw | grep '^ixp-manager:'

The application lives in /srv/ixpmanager, its configuration in /srv/ixpmanager/.env, and its logs in /srv/ixpmanager/storage/logs. Back up both the ixpmanager database and the .env file — the APP_KEY in .env is required to read anything the application has encrypted.

Operating system and Apache, PHP and MySQL packages continue to receive security updates through unattended upgrades. IXP Manager itself is pinned to the release this image shipped; follow the upstream release notes when you choose to move to a newer version.

Step 12: Security recommendations

  • Keep 2FA enrolled on every superuser account. IXP Manager enforces it, so do not disable the enforcement setting.

  • Restrict the Network Security Group so TCP 22 and TCP 80/443 are reachable only from your management networks, and put TLS in front of the portal before wider exposure (Step 9).

  • Treat /root/ixp-manager-credentials.txt as a one time handover: record the values in your password manager, then remove the file.

  • Change the superuser password from the generated one after first sign in, under My Account, and create named accounts for each operator rather than sharing admin.

  • Leave MySQL and memcached bound to the loopback. Nothing outside the VM needs to reach them.

  • Back up the ixpmanager database and /srv/ixpmanager/.env together, and store the backups encrypted.

Step 13: Support and Licensing

IXP Manager is free and open source software, published by INEX under the GNU General Public License version 2.0. The licence text ships with the application at /srv/ixpmanager/LICENSE. Upstream project documentation is at docs.ixpmanager.org.

This image is built and maintained by cloudimg. Support for the image, including deployment questions and security updates, is available 24/7 through the support channel listed on the Azure Marketplace offer page.