Route servers

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)

STH-A
vlan215 (MTU 1500):

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

vlan216 (MTU 4470):

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

STH-B
vlan15 (MTU 1500):

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

vlan16 (MTU 4470):

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

Peering coordinates for the Copenhagen route server

ASN: 52005 

Comix
vlan415 (MTU 1500):

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

vlan416 (MTU 4470):

       IPv4: 195.69.118.254
       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 
participants
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
          enforce-first-as-disable
          address-family ipv4 unicast
            send-community-ebgp

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.