MSK-IX / Internet Exchange / Route Server
← Go back
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
CityRoute Server ASAS-SETIP-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. Petersburg43690AS-SPBROUTESERVER194.226.100.100/23
17:00-18:00 (local time) daily
except Sat. and Sun.
13:00-14: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.
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.
12:30-13:30 (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.

* 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.

ActionBGP Standard Community (RFC1997)BGP Large Community (RFC8092)
Block announcement of prefix to AS [peer-as]0:peer-asRSAS:0:peer-as
Announce prefix to AS [peer-as]RSAS:peer-asRSAS:1:peer-as
Block announcement of prefix to all participants0:RSASRSAS:0:0
Announce prefix to all participantsRSAS:RSASRSAS:1:0
Blackhole community (blocking of incoming traffic)65535:666--
Prepend once when announcing this prefix to AS [peer-as]1:peer-asRSAS:101:peer-as
Prepend twice when announcing this prefix to AS [peer-as]2:peer-asRSAS:102:peer-as
Prepend three times when announcing this prefix to AS [peer-as]3:peer-asRSAS:103:peer-as
Geolocation specific BGP community to identify the city of interconnection
(inserted automatically at RS side)
ActionBGP Standard Community (RFC1997)
Aggregate for this prefix exists in IRR DB5RSAS:65500
Announce prefix with no-export attributeRSAS: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 0RSAS:0
Set local-preference 50RSAS:50
Set local-preference 100RSAS: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

ParticipantsAS number, if existsCommunityCity
Icewood LLC20111964865Ekaterinburg
Cortel Limited liability company20506364802Ekaterinburg
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala»20930764817Ekaterinburg
JSC «MSK-IX»20502264839Kazan
Huawei Technologies Co. Ltd.13690764814Moscow
Kaopu Cloud HK Limited13891564935Moscow
Apple Communication Ltd.13990164941Moscow
DE-CIX Academy19661064813Moscow
NetOne Rus19669564712Moscow
ISP WEBA Networks19675064771Moscow
Azertelecom LLC19692564765Moscow
JSC «R-Pharm»19706264711Moscow
LinkTelecom NN19727564972Moscow
«DoubleGIS» Ltd.19748264963Moscow
SkyNet LTD19782664709Moscow
SPB TV Telecom LLC19788864722Moscow
Federal State Unitary Enterprise «Morsziazsputnik»19796964875Moscow
SIACOM JSC19815064976Moscow
Joint Stock Company «Ul-com Media»19829764931Moscow
limited liability company «INKO-Telecom19836764918Moscow
LLC «United Networks»19853964885Moscow
LTD BeGet19861064751Moscow
IP Gasanov F. U.19900864903Moscow
Limited Liability Company «Telecom-Birja»19959964734Moscow
LLC «Okey-Telecom»19966964787Moscow
Stack Groupp20004464824Moscow
Yandex.Cloud LLC20035064815Moscow
OOO Hosting Vashego Uspeha20048764756Moscow
LIFESTREAM LTD20097664783Moscow
Icewood LLC20111964860Moscow
Tvoy Telecom, LLC20121164848Moscow
LLC «Servicepipe»20170664847Moscow
Miranda-Media LIMITED20177664821Moscow
«MaximaTelecom» JSC20217364743Moscow
Sky Telecom20248664838Moscow
Chernyshov A.A.20298464905Moscow
Fiber Telecom LTD20378464816Moscow
ShowJet LLC20427164880Moscow
«Technical Center of Internet» Limited Liability Company20458264831Moscow
Company Buster20460064789Moscow
JSC «MSK-IX»20502264810Moscow
Cortel Limited liability company20506364801Moscow
DE-CIX R&D20553064828Moscow
Tinkoff Mobile20563864962Moscow
RUCOMTECH LLC20713364785Moscow
Limited Liability Company Floral alliance20756164851Moscow
HOSTLINE, UAB20778564846Moscow
LLC «LTDNET»20812964914Moscow
O2xygen Ltd20834964923Moscow
Cloud technologies Ltd20867764895Moscow
AO «Kaspersky Lab»20903064822Moscow
«China Mobile International (Russia)» LLC20914164843Moscow
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala»20930764966Moscow
Tricolor LTD20973964837Moscow
Telegram Messenger Inc21115764892Moscow
Okko21160964888Moscow (RU)21191464958Moscow
ACCEPT (REN TV Channel)21207564944Moscow
Port 179 Ltd21223264957Moscow
Start.Ru, LLC21307564921Moscow
Icewood LLC20111964864Novosibirsk
Fiber Telecom LTD20378464807Novosibirsk
Cortel Limited liability company20506364797Novosibirsk
HOSTLINE, UAB20778564886Novosibirsk
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala»20930764968Novosibirsk
Individual Entrepreneur Bakaev Ivan Vladimirovich21182164959Novosibirsk
BaishanCloud13905764896St. Petersburg
ISP WEBA Networks19675064763St. Petersburg
LTD BeGet19861064750St. Petersburg
RetnNet19894764805St. Petersburg
LLC «Okey-Telecom»19966964788St. Petersburg
AtomData Ltd19986064964St. Petersburg
OOO Hosting Vashego Uspeha20048764755St. Petersburg
Icewood LLC20111964861St. Petersburg
Company Buster20460064790St. Petersburg
Cortel Limited liability company20506364800St. Petersburg
medsi20629564826St. Petersburg
HOSTLINE, UAB20778564877St. Petersburg
Obshchestvo s ogranichennoj otvetstvennost'yu «Cifrovye Seti Urala»20930764967St. Petersburg
EdgeCenter21075664910St. Petersburg
Okko21160964887St. Petersburg
Individual entrepreneur Filicheva Natalya Sergeyevna19694964752Vladivostok

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. IPv4 only: 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. IPv6 only: RS accepts networks with attribute 65535:666 and network size ranging from /49 through /128. It is recommended to use the /128 by default.

  4. It is recommended to accept RS announcements of networks with set attribute 65535:666 and size varying from /25 through /32 (ipv4) and size varying from /49 through /128 (ipv6) for all participants using RS.

  5. 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
CityIPv4IPv6MAC-addressBGP community
St. Petersburg194.226.100.600:66:00:66:00:6665535: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 addressesequal with BGP session config
Protocol and portUDP, port 3784
Min Rx interval1000 ms
Min Tx interval1000 ms
Idle Tx interval1000 ms

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

If your device supports a BFD timer with a maximum of 999 ms, you can use it. In this case, there will be no errors or conflicts.

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

Back to list