BGP peer templates

When Cisco introduced peer groups for BGP neighbors, their intention was to associate neighbors which shared routing policies in an effort to optimize CPU utilization. A side effect of peer-group configuration is reduced syntax. For example, consider the following verbose configuration:

neighbor 192.168.0.1 remote-as 100
neighbor 192.168.0.1 ttl-security hops 1
neighbor 192.168.0.1 timers 30 300
neighbor 192.168.0.2 remote-as 100
neighbor 192.168.0.2 ttl-security hops 1
neighbor 192.168.0.2 timers 30 300
neighbor 192.168.0.3 remote-as 100
neighbor 192.168.0.3 ttl-security hops 1
neighbor 192.168.0.3 timers 30 300
neighbor 192.168.0.4 remote-as 100
neighbor 192.168.0.4 ttl-security hops 1
neighbor 192.168.0.4 timers 30 300

These twelve lines become only eight after implementing a peer group, removing much redundancy from the original configuration:

neighbor MyGroup peer-group
neighbor MyGroup remote-as 100
neighbor MyGroup ttl-security hops 1
neighbor MyGroup timers 30 300
neighbor 192.168.0.1 peer-group MyGroup
neighbor 192.168.0.2 peer-group MyGroup
neighbor 192.168.0.3 peer-group MyGroup
neighbor 192.168.0.4 peer-group MyGroup

Unfortunately, because simplified syntax was never the primary goal of peer groups, they can still be rather unwieldy when attempting to configure neighbors with similar, but not identical, routing policies.

In IOS 12.0(24)S, Cisco introduced dynamic update peer groups, a feature which essentially enables the software to automatically group BGP neighbors into peer groups and generate update messages accordingly. Although this new feature effectively obsoleted manually defined peer groups, they have stuck around as many administrators appreciate the convenience they offer in configuration.

Around the same time dynamic update peer groups were introduced, Cisco also debuted BGP peer templates. With the burden of CPU optimization delegated to dynamic update peer groups, peer templates introduced a much more flexible, hierarchical peer configuration scheme. There are two types of peer templates: session templates and policy templates.

Session templates affect the actual BGP session with a neighboring router, whereas policy templates affect protocol-specific (NLRI) policy (e.g. IPv4 versus IPv6). The following table lists which parameters are defined in each type of template (as of IOS 12.4T):

To illustrate how peer templates work, consider the following peer group configuration:

router bgp 65200
 no synchronization
 bgp router-id 10.0.0.3
 bgp log-neighbor-changes
 neighbor IBGP-Peers peer-group
 neighbor IBGP-Peers remote-as 65200
 neighbor IBGP-Peers timers 30 300
 neighbor EBGP-Peers peer-group
 neighbor EBGP-Peers ttl-security hops 1
 neighbor EBGP-Peers timers 30 300
 neighbor 10.0.1.1 remote-as 65101
 neighbor 10.0.1.1 peer-group EBGP-Peers
 neighbor 10.0.1.2 remote-as 65102
 neighbor 10.0.1.2 peer-group EBGP-Peers
 neighbor 10.0.2.4 peer-group IBGP-Peers
 neighbor 10.0.2.5 peer-group IBGP-Peers
 no auto-summary

Two peer groups have been created: one for IBGP neighbors, and one for EBGP neighbors. Each group defines some unique session characteristics, but they both also have one in common (the BGP timers configuration). Because of the way peer groups work (again, they were originally intended only for CPU optimization), common attributes must be replicated across peer groups, introducing redundancy in the configuration.

Peer templates embrace a hierarchical approach to combat such redundancy. We can create one template for session parameters common to all BGP neighbors, and then create more-specific templates which inherit those parameters. Templates are created under the BGP routing process:

R3(config)# router bgp 65200
R3(config-router)# template ?
  peer-policy   Template configuration for policy parameters
  peer-session  Template configuration for session parameters

R3(config-router)# template peer-session BGP-All
R3(config-router-stmp)# timers 30 300
R3(config-router-stmp)# exit-peer-session
R3(config-router)#

The BGP-All template holds the timers configuration line we want to apply to all peers. Next we'll create separate IBGP and EBGP templates, both of which will inherit parameters from the BGP-All template using the inherit peer-session command.

The completed configuration looks like this:

router bgp 65200
 template peer-session BGP-All
  timers 30 300
 exit-peer-session
 !
 template peer-session IBGP
  remote-as 65200
  inherit peer-session BGP-All
 exit-peer-session
 !
 template peer-session EBGP
  ttl-security hops 1
  inherit peer-session BGP-All
 exit-peer-session
 !
 no synchronization
 bgp router-id 10.0.0.3
 bgp log-neighbor-changes
 neighbor 10.0.1.1 remote-as 65101
 neighbor 10.0.1.1 inherit peer-session EBGP
 neighbor 10.0.1.2 remote-as 65102
 neighbor 10.0.1.2 inherit peer-session EBGP
 neighbor 10.0.2.4 inherit peer-session IBGP
 neighbor 10.0.2.5 inherit peer-session IBGP
 no auto-summary

Admittedly, with only four neighbors and only two significant classifications (EBGP and IBGP), the improvement might not seem all that drastic. But consider the efficiency afforded when configuring dozens of BGP peers in a similar matter.

The above example demonstrates peer session templates at work. As you might have guessed, peer policy templates work very similarly:

R3(config-router)# template peer-policy BGP-All
R3(config-router-ptmp)# prefix-list DENY-MARTIANS in
R3(config-router-ptmp)# exit-peer-policy
R3(config-router)# neighbor 10.0.1.1 inherit peer-policy BGP-All

Policy template inheritance works the same way, but with the inherit peer-policy command.

Finally, the show ip bgp template command can be used to verify template inheritance:

R3# show ip bgp template peer-session
Template:BGP-All, index:1
Local policies:0x20, Inherited polices:0x0
 *Inherited by Template IBGP, index= 2 
 *Inherited by Template EBGP, index= 3 
Locally configured session commands: 
 timers 30 300
Inherited session commands:

Template:IBGP, index:2
Local policies:0x1, Inherited polices:0x20
This template inherits: 
  BGP-All index:1 flags:0x0
Locally configured session commands: 
 remote-as 65200
Inherited session commands: 
 timers 30 300

Template:EBGP, index:3
Local policies:0x800, Inherited polices:0x20
This template inherits: 
  BGP-All index:1 flags:0x0
Locally configured session commands: 
 ttl-security hops 1
Inherited session commands: 
 timers 30 300

R3# show ip bgp template peer-policy
Template:BGP-All, index:1.
Local policies:0x40, Inherited polices:0x0
Locally configured policies: 
  prefix-list DENY-MARTIANS in
Inherited policies: