Route Server

About RS

The Route Server (RS) is a network service that simplifies peering between MSK-IX participants and allows them to reduce the number of individually administered peering sessions. The RS retransmits BGP announcements between the connected participants, thus peering with the RS means establishing peering relations with all the other MSK-IX participants connected to the RS.

Route Server service doesn't influence cross-network delays as the traffic between interfaces of participants is transferred directly.

Available on the common peering VLAN, the RS operates over IPv4 and IPv6 and supports 16bit and 32bit AS numbers.

RS configuration info

City Route Server AS AS-SET IP-addresses of BGP-speakers* Configuration update schedule**
(local time)
15:30-16:30 (local time)
daily except Sat. and Sun.
11:30-12:30 (local time)
daily except Sat. and Sun.
St.-Petersburg 43690 AS-SPBROUTESERVER
17:00-18:00 (local time)
daily except Sat. and Sun.
13:00-14:00 (local time)
daily except Sat. and Sun.
Rostov-on-Don 48216 AS-RNDROUTESERVER
17:00-18:00 (local time)
daily except Sat. and Sun.
12:30-13:30 (local time)
daily except Sat. and Sun.
17:00-18:00 (local time)
daily except Sat. and Sun.
17:00-18:00 (local time)
daily except Sat. and Sun.
12:30-13:30 (local time)
daily except Sat. and Sun.
17:00-18:00 (local time)
daily except Sat. and Sun.
Ekaterinburg 43213 AS-EKTROUTESERVER
17:00-18:00 (local time)
daily except Sat. and Sun.
12:30-13:30 (local time)
daily except Sat. and Sun.
Novosibirsk 42403 AS-NSKROUTESERVER
17:00-18:00 (local time)
daily except Sat. and Sun.
12:30-13:30 (local time)
daily except Sat. and Sun.
Vladivostok 48531 AS-VLVROUTESERVER
17:00-18:00 (local time)
daily except Sat. and Sun.
12:30-13:30 (local time)
daily except Sat. and Sun.
Riga n/a


* In cities with two addresses of BGP-speakers the RS hardware consists of two redundant servers located at different locations.

** Configuration updates include checks and updates of information in the IRR, updates or the routing policy filters, application of changes to the configuration of the RS. The procedure takes from several minutes to one hour.

How to start using RS?

All participants using the RS must comply with the Technological Requirements.

To start using the RS, a participant must perform the following steps to establish a BGP peering session with Route Server autonomous system (see configuration table upper):

  1. Add peering with Route Server AS to the routing policy description of your AS. The routing policy description must be maintained in RIPE, ARIN, or RADB Internet Routing Registry (IRR).
  2. Send application from authorized contact address to containing the ID of the organization, the AS number and the IP address of the border router (IPv4 and/or IPv6).
  3. Configure BGP-sessions with both instances of the RS.
  4. Disable first-as check in your BGP configuration by issuing no bgp enforce-first-as command (or it's counterparts for your vendor).

Information about MSK-IX participants peering with the RS may be retrieved at Customer Portal MSK-IX.

Information about RS routing policy may be retrieved from the RIPE database (see or whois -h as[Route Server AS]).

Use the RS Looking Glass to view and debug BGP announcements to the RS.

RS routing policy

The RS exchanges the routing information with connected participants via BGP4 protocol as described in RFC4271. By default, the RS announces the best of all routes received from its peers. The Next-Hop attribute contains the IP-address of the host from RS received the announcement. The AS_PATH attribute is passed unchanged. Thus, the traffic is exchanged between RS peers directly.

RS is processing the BGP routes on the following rules:

  1. RS does not accept routes of private networks, default route and networks with special purpose (RFC6890).
  2. RS does not accept routes of private AS and AS with special purpose (RFC5398, RFC6996, RFC7300, RFC7607).
  3. RS does not accept routes for networks where the value "origin" of the object "route/route6" in the database IRR does not match with the starting AS number in the AS_PATH attribute.
  4. RS does not accept routes for networks for which the number of the last added AS in the AS_PATH attribute does not match the AS number of the participant established BGP session.
  5. RS performs RPKI check (RFC6480) for the given route and mark result with special BGP community.

    1. Routes with RPKI_VALID status are accepted if "origin" AS number contains within AS-SET of this BGP peer policy (see paragraph 6).
    2. Routes with RPKI_INVALID status are rejected.
    3. Routes with RPKI_UNKNOWN status are processed according rules below.
  6. RS accepts the route if it has corresponding "route/route6" object that exists in IRR DB. This route object's AS number (or AS-SET) must be described in BGP peer "aut-num" object export/mp-export policy for route server AS number. The route and IRR DB route object sizes must be equal except paragraph 7.
  7. RS accepts routes if they has corresponding aggregate route (route with smaller netmask) in IRR DB. These accepted routes are marked with BGP community (RSAS:65500). The aggregate route meets same requirements as in 6 paragraph.

BGP community attributes

RSAS means Route Server AS number in your city.

Route Server supports two groups of BGP community attributes: basic and extra. Basic communities are applied in the table order. The processing priority of BGP Community: Large > Standard.


Action BGP Standard Community (RFC1997) BGP Large Community (RFC8092)
Block announcement of prefix to AS [peer-as] 0:peer-as RSAS:0:peer-as
Announce prefix to AS [peer-as] RSAS:peer-as RSAS:1:peer-as
Block announcement of prefix to all participants 0:RSAS RSAS:0:0
Announce prefix to all participants RSAS:RSAS RSAS:1:0
Blackhole community (blocking of incoming traffic) 65535:666 --
Prepend once when announcing this prefix to AS [peer-as] 1:peer-as RSAS:101:peer-as
Prepend twice when announcing this prefix to AS [peer-as] 2:peer-as RSAS:102:peer-as
Prepend three times when announcing this prefix to AS [peer-as] 3:peer-as RSAS:103:peer-as
Geolocation specific BGP community to identify the city of interconnection
(inserted automatically at RS side)
11:City RSAS:1911:City


Action BGP Standard Community (RFC1997)
Aggregate for this prefix exists in IRR DB5 RSAS:65500
Announce prefix with no-export attribute RSAS:65281
RPKI_VALID (inserted automatically at RS side) RSAS:65510
RPKI_UNKNOWN (inserted automatically at RS side) RSAS:65511
RPKI_INVALID (inserted automatically at RS side) RSAS:65512
Set local-preference 0 RSAS:0
Set local-preference 50 RSAS:50
Set local-preference 100 RSAS:100

  1. In case of either no BGP community attribute is set or its format does not fit to the requirements above, prefix is accepted and announced throughout all participants.
  2. The Looking Glass displays prefixes announced to the RS and basic BGP communities. For extra BGP communities, only the result of their application is shown.
  3. When announcing via RS, all MSK-IX control communities are cleared, all the other community attributes are passed transparently.
  4. By default all announcements are assigned with local-preference 100.
  5. BGP community RSAS:65500 is used to mark prefixes which have aggregate route/route6 object (route with lower CIDR) and do not have corresponding route/route6 objects in IRR DB.
    • IPv4: The BGP community is used for prefixes less or equal than /24 CIDR. Prefixes with CIDR from /25 to /32 are not marked and these prefixes are allowed if corresponding route objects exist in IRR DB.
    • IPv6: The BGP community is used for prefixes less or equal than /48 CIDR. Prefixes with CIDR from /49 to /128 are not marked and these prefixes are allowed if corresponding route6 objects exist in IRR DB.
  6. Prefixes with set no-export attribute (65535:65281) are announced to all participants w/o modification.

Control BGP Standard Community for 32-bit AS numbers

Skip this section in case of control BGP Large Communities.

To use BGP communities with 32-bit AS numbers, set peer-as values as listed in the following table:

Member AS number Community City
Oriental Power Holdings LTD 132203 64791 Moscow
Huawei Technologies Co. Ltd. 136907 64814 Moscow
DE-CIX Academy 196610 64813 Moscow
NetOne Rus 196695 64712 Moscow
CJSC «GNC-ALFA» 196709 64742 Moscow
ISP WEBA Networks 196750 64771 Moscow
Volkhov-Online Ltd. 196879 64737 Moscow
Azertelecom LLC 196925 64765 Moscow
JSC «R-Pharm» 197062 64711 Moscow
TeleMaks 197204 64761 Moscow
SkyNet LTD 197826 64709 Moscow
SPB TV Telecom LLC 197888 64722 Moscow
Federal State Unitary Enterprise «Morsziazsputnik» 197969 64875 Moscow
LLC «United Networks» 198539 64885 Moscow
LTD BeGet 198610 64751 Moscow
StreamLogic corp 199168 64776 Moscow
City Connect LLC 199361 64731 Moscow
Gcore Rus Ltd 199524 64769 Moscow
Setevye technologii LLC 199572 64741 Moscow
Limited Liability Company «Telecom-Birja» 199599 64734 Moscow
LLC «RelCom» 199624 64758 Moscow
199634 64834 Moscow
LLC «Okey-Telecom» 199669 64787 Moscow
«IP Telecom Bulgaria» LTD 199790 64891 Moscow
Stack Groupp 200044 64824 Moscow
DATAPRO 200161 64767 Moscow
LLC «MICROIMPULS» 200172 64725 Moscow
Yandex.Cloud LLC 200350 64815 Moscow
OOO Hosting Vashego Uspeha 200487 64756 Moscow
LIFESTREAM LTD 200976 64783 Moscow
Icewood LLC 201119 64860 Moscow
Tvoy Telecom, LLC 201211 64848 Moscow
LLC «Servicepipe» 201706 64847 Moscow
Miranda-Media LIMITED 201776 64821 Moscow
LLC «Rosfon» 201825 64879 Moscow
COMUTO SA 202069 64777 Moscow
«MaximaTelecom» JSC 202173 64743 Moscow
Sky Telecom 202486 64838 Moscow
Intercom 202838 64867 Moscow
Cloud Solutions LLC 202933 64856 Moscow
IE Slepyshkov Maksim Aleksandrovich 203674 64759 Moscow
Global Web Group 203703 64794 Moscow
Fiber Telecom LTD 203784 64816 Moscow
LLC Aiticon 203968 64857 Moscow
ShowJet LLC 204271 64880 Moscow
«Technical Center of Internet» Limited Liability Company 204582 64831 Moscow
Company Buster 204600 64789 Moscow
CDNetworks 204720 64830 Moscow
JSC «MSK-IX» 205022 64810 Moscow
Cortel Limited liability company 205063 64801 Moscow
LLC MEGOGO 205216 64781 Moscow
DE-CIX R&D 205530 64828 Moscow
206295 64825 Moscow
LLC Fastcom 206846 64868 Moscow
RUCOMTECH LLC 207133 64785 Moscow
Limited Liability Company Floral alliance 207561 64851 Moscow
HOSTLINE, UAB 207785 64846 Moscow
FGBU Center MIR IT 208075 64833 Moscow
Mossvyaz 208912 64827 Moscow
AO «Kaspersky Lab» 209030 64822 Moscow
«China Mobile International (Russia)» LLC 209141 64843 Moscow
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala» 209307 64819 Moscow
Tricolor LTD 209739 64837 Moscow
Okko 211609 64888 Moscow
212487 64873 Moscow
PowerHost Telecom SPA 263237 64852 Moscow
TikTok Pte. Ltd. 396986 64882 Moscow
PowerHost LLC 398131 64836 Moscow
ISP WEBA Networks 196750 64763 St.-Petersburg
Volkhov-Online Ltd. 196879 64735 St.-Petersburg
SPB TV Telecom LLC 197888 64739 St.-Petersburg
LTD BeGet 198610 64750 St.-Petersburg
RetnNet 198947 64805 St.-Petersburg
Gcore Rus Ltd 199524 64782 St.-Petersburg
LLC «Okey-Telecom» 199669 64788 St.-Petersburg
OOO Hosting Vashego Uspeha 200487 64755 St.-Petersburg
Icewood LLC 201119 64861 St.-Petersburg
LLC «Concept» 201469 64874 St.-Petersburg
IE Slepyshkov Maksim Aleksandrovich 203674 64760 St.-Petersburg
Global Web Group 203703 64793 St.-Petersburg
SERVERMALL LLC 204576 64876 St.-Petersburg
Company Buster 204600 64790 St.-Petersburg
Cortel Limited liability company 205063 64800 St.-Petersburg
206295 64826 St.-Petersburg
HOSTLINE, UAB 207785 64877 St.-Petersburg
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala» 209307 64818 St.-Petersburg
JSC TELECOMMUNICATION 209343 64844 St.-Petersburg
Okko 211609 64887 St.-Petersburg
Gcore Rus Ltd 199524 64835 Rostov-on-Don
CDNetworks 204720 64866 Rostov-on-Don
Gcore Rus Ltd 199524 64869 Samara
CDNetworks 204720 64829 Samara
Okko 211609 64889 Samara
Gcore Rus Ltd 199524 64870 Kazan
JSC «MSK-IX» 205022 64839 Kazan
Gcore Rus Ltd 199524 64786 Ekaterinburg
Icewood LLC 201119 64865 Ekaterinburg
State budgetary institution «Operator of the electronic government of the Sverdlovsk region» 201634 64883 Ekaterinburg
Fiber Telecom LTD 203784 64863 Ekaterinburg
Cortel Limited liability company 205063 64802 Ekaterinburg
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala» 209307 64817 Ekaterinburg
Gcore Rus Ltd 199524 64853 Novosibirsk
Icewood LLC 201119 64864 Novosibirsk
Rossko-k 203514 64804 Novosibirsk
Fiber Telecom LTD 203784 64807 Novosibirsk
CDNetworks 204720 64849 Novosibirsk
Cortel Limited liability company 205063 64797 Novosibirsk
HOSTLINE, UAB 207785 64886 Novosibirsk
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala» 209307 64820 Novosibirsk
Okko 211609 64890 Novosibirsk
Individual entrepreneur Filicheva Natalya Sergeyevna 196949 64752 Vladivostok
Gcore Rus Ltd 199524 64854 Vladivostok

Protection against DDoS-attacks by blackholing

MSK-IX offers the Blackholing mechanism of protection from DDoS-attacks to all participants using RS. The mechanism allows the participant at the time of the attack to completely filter out incoming traffic directed to the attacked network prefix.

Traffic filtering is performed by rewriting BGP next-hop IP address on unique Blackhole filter interface for the affected network prefix within BGP-announcements of the participant. RS automatically rewrite next-hop for the participant with set Blackhole community 65535:666. Once the participant removes the Blackhole community attribute from its BGP-announcements traffic flow to the affected prefix is automatically resumed.

  1. Attribute 65535:666 for Blackhole Community is used according to RFC 7999.
  2. RS accepts networks with attribute 65535:666 and network size ranging from /25 through /32. It is recommended to use the /32 by default.
  3. It is recommended to accept RS announcements of networks with set attribute 65535:666 and size varying from /25 through /32 for all participants using RS.
  4. In accordance with the policy of regional Internet registries RIR (RIPE, RADB and so on), Blackhole community can be set up only for networks that have already been announced to the participant. RS accepts announcements from networks with set BGP community 65535:666 provided such networks have already been announced by the participant without attribute 65535:666.

The parameters of Blackhole filter interface

IPv4-address Moscow
Riga n/a
MAC-address 0066.0066.0066
BGP community 65535:666

Bidirectional Forwarding Detection (BFD) protocol

The Bidirectional Forwarding Detection (BFD) protocol is designed to ensure rapid detection of link failures in networks and reroute traffic to an alternate path. The protocol is supported by all MSK-IX Route Servers.

To enable BFD protocol support for BGP session with the Route Server, send a request to from the address of your organization's technical or administrative representative.

BFD protocol timers and configurations (default values)*

BFD protocol IP addresses equal with BGP session config
Protocol and port UDP, port 3784
Min Rx interval 1000 ms
Min Tx interval 1000 ms
Idle Tx interval 1000 ms
Multiplier 5


* If you wish to use other BFD timers, please consult with MSK-IX technical representatives .

Information on BFD sessions with the Route Server is available at Looking Glass MSK-IX under Summary and Neighbor Info.