8.3 IBGP Split-Horizon and Scaling Solutions

Why ordinary IBGP is not a relay chain

An ordinary BGP speaker does not advertise an IBGP-learned route to another ordinary IBGP peer. This is often called IBGP split horizon. Unlike an external AS hop, an internal advertisement does not prepend the local AS to AS_PATH. Internal route distribution therefore needs rules beyond the external AS-loop test.

Consider R1, R2, and R3 in AS 64512. R1 learns an external prefix and advertises it to R2 over IBGP. If R3 peers only with R2, ordinary IBGP does not automatically relay R1's route to R3. A connected TCP session between R2 and R3 does not override the advertisement rule.

This lesson provides supporting context for introductory BGP. Large-scale route-reflector engineering is deeper than the current course's basic BGP objective, but understanding the relay restriction prevents mistakes in small lab topologies.

Full mesh means sessions, not cables

One solution is a full mesh of IBGP sessions among the BGP speakers that need the information. It does not require a dedicated physical cable between every pair: underlying IP routing can carry the sessions.

For N participating BGP speakers, the undirected session count is:

$$\text{Sessions}=\frac{N(N-1)}{2}$$

Growth is quadratic, not exponential. Adding one speaker to N existing speakers creates N new pairings. The new router needs N peer definitions, and each existing router needs an additional peer definition. Platform capacity and update load, rather than an invented universal session limit, determine whether a design is suitable.

Not every physical provider router must run BGP. A transit MPLS P router may forward labeled service traffic using underlay and label state without carrying customer BGP routes.

Route reflection

A Route Reflector (RR) selectively relaxes the ordinary IBGP advertisement rule. An RR and its clients form a cluster. Clients use ordinary IBGP peering; the reflector knows which peers are clients. A non-client is another IBGP peer not assigned client status for that reflector.

For a selected eligible route, the basic reflection rules are:

The route is not reflected back to its originator. Export policy, address families, and loop checks still apply. More elaborate hierarchies and redundant RRs require an intentional design; the simple table is not a promise that arbitrary combinations of reflectors eliminate every distribution gap.

Reflection usually preserves AS_PATH and the intended forwarding next hop, but it does add loop-prevention attributes. It is therefore inaccurate to say it never changes any path attributes.

Loop-prevention attributes

ORIGINATOR_ID identifies the originating internal BGP speaker. A router receiving a reflected route with its own identifier can reject the looped information.

CLUSTER_LIST records reflector clusters traversed by a route. A reflector prepends its cluster identifier when reflecting according to the protocol rules. Receiving its own cluster identifier in that list indicates an information loop.

These are control-plane checks. They do not mean the customer's data packet contains ORIGINATOR_ID or CLUSTER_LIST. A routing UPDATE and a customer packet are different objects.

A useful exercise is to follow an external prefix from R1 through RR-A to client R3. Write down the prefix, forwarding next hop, ORIGINATOR_ID, and cluster information separately. Then trace the customer packet: it follows resolved forwarding toward the next hop, not necessarily through the reflector.

Next-hop reachability

A common internal routing problem is an external NEXT_HOP that internal peers cannot resolve. Suppose R1 receives a prefix from external 192.0.2.2 and preserves that next hop when advertising internally. R3 needs a usable route resolving 192.0.2.2 even though its IBGP session is with R1 or an RR.

There are several intentional designs. The operator can make the peering subnet reachable internally, or apply supported next-hop-self behavior on the advertising border router so that internal peers resolve R1 instead. The latter requires R1 itself to have valid onward forwarding.

Next-hop-self is not universally mandatory. It is appropriate when the design requires that rewrite. Blindly changing a reflected VPN route's next hop can break the relationship between its advertised service label and its egress PE. Apply policy for the relevant address family and service design.

Verify control and data paths independently

When an internal router lacks a prefix, check whether the originator has it, whether policy permits advertising it, whether the peer is a client or non-client, and whether the relevant family is negotiated. Then inspect next-hop resolution and main-table selection.

When a route exists but packets fail, do not assume the reflector is dropping data. The RR may not be on the forwarding path. Check the ingress router's next hop, the underlay route or tunnel, the egress PE's service state, and the return path.

Changing an IBGP topology should be a lab exercise with before-and-after route observations. A reduced session count proves a configuration change, not complete routing coverage. Verify that every intended speaker receives and can use the required destinations.

Primary reference

Route reflection specification, checked October 20, 2026. Nokia configuration and policy syntax depend on the selected release and address family.