Contents

1   Overview

This document provides an overview of the Border Gateway Protocol (BGP) and describes the tasks and commands used to configure, monitor, troubleshoot, and administer BGP features through the SmartEdge router.

BGP is an Exterior Gateway Protocol (EGP) based on distance-vector algorithms, and uses the Transmission Control Protocol (TCP) as its transport protocol. BGP is a protocol between two BGP nodes, or BGP speakers. First, the TCP connection is established and then the two BGP speakers exchange dynamic routing information over the connection. The exchange of messages is a BGP session between BGP peers.

The SmartEdge router supports multiple BGP features, including those specified in the following IETF drafts and RFCs:

• Base features:
  • Y. Rekhter, T. Li, RFC 4271, Border Gateway Protocol 4 (BGP-4), January 2006
  • Y. Rekhter, T. Li, Internet Draft, A Border Gateway Protocol 4 (BGP-4), draft-ietf-idr-bgp4-12.txt, January 2001
• Route reflection:

  T. Bates, R. Chandra, E. Chen, RFC 2796, BGP Route Reflection - An Alternative to Full Mesh IBGP, April 2000

• Autonomous system confederations:

  P. Traina, D. McPherson, J. Scudder, RFC 3065, Autonomous System Confederations for BGP, February 2001

• Extended Communities attribute:

  R. Chandra, P. Traina, T. Li, RFC 1997, BGP Communities Attribute, August 1996

• MD-5 authentication:

  A. Heffernan, RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option, August 1998

• Route-flap damping:

  C. Villamizar, R. Chandra, R. Govindan, RFC 2439, BGP Route Flap Damping, November 1998

• Capabilities advertisement:

  R. Chandra, J. Scudder, RFC 2842, Capabilities Advertisement with BGP-4, May 2000

• Multiprotocol extensions:

  T. Bates, R. Chandra, D. Katz, Y. Rekhter, RFC 2858, Multiprotocol Extensions for BGP-4, June 2000

• Route refresh capability:

  E. Chen, RFC 2918, Route Refresh Capability for BGP-4, September 2000

• Outbound route filtering (ORF) capability:

  E. Chen, Y. Rekhter, RFC 5291, Outbound Route Filtering Capability for BGP-4, August 2008

• Address prefix-based ORF capability:

  E. Chen, S. Sangli, RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4, August 2008

• Graceful restart capability:

  S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen, RFC 4274, Graceful Restart Mechanism for BGP, January 2007

• Four-byte autonomous system (AS) capability:

  Q. Vohra, E. Chen, Internet Draft, BGP Support For Four-Octet AS Number Space, draft-ietf-idr-as4bytes-03.txt, May 2001

The following additional features are also supported:

• Routing policies, including these types of filters:
  • Prefix lists
  • AS path lists
  • Route maps
• Address family identifier (AFI) and subsequent address family identifier (SAFI) configuration, including:
  • IPv4 unicast
  • IPv4 labeled
  • IPv4 multicast
  • IPv4 VPN
  • IPv6 unicast
  • IPv6 labeled
  • IPv6 VPN
• BGP route sourcing, including these methods:
  • Redistribution from other routing protocols into the BGP routing domain
  • Origination of BGP routes through the network command in BGP address family configuration mode

    Note:  

    The network command is available in the local context only. You cannot configure the network statement inside an IP VPN.

    
    
• Route aggregation through the support of the AS_SET attribute
• Default origination—both conditional and unconditional
• Maximum number of prefixes setting
• Next-Hop-Triggered BGP best-path calculation
• Multipath capability for both internal BGP (iBGP) and external BGP (eBGP).
• Peer groups, including these features:
  • Address family-specific grouping
  • Decoupling of peer groups and default origination
• 6PE: IPv6 on the provider edge (PE), which allows IPv6 to be tunneled over a MPLS/IPv4-based core network.
• 6VPE: VPN IPv6 on the provider edge (PE), which allows VPN IPv6 to be tunneled over a MPLS/IPv4-based core network.
• Route-flap statistics for both iBGP and eBGP
• Fast-reset of BGP sessions on receipt of a link-failure event.
• Configurable Minimum Route Advertisement Interval (MRAI) (using the advertisement-interval command).
• Optional verification of the first AS number in a received AS path from an eBGP peer.
• Accounting of routes by these methods:
  • Number of routes sourced
  • Number of routes accepted, active, dampened, and historical from each peer
  • Number of routes advertised to a peer
• Advanced debug facilities, including these features:
  • Per-neighbor based generation of debug messages
  • Storage and display of malformed messages and notification messages
  • Peer reset history

In-depth information on how BGP is structured, and how it operates, is described the sections that follow.

1.1   Introduction to iBGP and eBGP

Routers that belong to the same AS and exchange BGP updates are running iBGP, and routers that belong to different autonomous systems and exchange BGP updates are running eBGP.

Figure 1 illustrates the concept of autonomous systems and iBGP versus eBGP.

1.2   Introduction to iBGP Route Reflectors

Typically, iBGP speakers must be fully meshed. Any BGP speaker that receives messages from an external router must advertise the routes it receives to all BGP speakers in its autonomous system. However, if a route reflector is configured, although it must have connections to all other BGP speakers in the AS, not all other BGP speakers must be fully meshed. When a BGP speaker in the AS receives messages from an external router, it is sufficient to advertise these routes only to the route reflector, which then readvertises the bestpath of each route to all other BGP speakers in the AS.

Internal peers of the route reflector are divided into two groups: client peers and nonclient peers. A route reflector reflects routes between these two groups. The route reflector and its client peers form a cluster. Nonclient peers must be fully meshed with each other. Client peers are not required to be fully meshed and do not communicate with BGP speakers outside their cluster. If it is required, peer client-to-peer client route reflection can be disabled.

When the route reflector receives an advertised route:

• Any route from an external BGP speaker is advertised to all peers.
• Any route from a nonclient peer is advertised to all client peers.
• Any route from a client peer is advertised to all peers.

Figure 2 shows an example of iBGP networking using route reflection.

1.3   Introduction to iBGP Confederations

Another way to reduce iBGP mesh is to divide an autonomous system into subautonomous systems grouped by a routing domain identifier. The AS and its subautonomous systems are part of the same confederation. Externally, the confederation looks like a single AS. Each subautonomous system is fully meshed within itself and has a few connections to other subautonomous systems in the confederation.

Neighbors from other subautonomous systems are treated as special eBGP peers. Even though peers in different subautonomous systems engage in eBGP sessions, they exchange routing information as if they were iBGP peers. Specifically, the next-hop, the Multi-Exit Discriminator (MED), and local preference information is preserved, so that a single Interior Gateway Protocol (IGP) is used for all of the subautonomous systems; see Figure 3.

Note:  

For iBGP paths, the MED is always 0.

1.4   Route Aggregation

BGP4 supports Classless InterDomain Routing (CIDR). With CIDR, routers use the network prefix to determine the dividing point between the network number and the host number. For example, the range of addresses 128.186.1.0 to 128.186.1.255 can be represented as the network prefix 128.186.1.0/24; the 24 indicates that all addresses in the segment agree in their first 24 bits.

In addition, CIDR does not require a network to be of standard size, as is the case in classful addressing, which provides 8-bit (Class A), 16-bit (Class B), and 24-bit (Class C) network deployment. This flexibility in CIDR enables the creation of arbitrarily sized networks.

Of particular importance is CIDR’s ability to lend itself to the concept of route aggregation. The Internet is divided into addressing domains. Within a domain, detailed information is available about all of the networks that reside in the domain. Outside of an addressing domain, however, only the common network prefix is advertised. By allowing a single routing table entry to specify a route to many individual network addresses, aggregation minimizes the size of the routing table. A router cannot aggregate an address if it does not have a more specific route of that address in the BGP routing table. More specific routes can be injected in the BGP routing table by incoming updates from other autonomous systems.

1.5   Next-Hop-Triggered BGP Best-Path Calculation

By default, a change in a next-hop reachability does not immediately trigger a BGP best-path calculation. Instead, the SmartEdge router periodically checks whether any next-hop has changed since the last check, and if there has been a change, it runs BGP best-path calculations for all routes. This behavior reduces computational burden, but delays network convergence.

The next-hop-triggered BGP best-path calculation feature allows the user to change this default behavior. When the feature is enabled, the SmartEdge router runs the best-path calculation immediately upon notification of a next-hop change by the RIB, thereby improving the convergence time. A hold down time and a backoff mechanism prevent unnecessary churn and excessive CPU usage during network instability.

If next-hop best-path calculation is enabled for an address family, the periodic next-hop check is not performed for that address family.

Use the following commands to configure next-hop-triggered BGP best-path calculation:

• nexthop triggered—Enables the triggering of immediate BGP best-path calculation on notification of a next-hop withdrawal by the RIB.
• nexthop triggered delay—Defines the delay, in seconds or milliseconds, before starting the best-path calculation after a next-hop change notification. This delay allows time for the accumulation of more than one next-hop change into a single best-path calculation when multiple next-hop change events are expected in response to a network event.
• nexthop triggered holdtime—Defines the minimum interval, in seconds or milliseconds, between two consecutive next-hop triggered best-path calculations. During IGP churn, BGP limits the next-hop triggered best-path calculations first by the configured hold time, then by increasing the time through the configured backoff value for every new next-hop change that occurs before the expiration of the hold time. A hold time is not applicable across different next hops. In other words, a next-hop change for 10.12.13.14/32 followed by a next-hop change for 10.40.50.60/32 does not trigger a hold time. A next-hop change caused by an IGP route update and a next-hop change caused by an LSP route update will have individual hold times.

Note:  

Next-hop-triggered BGP best-path calculation is not supported for the IPv4 multicast address family.

The following commands show information related to BGP next-hop scanning:

• show bgp route summary [detail]
• debug bgp event

1.5.1   BGP Multipath

By default, BGP multipath capabilities are disabled, which means BGP installs a single path in the RIB for each destination. If that path fails and no other path has installed a path for that prefix, traffic destined for that path is lost until the path is available again.

When BGP multipath is enabled with the multi-paths command, BGP installs multiple best equal-cost paths in the routing table for load-balancing traffic to BGP destinations. With multipath, the paths can be:

• All iBGP (configured with the multi-paths internal path-num command)
• All eBGP (configured with the multi-paths external path-num command)
• In the VPN context, a combination of iBGP and eBGP, where only 1 eBGP path is allowed, and the number of allowed iBGP equal-cost paths is equal to the maximum number of paths allowed (configured with the multi-paths eibgp path-num command) minus 1. For example, if you configure eibgp 7, 6 iBGP paths and 1 eBGP path are installed in the RIB.

  Note:  

  The eibgp keyword is not supported for IPv6 traffic.

  
  

When BGP multipath capabilities are enabled, even though multiple paths are installed in the RIB, BGP advertises only one path (the BGP best path) to its peers.

1.6   MP-BGP

Multiprotocol BGP (MP-BGP) makes use of multiprotocol extensions to BGP4, as defined in RFC 2283, Multiprotocol Extensions for BGP-4, that allow other protocols to use BGP to exchange protocol-specific information.

One of the main advantages of MP-BGP is the ability to use BGP’s scalability and policy control, to easily configure routers to peer with other interdomain routers, exchange multicast source route information, and configure multicast routing policies using familiar BGP commands. MP-BGP also carries two sets of routes: one set for unicast routing and one set for multicast routing, allowing you to configure separate routing policies for unicast and multicast routes.

1.7   Routing Policy Triggered Update

Before Release 2.5, whenever there was a change in an inbound or outbound routing policy, such as a prefix-list, as-path-list, or route-map, for a BGP peer, the clear bgp neighbor ip-addr soft [in | out] command had to be manually issued to make the policy change effective. Currently, routing policy changes automatically take effect, and issuing the clear bgp neighbor ip-addr soft [in | out] command to update routing policies can cause updates to be unnecessarily sent, so it is not recommended.

To aggregate multiple policy changes, the operating system performs the necessary action 15 seconds after a policy change.

1.8   Non-Intrusive MD5 Password Change

The non-intrusive Message Digest 5 (MD5) password change feature for BGP allows you to change the password for a BGP peer without resetting the BGP session. The sections that follow describe in detail how the non-intrusive MD5 password change feature is implemented.

1.8.1   Replace a Password

When an old MD5 password is replaced by a new one in a BGP peer configuration, both passwords are allowed to coexist for authentication until the old password expires. To facilitate a smooth transition from the old to new password, a new configuration can be used to specify the time interval during which the old MD5 password coexists with the new one.

For a TCP connection that is already established, or is in one of the closing states when an existing password is replaced by a new MD5 password, both password strings coexist for authentication during the specified time interval before the old MD5 password expires. The old MD5 password continues to be used for authentication until either the password expires, or the remote TCP for the peer uses a new MD5 password.

For a TCP connection that is not yet established, when the old password is replaced, the local TCP immediately uses the new MD5 password.

Note:  

BGP keeps only the latest password string configured and the previous password to be replaced. That is, if a third password is configured before the timer for first (active) password expires, the oldest password is immediately deleted, and the expiration timer is started for the second password.

1.8.2   Add a New Password

This feature does not apply when configuring a new MD5 password for a peer while there is no existing password already configured for the peer. The BGP peer session is reset after the new MD5 password is configured.

1.8.3   Delete a Password

This feature does not apply when explicitly deleting a MD5 password from the BGP peer configuration.

When the current active MD5 password is deleted from the configuration, the old password (if existing) and the current password are both immediately deleted, and the BGP session with the peer is reset.

Note:  

To avoid BGP sessions from being reset when changing a peer MD5 password, we recommend that you do not delete the password from the configuration, and always use the password command to implicitly replace the password.

1.9   BGP Prefix-Based Outbound Route Filtering

A BGP speaker can use its local routing policy to filter out unwanted routes received from peers of the speaker. However, filtering uses resources on both the sender and receiver, which must generate and process BGP updates for the unwanted routes. To preserve resources in your network, you can use BGP prefix-based outbound route filtering (ORF) to prevent the generation and processing of these BGP updates.

With BGP prefix-based ORF, a BGP speaker sends a set of outbound route filters to a BGP peer. The peer applies these filters in addition to any locally configured outbound filters. These filters prevent unnecessary outbound routing updates from being sent to the speaker.

To configure ORF on your system:

• Configure the sending BGP speaker to send ORFs:
  • Use the send filter prefix-list command to advertise to a BGP peer that this BGP speaker can send prefixed-based filtering to the peer.
  
  
  • Use the prefix-list pl-name in command to apply the IP prefix list to a neighbor address family. Replace the pl-name argument with the name of the prefix list you want to apply.
• On the receiving BGP speaker (the speaker that applies the ORFs), use the accept filter prefix-list command to configure the receiving BGP speaker to accept ORFs received from the sending BGP speaker.

Note:  

When you enter the accept filter prefix-list and send filter prefix-list commands, the connection between the BGP speakers automatically resets. Because ORF capabilities are communicated between BGP speakers during BGP connection establishment, the accept filter prefix-list and send filter prefix-list commands do not take effect until the BGP connection resets.

1.10   BGP Graceful Restart Capabilities

Graceful restart is enabled on all BGP routing instances. When configured as a BGP speaker, the router:

• Preserves the forwarding state of the BGP speaker during a BGP restart
• Generates the end-of-Routing Information Base (RIB) marker on the completion of initial routing updates

The BGP speaker advertises these graceful restart capabilities to the peers.

Keep the following in mind when configuring graceful restart for a BGP routing instance:

• Graceful restart is always enabled on all BGP routing instances.
• Graceful restart is supported for all IPv4 and IPv6 address families. You must use the send label command to enable the negotiation of IPv4 and IPv6 labeled address families.
• When an iBGP peer restarts, the restarting and helper peers exchange graceful restart capabilities. In addition, all iBGP peers within the same domain exchange their graceful restart capabilities, including the list of IP address families with routes that can be gracefully restarted. The helper router helps restart only those iBGP peers that have the same address-family capabilities. Use the following commands to configure address-family capabilities:
  • See address-family ipv4 (BGP).
  • See address-family ipv6 unicast.
  • See address-family ipv6 vpn.

Note:  

To ensure that routes are maintained in an iBGP system, we recommend configuring all iBGP peers in a domain with the same address-family capabilities.

Figure 4 illustrates an example of how routes are maintained in an iBGP system. This example shows a system of four iBGP peers, where router A is the helper router. If router D fails, router A retains the address families and routes from router D only if routers B and C are configured with the same routing capabilities as router D. For example, if router D is configured with IPv4 unicast address family capabilities, router A retains those IPv4 unicast routes only if routers B and C are also configured with IPv4 unicast address family capabilities. If router D is configured with IPv4 unicast and IPv6 unicast capabilities, but routers B and C are configured only with IPv4 unicast address family capabilities, Router A retains only the IPv4 unicast address families and routers when router D fails.

1.11   Fast-Reset of BGP Sessions

The BGP fast-reset feature enables fast resetting of a BGP peer session when the links used to reach a neighbor go down.

When fast-reset is disabled, the BGP session is not reset immediately when the link used to reach that peer goes down. Instead, the BGP sessions remain connected to the peer until the configured BGP holdtime timer (set with the timers keepalive command in BGP router configuration mode) expires. If no packets are received from a peer within the configured hold time, the BGP session is reset.

When fast-reset is enabled, the configured hold time is ignored, and BGP drops its session with a peer immediately if the link to that peer goes down. When BGP fast-reset is enabled on peers, packet loss is minimized during link failures.

Fast-reset is supported on directly connected and multihop BGP sessions.

For directly connected eBGP peers, use the fast-reset command in BGP router configuration mode to specify the amount of time (in seconds) that must pass before the BGP routing process drops sessions of directly connected external peers when the link used to reach them goes down. In this case, the fast-reset configuration applies to all eBGP peers that are directly connected to the local system.

For iBGP or multihop eBGP sessions, a peer is reachable through a number of interfaces. To configure fast-reset for iBGP or multihop eBGP sessions, do the following:

1. Use the fast-reset command in BGP neighbor configuration or BGP peer group configuration mode to do the following:
   • Access BGP neighbor fast-reset configuration mode, where you create a BGP fast-reset interface list of links to a BGP neighbor; BGP fast-reset is triggered when all links in the list go down.

   • Configure the interval that must pass before BGP routing process triggers fast-reset after all of the links in the BGP fast-reset interface list go down.
2. Use the interface command in BGP neighbor fast-reset configuration mode to add an interface to a BGP fast-reset interface list; you can add up to 10 interfaces.

Consider the following when configuring BGP fast-reset on a multihop BGP session:

• A BGP session remains active as long as at least one of the interfaces in the BGP fast-reset interface list is up. When all of the interfaces in the list go down, BGP ignores the configured hold time (specified by the timers keepalive command ) and, instead, waits for the specified fast-reset interval before removing its sessions with the affected neighbor.
• If none of the specified interfaces are up in the configured BGP fast-reset interface list, BGP does not establish a session with a neighbor (regardless of whether the neighbor is reachable).
• If all of the interfaces configured in a fast-reset interface list go down, the BGP session goes down and does not become active again until at least one of the down interfaces comes up.
• When configuring BGP fast-reset for BGP peer groups:
  • The BGP fast-reset configuration for a particular neighbor takes precedence over the BGP fast-reset configuration for a peer group. For example, if a BGP neighbor is configured with a fast-reset interval of 50 milliseconds, and that neighbor belongs to a peer group that is configured with a fast-reset interval of 20 seconds, the BGP neighbor ignores the peer group configuration and uses the 50-millisecond interval.
  • If a neighbor does not already have BGP fast reset configured, that neighbor inherits the fast-reset configuration from the peer group.
  • If a neighbor has its own BGP fast-reset configuration, to return that neighbor to the default (where the neighbor inherits the BGP fast-reset configuration from the peer group), you must remove the neighbor from and the peer group and then add it back.

1.12   BGP Minimum Route Advertisement Interval

You can configure the Minimum Route Advertisement Interval (MRAI) by using the advertisement-interval command. The MRAI starts when an UPDATE message is sent to a BGP neighbor or peer group. After sending an UPDATE message to the specified BGP peers, the router waits for the specified MRAI before sending the next UPDATE message. If a route change occurs and the MRAI has passed since the last UPDATE message was sent, the router immediately sends an UPDATE message to the peer. If a route change occurs and the MRAI has not passed since the last UPDATE message was sent to the peer, the router waits the specified MRAI before sending a new UPDATE message.

Figure 5 illustrates an example of how MRAI sends UPDATE messages to BGP peers.

If the MRAI in Figure 5 is set to 20 seconds:

• The first route change occurs, so the BGP router immediately sends an UPDATE message to the specified peers and starts the MRAI. (The first route change always occurs at 0 seconds according to the MRAI).
• A second route change occurs 2 seconds after the MRAI starts. In this case, the router waits 18 more seconds before sending an UPDATE message to the specified peers. The router restarts the MRAI after sending the UPDATE message to the specified peers.
• A third route change occurs at 60 seconds. Because 40 seconds passed since the last UPDATE message was sent (40 seconds is greater than the configured MRAI of 20 seconds), the router immediately sends the third UPDATE message.

2   Configuration and Operations Tasks

Note:  

In this section, the command syntax in the task tables displays only the root command.

To configure BGP, perform the tasks described in the sections that follow.

2.1   Configuring BGP Routing Instances and Instance Attributes

A BGP routing instance enables the SmartEdge router to be a BGP speaker. In addition, many BGP parameters that can affect the global routing process can be configured within a BGP routing instance.

To configure a BGP routing instance and other instance attributes, perform the tasks described in the sections that follow.

2.1.1   Creating and Configuring a BGP Routing Instance

To configure a BGP routing instance, perform the tasks described in Table 1.

2.1.2   Configuring IPv4 Address Family Attributes for a BGP Routing Instance

To configure the IPv4 address family attributes for a BGP routing instance, perform the tasks described in Table 2.

2.1.3   Configuring IPv6 Address Family Attributes for a BGP Routing Instance

To configure the IPv6 address family attributes for a BGP routing instance, perform the tasks described in Table 3.

2.1.4   Configuring Graceful Restart Characteristics for a BGP Routing Instance

Graceful restart is always enabled in all BGP routing instances, and is supported for both IPv4 and IPv6 address families. You cannot disable BGP graceful restart on a BGP neighbor, but you can configure some characteristics.

Note:  

Before you can configure graceful restart for a BGP routing instance, you need to create and configure a BGP routing instance, as described in Creating and Configuring a BGP Routing Instance.

To configure the graceful restart characteristics for a BGP routing instance, perform the tasks described in Table 4. Enter all commands in BGP router configuration mode.

2.1.5   Configuring BGP Route Reflection

If a BGP route reflector is configured, while it must have connections to all other BGP speakers in the AS, not all other BGP speakers must be fully meshed. When a BGP speaker in the AS receives messages from an external router, it is sufficient to advertise these routes only to the router reflector, which then readvertises the routes to all other BGP speakers in the AS.

Note:  

Before you can configure a BGP router reflector, you need to create and configure a BGP routing instance, as described in Creating and Configuring a BGP Routing Instance.

To configure BGP route reflection, perform the tasks described in Table 5. Enter all commands in BGP router configuration mode.

2.1.6   Configuring a BGP Confederation

To reduce iBGP mesh, you can divide an autonomous system into subautonomous systems grouped by a routing domain identifier. The AS and its subautonomous systems are part of a BGP confederation. Externally, the confederation looks like a single autonomous system.

Note:  

Before you can configure a BGP confederation, you need to create and configure a BGP routing instance, as described in the Creating and Configuring a BGP Routing Instance.

To configure a BGP confederation, perform the tasks described in Table 6. Enter all commands in BGP router configuration mode.

2.2   Configuring BGP Neighbors and Neighbor Attributes

BGP speakers (BGP-enabled routers) that exchange inter-AS routing information are called BGP neighbors. BGP supports two kinds of neighbors: internal and external. Internal neighbors are in the same AS; external neighbors are in different autonomous systems. External neighbors must be adjacent to each other and share the same subnet, while internal neighbors may be located anywhere inside the same autonomous system.

To enable BGP speakers to effectively communicate with each other, each BGP speaker must be configured with information about its BGP neighbors.

The sections that follow describe how to configure a BGP neighbor and other neighbor attributes.

2.2.1   Configuring a BGP Neighbor

To configure a BGP neighbor, perform the tasks described in Table 7.

Note:  

Before you can configure a BGP neighbor, you need to create and configure a BGP routing instance, as described in Creating and Configuring a BGP Routing Instance.

2.2.2   Configuring IPv4 Address Family Attributes for a BGP Neighbor

To configure the IPv4 address family attributes for a BGP neighbor, perform the tasks described in Table 8.

Note:  

Before you can configure IPv4 address family attributes for a BGP neighbor, you need to configure the BGP neighbor, as described in Configuring a BGP Neighbor.

2.2.3   Configuring IPv6 Address Family Attributes for a BGP Neighbor

To configure the IPv6 address family attributes for a BGP neighbor, perform the tasks described in Table 9.

Note:  

Before you can configure IPv6 address family attributes for a BGP neighbor, you need to configure the BGP neighbor, as described in Configuring a BGP Neighbor.

2.2.4   Configuring Graceful Restart Characteristics for a BGP Neighbor

Graceful restart is always enabled on all BGP routing instances, and is supported for both IPv4 and IPv6 address families. You cannot disable BGP graceful restart on a BGP neighbor, but you can configure certain characteristics.

To configure the graceful restart characteristics for a BGP neighbor, perform the tasks described in Table 10.

Note:  

Before you can configure graceful restart for a BGP neighbor, you need to configure the BGP neighbor, as described in Configuring a BGP Neighbor.

2.3   Enabling IPv6 over an IPv4 MPLS Core

To enable IPv6 over an IPv4 MPLS core, perform the tasks described in Table 11.

Note:  

IPv6 over IPv4 MPLS configuration is supported in the local context only.

2.4   Configuring BGP Peer Groups and Peer Group Attributes

BGP peer groups are helpful in cases where many BGP neighbors are configured with the same update policies. Grouping a large number of neighbors into one or more peer groups simplifies modifications to a configuration and makes the BGP update calculation process more efficient. A BGP peer group can be an eBGP or as an iBGP peer group.

To configure a BGP peer group and other peer group attributes, perform the tasks described in the sections that follow.

2.4.1   Configuring a BGP Peer Group

To configure a BGP peer group, perform the tasks described in Table 12.

2.4.2   Configuring IPv4 Address Family Attributes for a BGP Peer Group

To configure IPv4 address family attributes for a BGP peer group, perform the tasks described in Table 13. Enter all commands in BGP peer group address family configuration mode, unless otherwise noted.

2.4.3   Configuring IPv6 Address Family Attributes for a BGP Peer Group

To configure IPv6 address family attributes for a BGP peer group, perform the tasks described in Table 14. Enter all commands in BGP peer group address family configuration mode, unless otherwise noted.

2.4.4   Applying Peer Group Attributes

A BGP neighbor, or BGP neighbor address family, can inherit attributes from the peer group to which a neighbor is assigned. The following BGP neighbor configuration mode commands represent attributes that cannot be customized per neighbor when the neighbor is assigned to a peer group: advertisement-interval, ebgp-multihop, local-as, send community, and timers keepalive. Attributes inherited from a peer group that can be customized per neighbor include those set by the following commands: description, password, send prefix, shutdown, and update-source.

To apply peer group attributes, perform the tasks described in Table 15.

2.5   Configuring BGP Prefix-Based ORF

To enable BGP prefix-based ORF, perform the tasks described in Table 16.

2.6   BGP Operations

To manage BGP functions, perform the appropriate tasks described in Table 17. Enter the show commands in any mode; enter the clear and debug commands in exec mode.

3   Configuration Examples

The sections that follow provide BGP configuration examples for basic BGP, next-hop triggered BGP best-path calculation, iMP-BGP peers, iMP-BGP peer groups, eMP-BGP peers, eMP-BGP peer groups, and IPv6 over an IPv4 core.

3.1   Example: Configure Basic BGP

The following example show the minimum commands needed to configure BGP:

[local]Router_A#config

[local]Router_A(config)#context local

[local]Router_A(config-ctx)#router bgp 64001

[local]Router_A(config-bgp)#router-id 1.1.1.71

[local]Router_A(config-bgp)#address-family ipv4 unicast

[local]Router_A(config-bgp-af)#redistribute static

[local]Router_A(config-bgp-af)#exit

[local]Router_A(config-bgp)#peer-group iBGP internal

[local]Router_A(config-bgp-peer-group)#next-hop-self

[local]Redback(config-bgp-peer-group)#update-source loopback0

[local]Redback(config-bgp-peer-group)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-peer-group)#exit

[local]Redback(config-bgp)#peer-group customer-routes external

[local]Redback(config-bgp-peer-group)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#route-map rmap1 out

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-peer-group)#exit

[local]Redback(config-bgp)#neighbor 1.1.1.1 internal

[local]Redback(config-bgp-neighbor)#peer-group ibgp

[local]Redback(config-bgp-neighbor)#exit

[local]Redback(config-bgp)#neighbor 2.2.2.2 external

[local]Redback(config-bgp-neighbor)#remote-as 200

[local]Redback(config-bgp-neighbor)#peer-group customer-routes

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#prefix-list bar in

[local]Redback(config-bgp-peer-af)#route-map foo2 in

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-neighbor)#exit

[local]Redback(config-bgp)#neighbor 3.3.3.3 external

[local]Redback(config-bgp-neighbor)#remote-as 300

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#prefix-list bar in

[local]Redback(config-bgp-peer-af)#route-map foo3 out

3.2   Example: Configure Next-Hop-Triggered BGP Best-Path Calculation

The following example shows how to enable and then configure next-hop triggered BGP best-path calculation:

[local]Router_A#config

[local]Router_A(config)#context local

[local]Router_A(config-ctx)#router bgp 64001

[local]Router_A(config-bgp)#address-family ipv4 unicast

[local]Router_A(config-bgp-af)#nexthop triggered

[local]Router_A(config-bgp-af)#nexthop triggered delay 30

[local]Router_A(config-bgp-af)#nexthop triggered holdtime 2 backoff 10

[local]Router_A(config-bgp-af)#commit

3.3   Example: Configure iMP-BGP Peers

The following example configures two iMP-BGP peers. Figure 6 shows the network topology for the configuration.

The configuration for Router_A is as follows:

[local]Router_A#config

[local]Router_A(config)#context local

[local]Router_A(config-ctx)#interface lo1 loopback

[local]Router_A(config-if)#ip address 10.200.1.1/32

[local]Router_A(config-if)#exit

[local]Router_A(config-ctx)#router bgp 100

[local]Router_A(config-bgp)#router-id 10.200.1.1

[local]Router_A(config-bgp)#neighbor 10.200.1.2 internal

[local]Router_A(config-bgp-neighbor)#update-source lo1

[local]Router_A(config-bgp-neighbor)#address-family ipv4 multicast

[local]Router_A(config-bgp-peer-af)#exit

[local]Router_A(config-bgp-neighbor)#exit

[local]Router_A(config-bgp)#exit

[local]Router_A(config-ctx)#ip route 10.200.1.2/32 102.1.1.2

The configuration for Router B is as follows:

[local]Router_B#config

[local]Router_B(config)#context local

[local]Router_B(config-ctx)#interface lo1 loopback

[local]Router_B(config-if)#ip address 10.200.1.2/32

[local]Router_B(config-if)#exit

[local]Router_B(config-ctx)#router bgp 100

[local]Router_B(config-bgp)#router-id 10.200.1.2

[local]Router_B(config-bgp)#neighbor 10.200.1.1 internal

[local]Router_B(config-bgp-neighbor)#update-source lo1

[local]Router_B(config-bgp-neighbor)#address-family ipv4 multicast

[local]Router_B(config-bgp-peer-af)#exit

[local]Router_B(config-bgp-neighbor)#exit

[local]Router_B(config-bgp)#exit

[local]Router_B(config-ctx)#ip route 10.200.1.1/32 102.1.1.1

3.4   Example: Configure an iMP-BGP Peer Group

The following example configures an iMP-BGP peer group for two iMP-BGP peers. Figure 7 shows the network topology for the configuration.

The configuration for Router_A is as follows:

[local]Router_A#config

[local]Router_A(config)#context local

[local]Router_A(config-ctx)#interface lo1 loopback

[local]Router_A(config-if)#ip address 10.200.1.1/32

[local]Router_A(config-if)#exit

[local]Router_A(config-ctx)#router bgp 100

[local]Router_A(config-bgp)#router-id 10.200.1.1

[local]Router_A(config-bgp)#address-family ipv4 multicast

[local]Router_A(config-bgp-af)#exit

[local]Router_A(config-bgp)#peer-group iMBGP internal

[local]Router_A(config-bgp-peer-group)#update-source lo1

[local]Router_A(config-bgp-peer-group)#address-family ipv4 multicast

[local]Router_A(config-bgp-peer-af)#exit

[local]Router_B(config-bgp-peer-group)#exit 

[local]Router_A(config-bgp)#neighbor 10.200.1.2 internal

[local]Router_A(config-bgp-neighbor)#peer-group iMBGP

The configuration for Router_B is as follows:

[local]Router_B#config

[local]Router_B(config)#context local

[local]Router_B(config-ctx)#interface lo1 loopback

[local]Router_B(config-if)#ip address 10.200.1.2/32

[local]Router_B(config-if)#exit

[local]Router_B(config-ctx)#router bgp 100

[local]Router_B(config-bgp)#router-id 10.200.1.2

[local]Router_B(config-bgp)#address-family ipv4 multicast

[local]Router_B(config-bgp-af)#exit

[local]Router_B(config-bgp)#peer-group iMBGP internal

[local]Router_B(config-bgp-peer-group)#update-source lo1

[local]Router_B(config-bgp-peer-group)#address-family ipv4 multicast

[local]Router_B(config-bgp-peer-af)#exit

[local]Router_B(config-bgp-peer-group)#exit 

[local]Router_B(config-bgp)#neighbor 10.200.1.1 internal

[local]Router_B(config-bgp-neighbor)#peer-group iMBGP

3.5   Example: Configure eMP-BGP Peers

The following example configures two eMP-BGP peers. Figure 8 shows the network topology for the configuration.

The configuration for Router_B is as follows:

[local]Router_B#config

[local]Router_B(config)#context local

[local]Router_B(config-ctx)#interface lo1 loopback

[local]Router_B(config-if)#ip address 10.200.1.2/32

[local]Router_B(config-if)#exit

[local]Router_B(config-ctx)#router bgp 100

[local]Router_B(config-bgp)#router-id 10.200.1.2

[local]Router_B(config-bgp)#neighbor 10.200.1.3 external

[local]Router_B(config-bgp-neighbor)#remote-as 200

[local]Router_B(config-bgp-neighbor)#ebgp-multihop 10

[local]Router_B(config-bgp-neighbor)#update-source lo1

[local]Router_B(config-bgp-neighbor)#address-family ipv4 multicast

The configuration for Router_C is as follows:

[local]Router_C#config

[local]Router_C(config)#context local

[local]Router_C(config-ctx)#interface lo1 loopback

[local]Router_C(config-if)#ip address 10.200.1.3/32

[local]Router_C(config-if)#exit

[local]Router_C(config-ctx)#router bgp 100

[local]Router_C(config-bgp)#router-id 10.200.1.2

[local]Router_C(config-bgp)#neighbor 10.200.1.1 internal

[local]Router_C(config-bgp-neighbor)#remote-as 100

[local]Router_C(config-bgp-neighbor)#ebgp-multihop 10

[local]Router_C(config-bgp-neighbor)#update-source lo1

[local]Router_C(config-bgp-neighbor)#address-family ipv4 multicast

3.6   Example: Configure an eMP-BGP Peer Group

The following example configures an eMP-BGP peer group for two eMP-BGP peers. Figure 9 shows the network topology for the configuration.

The configuration for Router_B is as follows:

[local]Router_B#config

[local]Router_B(config)#context local

[local]Router_B(config-ctx)#interface lo1 loopback

[local]Router_B(config-if)#ip address 10.200.1.2/32

[local]Router_B(config-if)#exit

[local]Router_B(config-ctx)#router bgp 100

[local]Router_B(config-bgp)#router-id 10.200.1.2

[local]Router_B(config-bgp)#address-family ipv4 multicast

[local]Router_B(config-bgp-af)#exit

[local]Router_B(config-bgp)#peer-group eMBGP external

[local]Router_B(config-bgp-peer-group)#ebgp-multihop 10

[local]Router_B(config-bgp-peer-group)#update-source lo1

[local]Router_B(config-bgp-peer-group)#address-family ipv4 multicast

[local]Router_B(config-bgp-peer-af)#exit

[local]Router_B(config-bgp-peer-group)#neighbor 10.200.1.3 external

[local]Router_B(config-bgp-neighbor)#remote-as 200

[local]Router_B(config-bgp-neighbor)#peer-group eMBGP

The configuration for Router_C is as follows:

[local]Router_C#config

[local]Router_C(config)#context local

[local]Router_C(config-ctx)#interface lo1 loopback

[local]Router_C(config-if)#ip address 10.200.1.3/32

[local]Router_C(config-if)#exit

[local]Router_C(config-ctx)#router bgp 200

[local]Router_C(config-bgp)#router-id 10.200.1.3

[local]Router_C(config-bgp)#address-family ipv4 multicast

[local]Router_C(config-bgp-af)#exit

[local]Router_C(config-bgp)#peer-group eMBGP external

[local]Router_C(config-bgp-peer-group)#ebgp-multihop 10

[local]Router_C(config-bgp-peer-group)#update-source lo1

[local]Router_C(config-bgp-peer-group)#address-family ipv4 multicast

[local]Router_C(config-bgp-peer-af)#exit

[local]Router_C(config-bgp-peer-group)#neighbor 10.200.1.2 external

[local]Router_C(config-bgp-neighbor)#remote-as 100

[local]Router_C(config-bgp-neighbor)#peer-group eMBGP

3.7   Example: Configure IPv6 over an IPv4 Core

The following example shows how to enable IPv6 over an MPLS IPv4 core in the SmartEdge router. Perform this configuration on a PE router that has at least one IPv4 session with a PE neighbor and one IPv6 session with a CE neighbor:

[local]Router_C#config context local

[local]Router_A(config-ctx)#router bgp 100

[local]Router_C(config-bgp)#address-family ipv6 unicast

[local]Router_C(config-bgp-af)#exit

[local]Router_C(config-bgp)#neighbor 10.200.1.3 internal

[local]Router_C(config-bgp-neighbor)#address-family ipv6 unicast

[local]Router_C(config-bgp-peer-af)#send label

[local]Router_C(config-bgp-peer-af)#commit

3.8   Example: Configure BGP ORF

The following example shows how to configure BGP ORF between a BGP speaker (IP address 192.168.255.120) and its BGP peer (IP address 192.168.255.110):

The following example creates an IP prefix list called ORF-test that has three filters:

[local]Redback#configure
[local]Redback(config)#context local
[local]Redback(config-ctx)#ip prefix-list ORF-test
[local]Redback(config-prefix-list)#seq 10 permit 192.168.128.0/24 ge 24
[local]Redback(config-prefix-list)#seq 15 permit 192.168.127.0/24 le 18
[local]Redback(config-prefix-list)#seq 20 deny any

The following example advertises to a BGP neighbor that this BGP speaker can send prefixed-based filtering to the peer, and applies the IP prefix list ORF-test to the BGP peer:

[local]Redback#configure
[local]Redback(config)#context local
[local]Redback(config-ctx)#router bgp 999
[local]Redback(config-bgp)#neighbor 192.168.255.110 external
[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast
[local]Redback(config-bgp-peer-af)#prefix-list ORF-test in

The following example configures the BGP peer (whose IP address is 192.168.255.110) to accept ORFs received from the sending BGP speaker (whose IP address is 192.168.255.120):

[local]Redback#configure
[local]Redback(config)#context local
[local]Redback(config-ctx)#router bgp 100
[local]Redback(config-bgp)#neighbor 192.168.255.120 external
[local]Redback(config-bgp-neighbor)#accept filter prefix-list 

3.9   Example: Configure BGP Route Redistribution and Aggregation

The following example configures route redistribution and aggregation for a BGP routing instance. First, configure a list of aggregate IP prefixes:

[local]Router(config-ctx)#ipv6 prefix-list test1-aggregate
[local]Router(config-ipv6-prefix-list)#seq 10 permit 4001:101:101:106::/64 ge 64
[local]Router(config-ipv6-prefix-list)#seq 20 permit 5001:101:101:106::/64 ge 64
[local]Router(config-ipv6-prefix-list)#seq 30 permit 6001:101:101:106::/64 ge 64
[local]Router(config-ipv6-prefix-list)#seq 40 permit 7001:101:101:106::/64 ge 64
[local]Router(config-ipv6-prefix-list)#seq 50 permit 2001:101:101::/48 ge 48

Next, configure route map test1 that aggregates the IPv6 prefixes in the aggregate prefix list called test1-aggregate:

[local]Router(config-ctx)#route-map test1 permit 10
[local]Router(config-route-map)#match ipv6 address prefix-list test1-aggregate
[local]Router(config-route-map)#set ipv6 aggregate test1-aggregate

Specify that routes selected for redistribution are summarized only if they contain any of the prefixes specified in IPv6 prefix list test1:

[local]Redback(config-ctx)#router bgp 1
[local]Redback(config-bgp)#address-family ipv6 unicast
[local]Redback(config-bgp-af)#redistribute static route-map test1

Configure the static routes. In this example, the routes match aggregate prefix 2001:101:101::/48:

[local]Redback(config-ctx)#ipv6 route 2001:101:101:303::/64 80::2
[local]Redback(config-ctx)#ipv6 route 2001:101:101:304::/64 80::2
[local]Redback(config-ctx)#ipv6 route 2001:101:101:305::/64 80::2
[local]Redback(config-ctx)#ipv6 route 2001:101:101:306::/64 80::2
[local]Redback(config-ctx)#ipv6 route 2001:101:101:307::/64 80::2

Note:  

When an IP prefix list is used for aggregation, the ge and le parameters (configured with the seq command) are ignored, and the prefix list entries match any route subsumed by the prefix. In such cases, the ge parameter is implicit.