SURF is building a new generation of the SURF network. This blog is part of a series of blogs about SURFnet Infinity. With SURFnet Infinity, SURF has opted for a vendor-neutral architecture based on open standards, ensuring that the network can continue to develop without restriction. You can read more about the new SURF network here.
In this blog, we’ll take a closer look at the technology and focus on SURFnet Infinity’s new peering network.
The first step
Replacement of the peering routers
In 2025, we quietly carried out a migration of the existing peering routers in the SURFnet8 domain. Until August 2025, all of SURF’s external connections were directly connected to the core routers in Amsterdam. There was a need for greater capacity and increased resilience within the SURF network. As the high-level architecture of the SURFnet Infinity network had already been finalised at that point, we decided to apply the new architecture here for the first time. Dedicated peering routers enable faster capacity expansions, a higher level of resilience in the event of DDoS attacks, and a smaller blast radius. The latter is a key aspect in the separation of network services, as it allows us to significantly limit the impact on other domains.
In early 2026, we migrated the existing Corero anti-DDoS service to the new package, Smartwall One. This is still linked to the existing Juniper MX-based peering routers, but offers plug-and-play capability for integration with PTX routers.
In July and August 2026, the migration to the new PTX platform took place. New PTX10002-36QDD routers were installed at the main peering locations, Equinix AMS7 and Nikhef. Both routers were provided with direct connections to the new SURFnet Infinity core network, which is currently under construction, as well as direct connections to the SURFnet8 core network. This enables us to gradually migrate customers from SURFnet8 to SURFnet Infinity, with sufficient capacity and without any impact on internet services. By migrating the peering routers ahead of the metro sites and connecting them to both core networks, we can focus fully on migrating the customer sites. There is no need to take routing or capacity into account, as this complex work has already been carried out.
A diagram is shown below:
Migration process
From a bird’s-eye view, such a migration process looks like this:
- – installation of the new routers
- – establishing connections with the SN8 core and the SN∞ core
- – integrate anti-DDoS platform
- – Migrating the external connections one by one
This migration was preceded by a major project plan, with the constant aim of causing no impact – or as little as possible – on service delivery. A great deal of planning went into this, particularly at our Nikhef site. Within SURFnet8, one of SURF’s most important peering locations was Digital Realty AMS9. In 2025, SURF decided to relocate the network core to the data centre of one of its members, Nikhef. The Nikhef data centre is one of Amsterdam’s most important connectivity hubs, making it the ideal location for peering. More information about the collaboration: https://www.surf.nl/en/news/surf-moves-network-core-from-private-business-to-member-organisation
Following consultations with various external parties and peering partners, the necessary cross-connects were requested between Digital Realty AMS9 and Nikhef. This enabled us to connect existing links from parties not physically present at Nikhef to the new peering nodes.
Field engineers will then migrate all connections from the MX peering router to the PTX peering routers. This means that the optics and fibres will be reconnected on a one-to-one basis. Afterwards, network engineers can use the automation platform developed by SURF to transfer the configuration at the touch of a button. This helps to ensure that the migration proceeds smoothly and without errors.
Actual migration: a shift in traffic patterns
The actual migration began in the week of 20 July 2026. We opted for a two-stage approach. At the Asd002a site, the migration was carried out using the ‘big bang’ method. On Monday 20 July at around 10.00, the first gateways were migrated to the new PTX platform. The entire migration was completed that same day at around 13.30. The graph below clearly shows the shift in traffic from SURFnet8 peering (in red) to SURFnet Infinity∞ (in green) at the asd002a site.
For the peering migration at site Asd001b, we opted for a phased approach. Various external connections needed to be relocated from site Asd001b (Digital Realty AMS9) to Asd066d (Nikhef). Due to the need to re-establish several campus cross-connects and set up new connections, this migration has been spread over several weeks. We are currently still awaiting the final handover and hope to have fully migrated to the PTX platform at Asd066d by the end of October 2026.
Distribution of traffic between SURFnet 8 and SURFnet∞
At present, the migration to the SURFnet Infinity metro network is still well into the design and installation phase. For most customers, this means that internet traffic is still routed via the SURFnet 8 core network. For a small number of metro locations, the migrations to SURFnet∞ have already been completed. We can also already see that traffic from the peering nodes is travelling via the SURFnet∞ core network. This is shown below, where traffic from our peering routers to SURFnet Infinity is shown in green and traffic to the SURFnet 8 core network is shown in red.
Next step: 3rd peering PoP in Frankfurt
To make the SURF network even more robust, we have decided to also implement geographical redundancy. As part of the expansion of our Cross-Border network, we are also building a new PoP in Frankfurt. This will enable us to establish external connections here as well, as a fully-fledged part of our peering strategy. The aim is to establish connections with other networks at this location later in 2026, thereby increasing our redundancy and capacity.
Further information
Would you like to find out more about SURFnet Infinity?
Follow this project on this page. We also post regular project updates on the network dashboard. Alternatively, please contact us at joachim.opdenakker@surf.nl