Route servers

Netnod operates route servers at the Stockholm IX as well as the Copenhagen exchange point (Copenhagen-Malmö). A route server facilitates the administration of peering arrangements for networks present at an exchange point. By connecting to the route server, you can replace some or all of your separate BGP sessions to your peers, with one single session towards the route server.

Not only does a route server make it easier for networks to manage their peering arrangements, but it also makes it easier for new peers to start exchanging traffic at the exchange point, from day one.

Route servers in Stockholm and Copenhagen

In Stockholm there are two separate route machines servers in Stockholm - with one at each switch. Each route server is comprised of four logical internal routing exchange matrices - two VLANs times two network protocols (IPv4 and IPv6). On each peering IP address below, you will only see prefixes that result from other peering sessions on the same VLAN.

Peering coordinates for the Stockholm IX route servers 

ASN: 52005 (all instances)

vlan215 (MTU 1500):

      IPv6: 2001:7f8:d:ff::254

vlan216 (MTU 4470):

      IPv6: 2001:7f8:d:fc::254

vlan15 (MTU 1500):

      IPv6: 2001:7f8:d:fe::254

vlan16 (MTU 4470):

      IPv6: 2001:7f8:d:fb::254

Peering coordinates for the Copenhagen route server

ASN: 52005 

vlan415 (MTU 1500):

       IPv6: 2001:7f8:d:200::254

vlan416 (MTU 4470):

       IPv6: 2001:7f8:d:201::254

You may tag routes sent to the route servers with BGP communities as follows:

0:peer-as      Block announcement of prefix to AS peer-as
0:52005        Block announcement of prefix to all 
52005:peer-as  Announce prefix to AS peer-as 
(when using block community)

If none of the above block-communities is specified the prefix will be announced to ALL participants.

These specific communities will be stripped when the route is announced to other peering parties. All other communities (including the well-known communities, such as NO_EXPORT) will be retained and forwarded to other peering parties. Routes without any of the communities listed above will be announced to all participants by the route server.

Please remember to set your peering session to:

a) Not enforce that the first ASN in the AS path matches the peering ASN.

b) Enable that communities are sent across the peering session.

On Cisco IOS/Brocade/Zebra/Quagga systems this is done using the following BGP commands

      router bgp (XXXX)
      no bgp enforce-first-as
      neigbor Y.Y.Y.Y send-communities

On Cisco IOS-XR you need something along the lines of ...

      router bgp XXXXXX
        neighbor Y.Y.Y.Y
          address-family ipv4 unicast

We do support MD5 passwords, but you have to use the same password on all RS peering sessions.

We also require that you peer from the same ASN for all of your route server peering sessions.

Technical information on Netnod IXP's

About Netnod
These are the basic facts and information about peering with Netnod. (ASN 8674).

Here are example configurations that illustrates a router connected to both of the VLANs on the STH-B switch. The VLAN ids will be different for other Netnod IX's. The examples are only examples and will most likely need to be adopted to your environment and platform.

This is the list of colocation providers in Stockholm, Copenhagen, Malmo and Gothenburg.

Transport network suppliers and fibre suppliers for connecting in Göteborg, Malmö and Sundsvall.

Here we answer some of the most common questions about peering, IXPs and Netnod IX.
Join the largest IXP in Northern Europe