Hero mask

Resources

Everything you need to design, deploy and operate high-performance network interconnections.

ARCHITECTURAL GUIDELINES

Distributed Internet Exchange

Why a Distributed Internet Exchange Matters

A distributed Internet Exchange extends the benefits of peering far beyond a single metropolitan hub. Instead of centralising traffic in one location, networks can interconnect across a pan-European platform, reducing latency, improving resilience and simplifying expansion into new markets.

Discover how a distributed architecture can help you build a faster, more scalable and geographically resilient network.

Choosing Between a Local and Distributed Internet Exchange

Not all Internet Exchanges are built the same. While traditional local exchanges concentrate interconnection in a single metropolitan area, a distributed Internet Exchange extends connectivity across multiple locations, offering greater flexibility, resilience and reach.

Discover the key differences between both models and learn which approach best fits your network architecture and growth strategy.

Connecting to European Content from the Edge of Europe

For networks outside Europe, delivering fast and reliable access to European content often means investing in expensive transport to multiple Internet Exchanges. NL-ix's distributed platform offers a different approach: connect at the edge of Europe through a single port and gain access to a vast European peering ecosystem.

Discover how to simplify international connectivity while improving performance and reducing infrastructure costs.

Peering & Interconnection

When Transit Alone Isn't Enough

For many growing networks, IP Transit is the simplest way to reach the Internet—but it isn't always the most efficient. As traffic volumes increase, combining Transit with Peering can improve routing, reduce latency and optimise costs without adding unnecessary complexity.

Learn when a hybrid approach becomes the smarter choice and how it can support your network's continued growth.

Consolidating Network Services onto a Single Port

NL-ix combines Peering, Transit, layer 2 Transport services and Cloud Connections over one port... enabling you to save money on patch cables and ports and simplifying manageability.

By combining services over 1 port we enable you to save on the monthly cost of patch cables and ports in use. Multiple services over 1 port also means a single invoice and easer manageability. We also give you more and easier insight into the usage of your port(s) through our My NL-ix portal. Through this customer portal you can easily view the usage per service on your ports.

Using NL-ix means lowering your costs, simplified administration and improved insight.

Designing Internet Connectivity for Mid-Sized Networks

As networks grow, choosing the right Internet connectivity strategy becomes increasingly important. For mid-sized ISPs, enterprises and service providers, balancing performance, resilience and cost requires more than simply adding bandwidth. Explore the key considerations when designing scalable Internet connectivity and

Discover how the right combination of Transit and interconnection services can support long-term growth.

Building Secure Cloud Connectivity

The cloud is currently an important place. But beware, because if your computing power is up in the sky you need a pretty solid connection to it.

The move to the cloud is here to stay. You as an enterprise or organisation have discovered the benefits of Infrastructure available as a Service. But with all that computing power up in the cloud you do need to be sure you are able to access that power when you need it.

You need end-to-end control over the road leading to that mission critical infrastructure in the cloud of choice. You want a stable, predictable, low latency connection that is always on, so you can harness the power of the cloud when and how you need it.

The NL-ix network delivers that control, stability and low latency connections. Build as a part of the Internet Core Infrastructure it is designed to be extremely resilient and as fast as possible. As a pan-European network connecting all major European datacenters it has already build the door-to-door direct connection between the datacenter you are in and all major datacenters of the cloud of your choice and a wide range of locations, saving you the costs of additional transport. Because the cloud is actually just another datacenter.

Discover more about our Cloud Connect Portfolio

Technical Documentation

Peering

Getting Started

When the order has been delivered, you will receive an ‘order delivery’ email. This email - send to you from provisioning@nl-ix.net - contains all details you need to setup your connection. The delivery date is also the start date of invoicing.

Next steps

  • You can update your MAC address of your router via the My NL-ix portal, via Ports > Manage MAC Address.
  • Setup the connection using the information given in de 'order delivery email' and test the connection.
  • Update your PeeringDB page.

Technical Requirements

All members’ use of NL-ix infrastructure shall conform to the relevant standards as laid out in STD0001 and associated Internet standardisation documents.

Each participant’s network must have an ASN (Autonomous System Number) assigned by an appropriate LIR or RIR (Regional Internet Registry), being either ARIN, RIPE-NCC, APNIC or LACNIC. During the application process this assignment will be checked.

Physical

Ethernet ports into NL-ix are offered in following configurations:

1GE – 1000Base-LX

10GE – 10GBASE-LR

Nx10GE – Link Aggregated

100GE – 100GBASE-LR4

Nx100GE – Link Aggregated

NL-ix supports standard single-mode (10km 1310nm) optics by default. For an additional charge, customer may request specialised optics, including extended reach optics in any common 100 Ghz DWDM or CWDM bands.

Options

By default, NL-ix Peering will be offered at line rate.

1G/Nx10/Nx100G

MTU

For the peering LAN an MTU of 1500 bytes is used.

VLAN-tagging

Peering VLAN ports (VLAN 7) must always be tagged.

We use industry standard IEEE 802.1q VLAN trunking, please see your vendor manual for information on how to tag your frames.

MAC address filtering

The Peering service can be used with one MAC address. This MAC address will be configured in the ACL belonging to the customer port. It's not allowed to have multiple MAC addresses configured on the port. Traffic originating from other source MAC addresses is discarded.

Frame types

The following ethernet frame types are accepted:

 0x0800 – IPv4

 0x0806 – ARP

 0x86dd – IPv6

All others are discarded.

Not allowed traffic

The following traffic is explicitly not allowed on the NL-ix Peering VLAN 7:

All broadcast and Non-IP protocols must be disabled facing the IX fabric, or filtered in some way when disabling is not an option. These include, but are not limited to forwarded DHCP, MOP, Ethernet Keepalives, LLDP, CDP (Cisco Discovery Protocol), VTP (VLAN Trunk Protocol), DTP (Dynamic Trunking Protocol), EIGRP (and other IGRP’s), BOOTP, PIM, UDLD

BUM traffic

Only ARP and multicast IPv6 Neighbor Discovery packets are allowed.

NetBIOS and IPv6 Router Advertisements

  1. IP/ICMP Redirects, IP Directed Broadcast and Proxy Protocols including Proxy ARP and IPv6 Proxy Neighbor must be disabled on IX facing interfaces.
  2. Layer-2 protocol traffic: spanning-tree must be disabled on IX facing interfaces.
  3. All Interior Gateway Protocols (IGPs, such as OSPF, IS-IS, RIP, etc) must be disabled on IX facing interfaces.

Open Peering

Interconnecting internationally to other networks via a Transit provider with a full or partial Routing BGP-table is a very effective Routing option. It can be used in combination with Peering either to improve and stabilise critical routes or to cut costs. Using multiple Transit providers over different ports guarantees redundancy. Open Peering is a tried and tested service offering full European coverage with the best routes available. It gives direct access to any network that peers on the Route Servers of all the major European exchanges, supplemented with bilateral peering sessions and the PNI’s of the Open Peering initiative.

Make sure that:

  • You are only advertising routes you are allowed to advertise with prefix lists or similar;
  • You are filtering bogon-routes in and outbound;
  • You configure redundant sessions, both to Nikhef and Telecity 2.
  • You have created RIPE Route-Objects and your AS-SET is correct and up-to-date.

MAC Filtering

NL-ix only permits 1 MAC address per port so any intermediate switches should be made silent.

During turn up, customer’s routing equipment is put into quarantine status to check for common configuration mistakes and to prove that it is suitably configured to participate in the peering fabric. Once verified, customer is placed out of quarantine, moved into production VLAN, and the MAC address of customer’s Routing equipment will be noted and configured. The configured MAC address will stay locked and enforced using L2 ACL. No frames with different source MAC addresses are allowed to enter the peering fabric.

The implementation of MAC filtering is important to protect the NL-ix Peering infrastructure against loops. Customers who intend to swap Routers or otherwise change their MAC address should coordinate this change in advance by configuring the new MAC in the My NL-ix portal. In the event of an after-hours emergency necessitating our help on a MAC change, please call our NOC

Route Server setup for Peering

NL-ix operates multiple Route Servers. Even though Peering with only one Route Server is sufficient for exchanging routes, it is preferred to peer with all Route Servers available in your setup.  Setting up redundant Route Server peers allows to carry out occasional maintenances without impacting your routing and guards against failures.

Preferably always setup 2 IPv4 sessions as well as 2 IPv6 sessions. This way the Route Servers help to get the majority of possible sessions and significantly leverage the burden of keeping track of newly arriving members.

Route Server

NL-ix AS34307:

RS1 - 193.239.116.255 - 2001:7f8:13::a503:4307:1
RS2 - 193.239.117.0 - 2001:7f8:13::a503:4307:2

NL-ix2 AS42604:

RS1 - 185.1.122.127 - 2001:7f8:cd::a504:2604:1
RS2 - 185.1.122.128 - 2001:7f8:cd::a504:2604:2

Route Server Configurator

The Route Server Configurator provides full control over the route server by making it easy to select networks you want to exchange traffic with based on latency times, geographical location and black & white lists.

Learn about the Route Server Configurator

BGP communities Peering

Traffic over the NL-ix Route Server can be managed via BGP communities or the Route Server Configurator (filter.nl-ix.net). Please note that you should make a choice for either the communities or the GUI of the Route Server Configurator. Using both may result in unexpected behaviour. The GUI will not show any communities that are set manually.

More on BGP Communities

Blackholing

For customers that have a host or block under a DDoS, the affected host/block can be advertised with a blackhole community. This will cause all traffic to that host/block to be blackholed at the core of our network. Once the attack has stopped, the community can be removed again in order to start receiving traffic again. NL-ix supports to announce a prefix length up to /32 for IPv4 and up to /128 for IPv6

Blackhole RFC7999 - 65535:666
Blackhole Joint Transit - 24785:666
Blackhole OpenPeering AS20562 - 20562:666

Example

Below is an example for a Cisco router for OpenPeering:

ip route 192.168.1.1 255.255.255.255 Null0
router bgp 6500
network 192.168.1.1 255.255.255.255 route-map blackhole
route-map blackhole permit 10
set community 20562:666

Bogon and martian filtering, BGP filtering

Bogon and martian filtering

A bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPNs or other tunnels) should never have an address in a bogon range. These are commonly found as the source addresses of DDoS attacks.

Bogon filtering filters bogus (fake) IP addresses of a computer network. Bogons can be filtered by using router access-control lists (ACLs), or by BGP blackholing. Full bogons filtering is recommended but not enabled by default. You can start bogon filtering here

BGP filtering

NL-ix advices customers using Peering to follow the BGP Filter Guides

RPKI filtering and RIPE administration

NL-ix secures "our part” of the Internet by protecting the peers connected to our Route Servers by actively clean-filtering all routing information using RPKI: a security framework that verifies the right to use an IP address or ASN. By default NL-ix declines routes where RPKI-validation fails.

Signing your prefixes in the routing database of RIPE is the best way to start with RPKI as the RIPE database provides essential information to keep individual networks and the overall Internet running.

Please make sure that you cover all prefixes you use, matching the ASN which they originate from.  Also have all active ASNs and AS-SETs listed in your main AS-SET and remove unused ones. Please send an email to sales@nl-ix.net if you require changes your AS-SET.

You can check on the status of your AS in the routing databases.

Transit

Joint Transit

Joint Transit offers the best IP Transit option. We have created a unique blend from geographic Tier 1 and Tier 2 Transit specialists that guarantee the best routes to specific regions. Users can connect from around datacenters in most important European metropolitan markets in 7 countries, receiving more than 600.000 IPv4 prefixes.

Configuration Example

Below is an example on how to configure your Joint Transit service. This config snippet can also be used to configure your Open Peering product.

Cisco router - BGP

router bgp 65000
bgp router-id 1.1.1.1
bgp log-neighbor-changes
bgp graceful-restart
bgp maxas-limit 50
!
address-family ipv4
bgp dampening
redistribute static
exit-address-family
!
address-family ipv4 vrf internet
bgp dampening
redistribute static
neighbor 213.207.12.x1 remote-as 24785
neighbor 213.207.12.x1 description eBGP with Transit Nikhef
neighbor 213.207.12.x1 version 4
neighbor 213.207.12.x1 activate
neighbor 213.207.12.x1 remove-private-as
neighbor 213.207.12.x1 soft-reconfiguration inbound
neighbor 213.207.12.x1 route-map BGP-NLix-1-Ingress in
neighbor 213.207.12.x1 route-map BGP-NLix-1-Engress out
neighbor 213.207.12.x1 maximum-prefix 750000
neighbor 213.207.12.x2 remote-as 24785
neighbor 213.207.12.x2 description description eBGP with Transit Telecity2
neighbor 213.207.12.x2 version 4
neighbor 213.207.12.x2 activate
neighbor 213.207.12.x2 remove-private-as
neighbor 213.207.12.x2 soft-reconfiguration inbound
neighbor 213.207.12.x2 route-map BGP-NLix-2-Ingress in
neighbor 213.207.12.x2 route-map BGP-NLix-2-Engress out
neighbor 213.207.12.x2 maximum-prefix 750000
maximum-paths eibgp 4
exit-address-family
!

Please note that that Transit is always redundant. You can configure a session to both Nikhef and Telecity 2.

Cisco router - Prex Lists

ip prefix-list BGP-Engress-Out-Filter seq 1 permit 203.0.113.0/24 le 32
!
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 2 deny 0.0.0.0/0
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 4 deny 10.0.0.0/8 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 6 deny 172.16.0.0/12 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 8 deny 192.168.0.0/16 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 10 deny 224.0.0.0/4 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 12 deny 240.0.0.0/4 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 14 deny 127.0.0.0/8 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 16 deny 169.254.0.0/16 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 18 deny 192.0.2.0/24 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 20 deny 198.51.100.0/24 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 22 deny 203.0.113.0/24 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 24 deny 192.42.172.0/24 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 26 deny 198.18.0.0/15 le 32
ip prefix-list BGP-Ingress-In-Full-Routing-Table seq 99 permit 0.0.0.0/0 le 24
!
route-map BGP-NLix-1-Engress permit 10 match ip address prefix-list BGP-Engress-Out-
Filter
!
route-map BGP-NLix-2-Engress permit 10 match ip address prefix-list BGP-Engress-Out-
Filter set as-path prepend 206730
!
route-map BGP-NLix-1-Ingress permit 10 match ip address prefix-list BGP-Ingress-In-
Permit-Default-Route
set local-preference 100
!
route-map BGP-NLix-2-Ingress permit 10 match ip address prefix-list BGP-Ingress-In-
Permit-Default-Route

Please make sure to filter both inbound and outbound as shown above. This way you cannot inadvertently announce and receive prefixes you do not want. We recommend you filter bogon-prefixes from Team Cymru www.team-cymru.org.

BGP communities Joint Transit

NL-ix offers BGP communities to all customers using Joint Transit for AS24785 as a standard service feature. This gives control over how your prefixes are announced to your upstreams or provides information to act on.

More information on BGP Communities for Joint Transit

Cloud

Microsoft Azure ExpressRoute

In order to setup a working ExpressRoute, different resources need to be created in the Azure domain.

It is important that the ExpressRoute resource is created with the correct parameters. The resources Connection and (ExpressRoute) Gateway, are merely 'linking' resources and fall inside the customer domain.

An ExpressRoute can be created via the Azure Portal or via the command line (cloud shell). In both cases, there are three properties that need to be set correctly. In the Azure Portal, these properties are found under the step Configuration:

  • the Port Type needs to be set on Provider.
  • the Provider needs to be set to NL-IX - available for Europe West or Europe North
  • When choosing a provider, the next step is to pick the Peering Location:
    • For the region Europe West, this is Amsterdam2
    • For the region Europe North, this is Dublin2

NOTE: In case a different region-location combination is selected, it could be that the chosen location is used as a ramp-up; Microsoft in that case charges extra for sending the traffic over the Microsoft network to the correct region. For example, if the selected region is Europe North, but the Peering location is set to Amsterdam (which is a ramp-up for Europe West), the connection will be extended towards Europe North over the Microsoft network. This is an expensive option which is not recommended.

Google Cloud Platform Partner Interconnect

In order to get a Google Partner Interconnect working, several cloud resources are required within the Google domain, most importantly a Cloud Router connected to a VPC network.

With these resources in place, a create so-called VLAN Attachments can be created in the "Network Connectivity" → "Interconnect" menu. When doing this, the following things need to be taken into account:

  • Create a "Partner Interconnect connection" and state that you already have a service provider. You don't need to state that it is NL-ix.
  • Create a redundant pair of VLAN attachments (Technically, it is possible to create a single VLAN, please however make sure it is a redundant pair of VLAN).
  • Give the VLAN attachment a name
  • Set the MTU to 1500 - default, and also recommended by NL-ix
  • The customer does not set a Bandwidth, NL-ix does this!

After the creation of the VLAN attachment, a 'pairing-key' generated that needs to be shared with NL-ix in order to identify the ordered InterConnects.

Transport

MPLS Transport

VLL - Virtual Leased Line

Virtual Leased Line offers dedicated low-latency high-bandwidth capacity on Ethernet.

The Virtual Leased Line:

  • Allows unlimited MAC addresses, Q-in-Q, MAC-in-MAC, MPLS and jumbo frames.
  • Delivers a private circuit where traffic cannot be seen by other customers nor by NL-ix
  • Can be delivered on any distance. NL-ix hides the distance between endpoints and repeats the signal along the way if needed.

Virtual Leased Lines (VLL) can be delivered over tagged as well as untagged ports. When your VLL is delivered on a port with multiple services, it will be delivered tagged. When you want to configure your own VLAN’s through a tagged VLL, make sure your equipment supports QinQ.

VPLS - Virtual Private LAN Service

The Virtual Private LAN Service (VPLS) is an Ethernet-based point-to-multipoint Layer 2 Virtual Private Network (VPN) that enables to connect geographically dispersed Ethernet Local Area Network (LAN) sites to each other across an MPLS backbone. For customers who implement VPLS, all sites appear to be in the same Ethernet LAN even though traffic travels outside of your own network networks of Service Providers.

  • Connects multiple ports on one VLAN allowing communication between all ports on the VLAN.
  • Allows one MAC address per port, which is enforced using port security.
  • Supports standard seize Ethernet packets with 9000 bytes Ethernet packet payload. Therefore trunking, Q-in-Q, jumbo frames are not supported.
  • Can be delivered on any distance. NL-ix hides the distance between endpoints and repeats the signal along the way if needed.

MAC address filtering for VPLS

The VPLS service can be used with one MAC address. This MAC address will be configured in the ACL belonging to the customer port. It is not allowed to have multiple MAC addresses configured on the port. Traffic originating from other source MAC addresses is discarded.

Operations

When is start billing?

After the order confirmation has been send, the NL-ix provisioning team gets to work to deliver your order. When the order has been delivered, for normal products usually within 10 working days after the order confirmation, the provisioning team will send an ‘order delivery’ email. This email contains all details you need to setup your connection. The delivery date is aso the start date of invoicing.

How do I order the cross-connect?

Once your order is placed, NL-ix will forward you a CFA/LOA for you to order a cross-connect into the IX node present in your selected facility. You are responsible for arranging and paying for the cross-connect to reach the IX fabric.

Troubleshooting layer-1

If after connecting the port to port cross-connect cabling the lights above the port do not turn green, please try to switch the send and receive connector of your port to port cross-connect cabling. If the lights still doesn’t turn green please investigate the following possibilities:

  • Is Rx/Tx connected correctly - check if swapping Rx and Tx will solve the issue?
  • Is the port on the other side enabled and connected?
  • Is auto-negotiation configured on the other side?
  • Are there switches or transceivers in-between which are not configured yet?
  • Did you use the GBIC or SFP with the same port type as specified at port details?
  • Is the cable okay? Please have the datacenter check the cable and connectors.
  • Is the port speed configured as ordered?
  • Does the optic match the speed of the interface?

If the port still does not come up, please contact us, and we will check the port configuration on our side.

How to get your layer-2 interface up and running and start using the services?

When you have the cross-connect in place and you have received the 'order delivery' e-mail, your NL-ix connection is physically ready to be used.

Please note that once the port is up, you need to configure the port at your end. You will find all required information such as port setting, VLAN-ID and/or IP Config in the 'order delivery' email you have receive upon delivery.

How can I add/change the MAC address of my router and information on MAC access-list

We have layer-2 access-lists enabled on all of our interfaces for Peering, Transit and VLAN-connections. Only one MAC address is allowed per VLAN/service per port, so any intermediate switches should be made silent.

To prevent problems on our and your infrastructure all ports have port security / access lists and storm control enabled.

Customers who intend to swap Routers or otherwise change their MAC address should coordinate this change in advance by configuring the new MAC in the My NL-ix portal. You can add or change the allowed MAC-address of your router via the My NL-ix portal, via Ports > Manage MAC Address which will automatically also add/change it to the access-list.

In the event of an after-hours emergency necessitating our help on a MAC change, please call our NOC

Port settings & VLAN-tagging

Please set the gigabit port configuration to ’auto negotiate’, otherwise the connection might not come up at all or stay down after a reset. For fast ethernet ports, enable ’auto negotiate’ and disable all auto-crossover features.

The connection delivery mail states if you must tag your interface or not, this differs per NL-ix service.We use industry standard IEEE 802.1q VLAN trunking, please see your vendor manual for information on how to tag your frames.