Route Servers

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 the the data plane of the exchanged traffic.

The route servers support Bidirectional Forwarding Detection (BFD) and 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 both 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 both route servers, and that each of those routers implement the same import/export policy for both 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

Route Server AS Number IPv4 Address IPv6 Address
rs0.gr-ix.gr 50745 176.126.38.120 2001:7f8:6e::120
rs1.gr-ix.gr 50745 176.126.38.121 2001:7f8:6e::121

Tip: In some BGP implementations, the BGP process is 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.

Community Purpose
Advertisement Control:
50745:PeerAS (for 16-bit AS numbers) or route_target:50745:PeerAS (for 16-bit or 32-bit AS numbers) Do not advertise to PeerAS
50745:0 orroute_target:50745:0 Inverse policy (do not advertise to any peers, except from those defined with RSasn:PeerAS)
Prepending (communities can be combined)
50745:65501 Prepend 50745 one time
50745:65502 Prepend 50745 two times
50745:65503 Prepend 50745 three times
MED handling
50745:65000 Do not alter incoming MED for IX switching optimization
Marking (performed by the route servers)
50745:65101 Prefix received by a peering at EIE/NHRF POP
50745:65102 Prefix received by a peering at LH POP
50745:65103 Prefix received by a peering at MED POP

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

grix-route-servers

Bidirectional Forwarding Detection (BFD)

Bidirectional Forwarding Detection (BFD) is a detection protocol that is designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning is easier, and reconvergence time is consistent and predictable. The main benefit of implementing BFD for BGP is a significantly faster reconvergence time.

The GR-IX route servers support BFD by default for all configured bgp peerings. Nevertheless, BFD is configured as passive, i.e. the feature is not activated and no outgoing BFD packets are sent untill a BFD packet is received by the bgp peer. The standard UDP ports (src:49152-65535, dst:3784-3785) are configured/expected for outgoing/incoming packets.

In order to form a BFD session with any of the route servers, the following timers are proposed:

bfd interval 300
multiplier 5

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 08.00 and 16.00 (local time), Monday to Friday
  • rs1: Every two hours, between 09.00 and 17.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.