Overview

The route servers simplify the exchange of routing information between the members 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 route servers support MD5 passwords. The route servers process and advertise prefixes according to some rules, and directions received by the members in the form of bgp communities. The route servers implement passive BGP sessions. That is, they will always act in server mode, listening to port 179, and will never initiate a session as a client.

The use of the route servers is recommended but not mandatory for GR-IX members. Each member should not assume that all other members are connected to the route servers, or that all connected members will be willing to exchange traffic with it. Even when peering through the route server, a bilateral (business-level) agreement may be necessary.

Recommendations for the members

• Peering with all route servers is recommended (although not mandatory).
• For members with multiple routers connected to GR-IX, it is recommended that each of these routers connect to all route servers, and that each of those routers implement the same import/export policy for all of these 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.

How to connect

The route servers implement the following BGP timers:
keepalive 10
hold-time 30

(Note: Timers are part of the bgp negotiation with the peer; the larger values apply)

Tip: 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 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 (i.e. with a no bgp enforce-first-as on a Cisco router)

BGP communities can be used in order to control the members where a prefix is advertised.

• By default, the route server will advertise each prefix to all connected members.
• Standard community 50745:PEER-AS or extended community route_target:50745:PEER-AS (depending on whether the PEER AS is 2- or 4-byte) can be used to exclude announcing this prefix to PEER-AS.
• Community 50745:0 can invert the policy for a prefix; that is, the prefix will be advertised only to the AS’es identified by the (route_target:)50745:PEER-AS communities on the prefix.

Note that this is a per-prefix behavior, i.e. each prefix may implement a different policy based on its own communities.

Note: also that there is no way for a member to block the incoming advertisements on the route-server level; this has to be done by ingress BGP filters on its own equipment.

Processing of prefixes

Received prefixes

The route server will not accept:

• Prefixes with next-hop different than the peers’ ip(v4/v6) address.
• Martians and other unexpected routes:
  • v4: 10.0.0.0/8+, 169.254.0.0/16+, 172.16.0.0/12+, 192.0.0.0/24+, 192.0.2.0/24+, 192.168.0.0/16+, 198.18.0.0/15+, 198.51.100.0/24+, 203.0.113.0/24+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32, 0.0.0.0/0(28-32), 0.0.0.0/0(0,7)
  • v6: ::/0, ::/96, ::/128, ::1/128, ::ffff:0.0.0.0/96+, ::224.0.0.0/100+, ::127.0.0.0/104+, ::0.0.0.0/104+, ::255.0.0.0/104+, 0000::/8+, 0200::/7+,3ffe::/16+, 2001:db8::/32+, 2002:e000::/20+, 2002:7f00::/24+, 2002:0000::/24+, 2002:ff00::/24+, 2002:0a00::/24+, 2002:ac10::/28+, 2002:c0a8::/3+, fc00::/7+, fe80::/10+, fec0::/10+, ff00::/8+
• Prefixes
  • with an RPKI INVALID status
  • with the last AS in the AS-PATH not included in the member’s AS-SET (as defined in the members portal), and
  • without a corresponding route object of same length that originates from an AS in the member’s AS-SET

In addition, the number of received prefixes is capped by the maximum prefixes defined per member in the members portal.

Advertised prefixes

The route servers:

• Will advertise to all peers except PeerAS all prefixes that contain 50745:PeerAS
• Will advertise only to PeerAS all prefixes that contain both 50745:0 and 50745:PeerAS
• Will NOT advertise to any peer all prefixes that contain only 50745:0

If more than one candidate exists for the same prefix, the route selection will take place as follows:

1. The prefix with the shortest AS path will be selected
2. The prefix with the best origin will be selected (IGP->EGP->incomplete)
3. For prefixes of the same Peer (same first AS in the AS-PATH), the prefix with the lower MED will be selected (no MED=0)
4. The older (more stable) prefix will be selected

Note: As different prefixes may be eligible to be advertised to different peers, different best candidates for the same prefix may be advertised to different members.

By default, the route servers will change MED in order to optimise routing (i.e, between two same prefixes of the same AS, the closer (in terms of switching hops) will be selected). This behavior can be overridden using the community 50745:65000; in that case MED will be respected by the route server and will be preserved at the outgoing advertisements.

The route server will always preserve the AS-PATH and next-hop.

MD5 Authentication

The route servers support MD5 authentication of the BGP peerings. In order to enable authentication please contact our helpdesk

Update Schedule

The route servers are updated in a regular basis in order to reflect changes in the IRRDBs (eg new AS numbers within a macro, new prefixes originating from an AS) or changes within the members portal (eg new MD5 password, new macro etc). The update scedule for the route servers is different in order to minimize the propagation of errors. The update schedule is as follows:

• rs0: Every two hours, between 10.00 and 14.00 (local time), Monday to Friday
• rs1: Every two hours, between 12.00 and 16.00 (local time), Monday to Friday
• rs2: Every two hours, between 11.00 and 15.00 (local time), Monday to Friday

You can see the time of the last reconfiguration of each route server through the route server looking glass.

Debugging

Two debugging tools are offered:

• The route server looking glass where you can check the prefixes and their properties (as_path, communities, next-hop etc) in each of the routing tables of each route server
• A Route Server Prefix report tool that reports prefixes accepted, rejected and acceptable (but not announced) prefixes. This tool is available for members only through the GR-IX portal.