Visual RFC.
ALL RFCs / RFC 4456
Read the RFC ↗
RFC 4456 / ROUTE REFLECTION

Replace a full mesh of internal sessions

01

A route reflector changes how internal routers distribute routing information, without becoming every packet’s next hop.

RFC 4456 · § 4EXAMPLE
4 / 4
Replace a full mesh of internal sessionsTwo six-router graphs compare all fifteen pairwise mesh sessions with five sessions in a single-RR star whose other five routers are clients. Redundancy and non-clients are explicitly excluded.Reduce the IBGP control-session meshR0R1R2R3R4R5RRC1C2C3C4C5Full mesh:15One RR + five clients:5Six routers in each chosen comparisonRedundant/non-client sessions are excludedRFC4456 · chapter 1 · state 4 · offline examples
04
Scale the chosen single cluster

All five non-RR routers in this chosen comparison are clients; redundancy/non-clients are not counted here.

Source for this drawing: RFC 4456 · Read RFC section 4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Fewer control sessions do not imply a new data-forwarding path.

  • BGP, the Border Gateway Protocol, exchanges information about routes to network prefixes. An autonomous system (AS) is a network under a common routing administration. IBGP is BGP between routers inside the same AS; EBGP is between ASes. A BGP session is a control connection, not a physical cable or the path taken by user packets (§§1,4).
  • Ordinary IBGP does not redistribute an IBGP-learned route to other internal peers. A full mesh therefore connects every pair of internal speakers. With n speakers, it has n(n−1)/2 distinct sessions: three speakers need three; a chosen six-speaker mesh needs fifteen (§1; RFC 4271 §9.2).
  • RFC 4456 permits a route reflector (RR) to advertise selected IBGP-learned routes to designated peers. In the three-router example, C reflects between clients A and B, allowing the A–B session to be omitted. The picture removes that session, not an underlying network link (§4).
  • A chosen single-RR cluster with six routers, all five other routers configured as clients, uses five RR-to-client sessions instead of fifteen mesh sessions. This is an illustrative topology, not the session count of every deployment. Redundancy, non-client peering and additional clusters change the count (§§5–7).
  • Reflection distributes route information. It does not force user packets to pass through the RR, change the AS number, create bandwidth, or guarantee the same path selection as a full mesh. NEXT_HOP and topology concerns are examined later (§§3,10–11).
DETAILS

Fictional offline routing examples. Lines show BGP control sessions or route advertisements, not user-packet forwarding paths. Helpers model selected reflection and attribute rules; they do not implement a BGP daemon, TCP session, full decision process or production configuration.

Read the RFC section ↗

All chapters in RFC 4456

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗