Peer Groups

When working with BGP, you will find that many routers require the same neighbor statements in their configurations. No matter what kind of routing policy you're implementing and how you're implementing it, if you want the same policy lists applied to a group of neighbors, you'll end up giving the same parameters on all the neighbor statements. This process can be error-prone and confusing.

Peer groups eliminate redundant configuration lines by allowing you to define a group and then make each neighbor a part of that group. For example, assume that you have a route map that enforces some routing policy. Instead of applying that route map separately on each neighbor, you can add all the neighbors to a peer group and then apply the route map for the group as a whole.

In Figure 10-3, we have a network (AS 500) with three BGP routers. Instead of defining the same route maps for each neighbor in Router 1's configuration, we create a peer group called policy1. This peer group defines the non-unique configuration items. We then make Router 2 and Router 3 members of this peer group. Here is the BGP configuration for Router 1:

Figure 10-3. iBGP network with peer-group configuration

router bgp 500 ! Define our peer group and apply the configuration items to it neighbor policy1 peer-group neighbor policy1 remote-as 500 neighbor policy1 next-hop-self neighbor policy1 route-map map1 in ! Now define our neighbors as part of peer group policy1 neighbor 10.10.2.1 peer-group policy1 neighbor 10.10.3.1 peer-group policy1

We can use the same peer-group configuration on Router 2 and Router 3. Unfortunately, we'll still have to type almost identical configurations on each router, but at least we've reduced the amount of duplication on the individual routers. We still have to keep our router configurations in sync, but the peer-group concept makes it easier to keep the configuration uniform within a router.