An emergency-management office peers with two similar ISP transit routers and wants identical outbound policies without duplicating every neighbor statement detail. Which BGP construct helps?
Select an answer to reveal the explanation.
Short Explanation
A peer group is a cookie cutter for look-alike ISP neighbors. Same shared policy template, less copy-paste, and the update machinery can treat them as a set. Perfect when emergency management has two nearly identical transit peers.
Full Explanation
An emergency-management office peering with two similar ISP transit routers and wanting identical outbound policies without duplicating every neighbor statement should use a BGP peer group. Peer groups apply shared update policies and common neighbor parameters to multiple peers, reducing repetitive configuration and allowing the update generation machinery to treat members more efficiently when policies match. That construct directly addresses identical outbound policy across look-alike ISP neighbors—why the correct answer fits. Separate OSPF stub areas per ISP peer in place of BGP policy confuse IGP area design with BGP neighbor policy and do not template eBGP outbound policy. Disabling best-path selection for those two peers is not a per-peer control, does not template outbound policy, and would break path selection rather than simplify configuration. Forcing unique private ASNs onto each identical policy line increases complexity and does not provide a shared policy template. Exam caveat: peer groups require compatible outbound policies among members; modern peer templates/session groups appear on some platforms, but the classic ENARSI concept remains peer groups for shared policy. Operational check: place both ISP neighbors in one peer group with the shared route-map/prefix-list; verify configuration brevity; confirm both sessions Established and that advertised prefixes match the intended identical outbound policy.