Packet Fabric
Unitas Global

PacketFabric - AS1828 - Network Information

PacketFabric operates a worldwide transport and IP transit network in support of its mission to improve network connectivity performance for its enterprise customers. We believe strongly in the ability for well-designed and implemented peering strategy to improve our customer experience while using network-connected services. We are committed to peering with networks that can provide a benefit to our customers, and to the internet community as a whole. We are also committed to providing a high-quality peering experience for our peers, and to that end we have established the following policies and guidelines for peering with PacketFabric (referred to below as "We" or "Us" or "Our").

Tools and Links

Peering Information

Peering requests should be sent to the appropriate address (see below) for the type of peering requested. Please note that we do not accept peering requests via phone or social media.

Some of our team keep an eye on IRC (#ix @ irc.terahertz.net) for peering matters, but if there are issues, please raise an issue immediately with our CMC Team, contact details listed on the PeeringDB record

Please include your ASN, a link to your PeeringDB record, and a brief description of your traffic profile and peering requirements.

Members of our peering team are normally available Monday to Friday 0800-2200 UTC, and we will endeavour to review requests within 72 hours. Requests for peering with AS1828 are reviewed according to our policy below, which serves as a general guideline, however we reserve the right to accept or reject requests at our sole discretion.

General Technical Requirements

  • A publicly routable and visible unique ASN.
  • 24x7x365 Network Operations Center (NOC), where problems can be reported.
  • Full and correctly updated PeeringDB entry and profile. Our provisioning systems rely on this information needed for configuration (IP Addresses, prefix lists and other information).
  • Peer networks must only advertise their own internal and customer routes (no transit or peering routes), and will not include routes with a private ASN in the advertisement.
  • Generally peers should advertise consistent routes at all common peering points. Exceptions are made for content delivery networks and cloud services. (Please note in requests if this is a requirement.)
  • Where possible we prefer to have direct sessions at multiple internet exchanges as we do not necessarily advertise all of our routes to IX route servers.
  • Advertised routes shall all be registered in an appropriate IRR, and where possible will have RPKI Valid ROAs for each advertised route. We reserves the right to reject RPKI Invalid routes received from peers.
  • MD5 authentication on peering sessions is not required, nor recommended, but can be supported if required. If you require MD5 authentication, please supply a password in your request.
  • We will not normally peer with an ASN that shows up in our current AS-SET (i.e. a Customer, or a downstream of that Customer).
    You may review our Current AS-SET on the IRR Explorer located at https://irrexplorer.nlnog.net/as-set/AS-UNITAS (Opens in a new window / tab) before requesting the session.
    If the IRR records are incorrect, please contact the maintainers of those records to correct them before contacting us for peering.
  • We will not normally peer with a downstream customer of an existing peer.
  • Please ensure you follow our Maximum prefix limits as detailed in our PeeringDB record

Public Internet Exchanges (IXPs)

  • At this time, there are no minimum traffic requirements for establishing bilateral BGP sessions over public internet exchanges, however we generally looks for some meaningful level of traffic or customer benefit before establishing new sessions.
  • Sessions between us and a peer network must exist in all common service regions/markets to avoid possible "trombone" routes that degrade performance. We will not normally peer with networks that do not have common peering points in all shared markets and IXs.
  • We currently peer with many IX route servers; in some cases only advertising regionally-originated routes. This policy is currently under review, for the latest status of exchanges where we peer with route servers, please check our PeeringDB record
  • Requests for bilateral sessions in public exchanges will be considered on an individual case basis, and will receive our full customer routing table, except in exceptional (normally capacity related) circumstances
  • Peering Requests for Public Internet Sessions should be sent to:   ixp-peering@packetfabric.com

Private Network Interconnects (PNIs)

  • Generally the same requirements apply for public exchange sessions, in addition to the following requirements:
  • We expect an aggregate of no less than 5 Gbps of traffic for peer networks requesting PNIs.
  • PNIs should be established in all common service areas. We generally discourage mixing public IX sessions with PNI sessions because they may have different priorities.
  • PNI cross connect costs will be shared equally by both networks, when multiple links are used.
  • PNI links are supported via 10G or 100G single mode fiber links, generally configured as LACP-active LAGs.
  • Peering Requests for Private Interconnect Sessions should be sent to:  pni-peering@packetfabric.com

Traffic Management

  • We expect peers to utilize closest-exit routing; We will do the same.
  • Requests to honor MEDs will be reviewed on an individual case basis. (Please note in requests if this is a requirement.)
  • Peers should not attempt to set a default route to our Network

Session Removal

  • If newly-requested sessions are not established within 14 days of deployment, sessions will be automatically removed.
  • Sessions idle for more than 14 days without a previously-declared extended maintenance will be automatically removed.

Other Considerations

  • We reserve the right to suspend or terminate peering at any time, if there are routing issues, or general abuse, although we will always attempt to work with our peering partners to remediate any issues.
  • Each party will bear its own expenses related to establishment of peering. (Cross connects, IX ports, necessary licenses or other regulatory approvals.)
  • None of the above policies, or the act of peering with us create any binding obligations or performance guarantees.
  • While we aim to keep bandwidth usage under 80% of capacity on any particular link and we expect the same of our peers, this cannot be guaranteed.

RPKI (Resource Public Key Infrastructure)

We support RPKI and will soon be rejecting RPKI Invalid routes received from peers, and customers. We encourage all peers to implement RPKI and to ensure that all advertised routes are covered by a valid ROA. We are currently in the process of auditing and signing all of our originated routes, and this procedure should be completed by November 1st, 2024. We are also requesting where possible that our customer networks also sign their originated routes.

For more information on RPKI, please visit https://rpki.readthedocs.io/en/latest/ (Opens in a new window / tab)
This site was last updated on June 11, 2024 with some minor corrections and clarifications. No policy changes were made. Please check back regularly for updates.