The route servers offer multi-lateral peering between the members of GLV-IX and speed up the peering process for new members.
The route servers act as BGP proxies, eliminating the need for direct peerings among the members. The route servers forward BGP announcements among the members according to rules set by the members themselves, without altering the BGP next-hop or the AS-PATH. As a result, the route servers participate in the BGP control plane without participating into the data plane of the exchanged traffic.
The use of route servers is mandatory for GLV-IX members. The route servers support MD5 passwords and usage is encouraged.
Peering with all route servers ir recommended. For members with multiple routers connected to GLV-IX, it is recommended that each of these routers connect to all route servers, and that each of those routers implement the same policy for all of those peerings. Members are not discouraged from setting up direct bgp peerings with other key members, in addition to peering with them through the route servers.
In some BGP implementations, the BGP process will discard by default any prefixes received from eBGP peers if the peer’s autonomous system (AS) number does not appear as first in the AS_PATH. This is always the case when peering with a route server, as the route server is configured to “hide” its AS number. Hence, when peering with the route servers, this check must be disabled.
Example on Cisco devices:
no bgp enforce-first-as router bgp 47352 neighbor < rs_ip > send-community both
BGP communities can be used to control where the members prefix is advertised. By default, the route server will advertise each prefix to all connected members.
|Standard communities (16-bit AS only)|
|0:PeerAS||Do not advertise to PeerAS|
|47352:PeerAS||Announce to specific PeerAS|
|0:47352||Do not announce to all peers|
|47352:47352||Announce to all peers (implicit behavior)|
|47352:666||Blackholing (next_hop changes to *66)|
|Large communities (16/32-bit AS)|
|47352:0:PeerAS||Do not advertise to PeerAS|
|47352:1:PeerAS||Announce to specific PeerAS|
|47352:0:0||Do not announce to all peers|
|47352:1:0||Announce to all peers (implicit behavior)|
|47352:101:PeerAS||Prepend once to PeerAS|
|47352:102:PeerAS||Prepend twice to PeerAS|
|47352:103:PeerAS||Prepend thrice to PeerAS|
|Marking (performend by the route servers)|
|47352:1900:1||Prefix received by peering in Zakusala PoP|
|47352:1900:2||Prefix received by peering in Talejas PoP|
|47352:1900:3||Prefix received by peering in Valmiera PoP|
|47352:1900:4||Prefix received by peering in Daugavpils PoP|
|47352:1900:5||Prefix received by peering in Ventspils PoP|
|47352:1900:6||Prefix received by peering in Liepaja PoP|
To blackhole a prefix member has to announce prefix with community 47352:666. This will change the next-hop of route to 22.214.171.124 or 2001:7f8:126::66. Traffic destined to those IPs will be filtered on ingress.
Received prefix processing
The route server will filter prefixes:
- Prefixes with next-hop different than the peers IP(v4/v6) address
- Martians and other unexpected routes
- RPKI INVALID status
- with the last AS in the AS-PATH not included in the member’s AS-SET
- without a corresponding route object of same length that originates from an AS in the member’s AS-SET
- Drop small prefixes – longer than /24 for IPv4 and longer than /48 for IPv6
- Ensure there is at least 1 ASN and less than 64 ASNs in the AS path
- Ensure the peer ASN is the same as the first ASN in the AS path
- Drop any prefix with a well-known transit network ASN in the AS path
The route servers will change MED to optimize routing (i.e, between two same prefixes of the same AS, the closer (in terms of switching hops) will be selected).
The route server configuration is updated on an hourly basis, to reflect changes in IRRDBs and member portal.