Category Archives: 3.7.a Describe implement and troubleshoot peer relationships

3.7.a Describe implement and troubleshoot peer relationships

from rfc 4271:

3.2.  Routing Information Base

The Routing Information Base (RIB) within a BGP speaker consists of
three distinct parts:

a) Adj-RIBs-In: The Adj-RIBs-In stores routing information learned
from inbound UPDATE messages that were received from other BGP
speakers.  Their contents represent routes that are available
as input to the Decision Process.

b) Loc-RIB: The Loc-RIB contains the local routing information the
BGP speaker selected by applying its local policies to the
routing information contained in its Adj-RIBs-In.  These are
the routes that will be used by the local BGP speaker.  The
next hop for each of these routes MUST be resolvable via the
local BGP speaker’s Routing Table.

c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP
speaker selected for advertisement to its peers.  The routing
information stored in the Adj-RIBs-Out will be carried in the
local BGP speaker’s UPDATE messages and advertised to its
peers.

In summary, the Adj-RIBs-In contains unprocessed routing information
that has been advertised to the local BGP speaker by its peers; the
Loc-RIB contains the routes that have been selected by the local BGP
speaker’s Decision Process; and the Adj-RIBs-Out organizes the routes
for advertisement to specific peers (by means of the local speaker’s
UPDATE messages).

3.7.a Describe implement and troubleshoot peer relationships

3.7.a [i] Peer-group, template

cciebgp

R3#sh run | b router bg
router bgp 123
bgp log-neighbor-changes
neighbor my-as peer-group
 neighbor my-as remote-as 123
 neighbor my-as update-source Loopback1
neighbor 1.1.1.1 peer-group my-as
 neighbor 1.1.1.1 password cisco
neighbor 2.2.2.2 peer-group my-as

the peer group is called my-as (or my ass)

the point of the peer group is to limit configuration keystrokes by grouping like values together…

in the case above the similar features are ibgp AS and update-source, then the neighbors are assigned to the peer group…

note the individual statement for neighbor 1.1.1.1 as r3 is using md5 authentication only with r1…

R1(config)#router bgp 123
R1(config-router)#neighb 3.3.3.3 pass chicso
R1(config-router)#
*Mar  8 10:32:45.243: %TCP-6-BADAUTH: Invalid MD5 digest from 3.3.3.3(179) to 1.1.1.1(31783) tableid – 0
R1(config-router)#
*Mar  8 10:32:46.643: %TCP-6-BADAUTH: Invalid MD5 digest from 3.3.3.3(179) to 1.1.1.1(31783) tableid – 0
R1(config-router)#neighb 3.3.3.3 pass cisco
R1(config-router)#do sh ip bgp summ
BGP router identifier 1.1.1.1, local AS number 123
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4          123       4       5        1    0    0 00:02:15                                    0
3.3.3.3         4          123       4       5        1    0    0 00:02:17                                    0
172.16.16.6     4          678       0       0        1    0    0 never                            Idle

according to wendell:

BGP peer groups do not allow any new BGP configuration settings; they
simply allow you to group BGP neighbor configuration settings into a group, and then apply that set of settings to a neighbor using the neighbor peer-group command. Additionally, BGP builds one set of Update messages for the peer group, applying routing policies for the entire group—rather than one router at a time—thereby reducing some BGP processing and memory overhead.