BGP Route Server Design: RFC 7947 Transparent Peering

An internet exchange route server is not a router and not a route reflector - it is a control-plane-only redistribution point that lets hundreds of members peer with each other without a full mesh of sessions. The distinguishing feature is transparency: the route server must not prepend its own AS number or rewrite the next hop, so members see the authentic path from the origin. Getting this wrong turns the exchange into an accidental transit AS. This guide covers the RFC 7947 requirements, the client-side settings they force, and the path-hiding problem that route servers create.

What a Route Server Is For

At an exchange point with 300 members, a bilateral full mesh would need tens of thousands of sessions. A route server collapses that to one session per member and redistributes the received routes to the others according to policy. It never forwards data-plane traffic - packets between members flow directly across the exchange fabric, and the route server is only ever consulted for the control plane.

Requirement 1: Do Not Modify AS_PATH

An ordinary BGP speaker prepends its own AS number before advertising. RFC 7947 explicitly says the route server SHOULD NOT prepend its AS, because doing so would make the exchange appear as a hop in the path and distort members' best-path decisions. The route server's own ASN must never appear in the AS_PATH a member receives.

Requirement 2: Preserve NEXT_HOP

The next hop must remain the originating member's router on the exchange fabric. If the route server rewrote the next hop to itself, member data traffic would be attracted to the route server, which does not forward packets - an immediate black hole.

Requirement 3: Clients Must Disable the First-AS Check

Standard BGP rejects an UPDATE whose leftmost AS is not the sending neighbour's AS number. A route server client will therefore see the originator's AS first, not the route server's, and must keep the session up anyway. RFC 7947 requires implementations to allow this check to be disabled, and preferably per peer.

# FRR on the member router - must be per-neighbor
router bgp 64501
 neighbor 198.51.100.1 remote-as 65530
 no neighbor 198.51.100.1 enforce-first-as

# BIRD equivalent
protocol bgp rs {
    neighbor 198.51.100.1 as 65530;
    enforce first as off;
}

The global command alone is not sufficient on some FRR releases; the per-neighbour form is what actually works.

Path Hiding: The Real Downside

Because a route server performs best-path selection before distributing, a member that filters the best path with its own policy may receive nothing at all for that prefix, even though a second-best path exists that it would have accepted. Two mitigations are standard: per-client best path (the route server computes a separate best path for each client after applying that client's import policy) and BGP Additional Paths, which lets multiple candidate paths be advertised so the client runs its own selection.

Policy and Hygiene

# Route server role marking (RFC 9234) and origin validation
rpki
roa 0.0.0.0/0 max 24
bgp origin-validation

# Prefix limits per member
neighbor 198.51.100.2 maximum-prefix 50000

Reject announcements whose next hop is not the member's own session address, enforce a prefix limit per member, and apply RPKI origin validation on import. This blocks the two most common exchange incidents: accidental transit announcements and prefix hijacks. For the internal equivalent of redistribution at scale, route reflector cluster ID configuration covers the RR path attributes, while confederation vs route reflector explains when a confederation is a better fit. Both arrangements use ORIGINATOR_ID and CLUSTER_LIST for loop prevention, which the route server deliberately does not.

Verification in Production

show bgp summary
show bgp neighbor 198.51.100.2
show bgp ipv4 unicast 203.0.113.0/24
# Confirm no route-server ASN appears in any received path
show bgp ipv4 unicast regexp 65530

An empty result for the route server's own ASN across the received table is the single best proof that transparency is configured correctly.

原文链接：https://datatracker.ietf.org/doc/html/rfc7947.html