Troubleshooting BGP

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009478a.shtml#bgp_trouble_multi_out

Why Do BGP Neighbors Toggle Between Idle, Connect, and Active States?

Introduction

BGP routers can exchange routing information only when they establish peer connection between them. The BGP peer establishment begins with the creation of a TCP connection between the devices. After TCP connection established, the BGP devices attempt to create a BGP session by the exchange of BGP Open messages, where they exchange BGP version, AS number, hold time and BGP identifier.

On the process of BGP peer establishment, several things can prevent a BGP neighborship from correctly being established. This document discusses some of these possible reasons for this issue:

• The neighbor statement is incorrect.
• No routes to the neighbor address exist , or the default route (0.0.0.0/0) is being used to reach the peer.
• The update-source command is missing under BGP.
• A typing error resulted in the wrong IP address in the neighbor statement or the wrong autonomous system number. You need to check your configurations.
• Unicast is broken due to one of these reasons:
  
  • Wrong virtual circuit (VC) mapping in an Asynchronous Transfer Mode (ATM) or Frame Relay environment in a highly redundant network.
  • Access list is blocking the unicast or TCP packet.
  • Network Address Translation (NAT) is running on the router and is translating the unicast packet.
  • Layer 2 is down.
• The lack of the ebgp-multihop command is a common mistake that keep peers from appearing. This issue is discussed in the second example.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Network Diagram

Use this network diagram as an example for the first three causes:

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

The Neighbor Statement Is Incorrect

The show ip bgp summary command on Router R1-AGS shows the session is active.

R1-AGS(9)# show ip bgp summary
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       0       0        0    0    0 never    Active

Here are the configurations:

R1-AGS	R6-2500
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 10.10.10.2 remote-as 400 neighbor 10.10.10.2 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2	interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 10.10.10.1 remote-as 400 neighbor 10.10.10.1 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1

The debug ip bgp and debug ip tcp transactions commands show the TCP connection failing.

Debugs on Router R1-AGS:

BGP: 10.10.10.2 open active, local address 2.2.2.2
TCB00135978 created
TCB00135978 setting property 0 16ABEA
TCB00135978 bound to 2.2.2.2.11039
TCP: sending SYN, seq 3797113156, ack 0
TCP0: Connection to 10.10.10.2:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [11039 -> 10.10.10.2(179)]
TCP0: state was SYNSENT -> CLOSED [11039 -> 10.10.10.2(179)]
TCP0: bad seg from 10.10.10.2 -- closing connection: seq 0 ack 3797113157 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB00135978 destroyed
BGP: 10.10.10.2 open failed: Connection refused by remote host
TCP: sending RST, seq 0, ack 1965664223
TCP: sent RST to 1.1.1.1:11016 from 10.10.10.1:179

Debugs on Router R6-2500:

TCP: sending RST, seq 0, ack 3797113157
TCP: sent RST to 2.2.2.2:11039 from 10.10.10.2:179
BGP: 10.10.10.1 open active, local address 1.1.1.1
TCB001E030C created
TCB001E030C setting property TCP_WINDOW_SIZE (0) 194F7A
TCB001E030C setting property TCP_TOS (11) 194F79
TCB001E030C bound to 1.1.1.1.11016
TCP: sending SYN, seq 1965664222, ack 0
TCP0: Connection to 10.10.10.1:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [11016 -> 10.10.10.1(179)]
TCP0: state was SYNSENT -> CLOSED [11016 -> 10.10.10.1(179)]
TCP0: bad seg from 10.10.10.1 -- closing connection: seq 0 ack 1965664223 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB 0x1E030C destroyed
BGP: 10.10.10.1 open failed: Connection refused by remote host

Solution

In order to remedy this situation, either correct the loopback address in the neighbor statement, or remove the update-source command from the configuration.

In this example, the address is corrected.

R1-AGS	R6-2500
router bgp 400 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2	router bgp 400 neighbor 2.2.2.2 remote-as 400 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1

A look at the show ip bgp summary command shows Router R1-AGS is in the established state.

R1-AGS(9)#show ip bgp summary
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Note: If a BGP session is not establlished after a router reloads, configure the neighbor soft-reconfiguration statements under BGP in order to soft reset.

No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer

The show ip bgp summary command on Router R1-AGS shows the session is currently active.

R1-AGS(9)#show ip bgp summary
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   400       0       0        0    0    0 never    Active

Here are the configurations:

R1-AGS	R6-2500
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 300 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0	interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 300 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0

If you run debug commands, it shows there is no route to the neighbor.

Debugs on Router R1-AGS:

BGP: 1.1.1.1 open active, delay 9568ms
BGP: 1.1.1.1 multihop open delayed 19872ms (no route)
BGP: 1.1.1.1 multihop open delayed 12784ms (no route)

Debugs on Router R6-2500:

BGP: 2.2.2.2 open active, delay 6531ms
BGP: 2.2.2.2 multihop open delayed 14112ms (no route)
BGP: 2.2.2.2 multihop open delayed 15408ms (no route)

Solution

The solution is to include a route to the next hop in the BGP neighbor statement. You can use a static or dynamic route depending on the situation. In an internal BGP (iBGP) environment where you have more control, you can propagate the route dynamically using a routing protocol. In an external BGP (eBGP) situation, it is recommended to configure a static route to reach the next hop.

Use the neighbor ebgp-multihop command only when the IP address you are peering to on your eBGP peer is not directly connected.

In this example, a static route was used.

R1-AGS	R6-2500
router bgp 300 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2	router bgp 400 neighbor 2.2.2.2 remote-as 300 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1

The show ip bgp summary command shows Router R1-AGS is in the established state.

R1-AGS(9)# show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Note: A default route is never going to be used to establish a BGP session (iBGP/eBGP), and you see the same (no route) output in the debugs, although you are able to ping the BGP neighbor. The solution is again to add a route to the BGP neighbor.

The update-source Command Is Missing Under BGP

The show ip bgp summary command on Router R1-AGS shows the session is active.

R1-AGS(9)# show ip bgp summary
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   400       0       0        0    0    0 never    Active

Here are the configurations:

R1-AGS	R6-2500
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 1.1.1.1 remote-as 400 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2	interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 400 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1

If you run debug commands, it shows the TCP connection fails.

Debugs on Router R1-AGS:

TCP: sending RST, seq 0, ack 2248020754
TCP: sent RST to 10.10.10.2:11018 from 2.2.2.2:179
BGP: 1.1.1.1 open active, local address 10.10.10.1
TCB0016B06C created
TCB0016B06C setting property 0 16ADEA
TCB0016B06C bound to 10.10.10.1.11042
TCP: sending SYN, seq 4099938541, ack 0
TCP0: Connection to 1.1.1.1:179, advertising MSS 536
TCP0: state was CLOSED -> SYNSENT [11042 -> 1.1.1.1(179)]
TCP0: state was SYNSENT -> CLOSED [11042 -> 1.1.1.1(179)]
TCP0: bad seg from 1.1.1.1 -- closing connection: seq 0 ack 4099938542 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB0016B06C destroyed
BGP: 1.1.1.1 open failed: Connection refused by remote host

Debugs on Router R6-2500:

BGP: 2.2.2.2 open active, local address 10.10.10.2
TCB00194800 created
TCB00194800 setting property TCP_WINDOW_SIZE (0) E6572
TCB00194800 setting property TCP_TOS (11) E6571
TCB00194800 bound to 10.10.10.2.11018
TCP: sending SYN, seq 2248020753, ack 0
TCP0: Connection to 2.2.2.2:179, advertising MSS 556
TCP0: state was CLOSED -> SYNSENT [11018 -> 2.2.2.2(179)]
TCP0: state was SYNSENT -> CLOSED [11018 -> 2.2.2.2(179)]
TCP0: bad seg from 2.2.2.2 -- closing connection: seq 0 ack 2248020754 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB 0x194800 destroyed
BGP: 2.2.2.2 open failed: Connection refused by remote host
TCP: sending RST, seq 0, ack 4099938542
TCP: sent RST to 10.10.10.1:11042 from 1.1.1.1:179

Solution

In order to solve this problem, either configure the update-source command on both routers, or remove the update-source command and change the neighbor statement on both routers. These are examples of both solutions.

Here, the update-source command is configured on both routers.

R1-AGS	R6-2500
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2	interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 400 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1

The show ip bgp summary command shows Router R1-AGS is in the established state.

R1-AGS(9)# show ip bgp summary
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   400       3       3        1    0    0 00:00:26        0

You only have to use the update-source command when someone is peering to your loopback address. This is true for an iBGP peer and an eBGP peer.

Here, the update-source command is removed and the neighbor statement is changed on both routers.

R1-AGS	R6-2500
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 10.10.10.2 remote-as 400	interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 10.10.10.1 remote-as 400

The show ip bgp summary command shows Router R1-AGS is in the established state.

R1-AGS(9)# show ip bgp summary
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       3       3        1    0    0 00:00:26        0

Sample Configuration for iBGP and eBGP With or Without a Loopback Address

Introduction

BGP is an exterior gateway protocol (EGP), used to perform interdomain routing in TCP/IP networks. A BGP router needs to establish a connection (on TCP port 179) to each of it's BGP peers before BGP updates can be exchanged. The BGP session between two BGP peers is said to be an external BGP (eBGP) session if the BGP peers are in different autonomous systems (AS) . A BGP session between two BGP peers is said to be an internal BGP (iBGP) session if the BGP peers are in the same autonomous systems.

By default, the peer relationship is established using the IP address of the interface closest to the peer router. However, using the neighbor update-source (registered customers only) command, any operational interface, including the loopback interface, can be specified to be used for establishing TCP connections. This method of peering using a loopback interface is useful since it will not bring down the BGP session when there are multiple paths between the BGP peers, which would otherwise result in tearing down the BGP session if the physical interface used for establishing the session goes down. In addition to that, it also allows the routers running BGP with multiple links between them to load balance over the available paths.

The sample configurations in this document are for iBGP and eBGP, both with and without a loopback addresses.

Note: You can use these configurations for establishing neighbor relationship. Refer to Using the Border Gateway Protocol for Interdomain Routing for more complex configurations.

Prerequisites

Requirements

Before you attempt this configuration, ensure that you meet this requirement:

• Knowledge of BGP protocols

Components Used

This document is not restricted to specific software and hardware versions. The command outputs shown in this document were taken from the 2500 Series Routers running IOS^® version 12.2(24a).

Conventions

For more information on document conventions, refer to Cisco Technical Tips Conventions.

Configure

This section contains the following configuration examples:

• iBGP Configuration
• eBGP Configuration
• iBGP Configuration with a Loopback Address
• eBGP Configuration with a Loopback Address

In this section, you are presented with the information to configure the features described in this document.

Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .

Network Diagram

This document uses this network setup:

iBGP Configuration

In this configuration, both routers are in AS 400.

R1-AGS	R6-2500
Current configuration: !-- Output suppressed. interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400!--- Enables BGP for the autonomous !--- system 400. neighbor 10.10.10.2 remote-as 400 !--- Specifies a neighbor 10.10.10.2 !--- in the remote AS 400, making !--- this an iBGP connection. !-- Output suppressed. end	Current configuration: !-- Output suppressed. interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 10.10.10.1 remote-as 400 !-- Output suppressed. end

eBGP Configuration

In this configuration, the router R1-AGS is in AS 300 and Router R6-2500 is in AS 400.

R1-AGS	R6-2500
Current configuration: !-- Output suppressed interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 300!--- Enables BGP for the autonomous !--- system 300. neighbor 10.10.10.2 remote-as 400 !--- Specifies a neighbor 10.10.10.2 !--- in the remote AS 400, making !--- this an eBGP connection.!-- Output suppressed. end	Current configuration: !-- Output suppressed. interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 10.10.10.1 remote-as 300 !-- Output suppressed. end

Peers must be directly connected when using eBGP. If they are not directly connected, the neighbor ebgp-multihop (registered customers only)command must be used and a path through an IGP or static route to reach the peer must exist in order for the routers to establish neighbor relationship. In the configuration above, R1-AGS router belongs to AS 300 while R6-2500 router belongs to AS 400.

iBGP Configuration with a Loopback Address

You can configure iBGP using a loopback address (or any other operational interface) as shown in this section.

R1-AGS

R6-2500

Current configuration: !-- Output suppressed. interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 300 neighbor 2.2.2.2 remote-as 300 neighbor 2.2.2.2 update-source Loopback0 !--- This command specifies that the TCP !--- connection with the specified external !--- peer should be established using the !--- address on the loopback interface. ! ip route 2.2.2.2 255.255.255.255 10.10.10.2 !--- This static route ensures that the !--- remote peer address used for peering !--- is reachable. !-- Output suppressed. end

Current configuration: !-- Output suppressed. interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 300 neighbor 1.1.1.1 remote-as 300 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.1 !-- Output suppressed. end

eBGP Configuration with a Loopback Address

You can also configure eBGP using a loopback address (or any other operational interface) as shown in this section. Loopback interfaces are used in this manner to guarantee reachability in networks with multiple paths as shown in the Load Sharing Using the Loopback Address as a BGP Neighborsection of Load Sharing with BGP in Single and Multihomed Environments: Sample Configurations.

R1-AGS

R6-2500

Current configuration: !-- Output suppressed. interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 300 neighbor 2.2.2.2 remote-as 400 neighbor 2.2.2.2 ebgp-multihop 2 !--- This command changes the ttl value in !--- order to allow the packet to reach the !--- external BGP peer which is not directly !--- connected or is using an interface other !--- than the directly connected interface. neighbor 2.2.2.2 update-source Loopback0 !--- This command specifies that the TCP !--- connection with the external BGP !--- peer should be established using the !--- address on the loopback interface. ! ip route 2.2.2.2 255.255.255.255 10.10.10.2 !--- This static route ensures that the !--- remote peer address used for peering !--- is reachable. !-- Output suppressed. end

Current configuration: !-- Output suppressed. interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 1.1.1.1 remote-as 300 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.1 !-- Output suppressed. end

Verify

These sections provide information you can use to confirm your configurations are working properly. Certain show commands are supported by theOutput Interpreter Tool , which allows you to view an analysis of show command output.

Verify iBGP Configuration

Use the show ip bgp neighbors (registered customers only) command to display information about the TCP and Border Gateway Protocol (BGP) connections and verify if the BGP peer is established. The output of the show ip bgp neighbors command below shows the BGP state as 'Established', which indicates that the BGP peer relationship has been established successfully.

R1-AGS# show ip bgp neighbors | include BGP
BGP neighbor is 10.10.10.2,  remote AS 400, internal link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:04:20
  BGP table version 1, neighbor version 1
R1-AGS#

The show ip bgp neighbors command has been used above with the modifier | include BGP. This makes the output more readable by filtering the the command output and displaying the relevant parts only.

In addition, the show ip bgp summary (registered customers only) command can also be used to display the status of all BGP connections, as shown below.

R1-AGS(9)# show ip bgp summary
BGP router identifier 10.1.1.2, local AS number 400 
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       3       3        1    0    0 00:00:26        0

Verify eBGP Configuration

Use the show ip bgp neighbors (registered customers only) command to display information about the TCP and Border Gateway Protocol (BGP) connections and verify if the BGP peer is established. The output of the show ip bgp neighbors command below shows the BGP state as 'Established', which indicates that the BGP peer relationship has been established successfully.

R1-AGS# show ip bgp neighbors | include BGP
BGP neighbor is 10.10.10.2,  remote AS 400, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:00:17
  BGP table version 1, neighbor version 1

In addition, the show ip bgp summary (registered customers only) command can also be used to display the status of all BGP connections, as shown below.

R1-AGS(9)# show ip bgp summary
BGP router identifier 10.10.10.1, local AS number 300
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       3       3        1    0    0 00:00:26        0

Verify iBGP Configuration with a Loopback Address

Use the show ip bgp neighbors (registered customers only) command to display information about the TCP and Border Gateway Protocol (BGP) connections and verify if the BGP peer is established. The output of the show ip bgp neighbors command below shows the BGP state as 'Established', which indicates that the BGP peer relationship has been established successfully.

R1-AGS# show ip bgp neighbors | include BGP
BGP neighbor is 2.2.2.2,  remote AS 300, internal link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:00:28
  BGP table version 1, neighbor version 1
R1-AGS#

In addition, the show ip bgp summary (registered customers only) command can also be used to display the status of all BGP connections, as shown below.

R1-AGS(9)# show ip bgp summary
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   400       3       3        1    0    0 00:00:26        0

Verify eBGP Configuration with a Loopback Address

Use the show ip bgp neighbors (registered customers only) command to display information about the TCP and Border Gateway Protocol (BGP) connections and verify if the BGP peer is established. The output of the show ip bgp neighbors command below shows the BGP state as 'Established', which indicates that the BGP peer relationship has been established successfully.

R1-AGS# show ip bgp neighbors | include BGP
BGP neighbor is 2.2.2.2,  remote AS 400, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:00:16
  BGP table version 1, neighbor version 1
  External BGP neighbor may be up to 2 hops away.

In addition, the show ip bgp summary (registered customers only) command can also be used to display the status of all BGP connections, as shown below.

R1-AGS(9)# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 300
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   400       3       3        1    0    0 00:00:26        0

Troubleshoot

Refer to Why Do BGP Neighbors Toggle Between Idle, Connect, and Active States? and Troubleshooting BGP for troubleshooting information.

Broadcast/Network Ping

If there is a need to ping several devices in one same subnet and broadcast domain, you can do several commands or ping like the one below.

R1#ping 10.1.1.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.255, timeout is 2 seconds:

Reply to request 0 from 10.1.1.2, 80 ms
Reply to request 0 from 10.1.1.3, 80 ms
Reply to request 0 from 10.1.1.4, 80 ms
Reply to request 1 from 10.1.1.4, 52 ms
Reply to request 1 from 10.1.1.2, 52 ms
Reply to request 1 from 10.1.1.3, 52 ms
Reply to request 2 from 10.1.1.3, 84 ms
Reply to request 2 from 10.1.1.4, 84 ms
Reply to request 2 from 10.1.1.2, 84 ms
Reply to request 3 from 10.1.1.2, 20 ms
Reply to request 3 from 10.1.1.4, 20 ms
Reply to request 3 from 10.1.1.3, 20 ms
Reply to request 4 from 10.1.1.3, 16 ms
Reply to request 4 from 10.1.1.4, 16 ms
Reply to request 4 from 10.1.1.2, 16 ms

You can also use the Network Address.

R1#ping 10.1.1.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:

Reply to request 0 from 10.1.1.4, 84 ms
Reply to request 0 from 10.1.1.2, 112 ms
Reply to request 0 from 10.1.1.3, 84 ms
Reply to request 1 from 10.1.1.2, 72 ms
Reply to request 1 from 10.1.1.3, 72 ms
Reply to request 1 from 10.1.1.4, 72 ms
Reply to request 2 from 10.1.1.4, 68 ms
Reply to request 2 from 10.1.1.2, 68 ms
Reply to request 2 from 10.1.1.3, 68 ms
Reply to request 3 from 10.1.1.3, 64 ms
Reply to request 3 from 10.1.1.4, 64 ms
Reply to request 3 from 10.1.1.2, 64 ms
Reply to request 4 from 10.1.1.4, 72 ms
Reply to request 4 from 10.1.1.3, 72 ms
Reply to request 4 from 10.1.1.2, 72 ms

You can also do a single ping command to check if all links in the routers are up or not. You can the following below. This works on all kinds of WAN interfaces connected to the router.

R1#ping 255.255.255.255 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 16 ms
Reply to request 0 from 10.1.1.4, 16 ms
Reply to request 0 from 10.1.1.3, 16 ms
Reply to request 0 from 10.1.1.2, 16 ms

This command can be helpful during the CCIE lab exam to verify if interfaces are working. I assume that all who read this already knew this from their CCNA studies but I guess there are exceptions. Even the smartest Cisco Engineers forget basic commands sometimes. Let me know if you are one of those who didn't know this one.