The case for automated peering
Peering is one of the fastest and most reliable ways to exchange traffic between networks, but the industry has never had a standard method for managing it at scale. Facebook’s traffic engineering team knows this pain firsthand: before building an automated system, every peering request required an engineer to manually verify emails, check dashboards and rulebooks, review PeeringDB records, configure BGP sessions, and reply to the peer. Requests trickled in through email and other out-of-band channels, with no centralized view of status. Each one needed hand-verification and a tool launched manually, and the whole process consumed more than nine hours per week.
That manual process is error-prone and slow, and it only gets worse as a network connects to more internet exchanges (IX) and adds routers at each one. To solve this, Facebook built an automated system that lets peers request and manage their own public peering sessions through facebook.com/peering.
How the automation works
When a user clicks a video on Facebook, the request can take one of two paths. The first goes over transit networks — a chain of intermediate providers that may be interconnected in suboptimal locations with capacity constraints, adding latency and risking buffering. The second is a direct peering session, where Facebook’s routers exchange BGP routes with the user’s ISP at a common internet exchange point. That route is faster, more reliable, and produces a better user experience.
The key to automating the setup of those direct sessions is authentication. Facebook chose to use PeeringDB’s OAuth service rather than building its own login system. PeeringDB is an open-source, volunteer-run database of network peering information, and most networks already maintain their records there as a source of truth. The OAuth service lets a requester authenticate with their PeeringDB login on behalf of their network’s organization, with no separate Facebook account required.
Once authenticated, the peer sees a list of their network’s existing public peering sessions with Facebook and can submit new requests. Behind the scenes, the request is sent to an auditing queue. If it is approved, a workflow takes over and:
- Queries PeeringDB and internal tables to validate and collect mutual peering information, such as IP addresses and max-prefix settings.
- Configures the BGP sessions on Facebook’s routers.
- Emails the peer to confirm that Facebook’s side is ready and waiting.
- Checks daily for the sessions to be established, sending reminder emails on days two, three, seven, and 13.
- Sends a final confirmation email once all sessions are up, at which point they appear as active in the peering page table.
The process also includes monitoring for the peering@ mailbox. When the system detects a peering request in the inbox, it automatically replies with instructions to use the self-service page. Human engineers still handle nonpeering inquiries, but the time spent parsing and verifying requests has dropped dramatically.
A proposed industry standard
Since launching the system, Facebook has received more than 170 peering requests and approved 149 of them. Those approvals have automatically pushed over 1,400 public peering sessions, saving more than eight hours per week compared to the manual process.
The peering automation work started with a focus on public peering at IXPs, but the same challenges exist for private network interconnects (PNIs), which carry larger traffic volumes. Facebook is now investigating ways to automate PNI provisioning, with the goal of offering a self-service option later this year. The team is also exploring the use of PeeringDB OAuth as an alternative login service for other partner-facing tools.
The takeaway from this effort is straightforward: PeeringDB OAuth provides a standardized way to validate peering request submissions, and it could serve as the basis for authentication across the industry. Wider adoption of that approach would make automated peering management the norm rather than the exception.
