BGP Peer Groups | Dynamic Update Peer Groups-Tempemail Zone

As a router gains more and more BGP neighbors, two issues arise. The first one is that withmany neighbors, whenever the router needs to send out a BGP update, it has to create anupdate message for each neighbor. Second, the BGP configuration can get quite long andunwieldy. BGP peer groups were the original solution to both problems. Later, the same twoproblems were tackled slightly differently with dynamic update peer groups and BGPtemplates.
Peer groups
First, let’s look at peer groups. Peer groups have been around for a long time, so it’s safe toassume all Cisco routers and other routers that use a similar configuration style supportthem. And often the limitations of peer groups are not problematic, so they can still beuseful. Suppose we have the following configuration towards an ISP:

!
router bgp 65000
network 192.0.2.0/24
neighbor 10.0.75.21 remote-as 65030
neighbor 10.0.75.21 description ISP A link to their R1
neighbor 10.0.75.21 password 12345
neighbor 10.0.75.21 prefix-list only-our-prefix out
neighbor 10.0.75.21 filter-list only-our-as out
neighbor 10.0.75.25 remote-as 65030
neighbor 10.0.75.25 description ISP A link to their R2
neighbor 10.0.75.25 password 12345
neighbor 10.0.75.25 prefix-list only-our-prefix out
neighbor 10.0.75.25 filter-list only-our-as out
!

 
Astute readers will observe that the configuration for neighbors 10.0.75.21 and 10.0.75.25 is identical, except for the description. Using a peer group will make this more readable:

!
router bgp 65000
network 192.0.2.0/24
neighbor ispa peer-group
neighbor ispa remote-as 65030
neighbor ispa description ISP A
neighbor ispa password 12345
neighbor ispa prefix-list only-our-prefix out
neighbor ispa filter-list only-our-as out
neighbor 10.0.75.21 peer-group ispa
neighbor 10.0.75.21 description ISP A link to their R1
neighbor 10.0.75.25 peer-group ispa
neighbor 10.0.75.25 description ISP A link to their R2
!

 
The first neighbor that is defined here is a peer group, as is immediately obvious from the fact that this neighbor has a name rather than an address. That name is followed by the statement “peer-group”. Then, we can assign settings to the peer group as usual for any neighbor.
After the peer group is done, we define two actual neighbors. Normally, the first thing we need to specify for a BGP neighbor is the remote AS. Instead, we refer to the previously created peer group, so the remote AS specified there is used, along with all other settings specified for the peer group. The result is as follows:

Router# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 6
Advertised to peer-groups:
ispa

 
With the previous non peer group configuration, this looked slightly differently:

Router#s how ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 3
Advertised to non peer-group peers:
10.0.75.21 10.0.75.25

 
The output above reflects the difference in behavior with and without peer groups. Without any peer groups, the router generates a separate BGP Update message for each neighbor that needs to get the update. When neighbors are part of a peer group, the router just generates one Update message for that set of neighbors and sends copies of that single Update message to all members of the peer group. With many neighbors and complex filters, this can save a lot of work for the router.
It is possible to overrule settings inherited from a peer group. For instance, if we add a BGP session towards a third router to our peer group configuration example, but this BGP session has a different MD5 password, the additions could look as follows:

!
router bgp 65000
neighbor 10.0.75.29 peer-group ispa
neighbor 10.0.75.29 description ISP A link to their R3
neighbor 10.0.75.29 password 67890
!

 
So neighbors 10.0.75.21 and 10.0.75.25 inherit the password setting from the peer group, but for 10.0.75.29 the “neighbor 10.0.75.29 password 67890” line overrules peer group password setting.
Because the router must be able to send the same Update messages to all peer group members, outgoing filters and route maps must be shared by all peer group members. So those need to be part of the peer group configuration and can’t be set for individual members. However, it’s perfectly fine to have separate incoming filters and route maps for different neighbors, and have those overrule the ones set for the peer group.
Some additional complexity arises when we use peer groups with IPv6. Peer groups can have session related settings, such as the remote AS and the MD5 password, but also address family related settings, such as filters and route maps. When applying a peer group to a neighbor in the BGP configuration, that peer group is applied to the session settings as well the address family IPv4 settings. The peer group does not automatically apply to the address family IPv6 settings.
This means that for eBGP sessions, it’s necessary to have different peer groups for IPv4 neighbors and IPv6 neighbors, because with the same peer group, it wouldn’t be possible to deactivate IPv4 for the IPv6 neighbors without also deactivating IPv4 for the IPv4 neighbors (which would be an unusual configuration, to say the least).
It’s best to not exchange IPv6 prefixes over an IPv4 eBGP session or the other way around because this can get in the way of properly updating the next hop address. With iBGP, the next hop address isn’t updated, so here there is no trouble exchanging IPv6 prefixes over IPv6. That could look like this:

!
router bgp 65000
neighbor ibgp peer-group
neighbor ibgp remote-as 65000
neighbor ibgp password 12345
neighbor 203.0.113.75 peer-group ibgp
neighbor 203.0.113.77 peer-group ibgp
!
address-family ipv6
neighbor ibgp activate
neighbor 203.0.113.75 peer-group ibgp
neighbor 203.0.113.77 peer-group ibgp
exit-address-family
exit
!

 
However, the configuration would be shorter (granted, only by a single line) by not using a peer group in the address-family ipv6 part:

!
address-family ipv6
neighbor 203.0.113.75 activate
neighbor 203.0.113.77 activate
exit-address-family
exit
!

 
Dynamic update peer groups
These days, it’s no longer necessary to explicitly create peer groups for performance reasons. Instead, Cisco routers automatically create dynamic update peer groups that allow the router to send the same Update message to multiple neighbors if the outgoing policies for multiple neighbors are the same. This results in the following output:

Router# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 8
Advertised to update-groups:
2

 
There is no need to configure dynamic update peer groups, they are created and maintained automatically. However, it helps to use the same filters and route maps for multiple neighbors where possible to allow the router to create the dynamic update peer groups.
BGP templates
With the performance aspects covered by dynamic update peer groups, BGP templates replace the configuration simplification aspect of peer groups. A BGP template version of the second example above would look like this:

!
router bgp 65000
template peer-policy ispa-filters
prefix-list only-our-prefix out
filter-list only-our-as out
exit-peer-policy
!
template peer-session ispa-session
remote-as 65030
description ISP A
password 12345
exit-peer-session
!
neighbor 10.0.75.21 inherit peer-session ispa-session
neighbor 10.0.75.21 inherit peer-policy ispa-filters
neighbor 10.0.75.21 description ISP A link to their R1
neighbor 10.0.75.25 inherit peer-session ispa-session
neighbor 10.0.75.25 inherit peer-policy ispa-filters
neighbor 10.0.75.25 description ISP A link to their R2
neighbor 10.0.75.29 inherit peer-session ispa-session
neighbor 10.0.75.29 inherit peer-policy ispa-filters
neighbor 10.0.75.29 description ISP A link to their R3
neighbor 10.0.75.29 password 67890
!

 
There’s now a clean separation of the session and the policy configuration. Policy templates are address family specific. A template may inherit settings from another template, to a maximum depth of eight templates total. Higher levels can overrule settings in lower level, deeper nested templates. An iBGP example could look like this:

!
router bgp 65000
template peer-session ibgp
remote-as 65000
password 12345
exit-peer-session
!
template peer-session ibgp-east
description iBGP sessions to routers East
inherit peer-session ibgp
exit-peer-session
!
template peer-session ibgp-west
description iBGP sessions to routers West
inherit peer-session ibgp
exit-peer-session
!
neighbor 203.0.113.71 inherit peer-session ibgp-east
neighbor 203.0.113.73 inherit peer-session ibgp-east
neighbor 203.0.113.75 inherit peer-session ibgp-west
neighbor 203.0.113.77 inherit peer-session ibgp-west
!
address-family ipv6
neighbor 203.0.113.75 activate
neighbor 203.0.113.77 activate
exit-address-family
exit
!

 
This configuration makes it very easy to shut down a group of BGP sessions, for instance, in preparation for maintenance:

!
router bgp 65000
template peer-session ibgp-east
shutdown
exit-peer-session
!
!

 
Afterwards, we can then bring all the sessions back up again:

!
router bgp 65000
template peer-session ibgp-east
no shutdown
exit-peer-session
!
!

 
This shows the advantage of inheritance that BGP templates provide: we can now still change settings for all iBGP neighbors in one place, under the ibgp template, while we can also change settings for a subset of iBGP neighbors.

Tempemail , Tempmail Temp email addressess (10 minutes emails)– When you want to create account on some forum or social media, like Facebook, Reddit, Twitter, TikTok you have to enter information about your e-mail box to get an activation link. Unfortunately, after registration, this social media sends you dozens of messages with useless information, which you are not interested in. To avoid that, visit this Temp mail generator: tempemail.co and you will have a Temp mail disposable address and end up on a bunch of spam lists. This email will expire after 10 minute so you can call this Temp mail 10 minute email. Our service is free! Let’s enjoy!

Leave a Reply

Your email address will not be published. Required fields are marked *