Tier navigation Contact Us Main navigation Products Tech info News & Resources About us 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. 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 IXP Blackhole IPv4 Address Blackhole IPv6 Address Stockholm, BLUE, VLAN15 194.68.128.1 2001:7f8:d:fe::1 Stockholm, BLUE, VLAN16 195.69.119.1 2001:7f8:d:fb::1 Stockholm, GREEN, VLAN215 194.68.123.1 2001:7f8:d:ff::1 Stockholm, GREEN, VLAN216 195.245.240.1 2001:7f8:d:fc::1 Copenhagen, BLUE, VLAN410 212.237.192.1 2001:7f8:d:202::1 Copenhagen, GREEN, VLAN420 212.237.193.1 2001:7f8:d:203::1 Gothenburg, BLUE, VLAN315 194.68.130.1 2001:7f8:d:100::1 Gothenburg, BLUE, VLAN316 195.69.116.1 2001:7f8:d:101::1 Sundsvall, BLUE, VLAN515 194.68.133.1 2001:7f8:d:300::1 Sundsvall, BLUE,VLAN516 194.68.135.1 2001:7f8:d:301::1 Luleå, BLUE, VLAN610 194.68.131.125 2001:7f8:d:400::125 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 RS LAN VLAN IP MTU IPv4 IPv6 rs1 BLUE 15 1500 194.68.128.254 2001:7f8:d:fe::254 rs2 BLUE 16 4470 195.69.119.254 2001:7f8:d:fb::254 rs1 GREEN 215 1500 194.68.123.254 2001:7f8:d:ff::254 rs2 GREEN 216 4470 195.245.240.254 2001:7f8:d:fc::254 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 RS LAN VLAN IP MTU IPv4 IPv6 rs1 BLUE 410 9000 212.237.192.254 2001:7f8:d:202::254 rs1 GREEN 420 9000 212.237.193.254 2001:7f8:d:203::254 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 RS LAN VLAN IP MTU IPv4 IPv6 rs1 BLUE 315 1500 194.68.130.254 2001:7f8:d:100::254 rs2 BLUE 316 4470 195.69.116.254 2001:7f8:d:101::254 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 RS LAN VLAN IP MTU IPv4 IPv6 rs1 BLUE 515 1500 194.68.133.254 2001:7f8:d:300::254 rs2 BLUE 516 4470 194.68.135.254 2001:7f8:d:301::254 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 RS LAN VLAN IP MTU IPv4 IPv6 rs1 BLUE 610 9000 194.68.131.126 2001:7f8:d:400::126 Facebook Twitter LinkedIn Email TAGS IX IX Technical info Technical information on Netnod IXP's Learn more ABOUT NETNOD Peering with Netnod These are the basic facts and information about peering with Netnod. (ASN 8674). IX Netnod’s IXP Architecture Swedish national Internet exchange points are built on Ethernet technology. They are a layer 2 service with no routing facilities existing within the exchange points. The connected customer’s routers are responsible for the routing of packets through the exchange points. Netnod provides IX connections at sites in Stockholm, Copenhagen/Malmo, Gothenburg, Sundsvall/Gavle, Lulea and Oslo (powered by NIX). IX Router configuration examples 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 Point of Presence This is the list of colocation providers in Stockholm, Copenhagen, Malmo, Gothenburg, Sunsvall and Luleå. IX Dark fibre providers Transport network suppliers and fibre suppliers for connecting in Göteborg, Malmö and Sundsvall. IX IX FAQ Here we answer some of the most common questions about peering, IXPs and Netnod IX. Join the largest IXP in Northern Europe Learn more Social CONTACT Greta Garbos väg 13 169 40 Solna Sweden Phone: +46 (0)8 562 860 00 Registration number: 556534-0014 Registered office: Stockholm Contact page Contact form Press #netnod SUPPORT General: info[at]netnod.se Technical & network: noc@netnod.se Web: webmaster@netnod.se Fault report Peering with Netnod Route servers NTP servers ABOUT About Netnod Blog History Netnod Staff Netnod Board Work at Netnod Netnod DNS Data Retention and Web policies Sign up for Newsletter © Netnod 2021