Peer groups
BGP dynamic update peer groups
Update packing enhancement
BGP read-only mode
This section will cover BGP peer groups.
Peer groups provide a mechanism for BGP peers that have the same outbound policy to be associated with each other. Peer groups provide two major benefits- configuration reduction and ability of replicate updates between peers.
The peer group is formed, and the common outbound policy is applied to the peer group. Each peer that has the same outbound policy is assigned to the peer group which greatly reduces redundant configuration on routers that have a large number of BGP peers.
A peer group is configured under BGP configuration and all the common outbound policies are applied to the peer-group.
Example peer-group configuration
Router(config)# router bgp 100
Router(config-router)# neighbor INTERNAL peer-group
Router(config-router)# neighbor INTERNAL version 4
Router(config-router)# neighbor INTERNAL remote-as 100
Router(config-router)# neighbor INTERNAL update-source Loopback 0
Router(config-router)# neighbor 2.2.2.2 peer-group INTERNAL
Router(config-router)# neighbor 3.3.3.3 peer-group INTERNAL
This greatly reduces redundant configuration in a large environment. Because all the peers have the same outbound policy, the update messages they send are the same. This means that the BGP update message is generated once for each peer-group and then is reused for all the neighbors.
Consider in a non-peer-group environment, the BGP process must walk the entire BGP table for every peer, and create updates for each peer independently. If there are 100 BGP routes and 100 BGP peers, the router must walk through the BGP table 100 times, essentially walking through 10,000 prefixes.
In a peer-group environment, BGP process walks the entire BGP table only once per peer-group. A peer-group leader is elected for each peer-group i.e. peer with lowest IP address. The BGP process walks the BGP table for the peer group leader, and creates update messages. These update messages are replicated for all other peer-group members. So, for 100 BGP peers, the router walks the BGP table only once, creates update messages for peer-group leader but all peer-group members receive the same update message. Hence, the router walk only 100 prefixes compared to 10,000 prefixes in non-peer-group environment. This reduces the processor and memory requirements.
The peer-group members must be in sync with the peer-group leader for replication to take place. The peer-group member is synchronized with the leader if the set of BGP paths advertised to the leader has also been advertised to peer-group member. If the peer-group member initializes after a peer-group is configured, the member will not be synchronized with the peer-group. In this case, the router updates the non-synchronized peer-group member as it would update a non-peer-group member until that peer becomes synchronized with the peer-group leader.
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
Addition of another peer Core-3 router:
Core-3 router also peers with Edge-1 router. The BGP table of Core-3 router is completely out-of-sync hence Edge-1 router will format UPDATE messages for Core-3 router individually until the BGP tables of all the members are in-sync. Until then the replication would not be perfect. If a next UPDATE message was to be advertised by Edge-1 router, it will be formatted for group-leader and replicated to all group-members including Core-3 router.
UPDATE message formation and replication
*Mar 1 17:31:08.671: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
Edge-1#
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (format) 10.1.1.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 10.2.2.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 1.1.1.1/32, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (format) 4.4.4.4/32, next 1.1.1.1, metric 0, path 200
*Mar 1 17:31:08.783: BGP(0): updgrp 1 - 5.5.5.5 updates replicated for neighbors:
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 3 2.2.2.2 11 9 0/1000 5/0
2 1 10.2.2.2 4 0 0/100 5/0
0 comments:
Post a Comment