MLPE allows participating networks to exchange BGP routes through a common route-server service, making it possible to exchange traffic directly over an Internet exchange rather than through intermediate transit providers. This can reduce transit costs, improve routing efficiency, and potentially lower latency.
If you’ve connected to an Internet Exchange Point (IXP) such as Equinix IX, DE-CIX, LINX, or AMS-IX, you’ve had to decide how you’ll exchange routes with the other networks on the fabric. There are two ways to do it: bilateral peering, where you build a BGP session directly with each network, and multilateral peering, where you peer with the exchange’s route servers and reach many networks at once.
Equinix calls its multilateral service MLPE (Multi-Lateral Peering Exchange). At most other exchanges, you’ll see it called route server peering. The concept is the same, and that’s what this post covers: how it works, where it helps, where it falls short, and how I’d use it.
What Is Multilateral Peering?
With bilateral peering, you contact each network, agree to peer, and configure a separate BGP session for every one of them. With 200 peers, that’s 200 sessions to build and maintain.
With multilateral peering, you build BGP sessions to the exchange’s route servers instead, usually two of them for redundancy, with separate IPv4 and IPv6 sessions, so typically four sessions in total. Through those sessions, you can exchange routes with other eligible route-server participants, subject to the exchange’s filters and each participant’s routing policies.
Bilateral peering (one session per peer):
[ Your Router ] <--- BGP ---> [ Peer A ]
[ Your Router ] <--- BGP ---> [ Peer B ]
[ Your Router ] <--- BGP ---> [ Peer C ]
... and so on for every peer
Multilateral peering (sessions to the route servers):
[ Your Router ] <--- BGP ---> [ Route Server 1 & 2 ] <--- BGP ---> [ Hundreds of peers ]
Data plane in both cases:
[ Your Router ] <=== traffic over the IX switch ===> [ Peer's Router ]
How Route Servers Work
The most common misconception is that traffic flows through the route server. It doesn’t.
- Control plane only: Your router exchanges route announcements with the route server, which passes them on to the other participants.
- Next hop is preserved: The route server keeps the original peer’s IX address as the BGP next hop. It also normally doesn’t add its own AS number to the AS path, so routes look as though they came directly from the peer.
- Traffic goes direct: When you send packets to a destination learned from the route server, they cross the IX switch straight to that peer’s router. The route server never touches the traffic.
Route Collectors Are Not Route Servers
Internet exchanges may also operate route collectors, which receive BGP route announcements for visibility, diagnostics, and routing analysis. A route collector is not an MLPE route server: it does not distribute your routes to other participants as a peering service, and it does not carry their production packets. The route server distributes eligible BGP routes, while the IX Ethernet switching fabric carries production traffic directly between participating routers. Both control-plane sessions and production traffic can use the same physical IX port, so a faulty optic on that port can cause packet loss even while the route-server BGP sessions remain established.
Why Use Multilateral Peering
1. Broad reach on day one
Once your route-server sessions are established and the necessary policies are in place, you can exchange routes with eligible participants using the service. On a large exchange, that can mean access to hundreds of networks without negotiating a bilateral session with each one.
2. Much less operational overhead
Bilateral peering means one session per peer: contacting each network, agreeing terms, configuring sessions and passwords, and tracking changes over time. That grows with every peer you add. Route server peering replaces most of that work with a handful of sessions.
3. Lower transit costs
Traffic exchanged over the IX doesn’t count toward your 95th-percentile usage on paid IP transit. How much you save depends on your traffic mix, which networks are on the exchange, and what you’re paying for transit. Remember to weigh that against the cost of the IX port, colocation space, and cross-connects.
4. Built-in route filtering
Most modern route servers apply route-validation policies that can include IRR records, RPKI, bogon filtering, prefix-length limits, and next-hop checks. That adds a valuable layer of protection, but the exact filters vary by exchange and do not replace your own inbound policy, maximum-prefix limits, or operational monitoring.
5. Control over who hears your routes
Route servers support action communities that control where your announcements go: don’t announce to a specific AS, announce only to specific ASes, and at some exchanges, prepend toward a specific AS. Many exchanges use large communities (RFC 8092) for this, since standard communities can’t hold 32-bit AS numbers. Check your exchange’s documentation for the exact values.
Controlling what you receive is done on your own router: filter or set local preference on routes learned from the route server just as you would with any other BGP neighbor.
Drawbacks and Risks
1. You may not see every path
When several peers announce the same prefix, a route server may pick one best path and send you only that one. You lose visibility of the alternatives and the ability to choose between them. Some route server implementations reduce this problem, but it’s the main reason route server peering offers less traffic-engineering control than bilateral sessions.
2. Data-plane failures can go undetected
This is the risk I think gets overlooked most often. Your BGP session is with the route server, not with the individual forwarding peer. If reachability to a specific peer’s next hop fails while both networks remain connected to the route server, your route-server session can stay established and the affected route may remain installed. A bilateral BGP session gives you a direct relationship to monitor, and BFD can improve detection where both sides support and configure it. Neither bilateral peering nor BFD guarantees instant detection of every possible data-plane problem.
3. Shared fate
If a route server has a bug or misconfiguration, it can affect routes from many peers at once. Exchanges reduce this risk by running redundant route servers, so peer with both where practical. If the route-server sessions fail and their routes are withdrawn, traffic can shift to alternate paths such as paid transit if those routes exist, routing policy selects them, and the remaining connections have sufficient capacity. Recovery is not necessarily instantaneous, and transit utilization may rise sharply.
4. Port capacity planning
Peering generally redistributes existing traffic between available paths; it does not, by itself, solve every capacity problem. Route-server peering can shift a substantial amount of traffic onto an IX port from many networks at once. Size the port for normal and failure-state demand and monitor it closely during rollout. To influence inbound traffic, use the exchange’s supported announcement communities and other appropriate policies. To influence outbound traffic, evaluate your own local preference, route filters, and best-path selection. Those controls are not interchangeable.
And don’t stop at the Internet edge. If the IX is 20G but all of that traffic eventually converges on an oversubscribed 10G aggregation link, firewall, or WAN connection, the underlying bottleneck remains. More external paths do not guarantee more usable end-to-end capacity.
5. Not every network uses route servers
Many networks prefer or require bilateral sessions, especially for high-volume traffic, and peering policies vary from open to selective. Some large content networks connect to route servers at many exchanges, while others don’t. If you need to peer with a specific network, check its PeeringDB record for its peering policy and route server participation.
6. The Hidden Cost: Operational Complexity
I’ve always believed in keeping enterprise networks as simple as possible. Not because simplicity means fewer technologies, but because a simpler network is generally easier to understand, operate, troubleshoot, and maintain.
MLPE can reduce the administrative burden of establishing individual BGP peering sessions. However, it can also introduce additional routing paths and operational dependencies that didn’t exist when traffic primarily traversed traditional Internet transit providers.
Consider troubleshooting an application experiencing intermittent packet loss. Previously, we might have needed to examine our two Internet providers and internal network. Now we also need to consider the Internet exchange fabric, participating peers, BGP route-server advertisements, next-hop reachability, and whether traffic is taking different inbound and outbound paths.
That complexity becomes a bigger problem when the entire network team doesn’t understand the design.
And this raises a fundamental architectural question: Are we gaining enough performance, reliability, or cost savings to justify the additional complexity?
If MLPE significantly reduces transit utilization, improves connectivity to important networks, or provides measurable performance benefits, it may be worth implementing.
But if the improvements are negligible, we’re potentially adding operational overhead without solving a meaningful problem.
My approach is simple: Start with the simplest architecture that satisfies the requirements. Introduce additional routing paths only when there is a measurable benefit, a documented operational model, and a team prepared to support them.
More connectivity doesn’t automatically mean better networking.
Bilateral Peering Is Not Necessarily Physical Redundancy
An important architectural distinction: bilateral peering and MLPE can use the same IX port, the same peering VLAN, and the same underlying switching fabric. Equinix explicitly supports bilateral and multilateral peering over the same IX connection.
If you establish a bilateral BGP session with a network already reachable through an IX route server, you may gain more routing-policy control and direct session visibility. But you have not automatically gained another physical path or another capacity domain. The actual packets may still cross the same shared IX infrastructure.
At a Glance
| Route Server (Multilateral) | Bilateral | |
|---|---|---|
| BGP sessions | A few (typically 2 route servers × IPv4/IPv6) | One per peer |
| Setup time | Fast: reach many networks at once | Slow: one negotiation and configuration per peer |
| Ongoing effort | Low | Grows with every peer |
| Paths visible | May be limited to the route server’s best path | Every path each peer sends you |
| Failure detection | Individual peer data-plane issues may go unnoticed | Direct session monitoring; BFD where supported |
| Announcement control | Route server action communities | Full per-peer policy |
| Best for | The “long tail” of small and mid-sized networks | Your highest-volume and most important peers |
Before You Start
For enterprises in particular, a few prerequisites:
- Public ASN and authorized prefixes. Use a public ASN and ensure you have authorization to originate the prefixes you advertise. Provider-assigned space may require the address holder’s authorization and appropriate IRR/RPKI records; check the exchange’s route-acceptance requirements.
- Presence at the exchange. A router in a facility where the IX is available, or a remote-peering connection, plus the port and cross-connect.
- Up-to-date IRR records and RPKI ROAs. Maintain accurate route objects and ROAs for the prefixes you originate. An RPKI-invalid announcement is not the same as an RPKI-unknown one; check the specific exchange’s acceptance policy.
- A PeeringDB record. Exchanges and peers use it to find you and check your details.
- Your own filters. Inbound prefix filtering and maximum-prefix limits on the route server sessions, even though the route server also filters.
Don’t Just Enable MLPE Because It’s Available
One thing I feel strongly about is that MLPE should never be treated as simply enabling a couple of BGP neighbors and updating a network diagram. Just because the service is available doesn’t mean the network is ready to use it.
Before introducing new Internet routing paths, I want a stable, consistent, reliable Internet routing foundation: healthy transit connections, predictable BGP policies, well-understood inbound and outbound traffic patterns, and working monitoring. If you’re already dealing with unexplained packet loss, asymmetric paths, unreliable transit, or congestion, adding MLPE without understanding those problems can make them harder to isolate.
That doesn’t mean the network has to be perfect. It means the current behavior must be understood, measured, and supportable before adding new variables.
The Entire Team Needs to Understand What, How, and Why
A network change should not be understood only by the engineer implementing it. Before production deployment, the entire network engineering and operations team should be able to explain:
- What we’re doing: Which IX services, peers, route servers, sessions, and advertised or received prefixes are changing.
- Why we’re doing it: Whether the goal is better reachability, measurable transit-cost reduction, path optimization, resiliency, or relief of a verified capacity constraint.
- How routing will change: The role of local preference, AS-path information, route filtering, communities, and the intended relationship among transit, bilateral peers, and MLPE.
- What happens during failure: How routes withdraw or reconverge, where traffic should move, whether alternate links have headroom, and how rollback works.
- How we’ll troubleshoot it: Where to find BGP routes and next hops, flow telemetry, peering information, interface counters, provider contacts, and the authoritative network diagram.
Management should understand the purpose, expected benefits, dependencies, operational risks, capacity assumptions, and planned rollout before approving the change. Management does not need to configure BGP, but it should understand what is being introduced and why the team is prepared to operate it.
Troubleshooting Changes After MLPE Goes Live
Imagine traffic to an application reached the Internet through paid transit yesterday. After enabling MLPE, the preferred path for that prefix now exits through an IX peer. Tomorrow, users report intermittent loss or increased latency. Is the issue with the transit provider, your local router, the IX fabric, the peer’s router, a policy change, or a downstream bottleneck?
A healthy BGP session to the route server doesn’t prove that every peer’s forwarding path is healthy. And running a traceroute from an unrelated network doesn’t necessarily test the IX path you care about. Engineers need to identify the actual forwarding next hop, validate the selected path from the relevant device, examine interface and flow data, and work with the exchange or peer using measurements taken at the correct points.
Every additional routing choice creates another possibility the entire support team must be prepared to investigate. That’s why the design and troubleshooting procedures should be shared before deployment, not reconstructed during an incident.
Baseline, Controlled Rollout, and Rollback
Before activation, record transit and IX utilization, top destination and peer ASNs, route counts, BGP best paths, next-hop behavior, latency, packet loss, and the utilization of downstream interfaces. Define acceptable changes and validate failure scenarios, including the return of IX traffic to transit when the exchange or route-server sessions become unavailable.
Bring up sessions with a controlled routing policy, verify advertisements and received routes, then introduce traffic deliberately. Observe the results, compare them with the baseline, and retain a tested rollback procedure. Established BGP sessions are not, by themselves, evidence of a successful implementation.
Evaluate Existing Peering Before Adding More
Before ordering another connection, evaluate the services already in place. For example, an enterprise connected to Equinix IX may already have access to both Equinix’s MLPE route servers and direct bilateral peering with networks present on that exchange.
Hurricane Electric (AS6939) is worth evaluating, but it’s important to identify which service is actually being proposed. Hurricane Electric operates a global backbone and offers Internet transit and direct peering. Equinix IX is an exchange platform; Hurricane Electric is a network that may be a peer or transit provider. They are not competing versions of the same product.
Hurricane Electric lists an open peering policy and participates at Equinix IX locations. Its published PeeringDB profile indicates “Never via route servers,” so don’t assume that enabling Equinix MLPE establishes peering with AS6939. Confirm bilateral eligibility, the relevant metro, and the actual peering or transit product with the provider.
What Are the Options?
| Option | What it provides | Key question |
|---|---|---|
| Equinix IX MLPE | Multilateral route exchange through IX route servers | Are existing IX port capacity and policy sufficient? |
| Hurricane Electric bilateral peering | Direct BGP peering with AS6939 over a shared IX or another agreed interconnect | Could we use an existing Equinix IX connection? |
| Hurricane Electric IP transit | Commercial transit providing broader Internet reachability under a service agreement | Does this add an independent transit path and measurable capacity? |
| DE-CIX, LINX, AMS-IX | Alternative IX ecosystems offering opportunities for route-server and bilateral peering | Do they offer useful peers, reachability, and diversity in our metros? |
| Private network interconnect (PNI) | Dedicated connectivity to a selected high-volume partner | Does the traffic justify its cost and dedicated infrastructure? |
Are We Actually Adding Something New?
If Hurricane Electric can peer with us over the Equinix IX infrastructure we already own, a new bilateral BGP session may provide more specific policy control without requiring a separate IX connection. Conversely, a separately provisioned Hurricane Electric transit service could provide a different type of reachability and potentially another physical path, depending on where and how it is delivered.
Neither case should be assumed to add resiliency or eliminate congestion. We need to examine traffic demand, available peers, routing changes, commercial costs, physical topology, shared failure domains, and downstream capacity.
Before approving a new service, I would ask: What specific problem are we solving, why can’t the existing connections address it, how much traffic will realistically move, and what does the entire forwarding path look like under normal and failure conditions?
My Recommendation: Use Both
For most networks, this isn’t an either-or choice. Here’s how I’d set it up:
- Use the route servers to reach the long tail of small and mid-sized networks with almost no effort.
- Build bilateral sessions with your top traffic partners, usually the handful of networks carrying most of your IX traffic. Consider BFD where both peers support it and the failure-detection requirements justify it.
- Prefer bilateral routes where appropriate using a deliberate local-preference policy so you control which path wins when both the route server and the bilateral peer advertise the same prefix. Don’t assume bilateral routes always need to win.
- Use flow data (NetFlow/IPFIX) to see which networks are actually sending you traffic over the IX. That shows you who’s worth a bilateral session.
A successful network design isn’t measured by how many BGP sessions or Internet connections we establish. It’s measured by how reliably the network operates, how predictably traffic flows, and how effectively the entire team can support it.