Peering at Perú IX (PIT Peru sac)

Route Servers

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) ( 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 ServerDirección IPASN
RS1-v4 (IPv4)
RS2-v4 (IPv4)
RS1-v6 (IPv6)2803:cd60:6411:5::164115
RS2-v6 (IPv6)2803:cd60:6411:5::264115

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.

BGP Communities

Comunidades BGP para controlar anuncio de prefijos a uno o más peers del Route Server de Lima

DescriptionCommon BGP CommunitiesBGP Large Communities
Avoid announcing a prefix to a peer0:peer-as64115:0:peer-as
Advertise a route to a certain peer64115:peer-as64115:1:peer-as
Avoid announcing a prefix to all peers0:6411564115:0:0
Advertise a route to all peers64115:6411564115: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

DescriptionBGP Large Communities
Do prepend once to peer64115:101:peer-as
Do prepend twice to peer64115:102:peer-as
Prepend three times to peer64115: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.

Bilateral Sessions

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.