GLV-IX Route Servers

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.

Zakusala Talejas Valmiera Daugavpils Ventspils Liepaja

Sate Operational Operational Planned Planned Planned Planned
ASN 47352 47352 47352 47352 47352 47352
IPv6 2001:7f8:126::1 2001:7f8:126::2 2001:7f8:126::3 2001:7f8:126::4 2001:7f8:126::5 2001:7f8:126::6

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

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.

Community Usage

Advertisement control
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 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.