I85PREP
⌘ K
Nokia BGP Fundamentals for Services study materials
Nokia BGP Fundamentals for Services study resources

Nokia BGP Fundamentals for Services: Scaling: Route Reflectors, Confederations, and Peer Groups

Nokia BGP Fundamentals for Services · Work through your exam, one topic at a time.

All guide sections

Scaling: Route Reflectors, Confederations, and Peer Groups

This domain tests how you scale iBGP beyond a full mesh and how SR OS implements route reflection, confederations and group-based configuration.

Why scaling is needed

iBGP full mesh requires n(n-1)/2 sessions and, worse, each router stores every path. Twenty PEs means 190 sessions; two route reflectors reduce that to 40 while keeping path diversity manageable.

Route reflectors

Configure cluster <cluster-id> on the reflector and flag selected neighbours with client. Reflection rules: client-to-client, client-to-non-client and non-client-to-client are reflected; non-client-to-non-client is not. Loop prevention uses ORIGINATOR_ID (the originating router ID) and CLUSTER_LIST (each reflector prepends its cluster ID; a router discards a route containing its own cluster ID). Put redundant reflectors in the same cluster ID so they do not re-reflect each other's paths, and consider add-paths on the reflector so clients see more than one path per prefix.

Confederations

configure router bgp confederation <as> members <sub-as> ... splits one administrative AS into member sub-ASes. Inside a member sub-AS you still need iBGP full mesh or reflection; between member sub-ASes the behaviour is eBGP-like, with AS_CONFED_SEQUENCE/SET segments in AS_PATH, but LOCAL_PREF and MED are preserved across member boundaries. External peers see only the confederation AS; confederation segments are stripped before advertisement outside.

Groups (peer groups)

An SR OS group acts as a template: peer-as, family, hold time, authentication and import/export policy inherit to members. This gives consistent policy and fast provisioning at scale; it does not reduce per-neighbour UPDATE processing or memory.

Worked example

Two reflectors configured with different cluster IDs (1.1.1.1 and 2.2.2.2) both reflect the same prefix to the same client. The client keeps both paths, doubling RIB entries and causing churn on every reflector failure. Setting the same cluster ID on both reflectors makes one path arrive with the client's own cluster loop check satisfied for only one copy, collapsing the duplication.

Traps

  • Marking client on only one side of the reflector relationship, so reflection paths are asymmetric.
  • Different cluster IDs on redundant reflectors, causing duplicate paths and stale entries.
  • Assuming confederation member boundaries preserve NEXT_HOP handling identical to eBGP; verifying the SR OS behaviour matters before designing around it.