eBGP Peer Groups

eBGP Peer Groups

Erick N. Borgard CCNP

BGP peer groups is a topic that might make you scratch your head wondering how this all works. More importantly, you might be asking yourself; “How is this supposed to help save me some configuration steps?"  Maybe you were researching but still never understood BGP Peer Groups. This document is going to explain the concept behind BGP peer groups and demystify this concept once and for all.

Please take Diagram 1-1 into consideration. (Click to enlarge)

Before we get into the configuration, it's important to discuss the overall purpose of BGP peer groups.  So what are BGP peer groups?  BGP peer groups are groupings of BGP speaking routers that share the same policies and options.  Suppose we needed to peer with our loopback addresses instead of the directly connected interfaces.  The engineer would have to type neighbor x.x.x.x ebgp-mulithop x & neighborx.x.x.x update-source lox for every single peering.  In addition to that, the engineer would have to apply the ingress and egress BGP policy to each and every peering.   BGP peer groups allow the engineer to apply that policy only once.  Let's take Dallas for example.  In this example, you are only asked to create peering with 3 routers. Supposed you have 150 or maybe 300 peering you manage.  If all of those devices will share the same policy and options, you can create BGP peer groups and stick them in a peer group.  Maybe, you get something that states the following on an exam.  Create eBGP peers between R1, R2, R3, &R4. All routers share the same routing policy.  Use the minimum configuration possible.  Well, if you create each and every peering individually, you aren't using the minimal amount of lines of configuration because it was explicitly stated that all peerings share the same ingress and egress policy.

Here is Dallas' BGP and policy configuration.

router bgp 177

 no synchronization

 bgp log-neighbor-changes

 bgp scan-time 5

 network 1.1.1.1 mask 255.255.255.255

 network 11.1.11.1 mask 255.255.255.255

 network 11.11.11.11 mask 255.255.255.255

 network 111.11.11.11 mask 255.255.255.255

 neighbor EBGP_PEERS peer-group

 neighbor EBGP_PEERS ebgp-multihop 255

 neighbor EBGP_PEERS filter-list 200 in

 neighbor EBGP_PEERS filter-list 100 out

 neighbor 10.77.10.2 remote-as 110

 neighbor 10.77.10.2 peer-group EBGP_PEERS

 neighbor 10.77.20.2 remote-as 220

 neighbor 10.77.20.2 peer-group EBGP_PEERS

 neighbor 10.77.30.2 remote-as 330

 neighbor 10.77.30.2 peer-group EBGP_PEERS

 neighbor 155.1.12.2 remote-as 177

 neighbor 155.1.12.2 next-hop-self

 no auto-summary

!

!

ip as-path access-list 100 permit ^$

ip as-path access-list 200 permit ^110$

ip as-path access-list 200 permit ^220$

ip as-path access-list 200 permit ^330$

Now at this point, you might be asking yourself how is all that configuration is supposed to make our life easier? I know I had the very same question until I began to work with BGP peer groups.  All of that code sure doesn't look like it's making my life any easier.  Let's imagine that your initial set up is working great and life is good.  The cramping in your fingers is finally starting to subside from the initial configuration.

The company announces growth and expansion. (See Diagram 1-2) The engineer is tasked with creating two BGP peerings with Calgary and Hawaii.  They should get the same BGP policy that Seattle, Cape Town and London gets.  Here is where the magic happens. In order to form those two(2) peering, the engineer only needs 6 lines of code and only 4 of those 6 lines apply to the peering!  The engineer needs to add the neighbor remote-as command.  The engineer also needs to add the neighbor peer-group EBGP_PEERS command to associate the peering with the peer group.  That's it.  The only other change that needs to be made is to add the peering AS(s) to the as-path access list for each peering.  That's it. It's that simple once the initial configuration is in place.

Diagram 1-2 (Click to enlarge)

The additional configuration for the two peerings  would be:

Dallas

neighbor 10.77.40.2 remote-as 440

neighbor 10.77.40.2 peer-group EBGP_PEERS

neighbor 10.77.50.2 remote-as 550

neighbor 10.77.50.2 peer-group EBGP_PEERS

!

!

ip as-path access list 200 permit ^440$

ip as-path access-list 200 permit ^550$

That's really all there is to eBGP peer groups.  Suppose those 2 additional peerings were 15 additional and you had to apply the same filter-list and options to every peering.  All of those lines of code start to add up, creating an enormous amount of overhead.  Isn't it fantastic that the engineer has a great tool in his back pocket like BGP peer groups to help simplify the configuration and administration of large scale BGP operations?