BGP Route Reflector Design: The Rules, the Clusters, and the Paths Your Clients Never See

iBGP has a rule that makes it scale badly: a router does not re-advertise a prefix learned from one internal peer to another internal peer. That rule exists because iBGP has no loop-prevention attribute of its own — AS_PATH does not change inside an autonomous system, so a prefix passed from router to router internally would circulate forever. The workaround the original specification chose was a full mesh, where every iBGP speaker peers with every other. Twenty routers means 190 sessions. Fifty means 1,225. The configuration burden is bad and the operational burden is worse, because adding one router means touching every other router in the domain.

Route reflection solves it by designating some routers as reflectors that are permitted to break the re-advertisement rule, and replacing the missing loop prevention with two new attributes. ORIGINATOR_ID records which router first injected the prefix into iBGP, and a router that sees its own router ID there discards the update. CLUSTER_LIST records each reflection cluster the update has traversed, and a reflector that sees its own cluster ID discards it. Both are optional non-transitive, so neither leaves the autonomous system. With those in place, a reflector can safely do what an ordinary iBGP speaker must not.

This article covers reflection from the rules to the designs that fail. Section one establishes why the full mesh exists and what the alternatives are. Section two gives the three reflection rules precisely and shows how the loop-prevention attributes work. Section three covers cluster design, redundancy, and the cluster-ID decision that most deployments get wrong by accident. Section four covers path hiding — the fact that a reflector advertises only its own best path, which removes path diversity from the entire domain — and the Add-Path mechanism that restores it. Section five is the failure catalogue.

Why Does iBGP Need a Full Mesh, and What Breaks It?

What is the underlying rule?

A BGP speaker does not advertise a prefix learned from an internal peer to another internal peer. AS_PATH is BGP's loop-prevention mechanism and it does not change within an autonomous system, so an internally propagated prefix carries no record of the routers it has already visited and would circulate indefinitely. The specification's answer was to require that every iBGP speaker peer directly with every other, so one hop is always sufficient. That produces n(n−1)/2 sessions, which is workable at ten routers, painful at thirty, and unmanageable beyond that — not because of the session count itself but because every addition requires configuration on every existing router.

A Deeper Dive into the Scaling Problem

What the full mesh actually costs

The memory and CPU cost per session is modest on modern hardware; the operational cost is what makes the mesh untenable. Every router addition is a change on every existing router, which means a maintenance window touching the entire control plane to add one device.

The two solutions and why one won

RFC 4456 defines route reflection: designate some routers as reflectors permitted to re-advertise between internal peers, and add two attributes to prevent the loops the mesh previously prevented structurally. RFC 5065 defines confederations: subdivide the autonomous system into sub-autonomous systems that use eBGP between them, so AS_PATH loop prevention works internally while the confederation presents a single AS externally. Both work. Reflection won in practice because it requires configuration on the reflectors only, while a confederation requires re-numbering every router into a sub-AS and changes the meaning of eBGP-versus-iBGP for every policy in the network.

The minimum configuration

Reflection is configured entirely on the reflector. A client is an ordinary iBGP speaker and needs no knowledge that it is a client — it peers with the reflector exactly as it would with any internal peer. That asymmetry is the feature: converting a full mesh to reflection touches only the routers becoming reflectors.

! ===== ON THE REFLECTOR ONLY =====
router bgp 65000
 bgp router-id 10.0.0.9
 ! Cluster ID defaults to the router ID; state it explicitly
 bgp cluster-id 10.0.0.9
 neighbor CLIENTS peer-group
 neighbor CLIENTS remote-as 65000
 neighbor CLIENTS update-source Loopback0
 neighbor 10.0.0.1 peer-group CLIENTS
 neighbor 10.0.0.2 peer-group CLIENTS
 neighbor 10.0.0.3 peer-group CLIENTS
 !
 address-family ipv4 unicast
  neighbor CLIENTS activate
  neighbor CLIENTS route-reflector-client
  ! Reflectors do not rewrite next hop by default - see section 5
  neighbor CLIENTS next-hop-self all
 exit-address-family
!
! ===== ON A CLIENT: an ordinary iBGP peering =====
router bgp 65000
 neighbor 10.0.0.9 remote-as 65000
 neighbor 10.0.0.9 update-source Loopback0
 address-family ipv4 unicast
  neighbor 10.0.0.9 activate
 exit-address-family

How Does a Route Reflector Decide What to Reflect?

What are the three rules?

A prefix received from a client is reflected to every other client, to every non-client, and to eBGP peers. A prefix received from a non-client is reflected to clients only — the reflector assumes non-clients are fully meshed with each other and therefore already have it. A prefix received from an eBGP peer is sent to clients and non-clients alike, exactly as an ordinary iBGP speaker would. Those three rules follow from one assumption: clients peer only with the reflector, while non-clients maintain a full mesh among themselves.

A Deeper Dive into the Rules and Loop Prevention

The rules restated as a table

The second row is the one that produces surprises. If the non-clients are not fully meshed — a common state after a partial migration — then a prefix from one non-client never reaches the others, and connectivity is missing in a way that no reflector configuration explains. The reflector is behaving correctly against an assumption that is no longer true.

ORIGINATOR_ID and CLUSTER_LIST in operation

When a reflector reflects a prefix, it sets ORIGINATOR_ID to the router ID of the iBGP peer that originated the update — and does not overwrite it if one is already present. It also prepends its own cluster ID to CLUSTER_LIST. On receipt, a router discards any update whose ORIGINATOR_ID matches its own router ID, and a reflector discards any update whose CLUSTER_LIST already contains its own cluster ID. Together those two checks make loops impossible without any change to AS_PATH.

C1# show ip bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 42
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65001
    10.0.0.1 (metric 20) from 10.0.0.9 (10.0.0.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
      rx pathid: 0, tx pathid: 0x0
! 'from 10.0.0.9' is the reflector that sent it.
! 'Originator: 10.0.0.1' is the client that injected it.
! 'Cluster list: 10.0.0.9' records the reflection.

The effect on best-path selection

Two steps of the decision process change under reflection. At step 11, where the lowest BGP router ID normally breaks a tie, the ORIGINATOR_ID is used instead when present — so the tie is broken by the router that originated the prefix rather than the reflector that forwarded it. Step 12 then compares CLUSTER_LIST length, preferring the path that traversed fewer reflection layers. Both are tiebreakers reached only when everything above them is equal, but in a symmetric reflected topology that is a common situation.

! Two reflectors, two copies of the same prefix on a client
C1# show ip bgp 203.0.113.0/24
Paths: (2 available, best #2, table default)
  65001
    10.0.0.1 (metric 30) from 10.0.0.10 (10.0.0.10)
      Origin IGP, localpref 100, valid, internal
      Originator: 10.0.0.1, Cluster list: 10.0.0.10
  65001
    10.0.0.1 (metric 20) from 10.0.0.9 (10.0.0.9)
      Origin IGP, localpref 100, valid, internal, best
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
! ^ Same originator, equal cluster list length. Step 8 decided:
!   IGP metric 20 to 10.0.0.1 via one RR beats 30 via the other.

Hierarchical reflection

A reflector can itself be a client of another reflector. That builds a hierarchy where a core cluster serves regional reflectors, each of which serves its own clients — the standard design for a network too large for one cluster. CLUSTER_LIST grows by one entry at each level, and step 12 therefore prefers paths that stayed within fewer levels. The main constraint is that the layers must not form a loop in the reflection topology, which the cluster-ID check enforces but which is better avoided by design.

! ===== Regional RR: client of the core RR, reflector for its own POD
router bgp 65000
 bgp router-id 10.0.1.9
 bgp cluster-id 10.0.1.9
 !
 ! Peering up to the core reflector as an ordinary client
 neighbor 10.0.0.9 remote-as 65000
 neighbor 10.0.0.9 update-source Loopback0
 !
 ! Reflecting down to POD members
 neighbor POD peer-group
 neighbor POD remote-as 65000
 neighbor POD update-source Loopback0
 neighbor 10.0.1.1 peer-group POD
 neighbor 10.0.1.2 peer-group POD
 !
 address-family ipv4 unicast
  neighbor 10.0.0.9 activate
  neighbor POD activate
  neighbor POD route-reflector-client
  neighbor POD next-hop-self all
 exit-address-family

How Do I Design Clusters and Redundancy?

What is a cluster and how should redundant reflectors be configured?

A cluster is a reflector together with its clients, identified by a cluster ID that defaults to the reflector's router ID. When two reflectors serve the same clients for redundancy, there are two possible configurations. Leaving the cluster IDs at their defaults gives each reflector its own, so clients receive two distinct copies of every prefix and retain path diversity between the reflectors. Configuring both reflectors with the same cluster ID makes them one logical cluster, which reduces the number of paths each client stores but means each reflector discards updates the other has already reflected. The default — different cluster IDs — is the safer choice for most networks.

A Deeper Dive into Cluster Design

The two redundancy models compared

! ===== RR-1 and RR-2, DIFFERENT cluster IDs (recommended) =====
! RR-1
router bgp 65000
 bgp router-id 10.0.0.9
 bgp cluster-id 10.0.0.9
 neighbor 10.0.0.10 remote-as 65000
 ! The two reflectors peer with each other as non-clients
!
! RR-2
router bgp 65000
 bgp router-id 10.0.0.10
 bgp cluster-id 10.0.0.10
 neighbor 10.0.0.9 remote-as 65000
!
! Result on a client: two paths, one per reflector
C1# show ip bgp 203.0.113.0/24 | include Cluster
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
      Originator: 10.0.0.1, Cluster list: 10.0.0.10

Where to place reflectors in the topology

A reflector advertises only its own best path, and its best path is chosen partly by its own IGP metric to each next hop. That makes the reflector's topological position a global input: a reflector sitting in one data centre will prefer exits near that data centre and will impose that preference on every client, including clients on the other side of the network for whom a different exit is closer. Placing reflectors at topologically central points — or one per region, in a hierarchy — keeps the reflector's view close to its clients' views.

! Symptom of a badly placed reflector: clients using a distant exit
C-REMOTE# show ip bgp 0.0.0.0/0
  65001
    10.0.0.1 (metric 140) from 10.0.0.9 (10.0.0.9)
      Origin IGP, localpref 100, valid, internal, best
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
! ^ IGP metric 140 from this client to the chosen exit, while a
!   nearer exit at metric 20 exists. The RR chose using ITS metrics.
!
! Confirm the reflector's own view differs from the client's
RR-1# show ip bgp 0.0.0.0/0 | include metric
    10.0.0.1 (metric 20) from 10.0.0.1 (10.0.0.1)

Dedicated reflectors that do not forward

A reflector participates only in the control plane; it does not need to be in the forwarding path for the prefixes it reflects. That makes a dedicated route reflector — a device or virtual machine with substantial memory and CPU but no traffic-forwarding role — an attractive design. It removes the coupling between control-plane scale and forwarding capacity, and it lets the reflector be placed for topological centrality rather than for where traffic needs to go. The requirement is that the reflector's own next-hop resolution stays sane, which usually means next-hop-self all is not appropriate on such a device, since it is not a valid forwarding next hop.

Migrating a full mesh to reflection without an outage

The migration is safe because reflection and a full mesh coexist. A router that is both a reflector client and fully meshed simply receives duplicate copies of every prefix, chooses one, and behaves identically. That means the two states overlap rather than cut over, and the sequence has no moment where connectivity depends on both halves being complete.

Deploy the reflectors first and peer every existing router to both of them, leaving the mesh untouched. Verify that every prefix is present via a reflector path by checking for the Cluster list attribute. Then remove the mesh sessions router by router, verifying prefix counts after each. The only irreversible step is the last mesh session, and by then every prefix has been arriving via the reflectors for however long you chose to soak it.

! Phase 1 - reflectors deployed, mesh still intact. Both paths exist.
R3# show ip bgp 203.0.113.0/24 | include available|Cluster
Paths: (3 available, best #1, table default)
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
      Originator: 10.0.0.1, Cluster list: 10.0.0.10
! ^ One direct mesh path plus one per reflector. Safe to proceed.
!
! Phase 2 - remove mesh sessions one router at a time
R3(config-router)# no neighbor 10.0.0.1
R3(config-router)# no neighbor 10.0.0.2
!
! Phase 3 - verify the count is unchanged after each removal
R3# show ip bgp | include Total number
Total number of prefixes 847
! ^ Same as before. If it dropped, restore the session and
!   find out which prefixes the reflectors are not carrying.

Reflection across multiple address families

route-reflector-client is an address-family command, so a neighbour can be a client for IPv4 unicast and not for VPNv4, or the reverse. In an MPLS L3VPN network that distinction is deliberate and common: the PE routers are VPNv4 clients of a dedicated VPNv4 reflector, while IPv4 unicast in the global table may use an entirely different reflection topology or none at all. Forgetting to repeat the client statement in a second family produces a family that silently falls back to plain iBGP behaviour, which without a full mesh means prefixes that never propagate.

! One neighbour, client status per family
router bgp 65000
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 update-source Loopback0
 !
 address-family ipv4 unicast
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 send-community extended
  neighbor 10.0.0.1 route-reflector-client
  ! Omitting this line here leaves VPNv4 without reflection
 exit-address-family
!
! Audit client status across every family in one pass
RR-1# show ip bgp all neighbors 10.0.0.1 | include address family|Route-Reflector

Sizing a cluster

• Keep the number of clients per reflector within what the platform can hold in memory for the full table times the number of address families.
• Two reflectors per cluster, with different cluster IDs, so a client always has two installed paths.
• Reflectors peer with each other, and with the reflectors of any other cluster, as non-clients in a full mesh among reflectors.
• Beyond roughly one cluster per region, move to a hierarchy rather than growing a single cluster.
• Every client peers with both reflectors of its cluster and with nothing else.

How Does Path Hiding Work and How Do I Fix It?

What is path hiding?

A BGP speaker advertises only its best path. A reflector is a BGP speaker, so it reflects only its own best path for each prefix — not every path it knows. In a full mesh, a router receives one copy of a prefix from every other router that has it, and can choose among them. Under reflection, a client receives one copy per reflector, and every copy is the reflector's opinion. The alternatives the reflector considered and rejected are invisible to the entire cluster. That is path hiding, and it removes the redundancy and load-distribution options that the underlying topology actually provides.

A Deeper Dive into Path Hiding and Add-Path

What path hiding costs

• Slower convergence: a client whose installed path fails must wait for the reflector to reconverge and re-advertise, rather than switching to an alternative it already holds.
• No multipath: a client cannot install two external exits if it only ever received one.
• Suboptimal exits: the reflector's chosen path may be the best from the reflector's position and not from the client's.
• MED oscillation: in some topologies, hiding paths from routers that would otherwise compare them can produce persistent route oscillation.
• Reduced visibility: troubleshooting is harder because the alternatives simply do not appear anywhere except on the reflector.

! The reflector holds four paths...
RR-1# show ip bgp 203.0.113.0/24 | include available
Paths: (4 available, best #3, table default)
!
! ...and the client received exactly one.
C1# show ip bgp 203.0.113.0/24 | include available
Paths: (1 available, best #1, table default)
! ^ Three alternatives exist in the network and are invisible here.

Add-Path: advertising more than the best path

RFC 7911 defines BGP Additional Paths, which lets a speaker advertise several paths for the same prefix by tagging each with a path identifier. It is a negotiated capability, so both ends must support and enable it. On Cisco platforms the configuration has two halves: the reflector must be told which paths to select as candidates, and each neighbour must be told how many to send.

! ===== ON THE REFLECTOR =====
router bgp 65000
 address-family ipv4 unicast
  ! 1. Compute additional candidate paths beyond the best
  bgp additional-paths select all
  ! 2. Negotiate the capability with clients
  bgp additional-paths send receive
  ! 3. Tell each neighbour how many to actually advertise
  neighbor CLIENTS advertise additional-paths best 2
  ! Alternatives: 'all', or 'group-best' for one per neighbouring AS
 exit-address-family
!
! ===== ON EACH CLIENT =====
router bgp 65000
 address-family ipv4 unicast
  bgp additional-paths receive
 exit-address-family

! Confirm the capability was negotiated
C1# show ip bgp neighbors 10.0.0.9 | include Additional
    Additional Paths: RX advertised and received
!
! The client now holds several paths, each with a path ID
C1# show ip bgp 203.0.113.0/24
Paths: (3 available, best #2, table default)
  65001
    10.0.0.1 (metric 20) from 10.0.0.9 (10.0.0.9)
      Origin IGP, localpref 100, valid, internal, best
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
      rx pathid: 0x1, tx pathid: 0x0
  65001
    10.0.0.2 (metric 30) from 10.0.0.9 (10.0.0.9)
      Origin IGP, localpref 100, valid, internal
      Originator: 10.0.0.2, Cluster list: 10.0.0.9
      rx pathid: 0x2, tx pathid: 0

Choosing which additional paths to send

Alternatives to Add-Path

Two older techniques address the same problem where Add-Path is unavailable. A shadow session — a second BGP session to the same reflector with different policy, so the reflector's second-best path is selected on that session — works but doubles session count. Diverse-path assigns a reflector the task of advertising its second-best path rather than its best, so a pair of reflectors between them advertise the top two. Both are more fragile than Add-Path and are worth knowing mainly because they appear in older designs.

! Diverse path: this reflector advertises its SECOND best path
router bgp 65000
 address-family ipv4 unicast
  bgp additional-paths select backup
  neighbor CLIENTS advertise diverse-path backup
 exit-address-family
! ^ Paired with a second RR advertising the best path, clients end
!   up with two distinct paths without full Add-Path negotiation.

Which Route Reflector Designs Fail in Production?

What are the recurring failure modes?

Six. A reflector that does not rewrite the next hop leaves clients with unresolvable paths. A partially migrated mesh leaves non-clients unable to see each other. A reflector placed at a topological extreme imposes its own exit preference on the whole cluster. A shared cluster ID between reflectors that are not correctly peered creates a partition. Add-Path enabled without a send limit exhausts client memory. And a single reflector with no redundancy makes the control plane for an entire cluster depend on one device.

A Deeper Dive into the Failure Catalogue

The next-hop problem, restated

A reflector does not modify NEXT_HOP when reflecting — reflection is specified to be transparent. A prefix learned from an eBGP peer therefore reaches clients carrying the external peer's address, which clients typically have no route to. There are two correct fixes and they are not equivalent: next-hop-self all on the reflector makes the reflector the next hop, which is only valid if the reflector is in the forwarding path; carrying the external links in the IGP preserves the original next hop and works regardless.

! Diagnose: paths present, none installed
C1# show ip bgp 203.0.113.0/24
Paths: (1 available, no best path)
  65001
    198.51.100.1 (inaccessible) from 10.0.0.9 (10.0.0.9)
!
! Fix A - reflector is in the forwarding path
router bgp 65000
 address-family ipv4 unicast
  neighbor CLIENTS next-hop-self all
  ! 'all' is required - without it, reflected routes are not rewritten
!
! Fix B - preferred with dedicated reflectors: set it at the border
! On the border router, before the prefix reaches the reflector:
router bgp 65000
 address-family ipv4 unicast
  neighbor 10.0.0.9 next-hop-self

Reflector placement and exit selection

Because a reflector chooses using its own IGP metrics at step eight, its position determines which exit the whole cluster uses. In a two-site network with one reflector in site A, clients in site B receive site A's preferred exit. The symptom is traffic crossing the core to reach an exit that was two hops away, and nothing in the client's configuration explains it. The fixes are a reflector per site, a hierarchy, or Add-Path so clients can choose for themselves.

Verification commands worth running

! Which neighbours are clients?
RR-1# show ip bgp neighbors | include BGP neighbor|Route-Reflector
BGP neighbor is 10.0.0.1,  remote AS 65000, internal link
  Route-Reflector Client
BGP neighbor is 10.0.0.10,  remote AS 65000, internal link
! ^ No 'Route-Reflector Client' line = non-client.
!
! What cluster ID is this reflector using?
RR-1# show ip bgp | include cluster
BGP table version is 812, local router ID is 10.0.0.9, cluster-id 10.0.0.9
!
! How many paths does the reflector hold versus advertise?
RR-1# show ip bgp 203.0.113.0/24 | include available|Advertised
Paths: (4 available, best #3, table default)
  Advertised to update-groups: 2
!
! Confirm a client sees the expected number of copies
C1# show ip bgp | include Total number

Conclusion

Route reflection trades a structural guarantee for an attribute-based one. The full mesh prevented loops by making every internal path exactly one hop, which is airtight and does not scale. Reflection permits multi-hop internal propagation and replaces the guarantee with ORIGINATOR_ID and CLUSTER_LIST, both checked on receipt, both confined to the autonomous system. That trade is sound, and it is why reflection is essentially universal while confederations remain rare — reflection is configured on the reflectors alone, so adopting it is incremental in a way that re-numbering an autonomous system into sub-autonomous systems can never be.

The consequence people underestimate is that a reflector does not merely forward information; it decides. It runs the best-path algorithm using its own IGP metrics and advertises the single result to every client, which means its topological position becomes an input to every client's forwarding decision. A reflector at the edge of the network imposes edge-shaped routing on the core. A reflector that holds four paths hands its clients one. Neither is a misconfiguration, and neither is visible from a client without comparing against the reflector directly.

Design accordingly. Two reflectors per cluster with distinct cluster IDs, so every client holds two installed paths and a reflector failure changes nothing. Reflectors placed where their view of the IGP resembles their clients' view, which usually means one cluster per region and a hierarchy above it. next-hop-self all where the reflector forwards, and next-hop rewriting at the border where it does not. Add-Path with a bounded send limit wherever path diversity matters at the client. Build a cluster with two reflectors and four clients, then compare show ip bgp <prefix> on a reflector against the same command on a client — the difference between those two outputs is path hiding, and seeing it once makes the rest of the design obvious.

External Links Recommendations

• RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh IBGP: the reflection rules, ORIGINATOR_ID, CLUSTER_LIST, and cluster definition.
• RFC 7911 — Advertisement of Multiple Paths in BGP: the Add-Path capability and path identifiers.
• RFC 5065 — Autonomous System Confederations for BGP: the alternative to reflection and why its AS_PATH segments count as zero.
• RFC 4271 — A Border Gateway Protocol 4 (BGP-4): the decision process, including the steps that use ORIGINATOR_ID and CLUSTER_LIST.
• Cisco — BGP Best Path Selection Algorithm: where reflection attributes enter the comparison.
• Cisco IOS-XE BGP Configuration Guide: current syntax for route-reflector-client, bgp cluster-id, next-hop-self all, and additional paths.
• Cisco Learning Network — CCIE Enterprise Infrastructure: current blueprint and lab equipment list.

Reference Notes

1. RFC 4456, Section 6 — the reflection rules: routes from a client are reflected to all peers, routes from a non-client are reflected to clients only.
2. RFC 4456, Section 7 — ORIGINATOR_ID is set by the reflector to the router ID of the originator and is not overwritten if already present.
3. RFC 4456, Section 7 — a router receiving an update whose ORIGINATOR_ID equals its own router ID must ignore it.
4. RFC 4456, Section 7 — CLUSTER_LIST is prepended with the local CLUSTER_ID by each reflector, and an update whose CLUSTER_LIST already contains the local CLUSTER_ID must be ignored.
5. RFC 4456, Section 8 — CLUSTER_ID defaults to the BGP Identifier of the route reflector and may be configured explicitly when redundant reflectors share a cluster.
6. RFC 4456, Section 10 — both ORIGINATOR_ID and CLUSTER_LIST are optional non-transitive attributes and are never propagated outside the autonomous system.
7. RFC 4271, Section 9.1.2.2 — the decision process tiebreakers, into which ORIGINATOR_ID and CLUSTER_LIST length are inserted by RFC 4456.
8. RFC 4271, Section 9.2 — a BGP speaker advertises only the route it has selected as best, which is the origin of path hiding under reflection.
9. RFC 7911, Section 3 — the ADD-PATH capability negotiation and the four-octet path identifier prepended to NLRI.
10. RFC 5065, Section 5 — confederation AS_PATH segments are excluded from path-length comparison, and confederation-external ranks between eBGP and iBGP.
11. Cisco IOS-XE BGP Configuration Guide — neighbor next-hop-self all is required for the next hop of reflected routes to be rewritten; the plain form does not apply to them.
12. Cisco IOS-XE BGP Configuration Guide — bgp additional-paths select chooses candidate paths and neighbor advertise additional-paths controls how many are sent.