One more scaling technique which Cisco has introduced for IOS, is a concept called the peer group, and this was originally introduced again in the mid 90s as an aid to scaling iBGP. Earlier we talked about how route reflectors were used to scale iBGP linearly rather than the full mesh iBGP, which scaled more or less by N squared. Another aid is the peer group because what this helps with, is building the iBGP neighbor mesh. Every iBGP neighbor received the same update in a full mesh and the way that iOS was implemented in the early years was the router would calculate the update to go to an iBGP neighbor and then send the update, and then repeat the same thing for every single neighbor. Now obviously this isn't really very efficient if you're 50 neighbors, you're 50 updates to compute, and then 50 updates to send. As computer programmers will know, you don't compute the same thing 50 times. You compute it once and then send the results out to the end devices that need those results. So what the peer group does is group peers that have the same outbound policy. The updates are calculated once and then are sent out to all members of the group. The advantages that we see even today, is that a peer group makes configuration easier, it makes the configuration less prone to error, it makes configuration more readable because we're now grouping the same configuration that shared amongst all peers in one place, and then using that configuration to calculate the updates for all those peers. And because it only applies to outbound policy, members of the peer group can have different inbound policy, and not only can we use peer groups for internal BGP, we can use it for external BGP as well. Advantages when Cisco first introduced peer groups into iOS, was it also lowered the router CPU load and helped the iBGP mesh build much more quickly. But more recently internal coding "Improvements in iOS" has seen the introduction of something called an update group which automatically or programmatically work sight which peers have the same outbound policy and group them all together. So even though peer groups may seem to have been replaced by Cisco's update groups which we'll look at in a minute, many operators still find peer groups extremely useful for ease of operation of the network. If we look at the slide, the configuration is quite simple. We set up the peer group, we give it a nice descriptive name and then we put all the configuration as a member of that peer group. So for internal BGP, that can even include AS number, and we include things like the updates- source being loopback interface, as we learned earlier. We want to send-community to our iBGP neighbors, and there might be any other outbound policy as well. And then we take the peer group and we apply it to the neighbors that share the same outbound policy. Note how we've got one example: the neighbor 10.0.0.2 which also has a separate inbound policy. We can use a peer group for external BGP as well. This is most commonly seen at Internet Exchange Points, where a member of an Internet Exchange Point will have the same outbound policy to many peers at that exchange point. This is very useful for again ease of management of the large number of peers you typically see at an Internet Exchange Point. Now peer groups are generally considered obsolete by many because it's been replaced by update groups which is an internal coding, but it's still considered best practice by many network operators. And indeed Cisco has introduced a concept called peer templates which is a much enhanced version of peer groups allowing much more complex constructs. But peer groups still are widely used by many network operators. if we quickly look at the update groups, this is an internal iOS coding and it takes over the performance gains introduced by peer groups, where the router, the software configuration, works out which neighbors share the same outbound policy, and then groups these altogether. You can find out the status of the update groups on an internal BGP speaking router simply by looking at the the prefix in the BGP table. You can also list all the peers which belong to a particular update group. Router may have a few update groups, so you can just list them all by group number, and you see which routers, which neighbors are members of each group. So my recommendation would still be to use peer groups, if you're using Cisco IOS. Use it for iBGP, use it for eBGP. I found us, network operators, scale the network. It just makes things much easier to manage and much more scalable in the longer term, and it makes the configuration really easy to read. You avoid having to repeat the same configuration for neighbor after neighbor, after neighbor. And indeed in the most sophisticated networks, whether the national research and education networks or national backbones, where they have many different types of iBGP peers. Grouping these different type of iBGP peers into different peer groups means ease of management for the network operation staff. Likewise for Internet Exchange Points, we often find peer groups being used here for eBGP as well, and it's also useful when the operator has many BGP customers or using the same AS number. So this will be BGP customers that are multihomed onto the the local network following the principles in RFC 2270, which will describe at some point in this series. Cisco's peer groups have been replicated by other equipment vendors, and have a similar concept. For example, if we look at Juniper, Juniper has something called a BGP group, and if you look at the slide in front of you, you will see a typical configuration for iBGP and the format is a similar idea in that you're grouping neighbors that are sharing the same configuration in the same group. And this BGP group likewise can be used for internal BGP, external BGP and so on.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.