BGP Update Generation

BGP Update Generation

The following are different methods of improving BGP update generation-

1. Peer groups
2. BGP dynamic update peer groups
3. Update packing enhancement
4. 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.

Network topology:

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