Chapter 11. BGP

This chapter covers the following subjects:

BGP Fundamentals: This section provides an overview of the fundamentals of the BGP routing protocol.

Basic BGP Configuration: This section walks through the process of configuring BGP to establish a neighbor session and how routes are exchanged between peers.

Route Summarization: This section provides an overview of how route summarization works with BGP and some of the design considerations with summarization.

Multiprotocol BGP for IPv6: This section explains how BGP provides support for IPv6 routing and configuration.

RFC 1654 defines Border Gateway Protocol (BGP) as an EGP standardized path vector routing protocol that provides scalability, flexibility, and network stability. When BGP was created, the primary design consideration was for IPv4 inter-organization connectivity on public networks like the Internet and on private dedicated networks. BGP is the only protocol used to exchange networks on the Internet, which has more than 780,000 IPv4 routes and continues to grow. Due to the large size of the BGP tables, BGP does not advertise incremental updates or refresh network advertisements as OSPF and IS-IS do. BGP prefers stability within the network, as a link flap could result in route computation for thousands of routes.

This chapter covers the fundamentals of BGP (path attributes, address families, and inter-router communication), BGP configuration, route summarization, and support for IPv6. Chapter 12, “Advanced BGP,” explains common scenarios in enterprise environments for BGP, route filtering and manipulation, BGP communities, and the logic BGP uses for identifying a route as the best path.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 11-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”

Table 11-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

BGP Fundamentals

1–4

Basic BGP Configuration

5–8

Route Summarization

9

Multiprotocol BGP for IPv6

10

1. Which of the following autonomous systems are private? (Choose two.)

  1. 64,512–65,535

  2. 65,000–65,535

  3. 4,200,000,000–4,294,967,294

  4. 4,265,000–4,265,535,016

2. Which BGP attribute must be recognized by all BGP implementations and advertised to other autonomous systems?

  1. Well-known mandatory

  2. Well-known discretionary

  3. Optional transitive

  4. Optional non-transitive

3. True or false: BGP supports dynamic neighbor discovery by both routers.

  1. True

  2. False

4. True or false: A BGP session is always one hop away from a neighbor.

  1. True

  2. False

5. True or false: The IPv4 address family must be initialized to establish a BGP session with a peer using IPv4 addressing.

  1. True

  2. False

6. Which command is used to view the BGP neighbors and their hello intervals?

  1. show bgp neighbors

  2. show bgp afi safi neighbors

  3. show bgp afi safi summary

  4. show afi bgp interface brief

7. How many tables does BGP use for storing prefixes?

  1. One

  2. Two

  3. Three

  4. Four

8. True or false: BGP advertises all its paths for every prefix so that every neighbor can build its own topology table.

  1. True

  2. False

9. Which BGP command advertises a summary route to prevent link-flap processing by downstream BGP routers?

  1. aggregate-address network subnet-mask as-set

  2. aggregate-address network subnet-mask summary-only

  3. summary-address network subnet-mask

  4. summary-address network mask subnet-mask

10. True or false: The IPv6 address family must be initialized to establish a BGP session with a peer using IPv6 addressing.

  1. True

  2. False

Answers to the “Do I Know This Already?” quiz:

1 A, C

2 A

3 B

4 B

5 B

6 B

7 C

8 B

9 B

10 A

Foundation Topics

BGP Fundamentals

From the perspective of BGP, an autonomous system (AS) is a collection of routers under a single organization’s control, using one or more IGPs and common metrics to route packets within the AS. If multiple IGPs or metrics are used within an AS, the AS must appear consistent to external ASs in routing policy. An IGP is not required within an AS; an AS could use BGP as the only routing protocol.

Autonomous System Numbers

An organization requiring connectivity to the Internet must obtain an autonomous system number (ASN). ASNs were originally 2 bytes (16-bit range), which made 65,535 ASNs possible. Due to exhaustion, RFC 4893 expanded the ASN field to accommodate 4 bytes (32-bit range). This allows for 4,294,967,295 unique ASNs, providing quite an increase from the original 65,535 ASNs.

Two blocks of private ASNs are available for any organization to use, as long as they are never exchanged publicly on the Internet. ASNs 64,512–65,535 are private ASNs in the 16-bit ASN range, and 4,200,000,000–4,294,967,294 are private ASNs within the extended 32-bit range.

The Internet Assigned Numbers Authority (IANA) is responsible for assigning all public ASNs to ensure that they are globally unique. IANA requires the following items when requesting a public ASN:

  • Proof of a publicly allocated network range

  • Proof that Internet connectivity is provided through multiple connections

  • Need for a unique routing policy from providers

In the event that an organization cannot provide this information, it should use the ASN provided by its service provider.

Note

It is imperative to use only the ASN assigned by IANA, the ASN assigned by your service provider, or a private ASN. Using another organization’s ASN without permission could result in traffic loss and cause havoc on the Internet.

Path Attributes

BGP uses path attributes (PAs) associated with each network path. The PAs provide BGP with granularity and control of routing policies within BGP. The BGP prefix PAs are classified as follows:

  • Well-known mandatory

  • Well-known discretionary

  • Optional transitive

  • Optional non-transitive

Per RFC 4271, well-known attributes must be recognized by all BGP implementations. Well-known mandatory attributes must be included with every prefix advertisement; well-known discretionary attributes may or may not be included with a prefix advertisement.

Optional attributes do not have to be recognized by all BGP implementations. Optional attributes can be set so that they are transitive and stay with the route advertisement from AS to AS. Other PAs are non-transitive and cannot be shared from AS to AS. In BGP, the Network Layer Reachability Information (NLRI) is a routing update that consists of the network prefix, prefix length, and any BGP PAs for the specific route.

Loop Prevention

BGP is a path vector routing protocol and does not contain a complete topology of the network, as link-state routing protocols do. BGP behaves like distance vector protocols, ensuring that a path is loop free.

The BGP attribute AS_Path is a well-known mandatory attribute and includes a complete list of all the ASNs that the prefix advertisement has traversed from its source AS. AS_Path is used as a loop-prevention mechanism in BGP. If a BGP router receives a prefix advertisement with its AS listed in the AS_Path attribute, it discards the prefix because the router thinks the advertisement forms a loop.

Figure 11-1 shows the loop-prevention mechanism:

  • AS 100 advertises the 172.16.1.0/24 prefix to AS 200.

  • AS 200 advertises the prefix to AS 400, which then advertises the prefix to AS 300.

  • AS 300 advertises the prefix back to AS 100 with an AS_Path of 300 400 200 100. AS 100 sees itself in the AS_Path variable and discards the prefix.

A figure demonstrates path vector loop prevention.

Figure 11-1 Path Vector Loop Prevention

Address Families

Originally, BGP was intended for routing of IPv4 prefixes between organizations, but RFC 2858 added Multi-Protocol BGP (MP-BGP) capability by adding an extension called the address family identifier (AFI). An address family correlates to a specific network protocol, such as IPv4 or IPv6, and additional granularity is provided through a subsequent address-family identifier (SAFI) such as unicast or multicast. MBGP achieves this separation by using the BGP path attributes (PAs) MP_REACH_NLRI and MP_UNREACH_NLRI. These attributes are carried inside BGP update messages and are used to carry network reachability information for different address families.

Note

Some network engineers refer to Multiprotocol BGP as MP-BGP, and other network engineers use the term MBGP. Both terms refer to the same thing.

Every address family maintains a separate database and configuration for each protocol (address family + sub-address family) in BGP. This allows for a routing policy in one address family to be different from a routing policy in a different address family, even though the router uses the same BGP session with the other router. BGP includes an AFI and SAFI with every route advertisement to differentiate between the AFI and SAFI databases.

Inter-Router Communication

BGP does not use hello packets to discover neighbors, as do IGP protocols, and it cannot discover neighbors dynamically. BGP was designed as an inter-autonomous routing protocol, implying that neighbor adjacencies should not change frequently and are coordinated. BGP neighbors are defined by IP address.

BGP uses TCP port 179 to communicate with other routers. TCP allows for handling of fragmentation, sequencing, and reliability (acknowledgment and retransmission) of communication packets. Most recent implementations of BGP set the do-not-fragment (DF) bit to prevent fragmentation and rely on path MTU discovery.

IGPs follow the physical topology because the sessions are formed with hellos that cannot cross network boundaries (that is, single hop only). BGP uses TCP, which is capable of crossing network boundaries (that is, multi-hop capable). While BGP can form neighbor adjacencies that are directly connected, it can also form adjacencies that are multiple hops away.

A BGP session refers to the established adjacency between two BGP routers. Multi-hop sessions require that the router use an underlying route installed in the RIB (static or from any routing protocol) to establish the TCP session with the remote endpoint.

In Figure 11-2, R1 is able to establish a direct BGP session with R2. In addition, R2 is able to establish a BGP session with R4, even though it passes through R3. R1 and R2 use a directly connected route to locate each other. R2 uses a static route to reach the 10.34.1.0/24 network, and R4 has a static route to reach the 10.23.1.0/24 network. R3 is unaware that R2 and R4 have established a BGP session even though the packets flow through R3.

A figure depicts BGP single and multi-hop sessions. A figure shows four routers connected in serial. R1 is connected to R2 via 10.12.1.0/24, R2 is connected to R3 via 10.23.1.0/24, and R3 is connected to R4 via 10.34.1.0/24. BGP peering exists between R1 and R2 and also between R2 and R4.

Figure 11-2 BGP Single- and Multi-Hop Sessions

Note

BGP neighbors connected to the same network use the ARP table to locate the IP address of the peer. Multi-hop BGP sessions require routing table information for finding the IP address of the peer. It is common to have a static route or an IGP running between iBGP neighbors for providing the topology path information to establish the BGP TCP session. A default route is not sufficient to establish a multi-hop BGP session.

BGP can be thought of as a control plane routing protocol or as an application because it allows for the exchange of routes with a peer that is multiple hops away. BGP routers do not have to be in the data plane (path) to exchange prefixes, but all routers in the data path need to know all the routes that will be forwarded through them.

BGP Session Types

BGP sessions are categorized into two types:

  • Internal BGP (iBGP): Sessions established with an iBGP router that are in the same AS or that participate in the same BGP confederation. iBGP prefixes are assigned an administrative distance (AD) of 200 upon installation in the router’s RIB.

  • External BGP (eBGP): Sessions established with a BGP router that are in a different AS. eBGP prefixes are assigned an AD of 20 upon installation in the router’s RIB.

The following sections review these two types of BGP sessions.

iBGP

The need for BGP within an AS typically occurs when multiple routing policies are required or when transit connectivity is provided between autonomous systems. In Figure 11-3, AS 65200 provides transit connectivity to AS 65100 and AS 65300. AS 65100 connects at R2, and AS 65300 connects at R4.

A figure demonstrates about networks providing transit connectivity.

Figure 11-3 AS 65200 Providing Transit Connectivity

R2 could form an iBGP session directly with R4, but R3 would not know where to route traffic from AS 65100 or AS 65300 when traffic from either AS reaches R3, as shown in Figure 11-4, because R3 would not have the appropriate route forwarding information for the destination traffic.

A figure depicts iBGP prefix advertisement behavior.

Figure 11-4 iBGP Prefix Advertisement Behavior

You might assume that redistributing the BGP table into an IGP overcomes the problem, but this not a viable solution for several reasons:

  • Scalability: The Internet at the time of this writing has 780,000+ IPv4 network prefixes and continues to increase in size. IGPs cannot scale to that level of routes.

  • Custom routing: Link-state protocols and distance vector routing protocols use metric as the primary method for route selection. IGP protocols always use this routing pattern for path selection. BGP uses multiple steps to identify the best path and allows for BGP path attributes to manipulate the path for a specific prefix (NLRI). The path could be longer, and that would normally be deemed suboptimal from an IGP’s perspective.

  • Path attributes: All the BGP path attributes cannot be maintained within IGP protocols. Only BGP is capable of maintaining the path attribute as the prefix is advertised from one edge of the AS to the other edge.

Establishing iBGP sessions between all the same routers (R2, R3, and R4) in a full mesh allows for proper forwarding between autonomous systems.

Note

Service providers provide transit connectivity. Enterprise organizations are consumers and should not provide transit connectivity between autonomous systems across the Internet.

eBGP

eBGP peerings are the core component of BGP on the Internet. eBGP involves the exchange of network prefixes between autonomous systems. The following behaviors are different on eBGP sessions than on iBGP sessions:

  • Time-to-live (TTL) on eBGP packets is set to 1 by default. eBGP packets drop in transit if a multi-hop BGP session is attempted. (TTL on iBGP packets is set to 255, which allows for multi-hop sessions.)

  • The advertising router modifies the BGP next-hop address to the IP address sourcing the BGP connection.

  • The advertising router prepends its ASN to the existing AS_Path variable.

  • The receiving router verifies that the AS_Path variable does not contain an ASN that matches the local routers. BGP discards the NLRI if it fails the AS_Path loop prevention check.

The configurations for eBGP and iBGP sessions are fundamentally the same except that the ASN in the remote-as statement is different from the ASN defined in the BGP process.

Figure 11-5 shows the eBGP and iBGP sessions that would be needed between the routers to allow connectivity between AS 65100 and AS 65300. Notice that AS 65200 R2 establishes an iBGP session with R4 to overcome the loop-prevention behavior of iBGP learned routes.

A figure demonstrates about eBGP and iBGP sessions.

Figure 11-5 eBGP and iBGP Sessions

BGP Messages

BGP communication uses four message types, as shown in Table 11-2.

Table 11-2 BGP Packet Types

Type

Name

Functional Overview

1

OPEN

Sets up and establishes BGP adjacency

2

UPDATE

Advertises, updates, or withdraws routes

3

NOTIFICATION

Indicates an error condition to a BGP neighbor

4

KEEPALIVE

Ensures that BGP neighbors are still alive

  • OPEN: An OPEN message is used to establish a BGP adjacency. Both sides negotiate session capabilities before BGP peering is established. The OPEN message contains the BGP version number, the ASN of the originating router, the hold time, the BGP identifier, and other optional parameters that establish the session capabilities.

    • Hold time: The hold time attribute sets the hold timer, in seconds, for each BGP neighbor. Upon receipt of an UPDATE or KEEPALIVE, the hold timer resets to the initial value. If the hold timer reaches zero, the BGP session is torn down, routes from that neighbor are removed, and an appropriate update route withdraw message is sent to other BGP neighbors for the affected prefixes. The hold time is a heartbeat mechanism for BGP neighbors to ensure that a neighbor is healthy and alive.

    • When establishing a BGP session, the routers use the smaller hold time value contained in the two routers’ OPEN messages. The hold time value must be at least 3 seconds, or is set to 0 to disable keepalive messages. For Cisco routers, the default hold timer is 180 seconds.

    • BGP identifier: The BGP router ID (RID) is a 32-bit unique number that identifies the BGP router in the advertised prefixes. The RID can be used as a loop-prevention mechanism for routers advertised within an autonomous system. The RID can be set manually or dynamically for BGP. A nonzero value must be set in order for routers to become neighbors.

  • KEEPALIVE: BGP does not rely on the TCP connection state to ensure that the neighbors are still alive. KEEPALIVE messages are exchanged every one-third of the hold timer agreed upon between the two BGP routers. Cisco devices have a default hold time of 180 seconds, so the default keepalive interval is 60 seconds. If the hold time is set to 0, then no keepalive messages are sent between the BGP neighbors.

  • UPDATE: An UPDATE message advertises any feasible routes, withdraws previously advertised routes, or can do both. An UPDATE message includes the Network Layer Reachability Information (NLRI), such as the prefix and associated BGP PAs, when advertising prefixes. Withdrawn NLRIs include only the prefix. An UPDATE message can act as a keepalive to reduce unnecessary traffic.

  • NOTIFICATION: A NOTIFICATION message is sent when an error is detected with the BGP session, such as a hold timer expiring, neighbor capabilities changing, or a BGP session reset being requested. This causes the BGP connection to close.

BGP Neighbor States

BGP forms a TCP session with neighbor routers called peers. BGP uses the finite-state machine (FSM) to maintain a table of all BGP peers and their operational status. The BGP session may report the following states:

  • Idle

  • Connect

  • Active

  • OpenSent

  • OpenConfirm

  • Established

Figure 11-6 shows the BGP FSM and the states, listed in the order used in establishing a BGP session.

A figure depicts BGP neighbor states and session establishment.

Figure 11-6 BGP Neighbor States with Session Establishment

Idle

Idle is the first stage of the BGP FSM. BGP detects a start event and tries to initiate a TCP connection to the BGP peer and also listens for a new connection from a peer router.

If an error causes BGP to go back to the Idle state for a second time, the ConnectRetryTimer is set to 60 seconds and must decrement to zero before the connection can be initiated again. Further failures to leave the Idle state result in the ConnectRetryTimer doubling in length from the previous time.

Connect

In the Connect state, BGP initiates the TCP connection. If the three-way TCP handshake is completed, the established BGP session process resets the ConnectRetryTimer and sends the Open message to the neighbor; it then changes to the OpenSent state.

If the ConnectRetryTimer depletes before this stage is complete, a new TCP connection is attempted, the ConnectRetryTimer is reset, and the state is moved to Active. If any other input is received, the state is changed to Idle.

During this stage, the neighbor with the higher IP address manages the connection. The router initiating the request uses a dynamic source port, but the destination port is always 179.

Example 11-1 shows an established BGP session using the command show tcp brief to displays the active TCP sessions between a router. Notice that the TCP source port is 179 and the destination port is 59884 on R1; the ports are opposite on R2.

Example 11-1 An Established BGP Session

R1# show tcp brief
TCB       Local Address               Foreign Address             (state)
F6F84258  10.12.1.1.59884            10.12.1.2.179               ESTAB
R2# show tcp brief
TCB       Local Address               Foreign Address             (state)
EF153B88  10.12.1.2.59884             10.12.1.1.179                ESTA
Active

In the Active state, BGP starts a new three-way TCP handshake. If a connection is established, an Open message is sent, the hold timer is set to 4 minutes, and the state moves to OpenSent. If this attempt for TCP connection fails, the state moves back to the Connect state, and the ConnectRetryTimer is reset.

OpenSent

In the OpenSent state, an Open message has been sent from the originating router and is awaiting an Open message from the other router. Once the originating router receives the OPEN message from the other router, both OPEN messages are checked for errors. The following items are examined:

  • BGP versions must match.

  • The source IP address of the OPEN message must match IP address that is configured for the neighbor.

  • The AS number in the OPEN message must match what is configured for the neighbor.

  • BGP identifiers (RIDs) must be unique. If a RID does not exist, this condition is not met.

  • Security parameters (such as password and TTL) must be set appropriately.

If the OPEN messages do not have any errors, the hold time is negotiated (using the lower value), and a KEEPALIVE message is sent (assuming that the value is not set to 0). The connection state is then moved to OpenConfirm. If an error is found in the OPEN message, a NOTIFICATION message is sent, and the state is moved back to Idle.

If TCP receives a disconnect message, BGP closes the connection, resets the ConnectRetryTimer, and sets the state to Active. Any other input in this process results in the state moving to Idle.

OpenConfirm

In the OpenConfirm state, BGP waits for a KEEPALIVE or NOTIFICATION message. Upon receipt of a neighbor’s KEEPALIVE message, the state is moved to Established. If the hold timer expires, a stop event occurs, or if a NOTIFICATION message is received, the state is moved to Idle.

Established

In the Established state, the BGP session is established. BGP neighbors exchange routes using UPDATE messages. As UPDATE and KEEPALIVE messages are received, the hold timer is reset. If the hold timer expires, an error is detected, and BGP moves the neighbor back to the Idle state.

Basic BGP Configuration

When configuring BGP, it is best to think of the configuration from a modular perspective. BGP router configuration requires the following components:

  • BGP session parameters: BGP session parameters provide settings that involve establishing communication to the remote BGP neighbor. Session settings include the ASN of the BGP peer, authentication, and keepalive timers.

  • Address family initialization: The address family is initialized under the BGP router configuration mode. Network advertisement and summarization occur within the address family.

  • Activate the address family on the BGP peer: In order for a session to initiate, one address family for a neighbor must be activated. The router’s IP address is added to the neighbor table, and BGP attempts to establish a BGP session or accepts a BGP session initiated from the peer router

The following steps show how to configure BGP:

Step 1. Initialize the BGP routing process with the global command router bgp as-number.

Step 2. (Optional) Statically define the BGP router ID (RID). The dynamic RID allocation logic uses the highest IP address of the any up loopback interfaces. If there is not an up loopback interface, then the highest IP address of any active up interfaces becomes the RID when the BGP process initializes.

To ensure that the RID does not change, a static RID is assigned (typically representing an IPv4 address that resides on the router, such as a loopback address). Any IPv4 address can be used, including IP addresses not configured on the router. Statically configuring the BGP RID is a best practice and involves using the command bgp router-id router-id.

When the router ID changes, all BGP sessions reset and need to be reestablished.

Step 3. Identify the BGP neighbor’s IP address and autonomous system number with the BGP router configuration command neighbor ip-address remote-as as-number. It is important to understand the traffic flow of BGP packets between peers. The source IP address of the BGP packets still reflects the IP address of the outbound interface. When a BGP packet is received, the router correlates the source IP address of the packet to the IP address configured for that neighbor. If the BGP packet source does not match an entry in the neighbor table, the packet cannot be associated to a neighbor and is discarded.

Note

IOS activates the IPv4 address family by default. This can simplify the configuration in an IPv4 environment because steps 4 and 5 are optional but may cause confusion when working with other address families. The BGP router configuration command no bgp default ip4-unicast disables the automatic activation of the IPv4 AFI so that steps 4 and 5 are required.

Step 4. Initialize the address family with the BGP router configuration command address-family afi safi. Examples of afi values are IPv4 and IPv6, and examples of safi values are unicast and multicast.

Step 5. Activate the address family for the BGP neighbor with the BGP address family configuration command neighbor ip-address activate.

Note

On IOS and IOS XE devices, the default subsequent address family identifier (SAFI) for the IPv4 and IPv6 address families is unicast and is optional.

Figure 11-7 shows a topology for a simple BGP configuration.

A simple BGP topology is shown. A BGP topology contains two networks: AS 65100 (loop back 0, 192.168.1.1) and AS 65200 (loop back 0, 192.168.2.2). The router R1 in AS 65100 is connected to router R2 of AS 65200 via the link 10.12.1.0/24.

Figure 11-7 Simple BGP Topology

Example 11-2 shows how to configure R1 and R2 using the IOS default and optional IPv4 AFI modifier CLI syntax. R1 is configured with the default IPv4 address family enabled, and R2 disables IOS’s default IPv4 address family and manually activates it for the specific neighbor 10.12.1.1.

Example 11-2 Configuring Basic BGP on IOS

R1 (Default IPv4 Address-Family Enabled)
router bgp 65100
 neighbor 10.12.1.2 remote-as 65200
R2 (Default IPv4 Address-Family Disabled)
router bgp 65200
 no bgp default ipv4-unicas
 neighbor 10.12.1.1 remote-as 65100
 !
 address-family ipv4
  neighbor 10.12.1.1 activate
 exit-address-family

Verification of BGP Sessions

The BGP session is verified with the command show bgp afi safi summary. Example 11-3 shows the IPv4 BGP unicast summary. Notice that the BGP RID and table version are the first components shown. The Up/Down column indicates that the BGP session is up for over 5 minutes.

Note

Earlier commands like show ip bgp summary came out before MBGP and do not provide a structure for the current multiprotocol capabilities within BGP. Using the AFI and SAFI syntax ensures consistency for the commands, regardless of information exchanged by BGP. This will become more apparent as engineers work with address families like IPv6, VPNv4, and VPNv6.

Example 11-3 Verifying the BGP IPv4 Session Summary

R1# show bgp ipv4 unicast summary
BGP router identifier 192.168.2.2, local AS number 65200
BGP table version is 1, main routing table version 1

Neighbor      V     AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.12.1.2     4  65200       8       9        1    0    0 00:05:23       0

Table 11-3 explains the fields of output displayed in a BGP table (as in Example 11-3).

Table 11-3 BGP Summary Fields

Field

Description

Neighbor

IP address of the BGP peer

V

BGP version spoken by the BGP peer

AS

Autonomous system number of the BGP peer

MsgRcvd

Count of messages received from the BGP peer

MsgSent

Count of messages sent to the BGP peer

TblVer

Last version of the BGP database sent to the peer

InQ

Number of messages queued to be processed by the peer

OutQ

Number of messages queued to be sent to the peer

Up/Down

Length of time the BGP session is established or the current status if the session is not in an established state

State/PfxRcd

Current state of the BGP peer or the number of prefixes received from the peer

BGP neighbor session state, timers, and other essential peering information is available with the command show bgp afi safi neighbors ip-address, as shown in Example 11-4.

Example 11-4 BGP IPv4 Neighbor Output

R2# show bgp ipv4 unicast neighbors 10.12.1.1
! Output ommitted for brevity                                                         

! The first section provides the neighbor{'s IP address, remote-as, indicates if      
! the neighbor is {'internal{' or {'external{', the neighbor{’s BGP version, RID,     
! session state, and timers.                                                          

BGP neighbor is 10.12.1.1, remote AS65100, external link
  BGP version 4, remote router ID 192.168.1.1
  BGP state = Established, up for 00:01:04
  Last read 00:00:10, last write 00:00:09, hold is 180, keepalive is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
! This second section indicates the capabilities of the BGP neighbor and              
! address-families configured on the neighbor.                                        
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                                                                                      
! This section provides a list of the BGP packet types that have been received        
! or sent to the neighbor router.                                                     
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:             2          2
    Route Refresh:          0          0
    Total:                  4          3
  Default minimum time between advertisement runs is 0 seconds

! This section provides the BGP table version of the IPv4 Unicast address-             
! family. The table version is not a 1-to-1 correlation with routes as multiple        
! route change can occur during a revision change. Notice the Prefix Activity          
! columns in this section.                                                             

For address family: IPv4 Unicast
  Session: 10.12.1.1
  BGP table version 1, neighbor version 1/
  Output queue size : 0
  Index 1, Advertise bit 0
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0

! This section indicates that a valid route exists in the RIB to the BGP peer IP       
! address, provides the number of times that the connection has established and        
! time dropped, since the last reset, the reason for the reset, if path-mtu-           
! discovery is enabled, and ports used for the BGP session.                            

  Address tracking is enabled, the RIB does have a route to 10.12.1.1
  Connections established 2; dropped 1
  Last reset 00:01:40, due to Peer closed the session
  Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 10.12.1.2, Local port: 179
Foreign host: 10.12.1.1, Foreign port: 56824

Prefix Advertisement

BGP network statements do not enable BGP for a specific interface; instead, they identify specific network prefixes to be installed into the BGP table, known as the Loc-RIB table.

After configuring a BGP network statement, the BGP process searches the global RIB for an exact network prefix match. The network prefix can be for a connected network, a secondary connected network, or any route from a routing protocol. After verifying that the network statement matches a prefix in the global RIB, the prefix is installed into the BGP Loc-RIB table. As the BGP prefix is installed into the Loc-RIB table, the following BGP PAs are set, depending on the RIB prefix type:

  • Connected network: The next-hop BGP attribute is set to 0.0.0.0, the BGP origin attribute is set to i (IGP), and the BGP weight is set to 32,768.

  • Static route or routing protocol: The next-hop BGP attribute is set to the next-hop IP address in the RIB, the BGP origin attribute is set to i (IGP), the BGP weight is set to 32,768, and the MED is set to the IGP metric.

Not every route in the Loc-RIB table is advertised to a BGP peer. All routes in the Loc-RIB table use the following process for advertisement to BGP peers.

Step 1. Pass a validity check. Verify that the NRLI is valid and that the next-hop address is resolvable in the global RIB. If the NRLI fails, the NLRI remains but does not process further.

Step 2. Process outbound neighbor route policies. After processing, if a route was not denied by the outbound policies, the route is maintained in the Adj-RIB-Out table for later reference.

Step 3. Advertise the NLRI to BGP peers. If the NLRI’s next-hop BGP PA is 0.0.0.0, then the next-hop address is changed to the IP address of the BGP session.

Figure 11-8 illustrates the concept of installing the network prefix from localized BGP network advertisements to the BGP table.

A flowchart depicts the steps involved in BGP database processing of local route advertisements.

Figure 11-8 BGP Database Processing of Local Route Advertisements

Note

BGP only advertises the best path to other BGP peers, regardless of the number of routes (NLRIs) in the BGP Loc-RIB table.

The network statement resides under the appropriate address family within the BGP router configuration. The command network network mask subnet-mask [route-map route-map-name] is used for advertising IPv4 networks. The optional route-map provides a method of setting specific BGP PAs when the prefix installs into the Loc-RIB table. Route maps are discussed in more detail in Chapter 12.

Figure 11-7 illustrates R1 and R2 connected through the 10.12.1.0/24 network. Example 11-5 demonstrates the configuration where both routers will advertise the Loopback 0 interfaces (192.168.1.1/32 and 192.168.2.2/32, respectively) and the 10.12.1.0/24 network into BGP. Notice that R1 uses the default IPv4 address family, and R2 explicitly specifies the IPv4 address family.

Example 11-5 Configuring BGP Network Advertisement

R1
router bgp 65100
 bgp log-neighbor-changes
 no bgp default ipv4-unicas
 neighbor 10.12.1.2 remote-as 100
 network 10.12.1.0 mask 255.255.255.0                                                     
 network 192.168.1.1 mask 255.255.255.255                                                 
R2
router bgp 65200
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.12.1.1 remote-as 65100
 !
 address-family ipv4
  network 10.12.1.0 mask 255.255.255.0                                                      
  network 192.168.2.2 mask 255.255.255.255                                                  
  neighbor 10.12.1.1 activate
 exit-address-family

Receiving and Viewing Routes

BGP uses three tables for maintaining the network prefix and path attributes (PAs) for a route:

  • Adj-RIB-In: Contains the NLRIs in original form (that is, from before inbound route policies are processed). To save memory, the table is purged after all route policies are processed.

  • Loc-RIB: Contains all the NLRIs that originated locally or were received from other BGP peers. After NLRIs pass the validity and next-hop reachability check, the BGP best-path algorithm selects the best NLRI for a specific prefix. The Loc-RIB table is the table used for presenting routes to the IP routing table.

  • Adj-RIB-Out: Contains the NLRIs after outbound route policies have been processed.

Not every prefix in the Loc-RIB table is advertised to a BGP peer or installed into the global RIB when received from a BGP peer. BGP performs the following route processing steps:

Step 1. Store the route in the Adj-RIB-In table in the original state and apply the inbound route policy based on the neighbor on which the route was received.

Step 2. Update the Loc-RIB with the latest entry. The Adj-RIB-In table is cleared to save memory.

Step 3. Pass a validity check to verify that the route is valid and that the next-hop address is resolvable in the global RIB. If the route fails, the route remains in the Loc-RIB table but is not processed further.

Step 4. Identify the BGP best path and pass only the best path and its path attributes to step 5. The BGP best path selection process is covered in Chapter 12.

Step 5. Install the best-path route into the global RIB, process the outbound route policy, store the non-discarded routes in the Adj-RIB-Out table, and advertise to BGP peers.

Figure 11-9 shows the complete BGP route processing logic. It includes the receipt of a route from a BGP peers and the BGP best-path algorithm.

A flowchart demonstrates the BGP database processing logic.

Figure 11-9 BGP Database Processing

The command show bgp afi safi displays the contents of the BGP database (Loc-RIB) on the router. Every entry in the BGP Loc-RIB table contains at least one path but could contain multiple paths for the same network prefix. Example 11-6 displays the BGP table on R1, which contains received routes and locally generated routes.

Example 11-6 Displaying the BGP Table

R1# show bgp ipv4 unicast
BGP table version is 4, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.2                0             0 65200 i
 *>                   0.0.0.0                  0         32768 i
 *>  192.168.1.1/32   0.0.0.0                  0         32768 i
 *>  192.168.2.2/32   10.12.1.2                0             0 65200 i
R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 i
 *>                   0.0.0.0                  0         32768 i
 *>  192.168.1.1/32   10.12.1.1                0             0 65100 i
 *>  192.168.2.2/32   0.0.0.0                  0         32768

Table 11-4 explains the fields of output when displaying the BGP table.

Table 11-4 BGP Table Fields

Field

Description

Network

A list of the network prefixes installed in BGP. If multiple NLRIs exist for the same prefix, only the first prefix is identified, and others are blank.

Valid NLRIs are indicated by the *.

The NLRI selected as the best path is indicated by an angle bracket (>).

Next Hop

A well-known mandatory BGP path attribute that defines the IP address for the next hop for that specific NLRI.

Metric

Multiple-exit discrimator (MED): An optional non-transitive BGP path attribute used in BGP for the specific NLRI.

LocPrf

Local Preference: A well-known discretionary BGP path attribute used in the BGP best-path algorithm for the specific NLRI.

Weight

A locally significant Cisco-defined attribute used in the BGP best-path algorithm for the specific NLRI.

Path and Origin

AS_Path: A well-known mandatory BGP path attribute used for loop prevention and in the BGP best-path algorithm for the specific NLRI.

Origin: A well-known mandatory BGP path attribute used in the BGP best-path algorithm. A value of i represents an IGP, e indicates EGP, and ? indicates a route that was redistributed into BGP.

The command show bgp afi safi network displays all the paths for a specific route and the BGP path attributes for that route. Example 11-7 shows the paths for the 10.12.1.0/24 network. The output includes the number of paths and which path is the best path.

Example 11-7 Viewing Explicit BGP Routes and Path Attributes

R1# show bgp ipv4 unicast 10.12.1.0
BGP routing table entry for 10.12.1.0/24, version 2
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  65200
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

Note

The command show bgp afi safi detail displays the entire BGP table with all the path attributes, such as those shown in Example 11-7.

The Adj-RIB-Out table is a unique table maintained for each BGP peer. It enables a network engineer to view routes advertised to a specific router. The command show bgp afi safi neighbor ip-address advertised routes displays the contents of the Adj-RIB-Out table for a neighbor.

Example 11-8 shows the Adj-RIB-Out entries specific to each neighbor. Notice that the next-hop address reflects the local router and will be changed as the route advertises to the peer.

Example 11-8 Neighbor-Specific View of the Adj-RIB-Out Table

R1# show bgp ipv4 unicast neighbors 10.12.1.2 advertised-routes
! Output omitted for brevity                                                      
     Network          Next Hop            Metric LocPrf Weight Path
*> 10.12.1.0/24     0.0.0.0                  0         32768 i
*> 192.168.1.1/32   0.0.0.0                  0         32768 i

Total number of prefixes 2
R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes
! Output omitted for brevity                                                        
     Network          Next Hop            Metric LocPrf Weight Path
*> 10.12.1.0/24     0.0.0.0                  0         32768 i
*> 192.168.2.2/32   0.0.0.0                  0         32768 i

Total number of prefixes 2

The show bgp ipv4 unicast summary command can also be used to verify the exchange of NLRIs between nodes, as shown in Example 11-9.

Example 11-9 BGP Summary with Prefixes

The BGP routes in the global IP routing table (RIB) are displayed with the command show ip route bgp. Example 11-10 shows these commands in the sample topology. The prefixes are from an eBGP session and have an AD of 20, and no metric is present.

Example 11-10 Displaying BGP Routes in an IP Routing Table

R1# show ip route bgp | begin Gateway
Gateway of last resort is not set
      192.168.2.0/32 is subnetted, 1 subnets
B        192.168.2.2 [20/0] via 10.12.1.2, 00:06:12

BGP Route Advertisements from Indirect Sources

As stated earlier, BGP should be thought of as a routing application as the BGP session and route advertisement are two separate components. Figure 11-10 demonstrates a topology where R1 installs multiple routes learned from static routes, EIGRP, and OSPF. R1 can advertise these routes to R2.

A figure demonstrates about installing multiple BGP routes.

Figure 11-10 Multiple BGP Route Sources

Example 11-11 shows the routing table for R1. Notice that R3’s loopback was learned via EIGRP, R4’s loopback is reached using a static route, and R5’s loopback is learned from OSPF.

Example 11-11 R1’s Routing Table with Loopbacks for R3, R4, and R5

R1# show ip route
! Output omitted for brevity                                                        
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
..
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.12.1.0/24 is directly connected, GigabitEthernet0/0
C        10.13.1.0/24 is directly connected, GigabitEthernet0/1
C        10.14.1.0/24 is directly connected, GigabitEthernet0/2
C        10.15.1.0/24 is directly connected, GigabitEthernet0/3
C        192.168.1.1 is directly connected, Loopback0
B        192.168.2.2 [20/0] via 10.12.1.2, 00:01:17
D        192.168.3.3 [90/3584] via 10.13.1.3, 00:02:10, GigabitEthernet0/1         
S        192.168.4.4 [1/0] via 10.14.1.4                                           
O        192.168.5.5 [110/11] via 10.15.1.5, 00:00:08, GigabitEthernet0/3          

Example 11-12 shows the installation of R3’s and R4’s loopback using a network statement. Specifying every network prefix that should be advertised might seem tedious. R5’s loopback was learned by redistributing OSPF straight into BGP.

Example 11-12 Configuring Advertising Routes for Non-Connected Routes

R1
router bgp 65100
 bgp log-neighbor-changes
 network 10.12.1.0 mask 255.255.255.0
 network 192.168.1.1 mask 255.255.255.255
 network 192.168.3.3 mask 255.255.255.255                                
 network 192.168.4.4 mask 255.255.255.255                                
 redistribute ospf 1                                                     
 neighbor 10.12.1.2 remote-as 65200

Note

Redistributing routes learned from an IGP into BGP is completely safe; however, redistributing routes learned from BGP should be done with caution. BGP is designed for large scale and can handle a routing table the size of the Internet (780,000+ prefixes), whereas IGPs could have stability problems with fewer than 20,000 routes.

Example 11-13 shows the BGP routing tables on R1 and R2. Notice that on R1, the next hop matches the next hop learned from the RIB, the AS_Path is blank, and the origin codes is IGP (for routes learned from network statement) or incomplete (redistributed). The metric is carried over from R3’s and R5’s IGP routing protocols and is reflected as the MED. R2 learns the routes strictly from eBGP and sees only the MED and the origin codes.

Example 11-13 BGP Table for Routes from Multiple Sources

R1# show bgp ipv4 unicast
BGP table version is 9, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     0.0.0.0                  0         32768 i
 *                    10.12.1.2                0             0 65200 i
 *>  10.15.1.0/24     0.0.0.0                  0         32768 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 i
 *>  192.168.2.2/32   10.12.1.2                0             0 65200 i
 ! The following route comes from EIGRP and uses a network statement                 
 *>  192.168.3.3/32   10.13.1.3             3584         32768 i
! The following route comes from a static route and uses a network statement         
 *>  192.168.4.4/32   10.14.1.4                0         32768 i
! The following route was redistributed from OSPF statement                          
*>  192.168.5.5/32   10.15.1.5               11         32768 ?
R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 i
 *>                   0.0.0.0                  0         32768 i
 *>  10.15.1.0/24     10.12.1.1                0             0 65100 ?
 *>  192.168.1.1/32   10.12.1.1                0             0 65100 i
 *>  192.168.2.2/32   0.0.0.0                  0         32768 i
 *>  192.168.3.3/32   10.12.1.1             3584             0 65100 i
 *>  192.168.4.4/32   10.12.1.1                0             0 65100 i
 *>  192.168.5.5/32   10.12.1.1               11             0 65100 ?

Route Summarization

Summarizing prefixes conserves router resources and accelerates best-path calculation by reducing the size of the table. Summarization also provides the benefit of stability by hiding route flaps from downstream routers, thereby reducing routing churn. While most service providers do not accept prefixes larger than /24 for IPv4 (/25 through /32), the Internet, at the time of this writing, still has more than 780,000 routes and continues to grow. Route summarization is required to reduce the size of the BGP table for Internet routers.

BGP route summarization on BGP edge routers reduces route computation on routers in the core for received routes or for advertised routes. In Figure 11-11, R3 summarizes all the eBGP routes received from AS 65100 and AS 65200 to reduce route computation on R4 during link flaps. In the event of a link flap on the 10.13.1.0/24 network, R3 removes all the AS 65100 routes learned directly from R1 and identifies the same network prefixes via R2 with different path attributes (a longer AS_Path). R3 has to advertise new routes to R4 because of these flaps, which is a waste of CPU cycles because R4 only receives connectivity from R3. If R3 summarized the network prefix range, R4 would execute the best-path algorithm once and not need to run during link flaps of the 10.13.1.0/24 link.

A figure illustrates BGP route summarization.

Figure 11-11 BGP Route Summarization Hiding Link Flaps

There are two techniques for BGP summarization:

  • Static: Create a static route to Null0 for the summary network prefix and then advertise the prefix with a network statement. The downfall of this technique is that the summary route is always advertised, even if the networks are not available.

  • Dynamic: Configure an aggregation network prefix. When viable component routes that match the aggregate network prefix enter the BGP table, then the aggregate prefix is created. The originating router sets the next hop to Null0 as a discard route for the aggregated prefix for loop prevention.

In both methods of route aggregation, a new network prefix with a shorter prefix length is advertised into BGP. Because the aggregated prefix is a new route, the summarizing router is the originator for the new aggregate route.

Aggregate Address

Dynamic route summarization is accomplished with the BGP address family configuration command aggregate-address network subnet-mask [summary-only] [as-set].

Figure 11-12 removes the flapping serial link between R1 and R3 to demonstrate BGP route aggregation and the effects of the commands.

A BGP summarization topology is shown.

Figure 11-12 BGP Summarization Topology

Example 11-14 shows the BGP tables for R1, R2, and R3 before route aggregation has been performed. R1’s stub networks (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) are advertised through all the autonomous systems, along with the router’s loopback addresses (192.168.1.1/32, 192.168.2.2/32, and 192.168.3.3/32) and the peering links (10.12.1.0/24 and 10.23.1.0/24).

Example 11-14 BGP Tables for R1, R2, and R3 Without Aggregation

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2                0             0 65200 ?
 *>  172.16.1.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.2.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.3.0/24    0.0.0.0                  0         32768 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2                0             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2                              0 65200 65300 ?
R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 ?
 *>                   0.0.0.0                  0         32768 ?
 *   10.23.1.0/24     10.23.1.3                0             0 65300 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.1.0/24    10.12.1.1                0             0 65100 ?
 *>  172.16.2.0/24    10.12.1.1                0             0 65100 ?
 *>  172.16.3.0/24    10.12.1.1                0             0 65100 ?
 *>  192.168.1.1/32   10.12.1.1                0             0 65100 ?
 *>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 *>  192.168.3.3/32   10.23.1.3                0             0 65300 ?
R3# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     10.23.1.2                0             0 65200 ?
 *   10.23.1.0/24     10.23.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.1.0/24    10.23.1.2                              0 65200 65100 ?
 *>  172.16.2.0/24    10.23.1.2                              0 65200 65100 ?
 *>  172.16.3.0/24    10.23.1.2                              0 65200 65100 ?
 *>  192.168.1.1/32   10.23.1.2                              0 65200 65100 ?
 *>  192.168.2.2/32   10.23.1.2                0             0 65200 ?
 *>  192.168.3.3/32   0.0.0.0                  0         32768 ?

R1 aggregates all the stub networks (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) into a 172.16.0.0/20 network prefix. R2 aggregates all of the router’s loopback addresses into a 192.168.0.0/16 network prefix. Example 11-15 shows the configuration for R1 running with the default IPv4 address family and R2 running without the default IPv4 address family.

Example 11-15 Configuring BGP Route Aggregation

R1# show running-config | section router bgp
router bgp 65100
 bgp log-neighbor-changes
 aggregate-address 172.16.0.0 255.255.240.0                                     
 redistribute connected
 neighbor 10.12.1.2 remote-as 65200
R2# show running-config | section router bgp
router bgp 65200
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.12.1.1 remote-as 65100
 neighbor 10.23.1.3 remote-as 65300
 !
 address-family ipv4
 aggregate-address 192.168.0.0 255.255.0.0                                      
  redistribute connected
  neighbor 10.12.1.1 activate
  neighbor 10.23.1.3 activate
 exit-address-family

Example 11-16 shows the routing tables for R1, R2, and R3 after aggregation is configured on R1 and R2.

Example 11-16 BGP Tables for R1, R2, and R3 with Aggregation

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2                0             0 65200 ?
 *>  172.16.0.0/20    0.0.0.0                            32768 i
 *>  172.16.1.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.2.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.3.0/24    0.0.0.0                  0         32768 ?
 *>  192.168.0.0/16   10.12.1.2                0             0 65200 i
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2                0             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2                              0 65200 65300 ?
R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 ?
 *>                   0.0.0.0                  0         32768 ?
 *   10.23.1.0/24     10.23.1.3                0             0 65300 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    10.12.1.1                0             0 65100 i
 *>  172.16.1.0/24    10.12.1.1                0             0 65100 ?
 *>  172.16.2.0/24    10.12.1.1                0             0 65100 ?
 *>  172.16.3.0/24    10.12.1.1                0             0 65100 ?
 *>  192.168.0.0/16   0.0.0.0                            32768 i
 *>  192.168.1.1/32   10.12.1.1                0             0 65100 ?
 *>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 *>  192.168.3.3/32   10.23.1.3                0             0 65300 ?

Notice that the 172.16.0.0/20 and 192.168.0.0/16 network prefixes are visible, but the smaller component network prefixes still exist on all the routers. The aggregate-address command advertises the aggregated route in addition to the original component network prefixes. Using the optional summary-only keyword suppresses the component network prefixes in the summarized network range. Example 11-17 shows the configuration with the summary-only keyword.

Example 11-17 BGP Route Aggregation Configuration with Suppression

R1# show running-config | section router bgp
router bgp 65100
 bgp log-neighbor-changes
 aggregate-address 172.16.0.0 255.255.240.0 summary-only
 redistribute connected
 neighbor 10.12.1.2 remote-as 65200
R2# show running-config | section router bgp
router bgp 65200
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.12.1.1 remote-as 65100
 neighbor 10.23.1.3 remote-as 65300
 !
 address-family ipv4
  aggregate-address 192.168.0.0 255.255.0.0 summary-only
  redistribute connected
  neighbor 10.12.1.1 activate
  neighbor 10.23.1.3 activate
 exit-address-family

Example 11-18 shows the BGP table for R3 after the summary-only keyword is added to the aggregation command. R1’s stub network has been aggregated in the 172.16.0.0/20 network prefix, while R1’s and R2’s loopback has been aggregated into the 192.168.0.0/16 network prefix. None of R1’s stub networks or the loopback addresses from R1 or R2 are visible on R3.

Example 11-18 BGP Tables for R3 with Aggregation and Suppression

R3# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     10.23.1.2                0             0 65200 ?
 *   10.23.1.0/24     10.23.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    10.23.1.2                              0 65200 65100 i
 *>  192.168.0.0/16   10.23.1.2                0             0 65200 i
 *>  192.168.3.3/32   0.0.0.0                  0         32768 ?

Example 11-19 shows the BGP table and RIB for R2. Notice that the component loopback networks have been suppressed by BGP and are not advertised by R2. In addition, a summary discard route has been installed to Null0 as a loop-prevention mechanism.

Example 11-19 R2’s BGP and RIB After Aggregation with Suppression

R2# show bgp ipv4 unicast
BGP table version is 10, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
*   10.12.1.0/24     10.12.1.1                0             0 65100 ?
 *>                   0.0.0.0                  0         32768 ?
 *   10.23.1.0/24     10.23.1.3                0             0 65300 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    10.12.1.1                0             0 65100 i
 *>  192.168.0.0/16   0.0.0.0                            32768 i
 s>  192.168.1.1/32   10.12.1.1                0             0 65100 ?
 s>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 s>  192.168.3.3/32   10.23.1.3                0             0 65300 ?
R2# show ip route bgp | begin Gateway
Gateway of last resort is not set
      172.16.0.0/20 is subnetted, 1 subnets
B        172.16.0.0 [20/0] via 10.12.1.1, 00:06:18
B     192.168.0.0/16 [200/0], 00:05:37, Null0                                    
      192.168.1.0/32 is subnetted, 1 subnets
B        192.168.1.1 [20/0] via 10.12.1.1, 00:02:15
      192.168.3.0/32 is subnetted, 1 subnets
B        192.168.3.3 [20/0] via 10.23.1.3, 00:02:1

Example 11-20 shows that R1’s stub networks have been suppressed, and the summary discard route for the 172.16.0.0/20 network has been installed in the RIB as well.

Example 11-20 R1’s BGP and RIB After Aggregation with Suppression

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2                0             0 65200 ?
 *>  172.16.0.0/20    0.0.0.0                            32768 i
 s>  172.16.1.0/24    0.0.0.0                  0         32768 ?
 s>  172.16.2.0/24    0.0.0.0                  0         32768 ?
 s>  172.16.3.0/24    0.0.0.0                  0         32768 ?
 *>  192.168.0.0/16   10.12.1.2                0             0 65200 i
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
R1# show ip route bgp | begin Gateway
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B        10.23.1.0/24 [20/0] via 10.12.1.2, 00:12:50
      172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
B        172.16.0.0/20 [200/0], 00:06:51, Null0
B     192.168.0.0/16 [20/0] via 10.12.1.2, 00:06:10

Atomic Aggregate

Aggregated routes act like new BGP routes with a shorter prefix length. When a BGP router summarizes a route, it does not advertise the AS_Path information from before the aggregation. BGP path attributes like AS_Path, MED, and BGP communities are not included in the new BGP advertisement.

The atomic aggregate attribute indicates that a loss of path information has occurred. To demonstrate this best, the previous BGP route aggregation on R1 has been removed and added to R2 so that R2 is now aggregating the 172.16.0.0/20 and 192.168.0.0/16 networks with suppression. Example 11-21 shows the configuration on R2.

Example 11-21 Configuring Aggregation for 172.16.0.0/20 and 192.168.0.0/16

R2# show running-config | section router bgp
router bgp 65200
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.12.1.1 remote-as 65100
 neighbor 10.23.1.3 remote-as 65300
 !
 address-family ipv4
  aggregate-address 192.168.0.0 255.255.0.0 summary-only                                      
  aggregate-address 172.16.0.0 255.255.240.0 summary-only                                     
  redistribute connected
  neighbor 10.12.1.1 activate
  neighbor 10.23.1.3 activate
 exit-address-famil

Example 11-22 shows R2’s and R3’s BGP tables. R2 is aggregating and suppressing R1’s stub networks (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) into the 172.16.0.0/20 network. The component network prefixes maintain an AS_Path of 65100 on R2, while the aggregate 172.16.0.0/20 network appears locally generated on R2.

From R3’s perspective, R2 does not advertise R1’s stub networks; instead, it advertises the 172.16.0.0/20 network as its own. The AS_Path for the 172.16.0.0/20 network prefix on R3 is simply AS 65200 and does not include AS 65100.

Example 11-22 R2’s and R3’s BGP Tables with Path Attribute Loss

R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 ?
 *>                   0.0.0.0                  0         32768 ?
 *   10.23.1.0/24     10.23.1.3                0             0 65300 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    0.0.0.0                            32768 i
 s>  172.16.1.0/24    10.12.1.1                0             0 65100 ?                         
 s>  172.16.2.0/24    10.12.1.1                0             0 65100 ?                         
 s>  172.16.3.0/24    10.12.1.1                0             0 65100 ?                         
 *>  192.168.0.0/16   0.0.0.0                            32768 i
 s>  192.168.1.1/32   10.12.1.1                0             0 65100 ?
 s>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 s>  192.168.3.3/32   10.23.1.3                0             0 65300 ?
R3# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     10.23.1.2                0             0 65200 ?
 *   10.23.1.0/24     10.23.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    10.23.1.2                0             0 65200 i                   
 *>  192.168.0.0/16   10.23.1.2                0             0 65200 i
 *>  192.168.3.3/32   0.0.0.0                  0         32768 ?

Example 11-23 shows the explicit 172.16.0.0/20 prefix entry on R3. The route’s NLRI information indicates that the routes were aggregated in AS 65200 by the router with the RID 192.168.2.2. In addition, the atomic aggregate attribute has been set to indicate a loss of path attributes, such as AS_Path in this scenario.

Example 11-23 Examining the BGP Attribute for the Atomic Aggregate Attribute

R3# show bgp ipv4 unicast 172.16.0.0
BGP routing table entry for 172.16.0.0/20, version 25
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  65200, (aggregated by 65200 192.168.2.2)
    10.23.1.2 from 10.23.1.2 (192.168.2.2)
      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
      rx pathid: 0, tx pathid: 0x

Route Aggregation with AS_SET

To keep the BGP path information history, the optional as-set keyword may be used with the aggregate-address command. As the router generates the aggregate route, BGP attributes from the component aggregate routes are copied over to it. The AS_Path settings from the original prefixes are stored in the AS_SET portion of the AS_Path. The AS_SET, which is displayed within brackets, only counts as one hop, even if multiple ASs are listed.

Example 11-24 shows R2’s updated BGP configuration for summarizing both networks with the as-set keyword.

Example 11-24 Configuring Aggregation While Preserving BGP Attributes

R2# show running-config | section router bgp
router bgp 65200
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.12.1.1 remote-as 65100
 neighbor 10.23.1.3 remote-as 65300
 !
 address-family ipv4
  aggregate-address 192.168.0.0 255.255.0.0 as-set summary-only
  aggregate-address 172.16.0.0 255.255.240.0 as-set summary-only
  redistribute connected
  neighbor 10.12.1.1 activate
  neighbor 10.23.1.3 activate
 exit-address-famil

Example 11-25 shows the 172.16.0.0/20 network again, now that BGP attributes will be propagated into the new route. Notice that the AS_Path information now contains AS 65100 as part of the information.

Example 11-25 Verifying That Path Attributes Are Injected into the BGP Aggregate

R3# show bgp ipv4 unicast 172.16.0.0
BGP routing table entry for 172.16.0.0/20, version 30
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  65200 65100, (aggregated by 65200 192.168.2.2)
    10.23.1.2 from 10.23.1.2 (192.168.2.2)
      Origin incomplete, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
R3# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     10.23.1.2                0             0 65200 ?
 *   10.23.1.0/24     10.23.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    10.23.1.2                0             0 65200 65100 ?
 *>  192.168.3.3/32   0.0.0.0                  0         32768 ?

Did you notice that the 192.168.0.0/16 network is no longer present in R3’s BGP table? The reason for this is that on R2, R2 is aggregating all of the loopback networks from R1 (AS 65100), R2 (AS 65200), and R3 (AS 65300). And now that R2 is copying all component routes’ BGP path attributes into the AS_SET information, the AS_Path for the 192.168.0.0/16 network contains AS 65300. When the aggregate is advertised to R3, R3 discards that route because it sees its own AS_Path in the advertisement and thinks that it is a loop.

Example 11-26 shows R2’s BGP table and the path attributes for the aggregated 192.168.0.0/16 network entry.

Example 11-26 Viewing the Aggregated Properties of 192.168.0.0/16

R2# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.1                0             0 65100 ?
 *>                   0.0.0.0                  0         32768 ?
 *   10.23.1.0/24     10.23.1.3                0             0 65300 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  172.16.0.0/20    0.0.0.0                       100  32768 65100 ?
 s>  172.16.1.0/24    10.12.1.1                0             0 65100 ?
 s>  172.16.2.0/24    10.12.1.1                0             0 65100 ?
 s>  172.16.3.0/24    10.12.1.1                0             0 65100 ?
 *>  192.168.0.0/16   0.0.0.0                       100  32768 {65100,65300} ?
 s>  192.168.1.1/32   10.12.1.1                0             0 65100 ?
 s>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 s>  192.168.3.3/32   10.23.1.3                0             0 65300 ?
R2# show bgp ipv4 unicast 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 28
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  {65100,65300}, (aggregated by 65200 192.168.2.2)
    0.0.0.0 from 0.0.0.0 (192.168.2.2)
      Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, best
      rx pathid: 0, tx pathid: 0x

R1 does not install the 192.168.0.0/16 network for the same reasons that R3 does not install the 192.168.0.0/16 network. R1 thinks that the advertisement is a loop because it detects AS65100 in the advertisement. This can be confirmed by examining R1’s BGP table, as shown in Example 11-27.

Example 11-27 R1’s BGP Table, with 192.168.0.0/16 Discarded

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   10.12.1.0/24     10.12.1.2                0             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2                0             0 65200 ?
 *>  172.16.1.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.2.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.3.0/24    0.0.0.0                  0         32768 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?

Multiprotocol BGP for IPv6

Multiprotocol BGP (MP-BGP) enables BGP to carry NLRI for multiple protocols, such as IPv4, IPv6, and Multiprotocol Label Switching (MPLS) Layer 3 virtual private networks (L3VPNs).

RFC 4760 defines the following new features:

  • A new address family identifier (AFI) model

  • New BGPv4 optional and nontransitive attributes:

    • Multiprotocol reachable NLRI

    • Multiprotocol unreachable NLRI

The new multiprotocol reachable NLRI attribute describes IPv6 route information, and the multiprotocol unreachable NLRI attribute withdraws the IPv6 route from service. The attributes are optional and nontransitive, so if an older router does not understand the attributes, the information can just be ignored.

All the same underlying IPv4 path vector routing protocol features and rules also apply to MP-BGP for IPv6. MP-BGP for IPv6 continues to use the same well-known TCP port 179 for session peering as BGP uses for IPv4. During the initial open message negotiation, the BGP peer routers exchange capabilities. The MP-BGP extensions include an address family identifier (AFI) that describes the supported protocols, along with subsequent address family identifier (SAFI) attribute fields that describe whether the prefix applies to the unicast or multicast routing table:

  • IPv4 unicast: AFI: 1, SAFI: 1

  • IPv6 unicast: AFI: 2, SAFI: 1

Figure 11-13 demonstrates a simple topology with three different ASs and R2 forming an eBGP session with R1 and R3. The link-local addresses have been configured from the defined link-local range FE80::/10. All of R1’s links are configured to FE80::1, all of R2’s links are set to FE80::2, and all of R3’s links are configured for FE80::3. This topology is used throughout this section.

IPv6 sample topology is shown.

Figure 11-13 IPv6 Sample Topology

IPv6 Configuration

All the BGP configuration rules demonstrated earlier apply with IPv6, except that the IPv6 address family must be initialized, and the neighbor is activated. Routers with only IPv6 addressing must statically define the BGP RID to allow sessions to form.

The protocol used to establish the BGP session is independent of the AFI/SAFI route advertisements. The TCP session used by BGP is a Layer 4 protocol, and it can use either an IPv4 or IPv6 address to form a session adjacency and exchange routes. Advertising IPv6 prefixes over an IPv4 BGP session is feasible but beyond the scope of this book as additional configuration is required.

Note

Unique global unicast addressing is the recommended method for BGP peering to avoid operational complexity. BGP peering using the link-local address may introduce risk if the address is not manually assigned to an interface. A hardware failure or cabling move will change the MAC address, resulting in a new link-local address. This will cause the session to fail because the stateless address autoconfiguration will generate a new IP address.

Example 11-28 shows the IPv6 BGP configuration for R1, R2, and R3. The peering uses global unicast addressing for establishing the session. The BGP RID has been set to the IPv4 loopback format used throughout this book. R1 advertises all its networks through redistribution, and R2 and R3 use the network statement to advertise all their connected networks.

Example 11-28 Configuring IPv6 BGP

R1
router bgp 65100
 bgp router-id 192.168.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:0:12::2 remote-as 65200
 !
address-family ipv6
  neighbor 2001:DB8:0:12::2 activate
  redistribute connected
R2
router bgp 65200
 bgp router-id 192.168.2.2
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:0:12::1 remote-as 65100
 neighbor 2001:DB8:0:23::3 remote-as 65300
!
 address-family ipv6
  neighbor 2001:DB8:0:12::1 activate
  neighbor 2001:DB8:0:23::3 activate
  network 2001:DB8::2/12
8
  network 2001:DB8:0:12::/64
  network 2001:DB8:0:23::/64
R3
router bgp 65300
 bgp router-id 192.168.3.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:0:23::2 remote-as 65200
 !
 address-family ipv6
  neighbor 2001:DB8:0:23::2 activate
  network 2001:DB8::3/128
  network 2001:DB8:0:3::/64
  network 2001:DB8:0:23::/64

Note

IPv4 unicast routing capability is advertised by default in IOS unless the neighbor is specifically shut down within the IPv4 address family or globally within the BGP process with the command no bgp default ipv4-unicast.

Routers exchange AFI capabilities during the initial BGP session negotiation. The command show bgp ipv6 unicast neighbors ip-address [detail] displays detailed information on whether the IPv6 capabilities were negotiated successfully. Example 11-29 shows the fields that should be examined for IPv6 session establishment and route advertisement.

Example 11-29 Viewing BGP Neighbors for IPv6 Capabilities

R1# show bgp ipv6 unicast neighbors 2001:DB8:0:12::2
! Output omitted for brevity                                          
BGP neighbor is 2001:DB8:0:12::2,  remote AS 65200, external link
  BGP version 4, remote router ID 192.168.2.2
  BGP state = Established, up for 00:28:25
  Last read 00:00:54, last write 00:00:34, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv6 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
 ..
 For address family: IPv6 Unicast
  Session: 2001:DB8:0:12::2
  BGP table version 13, neighbor version 13/0
  Output queue size :

  Index 1, Advertise bit 0
  1 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               3         5 (Consumes 520 bytes)
    Prefixes Total:                 6         1

The command show bgp ipv6 unicast summary displays a status summary of the sessions, including the number of routes that have been exchanged and the session uptime.

Example 11-30 highlights the IPv6 AFI neighbor status for R2. Notice that the two neighbor adjacencies have been up for about 25 minutes. Neighbor 2001:db8:0:12::1 is advertising three routes, and neighbor 2001:db8:0:23::3 is advertising three routes.

Example 11-30 Verifying an IPv6 BGP Session

R2# show bgp ipv6 unicast summary
BGP router identifier 192.168.2.2, local AS number 65200
BGP table version is 19, main routing table version 19
7 network entries using 1176 bytes of memory
8 path entries using 832 bytes of memory
3/3 BGP path/bestpath attribute entries using 456 bytes of memory
2 BGP AS-PATH entries using 48 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
BGP using 2512 total bytes of memory
BGP activity 7/0 prefixes, 8/0 paths, scan interval 60 secs
Neighbor         V     AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
2001:DB8:0:12::1 4  65100      35      37     19   0    0 00:25:08        3
2001:DB8:0:23::3 4  65300      32      37     19   0    0 00:25:11        3

Example 11-31 shows the IPv6 unicast BGP tables for R1, R2, and R3. Notice that some of the routes include an unspecified address (::) as the next hop. An unspecified address indicates that the local router is generating the prefix for the BGP table. The weight value 32,768 also indicates that the prefix is locally originated by the router.

Example 11-31 Viewing the IPv6 BGP Tables

R1# show bgp ipv6 unicast
BGP table version is 13, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::1/128    ::                     0         32768 ?
 *>  2001:DB8::2/128    2001:DB8:0:12::2       0             0 65200 i
 *>  2001:DB8::3/128    2001:DB8:0:12::2                     0 65200 65300 i
 *>  2001:DB8:0:1::/64  ::                     0         32768 ?
 *>  2001:DB8:0:3::/64  2001:DB8:0:12::2                     0 65200 65300 i
 *   2001:DB8:0:12::/64 2001:DB8:0:12::2       0             0 65200 i
 *>                     ::                     0         32768 ?
 *>  2001:DB8:0:23::/64 2001:DB8:0:12::2                     0 65200 65300 i
R2# show bgp ipv6 unicast | begin Network
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::1/128    2001:DB8:0:12::1       0             0 65100 ?
 *>  2001:DB8::2/128    ::                     0         32768 i
 *>  2001:DB8::3/128    2001:DB8:0:23::3       0             0 65300 i
 *>  2001:DB8:0:1::/64  2001:DB8:0:12::1       0             0 65100 ?
 *>  2001:DB8:0:3::/64  2001:DB8:0:23::3       0             0 65300 i
 *>  2001:DB8:0:12::/64 ::                     0         32768 i
 *                      2001:DB8:0:12::1       0             0 65100 ?
 *>  2001:DB8:0:23::/64 ::                       0         32768 i
                        2001:DB8:0:23::3       0             0 65300 i
R3# show bgp ipv6 unicast | begin Network
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::1/128    2001:DB8:0:23::2                     0 65200 65100 ?
 *>  2001:DB8::2/128    2001:DB8:0:23::2       0             0 65200 i
 *>  2001:DB8::3/128    ::                     0         32768 i
 *>  2001:DB8:0:1::/64  2001:DB8:0:23::2                     0 65200 65100 ?
 *>  2001:DB8:0:3::/64  ::                     0         32768 i
 *>  2001:DB8:0:12::/64 2001:DB8:0:23::2       0             0 65200 i
 *>  2001:DB8:0:23::/64 ::                     0         32768       i

The BGP path attributes for an IPv6 route are displayed with the command show bgp ipv6 unicast prefix/prefix-length. Example 11-32 shows R3 examining R1’s loopback address. Some of the common fields, such as AS_Path, origin, and local preference, are identical to those for IPv4 routes.

Example 11-32 Viewing the BGP Path Attributes for an IPv6 Route

R3# show bgp ipv6 unicast 2001:DB8::1/128
BGP routing table entry for 2001:DB8::1/128, version 9
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  65200 65100
    2001:DB8:0:23::2 (FE80::2) from 2001:DB8:0:23::2 (192.168.2.2)
      Origin incomplete, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x

Example 11-33 shows the IPv6 BGP route entries for R2. Notice that the next-hop address is the link-local address for the next-hop forwarding address, which is resolved through a recursive lookup.

Example 11-33 Global RIB for BGP Learned IPv6 Routes

R2# show ipv6 route bgp
IPv6 Routing Table - default - 10 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
       H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
       IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
       ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
       RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
       a - Application
B   2001:DB8::1/128 [20/0]
     via FE80::1, GigabitEthernet0/0
B   2001:DB8::3/128 [20/0]
     via FE80::3, GigabitEthernet0/1
B   2001:DB8:0:1::/64 [20/0]
     via FE80::1, GigabitEthernet0/0
B   2001:DB8:0:3::/64 [20/0]
     via FE80::3, GigabitEthernet0/

IPv6 Summarization

The same process for summarizing or aggregating IPv4 routes occurs with IPv6 routes, and the format is identical except that the configuration is placed under the IPv6 address family using the command aggregate-address prefix/prefix-length [summary-only] [as-set].

Let’s revisit the previous IPv6 deployment but now want to summarize all the loopback addresses (2001:db8:0:1/128, 2001:db8:0:2/128, and 2001:db8:0:3/128) along with the peering link between R1 and R2 (2001:db8:0:12/64) on R2. The configuration would look as shown in Example 11-34.

Example 11-34 Configuring IPv6 BGP Aggregation on R2

router bgp 65200
 bgp router-id 192.168.2.2
 bgp log-neighbor-changes
 neighbor 2001:DB8:0:12::1 remote-as 65100
 neighbor 2001:DB8:0:23::3 remote-as 65300
 !
 address-family ipv4
  no neighbor 2001:DB8:0:12::1 activate
  no neighbor 2001:DB8:0:23::3 activate
 exit-address-family
 !
 address-family ipv6
  bgp scan-time 6
  network 2001:DB8::2/128
  network 2001:DB8:0:12::/64
  aggregate-address 2001:DB8::/59 summary-only                                   
  neighbor 2001:DB8:0:12::1 activate
  neighbor 2001:DB8:0:23::3 activate
 exit-address-famil

Example 11-35 shows the BGP tables on R1 and R3. You can see that all the smaller routes have been aggregated and suppressed into 2001:db8::/59, as expected.

Example 11-35 Verifying IPv6 Route Aggregation

R3# show bgp ipv6 unicast | b Network
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::/59      2001:DB8:0:23::2       0             0 65200 i
 *>  2001:DB8::3/128    ::                     0         32768 i
 *>  2001:DB8:0:3::/64  ::                     0         32768 i
 *>  2001:DB8:0:23::/64 ::                     0         32768 i
R1# show bgp ipv6 unicast | b Network
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::/59      2001:DB8:0:12::2       0             0 65200 i
 *>  2001:DB8::1/128    ::                     0         32768 ?
 *>  2001:DB8:0:1::/64  ::                     0         32768 ?
 *>  2001:DB8:0:12::/64 ::                     0         32768 ?
 *>  2001:DB8:0:23::/64 2001:DB8:0:12::2       0 65200 65300

The summarization of the IPv6 loopback addresses (2001:db8:0:1/128, 2001:db8:0:2/128, and 2001:db8:0:3/128) is fairly simple as they all fall into the base IPv6 summary range 2001:db8:0:0::/64. The fourth hextet beginning with a decimal value of 1, 2, or 3 would consume only 2 bits; the range could be summarized easily into the 2001:db8:0:0::/62 (or 2001:db8::/62) network range.

The peering link between R1 and R2 (2001:db8:0:12::/64) requires thinking in hex first, rather than in decimal values. The fourth hextet carries a decimal value of 18 (not 12), which requires 5 bits minimum. Table 11-5 lists the bits needed for summarization, the IPv6 summary address, and the component networks in the summary range.

Table 11-5 IPv6 Summarization Table

Bits Needed

Summary Address

Component Networks

2

2001:db8:0:0::/62

2001:db8:0:0::/64 through 2001:db8:0:3::/64

3

2001:db8:0:0::/61

2001:db8:0:0::/64 through 2001:db8:0:7::/64

4

2001:db8:0:0::/60

2001:db8:0:0::/64 through 2001:db8:0:F::/64

5

2001:db8:0:0::/59

2001:db8:0:0::/64 through 2001:db8:0:1F::/64

6

2001:db8:0:0::/58

2001:db8:0:0::/64 through 2001:db8:0:3F::/64

Currently the peering link between R2 and R3 (2001:db8:0:23::/64) is not being summarized and suppressed, as it is still visible in R1’s routing table in Example 11-35. The hex value of 23 (i.e. 0x23) converts to a decimal value of 35, which requires 6 bits. The summarized network range must be changed to 2001:db8::/58 for summarization of the 2001:db9:0:23::/64 network to occur. Example 11-36 shows the configuration change being made to R2.

Example 11-36 Configuring a Change to Summarize the 2001:db8:0:23::/64 Network

R2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# router bgp 65200
R2(config-router)# address-family ipv6 unicast
R2(config-router-af)# no aggregate-address 2001:DB8::/59 summary-only
R2(config-router-af)# aggregate-address 2001:DB8::/58 summary-onl

Example 11-37 verifies that the 2001:db8:0:23::/64 is now within the aggregate address space and is no longer being advertised to R1.

Example 11-37 Verifying Summarization of the 2001:db8:0:23::/64 Network

R1# show bgp ipv6 unicast | b Network
     Network            Next Hop          Metric LocPrf Weight Path
 *>  2001:DB8::/58      2001:DB8:0:12::2       0             0 65200 i
 *>  2001:DB8::1/128    ::                     0         32768 ?
 *>  2001:DB8:0:1::/64  ::                     0         32768 ?
 *>  2001:DB8:0:12::/64 ::                     0         32768 ?

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 11-6 lists these key topics and the page number on which each is found.

Table 11-6 Key Topics for Chapter 11

Key Topic Element

Description

Page

Section

Autonomous system numbers

242

Section

Path attributes

243

Paragraph

BGP attribute AS_Path

243

Paragraph

Address family databases and configuration

244

Section

Inter-router communication

244

Figure 11-2

BGP Single- and Multi-Hop Sessions

245

Section

BGP session types

245

Section

eBGP

247

Section

Basic BGP configuration

251

Section

Verification of BGP sessions

253

Section

Prefix advertisement

255

Figure 11-9

BGP Database Processing

258

Table 11-4

BGP Table Fields

259

List

BGP summarization techniques

263

Section

Aggregate address

264

Paragraph

Aggregate address with summary-only

267

Section

Atomic aggregate

269

Section

Route aggregation with AS_SET

270

Section

Multiprotocol BGP for IPv6

273

Section

IPv6 configuration

274

Section

IPv6 summarization

278

Complete Tables and Lists from Memory

There are no memory tables in this chapter.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

address family

AS_Path

atomic aggregate

autonomous system (AS)

eBGP session

iBGP session

Loc-RIB table

optional non-transitive

optional transitive

path vector routing protocol

well-known discretionary

well-known mandatory.

Use the Command Reference to Check Your Memory

Table 11-7 lists the important commands from this chapter. To test your memory, cover the right side of the table with a piece of paper, read the description on the left side, and see how much of the command you can remember.

Table 11-7 Command Reference

Task

Command Syntax

Initialize the BGP router process

router bgp as-number

Identify a BGP peer to establish a session with

neighbor ip-address remote-as as-number

Disable the automatic IPv4 address family configuration mode

no bgp default ip4-unicast

Initialize a specific address family and sub-address family

address-family afi safi

Activate a BGP neighbor for a specific address family

neighbor ip-address activate

Advertise a network to BGP

network network mask subnet-mask [route-map route-map-name]

Configure a BGP aggregate IPv4 prefix

aggregate-address network subnet-mask [summary-only] [as-set]

Configure a BGP aggregate IPv6 prefix

aggregate-address prefix/prefix-length [summary-only] [as-set]

Display the contents of the BGP database

show bgp afi safi [network] [detailed]

Display a summary of the BGP table and neighbor peering sessions

show bgp afi safi summary

Display the negotiated BGP settings with a specific peer and the number of prefixes exchanged with that peer

show bgp afi safi neighbors ip-address

Display the Adj-RIB-Out BGP table for a specific BGP neighbor

show bgp afi safi neighbor ip-address advertised routes

References in This Chapter

RFC 1654, A Border Gateway Protocol 4 (BGP-4), by Yakov Rekhter and Tony Li.https://www.ietf.org/rfc/rfc1654.txt, July 1994.

RFC 2858, Multiprotocol Extensions for BGP-4, by Yakov Rekhter, Tony Bates, Ravi Chandra, and Dave Katz. https://www.ietf.org/rfc/rfc2858.txt, June 2000.

RFC 4271, A Border Gateway Protocol 4 (BGP-4), Yakov Rekhter, Tony Li, and Susan Hares. https://www.ietf.org/rfc/rfc4271.txt, January 2006.

RFC 4760, Multiprotocol Extensions for BGP-4, by Yakov Rekhter, Tony Bates, Ravi Chandra, and Dave Katz. https://www.ietf.org/rfc/rfc4760.txt, January 2007.

RFC 4893, BGP Support for Four-octet AS Number Space, by Quaizar Vohra and Enke Chen. https://www.ietf.org/rfc/rfc4893.txt, May 2007.

IP Routing on Cisco IOS, IOS XE, and IOS XR, by Brad Edgeworth, Aaron Foss, and Ramiro Garza Rios. Cisco Press, 2014.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.237.24.82