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:
Any network is welcome to contact VTS via email at email@example.com 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:
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.
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.
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.
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.
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.