[c-nsp] BGP Peer Group drawbacks???

[Artur]

Great point Marko,

just adding to that, in the most recent IOS versions update-groups are 
built automatically when you have neighbors with an equal policy 
configuration.

That means, peers belonging to the same peer-group, or with the same 
peer-policy template or even without peer-groups or templates configured 
but with the same policy applied.

The optimization brought by update-groups is obtained because as all the 
neighbors have an equal policy IOS knows that it needs to calculate a 
single set of updates to all of them, in older versions it used to 
calculate updates for each neighbor, even though they had equal policies.

Artur

On 1/10/2010 4:05 AM, Marko Milivojevic wrote:
>> Seems to me that peer/session templates would allow you to get more granular
>> with your BGP configuration then peer-groups due to
>> their inheritance feature.  So it makes sense to me.
>>
>> I don't think scale is the only deciding factor between peer group and
>> templates.  I think it also depends on the complexity of your routing policy
>> and # of prefix's etc...I guess a question could be - why wouldn't you use
>> templates - even for a simple BGP config?  Any ISP ops on the list - do you
>> use templates, peer-groups - or both?
>>
>> To the original poster - perhaps you can decide for yourself?  See here:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpct.html#wp1027129
>> and
>> a good explanation here with configurations
>> http://cciethebeginning.wordpress.com/2009/01/09/358/
>>      
> Well... comparing peer-groups and templates is just a little bit like
> comparing apples and oranges. They were meant to solve different
> problems.
>
> When they were introduced, peer-groups were used to optimize the
> updates sent to neighbors. I.e. using peer-groups had impact on your
> CPU in such a way that members of the same peer group shared the same
> update that was only replicated. Non-peer-group peers had to have
> their updates built separately, even though it may end up being the
> same. The fact that the peer-groups had this nice side effect of being
> able to group configuration and make deployments somewhat easier, was
> never their primary purpose in life... and that shows, as they look
> unnatural and are not very flexible.
>
> Naturally, over the years, Cisco found the way to optimize updates
> automatically (using update-groups) and the only purpose of
> peer-groups was to group commands together. Since they were not doing
> that as well as one would hope (whoever configured peer-groups in
> multiple address-families probably knows how ... "intuitive" that is),
> another solution needed to be made. This is how we got templates,
> whose only purpose is to group configurations and they do pretty good
> job at that.
>
> All that said, for all new deployments, I would suggest using
> templates and not peer-groups... they could disappear at any time.
>
> --
> Marko Milivojevic - CCIE #18427
> Senior Technical Instructor - IPexpert
>
> Mailto: markom at ipexpert.com
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> Community: http://www.ipexpert.com/communities
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/