• About RS
• RS configuration info
• How to start using RS?
• RS routing policy
• BGP community attributes
• Control BGP Standard Community for 32-bit AS numbers
• Protection against DDoS-attacks by blackholing
• Bidirectional Forwarding Detection (BFD) protocol

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.

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

How to start using RS?

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 noc@ix.ru 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 https://www.ripe.net or whois -h whois.ripe.net 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

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.

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

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.

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 noc@ix.ru from the address of your organization's technical or administrative representative.

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