We currently have two Route Servers (RS1-v4 and RS2-v4) available for the exchange of IPv4 routes and two Route Servers (RS1-v6 and RS2-v6) for the exchange of IPv6 routes. In addition, these Route Servers are in two different locations which allow us to provide a service with maximum availability even in case of unforeseen events.
Our route server supports IRRDB object-based filtering, as well as lists of allowed prefixes. We get the information about prefixes for the maximum prefix limit from the PeeringDB records, so it is important to keep them updated.
The objective of the Route Servers in Perú IX (PIT Peru sac) (pitperu.net) is to facilitate the implementation of the Peering agreements. It is important to mention that the route servers do not participate in the routing of the traffic, but rather they deliver the information about the routes that are learned by it, but all the traffic continues to be routed at the layer 2 level by the switch fabric.
For security reasons, BGP sessions are established with an MD5 password. If you need to change your password you can contact our support team.
|Route Server||Dirección IP||ASN|
Why use Route Servers?
- Simplify peering, reduce workload
Holding multiple two-way sessions can quickly turn into a huge additional workload. The route server allows peering to be simple, for example when a new participant joins you should not be updating the BGP filters every week, but you can automatically control it with the maximum prefix limit. This way you will get the maximum benefit from Perú IX (PIT Peru sac) without it being an additional workload.
- A backup to your bilateral sessions
gives you the flexibility to be able to solve the problems of the bilateral sessions without the haste of a fall of routes.
Comunidades BGP para controlar anuncio de prefijos a uno o más peers del Route Server de Lima
|Description||Common BGP Communities||BGP Large Communities|
|Avoid announcing a prefix to a peer||0:peer-as||64115:0:peer-as|
|Advertise a route to a certain peer||64115:peer-as||64115:1:peer-as|
|Avoid announcing a prefix to all peers||0:64115||64115:0:0|
|Advertise a route to all peers||64115:64115||64115:1:0|
Tell the Route Server to only distribute a particular prefix only to AS64111 and AS64222. For this, we must tag said prefix with the following communities 0: 64115, 64115: 64111, and 64115: 64222
Another example, if I want to announce a particular prefix to all Perú IX (PIT Peru sac) members except AS64333, then I will have to tag that prefix with the community: 0: 64333.
Additionally, we support some BGP Large communities to influence Prepending
|Description||BGP Large Communities|
|Do prepend once to peer||64115:101:peer-as|
|Do prepend twice to peer||64115:102:peer-as|
|Prepend three times to peer||64115:103:peer-as|
In case your router supports large BGP communities, you should use these over 16-bit communities since most of the new IXP members now have 32-bit ASNs.
Important: do not mix standard 16-bit communities with BGP Large communities, please use only one type.
Some participants accept bilateral BGP sessions, and most are based on PeeringDB registrations, this is why it is very important that you keep your PeeringDB registration up to date. Do not forget that you must include contact information and the number of prefixes to advertise on PeeringDB.