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.
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/
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:
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.
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.
| 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 |
| Helsinki, BLUE, VLAN715 | 185.1.230.1 | 2001:7f8:122::1 |
| Helsinki, GREEN, VLAN716 | 185.1.230.129 | 2001:7f8:122:8000::129 |
| 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 |
Participants may tag routes sent to the route servers in to be able to control their traffic. Communities are indicated if they 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.
Netnod is currently supporting the following standard, extended and large BGP communities (RFC8092) on the route servers.
| Community | Description | Will be stripped |
|---|---|---|
| 0:52005 | Do not announce to ANY | Yes |
| 0:peer-as | Do not announce to PEER | Yes |
| 52005:peer-as | Announce to PEER | Yes |
| 65501:52005 | Prepend once to ANY | Yes |
| 65502:52005 | Prepend twice to ANY | Yes |
| 65503:52005 | Prepend thrice to ANY | Yes |
| 65511:peer-as | Prepend once to PEER | Yes |
| 65512:peer-as | Prepend twice to PEER | Yes |
| 65513:peer-as | Prepend thrice to PEER | Yes |
| 65281:peer-as | Add 'no-export' to PEER | No |
| 65282:peer-as | Add 'no-advertise' to PEER | No |
| 65535:0 | BGP Graceful Shutdown (RFC8326) | No |
| 65535:666 | BLACKHOLE community (RFC7999) | No |
| Community | Description | Will be stripped |
|---|---|---|
| rt:0:52005 | Do not announce to ANY | Yes |
| rt:0:peer-as | Do not announce to PEER | Yes |
| rt:rs_as:peer-as | Announce to PEER | Yes |
| rt:65501:52005 | Prepend once to ANY | Yes |
| rt:65502:52005 | Prepend twice to ANY | Yes |
| rt:65503:52005 | Prepend thrice to ANY | Yes |
| rt:65511:peer-as | Prepend once to PEER | Yes |
| rt:65512:peer-as | Prepend twice to PEER | Yes |
| rt:65513:peer-as | Prepend thrice to PEER | Yes |
| rt:65281:peer-as | Add 'no-export' to PEER | No |
| rt:65282:peer-as | Add 'no-advertise' to PEER | No |
| Community | Description | Will be stripped |
|---|---|---|
| 52005:0:0 | Do not announce to ANY | Yes |
| 52005:0:peer-as | Do not announce to PEER | Yes |
| 52005:1:peer-as | Announce to PEER | Yes |
| 52005:101:0 | Prepend once to ANY | Yes |
| 52005:102:0 | Prepend twice to ANY | Yes |
| 52005:103:0 | Prepend thrice to ANY | Yes |
| 52005:101:peer-as | Prepend once to PEER | Yes |
| 52005:102:peer-as | Prepend twice to PEER | Yes |
| 52005:103:peer-as | Prepend thrice to PEER | Yes |
| 52005:65281:peer-as | Add 'no-export' to PEER | No |
| 52005:65282:peer-as | Add 'no-advertise' to PEER | No |
*Communities noted with “Yes” in the tables above 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!
In order to start peering with the route servers you need to provide Netnod with the following data:
You also need to configure your BGP router to support the following, in order to have the session established successfully:
Below are some examples that show how a route server session would be configured on various platforms.
-----
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
!
-----router bgp YOUR-ASN
bgp enforce-first-as disable
neighbor Y.Y.Y.Y remote-as 52005
address-family ipv4 unicast
send-community-ebgp 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.
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 | 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 |
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 | 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 |
At Netnod Helsinki we operate one route server 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 VLAN715 (BLUE, MTU9000) will only receive routes from other participants peering over VLAN715 (BLUE MTU9000).
Peering details for Netnod Helsinki route servers
ASN: 52005
| RS | LAN | VLAN | MTU | IPv4 | IPv6 |
|---|---|---|---|---|---|
| rs1 | BLUE | 715 | 9000 | 185.1.230.126 | 2001:7f8:122::126 |
| rs2 | GREEN | 716 | 9000 | 185.1.230.254 | 2001:7f8:122:8000::254 |
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 | 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 |
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 | 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 |
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 | MTU | IPv4 | IPv6 |
|---|---|---|---|---|---|
| rs1 | BLUE | 610 | 9000 | 194.68.131.126 | 2001:7f8:d:400::126 |