You are browsing a read-only backup copy of Wikitech. The primary site can be found at

Peering management

From Wikitech-static
Revision as of 14:56, 3 October 2022 by imported>Ayounsi
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Peering management is something with still a large manual process. This is mostly due to communication (for new, changes, or issues) happening over emails.

Finding peering candidates

peering@ email alias

The easy one, as we usually accept all peering requests.

Equinix peering opportunities portal

Using their own flow data, Equinix brings to light networks we peer with at some of the Equinix IXPs, but where sessions are missing from other IXPs.

Eg We peer with AS X at Equinix Ashburn, and both Wikimedia and X are present at Equinix Chicago but we don't have any BGP session yet.


See also Netflow allows to filter/sort through all our external traffic on BGP criteria.

For example sorts outbound drmrs traffic by AS_PATH (with the first 2 AS the traffic is going to transit through), and the final AS (the final AS of the path).

This can help reveal networks (ASNs) that we currently reach through our transit peers. This needs to be used with PeeringDB to identify those peers' IX presences.


This is the most comprehensive list of networks present at a given IXP, and thus candidates networks.

IX mailing lists

New IXP members will be announced on the IXP mailing list

Peering workflow

This workflow is quite flexible as peers behaviors varies greatly.

Setting up new sessions


Blue: via cookbooks, yellow: manual.


  • Even though we prefer to not use any MD5 key, some peers require it, this need to be manually added after running the configure cookbook
  • If the peer's ETA is long in the future, wait to be close to the date to configure our side to limit the risk of alerting/log noise.

Managing down sessions

File:Peering down diagram.png


Possible improvements

  • Automate extensively the peering candidate search by joining PeeringDB data, Hive/netflow, the list of current peers (from the routers), and a manual list of exceptions.
    • An even more advanced version could show the benefits of extending our peering to new IXPs based on the peer's list
  • Automate the "BGP sessions down" workflow