CCNP BSCI 20

If you look at the previous few articles, you'd notice that BGP actually requires a lot of commands for each neighbor. If you have multiple neighbors, you'd have to type the same commands over and over a lot of times. This is where BGP peer groups come in!
BGP peer groups allow you to quickly put multiple similar routers into the same group. This is very useful if you look at the previously used topology:


Suppose that we've decided to run IBGP on all routers in the local AS. However, this would mean that we must type the same commands used on R1 on R2 and R4 as well. The better approach is to actually create a group configuration. We'll then apply the group configuration to all IBGP neighbors.

To do this, we'll create a peer-group:
neighbor IBGPPEERGROUP peer-group
neighbor IBGPPEERGROUP remote-as 1000
neighbor IBGPPEERGROUP next-hop-self
neighbor IBGPPEERGROUP update-source lo0

We'll now add the neighbors as shown:
neighbor 10.0.1.1 peer-group IBGPPEERGROUP
neighbor 10.0.1.2 peer-group IBGPPEERGROUP
neighbor 10.0.1.4 peer-group IBGPPEERGROUP

Now, we would want to configure this into a full mesh topology. We cannot simply have R1 and R3 peer with R2 and R4. This is because of the IBGP split-horizon rule. The rule states that a route learned from IBGP would not be advertised to another IBGP neighbor. This would mean that if R2 or R4 learns of a route from R3, it would not pass it on to R1. To make them pass the routes, we would need to configure route reflectors, which is an advanced topic explained later on. For now, we'll need to configure all routers to have a full mesh neighborship with every other router.

Now, let's talk about how BGP neighbors form relationships. There are many steps and here's a summary:
1) Idle: Verifying route to neighbor
2) Active: Attempting to connect to neighbor
3) Open Sent: Open Message Sent to Neighbor
4) Open Confirm: Open Message Replied from Neighbor
5) Established

On step 4, if neighbor did not reply with a correct Open message, you would cycle back to Active instead. This is known as BGP Stuck-In-Active. (Of course, don't confuse this with EIGRP Stuck-In-Active where a broadcast storm is created while looking for backup routes.)

The first two steps take the longest time. We can actually view the neighbor forming process using the debug command:
debug ip bgp

We'll then clear the neighbor relationships using:
clear ip bgp *

This would be the typical output of a normal relationship forming process:

*Mar  1 00:05:27.971: BGP: 1.1.1.1 went from Idle to Active
*Mar  1 00:05:27.987: BGP: 1.1.1.1 open active, local address 1.1.1.2
*Mar  1 00:05:28.023: BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 362ms (850ms max, 87% jitter)
*Mar  1 00:05:28.387: BGP: 1.1.1.1 open active, local address 1.1.1.2
*Mar  1 00:05:28.443: BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 659ms (1000ms max, 87% jitter)
*Mar  1 00:05:29.107: BGP: 1.1.1.1 open active, local address 1.1.1.2
*Mar  1 00:05:29.151: BGP: 1.1.1.1 went from Active to OpenSent
*Mar  1 00:05:29.155: BGP: 1.1.1.1 sending OPEN, version 4, my as: 1, holdtime 180 seconds
*Mar  1 00:05:29.239: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  1 00:05:29.243: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:05:29.247: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:05:29.247: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:05:29.251: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:05:29.251: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:05:29.255: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:05:29.259: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:05:29.259: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:05:29.263: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:05:29.263: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:05:29.267: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 1.1.1.1 rcvd OPEN w/ remote AS 1
*Mar  1 00:05:29.267: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Mar  1 00:05:29.267: BGP: 1.1.1.1 went from OpenConfirm to Established
*Mar  1 00:05:29.271: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Now we'll check out some BGP verification commands. The most commonly used one is:
show ip bgp

This command is used to check the BGP prefixes table. From here, you can see which routes are learned, and which of those learned routes are accepted. You can also derive information about a route to find out why it wasn't added to the topology table.

Another show command which shows more information in a summarized form is:
show ip bgp sum

The above command shows all the routes statistics (instead of actual routes) as well as neighbors relationships.

There is a very detailed way to display information about neighbors. This is typically not used unless you require the details. Most of the useful information are in the first two commands. To see detailed neighbor information, use:
show ip bgp nei

If there are routes not showing up in the routing table (a route with no caret), you can see the reason why it isn't added using:
show ip bgp rib-failure

RIB-Failure sounds disgusting, but it actually means Routing Information Base Failure.

This should be enough to get you prepared for the next few BGP articles. If you thought BGP up to this point sounds nightmarish, wait till you see the BGP Attributes.