Hi Rene,
Any lessons on BGP Peer Template (peer session, peer policy)?
Hello Kenneth
Rene has a lesson on BGP Peer Groups but there is currently no lesson on peer templates, peer sessions or peer policies. If this is content you would like to see in upcoming lessons, feel free to post your suggestions on the Member Ideas page below:
You may find that others have suggested something similar, and you can add your voice to theirs.
I hope this has been helpful!
Laz
Lets say i am not using peer group and i have configured the same attribute and other configuration on per neighbor basis as it is , How the bgp will dynamically separate them in terms of update group ??
how can bgp minimize the more update creation after peer group configuration ?
what is bgp template ??
Hello Narad
To clarify:
Without peer groups:
- you must explicitly put in all the BGP commands for each neighbor
- the router must use CPU and memory to process each peering separately, creating updates for each one individually
With peer groups
- you can configure BGP parameters one for a peer group
- all BGP routers in that peer group will receive the same configuration
- CPU and memory will be used to process and create a single update that will be sent to the three neighbors
Note that the difference is primarily in the fact that the configuration syntax changes, and becomes easier to duplicate for multiple peers, and the processing is made more efficient so that an update is processed only once and sent to multiple members of the peer group.
BGP templates are another feature that is helpful in simplifying BGP configuration. This feature allows you to create blocks of BGP configuration that you can use for similar BGP peers. Each block allows you to define a set of attributes that a peer then inherits. You can find out more information about this at the following link:
I hope this has been helpful!
Laz
So peer-group is really a good option when you have more than 2-4 neighbors. I can define it under BGP. Does it have to be defined separately in various VRFs and families? Sounds like a little dumb question (since VRFs have their own neighbors) but still better ask (the more dumb questions one asks the less dumb questions left 
).
Also, is peer-group functionality the same as neighbor-group functionality? Where one or the other applicable? Usually, things like that are different between IOS, NX and XR but at least ASR9000 seems accepts peer-group command. Hence the question.
Hello Vadim
The neighbor command can be defined either under BGP or under specific address families. This is the case whether you use a peer group or use a particular IP address to create the peering. So yes, you are correct, that it is defined separately when multiple VRFs and address families exist.
A neighbor-group is different than a peer-group. A neighbor group is used to help apply the same config to one or more neighbors. It essentially creates a template config that can be assigned to a particular neighbor. Once created, you can use the use command to have a neighbor inherit the config of the neighbor-group.
More about neighbor-groups can be found here:
I hope this has been helpful!
Laz
Thank you,
I still a little slow on neighbor groups ā āA neighbor group is used to help apply the same config to one or more neighborsā¦ā - is not it what peer-group is doing? I understood peer-group allows to create configuration ātemplateā that is then applied to all members of the group. How they are different then? What am I missing? (Particularly that even words āneighborā and āpeerā seems are used interchangeably in BGP world). If there is a difference what are some scenarios where neighbor-group would be preferable to peer-group to use?
Thanks
Hello Vadim
After digging a little deeper, I have found that thereās a little more to the topic than meets the eye. It seems that neighbor-groups are a specific feature of the IOS-XR software, where peer groups are supported by the IOS-XE. They are similar in what they deliver, but their syntax is different. So essentially, they do deliver the same function, simply in a different manner.
I hope this has been helpful!
Laz
Yes, thank you. I suspected that much but its good to have a confirmation.
1 Like
Hi Rene,
Can you upload a video showing how does it exactly work after turning debug on ? Based on what you explained Itās clear that it simplify configuration and save memory but I still donāt understand how does it save CPU cycles. I want to see how does an update and replication work in your example letās say when we add another loopback interface on R1 or something else.
Hello Ripal
A debug will not show how CPU cycles are saved, however, you can see it like this.
Every time a router wants to send updates to a BGP neighbor, it uses the information found in its BGP and routing tables to generate updates. The generation of these updates uses CPU cycles to take the prefixes, next-hop information, redistributed information, and so on, and to create and craft the update. Now if there is one BGP neighbor, then weāre OK. But if there are, say 20 BGP neighbors, there will be 20 times the number of CPU cycles to generate those updates.
Now if you are able to place all 20 of those BGP peers into a single peer group, this means that you can generate the same BGP update only once rather than 20 times, and send it out to all the BGP peers. Immediately you see that you saved CPU usage twentyfold.
I hope this has been helpful!
Laz
Hey, everyone!
With peer groups, the update is generated only once for the peer group. For each neighbor, we only have to replicate the updateā¦thatās it. That saves some CPU cycles on the router.
Please, how exactly does this work if we have multiple neighbors within a peer group but letās say that some of them have different outbound policies applied?
In such a situation, an UPDATE would have to be independently generated for the neighbors with the different outbound policies configured, correct? While those that have no policies or the same policy applied could just have a replicated UPDATE, like Rene above said.
Thank you in advance for your help.
Kind regards,
David
Hello David
You must keep in mind that the generation of the BGP update and the manipulations and changes to that update that take place based on outbound policies applied using route maps and such, are two different processes.
When a BGP update is generated, it is done so based on the parameters found within the BGP configuration including prefixes and advertised routes. This update is generated and takes up CPU cycles to do so. Thatās the first process.
Once the update is ready, it is then sent to a neighboring peer. When this happens, any prefix lists or route maps that are applied on that peering in an outbound direction are applied to the BGP update and it is changed before being sent. This is the second process.
When we use peer groups, we save on CPU cycles of the first process. Instead of crafting multiple BGP updates, one for each peer, it creates only one, that is copied and sent to all peers in the peer group. The outbound policies, however, which are the second process, are still applied to each individual update in accordance with the configured route maps that apply them.
I hope this has been helpful!
Laz
For the above lab, to be fully functional (and not only related to the main topi BGP Peers) you need to either add the router config respective network mask commands or to add on R1 under router config the redistribute connected and on R2, 3, 4 the network commands. Then you can verify the the prefixes on R1 and the particular metric on R2,3,4
R1#show bgp ipv4 unicast summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 154 171 15 0 0 01:54:57 1
3.3.3.3 4 3 142 155 15 0 0 01:54:10 1
4.4.4.4 4 4 141 154 15 0 0 01:53:25 1
R1#
R2#show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 10
Paths: (1 available, best #1, table default, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 11
1
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 2323, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
R2#
Hello Dan
Yes you are correct. The lesson only shows the exchange of routing information between BGP peers, and does not include the full configuration necessary to ensure that you are able to ping the destinations. The purpose of the lesson is to show how to use BGP peer groups to exchange this information successfully.
I hope this has been helpful!
Laz
Sorry for replying late on this but I donāt think that this is entirely correct.
I found out today after revisiting BGP that neighbors within the same peer group must have the same outbound policy.
In other words, I cannot create a unique outbound policy for a neighbor that is part of a peer group
So it looks like unique outbound policies cannot be applied for BGP Peer Groups. They either share the same one or they donāt share one at all. From what Iāve seen, Peer Templates are the way to go if we have a large BGP configuration or we need unique outbound policies for our peers and still want to use grouping/a hierarachy of some sort 
Kind regards,
David
Hello David
Yes, you are correct. Iāve verified this myself as well. One of the requirements, as stated in this Cisco documentation is that:
All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members.
Also note that:
You can customize the inbound update policy for any member of a peer group.
Thanks for noting this. I will make a NetworkLessons note on the topic and link to it here when I have done so.
Indeed BGP peer templates are a more flexible and powerful tool that you can use if you want to achieve what you are describing.
Thanks again!
Laz