Summary

  • RFC 7947 deliberately separates an IXP route server's control-plane role from the forwarding path. It normally preserves the original AS_PATH and must preserve NEXT_HOP because packets should travel directly between participants, not through the broker.
  • A route-server client consequently receives an UPDATE whose BGP speaker may be absent from the left edge of AS_PATH and whose session address is not the forwarding next hop. The necessary first-AS exception must be limited to verified route-server peers, while independent import and loop policy remain in force.
  • Safe operation requires a joined evidence chain: announcing-client input, route-server validation, per-client selected view, transparent Adj-RIB-Out, client Adj-RIB-In, next-hop-to-MAC resolution, FIB installation and packets. An Established session, a clean path or a healthy second server cannot substitute for that chain.

A route that contradicted the usual eBGP story

Consider a synthetic exchange fabric using documentation-only addresses and ASNs. Participant A announces a canary prefix to two route servers. Participant B has an established eBGP session to each broker. One UPDATE reaches B with A's ASN at the left edge of AS_PATH and A's peering-LAN address in NEXT_HOP. The route-server ASN appears in neither place.

B's generic external-neighbor configuration enforces the familiar rule that the first AS in a received path should equal the peer's AS. The canary is rejected. An engineer disables that check for the verified route-server neighbor only. The route enters B's Adj-RIB-In, wins local selection and installs A's address as its forwarding next hop. Neighbor discovery resolves A's router directly. A packet crosses the exchange switch from B to A without visiting the route server.

The second route-server session is also Established, but the canary is absent. Its master table contains a path from A. A client-specific export rule, or a best-path calculation performed before that rule, has prevented this version from reaching B. The two green sessions therefore describe transport availability, not equivalent reachability.

This example is not a production incident. It isolates the mechanism that makes route servers useful and dangerous to misunderstand. In ordinary eBGP, session peer, path edge and often next hop appear to reinforce one another. At a route server they are deliberately pulled apart.

The broker is neither a router nor a collector

An Internet exchange gives multiple autonomous systems a shared Layer 2 meeting place. Bilateral peering can require a growing mesh of BGP sessions as the participant count rises. A route server reduces that administrative burden: each client can announce reachability to the broker and receive routes from many other clients over one or a small number of sessions.

RFC 7947 uses “route server” for this multilateral interconnection function. The term is sometimes applied to a system that collects feeds for observation, but a collector has a different purpose. It records routes for analysis. An IXP route server takes part in the live distribution of reachability and may apply policy on behalf of individual clients.

Nor is it an ordinary forwarding router. It speaks BGP, owns RIBs and makes distribution choices, yet packets for the advertised destinations are expected to move directly among participants across the exchange fabric. Its authority is real, but it is not the authority of a transit hop.

That distinction answers a deceptively important question: what is AS_PATH supposed to record? It describes the autonomous-system path associated with reachability and supports selection, policy and loop detection. It is not an attendance list of every process that inspected or relayed the UPDATE. Inserting the route server merely because it spoke the session would make the forwarding history less accurate and could change the receiving client's decision.

Transparency is an active constraint

RFC 4271's ordinary external advertisement procedure prepends the advertising speaker's AS. RFC 7947 recommends a different default for route servers: do not prepend the route-server AS and do not otherwise modify AS_PATH unless explicitly configured. The exception exists because the route server is not forwarding the traffic and because an extra AS can affect policy or path selection.

The same logic is stronger for NEXT_HOP. RFC 7947 requires the route server to pass it unmodified. If A announced a prefix, B should forward to A's peering-LAN router, not to the control-plane broker. Rewriting NEXT_HOP to the route server would either attract traffic to a machine not designed to forward it or force the exchange to build a different service.

The recommendation extends beyond those two attributes. Route servers should normally preserve well-known and optional attributes unless local exchange policy calls for processing. Attribute transparency protects participants from accidental policy changes inside the broker.

But “transparent” does not mean passive. A window is passive; a route server is a policy engine. It can reject A's prefix, select one of several paths, interpret a distribution community, construct a view specifically for B and decide what to send. Its effect may be absent from AS_PATH while remaining decisive for reachability.

The proper evidence model therefore has two ledgers. The route carries forwarding attributes. The route server keeps operational evidence of the brokerage: session, input, validation, selected candidate, client policy and output. Trying to make either ledger stand in for the other produces false history.

The first-AS exception is a scoped trust decision

An ordinary eBGP receiver often checks whether the leftmost AS equals the neighbor's AS. This detects several classes of error and helps an operator notice that the path presented on the session does not fit the expected relationship. A transparent route server intentionally breaks that equality.

RFC 7947 consequently requires route-server client implementations to allow the check to be disabled and recommends doing so per peer. The scope is the safeguard. A verified exchange route-server session needs the exception; a transit or bilateral peer usually does not.

A global “no enforce first AS” configuration profile turns one bounded protocol adaptation into a network-wide loss of evidence. A copied configuration can silently weaken every new external relationship. Conversely, retaining the generic check on the route-server peer makes the session look healthy while discarding all useful routes.

Disabling first-AS consistency does not mean accepting any path. The receiving client still needs independent import filters, maximum-prefix controls, origin and route validation appropriate to its policy, and ordinary detection of its own ASN in AS_PATH. It should also know which route-server ASN, addresses and exchange fabric it has authorized. A route server concentrates distribution; it does not inherit the client's final decision.

This is the difference between delegating a function and surrendering authority. The exchange broker can create a candidate view. The participant remains responsible for deciding whether that view is safe to install.

Path hiding: when one best path is not each client's best path

Per-client distribution is one reason route servers are valuable. A participant may want a prefix advertised to most clients but withheld from a particular network. Standard or Large Communities, routing-registry policy or an exchange portal can express that preference. The route server turns it into export policy.

The order of operations matters. Suppose the route server receives two paths to a prefix. Its common decision process selects A's path. B's client policy then excludes A. If the implementation simply removes the selected route at export, B receives nothing even though the other path would have been acceptable. RFC 7947 calls this path hiding.

The failure is subtle because no invalid route needs to appear. The broker's internal best path is legitimate, the per-client filter is legitimate and the empty output follows mechanically. What is wrong is treating one global choice as if it represented every client's policy perspective.

One portable mitigation is a separate selected view for each client, with filtering applied before the client-specific best-path decision. Implementations can optimize common state while preserving those distinct outcomes. FRRouting currently documents a per-client Loc-RIB model for route-server clients. Other designs may send multiple candidates using diverse-path techniques or ADD-PATH. RFC 7947 recommends that ADD-PATH be send-only from the route server toward clients so the broker does not accept a client's inactive or inappropriate alternatives as new distribution input.

No feature name proves the result. “Secondary”, “per-client RIB” or “ADD-PATH enabled” is configuration evidence. The decisive test asks whether, for each recipient, an acceptable alternative is advertised when the globally preferred path is excluded.

Preserving NEXT_HOP creates a new validation burden

Third-party NEXT_HOP is necessary to keep packets off the route server. It also creates a tempting abuse surface. A mistaken or malicious participant can announce its own prefix while naming another participant's peering-LAN router. If the route server redistributes that path, many clients may direct traffic toward the named router.

The receiving clients cannot easily reconstruct who was authorized to name which next hop after many participants' routes have been aggregated over one session. RFC 7948 therefore places an important check at the broker: the NEXT_HOP on a received route should match the announcing client's interface address, and a cross-AS mismatch should be dropped. A same-AS exception can support one organization using several routers on the fabric.

Current IXP Manager documentation shows this as a concrete ingress control alongside path, prefix, IRR and RPKI checks. That is useful deployment evidence, not a universal guarantee. A participant must still verify the exchange's published rules and observed behavior.

The control also has a boundary. It proves authorization at ingress, not Layer 2 availability at forwarding time. The correct A address can stop answering neighbor discovery. A switch fault can create non-transitive connectivity where B reaches the route server and the route server reaches A, but B cannot reach A. Both BGP sessions remain green while packets fail.

For this reason the route-server health check and the participant-to-participant fabric check must be separate. Pinging only the broker tests the wrong path.

Redundancy is equality of service, not equality of boxes

RFC 7948 recommends multiple route servers on an exchange fabric. Two systems reduce dependence on one process, host or implementation. Some IXPs deliberately diversify routing software as well.

Yet availability can diverge from equivalence. Both servers can accept B's sessions while using different policy generations, registry snapshots, RPKI state, software behavior or per-client best-path results. Prefix counts can match while attributes differ. A single prefix can be present on one and absent on the other.

The strongest comparison operates at the service boundary: for a canary set and then the broader table, compare the exact client-visible NLRI, AS_PATH, NEXT_HOP, MED, communities and relevant validation markers from both servers. Explain every expected difference. A policy rollout should include a generation identifier or other auditable link between configuration intent and each running instance.

Implementation diversity is valuable when it prevents one defect from taking down both brokers. It is dangerous when “diverse” becomes an excuse for unexplained output. Independence improves resilience only when the contract of equivalent reachability remains testable.

The evidence chain must cross four authorities

No single screen can prove a route-server outcome. The useful chain is sequential:

Record What it can establish What it cannot establish alone
A's Adj-RIB-Out or packet capture What the announcing participant attempted to send Whether the route server accepted or redistributed it
Route-server Adj-RIB-In and validation log What the broker received and how ingress checks classified it Which path a particular client was offered
Per-client selected view and policy generation Which candidate survived for B under a named policy Whether the UPDATE crossed the BGP session
Route-server Adj-RIB-Out Exact transparent attributes offered to B Whether B accepted or selected them
B's Adj-RIB-In The route and attributes B actually received Whether it won local selection or entered the FIB
B's selected RIB and FIB The chosen route and programmed next hop Whether the fabric can deliver packets to that next hop
Neighbor/MAC state and packet evidence Direct Layer 2 resolution and actual traffic path The policy reasoning that produced the route

Timestamps and identity matter throughout. A snapshot taken after convergence cannot explain the order that caused a transient withdrawal. A master route-server table is not the same as B's view. A public looking glass may expose a useful selected path while hiding rejected candidates and policy inputs.

The chain also clarifies accountability. A owns the truthfulness of its announcement. The route-server operator owns ingress validation and faithful execution of the per-client distribution contract. B owns its import decision. The exchange operator owns the shared fabric service. None can erase its part by pointing to the other three.

A migration that tests the contradiction directly

Adding a route-server session should begin with a deliberately small acceptance surface.

First, identify the server from the exchange's authoritative configuration: ASN, addresses, AFI/SAFI, authentication if used, supported capabilities and policy-community contract. Scope the first-AS exception to those neighbor objects only. Keep ordinary loop, prefix and import controls active.

Second, advertise a documentation-safe canary through one participant. Record the announcer's exact path and next hop. On each route server, verify ingress validation, the recipient-specific view and Adj-RIB-Out. On the recipient, verify that the leftmost AS is the announcer, the next hop is the announcer's fabric address and the route-server AS has not been inserted merely to satisfy ordinary eBGP appearance.

Third, exercise policy rather than only the happy path. Permit the canary to B and deny it to C. Reverse the choice. Create two candidate paths so that the preferred one is denied to B and confirm an acceptable alternative is not hidden. Send an unauthorized cross-AS next hop and require rejection. Test IPv4 and IPv6 independently.

Fourth, test the data plane. Resolve the participant's next-hop MAC from the receiving router. Trace or capture the canary packets and prove that they cross directly between participants. Introduce a lab Layer 2 failure that leaves the BGP session alive and ensure monitoring distinguishes fabric reachability from broker reachability.

Finally, compare both route servers. Do not move from canary to broad import until exact unexpected differences are zero or explained. Rollback must restore the previous neighbor policy and cause learned routes to be re-evaluated or withdrawn; removing a line of configuration is not proof that stale paths disappeared.

Sources and limits

The protocol basis is RFC 7947, read with the base BGP behavior in RFC 4271. Operational risks and recommendations come from RFC 7948. The path-hiding alternatives reference RFC 7911 and RFC 6774.

Current implementation evidence comes from FRRouting's BGP route-server documentation, the BIRD protocol guide and IXP Manager's route-server documentation. Deployment examples come from first-party AMS-IX and LINX pages.

These sources define standards, software behavior and published operating intent. They do not prove the live state of an unnamed exchange, and the opening scenario is synthetic. Runtime compliance needs the records described above.