External BGP for Enterprises ccie course training institute in delhi ncr

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

Some of the core operational concepts of BGP mirror those of EIGRP and OSPF. BGP
first forms a neighbor relationship with peers. BGP then learns information from its neighbors,
placing that information in a table–the BGP table. Finally, BGP analyzes the BGP
table to choose the best working route for each prefix in the BGP table, placing those
routes into the IP routing table.
This section discusses external BGP (eBGP), focusing on two of the three aspects of how a
routing protocol learns routes: forming neighborships and exchanging the reachability or
topology information that is stored in the BGP table. First, this section examines the baseline
configuration of eBGP peers (also called neighbors), along with several optional settings
that may be needed specifically for eBGP connections. This configuration should
result in working BGP neighborships. Then, this section examines the BGP table, listing the
prefix/length and path attributes (PA) learned from the Internet, and the IP routing table.
eBGP Neighbor Configuration
At a minimum, a router participating in BGP needs to configure the following settings:
■ The router’s own ASN (router bgp asn global command)
■ The IP address of each neighbor and that neighbor’s ASN (neighbor ip-address
remote-as remote-asn BGP subcommand)
For example, consider a typical multihomed Enterprise Internet design, as shown in
Figure 13-1. In this case, the following design requirements have already been decided, but
you must then determine the configuration, knowing the information in the following list
and the figure:
■ The Enterprise uses ASN 11.
■ The connection to ISP1 (two T-1’s) is considered the primary connection, with the
connection to ISP3 (one T-1) being secondary.
■ ISP1 advertises a default route, plus full updates.
■ ISP1 uses ASN 1.
■ ISP3 advertises a default route, plus partial updates that includes only ISP3’s local
customers.
■ ISP3 uses ASN 3.
■ Each ISP uses the IP address of its lowest-numbered interface for its peer relationships.
For Router E1, the BGP configuration requires only three commands, at least to configure
BGP to the point where E1 will form neighborships with the two other routers. (Note that
this chapter continues to change and add to this configuration when introducing new
concepts.) The example also shows the configuration on Routers I1-1 and I3-1 added
Requirements for Forming eBGP Neighborships
Routers must meet several requirements to become BGP neighbors:
■ A local router’s ASN (on the router bgp asn command) must match the neighboring
router’s reference to that ASN with its neighbor remote-as asn command.
■ The BGP router IDs of the two routers must not be the same.
■ If configured, MD5 authentication must pass.
■ Each router must be part of a TCP connection with the other router, with the remote
router’s IP address used in that TCP connection matching what the local router configures
in a BGP neighbor remote-as command.
Consider the first two items in this list. First, the highlights in Example 13-1 demonstrate
the first of the four requirements. Next, the second requirement in the list requires only a
little thought if you recall the similar details about router IDs (RID) with EIGRP and
OSPF. Like EIGRP and OSPF, BGP defines a 32-bit router ID, written in dotted-decimal
notation. And like EIGRP and OSPF, BGP on a router chooses its RID the same general
way, by using the following steps, in order, until a BGP RID has been chosen:
■ Configured: Use the setting of the bgp router-id rid router subcommand.
■ Highest Loopback: Choose the highest numeric IP address of any up/up loopback
interface, at the time the BGP process initializes.
■ Highest other interface: Choose the highest numeric IP address of any up/up nonloopback
interface, at the time the BGP process initializes.
The third requirement in the list, the MD5 authentication check, occurs only if authentication
has been configured on at least one of the two routers, using the neighbor
neighbor-ip password key command. If two BGP neighbors configure this command, referring
to the other routers’ IP address, while configuring a matching MD5 authentication
key value, the authentication passes. If both omit this command, then no authentication
occurs, and the neighbor can still work. However, if the keys do not match, or if only one
router configures authentication, then authentication fails.
The fourth neighbor requirement–that the IP addresses used for the neighbor TCP connection
match–requires a more detailed discussion. BGP neighbors first form a TCP connection;
later, BGP messages flow over that connection, which allows BGP routers to
know when the messages arrived at the neighbor, and when they did not.
A BGP router creates the TCP connection by trying to establish a TCP connection to the
address configured in the neighbor neighbor-ip remote-as command. However, IOS does
not require the BGP configuration to explicitly state the source address that router uses
when establishing this TCP connection, and if not explicitly configured, IOS picks an IP
address on the local router. By default, IOS chooses its BGP source IP address for a given
neighbor as the interface IP address of the outgoing interface of the route used to forward
packets to that neighbor. That’s a lot of words to fight through, and much more easily seen
with a figure, such as Figure 13-2, which focuses on the eBGP connection between E1 and
I1-1 shown in Figure 13-1.
Chapter 13: External BGP 425
Key
Topic
Key
Topic
www.CareerCert.info
426 CCNP ROUTE 642-902 Official Certification Guide
1 2
3
E1 I1-1
10.1.1.1 10.1.1.2 TCP BGP
Source Destination
10.1.1.1/30
S0/0/0 Routing Table
Destination Outgoing
10.1.1.0/30 S0/0/0 neighbor 10.1.1.1 ....
neighbor 10.1.1.2 remote-as 1
4
5
Figure 13-2 A Default Choice for Update Source
A description of the steps in logic shown in the figure follows:
Step 1. E1 finds the neighbor 10.1.1.2 command, so E1 sends the BGP messages for
this neighbor inside packets with destination IP address 10.1.1.2.
Step 2. E1 looks in the IP routing table for the route that matches destination 10.1.1.2.
Step 3. The route matched in Step 2 lists S0/0/0 as outgoing interface.
Step 4. E1’s interface IP address for S0/0/0 is 10.1.1.1, so E1 uses 10.1.1.1 as its source
IP address for this BGP peer.
Step 5. The neighbor command on the other router, I1-1, must refer to E1’s source IP
address (10.1.1.1 in this case).
Now, consider again the last of the four requirements to become neighbors. Restated, for
proper operation, the BGP update source on one router must match the IP address configured
on the other router’s neighbor command, and vice versa. As shown in Figure 13-2, E1
uses update source 10.1.1.1, with I1-1 configuring the neighbor 10.1.1.1... command. Conversely,
I1-1 uses 10.1.1.2 as its update source for this neighbor relationship, with E1 configuring
a matching neighbor 10.1.1.2 command.
Note: The update source concept applies per neighbor.
Issues When Redundancy Exists Between eBGP Neighbors
In many cases, a single Layer 3 path exists between eBGP neighbors. For example, a single
T1, or single T3, or maybe a single MetroE Virtual Private Wire Service (VPWS) path exists
between the two routers. In such cases, the eBGP configuration can simply use the interface
IP addresses on that particular link. For example, in Figure 13-1, a single serial link
exists between Routers E1 and I3-1, and they can reasonably use the serial link’s IP addresses,
as shown in Example 13-1.
However, when redundant Layer 3 paths exist between two eBGP neighbors, the use of interface
IP addresses for the underlying TCP connection can result in an outage when only
one of the two links fails. BGP neighborships fail when the underlying TCP connection
Key
Topic
www.CareerCert.info
fails. TCP uses a concept called a socket, which consists of a local TCP port number and
an IP address. That IP address must be associated with a working interface (an interface
whose state is line status up, line protocol up, per the show interfaces command). If the
interface whose IP address is used by BGP were to fail, then the TCP socket would fail,
closing the TCP connection. As a result, the BGP neighborship can only be up when the
associated interfaces also happens to be up.
Two alternative solutions exist in this case. One option would be to configure two
neighbor commands on each router, one for each of the neighbor’s interface IP addresses.
This solves the availability issue, because if one link fails, the other neighborship can remain
up and working. However, in this case, both neighborships exchange BGP routes,
consuming bandwidth and more memory in the BGP table.
The preferred option, which uses loopback interfaces as the TCP connection endpoints,
solves the availability problem while avoiding the extra overhead. The two routers each
configure a loopback interface and IP address, and use those loopback IP addresses as the
source of their single BGP TCP connection. If one of the multiple links fails, the loopback
interface does not fail. As long as the two routers have working routes to reach each
other’s loopback IP addresses, the TCP connection does not fail.
Configuring eBGP peers to use a loopback interface IP address with BGP requires several
steps, as follows:
Step 1. Configure an IP address on a loopback interface on each router.
Step 2. Tell BGP on each router to use the loopback IP address as the source IP address
using the neighbor... update-source ip-address command.
Step 3. Configure the BGP neighbor command on each router to refer to the other
router’s loopback IP address at the neighbor IP address in the neighbor
neighbor-ip remote-as command.
Step 4. Make sure each router has IP routes so that they can forward packets to the
loopback interface IP address of the other router.
Step 5. Configure eBGP multihop using the neighbor... ebgp-multihop hops command.
The first three steps in the list require configuration on both the routers. Figure 13-3
shows the details related to the first three steps, focusing on Router E1’s use of its loopback1
interface (based on Figure 13-1).
The fourth step in the list is an overt reminder that for TCP to work, both routers must be
able to deliver packets to the IP address listed in the neighbor commands. Because the
neighbor commands now refer to loopback IP addresses, the routers cannot rely on connected
routes for forwarding the packets. To give each router a route to the other router’s
loopback, you can run an instance of an IGP to learn the routes, or just configure static
routes. If using static routes, make sure to configure the routes so that all redundant paths
would be used (as seen in upcoming Example 13-2). If using an IGP, make sure the configuration
allows the two routers to become IGP neighbors over all redundant links as well.
Chapter 13: External BGP 427
Key
Topic
www.CareerCert.info
428 CCNP ROUTE 642-902 Official Certification Guide
Router E1
neighbor 1.1.1.1 remote-as 1
Router I1-1
neighbor 1.1.1.1 update-source loopback 1
interface loopback 1
ip address 11.11.11.11 255.255.255.255 neighbor 11.11.11.11 remote-as 11
neighbor 11.11.11.11 update-source loopback2
interface loopback2
ip address 1.1.1.1 255.255.255.255
Figure 13-3 Using Loopbacks with Update Source for eBGP
eBGP Multihop Concepts
The fifth configuration step for using loopback IP addresses with eBGP peers refers to a
feature called eBGP multihop. By default, when building packets to send to an eBGP peer,
IOS sets the IP Time-To-Live (TTL) field in the IP header to a value of 1. With this default
action, the eBGP neighborship fails to complete when using loopback interface IP addresses.
The reason is that when the packet with TTL=1 arrives at the neighbor, the neighbor
discards the packet.
The logic of discarding the BGP packets may be a bit surprising, so an example can help.
For this example, assume the default action of TTL=1 is used and that eBGP multihop is
not configured yet. Router E1 from Figure 13-1 is trying to establish a BGP connection to
I1-1, using I1-1’s loopback IP address 1.1.1.1, as shown in Figure 13-3. The following occurs
with the IP packets sent by E1 when attempting to form a TCP connection for BGP to use:
Step 1. E1 sends a packet to destination address 1.1.1.1, TTL=1.
Step 2. I1-1 receives the packet. Seeing that the packet is not destined for the receiving
interface’s IP address, I1-1 passes the packet off to its own IP forwarding (IP
routing) logic.
Step 3. I1-1’s IP routing logic matches the destination (1.1.1.1) with the routing table
and finds interface loopback 2 as the outgoing interface.
Step 4. I1-1’s IP forwarding logic decrements TTL by 1, decreasing TTL to 0, and as a
result, I1-1 discards the packet.
In short, the internal IOS packet forwarding logic decrements the TTL before giving the
packet to the loopback interface, meaning that the normal IP forwarding logic discards
the packet.
Configuring the routers with the neighbor ebgp-multihop 2 command, as seen in upcoming
Example 13-2, solves the problem. This command defines the TTL that the router will
use when creating the BGP packets (2 in this case). As a result, the receiving router will
decrement the TTL to 1, so the packet will not be discarded.
Key
Topic
www.CareerCert.info
Chapter 13: External BGP 429
Configuring for eBGP Redundancy and Authentication
To pull these optional configuration steps together, Example 13-2 shows a new configuration
for E1 and I1-1 (as compared with Example 13-1). In this case:
■ Both routers use BGP authentication, with authentication key fred.
■ Two Layer 3 paths exist between E1 and I1-1, so the configuration uses all the steps
required to make both routers use the loopback interfaces listed in Figure 13-3.
■ Both routers use eBGP multihop. (Otherwise, the neighborships would fail.)
■ Both routers use static routes to provide reachability to the loopback interfaces, with
two routes each, one using each redundant path.
Example 13-2 Broader eBGP Configuration Example
! Configuration on router E1
interface loopback 1
ip address 11.11.11.11 255.255.255.255
!
ip route 1.1.1.1 255.255.255.255 s0/0/0
ip route 1.1.1.1 255.255.255.255 s0/0/1
!
router bgp 11
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source loopback 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 password fred
! Next commands are on I1-1
interface loopback 2
ip address 1.1.1.1 255.255.255.255
!
ip route 11.11.11.11 255.255.255.255 s0/0/0
ip route 11.11.11.11 255.255.255.255 s0/0/1
!
router bgp 1
neighbor 11.11.11.11 remote-as 11
neighbor 11.11.11.11 update-source loopback 2
neighbor 11.11.11.11 ebgp-multihop 2
neighbor 11.11.11.11 password fred
Besides listing the various configuration commands, this example is also the first in this
chapter that demonstrates how to configure multiple settings for a single BGP neighbor.
The IOS BGP neighbor command has many options. To set those options for a single
neighbor, the command begins with neighbor neighbor-ip-address, followed by the parameters.
So, instead of one neighbor command with a large number of parameters, the
configuration includes several neighbor commands, each listing the IP address of the same
neighbor, but each listing a different set of parameters. In this case, each router now uses
www.CareerCert.info
430 CCNP ROUTE 642-902 Official Certification Guide
Table 13-2 BGP Neighbor States
State Typical Reasons
Idle The BGP process is either administratively down or awaiting the next retry attempt.
Connect The BGP process is waiting for the TCP connection to be completed. You cannot
determine from this state information whether the TCP connection can
complete.
Active The TCP connection has been completed, but no BGP messages have been
sent to the peer yet.
Opensent The TCP connection exists, and a BGP Open message has been sent to the
peer, but the matching Open message has not yet been received from the
other router.
Openconfirm An Open message has been both sent to and received from the other router.
The next step is to receive a BGP Keepalive message (to confirm all neighborrelated
parameters matched) or BGP Notification message (to learn there is
some mismatch in neighbor parameters).
Key
Topic
four neighbor commands: one to define the remote ASN, one for the update source, one
to enable eBGP multihop, and one for the authentication key.
BGP Internals and Verifying eBGP Neighbors
Similar to OSPF, the BGP neighbor relationship goes through a series of states over time.
Although the Finite State Machine (FSM) for BGP neighbor states has many twists and
turns, particularly for handling exceptions, retries, and failures, the overall process works
as follows:
Step 1. A router tries to establish a TCP connection with the IP address listed on a
neighbor command, using well-known destination port 179.
Step 2. When the three-way TCP connection completes, the router sends its first BGP
message, the BGP Open message, which generally performs the same function
as the EIGRP and OSPF Hello messages. The Open message contains several
BGP parameters, including those that must be verified before allowing the
routers to become neighbors.
Step 3. After an Open message has been sent and received and the neighbor parameters
match, the neighbor relationship is formed, and the neighbors reach
established state.
Table 13-2 lists the various BGP states. If all works well, the neighborship reaches the final
state: established. When the neighbor relationship (also called a BGP peer or BGP peer
connection) reaches the established state, the neighbors can send BGP Update messages,
which list PAs and prefixes. However, if neighbor relationship fails for any reason, then the
neighbor relationship can cycle through all the states listed in Table 13-2 while the routers
periodically attempt to bring up the neighborship.
www.CareerCert.info
Chapter 13: External BGP 431
Table 13-2 BGP Neighbor States
State Typical Reasons
Established All neighbor parameters match, the neighbor relationship works, and the peers
can now exchange Update messages.
Verifying eBGP Neighbor Status
The two most common commands to display a BGP neighbor’s status are show ip bgp
summary and show ip bgp neighbors [neighbor-id]. Interestingly, most people use the
first of these commands because it supplies a similar amount of information, 1 line per
neighbor, as do the familiar show ip eigrp neighbors and show ip ospf neighbor commands.
The show ip bgp neighbors command lists a large volume of output per neighbor,
which, although useful, usually contains far too much information for the verification of
the current neighbor state. Examples 13-3 and 13-4 show samples of the output of each of
these two commands on Router E1, respectively, based on the configuration shown in
Example 13-2, with some description following each example.
Example 13-3 Summary Information with the show ip bgp summary Command
E1# show ip bgp summary
BGP router identifier 11.11.11.11, local AS number 11
BGP table version is 26, main routing table version 26
6 network entries using 792 bytes of memory
7 path entries using 364 bytes of memory
6/4 BGP path/bestpath attribute entries using 888 bytes of memory
5 BGP AS-PATH entries using 120 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 2196 total bytes of memory
BGP activity 12/6 prefixes, 38/31 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 60 61 26 0 0 00:45:01 6
192.168.1.2 4 3 153 159 26 0 0 00:38:13 1
The first line in the summary lists the local router’s BGP RID (11.11.11.11), along with the
local router’s ASN (11). The rest of the summary focuses on statistics for the BGP table entries.
The bottom of the output lists a heading line (highlighted in the output), plus one
line per neighbor, with two neighbors in this case. The Neighbor column lists the IP address
as defined on the local router’s neighbor command and not the neighbor’s BGP RID.
Other notable information includes the neighbor’s ASN (as configured on the local
router’s neighbor remote-as command), the time spent in the current state, and an interesting
heading: State/PfxRcd.
www.CareerCert.info
432 CCNP ROUTE 642-902 Official Certification Guide
This final heading, State/PfxRcd, either lists the BGP neighbor state, as summarized in
Table 13-2, or the number of prefixes received (PfxRcd) from that neighbor. A numeric
value under this heading implies a neighbor state of established, because the peers must
be in established state before Updates can be sent. If the peer is not in an established state,
the value in this heading lists the text name of the current BGP state.
Example 13-4 shows a sample of the show ip bgp neighbors 1.1.1.1 command on router
E1, which displays information about the connection to Router I1-1 in Figure 13-1. This
command lists several facts not seen in the shorter show ip bgp summary command output
in Example 13-3. The example highlights some of those key items, with the following
comments referring to those highlighted items, in order:
■ The neighbor is an eBGP neighbor (external link).
■ The neighbor’s BGP RID (1.1.1.1).
■ The current state (Established) is explicitly listed.
■ Route refresh is enabled (as referenced in Chapter 14’s section titled “Clearing BGP
Neighbors”).
■ The eBGP multihop setting (2 hops).
■ Local and remote TCP socket information (IP addresses and port numbers).
Example 13-4 Detailed Information with the show ip bgp neighbors Command
E1# show ip bgp neighbors 1.1.1.1
BGP neighbor is 1.1.1.1, remote AS 1, external link
BGP version 4, remote router ID 1.1.1.1
BGP state = Established, up for 00:45:08
Last read 00:00:02, last write 00:00:38, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 16 12
Keepalives: 43 47
Route Refresh: 0 0
Total: 61 61
Default minimum time between advertisement runs is 30 seconds
www.CareerCert.info
Chapter 13: External BGP 433
For address family: IPv4 Unicast
BGP table version 26, neighbor version 26/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: —— ——
Prefixes Current: 6 6 (Consumes 312 bytes)
Prefixes Total: 19 7
Implicit Withdraw: 11 0
Explicit Withdraw: 2 1
Used as bestpath: n/a 5
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: ———— ———-
AS_PATH loop: n/a 2
Total: 0 2
Number of NLRIs in the update sent: max 3, min 1
Address tracking is enabled, the RIB does have a route to 1.1.1.1
Connections established 2; dropped 1
Last reset 00:45:10, due to Peer closed the session
External BGP neighbor may be up to 2 hops away.
Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Minimum incoming TTL 0, Outgoing TTL 2
Local host: 11.11.11.11, Local port: 179
Foreign host: 1.1.1.1, Foreign port: 28995
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x8217A0):
Timer Starts Wakeups Next
Retrans 49 0 0x0
TimeWait 0 0 0x0
AckHold 49 46 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
www.CareerCert.info
434 CCNP ROUTE 642-902 Official Certification Guide
iss: 2070882650 snduna: 2070884280 sndnxt: 2070884280 sndwnd: 15890
irs: 3327995414 rcvnxt: 3327996693 rcvwnd: 16156 delrcvwnd: 228
SRTT: 300 ms, RTTO: 306 ms, RTV: 6 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable, md5
IP Precedence value : 6
Datagrams (max data segment is 516 bytes):
Rcvd: 98 (out of order: 0), with data: 50, total data bytes: 1278
Sent: 99 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0),
with data: 50, tot
al data bytes: 1629
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
E1# show tcp brief
TCB Local Address Foreign Address (state)
66D27FE0 192.168.1.1.179 192.168.1.2.16489 ESTAB
66D27378 11.11.11.11.179 1.1.1.1.28995 ESTAB
Note that the end of the example shows another command that you can use to confirm
the TCP socket details of the underlying TCP connection: show tcp brief.
Administratively Controlling Neighbor Status
Interestingly, Cisco IOS provides a means by which network operations personnel can administratively
disable any BGP neighbor. To do so, the operator would enter BGP configuration
mode and issue the neighbor neighbor-ip shutdown command. This command
brings down the current neighbor to an idle state. Later, when the BGP connection should
be brought up, the operator should repeat the process, but with the no version of the
command (no neighbor neighbor-ip shutdown).
These commands can be particularly useful to try in lab when learning BGP. Teamed with
the debug ip bgp command, you can bring down neighbors and see the somewhat-readable
BGP messages. These messages list the BGP states from Table 13-2. It also shows the
information inside the Open messages. Example 13-5 shows a sample, with the debug
messages that note a state transition highlighted. The output also lists the show ip bgp
summary command, with the administratively idle state created by the neighbor 1.1.1.1
shutdown BGP configuration command on Router E1.
Example 13-5 BGP Shutdown and BGP Neighbor State Transitions
E1# debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
E1# conf t
www.CareerCert.info
Chapter 13: External BGP 435
Enter configuration commands, one per line. End with CNTL/Z.
E1(config)# router bgp 11
E1(config-router)# neighbor 1.1.1.1 shutdown
E1(config-router)#
*Aug 11 20:23:01.335: BGPNSF state: 1.1.1.1 went from nsf_not_active to
nsf_not_active
*Aug 11 20:23:01.335: BGP: 1.1.1.1 went from Established to Idle
*Aug 11 20:23:01.335: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Admin. Shutdown
E1(config-router)# do show ip bgp summary
! lines omitted for brevity
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 87 87 0 0 0 00:00:06 Idle (Admin)
192.168.1.2 4 3 173 183 41 0 0 00:58:47 1
E1(config-router)# no neighbor 1.1.1.1 shutdown
E1(config-router)#
*Aug 11 20:23:26.571: BGP: 1.1.1.1 went from Idle to Active
*Aug 11 20:23:26.571: BGP: 1.1.1.1 open active, local address 11.11.11.11
*Aug 11 20:23:26.575: BGP: 1.1.1.1 read request no-op
*Aug 11 20:23:26.575: BGP: 1.1.1.1 went from Active to OpenSent
*Aug 11 20:23:26.575: BGP: 1.1.1.1 sending OPEN, version 4, my as: 11, holdtime
180 seconds
*Aug 11 20:23:26.579: BGP: 1.1.1.1 send message type 1, length (incl. header) 45
*Aug 11 20:23:26.583: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Aug 11 20:23:26.587: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Aug 11 20:23:26.587: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Aug 11 20:23:26.587: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2
(Capability) len 6
*Aug 11 20:23:26.587: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Aug 11 20:23:26.587: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Aug 11 20:23:26.587: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2
(Capability) len 2
*Aug 11 20:23:26.587: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Aug 11 20:23:26.587: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all
address-families
*Aug 11 20:23:26.587: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2
(Capability) len 2
*Aug 11 20:23:26.587: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Aug 11 20:23:26.587: 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
*Aug 11 20:23:26.587: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Aug 11 20:23:26.591: BGP: 1.1.1.1 went from OpenConfirm to Established
*Aug 11 20:23:26.591: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
*Aug 11 20:23:26.603: BGP_Router: unhandled major event code 128, minor 0
www.CareerCert.info
436 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
Table 13-3 BGP Message Types
Message Purpose
Similarity with
EIGRP
Open Used to establish a neighbor relationship and exchange basic
parameters, including ASN and MD5 authentication values.
Hello
Keepalive Sent on a periodic basis to maintain the neighbor relationship.
The lack of receipt of a Keepalive message within the
negotiated Hold timer causes BGP to bring down the neighbor
connection.
Hello
Update Used to exchange PAs and the associated prefix/length
(NLRI) that use those attributes.
Update
Notification Used to signal a BGP error; typically results in a reset to the
neighbor relationship.
No direct
equivalent
BGP Message Summary
So far, this chapter has mentioned three of the four BGP messages. For reference, Table
13-3 lists the four BGP messages, with comparisons to EIGRP messages for perspective.