Border Gateway Protocol (BGP) is an exterior gateway protocol (EGP). It is called internal BGP (IBGP) when it runs within an AS and called external BGP (EBGP) when it runs between ASs. The current version in use is BGP-4 (RFC 4271).

BGP characteristics

BGP has the following characteristics:

· Focuses on route control and selection rather than route discovery and calculation.

· Uses TCP to enhance reliability.

· Measures the distance of a route by using a list of ASs that the route must travel through to reach the destination. BGP is also called a path-vector protocol.

· Supports CIDR.

· Reduces bandwidth consumption by advertising only incremental updates. BGP is very suitable to advertise large numbers of routes on the Internet.

· Eliminates routing loops by adding AS path information to BGP route updates.

· Uses policies to implement flexible route filtering and selection.

· Has good scalability.

BGP speaker and BGP peer

A router running BGP is a BGP speaker. A BGP speaker establishes peer relationships with other BGP speakers to exchange routing information over TCP connections.

BGP peers include the following types:

· IBGP peers—Reside in the same AS as the local router.

· EBGP peers—Reside in different ASs from the local router.

Based on the IP version, a BGP peer can be either of the following types:

· IPv4 peer—Uses an IPv4 address to establish a peer relationship with the local router.

· IPv6 peer—Uses an IPv6 address to establish a peer relationship with the local router.

BGP message types

BGP uses the following message types:

· Open—After establishing a TCP connection, BGP sends an OPEN message to establish a session to the peer.

· Update—BGP sends UPDATE messages to exchange routing information between peers. Each UPDATE message can advertise a group of feasible routes with identical attributes and multiple withdrawn routes.

· Keepalive—BGP sends KEEPALIVE messages between peers to maintain connectivity.

· Route-refresh—BGP sends a ROUTE-REFRESH message to request the routing information for a specific address family from a peer.

· Notification—BGP sends a NOTIFICATION message upon detecting an error and immediately closes the connection.

BGP finite state machine

During session establishment, the devices at the two ends transition between different BGP states, as shown in Figure 1.

Figure 1 BGP finite state machine

‌

Idle

The idle state is the initial BGP state. In this state, BGP rejects any connection requests. Only upon receiving a Start event, the device assigns resources to BGP, and attempts to establish a TCP connection and transition to Connect state.

BGP transitions to Idle state from the remaining states upon a TCP disconnection error, packet error, connection closed due to configuration issues, and reception of a NOTIFICATION message.

Connect

In this state, BGP starts a Connect Retry timer and waits for TCP connection establishment to be completed.

· If TCP connection establishment succeeds before the Connect Retry timer expires, BGP closes the Connect Retry timer, sends an OPEN message to the peer, and transitions to OpenSent state.

· If TCP connection establishment fails before the Connect Retry timer expires, BGP transitions to Active state.

· If the Connect Retry timer expires, and no connection response is received, BGP resets the Connect Retry timer, tries to establish a TCP connection with the peer again, and stays in Connect state.

Active

In this state, BGP continuously attempts to establish a TCP connection.

· If TCP connection establishment succeeds, BGP closes the Connect Retry timer, sends an OPEN message to the peer, and transitions to OpenSent state.

· If TCP connection establishment fails, BGP resets the Connect Retry timer and stays in Active state.

· If the Connect Retry timer expires and no connection response is received, BGP resets the Connect Retry timer and transitions to Connect state.

OpenSent

In this state, BGP waits for an OPEN message from the peer, and checks the BGP version number and AS number in the OPEN message.

· If the OPEN message is correct, BGP sends a KEEPALIVE message to the peer, and transitions to OpenConfirm state.

· If the OPEN message is incorrect, BGP sends a NOTIFICATION message to the peer, and transitions to Idle state.

If the TCP connection is disconnected in this state, BGP resets the Connect Retry timer, transitions to Active state, and tries to establish a TCP connection again.

OpenConfirm

In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.

· Upon receiving a KEEPALIVE message, BGP transitions to Established state.

· Upon receiving a NOTIFICATION message, BGP transitions to Idle state.

Established

In this state, BGP can exchange UPDATE, KEEPALIVE, ROUTE-REFRESH, and NOTIFICATION messages with the peer.

· Upon receiving a correct UPDATE or KEEPALIVE message, BGP stays in Established state.

· Upon receiving an incorrect UPDATE or KEEPALIVE message, BGP sends a NOTIFICATION message to the peer and transitions to Idle state.

· Upon receiving a ROUTE-REFRESH message, BGP does not change its state.

· Upon receiving a NOTIFICATION message, BGP transitions to Idle state.

BGP path attributes

BGP uses the following path attributes in UPDATE messages for route filtering and selection:

ORIGIN

The ORIGIN attribute specifies the origin of BGP routes. This attribute has the following types:

· IGP—Has the highest priority. Routes generated in the local AS have the IGP attribute.

· EGP—Has the second highest priority. Routes obtained through EGP have the EGP attribute.

· INCOMPLETE—Has the lowest priority. The source of routes with this attribute is unknown. Routes redistributed from other routing protocols have the INCOMPLETE attribute.

AS_PATH

The AS_PATH attribute identifies the ASs through which a route has passed. Before advertising a route to another AS, BGP adds the local AS number into the AS_PATH attribute, so the receiver can determine ASs to route the message back.

The AS_PATH attribute has the following types:

· AS_SEQUENCE—Arranges AS numbers in sequence. As shown in Figure 2, the number of the AS closest to the receiver's AS is leftmost.

· AS_SET—Arranges AS numbers randomly.

Figure 2 AS_PATH attribute

‌

BGP uses the AS_PATH attribute to implement the following functions:

· Avoid routing loops—A BGP router does not receive routes containing the local AS number to avoid routing loops.

· Affect route selection—BGP gives priority to the route with the shortest AS_PATH length if other factors are the same. As shown in Figure 2, the BGP router in AS 50 gives priority to the route passing AS 40 for sending data to the destination 8.0.0.0. In some applications, you can apply a routing policy to control BGP route selection by modifying the AS_PATH length. For more information about routing policy, see "Configuring routing policies."

· Filter routes—By using an AS path list, you can filter routes based on AS numbers contained in the AS_PATH attribute. For more information about AS path list, see "Configuring routing policies."

NEXT_HOP

The NEXT_HOP attribute may not be the IP address of a directly connected router. Its value is determined as follows:

· When a BGP speaker advertises a self-originated route to a BGP peer, it sets the address of the sending interface as the NEXT_HOP.

· When a BGP speaker sends a received route to an EBGP peer, it sets the address of the sending interface as the NEXT_HOP.

· When a BGP speaker sends a route received from an EBGP peer to an IBGP peer, it does not modify the NEXT_HOP attribute. If load balancing is configured, BGP modifies the NEXT_HOP attribute for the equal-cost routes. For load balancing information, see "BGP load balancing."

Figure 3 NEXT_HOP attribute

‌

MED (MULTI_EXIT_DISC)

BGP advertises the MED attribute between two neighboring ASs, each of which does not advertise the attribute to any other AS.

Similar to metrics used by IGPs, MED is used to determine the optimal route for traffic going into an AS. When a BGP router obtains multiple routes to the same destination but with different next hops, it selects the route with the smallest MED value as the optimal route. As shown in Figure 4, traffic from AS 10 to AS 20 travels through Router B that is selected according to MED.

Figure 4 MED attribute

‌

Generally BGP only compares MEDs of routes received from the same AS. You can also use the compare-different-as-med command to force BGP to compare MED values of routes received from different ASs.

LOCAL_PREF

The LOCAL_PREF attribute is exchanged between IBGP peers only, and is not advertised to any other AS. It indicates the priority of a BGP router.

BGP uses LOCAL_PREF to determine the optimal route for traffic leaving the local AS. When a BGP router obtains multiple routes to the same destination but with different next hops, it selects the route with the highest LOCAL_PREF value as the optimal route. As shown in Figure 5, traffic from AS 20 to AS 10 travels through Router C that is selected according to LOCAL_PREF.

Figure 5 LOCAL_PREF attribute

‌

COMMUNITY

The COMMUNITY attribute identifies the community of BGP routes. A BGP community is a group of routes with the same characteristics. It has no geographical boundaries. Routes of different ASs can belong to the same community.

A route can carry one or more COMMUNITY attribute values (each of which is represented by a 4-byte integer). A router uses the COMMUNITY attribute to determine whether to advertise the route and the advertising scope without using complex filters such as ACLs. This mechanism simplifies routing policy configuration, management, and maintenance.

Well-known COMMUNITY attributes involve the following:

· INTERNET—By default, all routes belong to the Internet community. Routes with this attribute can be advertised to all BGP peers.

· NO_EXPORT—Routes with this attribute cannot be advertised out of the local AS or out of the local confederation, but can be advertised to other sub-ASs in the confederation. For confederation information, see "Settlements for problems in large-scale BGP networks."

· No_ADVERTISE—Routes with this attribute cannot be advertised to other BGP peers.

· No_EXPORT_SUBCONFED—Routes with this attribute cannot be advertised out of the local AS or other sub-ASs in the local confederation.

You can configure BGP community lists to filter BGP routes based on the BGP COMMUNITY attribute.

Extended community attribute

To meet new demands, BGP defines the extended community attribute. The extended community attribute has the following advantages over the COMMUNITY attribute:

· Provides more attribute values by extending the attribute length to eight bytes.

· Allows for using different types of extended community attributes in different scenarios to enhance route filtering and control and simplify configuration and management.

The device supports t he link bandwidth attribute, the route target attribute and the Site of Origin (SoO) extended community attribute. For information about route target, see MCE configuration in MCE Configuration Guide.

The link bandwidth attribute identifies the interface bandwidth used for EBGP peer relationship establishment. BGP advertises this attribute to IBGP peers in route updates.

The SoO attribute specifies the site where the route originated. It prevents advertising a route back to the originating site. If the AS-path attribute is lost, the router can use the SoO attribute to avoid routing loops.

The SoO attribute has the following formats:

· 16-bit AS number:32-bit user-defined number. For example, 100:3.

· 32-bit IP address:16-bit user-defined number. For example, 192.168.122.15:1.

· 32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is 65536. For example, 65536:1.

· 32-bit IP address/IPv4 address mask length:16-bit user-defined number. For example, 192.168.122.15/24:1.

· 32-bit AS number in dotted format:16-bit user-defined number. For example, 65535.65535:1.

BGP route selection

BGP discards routes with unreachable NEXT_HOPs. If multiple routes to the same destination are available, BGP selects the optimal route in the following sequence:

1. The route with the highest Preferred_value.

2. The route with the highest LOCAL_PREF.

3. The route generated by the network command, the route redistributed by the import-route command, or the summary route in turn.

4. The route with the smallest AIGP attribute value.

5. The route with the shortest AS_PATH.

6. The IGP, EGP, or INCOMPLETE route in turn.

7. The route with the lowest MED value.

8. The route learned from EBGP, confederation EBGP, confederation IBGP, or IBGP in turn.

9. The route with the smallest IGP metric.

10. The route with the smallest recursion depth.

11. If a route received from an EBGP peer is the current optimal route, BGP does not change the optimal route when it receives routes from other EBGP peers.

12. The route advertised by the router with the smallest router ID.

If one of the routes is advertised by a route reflector, BGP compares the ORIGINATOR_ID of the route with the router IDs of other routers. Then, BGP selects the route with the smallest ID as the optimal route.

13. The route with the shortest CLUSTER_LIST.

14. The route advertised by the peer with the lowest IP address.

The CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that contains its own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing loops.

If load balancing is configured, the system selects available routes to implement load balancing.

BGP route advertisement rules

BGP follows these rules for route advertisement:

· When multiple feasible routes to a destination exist, BGP advertises only the optimal route to its peers. If the advertise-rib-active command is configured, BGP advertises the optimal route in the IP routing table. If not, BGP advertises the optimal route in the BGP routing table.

· BGP advertises only routes that it uses.

· BGP advertises routes learned from an EBGP peer to all BGP peers, including both EBGP and IBGP peers.

· BGP advertises routes learned from an IBGP peer to EBGP peers, rather than other IBGP peers.

· After establishing a session to a new BGP peer, BGP advertises all the routes matching the above rules to the peer. After that, BGP advertises only incremental updates to the peer.

BGP load balancing

BGP load balancing is applicable between EBGP peers, between IBGP peers, and between confederations.

BGP implements load balancing through route recursion and route selection.

BGP load balancing through route recursion

The next hop of a BGP route might not be directly connected. One of the reasons is that the next hop information exchanged between IBGP peers is not modified. The BGP router must find the directly connected next hop through IGP. The matching route with the direct next hop is called the recursive route. The process of finding a recursive route is route recursion.

If multiple recursive routes to the same destination are load balanced, BGP generates the same number of next hops to forward packets.

BGP load balancing based on route recursion is always enabled in the system.

BGP load balancing through route selection

IGP routing protocols, such as OSPF, can use route metrics as criteria to load balance between routes that have the same metric. BGP cannot load balance between routes by route metrics as an IGP protocol does, because BGP does not have a route computation algorithm.

BGP uses the following load balancing criteria to determine load balanced routes:

· The routes have the same ORIGIN, LOCAL_PREF, AIGP, and MED attributes.

· The routes meet the following requirements on the AS_PATH attribute:

¡ If the balance as-path-neglect command is configured, the routes can have different AS_PATH attributes.

¡ If only the balance as-path-relax command is configured, the routes can have different AS_PATH attributes, but the length of the AS_PATH attributes must be the same.

¡ If neither the balance as-path-neglect nor the balance as-path-relax command is configured, the routes must have the same AS_PATH attribute.

· The next hops of the routes meet the following requirements on IGP metrics:

¡ If the bestroute igp-metric-ignore command is not configured, the next hops of the routes must have the same IGP metric value.

¡ If the bestroute igp-metric-ignore command is configured, the next hops of the routes can have different IGP metric values.

BGP does not use the route selection rules described in "BGP route selection" for load balancing.

As shown in Figure 6, Router A and Router B are IBGP peers of Router C. Router C allows a maximum number of two ECMP routes for load balancing.

Router D and Router E both advertise a route 9.0.0.0 to Router C. Router C installs the two routes to its routing table for load balancing if the routes meet the BGP load balancing criteria. After that, Router C forwards to Router A and Router B a single route whose attributes are changed as follows:

· AS_PATH attribute:

¡ If the balance as-path-neglect and balance as-path-relax commands are not configured, the AS_PATH attribute does not change.

¡ If the balance as-path-neglect or balance as-path-relax command is configured, the AS_PATH attribute is changed to the attribute of the optimal route.

· The NEXT_HOP attribute is changed to the IP address of Router C.

· Other attributes are changed to be the same as the optimal route.

Figure 6 Network diagram

‌

Settlements for problems in large-scale BGP networks

You can use the following methods to facilitate management and improve route distribution efficiency on a large-scale BGP network.

Route summarization

Route summarization can reduce the BGP routing table size by advertising summary routes rather than more specific routes.

The system supports both manual and automatic route summarization. Manual route summarization allows you to determine the attribute of a summary route and whether to advertise more specific routes.

Route dampening

Route flapping (a route comes up and disappears in the routing table frequently) causes BGP to send many routing updates. It can consume too many resources and affect other operations.

In most cases, BGP runs in complex networks where route changes are more frequent. To solve the issue caused by route flapping, you can use BGP route dampening to suppress unstable routes.

BGP route dampening uses a penalty value to judge the stability of a route. The bigger the value, the less stable the route. Each time a route state changes from reachable to unreachable, or a reachable route's attribute changes, BGP adds a penalty value of 1000 to the route. When the penalty value of the route exceeds the suppress value, the route is suppressed and cannot become the optimal route. When the penalty value reaches the upper limit, no penalty value is added.

If the suppressed route does not flap, its penalty value gradually decreases to half of the suppress value after a period of time. This period is called "Half-life." When the value decreases to the reusable threshold value, the route is usable again.

Figure 7 BGP route dampening

‌

Peer group

You can organize BGP peers with the same attributes into a group to simplify their configurations.

When a peer joins the peer group, the peer obtains the same configuration as the peer group. If the configuration of the peer group is changed, the configuration of group members is changed.

Community

You can apply a community list or an extended community list to a routing policy for route control. For more information, see "BGP path attributes."

Route reflector

IBGP peers must be fully meshed to maintain connectivity. If n routers exist in an AS, the number of IBGP connections is n(n-1)/2. If a large number of IBGP peers exist, large amounts of network and CPU resources are consumed to maintain sessions.

Using route reflectors can solve this issue. In an AS, a router acts as a route reflector, and other routers act as clients connecting to the route reflector. The route reflector forwards routing information received from a client to other clients. In this way, all clients can receive routing information from one another without establishing BGP sessions.

A router that is neither a route reflector nor a client is a non-client, which, as shown in Figure 8, must establish BGP sessions to the route reflector and other non-clients.

Figure 8 Network diagram for a route reflector

‌

The route reflector and clients form a cluster. Typically a cluster has one route reflector. The ID of the route reflector is the Cluster_ID. You can configure more than one route reflector in a cluster to improve availability, as shown in Figure 9. The configured route reflectors must have the same Cluster_ID to avoid routing loops.

Figure 9 Network diagram for route reflectors

‌

When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it consumes more bandwidth resources. You can use commands to disable route reflection instead of modifying network configuration or changing network topology.

After route reflection is disabled between clients, routes can still be reflected between a client and a non-client.

Confederation

Confederation is another method to manage growing IBGP connections in an AS. It splits an AS into multiple sub-ASs. In each sub-AS, IBGP peers are fully meshed. As shown in Figure 10, intra-confederation EBGP connections are established between sub-ASs in AS 200.

Figure 10 Confederation network diagram

‌

A non-confederation BGP speaker does not need to know sub-ASs in the confederation. To the BGP speaker, the confederation is one AS and the confederation ID is the AS number. In the above figure, AS 200 is the confederation ID.

Confederation has a deficiency. When you change an AS into a confederation, you must reconfigure the routers, and the topology will be changed.

In large-scale BGP networks, you can use both route reflector and confederation.

MP-BGP

Supported address families

BGP-4 can only advertise IPv4 unicast routing information. Multiprotocol Extensions for BGP-4 (MP-BGP) can advertise routing information for the following address families:

Only MP-BGP can advertise and maintain IPv6 unicast route prefix information.

MP-BGP extended attributes

Prefixes and next hops are key routing information. BGP-4 uses UPDATE messages to carry the following information:

· Feasible route prefixes in the Network Layer Reachability Information (NLRI) field.

· Unfeasible route prefixes in the withdrawn routes field.

· Next hops in the NEXT_HOP attribute.

BGP-4 cannot carry routing information for multiple network layer protocols.

To support multiple network layer protocols, MP-BGP defines the following path attributes:

· MP_REACH_NLRI—Carries feasible route prefixes and next hops for multiple network layer protocols.

· MP_UNREACH_NLRI—Carries unfeasible route prefixes for multiple network layer protocols.

MP-BGP uses these two attributes to advertise feasible and unfeasible routes for different network layer protocols. BGP speakers not supporting MP-BGP ignore updates containing these attributes and do not forward them to its peers.

Address family

MP-BGP uses address families and subsequent address families to identify different network layer protocols for routes contained in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. For example, an Address Family Identifier (AFI) of 2 and a Subsequent Address Family Identifier (SAFI) of 1 identify IPv6 unicast routing information carried in the MP_REACH_NLRI attribute. For address family values, see RFC 1700.

Exchanging IPv4 and IPv6 routes in both IPv4 and IPv6 address families

MP-BGP supports IPv4 route exchange between IPv6 peers and IPv6 route exchange between IPv4 peers as follows:

· When the next hop of an IPv6 route is an IPv4 address, MP-BGP maps the IPv4 address to an IPv6 address encapsulated in the NEXT_HOP attribute of update messages. In this scenario, you must specify a routing policy to change the next hop of the IPv6 route to the IPv6 address of the peer.

· When the next hop of an IPv4 route is an IPv6 address, BGP negotiates the extended next hop encoding capability with its peer. Then, BGP encapsulates the IPv4 NLRI in the MP_REACH_NLRI attribute of update messages. In this scenario, you must specify a routing policy to change the next hop of the IPv4 route to the IPv4 address of the peer.

Figure 11 Exchanging IPv4 and IPv6 routes in both IPv4 and IPv6 address families

‌

As shown in Figure 11, an IPv6 BGP peer relationship is established between Device A and Device B, between Device B and Device C, and between Device C and Device D. An IPv4 BGP peer relationship is established between Device A and Device B and between Device C and Device D. Device A and Device D can learn both IPv4 and IPv6 routes from each other and traffic is forwarded correctly in both IPv4 and IPv6 address families. For Device C to correctly receive IPv4 routes using the IPv6 address of Device B as the next hop, configure a routing policy on Device C. Use the routing policy to change the next hop of these routes to the IPv4 address of Device B.

BGP multi-instance

A BGP router can run multiple BGP processes. Each BGP process corresponds to a BGP instance. BGP maintains an independent routing table for each BGP instance.

BGP configuration views

BGP uses different views to manage routing information for different BGP instances, VPN instances, and address families. Most BGP commands are available in all BGP views. BGP supports multiple VPN instances by establishing a separate routing table for each VPN instance.

Table 1 describes different BGP configuration views.

Table 1 BGP configuration views

View names	Ways to enter the views	Remarks
BGP instance view	<Sysname> system-view [Sysname] bgp 100 instance abc [Sysname-bgp-abc]	You can create a BGP instance and enter its view by specifying the instance keyword in the bgp command. Configurations in this view apply to all public address families for the specified BGP instance. Some configurations (such as confederation, GR, and logging configurations) also apply to the address families of VPN instances.
BGP IPv4 unicast address family view	<Sysname> system-view [Sysname] bgp 100 instance abc [Sysname-bgp-abc] address-family ipv4 unicast [Sysname-bgp-abc-ipv4]	Configurations in this view apply to public IPv4 unicast routes and peers of the specified BGP instance.
BGP IPv6 unicast address family view	<Sysname> system-view [Sysname] bgp 100 instance abc [Sysname-bgp-abc] address-family ipv6 unicast [Sysname-bgp-abc-ipv6]	Configurations in this view apply to public IPv6 unicast routes and peers of the specified BGP instance.
BGP LS address family view	<Sysname> system-view [Sysname] bgp 100 instance abc [Sysname-bgp-abc] address-family link-state [Sysname-bgp-abc-ls]	Configurations in this view apply to LS messages and peers of the specified BGP instance.

‌

Protocols and standards

· RFC 1700, ASSIGNED NUMBERS

· RFC 1997, BGP Communities Attribute

· RFC 2439, BGP Route Flap Damping

· RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

· RFC 2918, Route Refresh Capability for BGP-4

· RFC 4271, A Border Gateway Protocol 4 (BGP-4)

· RFC 4275, BGP-4 MIB Implementation Survey

· RFC 4277, Experience with the BGP-4 Protocol

· RFC 4360, BGP Extended Communities Attribute

· RFC 4451, BGP MULTI_EXIT_DISC (MED) Consideration

· RFC 4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP

· RFC 4486, Subcodes for BGP Cease Notification Message

· RFC 4724, Graceful Restart Mechanism for BGP

· RFC 4760, Multiprotocol Extensions for BGP-4

· RFC 5004, Avoid BGP Best Path Transitions from One External to Another

· RFC 5065, Autonomous System Confederations for BGP

· RFC 5291, Outbound Route Filtering Capability for BGP-4

· RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4

· RFC 5492, Capabilities Advertisement with BGP-4

· RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop

· RFC 5668, 4-Octet AS Specific BGP Extended Community

· RFC 6198, Requirements for the Graceful Shutdown of BGP Sessions

· RFC 6793, BGP Support for Four-Octet Autonomous System (AS) Number Space

· RFC 7752, North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP

· RFC 7911, Advertisement of Multiple Paths in BGP

Building basic BGP networks

Restrictions: Licensing requirements for BGP

You can install a license to increase the maximum number of BGP routes supported by the device, if the default settings are not sufficient. For more information about licensing, see Fundamentals Configuration Guide.

Restrictions and guidelines: BGP configuration

You can create multiple public address families for a BGP instance. However, each public address family (except for public IPv4 unicast and IPv6 unicast address families) can belong to only one BGP instance.

You cannot specify the same peer for the same address family of different BGP instances.

Different BGP instances can have the same AS number but cannot have the same name.

Basic BGP network configuration tasks at a glance (IPv4 unicast)

To build basic BGP networks for the IPv4 unicast address family, perform the following tasks:

1. Configuring basic BGP

a. Enabling BGP

b. Configuring a BGP peer

c. Configuring dynamic BGP peers

d. Configuring an IBGP peer group

Configure BGP peer groups on large-scale BGP networks for easy configuration and maintenance.

e. Configuring an EBGP peer group

Configure BGP peer groups on large-scale BGP networks for easy configuration and maintenance.

f. (Optional.) Specifying the source address of TCP connections

2. Controlling BGP route generation

Choose the following tasks as needed:

¡ Injecting a local network

¡ Redistributing IGP routes

¡ (Optional.) Configuring BGP route summarization

¡ (Optional.) Advertising a default route to a peer or peer group

3. (Optional.) Controlling BGP route advertisement

¡ Advertising optimal routes in the IP routing table

¡ Enabling prioritized withdrawal of the default route

¡ Enabling prioritized withdrawal of specific routes

¡ Configuring BGP route distribution filtering policies

¡ Enabling first-AS-number check for EBGP routes before route advertisement

¡ Setting the BGP route sending rate

¡ Configuring BGP to delay sending route updates on reboot

¡ Control the frequency of sending the same route update

¡ Applying route update interval setting to withdrawn routes

¡ Configuring BGP route advertisement delay

¡ Configuring a startup policy for BGP route updates

¡ Setting the send buffer size for BGP sessions

4. (Optional.) Configuring the BGP update message sending parameters

5. (Optional.) Controlling BGP route reception

¡ Limiting routes received from a peer or peer group

¡ Configuring BGP route reception filtering policies

¡ Configuring the SoO attribute

¡ Configuring the link bandwidth attribute

6. (Optional.) Configuring BGP timers

¡ Configuring the keepalive interval and hold time

¡ Setting the session retry timer

7. (Optional.) Configuring BGP logging and notifications

¡ Enabling logging for session state changes

¡ Enabling logging for BGP route flapping

¡ Configuring BGP network management

Basic BGP network configuration tasks at a glance (IPv6 unicast)

To build basic BGP networks for the IPv6 unicast address family, perform the following tasks:

1. Configuring basic BGP

a. Enabling BGP

b. Configuring a BGP peer

c. Configuring dynamic BGP peers

d. Configuring an IBGP peer group

Configure BGP peer groups on large-scale BGP networks for easy configuration and maintenance.

e. Configuring an EBGP peer group

Configure BGP peer groups on large-scale BGP networks for easy configuration and maintenance.

f. (Optional.) Specifying the source address of TCP connections

2. Controlling BGP route generation

Choose the following tasks as needed:

¡ Injecting a local network

¡ Redistributing IGP routes

¡ (Optional.) Configuring BGP route summarization

¡ (Optional.) Advertising a default route to a peer or peer group

3. (Optional.) Controlling BGP route advertisement

¡ Advertising optimal routes in the IP routing table

¡ Enabling prioritized withdrawal of the default route

¡ Enabling prioritized withdrawal of specific routes

¡ Configuring BGP route distribution filtering policies

¡ Enabling first-AS-number check for EBGP routes before route advertisement

¡ Setting the BGP route sending rate

¡ Configuring BGP to delay sending route updates on reboot

¡ Control the frequency of sending the same route update

¡ Applying route update interval setting to withdrawn routes

¡ Configuring BGP route advertisement delay

¡ Configuring a startup policy for BGP route updates

¡ Setting the send buffer size for BGP sessions

4. Configuring the BGP update message sending parameters

5. (Optional.) Controlling BGP route reception

¡ Limiting routes received from a peer or peer group

¡ Configuring BGP route reception filtering policies

¡ Configuring the SoO attribute

¡ Configuring the link bandwidth attribute

6. (Optional.) Configuring BGP timers

¡ Configuring the keepalive interval and hold time

¡ Setting the session retry timer

7. (Optional.) Configuring BGP logging and notifications

¡ Enabling logging for session state changes

¡ Enabling logging for BGP route flapping

¡ Configuring BGP network management

Configuring basic BGP

Enabling BGP

Restrictions and guidelines

A router ID is the unique identifier of a BGP router in an AS.

· To ensure the uniqueness of a router ID and enhance availability, specify in BGP instance view the IP address of a local loopback interface as the router ID. Different BGP instances can have the same router ID.

· If no router ID is specified in BGP instance view, the global router ID is used.

· To modify a non-zero router ID of a BGP instance , use the router-id command in BGP instance view, rather than the router id command in system view.

· If you specify a router ID in BGP instance view and then remove the interface that owns the router ID, the router does not select a new router ID. To select a new router ID, use the undo router-id command in BGP instance view.

Procedure

1. Enter system view.

system-view

2. Configure a global router ID.

router id router-id

By default, no global router ID is configured.

If no global router ID is configured, the following rules apply:

¡ If loopback interfaces configured with an IP address exist, BGP uses the highest loopback interface IP address as the router ID.

¡ If no loopback interface IP address is available, BGP uses the highest physical interface IP address as the route ID regardless of the interface status.

3. Enable BGP and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is disabled and no BGP instances exist.

4. (Optional.) Configure a router ID for the BGP instance.

router-id router-id

By default, no router ID is configured for a BGP instance, and the BGP instance uses the global router ID configured by the router-id command in system view.

Configuring a BGP peer

Restrictions and guidelines

A BGP peer at an IPv6 link-local address must be directly connected to the local router. On the local router, you must use the peer connect-interface command to specify the interface directly connected to the BGP peer as the source interface of TCP connections.

To exchange IPv4 routes with an IPv6 peer or exchange IPv6 routes with an IPv4 peer, you must configure a routing policy to perform the following tasks:

· Change the next hop of IPv4 routes received from the IPv6 peer to the IPv4 address of the interface that the peer uses to connect to the local router.

· Change the next hop of IPv6 routes received from the IPv4 peer to the IPv6 address of the interface that the peer uses to connect to the local router.

Procedure (Exchanging IPv4 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IPv4 BGP peer and specify its AS number.

peer ipv4-address as-number as-number

4. (Optional.) Configure a description for a peer.

peer ipv4-address description text

By default, no description is configured for a peer.

5. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable the router to exchange IPv4 unicast routing information with the specified peer.

peer ipv4-address enable

By default, the router cannot exchange IPv4 unicast routing information with the peer.

Procedure (Exchanging IPv6 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IPv4 BGP peer and specify its AS number.

peer ipv4-address as-number as-number

4. (Optional.) Configure a description for the peer.

peer ipv4-address description text

By default, no description is configured for a peer.

5. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

6. Enable BGP to exchange IPv6 unicast routing information with the IPv4 peer.

peer ipv4-address enable

By default, BGP cannot exchange IPv6 unicast routing information with an IPv4 peer.

7. Use a routing policy to modify the next hop of routes received from the IPv4 peer.

peer ipv4-address route-policy route-policy-name import

Procedure (Exchanging IPv6 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IPv6 BGP peer and specify its AS number.

peer ipv6-address as-number as-number

4. (Optional.) Configure a description for a peer.

peer ipv6-address description text

By default, no description is configured for a peer.

5. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

6. Enable the router to exchange IPv6 unicast routing information with the specified peer.

peer ipv6-address enable

By default, the router cannot exchange IPv6 unicast routing information with the peer.

Procedure (Exchanging IPv4 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IPv6 BGP peer and specify its AS number.

peer ipv6-address as-number as-number

4. (Optional.) Configure a description for the peer.

peer ipv6-address description text

By default, no description is configured for a peer.

5. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable BGP to exchange IPv4 unicast routing information with the IPv6 peer.

peer ipv6-address enable

By default, BGP cannot exchange IPv4 unicast routing information with an IPv6 peer.

7. Use a routing policy to modify the next hop of routes received from the IPv6 peer.

peer ipv6-address route-policy route-policy-name import

Configuring dynamic BGP peers

About this task

This feature enables BGP to establish dynamic BGP peer relationships with devices in a network. BGP accepts connection requests from the network but it does not initiate connection requests to the network.

After a device in the network initiates a connection request, BGP establishes a dynamic peer relationship with the device.

If multiple BGP peers reside in the same network, you can use this feature to simplify BGP peer configuration.

Restrictions and guidelines

For a remote device to establish a peer relationship with the local device, you must specify the IP address of the local device on the remote device.

To exchange IPv4 routes with an IPv6 peer or exchange IPv6 routes with an IPv4 peer, you must configure a routing policy to perform the following tasks:

· Change the next hop of IPv4 routes received from the IPv6 peer to the IPv4 address of the interface that the peer uses to connect to the local router.

· Change the next hop of IPv6 routes received from the IPv4 peer to the IPv6 address of the interface that the peer uses to connect to the local router.

Procedure (Exchanging IPv4 unicast routes with dynamic IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify devices in a network as dynamic BGP peers and specify an AS number for the peers.

peer ipv4-address mask-length as-number as-number

4. (Optional.) Configure a description for dynamic BGP peers.

peer ipv4-address mask-length description text

By default, no description is configured for dynamic BGP peers.

5. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable BGP to exchange IPv4 unicast routing information with dynamic BGP peers in the specified network.

peer ipv4-address mask-length enable

By default, BGP cannot exchange IPv4 unicast routing information with dynamic BGP peers.

Procedure (Exchanging IPv6 unicast routes with dynamic IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify devices in an IPv4 network as dynamic IPv4 BGP peers and specify an AS number for the peers.

peer ipv4-address mask-length as-number as-number

4. (Optional.) Configure a description for the peer.

peer ipv4-address mask-length description text

By default, no description is configured for dynamic peers.

5. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

6. Enable BGP to exchange IPv6 unicast routing information with the dynamic IPv4 peers.

peer ipv4-address mask-length enable

By default, BGP cannot exchange IPv6 unicast routing information with dynamic IPv4 peers.

7. Use a routing policy to modify the next hop of routes received from the dynamic IPv4 peers.

peer ipv4-address mask-length route-policy route-policy-name import

Procedure (Exchanging IPv6 unicast routes with dynamic IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify devices in a network as dynamic BGP peers and specify an AS number for the peers.

peer ipv6-address prefix-length as-number as-number

4. (Optional.) Configure a description for dynamic BGP peers.

peer ipv6-address prefix-length description text

By default, no description is configured for dynamic BGP peers.

5. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

6. Enable BGP to exchange IPv6 unicast routing information with dynamic BGP peers in the specified network.

peer ipv6-address prefix-length enable

By default, BGP cannot exchange IPv6 unicast routing information with dynamic BGP peers.

Procedure (Exchanging IPv4 unicast routes with dynamic IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify devices in an IPv6 network as dynamic IPv6 BGP peers and specify an AS number for the peers.

peer ipv6-address prefix-length as-number as-number

4. (Optional.) Configure a description for the dynamic IPv6 peers.

peer ipv6-address prefix-length description text

By default, no description is configured for dynamic peers.

5. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable BGP to exchange IPv4 unicast routing information with dynamic IPv6 peers.

peer ipv6-address prefix-length enable

By default, BGP cannot exchange IPv4 unicast routing information with dynamic IPv6 peers.

7. Use a routing policy to modify the next hop of routes received from the dynamic IPv6 peers.

peer ipv6-address mask-length route-policy route-policy-name import

Configuring an IBGP peer group

About this task

A peer group is an IBGP peer group if peers in it belong to the same AS as the local router.

After you create an IBGP peer group and then add a peer into it, the system creates the peer in BGP instance view and specifies the local AS number for the peer.

Restrictions and guidelines

To exchange IPv4 routes with an IPv6 peer or exchange IPv6 routes with an IPv4 peer, you must configure a routing policy to perform the following tasks:

· Change the next hop of IPv4 routes received from the IPv6 peer to the IPv4 address of the interface that the peer uses to connect to the local router.

· Change the next hop of IPv6 routes received from the IPv4 peer to the IPv6 address of the interface that the peer uses to connect to the local router.

If you configure a BGP setting at both the peer group and the peer level, the most recent configuration takes effect on the peer.

Procedure (Exchanging IPv4 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IBGP peer group.

group group-name [ internal ]

4. Add a peer into the IBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the local AS number.

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

6. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

7. Enable the router to exchange IPv4 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv4 unicast routing information with the peers.

Procedure (Exchanging IPv6 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IBGP peer group.

group group-name [ internal ]

4. Add an IPv4 peer into the IBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the local AS number.

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

6. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

7. Enable BGP to exchange IPv6 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv6 unicast routing information with peers in a peer group.

8. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Procedure (Exchanging IPv6 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IBGP peer group.

group group-name [ internal ]

4. Add a peer into the IBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the local AS number.

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

6. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

7. Enable the router to exchange IPv6 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv6 unicast routing information with the peers.

Procedure (Exchanging IPv4 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an IBGP peer group.

group group-name [ internal ]

4. Add an IPv6 peer into the IBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the local AS number.

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

6. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

7. Enable BGP to exchange IPv4 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv4 unicast routing information with peers in a peer group.

8. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group

About this task

A peer group is an EBGP peer group if peers in it belong to different ASs.

If peers in an EBGP group belong to the same external AS, the EBGP peer group is a pure EBGP peer group. If not, it is a mixed EBGP peer group.

Restrictions and guidelines

Use one of the following methods to configure an EBGP peer group:

· Method 1—Create an EBGP peer group, specify its AS number, and add peers into it. All the added peers have the same AS number. All peers in the peer group have the same AS number as the peer group. You can specify an AS number for a peer before adding it into the peer group. The AS number must be the same as that of the peer group.

· Method 2—Create an EBGP peer group, specify an AS number for a peer, and add the peer into the peer group. Peers added in the group can have different AS numbers.

· Method 3—Create an EBGP peer group and add a peer with an AS number into it. Peers added in the group can have different AS numbers.

To exchange IPv4 routes with an IPv6 peer or exchange IPv6 routes with an IPv4 peer, you must configure a routing policy to perform the following tasks:

· Change the next hop of IPv4 routes received from the IPv6 peer to the IPv4 address of the interface that the peer uses to connect to the local router.

· Change the next hop of IPv6 routes received from the IPv4 peer to the IPv6 address of the interface that the peer uses to connect to the local router.

If you configure a BGP setting at both the peer group and the peer level, the most recent configuration takes effect on the peer.

Configuring an EBGP peer group by using Method 1 (Exchanging IPv4 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Specify the AS number of the group.

peer group-name as-number as-number

By default, no AS number is specified.

If a peer group contains peers, you cannot remove or change its AS number.

5. Add a peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer group-name as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

7. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable the router to exchange IPv4 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv4 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 2 (Exchanging IPv4 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Create an IPv4 BGP peer and specify its AS number.

peer ipv4-address [ mask-length ] as-number as-number

5. Add the peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer ipv4-address [ mask-length ] as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

7. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable the router to exchange IPv4 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv4 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 3 (Exchanging IPv4 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Add a peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name as-number as-number

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

6. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

7. Enable the router to exchange IPv4 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv4 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 1 (Exchanging IPv6 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Specify an AS number for the peer group.

peer group-name as-number as-number

By default, no AS number is specified for a peer group.

If a peer group contains peers, you cannot remove or change its AS number.

5. Add an IPv4 peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer group-name as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

7. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

8. Enable BGP to exchange IPv6 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv6 unicast routing information with peers in a peer group.

9. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group by using Method 2 (Exchanging IPv6 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Create an IPv4 BGP peer and specify its AS number.

peer ipv4-address [ mask-length ] as-number as-number

5. Add the IPv4 peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer ipv4-address [ mask-length ] as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

7. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

8. Enable BGP to exchange IPv6 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv6 unicast routing information with peers in a peer group.

9. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group by using Method 3 (Exchanging IPv6 unicast routes with IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Add an IPv4 peer into the EBGP peer group.

peer ipv4-address [ mask-length ] group group-name as-number as-number

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

6. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

7. Enable BGP to exchange IPv6 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv6 unicast routing information with peers in a peer group.

8. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group by using Method 1 (Exchanging IPv6 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Specify the AS number of the group.

peer group-name as-number as-number

By default, no AS number is specified.

If a peer group contains peers, you cannot remove or change its AS number.

5. Add a peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer group-name as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

7. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

8. Enable the router to exchange IPv6 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv6 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 2 (Exchanging IPv6 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Create an IPv6 BGP peer and specify its AS number.

peer ipv6-address [ prefix-length ] as-number as-number

5. Add the peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer ipv6-address [ prefix-length ] as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

7. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

8. Enable the router to exchange IPv6 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv6 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 3 (Exchanging IPv6 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Add a peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name as-number as-number

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for the peer group.

6. Create the BGP IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

7. Enable the router to exchange IPv6 unicast routing information with peers in the specified peer group.

peer group-name enable

By default, the router cannot exchange IPv6 unicast routing information with the peers.

Configuring an EBGP peer group by using Method 1 (Exchanging IPv4 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Specify an AS number for the peer group.

peer group-name as-number as-number

By default, no AS number is specified for a peer group.

If a peer group contains peers, you cannot remove or change its AS number.

5. Add an IPv6 peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer group-name as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

7. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable BGP to exchange IPv4 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv4 unicast routing information with peers in a peer group.

9. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group by using Method 2 (Exchanging IPv4 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Create an IPv6 BGP peer and specify its AS number.

peer ipv6-address [ prefix-length ] as-number as-number

5. Add the IPv6 peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name [ as-number as-number ]

The as-number as-number option must specify the same AS number as the peer ipv6-address [ prefix-length ] as-number as-number command.

6. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

7. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable BGP to exchange IPv4 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv4 unicast routing information with peers in a peer group.

9. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Configuring an EBGP peer group by using Method 3 (Exchanging IPv4 unicast routes with IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create an EBGP peer group.

group group-name external

4. Add an IPv6 peer into the EBGP peer group.

peer ipv6-address [ prefix-length ] group group-name as-number as-number

5. (Optional.) Configure a description for the peer group.

peer group-name description text

By default, no description is configured for a peer group.

6. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

7. Enable BGP to exchange IPv4 unicast routing information with peers in the peer group.

peer group-name enable

By default, BGP cannot exchange IPv4 unicast routing information with peers in a peer group.

8. Use a routing policy to modify the next hop of routes received from peers in the peer group.

peer group-name route-policy route-policy-name import

Specifying the source address of TCP connections

About this task

BGP uses TCP as the transport layer protocol. Perform this task in the following scenarios to specify the source address or source interface of TCP connections to a peer or peer group:

· The peer's IPv4/IPv6 address does not belong to the interface directly connected to the local router. To ensure successful TCP connection establishment, use one of the following methods:

¡ Specify the interface to which the IPv4/IPv6 address belongs as the source interface on the peer.

¡ Specify the IPv4/IPv6 address of the interface directly connected to the local router as the source address on the peer.

· A BGP peer at an IPv6 link-local address must be directly connected to the local router. On the local router, you must use the peer connect-interface command to specify the interface directly connected to the BGP peer as the source interface of TCP connections.

· On a BGP router that has multiple links to a peer, the source interface for TCP connection changes because the primary source interface fails. To avoid this issue, specify a loopback interface as the source interface or specify the IP address of a loopback interface as the source address.

· You want to establish multiple BGP sessions to a router. In this case, BGP might fail to determine the source address for each TCP connection based on the optimal route to the peer. To prevent this issue, use one of the following methods:

¡ If the BGP sessions use IP addresses of different interfaces, specify a source interface or source address for each session.

¡ If the BGP sessions use different IP addresses of the same interface, specify a source address for each session.

Restrictions and guidelines

BGP immediately tears down the session to an IBGP peer or peer group when the following conditions exist:

· The source interface of TCP connections to the IBGP peer or peer group is a physical interface.

· The source interface fails and the link to the IBGP peer or peer group goes down.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify the source address or source interface of TCP connections to a peer or peer group.

¡ Specify the source address of TCP connections to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } source-address source-ipv4-address

¡ Specify the source interface of TCP connections to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } connect-interface interface-type interface-number

By default, BGP uses the primary IPv4 address of the output interface in the optimal route to a peer or peer group as the source address of TCP connections to the peer or peer group.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify the source IPv6 address or source interface of TCP connections to a peer or peer group.

¡ Specify the source IPv6 address of TCP connections to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } source-address source-ipv6-address

¡ Specify the source interface of TCP connections to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } connect-interface interface-type interface-number

By default, BGP uses the IPv6 address of the output interface in the optimal route to the BGP peer or peer group as the source address of TCP connections to the peer or peer group.

Controlling BGP route generation

Injecting a local network

About this task

Perform this task to inject a network in the local routing table to the BGP routing table, so BGP can advertise the network to BGP peers. The ORIGIN attribute of BGP routes advertised in this way is IGP. You can also use a routing policy to control route advertisement.

The specified network must be available and active in the local IP routing table.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP to advertise a local network.

network ipv4-address [ mask-length | mask ] [ route-policy route-policy-name ]

By default, BGP does not advertise local networks.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure BGP to advertise a local network.

network ipv6-address prefix-length [ route-policy route-policy-name ]

By default, BGP does not advertise local networks.

Redistributing IGP routes

About this task

Perform this task to configure route redistribution from an IGP to BGP.

By default, BGP does not redistribute default IGP routes. You can use the default-route imported command to redistribute default IGP routes into the BGP routing table.

The ORIGIN attribute of BGP routes redistributed from IGPs is INCOMPLETE.

Only active routes can be redistributed. To view route state information, use the display ip routing-table protocol or display ipv6 routing-table protocol command. For more information about the commands, see Layer 3—IP Routing Command Reference.

If you execute the import-route command multiple times for an IGP process, the most recent configuration takes effect. To redistribute more routes from an IGP process without overwriting the routes redistributed before, use the import-route-append command.

When you execute both the import-route and import-route-append commands for an IGP process, the commands take effect as follows:

· A route is redistributed as long as it matches the criteria of either command.

· If a route matches the criteria of both commands, the route is redistributed, and the apply clauses in the routing policies specified in the two commands take effect as follows:

¡ If the apply clauses do not conflict, all apply clauses take effect.

¡ If conflicts occur between the apply clauses, only the apply clauses in the import-route-append command take effect.

· The MED value specified by the import-route-append command takes precedence over that specified by the import-route command.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable route redistribution from the specified IGP into BGP.

¡ Redistribute OSPF routes.

import-route ospf [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

¡ Redistribute direct or static routes.

import-route { direct | static } [ med med-value | route-policy route-policy-name ] *

By default, BGP does not redistribute IGP routes.

5. (Optional.) Redistribute routes from an IGP without overwriting the routes redistributed by the import-route command.

¡ Redistribute OSPF routes.

import-route-append ospf [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

¡ Redistribute direct or static routes.

import-route-append { direct | static } [ med med-value | route-policy route-policy-name ] *

By default, BGP does not redistribute IGP routes.

6. (Optional.) Enable default route redistribution into BGP.

default-route imported

By default, BGP does not redistribute default routes.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable route redistribution from the specified IGP into BGP.

¡ Redistribute OSPFv3 routes.

import-route ospfv3 [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

¡ Redistribute direct or static routes.

import-route { direct | static } [ med med-value | route-policy route-policy-name ] *

By default, BGP does not redistribute IGP routes.

5. (Optional.) Redistribute routes from an IGP without overwriting the routes redistributed by the import-route command.

¡ Redistribute OSPFv3 routes.

import-route-append ospfv3 [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

¡ Redistribute direct or static routes.

import-route-append { direct | static } [ med med-value | route-policy route-policy-name ] *

By default, BGP does not redistribute IGP routes.

6. (Optional.) Enable default route redistribution into BGP.

default-route imported

By default, BGP does not redistribute default routes.

Configuring BGP route summarization

About this task

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Create a summary route in the IPv6 BGP routing table.

aggregate ipv6-address prefix-length [ as-set | attribute-policy route-policy-name | detail-suppressed | origin-policy route-policy-name | suppress-policy route-policy-name ] *

By default, no summary routes are configured.

Advertising a default route to a peer or peer group

About this task

Perform this task to advertise a default BGP route with the next hop being the advertising router to a peer or peer group.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Advertise a default route to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } default-route-advertise [ route-policy route-policy-name ]

By default, no default route is advertised.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Advertise a default route to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } default-route-advertise [ route-policy route-policy-name ]

By default, no default route is advertised.

Controlling BGP route advertisement

Advertising optimal routes in the IP routing table

About this task

By default, BGP advertises optimal routes in the BGP routing table, which may not be optimal in the IP routing table. This task allows you to advertise BGP routes that are optimal in the IP routing table.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP to advertise optimal routes in the IP routing table.

advertise-rib-active

By default, BGP advertises optimal routes in the BGP routing table.

4. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

5. Enable BGP to advertise optimal routes in the IP routing table of the address family in the VPN instance.

advertise-rib-active

By default, the setting is the same as that in BGP instance view.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP to advertise optimal routes in the IPv6 routing table.

advertise-rib-active

By default, BGP advertises optimal routes in the BGP routing table.

4. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

5. Enable BGP to advertise optimal routes in the IPv6 routing table of the address family in the VPN instance.

advertise-rib-active

By default, the setting is the same as that in BGP instance view.

Enabling prioritized withdrawal of the default route

About this task

Typically a BGP router does not send withdrawal messages of the default route prior to other routes to its peers. If the peer relationship is down, the default route cannot be withdrawn first. Traffic interruption might occur. Perform this task to configure BGP to send the withdrawal messages of the default route prior to other routes. This can reduce the traffic interruption time when the peer relationship is down.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP to send withdrawal messages of the default route prior to other routes.

default-route update-first

By default, BGP does not send withdrawal messages of the default route prior to other routes.

Enabling prioritized withdrawal of specific routes

About this task

Perform this task to configure BGP to send the withdrawal messages of specific routes prior to other routes. This can achieve fast route switchover and reduce the traffic interruption time.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable BGP to send withdrawal messages of routes matching the specified routing policy prior to other routes.

update-first route-policy route-policy-name

By default, BGP does not send withdrawal messages of specific routes prior to other routes.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable BGP to send withdrawal messages of routes matching the specified routing policy prior to other routes.

update-first route-policy route-policy-name

By default, BGP does not send withdrawal messages of specific routes prior to other routes.

Configuring BGP route distribution filtering policies

About this task

To configure BGP route distribution filtering policies, use the following methods:

· Use an ACL or prefix list to filter routing information advertised to all peers.

· Use a routing policy, ACL, AS path list, or prefix list to filter routing information advertised to a peer or peer group.

If you configure multiple filtering policies, apply them in the following sequence:

1. filter-policy export

2. peer filter-policy export

3. peer as-path-acl export

4. peer prefix-list export

5. peer route-policy export

Only routes passing all the configured policies can be advertised.

Prerequisites

Before you configure BGP routing filtering policies, configure the following filters used for route filtering as needed:

· ACL (see ACL and QoS Configuration Guide).

· Prefix list (see "Configuring routing policies").

· Routing policy (see "Configuring routing policies").

· AS path list (see "Configuring routing policies").

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP route distribution filtering policies. Choose the options to configure as needed:

¡ Reference an ACL or IP prefix list to filter advertised BGP routes.

filter-policy { ipv4-acl-number | name ipv4-acl-name | prefix-list ipv4-prefix-list-name } export [ direct | { isis | ospf } process-id | static ]

¡ Specify a routing policy as the existent policy to control route advertisement.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-policy advertise-policy-name exist-policy exist-policy-name

This command is available only in BGP IPv4 unicast address family view.

¡ Specify a routing policy as the nonexistent policy to control route advertisement.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-policy advertise-policy-name non-exist-policy non-exist-policy-name

This command is available only in BGP IPv4 unicast address family view.

¡ Reference a routing policy to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name export

¡ Reference an ACL to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } filter-policy ipv4-acl-number export

¡ Reference an AS path list to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } as-path-acl as-path-acl-number export

¡ Reference an IPv4 prefix list to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } prefix-list ipv4-prefix-list-name export

By default, no BGP distribution filtering policy is configured.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure BGP route distribution filtering policies. Choose the options to configure as needed:

¡ Reference an ACL or IPv6 prefix list to filter advertised BGP routes.

filter-policy { ipv6-acl-number | name ipv6-acl-name | prefix-list ipv6-prefix-list-name } export [ direct | { isisv6 | ospfv3 } process-id | static ]

¡ Specify a routing policy as the existent policy to control route advertisement.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-policy advertise-policy-name exist-policy exist-policy-name

This command is available only in BGP IPv6 unicast address family view.

¡ Specify a routing policy as the nonexistent policy to control route advertisement.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-policy advertise-policy-name non-exist-policy non-exist-policy-name

This command is available only in BGP IPv6 unicast address family view.

¡ Reference a routing policy to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name export

¡ Reference an ACL to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } filter-policy ipv6-acl-number export

¡ Reference an AS path list to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } as-path-acl as-path-acl-number export

¡ Reference an IPv6 prefix list to filter BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } prefix-list ipv6-prefix-list-name export

By default, no BGP distribution filtering policy is configured.

Enabling first-AS-number check for EBGP routes before route advertisement

About this task

By default, BGP does not check the first AS number of a received EBGP route and directly advertises it to all peers except the source peer. The default setting for EBGP route advertisement brings about a large number of BGP routes and is not friendly to network maintenance.

To resolve this issue, perform this task. When the first AS number of an EBGP route to be advertised is the same as that of an EBGP peer, BGP does not advertise the route to that peer. This can reduce the number of routes received by EBGP peers.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable BGP to perform first-AS-number check for EBGP routes before route advertisement.

peer-as-check enable

By default, BGP does not check the first AS number of a received EBGP route and directly advertises it to all peers except the source peer.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable BGP to perform first-AS-number check for EBGP routes before route advertisement.

peer-as-check enable

By default, BGP does not check the first AS number of a received EBGP route and directly advertises it to all peers except the source peer.

Setting the BGP route sending rate

About this task

If a device sends many new routes within a short time period, it might be unable to add the routes to the FIB before the peer device adds them. This might result in traffic forwarding failure. To avoid this issue, you can perform this task to set an appropriate route sending rate for the device.

Restrictions and guidelines

If the device performance is high, set a high BGP route sending rate as needed. Otherwise, set a low rate.

To prevent route withdrawal failures when network flapping occurs, avoid setting the rate to 0 or a small value and make sure the rate is high enough for the network.

This task applies only to IPv4 unicast routes and IPv6 unicast routes.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set the BGP route sending rate.

route-rate-limit rate

By default, the BGP route sending rate is not limited.

Configuring BGP to delay sending route updates on reboot

About this task

This task reduces traffic loss. With this task performed, BGP delays sending route updates after the device restarts and the BGP process recovers. During the delay time, BGP learns all routes from other neighbors, and then selects the optimal route. After the delay time elapses, BGP will advertise the optimal route.

You can specify a prefix list and enable BGP to immediately send route updates for routes that match the prefix list.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure BGP to delay sending route updates after the device restarts and the BGP process recovers.

bgp update-delay on-startup seconds

By default, BGP immediately sends route updates to BGP peers in established state after the device restarts and the BGP process recovers.

4. (Optional.) Enable BGP to immediately send route updates for IPv4 routes that match a prefix list.

bgp update-delay on-startup prefix-list ipv4-prefix-list-name

By default, no prefix list is specified to filter IPv4 routes.

5. (Optional.) Enable BGP to immediately send route updates for IPv6 routes that match a prefix list.

bgp update-delay on-startup ipv6-prefix-list ipv6-prefix-list-name

By default, no prefix list is specified to filter IPv6 routes.

Control the frequency of sending the same route update

About this task

A BGP router sends an UPDATE message to its peers when a route is changed. If the route changes frequently, the BGP router keeps sending updates for the same route, resulting route flapping. This task can reduce the impact of routing flaps by suppressing the frequency of sending the same route update to a peer or peer group.

By default, BGP sends update and withdrawal messages to its peers immediately. To configure the withdrawal message sending interval, you can use this feature.

To control the frequency of sending the same route update, use one of the following methods:

· Configure the interval for sending the same route update.

BGP will send a route update at the specified intervals to a peer or peer group.

· Apply the intelligent timer to control the frequency of sending the same route update.

BGP can flexibly control the interval for sending the same route update to a peer or peer group according to the network condition.

If you apply the intelligent timer, the initial route-update suppression interval takes effect after BGP sends a route update. During the suppression interval, the number of times that BGP can send the same route update to a peer is limited. The length of the next suppression interval depends on the number of route flaps that occur within the current suppression interval as follows:

¡ If the number of route flaps increases, the next suppression interval also shortens.

¡ If the number of route flaps reduces, the next suppression interval is the same as the current suppression interval or shortens.

After the current suppression interval elapses, BGP can resend the route update, and then the next suppression interval takes effect.

For more information about how to calculate the suppression interval and how it works, see the route-update-interval intelligent-timer command in the command reference.

Restrictions and guidelines

The route-update-interval intelligent-timer command takes effect only when you use it together with the peer route-update-interval intelligent-timer command.

BGP compares the timer values specified for a BGP peer by using the route-update-delay command and the peer route-update-interval command. Only the larger timer value takes effect. If you did not execute the peer route-update-interval command, BGP compares the BGP route advertisement delay timer with the default value of the peer route-update-interval command.

Configuring the interval for sending the same route update

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the interval for sending updates for the same route to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-update-interval interval

By default, the interval is 15 seconds for an IBGP peer and 30 seconds for an EBGP peer.

Applying the intelligent timer for route update suppression

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the intelligent timer parameters for route-update suppression interval calculation.

route-update-interval intelligent-timer min-update-interval [ max-update-interval [ ignore-delay-count [ incremental-interval ] ] ]

By default, the following intelligent timer settings take effect:

¡ The maximum update suppression interval is 30 seconds.

¡ The minimum update suppression interval is 5 seconds.

¡ BGP can send the same route update to peers three times in a suppression interval.

¡ The penalty increment interval is 1 second.

4. Apply the intelligent timer to suppress the frequency of sending the same update.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-update-interval intelligent-timer

By default, the interval for sending the same update to an IBGP peer is 15 seconds and the interval for sending the same update to an EBGP peer is 30 seconds.

Applying route update interval setting to withdrawn routes

About this task

By default, for a route to be withdrawn, a BGP router immediately sends a withdrawal message to its peers. If the route changes frequently, the BGP router sends many updates for the route, resulting in routing flaps. To avoid this issue, use this feature to apply the route update interval configured in the peer route-update-interval command to withdrawn routes. BGP will send withdrawn and update messages at the specified intervals.

Restrictions and guidelines

This feature does not take effect on routes that exist before the feature is configured.

Procedure

1. Enter BGP instance view.

bgp as-number [ instance instance-name ]

2. Apply route update interval setting to withdrawn routes.

route-update-interval withdrawn enable

By default, route update interval setting does not apply to withdrawn routes. BGP sends withdrawal messages for withdrawn routes immediately.

Configuring BGP route advertisement delay

About this task

BGP sends update messages to peers when route changes occur or peer relationship establishment is complete. If a large number of routes need to be updated within a short time period, BGP might send update messages to peers before issuing the updated routes to the FIB. As a result, some packets might be discarded because BGP cannot find the forwarding path for the packets.

To resolve this issue, perform this task to enable BGP route advertisement delay and set a delay timer. When route changes occur or peer relationship establishment is complete, BGP cannot send any update messages unless the delay timer expires.

Restrictions and guidelines

This feature applies to BGP IPv4 unicast routes, BGP IPv6 unicast routes, BGP VPNv4 routes, and BGP VPNv6 routes.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP route advertisement delay and set a delay timer.

route-update-delay delay-value

By default, BGP route advertisement delay is disabled.

Configuring a startup policy for BGP route updates

About this task

Perform this task to configure BGP to send route updates with the specified attributes within the specified period after reboot.

As shown in Figure 12, if Router B restarts and sends route updates before route convergence completes, traffic sent from Router A through Router B might be lost. This feature enables Router B to send route updates with the specified attribute values within the specified period after reboot, so that Router A can forward traffic through Router C.

Figure 12 Network diagram

‌

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify the period after reboot within which the startup policy is effective.

bgp apply-policy on-startup duration seconds

By default, the startup policy does not take effect.

4. Specify a MED attribute value in the startup policy.

bgp policy on-startup med med-value

By default, the MED attribute value in the startup policy is 4294967295.

Setting the send buffer size for BGP sessions

About this task

A small send buffer size might cause a long convergence time when there are a large number of update messages to send. Execute this command to set an appropriate send buffer size to improve the convergence performance.

Restrictions and guidelines

This feature takes effect only on BGP sessions established or re-established after the feature is configured.

You can perform this task for all BGP peers or for a specific BGP peer or peer group. For a BGP peer or peer group, the configuration of the peer send-buffer-size command takes precedence over that of the send-buffer-size command. If you do not configure the peer send-buffer-size command for the peer or peer group, the configuration of the send-buffer-size command takes effect on the peer or peer group.

Procedure (global configuration)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set the send buffer size for BGP sessions.

send-buffer-size size

By default, the send buffer size is 32768 bytes.

Procedure (Configuration for a peer or peer group)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set the send buffer size for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } send-buffer-size size

By default, the send buffer size for a peer or peer group is not set. The send buffer size configured by the send-buffer-size command applies.

The configuration of this command takes precedence over that of the send-buffer-size command.

Configuring the BGP update message sending parameters

About this task

A BGP speaker uses update messages to advertise route updates to peers. Perform this task to prevent the device from sending a large number of update messages in a short time period, which saves system resources and improves the network convergence performance.

The BGP update message sending parameters are determined by the following configuration:

· Update message sending interval and the maximum number of update messages that can be sent each time.

· Update message send queue parameters.

Restrictions and guidelines

This feature takes effect only on BGP sessions established or re-established after the feature is configured.

Setting the update interval and the maximum number of update messages that can be sent each time

About this task

By default, the number of routes that a router can receive from a peer or peer group is not limited.

Configuring BGP route reception filtering policies

About this task

You can use the following methods to configure BGP route reception filtering policies:

· Use an ACL or prefix list to filter routing information received from all peers.

· Use a routing policy, ACL, AS path list, or prefix list to filter routing information received from a peer or peer group.

If you configure multiple filtering policies, apply them in the following sequence:

1. filter-policy import

2. peer filter-policy import

3. peer as-path-acl import

4. peer prefix-list import

5. peer route-policy import

Only routes passing all the configured policies can be received.

Prerequisites

Before you configure BGP route reception filtering policies, configure the following filters used for route filtering as needed:

· ACL (see ACL and QoS Configuration Guide).

· Prefix list (see "Configuring routing policies").

· Routing policy (see "Configuring routing policies").

· AS path list (see "Configuring routing policies").

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP route reception filtering policies. Choose the options to configure as needed:

¡ Reference an ACL or IP prefix list to filter BGP routes received from all peers.

filter-policy { ipv4-acl-number | name ipv4-acl-name | prefix-list ipv4-prefix-list-name } import

¡ Reference a routing policy to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name import

¡ Reference an ACL to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } filter-policy ipv4-acl-number import

¡ Reference an AS path list to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } as-path-acl as-path-acl-number import

¡ Reference an IPv4 prefix list to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } prefix-list ipv4-prefix-list-name import

By default, no route reception filtering is configured.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure BGP route reception filtering policies. Choose the options to configure as needed:

¡ Reference ACL or IPv6 prefix list to filter BGP routes received from all peers.

filter-policy { ipv6-acl-number | name ipv6-acl-name | prefix-list ipv6-prefix-list-name } import

¡ Reference a routing policy to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name import

¡ Reference an ACL to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } filter-policy ipv6-acl-number import

¡ Reference an AS path list to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } as-path-acl as-path-acl-number import

¡ Reference an IPv6 prefix list to filter BGP routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } prefix-list ipv6-prefix-list-name import

By default, no route reception filtering is configured.

Configuring the SoO attribute

About this task

After you configure the SoO attribute for a BGP peer or peer group, BGP adds the SoO attribute into the route updates received from the BGP peer or peer group. In addition, before advertising route updates to the peer or peer group, BGP checks the SoO attribute of the route update against the configured SoO attribute. If they are the same, BGP does not advertise the route updates to the BGP peer or peer group.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure the SoO attribute for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } soo site-of-origin

By default, no SoO attribute is configured for a peer or peer group.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure the SoO attribute for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } soo site-of-origin

By default, no SoO attribute is configured for a peer or peer group.

Configuring the link bandwidth attribute

About this task

Perform this task to add the link bandwidth attribute to routes received from a directly connected EBGP peer or peer group. The link bandwidth is the bandwidth of the interface directly connected to the EBGP peer or peer group. After BGP advertises the routes received from the EBGP peer or peer group to other IBGP peers, the IBGP peers can filter routes based on the link bandwidth attribute.

Restrictions and guidelines

This feature is applicable only to directly connected EBGP peers and peer groups.

If a directly connected EBGP peer or peer group changes to an indirectly connected one, BGP stops adding the link bandwidth attribute to routes received from the EBGP peer or peer group.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable BGP to add the link bandwidth attribute to routes received from an EBGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } bandwidth

By default, BGP does not add the link bandwidth attribute to routes received from an EBGP peer or peer group.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable BGP to add the link bandwidth attribute to routes received from an EBGP peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } bandwidth

By default, BGP does not add the link bandwidth attribute to routes received from an EBGP peer or peer group.

Configuring BGP timers

Configuring the keepalive interval and hold time

About this task

BGP sends KEEPALIVE messages regularly to keep the BGP session between two routers.

If a router receives no KEEPALIVE or UPDATE message from a peer within the hold time, it tears down the session.

You can configure the keepalive interval and hold time globally or for a peer or peer group. The individual settings take precedence over the global settings.

The actual keepalive interval and hold time are determined as follows:

· If the hold time settings on the local and peer routers are different, the smaller setting is used. If the hold time is 0, BGP does not send KEEPALIVE messages to its peers and never tears down the session.

· If the keepalive interval is not 0, the actual keepalive interval is the smaller one between 1/3 of the hold time and the keepalive interval.

Restrictions and guidelines

The hold time must be a minimum of three times the keepalive interval.

You can perform this task for all BGP peers or for a specific BGP peer or peer group. For a BGP peer or peer group, the configuration of the peer timer command takes precedence over that of the timer command. If you do not configure the peer timer command for the peer or peer group, the configuration of the timer command takes effect on the peer or peer group.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the keepalive interval and hold time.

¡ Configure the global keepalive interval and hold time.

timer keepalive keepalive hold holdtime

This command takes effect for new BGP sessions and does not affect existing sessions.

¡ Configure the keepalive interval and hold time for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } timer keepalive keepalive hold holdtime

By default, the keepalive interval is 60 seconds, and hold time is 180 seconds.

The timers configured with the timer and peer timer commands do not take effect until a session is re-established (for example, a session is reset).

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the keepalive interval and hold time.

¡ Configure the global keepalive interval and hold time.

timer keepalive keepalive hold holdtime

This command takes effect for new BGP sessions and does not affect existing sessions.

¡ Configure the keepalive interval and hold time for a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } timer keepalive keepalive hold holdtime

By default, the keepalive interval is 60 seconds, and hold time is 180 seconds.

The timers configured with the timer and peer timer commands do not take effect until a session is re-established (for example, a session is reset).

Setting the session retry timer

About this task

To speed up session establishment to a peer or peer group and route convergence, set a small session retry timer. If the BGP session flaps, you can set a large session retry timer to reduce the impact.

Restrictions and guidelines

The timer set by the peer timer connect-retry command takes precedence over the timer set by the timer connect-retry command.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set the session retry timer. Choose an option to configure as needed:

¡ Set the session retry timer for all peers or peer groups.

timer connect-retry retry-time

¡ Set the session retry timer for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } timer connect-retry retry-time

By default, the session retry timer is 32 seconds for a peer or peer group.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set the session retry timer. Choose an option to configure as needed:

¡ Set the session retry timer for all peers or peer groups.

timer connect-retry retry-time

¡ Set the session retry timer for a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] | link-local-address interface interface-type interface-number } timer connect-retry retry-time

By default, the session retry timer is 32 seconds for a peer or peer group.

Configuring BGP logging and notifications

Enabling logging for session state changes

About this task

Perform this task to enable BGP to log BGP session establishment and disconnection events. To display the log information, use the display bgp peer ipv4 unicast log-info command or the display bgp peer ipv6 unicast log-info command. The logs are sent to the information center. The output rules of the logs (whether to output the logs and where to output) are determined by the information center configuration.

For more information about information center configuration, see Device Management Configuration Guide.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable logging for session state changes globally.

log-peer-change

By default, logging for session state changes is enabled globally.

4. (Optional.) Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

5. Enable logging for session state changes for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } log-change

By default, logging for session state changes is enabled for all peers and peer groups.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable logging for session state changes globally.

log-peer-change

By default, logging for session state changes is enabled globally.

4. (Optional.) Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

5. Enable logging for session state changes for a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } log-change

By default, logging for session state changes is enabled for all peers and peer groups.

Enabling logging for BGP route flapping

About this task

This feature enables BGP to generate logs for BGP route flapping events that trigger log generation. The generated logs are sent to the information center. For the logs to be output correctly, you must also configure information center on the device. For more information about the information center, see Device Management Configuration Guide.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable logging for BGP route flapping.

log-route-flap monitor-time monitor-count [ log-count-limit | route-policy route-policy-name ] *

By default, logging for BGP route flapping is disabled.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable logging for BGP route flapping.

log-route-flap monitor-time monitor-count [ log-count-limit | route-policy route-policy-name ] *

By default, logging for BGP route flapping is disabled.

Configuring BGP network management

About this task

After you enable SNMP notifications for BGP, the device generates a notification when a BGP neighbor state change occurs. The notification includes the neighbor address, the error code and subcode of the most recent error, and the current neighbor state. For BGP notifications to be sent correctly, you must also configure SNMP on the device.

BGP does not know the BGP instance to which a managed MIB node belongs. To resolve this issue, configure different SNMP contexts for different BGP instances.

The device selects a MIB for an SNMP packet according to the context (for SNMPv3) or community name (for SNMPv1/v2c) in the following ways:

· For an SNMPv3 packet:

¡ The device selects the MIB of the default BGP instance if the packet does not carry a context and no SNMP context is configured for the default BGP instance.

¡ The device selects the MIB of a BGP instance if the packet meets the following conditions:

- Carries a context that is configured with the snmp-agent context command in system view.

- Matches the context of the BGP instance.

¡ The device does not process any MIBs in other situations.

· For an SNMPv1/v2c packet:

¡ The device selects the MIB of the default BGP instance if the following conditions are met:

- No community name-to-SNMP context mapping is configured with the snmp-agent community-map command in system view.

- No SNMP context is configured for the default BGP instance.

¡ The device selects the MIB of a BGP instance if the community name is mapped to an SNMP context and the context matches the context of the BGP instance.

¡ The device does not process any MIBs in other situations.

For more information about SNMP contexts and community names, see SNMP configuration in Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for BGP.

snmp-agent trap enable bgp [ instance instance-name ]

By default, SNMP notifications for BGP are enabled.

3. Enter BGP instance view.

bgp as-number [ instance instance-name ]

4. Configure an SNMP context for the BGP instance.

snmp context-name context-name

By default, no SNMP context is configured for the BGP instance.

Verifying and maintaining basic BGP network configuration

Verifying BGP configuration and running status (IPv4 unicast address family)

Perform display tasks in any view.

· Display BGP IPv4 unicast peer group information.

display bgp [ instance instance-name ] group ipv4 [ unicast ] [ group-name group-name ]

· Display information about a peer or peer group in BGP IPv4 unicast address family.

display bgp [ instance instance-name ] peer ipv4 [ unicast ] [ ipv4-address mask-length | { ipv4-address | group-name group-name } log-info | [ ipv4-address ] verbose ]

display bgp [ instance instance-name ] peer ipv4 [ unicast ] [ ipv6-address prefix-length | ipv6-address log-info | [ ipv6-address ] verbose ]

· Display information about routes advertised by the network command and shortcut routes configured by the network short-cut command.

display bgp [ instance instance-name ] network ipv4 [ unicast ]

· Display BGP IPv4 unicast route information.

display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ ipv4-address [ { mask-length | mask } [ longest-match ] ] | ipv4-address [ mask-length | mask ] advertise-info | ipv4-address [ mask-length | mask ] { as-path | cluster-list | community | ext-community } | peer { ipv4-address | ipv6-address } { advertised-routes | received-routes } [ ipv4-address [ mask-length | mask ] | statistics ] | statistics ]

display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] as-path-acl { as-path-acl-number | as-path-acl-name }

display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] community [ community-number&<1-32> | aa:nn&<1-32> ] [ internet | no-advertise | no-export | no-export-subconfed ] [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] community-list { basic-community-list-number | comm-list-name | adv-community-list-number } [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] ext-community [ bandwidth link-bandwidth-value | color color | rt route-target | soo site-of-origin ]&<1-32> [ whole-match ]

· Display information about BGP peer relationship down events.

display bgp [ instance instance-name ] troubleshooting [ event-count ] [ reverse ]

· Display update group information in BGP IPv4 unicast address family.

display bgp [ instance instance-name ] update-group ipv4 [ unicast ] [ ipv4-address | ipv6-address ]

· Display information about all BGP instances.

display bgp instance-info

Verifying BGP configuration and running status (IPv6 unicast address family)

Perform display tasks in any view.

· Display BGP IPv6 unicast peer group information.

display bgp [ instance instance-name ] group ipv6 [ unicast ] [ group-name group-name ]

· Display information about a peer or peer group in BGP IPv6 unicast address family.

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ ipv6-address prefix-length | { ipv6-address | group-name group-name } log-info | [ ipv6-address ] verbose ]

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ ipv4-address mask-length | ipv4-address log-info | [ ipv4-address ] verbose ]

· Display information about routes advertised by the network command and shortcut routes configured by the network short-cut command.

display bgp [ instance instance-name ] network ipv6 [ unicast ]

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ ipv4-address mask-length | ipv4-address log-info | [ ipv4-address ] verbose ]

· Display BGP IPv6 unicast route information.

display bgp [ instance instance-name ] routing-table ipv6 [ unicast ] [ ipv6-address prefix-length [ advertise-info ] | ipv6-address prefix-length { as-path | cluster-list | community | ext-community } | peer { ipv4-address | ipv6-address } { advertised-routes | received-routes } [ ipv6-address prefix-length | statistics ] | statistics ]

display bgp [ instance instance-name ] routing-table ipv6 [ unicast ] [ vpn-instance vpn-instance-name ] as-path-acl { as-path-acl-number | as-path-acl-name }

display bgp [ instance instance-name ] routing-table ipv6 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] community [ community-number&<1-32> | aa:nn&<1-32> ] [ internet | no-advertise | no-export | no-export-subconfed ] [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv6 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] community-list { basic-community-list-number | comm-list-name | adv-community-list-number } [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv6 [ unicast ] [ vpn-instance vpn-instance-name ] [ statistics ] ext-community [ bandwidth link-bandwidth-value | color color | rt route-target | soo site-of-origin ]&<1-32> [ whole-match ]

· Display information about BGP peer relationship down events.

display bgp [ instance instance-name ] troubleshooting [ event-count ] [ reverse ]

· Display BGP IPv6 unicast address family update group information.

display bgp [ instance instance-name ] update-group ipv6 [ unicast ] [ ipv4-address | ipv6-address ]

· Display information about all BGP instances.

display bgp instance-info

Resetting BGP sessions

About this task

A reset operation enables the router to apply a new route selection policy by re-establishing BGP sessions.

Restrictions and guidelines

A reset operation tears down BGP sessions for a short period of time.

Procedure

Perform reset tasks in user view.

· Reset BGP sessions for IPv4 unicast address family.

reset bgp [ instance instance-name ] { as-number | ipv4-address [ mask-length ] | all | external | group group-name | internal } ipv4 [ unicast ]

reset bgp ipv6-address [ mask-length ] ipv4 [ unicast ]

· Reset BGP sessions for IPv6 unicast address family.

reset bgp [ instance instance-name ] { as-number | ipv6-address [ prefix-length ] | all | external | group group-name | internal } ipv6 [ unicast ]

reset bgp ipv4-address [ mask-length ] ipv6 [ unicast ]

· Reset all BGP sessions.

reset bgp [ instance instance-name ] all

Displaying and clearing BGP route flapping statistics

Displaying BGP route flapping statistics

Perform display tasks in any view.

· Display BGP IPv4 unicast route flapping statistics.

display bgp [ instance instance-name ] routing-table flap-info ipv4 [ unicast ] [ ipv4-address [ { mask-length | mask } [ longest-match ] ] | as-path-acl { as-path-acl-number | as-path-acl-name } ]

· Display BGP IPv6 unicast route flapping statistics.

display bgp [ instance instance-name ] routing-table flap-info ipv6 [ unicast ] [ ipv6-address prefix-length | as-path-acl { as-path-acl-number | as-path-acl-name } ]

Clearing BGP route flapping statistics

Perform clear tasks in user view.

· Clear BGP IPv4 unicast route flapping statistics.

reset bgp [ instance instance-name ] flap-info ipv4 [ unicast ] [ ipv4-address [ mask-length | mask ] | as-path-acl { as-path-acl-number | as-path-acl-name } | peer ipv4-address [ mask-length ] ]

· Clear BGP IPv6 unicast route flapping statistics.

reset bgp [ instance instance-name ] flap-info ipv6 [ unicast ] [ ipv6-address prefix-length | as-path-acl { as-path-acl-number | as-path-acl-name } | peer ipv6-address [ prefix-length ] ]

Basic IPv4 BGP network configuration examples

Example: Configuring basic BGP

Network configuration

As shown in Figure 13, all switches run BGP. Run EBGP between Switch A and Switch B, and run IBGP between Switch B and Switch C to allow Switch C to access network 8.1.1.0/24 connected to Switch A.

Figure 13 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure IBGP:

¡ To prevent route flapping caused by port state changes, this example uses loopback interfaces to establish IBGP connections.

¡ Loopback interfaces are virtual interfaces. Therefore, use the peer connect-interface command to specify the loopback interface as the source interface for establishing BGP connections.

¡ Enable OSPF in AS 65009 to ensure that Switch B can communicate with Switch C through loopback interfaces.

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 3.3.3.3 as-number 65009

[SwitchB-bgp-default] peer 3.3.3.3 connect-interface loopback 0

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 3.3.3.3 enable

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

[SwitchB] ospf 1

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0

[SwitchB-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 2.2.2.2 as-number 65009

[SwitchC-bgp-default] peer 2.2.2.2 connect-interface loopback 0

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 2.2.2.2 enable

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

[SwitchC] ospf 1

[SwitchC-ospf-1] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0

[SwitchC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

[SwitchC] display bgp peer ipv4

BGP local router ID : 3.3.3.3

Local AS number : 65009

Total number of peers : 1 Peers in established state : 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

2.2.2.2 65009 2 2 0 0 00:00:13 Established

The output shows that Switch C has established an IBGP peer relationship with Switch B.

3. Configure EBGP:

¡ The EBGP peers, Switch A and Switch B (usually belong to different carriers), are located in different ASs. Typically, their loopback interfaces are not reachable to each other, so directly connected interfaces are used for establishing EBGP sessions.

¡ To enable Switch C to access the network 8.1.1.0/24 connected directly to Switch A, inject network 8.1.1.0/24 to the BGP routing table of Switch A.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 3.1.1.1 as-number 65009

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 3.1.1.1 enable

[SwitchA-bgp-default-ipv4] network 8.1.1.0 24

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp-default] peer 3.1.1.2 as-number 65008

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 3.1.1.2 enable

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Display BGP peer information on Switch B.

[SwitchB] display bgp peer ipv4

BGP local router ID : 2.2.2.2

Local AS number : 65009

Total number of peers : 2 Peers in established state : 2

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

3.3.3.3 65009 4 4 0 0 00:02:49 Established

3.1.1.2 65008 2 2 0 0 00:00:05 Established

The output shows that Switch B has established an IBGP peer relationship with Switch C and an EBGP peer relationship with Switch A.

# Display the BGP routing table on Switch A.

[SwitchA] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* > 8.1.1.0/24 8.1.1.1 0 32768 i

# Display the BGP routing table on Switch B.

[SwitchB] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 8.1.1.0/24 3.1.1.2 0 0 65008i

# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

i 8.1.1.0/24 3.1.1.2 0 100 0 65008i

The outputs show that Switch A has learned no route to AS 65009, and Switch C has learned network 8.1.1.0, but the next hop 3.1.1.2 is unreachable. As a result, the route is invalid.

4. Redistribute direct routes:

Configure BGP to redistribute direct routes on Switch B, so that Switch A can obtain the route to 9.1.1.0/24, and Switch C can obtain the route to 3.1.1.0/24.

# Configure Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] import-route direct

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Display the BGP routing table on Switch A.

[SwitchA] display bgp routing-table ipv4

Total number of routes: 4

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 2.2.2.2/32 3.1.1.1 0 0 65009?

* >e 3.1.1.0/24 3.1.1.1 0 0 65009?

* > 8.1.1.0/24 8.1.1.1 0 32768 i

* >e 9.1.1.0/24 3.1.1.1 0 0 65009?

Two routes, 2.2.2.2/32 and 9.1.1.0/24, have been added in Switch A's routing table.

# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table ipv4

Total number of routes: 4

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 2.2.2.2/32 2.2.2.2 0 100 0 ?

* >i 3.1.1.0/24 2.2.2.2 0 100 0 ?

* >i 8.1.1.0/24 3.1.1.2 0 100 0 65008i

* >i 9.1.1.0/24 2.2.2.2 0 100 0 ?

The output shows that the route 8.1.1.0 becomes valid with the next hop as Switch A.

Verifying the configuration

# Verify that Switch C can ping 8.1.1.1.

[SwitchC] ping 8.1.1.1

Ping 8.1.1.1 (8.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 8.1.1.1: icmp_seq=0 ttl=254 time=10.000 ms

56 bytes from 8.1.1.1: icmp_seq=1 ttl=254 time=4.000 ms

56 bytes from 8.1.1.1: icmp_seq=2 ttl=254 time=4.000 ms

56 bytes from 8.1.1.1: icmp_seq=3 ttl=254 time=3.000 ms

56 bytes from 8.1.1.1: icmp_seq=4 ttl=254 time=3.000 ms

--- Ping statistics for 8.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 3.000/4.800/10.000/2.638 ms

Example: Configuring BGP and IGP route redistribution

Network configuration

As shown in Figure 14, all devices of company A belong to AS 65008, and all devices of company B belong to AS 65009.

Configure BGP and IGP route redistribution to allow Switch A to access network 9.1.2.0/24 in AS 65009, and Switch C to access network 8.1.1.0/24 in AS 65008.

Figure 14 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure OSPF:

Enable OSPF in AS 65009, so Switch B can obtain the route to 9.1.2.0/24.

# Configure Switch B.

<SwitchB> system-view

[SwitchB] ospf 1

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0

[SwitchB-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] ospf 1

[SwitchC-ospf-1] import-route direct

[SwitchC-ospf-1] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

3. Configure the EBGP connection:

Configure the EBGP connection and inject network 8.1.1.0/24 to the BGP routing table of Switch A, so that Switch B can obtain the route to 8.1.1.0/24.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 3.1.1.1 as-number 65009

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 3.1.1.1 enable

[SwitchA-bgp-default-ipv4] network 8.1.1.0 24

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 3.1.1.2 as-number 65008

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 3.1.1.2 enable

4. Configure BGP and IGP route redistribution:

¡ Configure BGP to redistribute routes from OSPF on Switch B, so Switch A can obtain the route to 9.1.2.0/24.

¡ Configure OSPF to redistribute routes from BGP on Switch B, so Switch C can obtain the route to 8.1.1.0/24.

# Configure route redistribution between BGP and OSPF on Switch B.

[SwitchB-bgp-default-ipv4] import-route ospf 1

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

[SwitchB] ospf 1

[SwitchB-ospf-1] import-route bgp

[SwitchB-ospf-1] quit

# Display the BGP routing table on Switch A.

[SwitchA] display bgp routing-table ipv4

Total number of routes: 3

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 3.3.3.3/32 3.1.1.1 1 0 65009?

* > 8.1.1.0/24 8.1.1.1 0 32768 i

* >e 9.1.2.0/24 3.1.1.1 1 0 65009?

# Display the OSPF routing table on Switch C.

[SwitchC] display ospf routing

OSPF Process 1 with Router ID 3.3.3.3

Routing Tables

Routing for Network

Destination Cost Type NextHop AdvRouter Area

9.1.1.0/24 1 Transit 9.1.1.2 3.3.3.3 0.0.0.0

2.2.2.2/32 1 Stub 9.1.1.1 2.2.2.2 0.0.0.0

Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter

8.1.1.0/24 1 Type2 1 9.1.1.1 2.2.2.2

Total Nets: 3

Intra Area: 2 Inter Area: 0 ASE: 1 NSSA: 0

Verifying the configuration

# Use ping for verification.

[SwitchA] ping -a 8.1.1.1 9.1.2.1

Ping 9.1.2.1 (9.1.2.1) from 8.1.1.1: 56 data bytes, press CTRL+C to break

56 bytes from 9.1.2.1: icmp_seq=0 ttl=254 time=10.000 ms

56 bytes from 9.1.2.1: icmp_seq=1 ttl=254 time=12.000 ms

56 bytes from 9.1.2.1: icmp_seq=2 ttl=254 time=2.000 ms

56 bytes from 9.1.2.1: icmp_seq=3 ttl=254 time=7.000 ms

56 bytes from 9.1.2.1: icmp_seq=4 ttl=254 time=9.000 ms

--- Ping statistics for 9.1.2.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 2.000/8.000/12.000/3.406 ms

[SwitchC] ping -a 9.1.2.1 8.1.1.1

Ping 8.1.1.1 (8.1.1.1) from 9.1.2.1: 56 data bytes, press CTRL+C to break

56 bytes from 8.1.1.1: icmp_seq=0 ttl=254 time=9.000 ms

56 bytes from 8.1.1.1: icmp_seq=1 ttl=254 time=4.000 ms

56 bytes from 8.1.1.1: icmp_seq=2 ttl=254 time=3.000 ms

56 bytes from 8.1.1.1: icmp_seq=3 ttl=254 time=3.000 ms

56 bytes from 8.1.1.1: icmp_seq=4 ttl=254 time=3.000 ms

--- Ping statistics for 8.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 3.000/4.400/9.000/2.332 ms

Example: Configuring dynamic BGP peers

Network configuration

As shown in Figure 15, Switch A needs to establish IBGP peer relationships with Switch B, Switch C, and Switch D in network 10.1.0.0/16. Configure dynamic BGP peers to simplify the configuration.

Configure Switch A as the route reflector, and configure Switch B, Switch C, and Switch D as its clients.

Figure 15 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure IBGP peer relationship:

# Configure Switch A to establish dynamic BGP peer relationships with switches in network 10.1.0.0/16.

<SwitchA> system-view

[SwitchA] bgp 200

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 10.1.0.0 16 as-number 200

[SwitchA-bgp-default] address-family ipv4

[SwitchA-bgp-default-ipv4] peer 10.1.0.0 16 enable

# Configure Switch B to establish an IBGP peer relationship with Switch A.

<SwitchB> system-view

[SwitchB] bgp 200

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 10.1.1.1 as-number 200

[SwitchB-bgp-default] address-family ipv4

[SwitchB-bgp-default-ipv4] peer 10.1.1.1 enable

# Configure Switch C to establish an IBGP peer relationship with Switch A.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 10.1.2.1 as-number 200

[SwitchC-bgp-default] address-family ipv4

[SwitchC-bgp-default-ipv4] peer 10.1.2.1 enable

# Configure Switch D to establish an IBGP peer relationship with Switch A.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp-default] router-id 4.4.4.4

[SwitchD-bgp-default] peer 10.1.3.1 as-number 200

[SwitchD-bgp-default] address-family ipv4

[SwitchD-bgp-default-ipv4] peer 10.1.3.1 enable

# Display BGP peer information on Switch A. The output shows that Switch A has established IBGP peer relationships with Switch B, Switch C, and Switch D.

[SwitchA] display bgp peer ipv4

BGP local router ID : 1.1.1.1

Local AS number : 200

Total number of peers : 3 Peers in established state : 3

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

*10.1.1.2 200 7 10 0 0 00:06:09 Established

*10.1.2.2 200 7 10 0 0 00:06:09 Established

*10.1.3.2 200 7 10 0 0 00:06:09 Established

3. Configure Switch A as the route reflector, and configure peers in network 10.1.0.0/16 as its clients.

[SwitchA-bgp-default-ipv4] peer 10.1.0.0 16 reflect-client

4. Configure Switch C to advertise network 9.1.1.0/24.

[SwitchC-bgp-default-ipv4] network 9.1.1.0 24

Verifying the configuration

# Verify that route 9.1.1.0/24 exists in the BGP routing table on Switch A, Switch B, and Switch D. This example uses Switch A.

[SwitchA-bgp-default] display bgp routing-table ipv4

Total Number of Routes: 1

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* i 9.1.1.0/24 10.1.2.2 0 100 0 ?

Example: Configuring BGP route summarization

Network configuration

As shown in Figure 16, run EBGP between Switch C and Switch D, so the internal network and external network can communicate with each other.

· In AS 65106, perform the following configurations so the devices in the internal network can communicate:

¡ Configure static routing between Switch A and Switch B.

¡ Configure OSPF between Switch B and Switch C.

¡ Configure OSPF to redistribute static routes.

· Configure route summarization on Switch C so BGP advertises a summary route instead of advertising routes to the 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 networks to Switch D.

Figure 16 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure static routing between Switch A and Switch B:

# Configure a default route with the next hop 192.168.212.1 on Switch A.

<SwitchA> system-view

[SwitchA] ip route-static 0.0.0.0 0 192.168.212.1

# Configure static routes to 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 with the same next hop 192.168.212.161 on Switch B.

<SwitchB> system-view

[SwitchB] ip route-static 192.168.64.0 24 192.168.212.161

[SwitchB] ip route-static 192.168.74.0 24 192.168.212.161

[SwitchB] ip route-static 192.168.99.0 24 192.168.212.161

3. Configure OSPF between Switch B and Switch C and configure OSPF on Switch B to redistribute static routes:

# Configure OSPF to advertise the local network and enable OSPF to redistribute static routes on Switch B.

[SwitchB] ospf

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 172.17.100.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] import-route static

[SwitchB-ospf-1] quit

# Configure OSPF to advertise the local networks on Switch C.

[SwitchC] ospf

[SwitchC-ospf-1] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 172.17.100.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] network 10.220.2.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

# Display the IP routing table on Switch C.

[SwitchC] display ip routing-table protocol ospf

Summary count : 5

OSPF Routing table Status : <Active>

Summary count : 3

Destination/Mask Proto Pre Cost NextHop Interface

192.168.64.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

192.168.74.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

192.168.99.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

OSPF Routing table Status : <Inactive>

Summary count : 2

Destination/Mask Proto Pre Cost NextHop Interface

10.220.2.0/24 O_INTRA 10 1 10.220.2.16 Vlan200

172.17.100.0/24 O_INTRA 10 1 172.17.100.2 Vlan100

The output shows that Switch C has learned routes to 192.168.64.0/24, 192.168.99.0/24, and 192.168.64.0/18 through OSPF.

4. Configure BGP between Switch C and Switch D and configure BGP on Switch C to redistribute OSPF routes:

# On Switch C, enable BGP, specify Switch D as an EBGP peer, and configure BGP to redistribute OSPF routes.

[SwitchC] bgp 65106

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 10.220.2.217 as-number 64631

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 10.220.2.217 enable

[SwitchC-bgp-default-ipv4] import-route ospf

# Enable BGP, and configure Switch C as an EBGP peer on Switch D.

[SwitchD] bgp 64631

[SwitchD-bgp-default] router-id 4.4.4.4

[SwitchD-bgp-default] peer 10.220.2.16 as-number 65106

[SwitchD-bgp-default] address-family ipv4 unicast

[SwitchD-bgp-default-ipv4] peer 10.220.2.16 enable

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

# Display the IP routing table on Switch D.

[SwitchD] display ip routing-table protocol bgp

Summary count : 3

BGP Routing table Status : <Active>

Summary count : 3

Destination/Mask Proto Pre Cost NextHop Interface

192.168.64.0/24 BGP 255 1 10.220.2.16 Vlan200

192.168.74.0/24 BGP 255 1 10.220.2.16 Vlan200

192.168.99.0/24 BGP 255 1 10.220.2.16 Vlan200

BGP Routing table Status : <Inactive>

Summary count : 0

The output shows that Switch D has learned routes to 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 through BGP.

# Verify that Switch D can ping hosts on networks 192.168.74.0/24, 192.168.99.0/24, and 192.168.64.0/18. (Details not shown.)

5. Configure route summarization on Switch C to summarize 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24 into a single route 192.168.64.0/18, and disable advertisement of specific routes.

[SwitchC-bgp-default-ipv4] aggregate 192.168.64.0 18 detail-suppressed

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

Verifying the configuration

# Display IP routing table on Switch C.

[SwitchC] display ip routing-table | include 192.168

192.168.64.0/18 BGP 130 0 127.0.0.1 NULL0

192.168.64.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

192.168.74.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

192.168.99.0/24 O_ASE2 150 1 172.17.100.1 Vlan100

The output shows that Switch C has a summary route 192.168.64.0/18 with the output interface Null0.

# Display IP routing table on Switch D.

[SwitchD] display ip routing-table protocol bgp

Summary count : 1

BGP Routing table Status : <Active>

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

192.168.64.0/18 BGP 255 0 10.220.2.16 Vlan200

BGP Routing table Status : <Inactive>

Summary count : 0

The output shows that Switch D has only one route 192.168.64.0/18 to AS 65106.

# Verify that Switch D can ping the hosts on networks 192.168.64.0/24, 192.168.74.0/24, and 192.168.99.0/24. (Details not shown.)

Basic IPv6 BGP network configuration examples

Example: Configuring IPv6 BGP basics

Network configuration

As shown in Figure 17, all switches run BGP. Run EBGP between Switch A and Switch B, and run IBGP between Switch B and Switch C to allow Switch C to access network 50::/64 connected to Switch A.

Figure 17 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure IBGP:

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 9::2 as-number 65009

[SwitchB-bgp-default] address-family ipv6

[SwitchB-bgp-default-ipv6] peer 9::2 enable

[SwitchB-bgp-default-ipv6] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 9::1 as-number 65009

[SwitchC-bgp-default] address-family ipv6

[SwitchC-bgp-default-ipv6] peer 9::1 enable

3. Configure EBGP:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 10::1 as-number 65009

[SwitchA-bgp-default] address-family ipv6

[SwitchA-bgp-default-ipv6] peer 10::1 enable

# Configure Switch B.

[SwitchB-bgp-default] peer 10::2 as-number 65008

[SwitchB-bgp-default] address-family ipv6

[SwitchB-bgp-default-ipv6] peer 10::2 enable

4. Inject network routes to the BGP routing table:

# Configure Switch A.

[SwitchA-bgp-default-ipv6] network 10:: 64

[SwitchA-bgp-default-ipv6] network 50:: 64

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

[SwitchB-bgp-default-ipv6] network 10:: 64

[SwitchB-bgp-default-ipv6] network 9:: 64

[SwitchB-bgp-default-ipv6] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

[SwitchC-bgp-default-ipv6] network 9:: 64

[SwitchC-bgp-default-ipv6] quit

[SwitchC-bgp-default] quit

Verifying the configuration

# Display IPv6 BGP peer information on Switch B.

[SwitchB] display bgp peer ipv6

BGP local router ID: 2.2.2.2

Local AS number: 65009

Total number of peers: 2 Peers in established state: 2

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

9::2 65009 41 43 0 1 00:29:00 Established

10::2 65008 38 38 0 2 00:27:20 Established

The output shows that Switch A and Switch B have established an EBGP connection, and Switch B and Switch C have established an IBGP connection.

# Display IPv6 BGP routing table information on Switch A.

[SwitchA] display bgp routing-table ipv6

Total number of routes: 4

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* >e Network : 9:: PrefixLen : 64

NextHop : 10::1 LocPrf :

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: 65009i

* > Network : 10:: PrefixLen : 64

NextHop : :: LocPrf :

PrefVal : 32768 OutLabel : NULL

MED : 0

Path/Ogn: i

* e Network : 10:: PrefixLen : 64

NextHop : 10::1 LocPrf :

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: 65009i

* > Network : 50:: PrefixLen : 64

NextHop : :: LocPrf :

PrefVal : 32768 OutLabel : NULL

MED : 0

Path/Ogn: i

The output shows that Switch A has learned routing information of AS 65009.

# Display IPv6 BGP routing table information on Switch C.

[SwitchC] display bgp routing-table ipv6

Total number of routes: 4

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* > Network : 9:: PrefixLen : 64

NextHop : :: LocPrf :

PrefVal : 32768 OutLabel : NULL

MED : 0

Path/Ogn: i

* i Network : 9:: PrefixLen : 64

NextHop : 9::1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: i

* >i Network : 10:: PrefixLen : 64

NextHop : 9::1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: i

* >i Network : 50:: PrefixLen : 64

NextHop : 10::2 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: 65008i

The output shows that Switch C has learned the route 50::/64.

# Verify that Switch C can ping hosts on network 50::/64. (Details not shown.)

Troubleshooting BGP

State of the connection to a peer cannot become established

Symptom

The display bgp peer ipv4 unicast or display bgp peer ipv6 unicast command output shows that the state of the connection to a peer cannot become established.

Analysis

To become BGP peers, any two routers must establish a TCP connection using port 179 and exchange OPEN messages successfully.

Solution

1. To resolve the issue:

a. Use the display current-configuration command to verify the current configuration, and verify that the peer's AS number is correct.

b. Use the display bgp peer ipv4 unicast or display bgp peer ipv6 unicast command to verify that the peer's IP/IPv6 address is correct.

c. If a loopback interface is used, verify that the loopback interface is specified with the peer connect-interface command.

d. If the peer is a non-direct EBGP peer, verify that the peer ebgp-max-hop command is configured.

e. Verify that a valid route to the peer is available.

f. Use the ping command to verify the connectivity to the peer.

g. Use the display tcp verbose or display ipv6 tcp verbose command to verify the TCP connection.

h. Verify that no ACL rule is applied to disable TCP port 179.

2. If the issue persists, contact H3C Support.

Configuring large-scale BGP networks

Large-scale BGP network configuration tasks at a glance

To configure large-scale BGP networks, perform the following tasks:

· Configuring BGP route dampening

· Configuring BGP communities

· Configuring BGP route reflection

· Configuring BGP confederation settings

¡ Configuring a BGP confederation

¡ (Optional.) Configuring confederation compatibility

Configuring BGP route dampening

About this task

Route dampening enables BGP to not select unstable routes as optimal routes.

Restrictions and guidelines

This feature applies to EBGP routes but not to IBGP routes.

If an EBGP peer goes down after you configure this feature, routes coming from the peer are dampened but not deleted.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP route dampening.

dampening [ half-life-reachable half-life-unreachable reuse suppress ceiling | route-policy route-policy-name ] *

By default, BGP route dampening is not configured.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure IPv6 BGP route dampening.

dampening [ half-life-reachable half-life-unreachable reuse suppress ceiling | route-policy route-policy-name ] *

By default, IPv6 BGP route dampening is not configured.

Configuring BGP communities

About this task

By default, a router does not advertise the COMMUNITY or extended community attribute to its peers or peer groups. When the router receives a route carrying the COMMUNITY or extended community attribute, it removes the attribute before advertising the route to other peers or peer groups.

Perform this task to enable a router to advertise the COMMUNITY or extended community attribute to its peers for route filtering and control. You can also use a routing policy to add or modify the COMMUNITY or extended community attribute for specific routes. For more information about routing policy, see "Configuring routing policies."

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Advertise the COMMUNITY attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-community

By default, the COMMUNITY attribute is not advertised.

5. Advertise the extended community attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-ext-community

By default, the extended community attribute is not advertised.

6. (Optional.) Apply a routing policy to routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name export

By default, no routing policy is applied.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Advertise the COMMUNITY attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-community

By default, the COMMUNITY attribute is not advertised.

5. Advertise the extended community attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-ext-community

By default, the extended community attribute is not advertised.

6. (Optional.) Apply a routing policy to routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-policy route-policy-name export

By default, no routing policy is applied.

Configuring BGP route reflection

Configuring a BGP route reflector

About this task

Perform this task to configure a BGP route reflector and its clients. The route reflector and its clients automatically form a cluster identified by the router ID of the route reflector. The route reflector forwards route updates among its clients.

To improve availability, you can specify multiple route reflectors for a cluster. The route reflectors in the cluster must have the same cluster ID to avoid routing loops.

When a route reflector connects to multiple clusters, you can configure different cluster IDs for different peers or peer groups.

You only need to configure BGP route reflection on the device that acts as a route reflector. Other devices do not need to know the role of the local device in route reflection.

After you configure a device as a route reflector, it advertises routes as follows:

· Advertises routes received from a non-client IBGP peer to all clients.

· Advertises routes received from an IBGP peer that acts as a client to all peers.

· Advertises routes received from an EBGP peer to all peers.

Restrictions and guidelines

If you do not configure the peer cluster-id command for a peer or peer group, the peer or peer group uses the cluster ID configured by the reflector cluster-id command.

For a peer or peer group, the cluster ID configured by the peer cluster-id command takes precedence over the cluster ID configured by the reflector cluster-id command.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the cluster ID of the route reflector for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } cluster-id cluster-id

By default, the cluster ID of the route reflector is not configured for a peer or peer group.

4. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

5. Configure the router as a route reflector and specify a peer or peer group as its client.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } reflect-client

By default, no route reflector or client is configured.

6. (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

7. (Optional.) Configure the cluster ID of the route reflector.

reflector cluster-id { cluster-id | ipv4-address }

By default, a route reflector uses its own router ID as the cluster ID.

8. (Optional.) Enable the route reflector to change the attributes of routes to be reflected.

reflect change-path-attribute

By default, the route reflector cannot change the attributes of routes to be reflected.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the cluster ID of the route reflector for a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } cluster-id cluster-id

By default, the cluster ID of the route reflector is not configured for a peer or peer group.

4. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

5. Configure the router as a route reflector and specify a peer or peer group as its client.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } reflect-client

By default, no route reflector or client is configured.

6. (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

7. (Optional.) Configure the cluster ID of the route reflector.

reflector cluster-id { cluster-id | ipv4-address }

By default, a route reflector uses its own router ID as the cluster ID.

8. (Optional.) Enable the route reflector to change the attributes of routes to be reflected.

reflect change-path-attribute

By default, the route reflector cannot change the attributes of routes to be reflected.

Ignoring the ORIGINATOR_ID attribute

About this task

By default, BGP drops incoming route updates whose ORIGINATOR_ID attribute is the same as the local router ID. Some special networks such as firewall networks require BGP to accept such route updates. To meet the requirement, you must configure BGP to ignore the ORIGINATOR_ID attribute.

Restrictions and guidelines

Make sure this command does not result in a routing loop.

After you execute this command, BGP also ignores the CLUSTER_LIST attribute.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Ignore the ORIGINATOR_ID attribute.

peer { group-name | ipv4-address [ mask-length ] } ignore-originatorid

By default, BGP does not ignore the ORIGINATOR_ID attribute.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Ignore the ORIGINATOR_ID attribute.

peer { group-name | ipv6-address [ prefix-length ] } ignore-originatorid

By default, BGP does not ignore the ORIGINATOR_ID attribute.

Configuring BGP confederation settings

About BGP confederation

BGP confederation provides another way to reduce IBGP connections in an AS.

A confederation contains sub-ASs. In each sub-AS, IBGP peers are fully meshed. Sub-ASs establish EBGP connections in between.

Configuring a BGP confederation

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure a confederation ID.

confederation id as-number

By default, no confederation ID is configured.

From an outsider's perspective, the sub-ASs of the confederation is a single AS, which is identified by the confederation ID.

4. Specify confederation peer sub-ASs in the confederation.

confederation peer-as as-number-list

By default, no confederation peer sub-ASs are specified.

A confederation can contain a maximum of 32 sub-ASs. The AS number of a sub-AS is effective only in the confederation.

If the router needs to establish EBGP connections to other sub-ASs, you must specify the peering sub-ASs in the confederation.

Configuring confederation compatibility

About this task

If any routers in the confederation do not comply with RFC 3065, enable confederation compatibility to allow the router to work with those routers.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable confederation compatibility.

confederation nonstandard

By default, confederation compatibility is disabled.

Verifying and maintaining large-scale BGP network configuration

Verifying BGP configuration and running status (IPv4 unicast address family)

Perform display tasks in any view.

· Display BGP IPv4 unicast route dampening parameter information.

display bgp [ instance instance-name ] dampening parameter ipv4 [ unicast ]

· Display BGP IPv4 unicast peer group information.

display bgp [ instance instance-name ] group ipv4 [ unicast ] [ group-name group-name ]

· Display information about a peer or peer group in BGP IPv4 unicast address family.

display bgp [ instance instance-name ] peer ipv4 [ unicast ] [ ipv4-address mask-length | { ipv4-address | group-name group-name } log-info | [ ipv4-address ] verbose ]

display bgp [ instance instance-name ] peer ipv4 [ unicast ] [ ipv6-address prefix-length | ipv6-address log-info | [ ipv6-address ] verbose ]

· Display dampened BGP IPv4 unicast route information.

display bgp [ instance instance-name ] routing-table dampened ipv4 [ unicast ]

Verifying BGP configuration and running status (IPv6 unicast address family)

Perform display tasks in any view.

· Display BGP IPv6 unicast route dampening parameter information.

display bgp [ instance instance-name ] dampening parameter ipv6 [ unicast ]

· Display BGP IPv6 unicast peer group information.

display bgp [ instance instance-name ] group ipv6 [ unicast ] [ group-name group-name ]

· Display information about a peer or peer group information in BGP IPv6 unicast address family.

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ ipv6-address prefix-length | { ipv6-address | group-name group-name } log-info | [ ipv6-address ] verbose ]

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ ipv4-address mask-length | ipv4-address log-info | [ ipv4-address ] verbose ]

· Display dampened BGP IPv6 unicast route information.

display bgp [ instance instance-name ] routing-table dampened ipv6 [ unicast ]

Displaying and clearing BGP route flapping statistics

Displaying BGP route flapping statistics

Perform display tasks in any view.

· Display BGP IPv4 unicast route flapping statistics.

display bgp [ instance instance-name ] routing-table flap-info ipv4 [ unicast ] [ ipv4-address [ { mask-length | mask } [ longest-match ] ] | as-path-acl { as-path-acl-number | as-path-acl-name } ]

· Display BGP IPv6 unicast route flapping statistics.

display bgp [ instance instance-name ] routing-table flap-info ipv6 [ unicast ] [ ipv6-address prefix-length | as-path-acl { as-path-acl-number | as-path-acl-name } ]

Clearing BGP route flapping statistics

Perform clear tasks in user view.

· Clear BGP IPv4 unicast route flapping statistics.

reset bgp [ instance instance-name ] flap-info ipv4 [ unicast ] [ ipv4-address [ mask-length | mask ] | as-path-acl { as-path-acl-number | as-path-acl-name } | peer ipv4-address [ mask-length ] ]

· Clear BGP IPv6 unicast route flapping statistics.

reset bgp [ instance instance-name ] flap-info ipv6 [ unicast ] [ ipv6-address prefix-length | as-path-acl { as-path-acl-number | as-path-acl-name } | peer ipv6-address [ prefix-length ] ]

Large-scale BGP network configuration examples

Example: Configuring BGP communities

Network configuration

As shown in Figure 18, Switch B establishes EBGP connections with Switch A and Switch C. Configure NO_EXPORT community attribute on Switch A to make routes from AS 10 not advertised by AS 20 to any other AS.

Figure 18 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure EBGP connections:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 10

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 200.1.2.2 as-number 20

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 200.1.2.2 enable

[SwitchA-bgp-default-ipv4] network 9.1.1.0 255.255.255.0

[SwitchA-bgp-default] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 20

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 200.1.2.1 as-number 10

[SwitchB-bgp-default] peer 200.1.3.2 as-number 30

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 200.1.2.1 enable

[SwitchB-bgp-default-ipv4] peer 200.1.3.2 enable

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 30

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 200.1.3.1 as-number 20

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 200.1.3.1 enable

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

# Display the BGP routing table on Switch B.

[SwitchB] display bgp routing-table ipv4 9.1.1.0

BGP local router ID: 2.2.2.2

Local AS number: 20

Paths: 1 available, 1 best

BGP routing table information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)

Rely nexthop : 200.1.2.1

Original nexthop: 200.1.2.1

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

AS-path : 10

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

VPN-Peer UserID : N/A

DSCP : N/A

EXP : N/A

# Display advertisement information of network 9.1.1.0 on Switch B.

[SwitchB] display bgp routing-table ipv4 9.1.1.0 advertise-info

BGP local router ID: 2.2.2.2

Local AS number: 20

Paths: 1 best

BGP routing table information of 9.1.1.0/24:

Advertised to peers (1 in total):

200.1.3.2

The output shows that Switch B can advertise the route with the destination 9.1.1.0/24 to other ASs through BGP.

# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 9.1.1.0/24 200.1.3.1 0 20 10i

The output shows that Switch C has learned route 9.1.1.0/24 from Switch B.

3. Configure a BGP community:

# Configure a routing policy.

[SwitchA] route-policy comm_policy permit node 0

[SwitchA-route-policy-comm_policy-0] apply community no-export

[SwitchA-route-policy-comm_policy-0] quit

# Apply the routing policy.

[SwitchA] bgp 10

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 200.1.2.2 route-policy comm_policy export

[SwitchA-bgp-default-ipv4] peer 200.1.2.2 advertise-community

Verifying the configuration

# Display the routing table on Switch B.

[SwitchB] display bgp routing-table ipv4 9.1.1.0

BGP local router ID: 2.2.2.2

Local AS number: 20

Paths: 1 available, 1 best

BGP routing table information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)

Rely nexthop : 200.1.2.1

Original nexthop: 200.1.2.1

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

Community : No-Export

AS-path : 10

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

VPN-Peer UserID : N/A

DSCP : N/A

EXP : N/A

# Display advertisement information for the route 9.1.1.0 on Switch B.

[SwitchB] display bgp routing-table ipv4 9.1.1.0 advertise-info

BGP local router ID: 2.2.2.2

Local AS number: 20

Paths: 1 best

BGP routing table information of 9.1.1.0/24:

Not advertised to any peers yet

# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table ipv4

Total number of routes: 0

The output shows that BGP has not learned any route.

Example: Configuring BGP route reflector

Network configuration

As shown in Figure 19, all switches run BGP. Run EBGP between Switch A and Switch B, and run IBGP between Switch C and Switch B, and between Switch C and Switch D.

Configure Switch C as a route reflector with clients Switch B and Switch D to allow Switch D to learn route 20.0.0.0/8 from Switch C.

Figure 19 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces and configure OSPF in AS 200. (Details not shown.)

2. Configure BGP connections:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 192.1.1.2 as-number 200

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 192.1.1.2 enable

# Inject network 20.0.0.0/8 to the BGP routing table.

[SwitchA-bgp-default-ipv4] network 20.0.0.0

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 200

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] peer 192.1.1.1 as-number 100

[SwitchB-bgp-default] peer 193.1.1.1 as-number 200

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 192.1.1.1 enable

[SwitchB-bgp-default-ipv4] peer 193.1.1.1 enable

[SwitchB-bgp-default-ipv4] peer 193.1.1.1 next-hop-local

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 193.1.1.2 as-number 200

[SwitchC-bgp-default] peer 194.1.1.2 as-number 200

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 193.1.1.2 enable

[SwitchC-bgp-default-ipv4] peer 194.1.1.2 enable

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp-default] router-id 4.4.4.4

[SwitchD-bgp-default] peer 194.1.1.1 as-number 200

[SwitchD-bgp-default] address-family ipv4 unicast

[SwitchD-bgp-default-ipv4] peer 194.1.1.1 enable

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

3. Configure Switch C as the route reflector.

[SwitchC] bgp 200

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 193.1.1.2 reflect-client

[SwitchC-bgp-default-ipv4] peer 194.1.1.2 reflect-client

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

Verifying the configuration

# Display the BGP routing table on Switch B.

[SwitchB] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 20.0.0.0/8 192.1.1.1 0 0 100i

# Display the BGP routing table on Switch D.

[SwitchD] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 4.4.4.4

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 20.0.0.0/8 193.1.1.2 0 100 0 100i

The output shows that Switch D has learned route 20.0.0.0/8 from Switch C.

Example: Configuring BGP confederation

Network configuration

As shown in Figure 20, split AS 200 into three sub-ASs (AS 65001, AS 65002, and AS 65003) to reduce IBGP connections. Switches in AS 65001 are fully meshed.

Figure 20 Network diagram

‌

Table 2 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	200.1.1.1/24	Switch D	Vlan-int200	10.1.5.1/24
	Vlan-int200	10.1.1.1/24		Vlan-int400	10.1.3.2/24
	Vlan-int300	10.1.2.1/24	Switch E	Vlan-int200	10.1.5.2/24
	Vlan-int400	10.1.3.1/24		Vlan-int500	10.1.4.2/24
	Vlan-int500	10.1.4.1/24	Switch F	Vlan-int100	200.1.1.2/24
Switch B	Vlan-int200	10.1.1.2/24		Vlan-int600	9.1.1.1/24
Switch C	Vlan-int300	10.1.2.2/24

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure BGP confederation:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65001

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] confederation id 200

[SwitchA-bgp-default] confederation peer-as 65002 65003

[SwitchA-bgp-default] peer 10.1.1.2 as-number 65002

[SwitchA-bgp-default] peer 10.1.2.2 as-number 65003

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 10.1.1.2 enable

[SwitchA-bgp-default-ipv4] peer 10.1.2.2 enable

[SwitchA-bgp-default-ipv4] peer 10.1.1.2 next-hop-local

[SwitchA-bgp-default-ipv4] peer 10.1.2.2 next-hop-local

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65002

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] confederation id 200

[SwitchB-bgp-default] confederation peer-as 65001 65003

[SwitchB-bgp-default] peer 10.1.1.1 as-number 65001

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 10.1.1.1 enable

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65003

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] confederation id 200

[SwitchC-bgp-default] confederation peer-as 65001 65002

[SwitchC-bgp-default] peer 10.1.2.1 as-number 65001

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 10.1.2.1 enable

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

3. Configure IBGP connections in AS 65001:

# Configure Switch A.

[SwitchA] bgp 65001

[SwitchA-bgp-default] peer 10.1.3.2 as-number 65001

[SwitchA-bgp-default] peer 10.1.4.2 as-number 65001

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 10.1.3.2 enable

[SwitchA-bgp-default-ipv4] peer 10.1.4.2 enable

[SwitchA-bgp-default-ipv4] peer 10.1.3.2 next-hop-local

[SwitchA-bgp-default-ipv4] peer 10.1.4.2 next-hop-local

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 65001

[SwitchD-bgp-default] router-id 4.4.4.4

[SwitchD-bgp-default] confederation id 200

[SwitchD-bgp-default] peer 10.1.3.1 as-number 65001

[SwitchD-bgp-default] peer 10.1.5.2 as-number 65001

[SwitchD-bgp-default] address-family ipv4 unicast

[SwitchD-bgp-default-ipv4] peer 10.1.3.1 enable

[SwitchD-bgp-default-ipv4] peer 10.1.5.2 enable

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

# Configure Switch E.

<SwitchE> system-view

[SwitchE] bgp 65001

[SwitchE-bgp-default] router-id 5.5.5.5

[SwitchE-bgp-default] confederation id 200

[SwitchE-bgp-default] peer 10.1.4.1 as-number 65001

[SwitchE-bgp-default] peer 10.1.5.1 as-number 65001

[SwitchE-bgp-default] address-family ipv4 unicast

[SwitchE-bgp-default-ipv4] peer 10.1.4.1 enable

[SwitchE-bgp-default-ipv4] peer 10.1.5.1 enable

[SwitchE-bgp-default-ipv4] quit

[SwitchE-bgp-default] quit

4. Configure the EBGP connection between AS 100 and AS 200:

# Configure Switch A.

[SwitchA] bgp 65001

[SwitchA-bgp-default] peer 200.1.1.2 as-number 100

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 200.1.1.2 enable

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch F.

<SwitchF> system-view

[SwitchF] bgp 100

[SwitchF-bgp-default] router-id 6.6.6.6

[SwitchF-bgp-default] peer 200.1.1.1 as-number 200

[SwitchF-bgp-default] address-family ipv4 unicast

[SwitchF-bgp-default-ipv4] peer 200.1.1.1 enable

[SwitchF-bgp-default-ipv4] network 9.1.1.0 255.255.255.0

[SwitchF-bgp-default-ipv4] quit

[SwitchF-bgp-default] quit

Verifying the configuration

# Display the routing table on Switch B.

[SwitchB] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 9.1.1.0/24 10.1.1.1 0 100 0 (65001)

100i

[SwitchB] display bgp routing-table ipv4 9.1.1.0

BGP local router ID: 2.2.2.2

Local AS number: 65002

Paths: 1 available, 1 best

BGP routing table information of 9.1.1.0/24:

From : 10.1.1.1 (1.1.1.1)

Rely nexthop : 10.1.1.1

Original nexthop: 10.1.1.1

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

AS-path : (65001) 100

Origin : igp

Attribute value : MED 0, localpref 100, pref-val 0, pre 255

State : valid, external-confed, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

VPN-Peer UserID : N/A

DSCP : N/A

EXP : N/A

# Display the BGP routing table on Switch D.

[SwitchD] display bgp routing-table ipv4

Total number of routes: 1

BGP local router ID is 4.4.4.4

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 9.1.1.0/24 10.1.3.1 0 100 0 100i

[SwitchD] display bgp routing-table ipv4 9.1.1.0

BGP local router ID: 4.4.4.4

Local AS number: 65001

Paths: 1 available, 1 best

BGP routing table information of 9.1.1.0/24:

From : 10.1.3.1 (1.1.1.1)

Rely nexthop : 10.1.3.1

Original nexthop: 10.1.3.1

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

AS-path : 100

Origin : igp

Attribute value : MED 0, localpref 100, pref-val 0, pre 255

State : valid, internal-confed, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

VPN-Peer UserID : N/A

DSCP : N/A

EXP : N/A

The output shows the following:

· Switch F can send route information to Switch B and Switch C through the confederation by establishing only an EBGP connection with Switch A.

· Switch B and Switch D are in the same confederation, but belong to different sub-ASs. They obtain external route information from Switch A, and generate identical BGP route entries although they have no direct connection in between.

Controlling BGP path selection

BGP path selection control tasks at a glance

By configuring BGP path attributes, you can control BGP path selection.

To control BGP path selection, perform the following tasks:

1. Configuring preferences for BGP routes

2. Configuring the NEXT_HOP attribute

¡ Setting the local device as the next hop

¡ Disabling nexthop changing for routes advertised to a peer or peer group

¡ Advertising only the global unicast address in the NEXT_HOP attribute

3. Setting a preferred value for received routes

4. Configuring the default local preference

5. Configuring the AS_PATH attribute

¡ Permitting local AS number to appear in routes from a peer or peer group

¡ Ignoring the AS_PATH attribute during optimal route selection

¡ Advertising a fake AS number to a peer or peer group

¡ Configuring AS number substitution

¡ Removing/replacing private AS numbers in BGP updates

¡ Ignoring the first AS number of EBGP route updates

¡ Setting an AS number quantity threshold

6. Configuring the MED attribute

¡ Configuring the default MED value

¡ Enabling MED comparison for routes from different ASs

¡ Enabling MED comparison for routes on a per-AS basis

¡ Enabling MED comparison for routes from confederation peers

¡ Enabling BGP to use the MED and IGP metric together for optimal route selection

7. Minimizing the priority of BGP routes advertised to peers

¡ Minimizing the priority of BGP routes advertised to peers with a DOWN-to-UP state change

¡ Minimizing the priority of BGP routes advertised to peers after a device reboot

¡ (Optional.) Restoring the priority of advertised BGP routes

8. Configuring the AIGP attribute

9. Ignoring IGP metrics during optimal route selection

10. Ignoring router IDs during optimal route selection

Configuring preferences for BGP routes

About this task

Routing protocols each have a default preference. If they find multiple routes destined for the same network, the route found by the routing protocol with the highest preference is selected as the optimal route.

You can use the preference command to modify preferences for EBGP, IBGP, and local BGP routes, or use a routing policy to set a preference for matching routes. For routes not matching the routing policy, the default preference applies.

If a device has an EBGP route and a local BGP route to reach the same destination, it does not select the EBGP route because the EBGP route has a lower preference than the local BGP route by default. You can use the network short-cut command to configure the EBGP route as a shortcut route that has the same preference as the local BGP route. The EBGP route will more likely become the optimal route.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure preferences for EBGP, IBGP, and local BGP routes.

preference { external-preference internal-preference local-preference | route-policy route-policy-name }

By default, the preferences for EBGP, IBGP, and local BGP routes are 255, 255, and 130, respectively.

5. (Optional.) Configure an EBGP route as a shortcut route.

network ipv4-address [ mask-length | mask ] short-cut

By default, an EBGP route has a preference of 255.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure preferences for EBGP, IBGP, and local BGP routes.

preference { external-preference internal-preference local-preference | route-policy route-policy-name }

By default, the preferences for EBGP, IBGP, and local BGP routes are 255, 255, and 130, respectively.

5. (Optional.) Configure an EBGP route as a shortcut route.

network ipv6-address prefix-length short-cut

By default, an EBGP route has a preference of 255.

Configuring the NEXT_HOP attribute

Setting the local device as the next hop

About this task

By default, a BGP device does not set itself as the next hop for routes advertised to an IBGP peer or peer group. In some cases, however, you must configure the advertising device as the next hop to ensure that the BGP peer can find the correct next hop.

For example, as shown in Figure 21, Router A and Router B establish an EBGP neighbor relationship, and Router B and Router C establish an IBGP neighbor relationship. If Router C has no route destined for IP address 1.1.1.1/24, you must configure Router B to set itself 3.1.1.1/24 as the next hop for the network 2.1.1.1/24 advertised to Router C.

Figure 21 NEXT_HOP attribute configuration

‌

If a BGP device has two peers on a broadcast network, it does not set itself as the next hop for routes sent to an EBGP peer by default. As shown in Figure 22, Router A and Router B establish an EBGP neighbor relationship, and Router B and Router C establish an IBGP neighbor relationship. They are on the same broadcast network 1.1.1.0/24. When Router B sends EBGP routes to Router A, it does not set itself as the next hop by default. However, you can configure Router B to set it (1.1.1.2/24) as the next hop for routes sent to Router A by using the peer next-hop-local command as needed.

Figure 22 NEXT_HOP attribute configuration

‌

Restrictions and guidelines

If you have configured BGP load balancing, the device sets itself as the next hop for routes sent to an IBGP peer or peer group regardless of whether the peer next-hop-local command is configured.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Specify the device as the next hop for routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } next-hop-local

By default, the device sets itself as the next hop for routes sent to an EBGP peer or peer group. However, it does not set itself as the next hop for routes sent to an IBGP peer or peer group. When the device sends ECMP routes to IBGP peers, it sets the local device IP as the next hop of the optimal route among these routes.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Specify the device as the next hop for routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } next-hop-local

Disabling nexthop changing for routes advertised to a peer or peer group

About this task

T his feature disables the device from changing the NEXT_HOP attribute of routes advertised to peers. It is applicable to the networks where the advertisement of default routes hampers that of other routes.

For example, on a multi-AS network, configure this feature for a device to disable it from changing the NEXT_HOP attribute of routes advertised to a peer or peer group in a different AS. As shown in Figure 23, PE1 and PE2 are located in different ASs. They communicate with each other through the public network and exchange BGP IPv4 and IPv6 routes. To ensure service scheduling, the next hop of routes on PE1 must be PE2 and the next hop of routes on PE2 must be PE1.

Both PE1 and PE2 have established an EBGP relationship with PE3 and PE4 respectively on the backbone network to exchange routes with each other. On the receipt of routes from PE1, PE3 will forward the routes to PE4. Then, PE4 will change the next hop of the routes before forwarding them to PE2. As a result, the next hop of the routes received by PE2 is not PE1. To resolve this issue, you can use the peer next-hop-invariable command to disable PE4 from changing the next hop of routes.

Figure 23 Multi-AS network

‌

Restrictions and guidelines

To ensure that d irectly-connected EBGP peers can receive routes from the device, be cautious when you configure this feature for these peers on the device. A directly-connected EBGP peers does not receive any route whose next hop is not in the same subnet as that of the peer.

To change the NEXT_HOP attribute of routes after configuring this feature, you can configure a BGP route distribution policy that includes a routing policy.

When the device advertises the redistributed routes to IBGP peers, it changes the NEXT_HOP attribute of these routes regardless of the configuration of this feature.

The following commands are mutually exclusive when you execute them for the same peer or peer group:

· peer next-hop-local

· peer next-hop-invariable

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Disable the device from changing the NEXT_HOP attribute of routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } next-hop-invariable

By default, the device sets its IP address as the next hop for all routes advertised to an EBGP peer or peer group. It does not set its IP address as the next hop for routes advertised to an IBGP peer or peer group. When the device sends ECMP routes to IBGP peers, it sets its IP address as the next hop of the optimal route among these routes.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Disable the device from changing the NEXT_HOP attribute of routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } next-hop-invariable

Advertising only the global unicast address in the NEXT_HOP attribute

About this task

An IPv6 peer might fail to learn routes if it cannot parse a route update that contains both the link-local address and the global unicast address. To resolve this issue, perform this task to enable the local device to advertise only the global unicast address in the NEXT_HOP attribute to its IPv6 peers.

Restrictions and guidelines

This feature might not apply to EBGP peers established through directly connected broadcast interfaces. If the next hop of the advertised route and the directly connected broadcast interfaces belong to the same subnet, this feature does not take effect.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable the device to advertise only the global unicast address in the NEXT_HOP attribute to its IPv6 peers.

nexthop global-address-only

By default, the local device with a link-local address advertises both the link-local address and the global unicast address in the NEXT_HOP attribute to IPv6 BGP peers.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable the device to advertise only the global unicast address in the NEXT_HOP attribute to its IPv6 peers.

nexthop global-address-only

By default, the local device with a link-local address advertises both the link-local address and the global unicast address in the NEXT_HOP attribute to IPv6 BGP peers.

Setting a preferred value for received routes

About this task

Perform this task to set a preferred value for specific routes to control BGP path selection.

Among multiple routes that have the same destination/mask and are learned from different peers, the one with the greatest preferred value is selected as the optimal route.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Set a preferred value for routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } preferred-value value

By default, the preferred value is 0 for routes received from a peer or peer group.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Set a preferred value for routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } preferred-value value

By default, the preferred value is 0 for routes received from a peer or peer group.

Configuring the default local preference

About this task

The local preference is used to determine the optimal route for traffic leaving the local AS. When a BGP router obtains from several IBGP peers multiple routes to the same destination, but with different next hops, it selects the route with the highest local preference as the optimal route.

This task allows you to specify the default local preference for routes sent to IBGP peers.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure the default local preference.

default local-preference value

The default local preference is 100.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure the default local preference.

default local-preference value

The default local preference is 100.

Configuring the AS_PATH attribute

Permitting local AS number to appear in routes from a peer or peer group

By default, BGP includes the AS_PATH attribute in optimal route selection.

Advertising a fake AS number to a peer or peer group

About this task

After you move a BGP router from an AS to another AS (from AS 2 to AS 3 for example), you have to modify the AS number of the router on all its EBGP peers. To avoid such modifications, you can configure the router to advertise a fake AS number 2 to its EBGP peers so that the EBGP peers still think that Router A is in AS 2.

Restrictions and guidelines

This command applies only to EBGP peers or EBGP peer groups.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Advertise a fake AS number to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } fake-as as-number

By default, no fake AS number is advertised to a peer or peer group.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Advertise a fake AS number to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } fake-as as-number

By default, no fake AS number is advertised to a peer or peer group.

Configuring AS number substitution

About this task

To use EBGP between PE and CE in some networks, VPN sites in different geographical areas should have different AS numbers. Otherwise, BGP discards route updates containing the local AS number. If two CEs connected to different PEs use the same AS number, you must configure AS number substitution on each PE. This substitution can replace the AS number in route updates originated by the remote CE as its own AS number before advertising them to the connected CE.

Restrictions and guidelines

Do not configure AS number substitution in normal circumstances. Otherwise, routing loops might occur.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure AS number substitution for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } substitute-as

By default, AS number substitution is not configured.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure AS number substitution for a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } substitute-as

By default, AS number substitution is not configured.

Removing/replacing private AS numbers in BGP updates

About this task

Private AS numbers are typically used in test networks, and should not be transmitted in public networks. The range of private AS numbers is from 64512 to 65535.

You can perform this task to remove or replace private AS numbers with the local AS number in BGP updates as follows:

· When you execute the peer public-as-only command without specifying the force keyword or the limited keyword, the following rules apply:

¡ If the AS_PATH attribute of a BGP update carries only private AS numbers, the device removes the AS numbers before sending the update to the specified peer or peer group.

¡ If the AS_PATH attribute of an update carries both public and private AS numbers, this command does not take effect. BGP directly sends the update to the specified peer or peer group.

¡ If the AS_PATH attribute of an update carries the AS number of the sepcified peer or peer group, this command does not take effect. BGP directly sends the update to the sepcified peer or peer group.

· When you execute the peer public-as-only command with the force keyword specified, this command works as Table 3 shows.

Table 3 Command description

Keyword

Description

replace

Whether this keyword is specified:

· Specified—This command replaces all private AS numbers with the local AS number in the AS_PATH attribute.

· Not specified—This command removes all private AS numbers from the AS_PATH attribute.

include-peer-as

Whether this keyword is specified:

· Specified—This command removes or replaces the AS number of the specified peer or peer group if it is a private AS.

· Not specified—This command does not remove or replace the private AS number of the specified peer or peer group.

‌

· When you execute the peer public-as-only command with the limited keyword specified, this command works as Table 4 shows.

Table 4 Command description

Keyword

Description

replace

Whether this keyword is specified:

· Specified—This command replaces all private AS numbers on the left of the first non-private AS number in the AS_PATH attribute.

· Not specified—This command removes all private AS numbers on the left of the first non-private AS number from the AS_PATH attribute.

include-peer-as

Whether this keyword is specified:

· Specified—This command removes or replaces the private AS number of the specified peer or peer group on the left of the first non-private AS number in the AS_PATH attribute.

· Not specified—This command does not remove or replace the private AS number of the specified peer or peer group.

.‌

Restrictions and guidelines

This feature is applicable only to EBGP peers or peer groups.

Use this feature with caution, because changing the AS_PATH attribute might cause routing loops.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP to remove private AS numbers from the AS_PATH attribute of updates sent to an EBGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } public-as-only [ { force | limited } [ replace ] [ include-peer-as ] ]

By default, BGP updates sent to an EBGP peer or peer group can carry both public and private AS numbers.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure BGP to remove private AS numbers from the AS_PATH attribute of updates sent to an EBGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } public-as-only [ { force | limited } [ replace ] [ include-peer-as ] ]

By default, BGP updates sent to an EBGP peer or peer group can carry both public and private AS numbers.

This command is applicable to only EBGP peers or peer group.

Ignoring the first AS number of EBGP route updates

peer { group-name | ipv6-address [ prefix-length ] } ignore-first-as

By default, BGP checks the first AS number of EBGP-learned route updates.

Setting an AS number quantity threshold

About this task

Perform this task to enable BGP to filter routes based on the quantity of AS numbers contained in the AS_PATH attribute. BGP will discard incoming and outgoing routes, and withdraw routes that have been advertised if they exceed the specified quantity threshold.

Restrictions and guidelines

This feature does not take effect on routes that have been received or on local summary routes.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Set an AS number quantity threshold.

as-path-limit [ as-numbers ]

By default, no AS number quantity threshold is configured.

Configuring the MED attribute

About the MED attribute

BGP uses MED to determine the optimal route for traffic going into an AS. When a BGP router obtains multiple routes with the same destination but with different next hops, it selects the route with the smallest MED value as the optimal route if other conditions are the same.

Configuring the default MED value

Configuring the default MED value (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure the default MED value.

default med med-value

The default MED value is 0.

Configuring the default MED value (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure the default MED value.

default med med-value

The default MED value is 0.

Enabling MED comparison for routes from different ASs

About this task

By default, BGP only compares the MEDs of routes from the same AS. This task enables BGP to compare the MEDs of routes from different ASs.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable MED comparison for routes from different ASs.

compare-different-as-med

By default, MED comparison for routes from different ASs is disabled.

Enabling MED comparison for routes on a per-AS basis

About this task

This task enables BGP to compare the MEDs of routes from an AS.

Figure 24 Route selection based on MED (in an IPv4 network)

‌

As shown in Figure 24, Device D establishes indirect EBGP peer relationships with Device A, Device B, and Device C, and learns addresses 1.1.1.1/32, 2.2.2.2/32, and 3.3.3.3/32 through OSPF. The following output shows the routing information on Device D.

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 O_INTRA 10 10 11.1.1.2 Interface D1

2.2.2.2/32 O_INTRA 10 20 12.1.1.2 Interface D2

3.3.3.3/32 O_INTRA 10 30 13.1.1.2 Interface D3

Device D learns network 10.0.0.0 from both Device A and Device B. Because the route learned from Device B has a smaller IGP metric, the route is optimal. The following output shows the BGP routing table on Device D.

Network NextHop MED LocPrf PrefVal Path/Ogn

*>e 10.0.0.0 2.2.2.2 50 0 300 400e

* e 3.3.3.3 50 0 200 400e

When Device D learns network 10.0.0.0 from Device C, it compares the route with the optimal route in its routing table. Because Device C and Device B reside in different ASs, BGP does not compare the MEDs of the two routes. The route from Device C has a smaller IGP metric than the route from Device B, so the route from Device C becomes optimal. The following output shows the BGP routing table on Device D.

Network NextHop MED LocPrf PrefVal Path/Ogn

*>e 10.0.0.0 1.1.1.1 60 0 200 400e

* e 10.0.0.0 2.2.2.2 50 0 300 400e

* e 3.3.3.3 50 0 200 400e

However, Device C and Device A reside in the same AS, and Device C has a greater MED, so network 10.0.0.0 learned from Device C should not be optimal.

To avoid this issue, you can configure the bestroute compare-med command to enable MED comparison for routes from the same AS on Device D. After that, Device D puts the routes received from each AS into a group, selects the route with the lowest MED from each group, and compares routes from different groups. Network 10.0.0.0 learned from Device B is the optimal route. The following output shows the BGP routing table on Device D.

Network NextHop MED LocPrf PrefVal Path/Ogn

*>e 10.0.0.0 2.2.2.2 50 0 300 400e

* e 3.3.3.3 50 0 200 400e

* e 1.1.1.1 60 0 200 400e

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable MED comparison for routes on a per-AS basis.

bestroute compare-med

By default, MED comparison for routes on a per-AS basis is disabled.

Enabling MED comparison for routes from confederation peers

About this task

This task enables BGP to compare the MEDs of routes received from confederation peers. However, if a route received from a confederation peer has an AS number that does not belong to the confederation, BGP does not compare the route with other routes. For example, a confederation has three AS numbers 65006, 65007, and 65009. BGP receives three routes from different confederation peers. The AS_PATH attributes of these routes are 65006 65009, 65007 65009, and 65008 65009, and the MED values of them are 2, 3, and 1. Because the third route's AS_PATH attribute contains AS number 65008 that does not belong to the confederation, BGP does not compare it with other routes. As a result, the first route becomes the optimal route.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable MED comparison for routes from confederation peers.

bestroute med-confederation

By default, MED comparison for routes from confederation peers is disabled.

Enabling BGP to use the MED and IGP metric together for optimal route selection

About this task

By default, BGP uses the MED value and the IGP metric value separately for optimal route selection. With this command executed, BGP performs the following tasks when it selects the optimal route by MED comparison:

1. Multiply the MED value and IGP metric value for each route by the MED value multiplier and the IGP metric value multiplier, respectively.

2. Calculate the sum of the new MED value and IGP metric value for each route.

3. Select the route with the smallest sum as the optimal route.

BGP cannot use routes with different MED values to implement load balancing. To resolve this issue, set the multipliers as needed to ensure that the sums of the calculated MED and IGP metric values for these routes are the same.

Restrictions and guidelines

If a BGP route has no MED attribute, the MED value for this route is 0.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP to use the MED and IGP metric together for optimal route selection.

bestroute med-plus-igp [ igp-multiplier igp-multiplier | med-multiplier med-multiplier ] *

By default, BGP selects the route with the lowest MED value as the optimal route when it selects the optimal route by MED comparison.

M inimizing the priority of BGP routes advertised to peers

Minimizing the priority of BGP routes advertised to peers with a DOWN-to-UP state change

About this task

By default, the device sends BGP routes immediately to a peer when the peer state changes to UP. If the device advertises routes before completing ARP or ND table convergence, the traffic matching these advertised routes might not be forwarded correctly, which causes traffic loss.

To resolve this issue, use this feature to minimize the priority of the routes to be advertised after the state of a peer changes from DOWN to UP. The peer will not select the routes received from the device as the optimal routes. After the device completes ARP or ND table convergence and the specified wait time elapses, the device restores the priority of the routes advertised to the peer.

After you use this feature, the device performs the following tasks when the state of a peer changes from DOWN to UP:

1. Set the local preference value to the minimum (zero) and the MED value to the maximum (4294967295) for the routes to be advertised.

2. After the specified wait time elapses, restore the local preference value and the MED value for the advertised routes, and then advertise these routes immediately.

For the device to restore the priority of the advertised routes before the specified wait time elapses, use one of the following commands:

¡ reset bgp advertise lowest-priority on-peer-up

After you use this command, the device immediately sends BGP routes with the original local preference value and MED value to the peer. If the state of a peer changes from DOWN to UP later, the device still minimizes the priority of the routes advertised to that peer.

¡ undo advertise lowest-priority on-peer-up duration

After you use this command, the device immediately sends BGP routes with the original local preference value and MED value to the peer. The device does not change the original local preference value and MED value for the subsequent routes advertised to peers.

Restrictions and guidelines

You can use the advertise lowest-priority on-peer-up duration command in BGP instance view or BGP address family view:

· If you use this command in the view of a BGP instance, this command takes effect on all address families in the instance.

· If you use this command in the view of a BGP address family, this command takes effect only on the address family.

· For a BGP address family, the configuration of this command in BGP address family view takes precedence over that in BGP instance view.

You can use this command multiple times to change the wait time. After you change the wait time, the following rules apply:

· If the original wait time setting is taking effect, the new wait time setting will immediately take over and the device will update the time to wait for route priority restoration.

For example, you can set the wait time to 10 seconds by using the advertise lowest-priority on-peer-up duration 10 command. Then, you use the advertise lowest-priority on-peer-up duration 6 command to set a new wait time six seconds after the state of a peer changes from DOWN to UP. The device will still minimize the priority of the routes advertised to the peer during the following six seconds.

· If the original wait time is not taking effect, the new wait time will take effect after the state of a peer changes from DOWN to UP.

The following commands can influence each other:

· advertise lowest-priority on-peer-up duration

· advertise lowest-priority on-startup duration

· bgp update-delay on-startup

· route-update-delay

When you use two of the commands above together, the configuration result varies by command as follows:

Table 5 Configuration results

Command A	Command B	Configuration result
bgp update-delay on-startup	advertise lowest-priority on-startup duration in BGP instance view	Command A and command B overwrite each other. The command used at last takes effect.
	advertise lowest-priority on-peer-up duration in BGP instance view	Provided that the delay time specified in command A is TA and the wait time specified in command B is TB, the two commands take effect as follows after the device restarts and the BGP process recovers: · If TA ≥ TB, only command A takes effect. · If TA < TB, the device performs the following tasks: a. The device does not send any BGP routes to peers within TA. b. After TA elapses, the devi ce sends BGP routes to peers and minimizes the priority of these routes during the remaining time (TB minus TA). c. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to peers. The device does not minimize the priority of the subsequent routes advertised to peers.
	route-update-delay	Both command A and command B take effect after the device restarts and the BGP process recovers. Provided that the delay time specified in command A is TA, the device can advertise BGP routes to a peer only after TA plus TS elapses. TS represents the larger interval among the intervals specified in the peer route-update-interval command and command B. If you did not execute the peer route-update-interval command for the peer, the device uses the default value of this command to compare with the interval configured in command B.
	advertise lowest-priority on-startup duration in the view of a BGP address family	· In the address family configured with command B, only command B takes effect. · In the address families not configured with command B, command A takes effect.
	advertise lowest-priority on-peer-up duration in the view of a BGP address family	Provided that the delay time specified in command A is TA and the wait time specified in command B is TB, the following rules apply: · In the address families not configured with command B, only command A takes effect. · In the address family configured with command B, the two commands take effect as follows after the device restarts and the BGP process recovers: ¡ If TA ≥ TB, only command A takes effect. ¡ If TA < TB, the device performs the following tasks: i. The device does not send any BGP routes to peers within TA. ii. The device sends BGP routes to peers and minimizes the priority of these routes during the remaining time (TB minus TA). iii. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to peers. The device does not minimize the priority of the subsequent routes advertised to peers.
route-update-delay	advertise lowest-priority on-startup duration in BGP instance view	The following description applies to BGP IPv4 unicast address family and BGP IPv6 unicast address family. Provided that the wait time specified in command B is TB, the two commands take effect as follows after the device restarts and the BGP process recovers: · If TS ≥ TB, only command A takes effect. · If TS < TB, the device performs the following tasks: a. The device does not send any BGP routes to peers within TS. b. After TS elapses, the device sends BGP routes to peers and minimizes the priority of these routes during the remaining time (TB minus TS). c. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to peers. The device does not minimize the priority of the subsequent routes advertised to peers. TS represents the larger interval among the intervals specified in the peer route-update-interval command and command A. If you did not execute the peer route-update-interval command for the peers, the device uses the default value of this command to compare with the interval configured in command A.
	advertise lowest-priority on-peer-up duration in BGP instance view	The following description applies to BGP IPv4 unicast address family and BGP IPv6 unicast address family. Provided that the wait time specified in command B is TB, the two commands take effect as follows when the state of a peer changes from DOWN to UP: · If TS ≥ TB, only command A takes effect. · If TS < TB, the device performs the following tasks: a. The device does not send any BGP routes to the peer within TS. b. After TS elapses, the device sends BGP routes to the peer and minimizes the priority of these routes during the remaining time (TB minus TS). c. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to the peer. The device does not minimize the priority of the subsequent routes advertised to the peer. TS represents the larger interval among the intervals specified in the peer route-update-interval command and command A. If you did not execute the peer route-update-interval command for the peer, the device uses the default value of this command to compare with the interval configured in command A.
	advertise lowest-priority on-startup duration in BGP IPv4 unicast address family or BGP IPv6 unicast address family	Provided that the wait time specified in command B is TB, the following rules apply: · In the address families not configured with command B, only command A takes effect. · In the address family configured with command B, the two commands take effect as follows after the device restarts and the BGP process recovers: ¡ If TS ≥ TB, only command A takes effect. ¡ If TS < TB, the device performs the following tasks: i. The device does not send any BGP routes to peers within TS. ii. After TS elapses, the device sends BGP routes to peers and minimizes the priority of these routes during the remaining time (TB minus TS). iii. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to peers. The device does not minimize the priority of the subsequent routes advertised to peers. TS represents the larger interval among the intervals specified in the peer route-update-interval command and command A. If you did not execute the peer route-update-interval command for the peers, the device uses the default value of this command to compare with the interval configured in command A.
	advertise lowest-priority on-peer-up duration in BGP IPv4 unicast address family or BGP IPv6 unicast address family	Provided that the wait time specified in command B is TB, the following rules apply: · In the address families not configured with command B, only command A takes effect. · In the address family configured with command B, the two commands take effect as follows when the state of a peer changes from DOWN to UP: ¡ If TS ≥ TB, only command A takes effect. ¡ If TS < TB, the device performs the following tasks: i. The device does not send any BGP routes to the peer within TS. ii. After TS elapses, the device sends BGP routes to the peer and minimizes the priority of these routes during the remaining time (TB minus TS). iii. After TB elapses, the device restores the priority of the advertised routes, and then immediately sends them to the peer. The device does not minimize the priority of the subsequent routes advertised to the peer. TS represents the larger interval among the intervals specified in the peer route-update-interval command and command A. If you did not execute the peer route-update-interval command for the peer, the device uses the default value of this command to compare with the interval configured in command A.
advertise lowest-priority on-startup duration in BGP instance view	advertise lowest-priority on-peer-up duration in BGP instance view	Command A is mutually exclusive with command B.
	advertise lowest-priority on-peer-up duration in the view of a BGP address family	· In the address family configured with command B, only command B takes effect. · In the address families not configured with command B, only command A takes effect.
advertise lowest-priority on-peer-up duration in BGP instance view	advertise lowest-priority on-startup duration in the view of a BGP address family	· In the address family configured with command B, only command B takes effect. · In the address families not configured with command B, only command A takes effect.
advertise lowest-priority on-peer-up duration in the view of a BGP address family	advertise lowest-priority on-startup duration in the view of a BGP address family	Command A is mutually exclusive with command B in the same address family.

About this task

By default, the device sends BGP routes immediately to peers after the device restarts and the BGP process recovers. If the device advertises routes before completing ARP or ND table convergence, the traffic matching these advertised routes might not be forwarded correctly, which causes traffic loss.

To resolve this issue, use this feature to minimize the priority of the routes to be advertised after the device restarts and the BGP process recovers. Peers will not select the routes received from the device as the optimal routes. After the device completes ARP or ND table convergence and the specified wait time elapses, the device restores the priority of the routes advertised to the peers.

After you use this feature, the device performs the following tasks after the device restarts and the BGP process recovers:

1. Set the local preference value to the minimum (zero) and the MED value to the maximum (4294967295) for the routes to be advertised.

2. After the specified wait time elapses, restore the local preference value and the MED value for the advertised routes, and then advertise these routes immediately.

For the device to restore the priority of the advertised routes before the specified wait time elapses, use one of the following commands:

¡ reset bgp advertise lowest-priority on-startup

After you use this command, the device immediately sends BGP routes with the original local preference value and MED value to peers. The device does not minimize the priority of the subsequent routes advertised to the peers unless the device restarts again.

¡ undo advertise lowest-priority on-startup duration

After you use this command, the device immediately sends BGP routes with the original local preference value and MED value to peers. The device does not change the original local preference value and MED value for the subsequent routes advertised to the peers.

Restrictions and guidelines

When you use the advertise lowest-priority on-startup duration command, follows these guidelines:

· You can use this command in BGP instance view or BGP address family view:

¡ If you use this command in the view of a BGP instance, this command takes effect on all address families in the instance.

¡ If you use this command in the view of a BGP address family, this command takes effect only on the address family.

¡ For a BGP address family, the configuration of this command in BGP address family view takes precedence over that in BGP instance view.

· The configuration of this command does not take effect immediately. It takes effect only after the device restarts.

The following commands can influence the configuration of each other:

· advertise lowest-priority on-peer-up duration

· advertise lowest-priority on-startup duration

· bgp update-delay on-startup

· route-update-delay

About this task

Before performing this task, make sure the following conditions exist:

· The device has completed ARP or ND table convergence and is ready to advertise routes with original priority.

· The advertise lowest-priority on-peer-up duration or advertise lowest-priority on-startup duration command still takes effect after a peer comes up or the device restarts.

After you perform this task, the device immediately sends BGP routes with the original local preference value and MED value to peers.

· If the state of a peer changes from DOWN to UP later, the device still minimizes the priority of the routes advertised to that peer.

· If the device restarts again later, the device still minimizes the priority of the routes advertised to peers.

Procedure

To restore the priority of the advertised BGP routes, use the reset bgp [ instance instance-name ] advertise lowest-priority { on-peer-up | on-startup } command in user view.

Configuring the AIGP attribute

About this task

An Accumulated Interior Gateway Protocol (AIGP) administrative domain is a collection of multiple ASs that run the same IGP under one administrative control. Within the domain, BGP accumulates the IGP metrics all along the forwarding path for a route. Then, it uses the accumulated value as the AIGP attribute for the route to implement metric-based route selection.

By default, BGP does not advertise the AIGP attribute to its peers or peer groups. When BGP receives a route carrying the AIGP attribute, it ignores and removes the attribute before advertising the route to other peers or peer groups. Perform this task to enable BGP to advertise the AIGP attribute to its peers or peer groups.

With this feature enabled, a router processes the AIGP attribute in a received route as follows:

· If the router sets itself as the next hop for the route, it adds to the AIGP attribute value the IGP metric from itself to the original next hop and advertises the new AIGP attribute value.

· If the router does not set itself as the next hop for the route, it does not change the AIGP attribute value.

BGP uses the AIGP attribute to select the optimal route as follows:

· A route carrying the AIGP attribute takes precedence over a route not carrying the AIGP attribute.

· A route that has a smaller computed AIGP attribute value has a higher priority.

When the AIGP attribute of a route changes, BGP sends a route update with the new AIGP attribute.

Restrictions and guidelines

As a best practice, do not configure the peer aigp command on border routers of an AIGP administrative domain.

When a router receives a route not carrying the AIGP attribute, it does not advertise the AIGP attribute to a peer or peer group if you configure only the peer aigp command. To enable the router to advertise the AIGP attribute, you must configure both the peer aigp and apply aigp commands. For information about the apply aigp command, see "Configuring routing policies."

Procedure (IPv4)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Configure BGP to advertise the AIGP attribute to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } aigp

By default, BGP does not advertise the AIGP attribute to a peer or peer group and ignores the AIGP attribute in routes received from the peer or peer group.

5. (Optional.) Replace the MED value with AIGP value in routes advertised to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } aigp send med

By default, BGP does not replace the MED value with AIGP value in routes advertised to a peer or peer group.

Use this command to send the AIGP attribute to a peer or peer group that does not support AIGP.

Procedure (IPv6)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Configure BGP to advertise the AIGP attribute to the specified peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } aigp

By default, BGP does not advertise the AIGP attribute to a peer or peer group and ignores the AIGP attribute in routes received from the peer or peer group.

5. (Optional.) Replace the MED value with AIGP value in routes advertised to the specified peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } aigp send med

By default, BGP does not replace the MED value with AIGP value in routes advertised to a peer or peer group.

Use this command to send the AIGP attribute to a peer or peer group that does not support AIGP.

Ignoring IGP metrics during optimal route selection

About this task

By default, BGP includes IGP metrics in optimal route selection. If multiple routes to the same destination are available, BGP selects the route with the smallest IGP metric as the optimal route.

Perform this task to enable BGP to ignore IGP metrics during optimal route selection.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure BGP to ignore IGP metrics during optimal route selection.

bestroute igp-metric-ignore

By default, BGP includes IGP metrics in optimal route selection.

Ignoring router IDs during optimal route selection

About this task

By default, BGP compares router IDs during optimal route selection. If multiple routes to the same destination are available, BGP selects the route with the smallest router ID as the optimal route.

Perform this task to enable BGP to ignore router IDs during optimal route selection.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure BGP to ignore router IDs during optimal route selection.

bestroute router-id-ignore

By default, BGP selects the route with the smallest router ID as the optimal route.

Verifying and maintaining BGP path selection control

· To display BGP route attribute information, execute the following command in any view:

display bgp [ instance instance-name ] paths [ as-regular-expression ]

· To restore the priority of the advertised routes during the time to wait for route priority restoration, execute the following command in user view:

reset bgp [ instance instance-name ] advertise lowest-priority { on-peer-up | on-startup }

BGP path selection control configuration examples

Example: Configuring BGP path selection

Network configuration

As shown in Figure 25, all routers run BGP.

· EBGP runs between Router A and Router B, and between Router A and Router C.

· IBGP runs between Router B and Router D, and between Router D and Router C. OSPF is the IGP protocol in AS 200.

Configure routing policies to make Router D give priority to the route 1.0.0.0/8 learned from Router C.

Figure 25 Network diagram

‌

Table 6 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Router A	HGE1/0/1	1.0.0.1/8	Router D	HGE1/0/1	195.1.1.1/24
	HGE1/0/2	192.1.1.1/24		HGE1/0/2	194.1.1.1/24
	HGE1/0/3	193.1.1.1/24	Router C	HGE1/0/1	193.1.1.2/24
Router B	HGE1/0/1	192.1.1.2/24		HGE1/0/2	195.1.1.2/24
	HGE1/0/2	194.1.1.2/24

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure OSPF on Router B, Router C, and Router D:

# Configure Router B.

<RouterB> system-view

[RouterB] ospf

[RouterB-ospf] area 0

[RouterB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255

[RouterB-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[RouterB-ospf-1-area-0.0.0.0] quit

[RouterB-ospf-1] quit

# Configure Router C.

<RouterC> system-view

[RouterC] ospf

[RouterC-ospf] area 0

[RouterC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255

[RouterC-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[RouterC-ospf-1-area-0.0.0.0] quit

[RouterC-ospf-1] quit

# Configure Router D.

<RouterD> system-view

[RouterD] ospf

[RouterD-ospf] area 0

[RouterD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[RouterD-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[RouterD-ospf-1-area-0.0.0.0] quit

[RouterD-ospf-1] quit

3. Configure BGP connections:

# Configure Router A.

<RouterA> system-view

[RouterA] bgp 100

[RouterA-bgp-default] peer 192.1.1.2 as-number 200

[RouterA-bgp-default] peer 193.1.1.2 as-number 200

[RouterA-bgp-default] address-family ipv4 unicast

[RouterA-bgp-default-ipv4] peer 192.1.1.2 enable

[RouterA-bgp-default-ipv4] peer 193.1.1.2 enable

# Inject network 1.0.0.0/8 into the BGP routing table of Router A.

[RouterA-bgp-default-ipv4] network 1.0.0.0 8

[RouterA-bgp-default-ipv4] quit

[RouterA-bgp-default] quit

# Configure Router B.

[RouterB] bgp 200

[RouterB-bgp-default] peer 192.1.1.1 as-number 100

[RouterB-bgp-default] peer 194.1.1.1 as-number 200

[RouterB-bgp-default] address-family ipv4 unicast

[RouterB-bgp-default-ipv4] peer 192.1.1.1 enable

[RouterB-bgp-default-ipv4] peer 194.1.1.1 enable

[RouterB-bgp-default-ipv4] quit

[RouterB-bgp-default] quit

# Configure Router C.

[RouterC] bgp 200

[RouterC-bgp-default] peer 193.1.1.1 as-number 100

[RouterC-bgp-default] peer 195.1.1.1 as-number 200

[RouterC-bgp-default] address-family ipv4 unicast

[RouterC-bgp-default-ipv4] peer 193.1.1.1 enable

[RouterC-bgp-default-ipv4] peer 195.1.1.1 enable

[RouterC-bgp-default-ipv4] quit

[RouterC-bgp-default] quit

# Configure Router D.

[RouterD] bgp 200

[RouterD-bgp-default] peer 194.1.1.2 as-number 200

[RouterD-bgp-default] peer 195.1.1.2 as-number 200

[RouterD-bgp-default] address-family ipv4 unicast

[RouterD-bgp-default-ipv4] peer 194.1.1.2 enable

[RouterD-bgp-default-ipv4] peer 195.1.1.2 enable

[RouterD-bgp-default-ipv4] quit

[RouterD-bgp-default] quit

4. Configure local preference for the route 1.0.0.0/8 to make Router D give priority to the route learned from Router C:

# Define IPv4 basic ACL 2000 to permit the route 1.0.0.0/8 on Router C.

[RouterC] acl basic 2000

[RouterC-acl-ipv4-basic-2000] rule permit source 1.0.0.0 0.255.255.255

[RouterC-acl-ipv4-basic-2000] quit

# Define routing policy localpref on Router C to set the local preference of route 1.0.0.0/8 to 200 (the default is 100).

[RouterC] route-policy localpref permit node 10

[RouterC-route-policy-localpref-10] if-match ip address acl 2000

[RouterC-route-policy-localpref-10] apply local-preference 200

[RouterC-route-policy-localpref-10] quit

# Apply the routing policy localpref to the route from the peer 193.1.1.1 on Router C.

[RouterC] bgp 200

[RouterC-bgp-default] address-family ipv4 unicast

[RouterC-bgp-default-ipv4] peer 193.1.1.1 route-policy localpref import

[RouterC-bgp-default-ipv4] quit

[RouterC-bgp-default] quit

# Display the BGP routing table on Router D.

[RouterD] display bgp routing-table ipv4

Total number of routes: 2

BGP local router ID is 195.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 1.0.0.0/8 193.1.1.1 200 0 100i

* i 192.1.1.1 100 0 100i

The route 1.0.0.0/8 learned from Router C is the optimal route.

BGP path selection control configuration examples

Example: Configuring BGP path selection

Network configuration

As shown in Figure 26, all switches run BGP.

· EBGP runs between Switch A and Switch B, and between Switch A and Switch C.

· IBGP runs between Switch B and Switch D, and between Switch D and Switch C. OSPF is the IGP protocol in AS 200.

Configure routing policies, making Switch D use the route 1.0.0.0/8 from Switch C as the optimal.

Figure 26 Network diagram

‌

Table 7 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int101	1.0.0.1/8	Switch D	Vlan-int400	195.1.1.1/24
	Vlan-int100	192.1.1.1/24		Vlan-int300	194.1.1.1/24
	Vlan-int200	193.1.1.1/24	Switch C	Vlan-int400	195.1.1.2/24
Switch B	Vlan-int100	192.1.1.2/24		Vlan-int200	193.1.1.2/24
	Vlan-int300	194.1.1.2/24

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure OSPF on Switch B, Switch C, and Switch D:

# Configure Switch B.

<SwitchB> system-view

[SwitchB] ospf

[SwitchB-ospf] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] ospf

[SwitchC-ospf] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] ospf

[SwitchD-ospf] area 0

[SwitchD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[SwitchD-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[SwitchD-ospf-1-area-0.0.0.0] quit

[SwitchD-ospf-1] quit

3. Configure BGP connections:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] peer 192.1.1.2 as-number 200

[SwitchA-bgp-default] peer 193.1.1.2 as-number 200

[SwitchA-bgp-default] address-family ipv4 unicast

[SwitchA-bgp-default-ipv4] peer 192.1.1.2 enable

[SwitchA-bgp-default-ipv4] peer 193.1.1.2 enable

# Inject network 1.0.0.0/8 to the BGP routing table on Switch A.

[SwitchA-bgp-default-ipv4] network 1.0.0.0 8

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

[SwitchB] bgp 200

[SwitchB-bgp-default] peer 192.1.1.1 as-number 100

[SwitchB-bgp-default] peer 194.1.1.1 as-number 200

[SwitchB-bgp-default] address-family ipv4 unicast

[SwitchB-bgp-default-ipv4] peer 192.1.1.1 enable

[SwitchB-bgp-default-ipv4] peer 194.1.1.1 enable

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

[SwitchC] bgp 200

[SwitchC-bgp-default] peer 193.1.1.1 as-number 100

[SwitchC-bgp-default] peer 195.1.1.1 as-number 200

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 193.1.1.1 enable

[SwitchC-bgp-default-ipv4] peer 195.1.1.1 enable

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

# Configure Switch D.

[SwitchD] bgp 200

[SwitchD-bgp-default] peer 194.1.1.2 as-number 200

[SwitchD-bgp-default] peer 195.1.1.2 as-number 200

[SwitchD-bgp-default] address-family ipv4 unicast

[SwitchD-bgp-default-ipv4] peer 194.1.1.2 enable

[SwitchD-bgp-default-ipv4] peer 195.1.1.2 enable

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

4. Configure local preference for route 1.0.0.0/8, making Switch D give priority to the route learned from Switch C:

# Define IPv4 basic ACL 2000 on Switch C to permit route 1.0.0.0/8.

[SwitchC] acl basic 2000

[SwitchC-acl-ipv4-basic-2000] rule permit source 1.0.0.0 0.255.255.255

[SwitchC-acl-ipv4-basic-2000] quit

# Configure a routing policy named localpref on Switch C, setting the local preference of route 1.0.0.0/8 to 200 (the default is 100).

[SwitchC] route-policy localpref permit node 10

[SwitchC-route-policy-localpref-10] if-match ip address acl 2000

[SwitchC-route-policy-localpref-10] apply local-preference 200

[SwitchC-route-policy-localpref-10] quit

# Apply routing policy localpref to routes from peer 193.1.1.1.

[SwitchC] bgp 200

[SwitchC-bgp-default] address-family ipv4 unicast

[SwitchC-bgp-default-ipv4] peer 193.1.1.1 route-policy localpref import

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

# Display the BGP routing table on Switch D.

[SwitchD] display bgp routing-table ipv4

Total number of routes: 2

BGP local router ID is 195.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 1.0.0.0/8 193.1.1.1 200 0 100i

* i 192.1.1.1 100 0 100i

Route 1.0.0.0/8 learned from Switch C is the optimal.

06-Layer 3—IP Routing Configuration Guide

Idle

Connect

Active

OpenSent

OpenConfirm

Established

ORIGIN

AS_PATH

NEXT_HOP

MED (MULTI_EXIT_DISC)

LOCAL_PREF

COMMUNITY

Extended community attribute

BGP load balancing through route recursion

BGP load balancing through route selection

Route summarization

Route dampening

Peer group

Community

Route reflector

Confederation

Supported address families

MP-BGP extended attributes

Address family

Exchanging IPv4 and IPv6 routes in both IPv4 and IPv6 address families

Building basic BGP networks

Configuring basic BGP

Enabling BGP

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure (Exchanging IPv4 unicast routes with IPv4 peers)

Procedure (Exchanging IPv6 unicast routes with IPv4 peers)

Procedure (Exchanging IPv4 unicast routes with IPv6 peers)

About this task

Restrictions and guidelines

Procedure (Exchanging IPv4 unicast routes with dynamic IPv4 peers)

Procedure (Exchanging IPv6 unicast routes with dynamic IPv4 peers)

Procedure (Exchanging IPv6 unicast routes with dynamic IPv6 peers)

Procedure (Exchanging IPv4 unicast routes with dynamic IPv6 peers)

About this task

Restrictions and guidelines

Procedure (Exchanging IPv4 unicast routes with IPv4 peers)

Procedure (Exchanging IPv6 unicast routes with IPv4 peers)

Procedure (Exchanging IPv6 unicast routes with IPv6 peers)

Procedure (Exchanging IPv4 unicast routes with IPv6 peers)

About this task

Restrictions and guidelines

Configuring an EBGP peer group by using Method 1 (Exchanging IPv4 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 2 (Exchanging IPv4 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 3 (Exchanging IPv4 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 1 (Exchanging IPv6 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 2 (Exchanging IPv6 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 3 (Exchanging IPv6 unicast routes with IPv4 peers)

Configuring an EBGP peer group by using Method 1 (Exchanging IPv6 unicast routes with IPv6 peers)

Configuring an EBGP peer group by using Method 2 (Exchanging IPv6 unicast routes with IPv6 peers)

Configuring an EBGP peer group by using Method 3 (Exchanging IPv6 unicast routes with IPv6 peers)

Configuring an EBGP peer group by using Method 1 (Exchanging IPv4 unicast routes with IPv6 peers)

Configuring an EBGP peer group by using Method 2 (Exchanging IPv4 unicast routes with IPv6 peers)

Configuring an EBGP peer group by using Method 3 (Exchanging IPv4 unicast routes with IPv6 peers)

Specifying the source address of TCP connections

About this task

Restrictions and guidelines

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast address family)

About this task

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast address family)

Configuring BGP route summarization

About this task

Restrictions and guidelines for configuring BGP route summarization

Configuring automatic route summarization (IPv4 unicast address family)

Configuring manual route summarization (IPv4 unicast address family)

Configuring BGP manual route summarization (IPv6 unicast address family)

About this task

Procedure (IPv4 unicast address family)