Day 42 — Peer Groups, Peer Session Templates and Peer Policy Templates

1. Opening

Peer groups and templates solve a different scaling problem from route reflectors. They reduce repetitive configuration and policy drift; they do not change the fundamental BGP propagation rules by themselves.

The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture.

2. Concept and standards behavior

Cisco IOS XE supports peer groups and template-based inheritance, including peer session templates and policy templates. These structures can centralize shared neighbor parameters while allowing deliberate per-peer exceptions. Update groups are an internal optimization concept and should not be treated as a user-visible substitute for explicit policy design.

A recurring rule in this module is that configuration scale and routing-information scale are different problems. A design can be easy to configure but still create poor path visibility, slow convergence, or an oversized blast radius. Conversely, a topology can carry complete information but be operationally expensive to maintain.

3. Scenario

Build four external peers that share common session parameters but require two different export policies. Use session/template inheritance for the common configuration and retain separate policy attachment where business intent differs.

Documentation-safe addressing is used. The common lab AS is 65010. Internal loopbacks use 192.0.2.0/24 host routes; external test prefixes use 203.0.113.0/24 and 198.51.100.0/24 where needed. All fictional failures are lab-only.

Success criteria

1. Every speaker learns the routes it is supposed to learn.
2. The propagation rule can be explained before commands are applied.
3. Loop-prevention attributes are visible where the feature uses them.
4. A negative test proves that an invalid or unintended propagation does not occur.
5. Rollback returns the topology to a known-good control-plane state.

4. Topology diagram

A matching SVG/PNG diagram is stored in media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable IGP reachability among BGP loopbacks.
• Explicit update-source and appropriate neighbor reachability for loopback-based sessions.
• Authentication only if the lab image and design have been validated for it.
• Independent management access before changing route-reflection/confederation policy.
• Pre-change capture of BGP summary, selected paths and relevant neighbor state.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete device configuration.

router bgp 65010
 template peer-session TRANSIT-SESSION
  remote-as 65020
  update-source Loopback0
 exit-peer-session
 !
 template peer-policy TRANSIT-POLICY
  send-community both
 exit-peer-policy
!
! Apply inheritance to individual neighbors only where
! the shared parameters are genuinely identical.

Do not silently transfer this syntax to IOS XR or NX-OS. Those platforms must use their own policy/configuration model.

7. Verification before modification

Use a combination of topology, session and route evidence:

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors
show ip route

For route-reflection topics also inspect the path detail for ORIGINATOR_ID and CLUSTER_LIST where present. The absence or presence of a route must be explained by the propagation rule, not guessed from neighbor state alone.

8. Controlled modification

Move common timer/session settings into a peer-session template while leaving prefix-specific export policy per neighbor. Verify that the effective neighbor configuration still matches the intended boundary.

Predict the exact peers whose Adj-RIB-In/Loc-RIB should change. Then apply one control-plane change, re-check path detail, and verify that no unrelated peer loses reachability.

9. Fault injection

Illustrative lab — not a real incident.

Put a customer and a transit provider into the same policy template and accidentally inherit an export rule that should apply only to the provider. Sessions remain healthy while policy isolation is broken.

Capture the state before and after the fault. A useful fault must change one causal variable only.

10. Step-by-step troubleshooting

1. Confirm IGP reachability among BGP endpoints.
2. Confirm TCP/BGP sessions are Established.
3. Identify where the route originated.
4. Trace the route one BGP hop at a time.
5. Determine whether the receiving neighbor is eBGP, ordinary iBGP, RR client, RR non-client, or confederation peer.
6. Inspect best-path state before assuming propagation is broken.
7. Inspect ORIGINATOR_ID/CLUSTER_LIST for reflected routes.
8. Inspect policy and next-hop reachability.
9. Verify whether an alternative path was never learned, learned but not selected, or selected but not advertised.
10. Apply the smallest proven correction.
11. Re-run the same positive and negative tests.
12. Observe stability before closing the change.

11. Root cause and correction

The root cause is excessive inheritance scope. Split session-common parameters from business-policy parameters and use separate policy templates or explicit per-neighbor controls.

The correction must address the architectural cause rather than adding random neighbor statements until the route appears.

12. Post-fix verification

Verify:

• all intended sessions remain Established;
• the expected prefix is learned by the intended speakers;
• reflected attributes are correct where applicable;
• next hop remains reachable;
• no routing loop is created;
• the negative propagation test still passes.

13. Rollback

Restore the previous neighbor relationship or policy, not an ad-hoc alternative. If the change affects route reflection, preserve enough connectivity that clients do not become isolated during rollback. Roll back for unexpected loss of route visibility, oscillation, unintended path change, or evidence that the design created a larger failure domain than approved.

14. Production lessons

Configuration abstraction is safe only when shared intent is truly shared. Templates should make differences more visible, not hide them. Review inherited policy during change control just as carefully as direct configuration.

Deep-dive engineering notes

Templates reduce drift, not routing topology

Peer groups and templates are often called scaling features, but the scale they address is primarily configuration and update-generation efficiency. They do not allow an ordinary iBGP peer to re-advertise iBGP-learned paths to another ordinary iBGP peer. That architectural distinction prevents a common category error.

Separate session inheritance from policy inheritance

Session parameters such as remote-AS pattern, update source, timers, password mechanism, and capability-related settings can often be shared across a class of peers. Business policy is more dangerous to over-share. Customer, peer, transit and route-server relationships normally need visibly different import/export controls even when their transport settings are identical.

Peer session templates and peer policy templates help express this separation. The safe pattern is to inherit what is genuinely common and keep relationship-specific policy obvious.

Inheritance changes troubleshooting

When a neighbor behaves incorrectly, displaying only the neighbor's explicit stanza may not reveal inherited settings. Operational tooling and change review must show the effective configuration. A hidden inherited route map can be just as dangerous as an explicit one.

Update groups

Cisco can internally group peers that share outbound policy characteristics to optimize update generation. This is an implementation optimization, not a substitute for policy design. Engineers should avoid manipulating configuration solely to force a particular internal update-group structure unless Cisco documentation and a demonstrated performance problem justify it.

Change-control implication

Templates increase blast radius. Editing one shared template can alter many peers simultaneously. For that reason, template changes should receive stricter impact analysis than a single-neighbor change: enumerate inheriting peers, diff effective configuration, stage the change, validate a canary where possible, and retain a fast rollback.

Bridge to dynamic neighbors

Templates become especially useful when many neighbors share a predictable configuration profile. Dynamic-neighbor/listen-range designs build on that idea and deserve their own day because they add admission, range and security considerations beyond configuration inheritance.

15. Knowledge check

1. Which problem in this post is a control-plane topology problem rather than a command-syntax problem?
2. What evidence distinguishes “route was never learned” from “route was learned but not selected”?
3. What negative test proves the scaling feature has not introduced unintended propagation?

Answers

1. The relationship among BGP speakers and the rules governing propagation.
2. Per-prefix BGP path detail and neighbor route evidence.
3. Verify a route that should remain hidden/unadvertised is absent from the relevant neighbor's learned/advertised state.

16. Sources

• Cisco IOS XE 17.x — BGP peer groups, peer session templates and update groups
• RFC 4271 — BGP-4
• Cisco IOS XE 17.x BGP configuration guidance