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|
|Route Server||AS Number||IPv4 Address||IPv6 Address|
The route servers implement the following BGP timers:
(Note: Timers are part of the bgp negotiation with the peer; the larger values apply)
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
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-ASor 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.
50745:0can 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-AScommunities 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.
|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 or route_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|
|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 ATH01 (EIE)|
|50745:65102||Prefix received by a peering at ATH02 (LH)|
|50745:65103||Prefix received by a peering at ATH03 (TIS)|
|50745:65111||Prefix received by a peering at THESS01 (SNC)|
Processing of 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+, 184.108.40.206/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+, ::220.127.116.11/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+
- 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.
The route servers:
- Will advertise to all peers except PeerAS all prefixes that contain
- Will advertise only to PeerAS all prefixes that contain both
- Will NOT advertise to any peer all prefixes that contain only
If more than one candidate exists for the same prefix, the route selection will take place as follows:
- The prefix with the shortest AS path will be selected
- The prefix with the best origin will be selected (IGP->EGP->incomplete)
- 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)
- 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.
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:
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 400
The route servers support MD5 authentication of the BGP peerings. In order to enable authentication please contact our helpdesk
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.
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.