Route servers

Route servers make it easy for networks to manage their peering arrangements and for new peers to start exchanging traffic at an IX from day one.

Netnod currently operates route servers at Netnod Stockholm and Netnod Copenhagen. A route server facilitates the administration of peering arrangements for networks present at an IX. 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.

This page gives detailed information about how to connect to the route servers including the data you need to provide, how to configure your BGP router and how to set up your route server sessions as well as information about BGP communities and filtering.

Looking Glass

Netnod has implemented a looking glass, powered by Alice-LG, for route server participants. The looking glass is a tool provided for customers to get a clear view on the routing between peers.

We intend to actively support and contribute to the Alice-LG project. Many thanks to Matthias Hanning among the others who have contributed and developed Alice-LG!

The looking glass is available at: https://lg.netnod.se/

Filtering

Since April 2017, Netnod has been using IRR data from route server participants in order to build filters for all incoming BGP announcements from peers. This means that the route server will reject all prefixes that are not a member of the AS-SET the participant has provided at the time of configuration. We also implement AS-PATH filters for each peer as well.

We also make the following filtering checks from each peer on the route servers:

 

  • Private and reserved prefixes are being filtered. (RFC1918, RFC5735)
  • AS-PATH filtering, ensuring that the last AS in path is the configured ASN
  • RPKI filtering - we are dropping all prefixes which have an invalid Route Origin Authorisation (ROA). Unknowns are checked against the IRR filter of the customers.

Even though we are applying filters on your route server sessions, we highly recommend that each participant perform filtering on their side as well. If not on ingress, filters should always be applied on egress, containing the intended prefixes that should be announced to the route server/other participants.

BGP Communities

Participants may tag routes sent to the route servers in to be able to control their traffic. Netnod is currently supporting the following standard, extended and large BGP communities (RFC8092) on the route servers:

Standard communities:

 

0:52005 - Do not announce to ANY

0:peer-as - Do not announce to PEER

52005:peer-as - Announce to PEER

65501:52005 - Prepend once to ANY

65502:52005 - Prepend twice to ANY

65503:52005 - Prepend thrice to ANY

65511:peer-as - Prepend once to PEER

65512:peer-as - Prepend twice to PEER

65513:peer-as - Prepend thrice to PEER

65281:peer-as - Add 'no-export' to PEER

65282:peer-as - Add 'no-advertise' to PEER

65535:0 - BGP Graceful Shutdown (RFC8326)
 

Extended communities:

rt:0:52005 - Do not announce to ANY

rt:0:peer-as - Do not announce to PEER

rt:rs_as:peer-as - Announce to PEER

rt:65501:52005 - Prepend once to ANY

rt:65502:52005 - Prepend twice to ANY

rt:65503:52005 - Prepend thrice to ANY

rt:65511:peer-as - Prepend once to PEER

rt:65512:peer-as - Prepend twice to PEER

rt:65513:peer-as - Prepend thrice to PEER

rt:65281:peer-as - Add 'no-export' to PEER

rt:65282:peer-as - Add 'no-advertise' to PEER

 

Large communities:

52005:0:0 - Do not announce to ANY

52005:0:peer-as - Do not announce to PEER

52005:1:peer-as - Announce to PEER

52005:101:0 - Prepend once to ANY

52005:102:0 - Prepend twice to ANY

52005:103:0 - Prepend thrice to ANY

52005:101:peer-as - Prepend once to PEER

52005:102:peer-as - Prepend twice to PEER

52005:103:peer-as - Prepend thrice to PEER

52005:65281:peer-as - Add 'no-export' to PEER

52005:65282:peer-as - Add 'no-advertise' to PEER

Communities highlighted in bold will be stripped when the prefix is being announced to other participants. All other communities will be retained and forwarded to the other peering participants. Routes without any of the communities listed above will be announced to all participants by the route server.

We are continuously investigating communities features that support our participants in performing traffic engineering. If you have suggestions, please let us know!

 

General configuration

In order to start peering with the route servers you need to provide Netnod with the following data:

  • IPv4 + IPv6 addresses of the Netnod Peering LAN

  • AS number

  • A valid IRR record containing the prefixes and AS-PATH that you intend to announce

  • Technical contact and/or NOC contact information

 

You also need to configure your BGP router to support the following, in order to have the session established successfully:

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

  • Enable that communities are sent across the peering session.

Below are some examples that show how a route server session would be configured on various platforms.

Cisco IOS/Brocade/Arista:

-----
router bgp YOUR-ASN
  no bgp enforce-first-as
  neighbor NETNOD-RS
  neighbor NETNOD-RS peer-group
  neighbor NETNOD-RS send-community
  neighbor NETNOD-RS route-map ANNOUNCE-TO-NETNOD-RS out
  neighbor Y.Y.Y.Y peer-group NETNOD-RS
  neighbor Y.Y.Y.Y remote-as 52005
    neighbor Y.Y.Y.Y description NETNOD-RS
!
route-map ANNOUNCE-TO-NETNOD-RS permit 1
  match ip address prefix-list ANNOUNCE-TO-NETNOD-RS
!
ip prefix-list ANNOUNCE-TO-NETNOD-RS
  seq 10 permit 10.10.10.0/24
!
-----

Cisco IOS-XR:   

router bgp YOUR-ASN
       bgp enforce-first-as disable
       neighbor Y.Y.Y.Y remote-as 52005
       address-family ipv4 unicast
             send-community-ebgp

Juniper JunOS:

group NETNOD-RS {
  type external;
  description "NETNOD-RS";
  family inet {
    unicast;
  }
  export ANNOUNCE-TO-NETNOD-RS;
  peer-as 52005;          
  neighbor Y.Y.Y.Y {
  description NETNOD-RS1-IPV4;
  }        
}
policy-options {
  policy-statement ANNOUNCE-TO-NETNOD-RS {
    term EXPORT {
      from {
        rib inet.0
        prefix-list ANNOUNCE-TO-NETNOD-RS
      }
      then accept;
    }
    term REJECT-ALL {
      then reject;
    }
}
prefix-list ANNOUNCE-TO-NETNOD-RS {
  10.10.10.0/24;
    }
} 

Q: Do you support MD5 passwords?

A: Yes. However, you need to use the same password on all route server sessions.

 

Q: Can I peer with a different ASN across the different route servers?

A: No. We require that you peer from the same ASN for all of your route server sessions.

 

Netnod Stockholm

At Netnod Stockholm we operate two route servers per Peering LAN (BLUE and GREEN). To achieve software redundancy, we have deployed BIRD as the routing daemon on the BLUE Peering LAN and GoBGP on the GREEN Peering LAN. All route servers are fully feature compatible between each other.

Participants will only receive prefixes for the corresponding VLAN they are peering over. For example, sessions with the route server at VLAN215 (GREEN, MTU1500) will only receive routes from other participants peering over VLAN215 (GREEN, MTU1500).

Peering details for Netnod Stockholm route servers

ASN: 52005 (all instances)

BLUE (rs1b):

VLAN15 (MTU 1500):

  IPv4: 194.68.128.254/24

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

BGP daemon: BIRD

BLUE (rs2b):

VLAN16 (MTU 4470):

  IPv4: 195.69.119.254/24

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

BGP daemon: BIRD

GREEN (rs1g):

VLAN215 (MTU 1500):

  IPv4: 194.68.123.254/24

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

BGP daemon: GoBGP

GREEN (rs2g):

VLAN216 (MTU 4470):

  IPv4: 195.245.240.254/24

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

BGP daemon: GoBGP
 

Netnod Copenhagen

At Netnod Copenhagen, we operate one route server per Peering LAN (BLUE and GREEN). To achieve software redundancy, we have deployed BIRD as the routing daemon on the BLUE Peering LAN and GoBGP on the GREEN Peering LAN. All route servers are fully feature compatible between each other.

Participants will only receive prefixes for the corresponding VLAN they are peering over. For example, sessions with the route server at VLAN410 (BLUE, MTU9000) will only receive routes from other participants peering over VLAN410 (BLUE, MTU9000).

Peering details for Netnod Copenhagen route servers

ASN: 52005

BLUE (rs1b):

VLAN410 (MTU 9000):

   IPv4: 212.237.192.254/24

   IPv6: 2001:7f8:d:202::254/64

BGP daemon: BIRD

 

GREEN (rs1g):

VLAN420 (MTU 9000):

   IPv4: 212.237.193.254/24

   IPv6: 2001:7f8:d:203::254/64

BGP daemon: GoBGP

Share
Technical information on Netnod IXP's

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

IX
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.

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

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

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