Route servers
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