github inex/IXP-Manager v7.1.0
v7.1.0 Enhanced Security for Administrative Functions, and Much More
on GitHub

6 hours ago
image

We are pleased to announce the immediate availability of IXP Manager v7.1.0. This is primarily a security update that enables IXP administrators to protect access to administrative functions at the web server level, thereby reducing the potential attack surface by 72%.

This release also includes bug fixes and many new features.


Release Summary

git --no-pager diff --shortstat v7.0.1 v7.1.0
 264 files changed, 11753 insertions(+), 5203 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here. Follow these, including the database migrations.

NB: Before you disable maintenance mode, see the IPv6 max prefixes section below for how to check for inconsistencies.

New Features

Securing Administrative Functions

IXP Manager has always been both an administrative portal for organisations that run IXPs and a member/customer portal for the participants at an IXP. This creates a security paradox in that IXP Manager's administrative frontend must be publicly available if IXPs wish to provide the customer portal element.

To address this, v7.1.0 has prepended all administrative-only URLs, both web and API, with admin/. This will allow IXP administrators to restrict access to these prepended URLs to known-safe IP addresses via web server access lists, for which we provide examples for Varnish, Apache and Nginx here.

You can review the documentation here - https://docs.ixpmanager.org/7.1/install/security/.

Transition Settings

Prepending web requests with /admin should not cause any issues. However, IXPs that consume a number of the API endpoints may not be able to repoint them all to their newer /admin versions in a single maintenance window.

For this reason, IXP Manager v7.1.0 will ship with these API endpoints available under both /api/v4/... as before and also /admin/api/v4/.... Any requests to /api/v4/... will be logged, and these can be grepped as follows: 

/srv/ixpmanager $ cat storage/logs/laravel.log | grep grep 'UNPREPENDED/DEPRECATED'
[2026-02-15 10:10:20] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/nagios/switches/2 from 127.0.0.1
[2026-02-15 10:27:01] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/router/gen-config/as112-cork-ipv4 from 127.0.0.1
[2026-02-15 10:27:07] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/router/gen-config/as112-lan1-ipv4 from 127.0.0.1

This default will be changed in the next minor release.

Once you transition the clients consuming the APIs from the unsecured endpoints (/api/v4) to the secured endpoints (/admin/api/v4), you can disable the unsecured endpoints ahead of the next minor release via the Authentication / Unsecured API Access Enabled checkbox on the Settings frontend, or by setting the following in your .env file: 

UNSECURED_API_ACCESS=0

Router Configuration Improvements

Previous versions of IXP Manager shipped with individual sample route server, route collector and AS112 router (re)configuration scripts. However, these all essentially do the same thing, and in v7.1 we have merged them into this improved script - tools/runtime/outer-reconfigure-scripts/api-reconfigure-example-birdv2.sh.

Improvements include:

  • new unified script to handle as112/collectors/servers
  • new script releases lock via new API call on early exit
  • added unit tests for the lock/release API calls
  • database calls and database locking moved from model to controller for better testing

The documentation has been updated to reference and explain this new script, and we recommend you migrate to this new script, which, if you have not yet, will also implement lock/release for updates.

AS112

IXP Manager v7.1 includes an improved AS112 Bird2 template that now also utilises RPKI when available.

We are also releasing the templates for INEX's AS112 implementation with PowerDNS, as documented here. These are backed by a new testing framework in our Vagrant development environment and phpunit tests.

Route Server/Collector/AS112 Template Updates

The templates for the route servers, collectors and AS112 have been modernised to the latest BIRD 2 configuration standards since v2.14. There are no logic changes; it's essentially updating configuration elements, which modern BIRD v2 now warns about.

Examples include: 

# old syntax
function filter_rpki()

# new with return type
function filter_rpki() -> bool

# old syntax with variable definitions outside filter
filter f_import_as65500
prefix set allnet;
ip set allips;
int set allas;
{

# new syntax
filter f_import_as65500
{
    prefix set allnet;
    ip set allips;
    int set allas;

# old syntax
password "foobar";

# new syntax includes mechanism
password "foobar";
authentication md5;

If you are running BIRD >= v2.14, you can update your templates by changing the router definitions as follows:

  • Route servers: api/v4/router/server/bird2/standard -> api/v4/router/server/bird2-2025/standard
  • Route collectors: api/v4/router/collector/bird2/standard -> api/v4/router/collector/bird2-2025/standard
  • AS112: nothing required, the changes are in the standard template from IXP Manager v7.1.

Honour Graceful BGP Session Shutdown well-known BGP community (#960)

The above templates also include this from @job:

BCP 214, section 3.1.1, suggests using the well-known GRACEFUL_SHUTDOWN BGP community [RFC8326] to facilitate smooth drainage of traffic prior to BGP session tear down. The goal is to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link planned to be shut down.

With this routing policy change, Route Servers will preemptively converge onto alternative paths (provided those exist), or just continue to use the marked path until it is withdrawn. In other words, this implements a form of "make before break".

Even when no alternative paths exist in the Route Server's Loc-RIB itself, it is beneficial to promote the use of this BGP community, because its presence allows the RS peers (which hopefully /do/ have alternative paths!) to preemptively converge.

Introduction of IPv6 Max Prefix Settings

As requested in #937, we now introduce a new IPv6 max prefix setting so that different values can be entered for ipv4 and ipv6, as these tend to vary wildly.

NB: The IPv6 max prefix values will be initialised to the current IPv4 setting during the migration, as these were used for both.

As a reminder, the value for maxc prefixes is determined as follows:

The ipv4/6 max prefix setting on the customer is known as the global max prefixes value. It is used to work out the appropriate max prefixes value to apply to all router ipv4/ipv6 configurations in the stock / default templates (route collector and servers, AS112). The calculated value is also included in emails from the Peering Manager from customer to customer.

It is also possible to set a max prefixes value on a per VLAN interface basis. This should be avoided unless it is something you need to do.

The max prefixes value is worked out in the code when generating router configuration is as follows:

  1. The the VLAN interface value if set, otherwise the global value as set on the customer as above
  2. If neither is set, a default value is used (this can be changed in the Settings UI or the .env file).

The defaults can be updated in the Settings frontend, or via the following (defaults shown) in your .env: 

IXP_DEFAULT_MAXPREFIXES_V4=250
IXP_DEFAULT_MAXPREFIXES_V6=50

During the upgrade process, you should check for max prefix inconsistencies as the evaluation has changed if a value was set on the customer and on a vlan interface:

  • Before v7.1: the greater of the two.
  • From v7.1: the value on the vlan interface.

Run the following artisan command: 

$ php ./artisan update:max-prefixes-7.1.0

In IXP Manager v7.1, we have made some changes to how max prefixes is handled. In previous
versions, a max prefixes setting on a VLAN interface only took effect if it was greater than
the global (as set on the customer) value.

This is not intuitive as we should allow the more specific setting on the VLAN interface, whether
lower or higher than the global, take precedence.

This script will identify any settings on VLAN interfaces that are lower than the global setting,
as these will start to take effect, and give you the option to clear the setting.

This tool will walk you through any inconsistencies and ask you to make a decision on what do with each.

RPKI

RPKI RTR Version Settings in BIRD

BIRD has the following RPKI RTR settings: 

min version num

    Minimal allowed version of the RTR protocol. BIRD will refuse to downgrade a 
    connection below this version and drop the session instead. Default: 0

max version num

    Maximal allowed version of the RTR protocol. BIRD will start with this version. 
    Use this option if sending version 2 to your cache causes problems. Default: 2

To allow you to set these without skinning the templates, there are new settings UI/.env options as follows: 

IXP_RPKI_RTR1_MIN_VERSION=0
IXP_RPKI_RTR1_MAX_VERSION=2
IXP_RPKI_RTR2_MIN_VERSION=0
IXP_RPKI_RTR2_MAX_VERSION=2

Use RFC-compliant RPKI-ROV procedure

Contributed by @job.

@job correctly pointed out in #692 that: 

roa_check(roa_v4, net, bgp_path.last);

is recommended over 

roa_check(roa_v4, net, bgp_path.last_nonaggregated);

Use RTR timers signaled by the Cache or fall back to BIRD's default values (#961)

This change from @job implements two things: if the cache signals preferred timer values through the RTR End-of-Data PDU, those will be honored; and if no timer values are communicated by the cache itself, BIRD's default timers are used. BIRD's default timer interval values are the same timer values recommended in RFC 8210, section 6, which are as follows: 

  Expiry interval:  7200 seconds
  Refresh interval: 3600 seconds
  Retry interval:    600 seconds

🚨 This will cause the rpki protocols to reset, but this will not affect any existing BGP sessions or routes.

@job has much more information in #961.

Implement RIPE REST API to update RIPE objects (#953)

Some RIRs offered a facility to update RIR database objects via email, but RIPE phased it out at the end of 2025.

IXP Manager v7.1 implements RIPE's REST API to update existing objects instead of using email - this is documented here and implemented via commit 398be9c.

Other Improvements and Fixes

  • [BF] Allow routers to be unpaired - 755531b
  • [IM] Improve as112/route server peering - 86ae07b
  • [BF] broken link in diagnostic controller (via @sparkeh) - 852b4fe
  • [IM] Include closed customers on interface wizard - f231dc9
  • [BF] Stop annoying pop-up that occurs occasionally on customer overview - 5498120
  • [IM] Diagnostics - Only query routers with APIs, and return correct message for no protocol - 2050bc6
  • Update IEEE OUI URL - 61ea164
  • [IM] Replace IX-F URL as they appear to have changed it - 8e93635
  • [BF] Fix event handler for new notes - closes #944
  • [IM] Allow an infrastructure to be excluded from IX-F Export - fixes #788
  • [IM] IX-F export - members without connections are not included
  • fix: int cast before === User::AUTH_PUBLIC (https://github.com/inex/IXP-Manager#956)
  • Update ExportGroup.php: remove facility access related fields (https://github.com/inex/IXP-Manager#954)
  • [BF] Fix PeeringDB/OAuth/2fa conflict - #952
  • [BF|IM] Fix PeeringDB API request - closes #950
  • [IM] Add User-Agent to MANRS request in addition to agreed headers - 932ea58
  • [IM] Add User-Agent to IX-F API request - c9cda8e
  • [NF] Add a maintenance notice template - 836b504
  • [BF] Fix Undefined array key issue on virtints without physints - e6686b7

CI Results for this Release

~/dev/ixpm-inex main*
❯ ./vendor/bin/phpunit
PHPUnit 11.5.53 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.4.17
Configuration: /Users/barryo/dev/ixpm-inex/phpunit.xml

...............................................................  63 / 390 ( 16%)
............................................................... 126 / 390 ( 32%)
............................................................... 189 / 390 ( 48%)
............................................................... 252 / 390 ( 64%)
............................................................... 315 / 390 ( 80%)
............................................................... 378 / 390 ( 96%)
............                                                    390 / 390 (100%)

Time: 03:01.203, Memory: 104.50 MB

OK (390 tests, 3197 assertions)

~/dev/ixpm-inex main* 3m 1s

❯ ./vendor/bin/psalm --use-baseline psalm-baseline.xml

Running on PHP 8.4.17, Psalm 6.15.1@28dc127af1b5aecd52314f6f645bafc10d0e11f9.

JIT acceleration: ON

JIT compilation in progress... Done.

Target PHP version: 8.4 (inferred from current PHP version).


Scanning files...

3204 / 3204...

Analyzing files...

░
------------------------------

       No errors found!

------------------------------

Checks took 5.04 seconds and used 773.695MB of memory
Check out latest releases or
releases around inex/IXP-Manager v7.1.0

Don't miss a new IXP-Manager release

NewReleases is sending notifications on new releases.

Get notifications