Route servers

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.

Blackholing

Netnod supports the global BLACKHOLE community (RFC7999) on all of its route servers. Blackholing is commonly used to mitigate DDoS attacks which originate from other customers within the IXP fabric, leading to congestion on the customer facing port.

By appending the BLACKHOLE community (65535:666) for a prefix which is being announced towards the Netnod Route Servers, Netnod will perform a re-write of the next-hop to a specific address within the Peering LAN which acts as a soaking address. The address is being propagated throughout each Peering LAN with a unique MAC address. On all the customer facing ports, we then apply a MAC filter which implicitly deny this unique MAC address. This results in that the attack will not propagate further than the ingress port on the IX fabric.

The Netnod Route Servers only accept prefixes longer than /24 IPv4 and /48 IPv6 with the BLACKHOLING community.

See below for a table for each IPv4 and IPv6 Blackhole IP addresses
 

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)
65535:666 - BLACKHOLE community (RFC7999)

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). We are operating BIRD as a routing daemon for all of our route servers. 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

Netnod Copenhagen

At Netnod Copenhagen we operate one route servers per Peering LAN (BLUE and GREEN). We are operating BIRD as a routing daemon for all of our route servers. Both 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

Netnod Gothenburg

At Netnod Gothenburg we operate two route servers (BLUE Peering LAN only). We are operating BIRD as a routing daemon for all of our route servers. Both 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 VLAN315 (BLUE, MTU1500) will only receive routes from other participants peering over VLAN315 (BLUE MTU1500).

Peering details for Netnod Gothenburg route servers
ASN: 52005

Netnod Sundsvall

At Netnod Sundsvall we operate two route servers (BLUE Peering LAN only). We are operating BIRD as a routing daemon for all of our route servers. Both 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 VLAN515 (BLUE, MTU1500) will only receive routes from other participants peering over VLAN515 (BLUE MTU1500).

Peering details for Netnod Sundsvall route servers
ASN: 52005

Netnod Luleå

At Netnod Luleå we operate one route server (BLUE Peering LAN only). We are operating BIRD as a routing daemon for the route server.

Peering details for Netnod Luleå route servers
ASN: 52005