Route Server

Route servers provide multilateral peering between members IXP environment. Unlike the standard BGP peering, where everyone has to establish a BGP connection with each, the establishment of BGP Route Server allows the IXP members a service where is possible to retrieve all networks in IXP with only one connection. 

Below is an overview how the Route Server work in CIX.

rs-web.png

Meaning of BGP Community for Route Servers

BGP Community

Meaning for RS

0:ASN

do not send toward BGP neighbor with ASN

0:51702

do not send to anyone

51702:51702

send everyone

51702:ASN

send toward BGP neighbor with ASN

BGP communities for 32-bit AS numbers

To use BGP communities with 32-bit AS numbers, set ASN values as listed in the following table:

BGP Communities for 32-bit AS numbers

Member

AS number

Community

Sedmi odjel d.o.o.

198785

65002

Altus IT 199244 65003
Avalon 201563 65004
Databox 206575 65005
Telemach 205714 65006
4TEL Telekomunikacije 203964 65007
HAKOM 207514 65008
Fenice Telekom 204020 65009
EOLO 201987 65010

All advertised networks must be marked with some of the BGP community shown above. 

If route is not marked by any of these community, than the route will not be advertised to other members.

If route is marked with more communities, some of which are contradictory then apply the following rules:

- the first it takes into account the more specific community (51702:ASN, 0:ASN), provided that the advantage has community that allows for route to be advertised (51702:ASN)

- then it takes into account the general community (51702:51702, 0:51702), provided that the advantage has community that allows for route to be advertised (51702:51702)

Example:

CIX AS: 51702

AS peer1: 65222
AS peer2: 65333
AS peer3: 65444

 { 51702:51702 0:51702}

- route marked like this will be advertised toward every AS in CIX

 { 0:51702 51702:65333}

- route marked like this will be advertised only toward AS 65333

 { 51702:51702 0:65333}

- route marked like this will be advertised to everyone except AS 65333

 { 51702:51702 0:51702 51702:65222 0:65222 0:65444}

-route marked like this will be advertised to everyone except AS 65444

 { 0:51702 51702:65222 0:65222 51702:65333 0:65444}

- route marked like this will be advertised only toward AS 65222 and AS 65333

AS-CIX-ZG-RS

The list of AS and AS-SET objects, whose prefixes are advertised over route servers in CIX, can be found on the AS-CIX-ZG-RS object in the RIPE database.

BLACKHOLE

  • BLACKHOLE routes must be marked with community 65535:666.
  • Size of BLACKHOLE route can range from /16 to /32.
  • CIX members have to allow /25 - /32 routes marked with BLACKHOLE community to pass trough their input filters 
  • CIX members may advertise BLACKHOLE routes only from the range of their own address space!
  • It is possible to blackhole routes only to certain BGP neighbors respecting the rules described earlier on this page.

Example:

CIX AS: 51702
AS peer1: 65222
AS peer2: 65333

{ 65535:666 51702:51702} 

-  route marked like this will be advertised toward every AS in CIX

{ 65535:666 } 

- route marked like this will not be sent to anyone

{ 65535:666 51702:65222 51702:65333} 

- route marked like this will be advertised only toward AS 65222 and AS 65333

CIX members that use direct peerings for route exchanging can also use the blackholing service.
Networks or hosts that they want to protect should be announced in a way that nexthop address is set to 185.1.87.3.

RKPI validation of routing information

Resource Public Key Infrastructure (RPKI) is a cryptographic method of signing records that associate a route with an originating AS number. Presently the five RIRs (AFRINIC, APNIC, ARIN, LACNIC & RIPE) provide a method for members to take an IP/ASN pair and sign a ROA (Route Origin Authorization) record.

ROA (Route Origin Authorisations) is a cryptographically signed object that states which Autonomous System (AS) is authorized to originate a particular IP address prefix or set of prefixes.

Among the other things, ROA contains the 'maximum prefix length' field which is optional. When this field is not defined, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered invalid. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix. When present, this field specifies the length of the most specific IP prefix that the AS is authorised to advertise. For example, if the IP address prefix is 10.0.0.0/16 and the maximum length is 22, the AS is authorised to advertise any prefix under 10.0.0.0/16, as long as it is no more specific than /22. So, in this example, the AS would be authorised to advertise 10.0.0.0/16, 10.0.128.0/20 or 10.0.252.0/22, but not 10.0.255.0/24.

RPKI validation of routing information has been initiated on route servers in CIX and invalid prefixes are filtered on route servers. The results are visible on CIX Looking Glass (https://www.cix.hr/usluge/looking-glass) - by clicking on 'Neighbor info' and entering the AS number. The validation results are visible in the second column of the view (ovs). They can be:

  1. VALID – route announcement is covered by at least one ROA.
  2. INVALID – prefix is announced from an unauthorised AS (this means that there is a ROA for this prefix for another AS but no ROA authorising this AS, or this could be a hijacking attempt) or the announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS.
  3. UNKNOWN – prefix in this announcement is not covered (or only partially covered) by an existing ROA.

Configuration examples

Cisco Example

Juniper Example