Peering Policy

VTS Peering Policy

Virtual Technologies and Solutions is listed on PeeringDB, the industry database for peering information for network operators. Please review our PeeringDB entry for the most current list of VTS’s public and private peering locations. VTS generally has an open peering policy subject to the below:

  • Peering with with customers or customers of existing peering partners is not possible
  • VTS may shutdown peering if the peer is a customer or a customer of an existing peering partner
  • The peer should provide consistent routing announcements

Requesting Peering

Any network is welcome to contact VTS via email at peering@vts.bf to discuss peering or by submitting a peering request form. Please ensure your ASN and peering point locations are included. An up-to-date PeeringDB entry is nearly always required.

Please note: If you need to peer in multiple locations, a request should be submitted for each individual peering session/location. Prior to submitting a request, please take the following in consideration:

Routing Only Protocol

VTS is willing to peer with networks which are connected to one or more exchange points which we have in common. Only send us traffic that is destined for the prefixes we announce to you. Do not point default at us or use static routes to send us traffic that does not match the routes we announce to you as this will result in immediate de-peering.

Operational Contacts

Peers are required to operate a contactable NOC on a 24/7 x 365 basis. In addition peers must ensure that they have up-to-date NOC contact details published on PeeringDB. Contact details provided must be responsive to raised issues and concerns. Details should be published on PeeringDB along with other relevant peering.

Locations

VTS prefer to peer in multiple locations so peers should be willing and able to interconnect at any Internet Exchange Point, where they and VTS share a network point of presence. If additional transport is required to establish a peering relationship, parties agree to share any transport costs under mutually agreeable terms.

Traffic Volume

VTS does not require a minimum set threshold to consider IXP peering or PNI. The requesting party need only provide sufficient business case as part of the peering request.

Documented Routing Policy

Peers should maintain a publicly accessible description of their external routing policy, in a form usable by VTS engineers to determine the correctness of the routing information received in BGP.

At minimum, this should consist of the following RPSL objects, registered in a publicly available IRR databases:

  • autnum: An object describing the policy and contact details for the peer’s ASN
  • as-set: An object describing the set of ASNs for which the peer announces transit
  • route/route6/route-set: An object, for each prefix announced by the peer, specifying the ASN originating that prefix in BGP

VTS will use the above information to build inbound prefix filters. Peers must ensure that this information is kept up to date.

 

© VTS 2024. All rights reserved.