21 Peer Groups
Peer groups let a router apply a shared configuration to many neighbors at once. Beyond saving configuration time, their real benefit is a reduction in the processing and memory a router spends generating updates for large numbers of peers.
The core idea
A peer group bundles neighbors that share the same outbound policy. Instead of configuring each neighbor separately, the common policy is defined once on the group, and every member inherits it.
The real benefit: update generation efficiency
The important benefit is not just typing fewer commands. Without peer groups, a router computes the outbound update table (Adj-RIB-Out) separately for each neighbor. With a peer group, it computes that outbound policy once and replicates the result to all members of the group.
This is why peer groups matter on a router with dozens to hundreds of BGP neighbors: the router avoids repeating the same update computation many times, saving both processing and memory.
How it works
- Create the peer group with a name.
- Apply policies once to the group (remote-as, password, route-maps, and so on).
- Add neighbors to the group.
- All members inherit the group’s configuration.
Outbound shared, inbound can differ
Members of a peer group must share the same outbound policy, because that is what gets computed once and shared. However, they can still have different inbound policies: each neighbor can have its own inbound route-map. The optimization applies to the outbound update generation; inbound routes are processed per neighbor regardless.
Evolution: peer templates
On modern IOS-XE, peer groups have been partly replaced or complemented by peer templates (session templates and policy templates), which are more flexible. Peer groups remain the classic, widely taught mechanism, but knowing that templates exist is useful.
Self-check
Q1 — What is the real benefit of a peer group beyond saving configuration time?
A) It encrypts BGP sessions
B) It computes the outbound update once and replicates it to all members, saving processing and memory
C) It raises the Local Preference for members
D) It disables the connected-check
Respuesta
B is correct. Without peer groups a router computes Adj-RIB-Out per neighbor; with them it computes the outbound policy once and replicates it, saving CPU and memory on routers with many peers.
- A) False — peer groups are not an encryption feature.
- C) False — they do not change Local Preference.
- D) False — connected-check is a separate eBGP concern.
Q2 — What must members of a peer group share?
A) The same inbound policy
B) The same outbound policy
C) The same Router ID
D) The same IP subnet
Respuesta
B is correct. Members must share the same outbound policy, since that is the part computed once and replicated.
- A) False — inbound policy can differ per neighbor.
- C) False — Router IDs are unique per router, not shared by a group.
- D) False — members need not be in the same subnet.
Q3 — Can peer group members have different inbound policies?
A) No, everything must be identical
B) Yes, inbound route-maps can differ per neighbor
C) Only if they are eBGP peers
D) Only if multipath is enabled
Respuesta
B is correct. The optimization is on outbound update generation; inbound routes are processed per neighbor, so each member can have its own inbound route-map.
- A) False — only outbound policy must match.
- C) False — this is not restricted to eBGP.
- D) False — multipath is unrelated to inbound policy flexibility.
Q4 — On modern IOS-XE, what partly replaces or complements peer groups?
A) Distribute-lists
B) Peer templates (session and policy templates)
C) Route reflectors
D) Prefix-lists
Respuesta
B is correct. Peer templates (session templates and policy templates) are the more flexible modern mechanism that partly supersedes peer groups.
- A) False — distribute-lists are a filtering tool, not a peer-config mechanism.
- C) False — route reflectors solve the iBGP full-mesh problem, not peer configuration reuse.
- D) False — prefix-lists are for filtering prefixes.