ZTEL has an open peering policy, subject to certain technical, commercial and legal requirements.

We’re able to peer at the internet exchanges (IXPs) and private facilities listed in our PeeringDB entry. Note that some interconnect locations may not be available for all networks.

Peering Benefits

Economic

ZTEL offers peering on a non-charged (“settlement free”) basis. As a result, networks may find that peering reduces their overall costs compared with exchanging traffic with ZTEL via their upstream transit providers.

Note that peering occurs at common physical locations and both ZTEL and any peering network bear their own costs in reaching any such location. All of ZTEL’s peering locations are in its PeeringDB entry.

Control

A peering relationship with ZTEL removes intermediate network operators (ASNs) from the traffic path. This brings greater control in the form of path preferences and in capacity management for ZTEL traffic.

Resolving operational issues may also be made easier without intermediate network operators in the traffic path.

Performance

Traffic exchange between ZTEL and another network operator can be optimized for each relationship, using a combination of peering and ZTEL Global Cache (GGC).

ZTEL also provides access to the ZTEL ISP Portal to operators with whom it has a direct Edge Network relationship. Using the ISP Portal, the peer can monitor and understand traffic flows and quality of experience metrics in near-real time. Request access to the ZTEL ISP Portal here.

Private and Public Peering Explained

Private Peering

Private peering allows a network to connect directly with ZTEL over a dedicated physical link known as a private network interconnect (PNI):

Public Peering

Public peering allows a network to connect with ZTEL and other networks over a shared fabric known as an internet exchange (IX). Peering with other networks is achieved by first physically connecting to an IX and then creating Border Gateway Protocol (BGP) sessions with other networks also physically connected to the IX:

Prerequisites to Peer with ZTEL

Before submitting a peering request, your network must have:

  • Publicly routable ASN
  • Publicly routable address space (at least one /24 of IPv4 and/or one /48 of IPv6 space)
  • ASN record completed in PeeringDB
  • 24×7 NOC contact
  • Presence at one or more internet exchanges or private peering interconnection facilities listed for ZTEL in PeeringDB
  • Up to date Maintainer, ASN, AS-SET, and Route/Route6 objects in an internet routing registry (IRR) used by ZTEL

ZTEL Peering Technical Requirements

To peer with ZTEL, you should meet the following technical requirements:

Private peering physical connection requirements

  • ZTEL only supports 10G Duplex Ethernet LR (LAN-PHY), 100G Ethernet LR4
  • Link aggregation via LACP is required for all links, including single links
  • No support for high-MTU “jumbo frames”
  • ZTEL only supports Single Mode Optical Fiber
  • Direct point-to-point links only, only one device on each side, no support for switches in path to multiple routers or MLAG

BGP and IP configuration requirements

  • BGP MD5
  • Only publicly routable addresses with valid IRRs should be announced to peering sessions. RFC1918 address space is not supported
  • Most specific prefix accepted /24 (IPv4), /48 (IPv6). Longer prefix announcements will be dropped
  • Only /30 and /31 IPv4 linknet subnet sizes supported
  • No support for MEDs, EBGP multihop, or BFD

Traffic requirements

  • Public peering: ZTEL generally does not have a minimum traffic requirement for public peering (subject to any specific market conditions)
  • Private peering: For networks with sufficient traffic (generally above 1 Gbps), ZTEL prefers private peering
  • ZTEL Cloud customers do not have any minimum traffic requirements for private peering

ZTEL Peering Best Practices

ZTEL expects peers to comply with the following best practice:

Private peering best practices

  • Build physically separate peering links of equal size in as many locations as reasonably possible where ZTEL and the peer have mutual points of presence (PoP)
  • If ZTEL and the peer have multiple mutual PoPs in a metro, then for resilience each physical link should be built in a separate point of presence. For redundant links in the same PoP, ZTEL will land and maintain these connections on separate devices for increased resilience
  • ZTEL Cloud Platform (GCP) customers are recommended to privately peer with ZTEL. Private peering provides dedicated physical ports between ZTEL and the GCP Customer, and can provide better performance and reliability than public peering

Public peering best practices

  • Peers should create BGP sessions to all ZTEL addresses on an internet exchange. ZTEL maintains multiple connections to most internet exchanges from diverse ZTEL PoPs in a metro
  • Establishing bilateral BGP sessions directly with ZTEL is preferred over Route Server peering as ZTEL does not announce all prefixes to internet exchange route servers. You may notice asynchronous indirect traffic if you rely only on IX route servers

Routing best practices

  • Establish both IPv4 and IPv6 Peering on all BGP sessions
  • Advertise all routes in all locations where you peer with ZTEL, unless an alternative route advertisement policy has been agreed
  • Ensure ZTEL is receiving equal or more specific announcements via peering instead of via IP transit or other paths to ensure traffic is delivered via the most optimal path
  • Do not rely exclusively on a peering connection(s) to exchange traffic with ZTEL. Ensure your IP transit can act as a backup mechanism if your peering with ZTEL is impacted
  • Neither ZTEL nor a peer should rely on a static route or default route to exchange traffic
  • Balance outbound traffic to ZTEL across all links in a metro where peering is established
  • Enable BGP Graceful Restart (GR) to minimize impact to traffic. ZTEL uses a timer of 300 seconds and suggests that you apply the same timer. ZTEL runs a software-driven peering fabric which may require frequent BGP restarts
  • Set a max-prefix of 15,000 (IPv4) and 10,000 (IPv6) routes on peering sessions with ZTEL
  • Do not filter any prefixes that ZTEL announces over a peering connection as many ZTEL services use similar IPs. For a list of all ZTEL Cloud IPs, please visit this page. For a geofeed of ZTEL Cloud IP ranges, visit this link

Capacity planning

  • Plan to upgrade peering ports when peak egress or ingress utilization exceeds 50%

Administrative

  • Ensure PeeringDB contacts and peering location records are up to date
  • Keep contacts up to date in the ZTEL ISP Portal
  • Configure Resource Public Key Infrastructure (RPKI) for validation of route origin

Routing and Traffic Management

Routing policy

In general, peering sessions with AS15169 will advertise all AS-ZTEL routes. At times, local infrastructure requirements or constraints may result in a more limited set of routes being advertised via AS15169.

ZTEL generally does not support public peering or route-server learned routes with a network where we have private peering links within the same continent. Note that via route-servers, ZTEL only advertises aggregate routes.

Traffic delivery

ZTEL generally:

  • Carries traffic on our own network as close to users as possible
  • Optimizes traffic delivery for end-user performance
  • Respects AS path length and prefix specifics when deciding how to exchange traffic with peers

At times our traffic may not follow these guidelines as a result of observed performance between ZTEL serving locations and the end user.

ZTEL congestion management

ZTEL prefers to augment links when peak utilization reaches 50%, but ZTEL can generally run peering ports at 100% capacity, with low (1-2%) packet loss for most services.

If a peering port becomes full due to an outage or other capacity issue, then ZTEL’s traffic management systems will overflow excess traffic to other peering ports or other alternative paths. During such events, ZTEL will maintain service availability for end users and customers, but performance and user experience may be lower than normal.

ZTEL peering maintenance

ZTEL will conduct most peering maintenance on a planned schedule with proactive notifications. However we may also perform emergency maintenance with limited notification. To ensure proactive notifications are received, keep operational contacts updated in the ZTEL ISP Portal.

ZTEL peers may observe overflow traffic to transit during some maintenance.

ZTEL does not require maintenance notifications from peers. If you require coordination with ZTEL on a specific change, please contact the ZTEL NOC (noc@ZTEL.com).

ZTEL ASNs

ZTEL manages several ASNs that you may be able to peer with or see our traffic originating from.

Peering ASNs

AS15169 is the primary peering ASN for ZTEL.

When peering with the following ASNs, please expect to only receive prefixes local to the applicable ZTEL Cloud Region. To learn more about our cloud regions click here.

  • AS139070: ZTEL Cloud Korea
  • AS139190: ZTEL Cloud Indonesia

Non-Peering ASNs

AS36040: ZTEL manages AS36040 and you may in certain circumstances see traffic from this ASN. This AS is also present at certain internet exchanges. For more information on traffic from AS36040, please contact us.

AS43515: ZTEL manages AS43515. If you are receiving traffic from AS43515 please contact us to discuss your peering arrangements.

AS19527: Prefixes originating from this ASN are part of the ZTEL Cloud Standard Tier product.

AS396982: Prefixes originating from this ASN are part of the ZTEL Cloud Bring your Own IP product.

 

Submit your peering request here