HelpDesk: +370 5 274 5444

BALT-IX Route Servers

The Route Servers (RS) are used to simplify peering between BALT-IX participants and excludes the need to have a multiple BGP session with each other IX member. RS retransmits BGP announcements between the connected participants, thus peering with the RS means establishing peering relations with all other participants connected to that RS.

Once the BGP session is established, IP traffic will be exchanged transparently between pairs of neighbours on the peering LAN: the route-server IP address will never be shown as a next-hop address, nor the route-server ASN will appear in the as-path. Because no data is passing through the RS, therefore RS doesn't influence cross-network delays.

Note: RS doesn't insert its own ASN into the AS_PATH by default some routers might deny such updates, to solve this behaviour you should specify "no bgp enforce-first-as" (IOS/IOS-XE) or "bgp enforce-first-as disable" (IOS-XR).

Route Server Configuration Info

In BALT-IX the service is offered by means of two route-servers on the peering LAN. All the members should configure two peering sessions, in order to take advantage of the redundancy in case of an issue or maintenance. All RS are configured for both IPv4 and IPv6 peering.

Primary RS1-L160C: or 2001:1ab8:8486::1/64
Secondary RS2-J13: or 2001:1ab8:8486::254/64
ASN: AS8486

RS is processing the BGP routes on the following rules:
 RS does not accept default route
 RS does not accept private AS
 RS does not accept Martian’s prefixes (BOGONS VIA HTTP)
 RS accepts the route if it has corresponding "route/route6" object that exists in IRR DB. Each member has its own list of prefixes that are considered valid for the BGP announcements, this list is obtained by querying IRR DB using ASN off the member or a given as-set.

Filters are updating automatically every night at 04:00.

Maximum number of announced prefixes

For those members who have a max-prefix limit configured on the peering sessions with the route-servers, these are the recommended minimum thresholds:
 >60k prefixes for IPv4 peering
 >30k prefixes for IPv6 peering

BGP Community Attributes

Each of route-server does not modify, process or remove communities received from customers except those communities which are processed by the route-servers themselves.

Communities affecting announces to other peers:

0:8486 - Do not announce prefix to all peers
0:X - Do not announce prefix to peer ASX
8486:8486 - Announce prefix to all peers
8486:X - Announce prefix to peer ASX only


If peer's AS is 32-bit then BGP extended community attribute should be used:

rt:0:X - Do not announce prefix to peer ASX
rt:8684:X - Announce prefix to peer ASX only


Well-known communities like no-export or no-advertise are also supported. If no communities are set, then received prefixes are advertised to all peers by default.

Following communities are also applied by RS:

[65000 + <R>]:[10000 + 1000 * <X> + <CC>] ~ Where (based on RFC4384):

is the 5-bit Region Identifier
<X> is the 1-bit satellite link indication
X = 1 for satellite links, 0 otherwise
<CC> is the 10-bit ISO-3166-1 country code [ISO3166]
and <R> takes the values:
Africa (AF) 00001 (1)
Oceania (OC) 00010 (2)
Asia (AS) 00011 (3)
Antarctica (AQ) 00100 (4)
Europe (EU) 00101 (5)
Latin America/Caribbean Islands (LAC) 00110 (6)
North America (NA) 00111 (7)


65000:10000 - Tier1 and Tier2 ISPs
65005:10233 - Estonia
65005:10428 - Latvia
65005:10440 - Lithuania

Note: Communities are set to all prefixes received from BGP peer, based on peer AS country code:
whois -h " -v PeerAS"
With some exceptions like Tier1 and Tier2 ISPs, and some others.