BGP peer templates
By stretch | Tuesday, January 12, 2010 at 1:59 a.m. UTC
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):
Session Templates | Policy Templates |
|
|
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:
Posted in Routing
Comments
January 12, 2010 at 2:07 a.m. UTC
God bless you, my friend. I'm going to spend the week implementing this stuff on our DMVPN routers!
January 12, 2010 at 1:08 p.m. UTC
Damn you! I was going to post about the same thing in the near future.:P
January 12, 2010 at 3:21 p.m. UTC
NERD BLOG FIGHT
January 12, 2010 at 4:44 p.m. UTC
@Vito: Hahaha! The same thing happens to me occasionally. Sometimes I'll write half an article, google some detail, and discover a fellow blogger just made a post about the same topic a week ago. Of course there's no reason you can't still write about it.
January 12, 2010 at 7:28 p.m. UTC
Yours is better than mine would have been, hahah. I wrote about PVLANs instead.:x
January 12, 2010 at 7:38 p.m. UTC
On a side note, I hate Martians, too.
January 13, 2010 at 5:19 a.m. UTC
@Digital: Martian packet =P
January 13, 2010 at 1:36 p.m. UTC
Damn internets and the lack of [sarcasm] tags!
August 22, 2012 at 11:16 a.m. UTC
Thank you very much,
it is so clear.
Good luck,
April 15, 2013 at 10:21 a.m. UTC
Haha, Martians Attack!
May 29, 2014 at 8:01 a.m. UTC
Thank you very much!
March 10, 2016 at 6:59 a.m. UTC
Thank you.