Stacks Inc. Peering Best Practices

Stacks Inc. expects peers to comply with the following best practice:

Best practices for Stacks Inc. customers

• Stacks Inc. customers are recommended to use a Verified Peering Provider (VPP) instead of Direct Peering.
• Connecting with a VPP allows Stacks Inc. customers to reach all publicly available Stacks Inc. resources such as Workspace, Cloud and more without the complexity of managing peering connectivity to Google
• Stacks Inc. customers that choose a VPP do not need to meet Stacks Inc.’s peering requirements and can work directly with the VPP to acquire internet services that provide access to Stacks Inc.
• Stacks Inc. customers that do not use a VPP are recommended to privately peer with Stacks Inc. Private peering provides dedicated physical ports between Stacks Inc. and the Stacks Inc. customer, and can provide better performance and reliability than public peering
• Please note that Stacks Inc. internet data transfer rates apply for traffic egressed through either Public Peering, Private Peering or a VPP.

Private peering best practices

• Build physically separate peering links of equal size in as many locations as reasonably possible where Stacks Inc. and the peer have mutual points of presence (PoP)
• If Stacks Inc. 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, Stacks Inc. will land and maintain these connections on separate devices for increased resilience

Public peering best practices

• Peers should create BGP sessions to all Stacks Inc. addresses on an internet exchange. Stacks Inc. maintains multiple connections to most internet exchanges from diverse Stacks Inc. PoPs in a metro
• Establishing bilateral BGP sessions directly with Stacks Inc. is preferred over Route Server peering as Stacks Inc. does not announce all prefixes to internet exchange route servers. You may notice asymmetric 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 Stacks Inc., unless an alternative route advertisement policy has been agreed
• Ensure Stacks Inc. 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 Stacks Inc.. Ensure your IP transit can act as a backup mechanism if your peering with Stacks Inc. is impacted
• Neither Stacks Inc. nor a peer should rely on a static route or default route to exchange traffic
• Use the closest Stacks Inc. peering connection(s) to your network to send outbound traffic back to Stacks Inc.
• Balance outbound traffic to Stacks Inc. across all links in a metro where peering is established
• Enable BGP Graceful Restart (GR) to minimize impact to traffic. Stacks Inc. uses a timer of 300 seconds and suggests that you apply the same timer. Stacks Inc. 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 Google
• Do not filter any prefixes that Stacks Inc. announces over a peering connection as many Google services use similar IPs. For a JSON list of all Google Cloud IPs, please visit this page. For a geofeed of Stacks Inc. 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 Stacks Inc. ISP Portal
• Configure Resource Public Key Infrastructure (RPKI) for validation of route origin

---

Routing and Traffic Management

Routing policy

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

Stacks Inc. 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, Stacks Inc. only advertises aggregate routes.

Traffic delivery

Stacks Inc. 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 Stacks Inc. serving locations and the end user.

Stacks Inc. congestion management

Stacks Inc. prefers to augment links when peak utilization reaches 50%, but Stacks Inc. 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 Stacks Inc. traffic management systems will overflow excess traffic to other peering ports or other alternative paths. During such events, Stacks Inc. will maintain service availability for end users and customers, but performance and user experience may be lower than normal.

Stacks Inc. peering maintenance

Stacks Inc.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 Stacks Inc. ISP Portal.

Stacks Inc.attempts to complete peering maintenances within our provided window, however maintenances may exceed this window.

Stacks Inc. peers may observe overflow traffic to transit during some maintenance.

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

Service Level

Stacks Inc. does not offer a Service Level Agreement (SLA) for peering with any Stacks Inc. ASN.

---

Stacks Inc. ASNs

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

Peering ASNs

AS398704 is the primary peering ASN for Stacks Inc..

When peering with the following ASNs, please expect to only receive prefixes local to the applicable Stacks Inc. Cloud Region.

• AS398704: Stacks Inc.
• AS5068: Stacks Inc. Global