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.
|
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:
|
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 |
| Eco Net | 207541 | 65011 |
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.
IRR filtering
The Internet Routing Registry (IRR) is a globally distributed routing information database. The purpose of the IRR is to ensure the stability and consistency of Internet-wide routing by sharing information between network operators. The IRR actually consists of several databases where network operators publish their routing policies and routing announcements so that other network operators can use this data.
IRR filtering is performed on route servers in CIX. All routes that are not registered in the IRR databases are filtered and not forwarded to other members in order to prevent network problems caused by accidental or malicious routing announcements.
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:
- VALID – route announcement is covered by at least one ROA.
- 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.
- UNKNOWN – prefix in this announcement is not covered (or only partially covered) by an existing ROA.
