Peering

PEERING POLICY

This document outlines Fly Network’s policies and preferences for peering with external third parties on a free basis (“Fly Network Peering Policy” or “Fly Network Settlement Free Interconnection Policy”) and includes the key factors that Fly Network considers when evaluating a peering request from external parties with Fly Network’s AS209591 network or any subsequent AS number (“Fly Network AS209591”). In order to provide a highly available and high performance experience for our customers, Fly Network maintains a global network infrastructure and peers with external networks, using both public peering (Internet Exchange) and private peering (Private Network Interconnect ).

PEERING REQUESTS

Any external party intending to peer with Fly Network AS209591 must have an updated and fully completed entry in peeringdb.com. All peering requests should arrive via email. Fly Network, in its sole discretion, will evaluate peering requests and existing agreements on a case-by-case basis, considering the external party’s adherence to the best practices below and other factors. Fly Network undertakes to respond, inclined or refused, to all peering requests in a timely manner.
Our PeeringDB page: https://www.peeringdb.com/net/22298
Peering requests should be sent to: noc@flynetwork.it

Peering best practices

The following are the best practices expected by Fly Network peering partners:

  • PKeep an updated and fully completed entry in peeringdb.com
  • Use a unique public autonomous system number (“ASN”)
  • Manage a dual stack network (IPv4 and IPv6) using a public ASN
  • Resolve issues raised in support requests promptly, with a 24/7 network support contact
  • Committed to interconnect with Fly Network in all common places where Fly Network and the partner both have a point of presence
  • Keep entries in Internet routing logs (“IRR”) and use IRR entries to filter partner networks
  • Follow the technical guidelines for peering below
  • Enable or Schedule Enablement of Resource Public Key Infrastructure (“RPKI”) for Path Source Validation
  • Avoid malicious or otherwise undesirable traffic or activity on your partner’s network

Top of page

PEERING TECHNICAL GUIDELINES

Fly Network expects its peering partners to comply with the following technical guidelines which are based on best common practices for Internet eXchange Points (“IXPs”). Public peering partners must adhere to the technical requirements of the respective IXPs that are used for interconnection and may only use the IPv4/v6 addresses assigned to them by those IXPs.

ROUTING

  • Support Border Gateway Protocol (“BGP”) version 4 routing protocol for propagating routing information across the interconnection
  • Announce only the peering partner’s own routes, its customer routes and any other network that has agreed to allow the partner to announce its routes to third parties
  • On public IXPs, a peering partner should only announce prefixes with its own next-hop IP address and not announce routes on behalf of other peers on the IXP
  • Support both IPv4 unicast and IPv6 unicast traffic as native or dual-stacked
  • Accept any appropriately IRR-registered prefix announcements up to /24 in length for IPv4 and /48 in length for IPv6
  • Employ a routing policy that ensures that traffic generally follows a closest-exit behavior.
  • Support BGP prefix filter updates using these IRRs, with automated router configuration updates occurring no less than every 24 hours: RADB, ALTDB, RIPE, APNIC and ARIN
  • Support BGP prefix filters using Route Origin Authorizations (“ROAs”) for origin ASN validation for directly connected peers, or use RPKI-based validation for all route and traffic exchange.