BGP typically establishes a multihop TCP connection with a peer. Multiple intermediate devices might fragment BGP packets due to their MTU settings, resulting in frequent packet encapsulations and decapsulations that reduce forwarding efficiency.

To resolve this issue, you can perform this task to s et the TCP maximum segment size (MSS) for a peer or peer group. TCP segments sent by the source will not be re-fragmented along the path to the destination.

During TCP connection establishment with the peer or peer group specified in the peer tcp-mss command, the minimum of the following MSSs takes effect:

· The MSS calculated according to the IPv4 MTU set by the ip mtu command on the peer-facing interface.

· The MSS set by the tcp mss command for the peer-facing interface.

· The MSS calculated according to the path MTU detected by TCP path MTU discovery (enabled with the tcp path-mtu-discovery command).

· The MSS set by the peer tcp-mss command.

The MSS is calculated by using the following formula:

MSS = path MTU – IP header length – TCP header length

For more information about MTU and MSS, see IP performance optimization configuration in Layer 3—IP Services Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Set the TCP MSS for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } tcp-mss mss-value

By default, the TCP MSS is not set.

CAUTION:

Using this command might cause BGP session re-establishment. Make sure you understand the potential impact before using this command.

‌

Enabling BGP to establish an EBGP session over multiple hops

About this task

To establish an EBGP session, two routers must have a direct physical link and use directly connected interfaces. If no direct link is available, you must use the peer ebgp-max-hop command to enable BGP to establish an EBGP session over multiple hops and specify the maximum hops.

Restrictions and guidelines

When the BGP GTSM feature is enabled, two peers can establish an EBGP session after passing GTSM check, regardless of whether the maximum number of hops is reached.

To ensure correct BGP route recursion, do not specify any direct EBGP peer or peer group when you configure the peer ebgp-max-hop command.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP to establish an EBGP session to an indirectly connected peer or peer group and specify the maximum hop count.

peer { group-name | ipv4-address [ mask-length ] } ebgp-max-hop [ hop-count ]

By default, BGP cannot establish an EBGP session to an indirectly connected peer or peer group.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP to establish an EBGP session to an indirectly connected peer or peer group and specify the maximum hop count.

peer { group-name | ipv6-address [ prefix-length ] } ebgp-max-hop [ hop-count ]

By default, BGP cannot establish an EBGP session to an indirectly connected peer or peer group.

E nabling immediate re-establishment of direct EBGP connections upon link failure

About this task

When this feature is disabled and the link to a directly connected EBGP peer goes down, the router does not re-establish a session to the peer until the hold time timer expires. In this situation, route flapping does not affect EBGP session state. This feature enables BGP to immediately recreate the session in that situation.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable immediate re-establishment of direct EBGP connections upon link failure.

ebgp-interface-sensitive

By default, immediate re-establishment of direct EBGP connections is enabled.

Enabling BGP ORF capabilities negotiation

About BGP ORF

BGP Outbound Route Filtering (ORF) saves the system resources by reducing the route updates that are sent between BGP peers.

The BGP peers negotiate the ORF capabilities through Open messages. After completing the negotiation process, the BGP peers can exchange ORF information (local route reception filtering policy) through route refresh messages. Then, only routes that pass both the local route distribution filtering policy and the received route reception filtering policy can be advertised.

Restrictions and guidelines

You can enable the ORF information sending, receiving, or both sending and receiving capabilities on a BGP router. For two BGP peers to successfully negotiate the ORF capabilities, make sure one end has the sending capability and the other end has the receiving capability.

After you enable BGP ORF capabilities negotiation for a peer, the local device negotiates standard ORF capabilities as defined in RFC with the peer. If the peer uses nonstandard ORF, you must also enable nonstandard ORF capabilities negotiation for the peer.

Enabling BGP ORF capabilities negotiation for a peer or peer group

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Enable BGP ORF capabilities negotiation for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise orf prefix-list { both | receive | send }

By default, BGP ORF capabilities negotiation is disabled for a peer or peer group.

The ipv6-address [ prefix-length ] argument is not supported in BGP IPv4 multicast address family view.

Procedure (IPv6 unicast/IPv6 multicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Enable BGP ORF capabilities negotiation for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise orf prefix-list { both | receive | send }

By default, BGP ORF capabilities negotiation is disabled for a peer or peer group.

The ipv4-address [ mask-length ] argument is not supported in BGP IPv6 multicast address family view.

Enabling nonstandard BGP ORF capabilities negotiation for a peer or peer group

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable nonstandard BGP ORF capabilities negotiation for a peer or peer group.

peer { group-name | ip-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise orf non-standard

By default, nonstandard BGP ORF capabilities negotiation is disabled for a peer or peer group.

Verifying and maintaining BGP ORF

Perform displays tasks in any view.

· Display the ORF prefix information received by an IPv4 unicast peer.

display bgp [ instance instance-name ] peer ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] ipv4-address received prefix-list

· Display the ORF prefix information received by an IPv6 unicast peer.

display bgp [ instance instance-name ] peer ipv6 [ unicast ] [ vpn-instance vpn-instance-name ] ipv6-address received prefix-list

display bgp [ instance instance-name ] peer ipv6 [ unicast ] ipv4-address received prefix-list

· Display the ORF prefix information received by an IPv4 multicast peer.

display bgp [ instance instance-name ] peer ipv4 multicast ipv4-address received prefix-list

Enabling 4-byte AS number suppression

About this task

BGP supports 4-byte AS numbers. The 4-byte AS number occupies four bytes, in the range of 1 to 4294967295. By default, a device sends an OPEN message to the peer device for session establishment. The OPEN message indicates that the device supports 4-byte AS numbers. If the peer device supports 2-byte AS numbers instead of 4-byte AS numbers, the session cannot be established. To resolve this issue, enable the 4-byte AS number suppression feature. The device then sends an OPEN message to inform the peer that it does not support 4-byte AS numbers, so the BGP session can be established.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable 4-byte AS number suppression.

peer { group-name | ipv4-address [ mask-length ] } capability-advertise suppress-4-byte-as

By default, 4-byte AS number suppression is disabled.

CAUTION:

If the peer device supports 4-byte AS numbers, do not enable the 4-byte AS number suppression feature. Otherwise, the BGP session cannot be established.

‌

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable 4-byte AS number suppression.

peer { group-name | ipv6-address [ prefix-length ] } capability-advertise suppress-4-byte-as

By default, 4-byte AS number suppression is disabled.

CAUTION:

If the peer device supports 4-byte AS numbers, do not enable the 4-byte AS number suppression feature. Otherwise, the BGP session cannot be established.

‌

Enabling BGP to exchange withdrawal ROUTE-REFRESH messages with peers

About this task

As shown in Figure 1, two upstream BGP devices are deployed in a multi-level BGP network. When all uplinks of an upstream device fail and the device cannot complete route convergence in time, the device might also fail to send route withdrawal messages to downstream devices in time. At this time, those downstream devices still forward some user traffic to the upstream device, resulting in traffic forwarding failure.

Figure 1 Multi-level BGP network

‌

To avoid this issue, enable the upstream device to exchange withdrawal ROUTE-REFRESH messages with downstream devices. As shown in Figure 2, when all uplinks of the upstream device fail, it sends withdrawal ROUTE-REFRESH messages to the downstream devices. On receipt of the withdrawal ROUTE-REFRESH messages, the downstream devices immediately perform route switchover and forward traffic to another upstream device with normal uplinks.

Figure 2 Exchanging withdrawal ROUTE-REFRESH messages in the multi-level BGP network

‌

After this feature is configured, the upstream device performs the following operations:

1. Terminates and re-establishes the BGP session to the specified downstream device.

2. Exchanges OPEN messages with the downstream device to negotiate the capability of exchanging withdrawal ROUTE-REFRESH messages.

To ensure successful negotiation, you must configure this command at both ends of the BGP session, specifying the other end.

With the withdrawal ROUTE-REFRESH capability negotiated successfully, if the upstream device is disconnected from all peers in the same AS, it sends a withdrawal ROUTE-REFRESH message to the downstream device. The sent message carries the AS number from which the upstream device is disconnected. In this example, the disconnected AS is AS 10.

After receiving the withdrawal ROUTE-REFRESH message, the downstream device performs the following operations:

1. Searches in all BGP routes received from the upstream BGP device for routes with AS 10 as the first AS number in the NEXT_HOP attribute.

To view AS number information in the NEXT_HOP attribute of a BGP route, see the AS-path field in the output of the display rib nib or display ipv6 rib nib command. For more information about the two commands, see IP routing basics commands in Layer 3—IP Routing Command Reference.

2. After finding routes with AS 10 as the first AS number in the NEXT_HOP attribute, marks the IP routes corresponding to those routes as backup routes.

The downstream device no longer uses these routes for traffic forwarding, achieving fast route switchover.

After receiving a withdrawal ROUTE-REFRESH message, the device forwards the message to its peers as follows:

· If the message is received from an IBGP peer, the device forwards the message only to EBGP peers.

· If the message is received from an EBGP peer, the device forwards the message only to IBGP peers without changing the original AS number of the message.

You can use the peer capability-advertise withdraw-refresh command in conjunction with the peer tracking command on an upstream device. The peer tracking command enables the upstream device to fast detect status of the specified BGP peer session. When the related peer is unreachable, the local device immediately terminates the BGP peer session in time and sends withdrawal ROUTE-REFRESH messages to downstream devices. Collaboration of the two commands expedites forwarding path convergence upon uplink failures.

Restrictions and guidelines

Execute the peer capability-advertise withdraw-refresh command with caution, because this operation will terminate and re-establish the BGP session between the local device and the specified peer.

This feature is only applicable to the scenario described in "About this task". It is not applicable to scenarios where upstream devices that advertise withdrawal ROUTE-REFRESH messages are connected to IBGP peers in the uplink direction.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Enter BGP-VPN instance view.

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP to exchange withdrawal ROUTE-REFRESH messages with a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise withdraw-refresh

By default, BGP cannot exchange withdrawal ROUTE-REFRESH messages with any peer or peer group.

Enabling Track-based priority adjustment for BGP routes advertised to a peer or peer group

About this task

This feature collaborates BGP with Track to achieve fast switchover of traffic forwarding paths in multi-level BGP networks. As shown in Figure 3, two upstream BGP devices are deployed on the network, for example, Device 1 and Device 2. When all uplinks of Device 1 fail and the device cannot complete route convergence in time, the device might also fail to send route withdrawal messages to downstream devices in time. At this time, those downstream devices still forward some user traffic to Device 1, resulting in traffic forwarding failure.

Figure 3 Multi-level BGP network diagram

‌

To avoid this issue, enable BGP to collaborate with Track on upstream BGP devices. When uplink failures occur on an upstream BGP device, route switchover is triggered immediately and user traffic can be forwarded to another upstream BGP device with normal uplinks.

Figure 4 Track-based priority adjustment for BGP routes advertised to a peer or peer group

‌

To enable Track-based priority adjustment for BGP routes advertised to a downstream BGP device, perform the following operations on each upstream BGP device:

1. Associate the link state of its upstream interface with a track entry. For more information about Track, see track configuration in High Availability Configuration Guide.

2. Execute the apply track command to configure an apply clause that references the associated track entry.

3. Execute the peer advertise lowest-priority track-route-policy command to enable BGP to collaborate with Track. The { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } parameter specifies the desired downstream BGP device and the route-policy-name parameter specifies the routing policy configured in the previous step.

When certain uplinks of the upstream BGP device go down, the associated track entry transitions to Negative state. After perceiving the track entry state change, BGP immediately performs the following operations on the upstream BGP device:

1. Minimizes the priority of all routes advertised to the specified downstream BGP device by setting the local preference value to 0 and MED value to the maximum.

2. Advertises those routes again to the downstream BGP device.

The downstream BGP device will no longer select routes from the upstream BGP device as optimal routes and will forward user traffic to another upstream BGP device. This mechanism accelerates forwarding path switchover upon uplink failures on an upstream BGP device by skipping the process of hold timer timeout > route invalidation > route withdrawal.

For more information about routing policies and the apply track command, see routing policy configuration in Layer 3—IP Routing Configuration Guide.

Restrictions and guidelines

If a routing policy is specified in the peer advertise lowest-priority track-route-policy command, only the apply track clause of that routing policy can take effect.

Although the peer advertise lowest-priority track-route-policy command and the peer capability-advertise withdraw-refresh command function similarly, they are different in the following aspects:

· To use the feature associated with the peer advertise lowest-priority track-route-policy command, you only need to configure this command on the desired device. The device and devices from different vendors can co-locate in the same network. However, this command cannot provide selective traffic forwarding path control, because it minimizes the priority of all routes advertised to the specified peer or peer group.

· The peer capability-advertise withdraw-refresh command can take effect only if the specified downstream BGP device supports withdraw ROUTE-REFRESH messages. This command can provide selective traffic forwarding path control, because it can perform traffic forwarding path switchover in scenarios where only uplink failures occur.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view.

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view.

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Enable Track-based priority adjustment for BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise lowest-priority track-route-policy route-policy-name

By default, Track-based priority adjustment is disabled for BGP routes advertised to a peer or peer group.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view.

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view.

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Enable Track-based priority adjustment for BGP routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise lowest-priority track-route-policy route-policy-name

By default, Track-based priority adjustment is disabled for BGP routes advertised to a peer or peer group.

Disabling BGP session establishment

About disabling BGP session establishment

This task enables you to temporarily tear down BGP sessions to a peer/peer group. You can perform network upgrade and maintenance without deleting and reconfiguring the peers and peer groups. To recover the sessions, execute the undo peer ignore command.

To lower the priority of the routes advertised by BGP, you can specify the graceful keyword in the peer ignore command or the ignore all-peers command, and configure route attributes. BGP peers can then select other peers' routes as optimal routes, which avoids traffic interruption upon wait timer expiration or peer disconnection. To enable BGP to advertise low-priority routes without tearing down BGP sessions, you can set the value for the graceful graceful-time option to 0.

If you specify the graceful keyword in the peer ignore command, BGP performs the following tasks:

1. Starts the wait timer specified with the graceful keyword.

2. Advertises all routes to the specified peer or peer group and changes the attribute of the advertised routes to the specified value.

Advertises routes from the specified peer or peer group to other IBGP peers and peer groups and changes the attribute of the advertised routes to the specified value.

3. Shuts down the session to the specified peer or peer group after the wait timer expires.

If you specify the graceful keyword in the ignore all-peers command, BGP performs the following tasks:

1. Starts the wait timer specified with the graceful keyword.

2. Advertises all routes to all peers and peer groups and changes the attribute of the advertised routes to the specified value.

3. Shuts down all sessions to peers and peer groups after the wait timer expires.

Restrictions and guidelines

For a BGP peer or peer group, the configuration made by the peer ignore command takes precedence over the configuration made by the ignore all-peers command.

Disabling BGP session establishment with a peer or peer group (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Disable BGP session establishment with a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } ignore [ graceful graceful-time { community { community-number | aa:nn } | local-preference preference | med med } * ]

By default, BGP can establish a session to a peer or peer group.

CAUTION:

· If a session has been established to a peer, executing this command for the peer tears down the session and clears all related routing information.

· If sessions have been established to a peer group, executing this command for the peer group tears down the sessions to all peers in the group and clears all related routing information.

‌

Disabling BGP session establishment with a peer or peer group (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Disable BGP session establishment with a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } ignore [ graceful graceful-time { community { community-number | aa:nn } | local-preference preference | med med } * ]

By default, BGP can establish a session to a peer or peer group.

CAUTION:

· If a session has been established to a peer, executing this command for the peer tears down the session and clears all related routing information.

· If sessions have been established to a peer group, executing this command for the peer group tears down the sessions to all peers in the group and clears all related routing information.

‌

Disabling BGP session establishment with all peers or peer groups

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Disable BGP session establishment with all peers or peer groups.

ignore all-peers [ graceful graceful-time { community { community-number | aa:nn } | local-preference preference | med med } * ]

By default, BGP can establish sessions to all peers and peer groups.

CAUTION:

Executing this command tears down all existing sessions to peers and peer groups and clears all related routing information.

‌

Configuring BGP soft-reset

About BGP soft-reset

After you modify the route selection policy, for example, modify the preferred value, you must reset BGP sessions to apply the new policy. The reset operation tears down and re-establishes BGP sessions.

To avoid tearing down BGP sessions, you can use one of the following soft-reset methods to apply the new policy:

· Enabling route refresh—The BGP router advertises a ROUTE-REFRESH message to the specified peer, and the peer resends its routing information to the router. After receiving the routing information, the router filters the routing information by using the new policy.

This method requires that both the local router and the peer support route refresh.

· Saving updates—Use the peer keep-all-routes command to save all route updates from the specified peer. After modifying the route selection policy, filter routing information by using the new policy.

This method does not require that the local router and the peer support route refresh but it uses more memory resources to save routes.

· Manual soft-reset—Use the refresh bgp command to enable BGP to send local routing information or advertise a ROUTE-REFRESH message to the specified peer. The peer then resends its routing information. After receiving the routing information, the router filters the routing information by using the new policy.

This method requires that both the local router and the peer support route refresh.

Enabling route refresh (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP route refresh for a peer or peer group.

¡ Enable BGP route refresh for the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } capability-advertise route-refresh

¡ Enable the BGP route refresh, multi-protocol extension, and 4-byte AS number features for the specified peer or peer group.

undo peer { group-name | ipv4-address [ mask-length ] } capability-advertise conventional

By default, the BGP route refresh, multi-protocol extension, and 4-byte AS number features are enabled.

Enabling route refresh (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP route refresh for a peer or peer group.

¡ Enable BGP route refresh for the specified peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } capability-advertise route-refresh

¡ Enable the BGP route refresh, multi-protocol extension, and 4-byte AS number features for the specified peer or peer group.

undo peer { group-name | ipv6-address [ prefix-length ] } capability-advertise conventional

By default, the BGP route refresh, multi-protocol extension, and 4-byte AS number features are enabled.

Saving updates (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Save all route updates from the peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } keep-all-routes

By default, route updates from peers and peer groups are not saved.

The ipv6-address [ prefix-length ] argument is not supported in BGP IPv4 multicast address family view.

This command takes effect only for the routes received after this command is executed.

Saving updates (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Save all route updates from the peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } keep-all-routes

By default, route updates from peers and peer groups are not saved.

The ipv4-address [ mask-length ] argument is not supported in BGP IPv6 multicast address family view.

This command takes effect only for the routes received after this command is executed.

Configuring manual soft-reset (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP route refresh for a peer or peer group.

¡ Enable BGP route refresh for the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } capability-advertise route-refresh

¡ Enable the BGP route refresh, multi-protocol extension, and 4-byte AS number features for the specified peer or peer group.

undo peer { group-name | ipv4-address [ mask-length ] } capability-advertise conventional

By default, the BGP route refresh, multi-protocol extension, and 4-byte AS number features are enabled.

4. Execute the quit command twice to return to user view.

quit

5. Perform manual soft-reset. Choose one option as needed:

¡ Perform manual soft-reset on IPv4 sessions in BGP IPv4 address family.

refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] | all | external | group group-name | internal } { export | import } ipv4 [ multicast | [ unicast ] [ vpn-instance vpn-instance-name ] ]

¡ Perform manual soft-reset on IPv6 sessions in BGP IPv4 address family.

refresh bgp [ instance instance-name ] { ipv6-address [ prefix-length ] | all | external | group group-name | internal } { export | import } ipv4 [ multicast | [ unicast ] [ vpn-instance vpn-instance-name ] ]

Configuring manual soft-reset (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BGP route refresh for a peer or peer group.

¡ Enable BGP route refresh for the specified peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } capability-advertise route-refresh

¡ Enable the BGP route refresh, multi-protocol extension, and 4-byte AS number features for the specified peer or peer group.

undo peer { group-name | ipv6-address [ prefix-length ] } capability-advertise conventional

By default, the BGP route refresh, multi-protocol extension, and 4-byte AS number features are enabled.

4. Execute the quit command twice to return to user view.

quit

5. Perform manual soft-reset. Choose one option as needed:

¡ Perform manual soft-reset on IPv6 sessions in BGP IPv6 address family.

refresh bgp [ instance instance-name ] { ipv6-address [ prefix-length ] | all | external | group group-name | internal } { export | import } ipv6 [ multicast | [ unicast ] [ vpn-instance vpn-instance-name ] ]

¡ Perform manual soft-reset on IPv4 sessions in BGP IPv6 address family.

refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] | all | external | group group-name | internal } { export | import } ipv6 [ multicast | [ unicast ] [ vpn-instance vpn-instance-name ] ]

Configuring BGP load balancing

About this task

Perform this task to specify the maximum number of BGP ECMP routes for load balancing.

Restrictions and guidelines

When you use the balance command, follow these guidelines:

· If you specify the ecmp-nexthop-local keyword, BGP sets the local device IP as the next hop of each load balancing route.

· If you specify the ecmp-nexthop-unchanged keyword, BGP does not change the next hop of each load balancing route.

· If you specify neither the ecmp-nexthop-local keyword nor the ecmp-nexthop-unchanged keyword, BGP advertises the routes used for load balancing to IBGP peers as follows:

¡ Without the Add-Path feature configured, BGP advertises only the optimal route among the routes used for load balancing and sets the local device IP as the next hop of that optimal route.

¡ With the Add-Path feature configured, BGP performs the following tasks:

- Advertises the routes used for load balancing. The number of routes that BGP can advertise equals the maximum number of Add-Path optimal routes that can be advertised.

- Sets the local device IP as the next hop of the optimal route among the advertised routes.

Both the balance igp-metric-ignore and bestroute igp-metric-ignore commands can enable BGP to use routes with different IGP metrics for load balancing. The two commands are different as follows:

· The balance igp-metric-ignore command can be used only for load balancing. It does not change the rules of optimal route selection. BGP still compares the IGP metric value of each route during optimal route selection.

· The bestroute igp-metric-ignore command takes effect on optimal route selection and on route selection for load balancing. With this command executed, BGP will ignore the IGP metric in both cases.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. (Optional.) Enable BGP to ignore IGP metrics during optimal route selection.

bestroute igp-metric-ignore

By default, BGP compares IGP metrics during optimal route selection, and selects the route with the smallest IGP metric as the optimal route.

BGP cannot use routes with different IGP metrics to implement load balancing. To resolve this issue, you can use this command.

4. Return to system view.

¡ In BGP instance view:

quit

¡ In BGP-VPN instance view:

quit

5. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

6. Specify the maximum number of BGP ECMP routes for load balancing.

balance [ ebgp | eibgp | ibgp ] number [ ecmp-nexthop-local | ecmp-nexthop-unchanged ]

By default, load balancing is disabled.

7. (Optional.) Enable BGP to ignore the AS_PATH attribute when it implements load balancing.

balance as-path-neglect

By default, BGP does not ignore the AS_PATH attribute when it implements load balancing.

8. (Optional.) Enable BGP to perform load balancing for routes that have different AS_PATH attributes of the same length.

balance as-path-relax [ ebgp | ibgp ]

By default, BGP cannot perform load balancing for routes that have different AS_PATH attributes of the same length.

9. (Optional.) Enable BGP to use routes with different IGP metrics for load balancing.

balance igp-metric-ignore

By default, BGP cannot use routes with different IGP metrics for load balancing.

Procedure (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. (Optional.) Enable BGP to ignore IGP metrics during optimal route selection.

bestroute igp-metric-ignore

By default, BGP compares IGP metrics during optimal route selection, and selects the route with the smallest IGP metric as the optimal route.

BGP cannot use routes with different IGP metrics to implement load balancing. To resolve this issue, you can use this command.

4. Return to system view.

¡ In BGP instance view:

quit

¡ In BGP-VPN instance view:

quit

5. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

6. Specify the maximum number of BGP ECMP routes for load balancing.

balance [ ebgp | eibgp | ibgp ] number [ ecmp-nexthop-local | ecmp-nexthop-unchanged ]

By default, load balancing is disabled.

7. (Optional.) Enable BGP to ignore the AS_PATH attribute when it implements load balancing.

balance as-path-neglect

By default, BGP does not ignore the AS_PATH attribute when it implements load balancing.

8. (Optional.) Enable BGP to perform load balancing for routes that have different AS_PATH attributes of the same length.

balance as-path-relax [ ebgp | ibgp ]

By default, BGP cannot perform load balancing for routes that have different AS_PATH attributes of the same length.

9. (Optional.) Enable BGP to use routes with different IGP metrics for load balancing.

balance igp-metric-ignore

By default, BGP cannot use routes with different IGP metrics for load balancing.

C onfiguring the BGP Additional Paths feature

About this task

On a large-scale network, a route reflector can receive multiple BGP routes with the same prefix. By default, BGP advertises only one optimal route. When the optimal route fails, traffic forwarding will be interrupted until route convergence completes.

To resolve this issue, configure the BGP Additional Paths (Add-Path) feature on the route reflector. This feature enables the device to advertise multiple routes with the same prefix to a peer or peer group. On receipt of these routes, the peer generates multiple links to the same destination network. You can use these links to implement load balancing with the balance command or configure backup routes. When the optimal link fails, another link can take over to forward traffic, which enhances the reliability of data transmission.

Restrictions and guidelines

You can enable the BGP additional path sending, receiving, or both sending and receiving capabilities on a BGP peer. For two BGP peers to successfully negotiate the Additional Paths capabilities, make sure one end has the sending capability and the other end has the receiving capability.

Procedure (IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Configure the BGP Additional Paths capabilities.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } additional-paths { receive | send } *

By default, no BGP Additional Paths capabilities are configured.

4. Set the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise additional-paths best number

By default, a maximum of one Add-Path optimal route can be advertised to a peer or peer group.

5. Set the maximum number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number

By default, a maximum of one Add-Path optimal route can be advertised to all peers.

Procedure (IPv6 unicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Configure the BGP Additional Paths capabilities.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } additional-paths { receive | send } *

By default, no BGP Additional Paths capabilities are configured.

4. Set the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise additional-paths best number

By default, a maximum of one Add-Path optimal route can be advertised to a peer or peer group.

5. Set the maximum number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number

By default, a maximum of one Add-Path optimal route can be advertised to all peers.

Configuring BGP optimal route selection delay

About this task

Typically BGP optimal route selection is triggered in real time by the events such as attribute change, configuration change, and route recursion. To avoid packet loss upon switchover between redundant links, you can perform this task to delay optimal route selection.

As shown in Figure 5, BGP runs on all devices in the network. Device A and Device D uses the primary path for communication. When the primary path fails, Device A and Device D switch to the backup path for communication and then back to the primary path after the primary path recovers. In such case, traffic loss might occur if Device A forwards packets through Device B before Device B completes route convergence. You can configure optimal route selection delay on Device A to resolve the issue.

Figure 5 Network diagram

‌

Restrictions and guidelines

Follow these restrictions and guidelines when you configure this feature:

· The optimal route selection delay setting applies only when multiple effective routes with the same prefix exist after a route change occurs.

· For routes being delayed for optimal route selection, modifying the optimal route selection delay timer has the following effects:

¡ If you modify the delay timer to a non-zero value, the routes are not affected, and they still use the original delay timer.

¡ If you execute the undo form of the route-select delay command or modify the delay timer to 0, the device performs optimal route selection immediately.

· The optimal route selection delay configuration does not apply to the following conditions:

¡ A route change is caused by execution of a command or by route withdrawal.

¡ After a route change occurs, only one route exists for a specific destination network.

¡ An active/standby process switchover occurs.

¡ A route change occurs among equal-cost routes.

¡ Only the optimal and suboptimal routes exist when FRR is configured.

¡ Optimal route selection is triggered by a redistributed route.

¡ The next hop of the optimal route changes and a route with the same prefix is waiting for the delay timer to expire.

Procedure (IPv4 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Set the optimal route selection delay timer.

route-select delay delay-value

By default, the optimal route selection delay timer is 0 seconds, which means optimal route selection is not delayed.

Procedure (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Set the optimal route selection delay timer.

route-select delay delay-value

By default, the optimal route selection delay timer is 0 seconds, which means optimal route selection is not delayed.

Delaying BGP in notifying the RIB to delete routes

About this task

By default, valid optimal BGP routes can guide traffic forwarding only after they are issued from the BGP routing table to the RIB. When a BGP route is deleted from the BGP routing table, BGP also notifies the RIB to delete the related route.

As shown in Figure 6, Device A advertises its routing information to both Device B and Device C through BGP routes. Device B and Device C forward the route information received from Device A to each other, as shown by the pink arrows in the network diagram. During optimal route selection, Device B selects the route that uses Device C as the next hop, and Device C selects the route that is directly received from Device A. Guided by the default route, Device D sends traffic destined for Device A to both Device B and Device C. Based on the BGP route selection results on Device B and Device C, all traffic from Device D will be forwarded to Device A via Device C, as shown by the green arrows in the network diagram.

Figure 6 Original network diagram

As shown in Figure 7, when Device A withdraws the route information advertised to Device C, Device C must notify the RIB to remove the route information received from Device A. Consequently, Device C can only obtain the routing information of Device A through the routes learned from Device B, as shown by the pink arrows in the network diagram. After Device D sends traffic destined for Device A to Device B or Device C, all of the traffic is forwarded to Device A via Device B, as shown by the green arrows in the network diagram. Since the route information that Device C forwarded from Device A to Device B is withdrawn, Device B must perform optimal route selection again. Before Device B finishes route reselection and issues the new optimal route to its local RIB, traffic disruption will occur. This is because Device B does not have a route that guides traffic forwarding from Device D to Device A. In this scenario, a protection mechanism is required to prevent traffic disruption during the period when Device B performs route convergence to switch the forwarding path to Device D > (Device C >) Device B > Device A.

Figure 7 Network diagram after Device A withdraws the route information advertised to Device C

To meet this requirement, execute the route-select delay command to delay BGP in notifying the RIB to delete routes. When a route is deleted from the BGP routing table, BGP starts the specified delay timer. It does not notify the RIB to delete the related route unless the delay timer expires.

Figure 8 Network diagram when BGP is delayed in notifying the RIB to delete routes

As shown in Figure 8, when Device A withdraws the route information advertised to Device C, Device C does not immediately notify the RIB to delete the route information. The RIB retains the related route entries before the delay timer expires. During the route convergence on Device B, Device C can still use the routing information in the RIB for traffic forwarding from Device D to Device A, as shown by the green arrows in the network diagram. After Device B completes route convergence and the delay timer expires, Device C notifies the RIB to delete the routing information received from Device A. The forwarding path for traffic destined for Device A is then switched from Device D > (Device B >) Device C > Device A to Device D > (Device C >) Device B > Device A, as shown in Figure 9.

Figure 9 Network diagram after Device B completes route convergence

Restrictions and guidelines

This feature can delay BGP in notifying the RIB to delete a route only if that route has a unique route prefix in the RIB.

You can repeat the route-select delay command to modify the delay timer and the new delay timer takes effect as follows:

NOTE:

In this chapter, a delayed route is a route for which BGP sends a deletion notification to the RIB after the specified delay timer expires.

· If the new delay timer is non-zero, it does not take effect on the delayed routes.

· If the new delay timer is 0, the RIB will delete the delayed routes immediately.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Delay BGP in notifying the RIB to delete routes.

route-select delay delay-value

By default, the delay timer is 0 seconds. BGP is not delayed in notifying the RIB to delete routes.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Delay BGP in notifying the RIB to delete routes.

route-select delay delay-value

By default, the delay timer is 0 seconds. BGP is not delayed in notifying the RIB to delete routes.

Performing local-FIB route check before route update advertisement

About this task

This feature is applicable to devices with poor route convergence performance. After receiving BGP routes from a device (for example, Device A) with poor route convergence performance, a peer device completes route selection and adds the selected BGP routes to its local FIB. Packet loss might occur if the peer device finishes those tasks before Device A finishes adding the advertised BP routes into the local FIB. To avoid this issue, use this feature to enable local-FIB route check for BGP. Before sending routes in UPDATE messages, BGP identifies whether those routes are installed into the local FIB. Only routes in the local FIB can be advertised in UPDATE messages.

Restrictions and guidelines

When you configure the update wait-install command, follow these restrictions and guidelines:

· In BGP IPv4 unicast address family view, this command only takes effect on BGP IPv4 unicast routes.

· In BGP IPv6 unicast address family view, this command only takes effect on BGP IPv6 unicast routes.

· In BGP-VPN IPv4 unicast address family view, this command only takes effect on the following routes:

¡ BGP-VPN IPv4 unicast routes.

¡ BGP VPNv4 and BGP EVPN routes generated based on BGP-VPN IPv4 unicast routes.

· In BGP-VPN IPv6 unicast address family view, this command only takes effect on the following routes:

¡ BGP-VPN IPv6 unicast routes.

¡ BGP VPNv6 and BGP EVPN routes generated based on BGP-VPN IPv6 unicast routes.

· In BGP instance view, this command only takes effect on the following routes:

¡ BGP IPv4 and IPv6 unicast routes.

¡ BGP-VPN IPv4 and IPv6 unicast routes.

¡ BGP VPNv4, BGP VPNv6, and BGP EVPN routes generated based on BGP-VPN IPv4 and IPv6 unicast routes.

· This command does not take effect on the following routes:

¡ Routes redistributed by the import-route command.

¡ Routes advertised by the network command.

¡ Default routes imported by the default-route imported command.

¡ BGP VPNv4, BGP VPNv6, and BGP EVPN source routes.

¡ BGP IPv4 multicast routes and BGP IPv6 multicast routes.

· This command only takes effect on BGP routes that are generated after the command is executed. To have this command take effect on BGP routes that are generated before the command is executed, use the reset bgp command to reset BGP sessions and re-obtain route information.

· If this command is configured in both BGP instance view and an address family view, the address family-specific configuration takes precedence for the related address family.

· This command is mutually exclusive with the routing-table bgp-rib-only command.

Procedure (global)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP to perform local-FIB route check before route update advertisement.

update wait-install

By default, local-FIB route check is disabled for BGP. When BGP sends routes in UPDATE messages, it does not identify whether those routes have been installed into the local FIB.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Enable BGP to perform local-FIB route check before route update advertisement.

update wait-install

By default, local-FIB route check is disabled for BGP. When BGP sends routes in UPDATE messages, it does not identify whether those routes have been installed into the local FIB.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Enable BGP to perform local-FIB route check before route update advertisement.

update wait-install

By default, local-FIB route check is disabled for BGP. When BGP sends routes in UPDATE messages, it does not identify whether those routes have been installed into the local FIB.

Configuring the BGP session state to collaborate with the monitor link downlink interfaces

About this task

On the network as shown in Figure 10, Device A establishes BGP sessions to Device B and Device C, and both Device B and Device C establish BGP sessions to Device D and Device E. Users accessing Device D and Device E communicate with the external network through the BGP routes deployed by Device A. In normal conditions, traffic from users to the external network is load-shared between Device B and Device C.

In this scenario, if the link between Device A and Device B fails, the BGP session between Device A and Device B will be disconnected. Then, the BGP routes advertised by Device A cannot be forwarded to Device D and Device E through Device B. As a result, the traffic from users to the external network will not be forwarded through Device B. In this case, BGP sessions from Device B to Device D and Device E do not need to be established. You can disconnect these BGP sessions to save system resources.

Figure 10 Network diagram for the BGP session state to collaborate with the monitor link downlink interfaces

‌

With this feature configured, when the BGP session between Device A and Device B is disconnected, the BGP sessions from Device B to Device D and Device E are also automatically disconnected. When the BGP session between Device A and Device B recovers, the BGP sessions from Device B to Device D and Device E also automatically recover.

After this feature is configured, the BGP session between the local device and the peer or peer group specified by this feature will be used as a type of uplink interface in the specified monitor link group. The uplink interfaces and downlink interfaces in a monitor link group collaborate as follows:

· Uplink interfaces are defined as follows:

¡ In a monitor link group, an interface specified by using the port uplink or port monitor-link group uplink command is considered as an uplink interface.

¡ In a monitor link group, each BGP process specified by using the monitor bgp command is considered as an uplink interface.

¡ In a monitor link group, a BGP session specified by using the peer monitor-link group command is considered as an uplink interface.

If the BGP sessions specified by using the peer monitor-link group command are established in the BGP process specified by using the monitor bgp command, and at least one of these BGP sessions is in Established state, the BGP process is not an uplink interface. If the BGP sessions specified by using the peer monitor-link group command are established in the BGP process specified by using the monitor bgp command, and none of these BGP sessions is in Established state, these BGP sessions are not considered as uplink interfaces, and only the BGP process is considered as an uplink interface.

For example, use the monitor bgp command to specify BGP instances aaa and bbb as two uplink interfaces in a monitor link group, use the peer monitor-link group command in BGP instance aaa to specify two BGP sessions as the uplink interfaces, and do not use the peer monitor-link group command in BGP instance bbb to specify uplink interfaces. In this case, when at least one of the two specified BGP sessions are in Established state, the monitor link group has three uplink interfaces in total, including two BGP sessions and one BGP process without BGP sessions specified. When neither of the two specified BGP sessions is in Established state, the monitor link group has two uplink interfaces in total. One uplink interface is the BGP process with BGP sessions specified but neither of the BGP sessions is in Established state. The other is the BGP process without BGP sessions specified.

· Downlink interfaces are defined as follows: In a monitor link group, an interface specified by using the port downlink or port monitor-link group downlink command is considered as a downlink interface.

· Uplink interfaces and downlink interfaces collaborate as follows:

¡ When the number of uplink interfaces in up state in a monitor link group is lower than the threshold configured by using the uplink up-port-threshold command, the physical state is set to down for all downlink interfaces in the monitor link group. An uplink interface is determined as up or down following these rules:

- For an interface specified by using the port uplink or port monitor-link group uplink command, the uplink interface is considered as up if the interface is physically up, and the uplink interface is considered as down if the interface is physically down.

- For a BGP process specified by using the monitor bgp command, the uplink interface is considered as up when the BGP instance exists and runs normally, and the uplink interface is considered as down when the BGP instance is deleted and the corresponding process exits.

- For a BGP session specified by using the peer monitor-link group command, the uplink interface is considered as up when the BGP session is in Established state, and the uplink interface is considered as down when the BGP session is in any other state.

¡ When the number of uplink interfaces in up state in a monitor link group is greater than or equal to the threshold configured by using the uplink up-port-threshold command, the physical state is set to up for all downlink interfaces in the monitor link group.

As shown in Figure 11, use Device B as an example. Configure the monitor link group as follows: Configure the BGP session between Device A and Device B as the only uplink interface of the monitor link group. Configure the interfaces connecting Device B to Device D and Device E as the downlink interfaces of the monitor link group. When the BGP session between Device A and Device B is disconnected, the physical interfaces connecting Device B to Device D and Device E go down physically. As a result, the BGP sessions from Device B to Device D and Device E are automatically disconnected, and you do not need to modify the BGP-related settings. When the BGP session between Device A and Device B restores to the Established state, the physical interfaces connecting Device B to Device D and Device E come up physically. As a result, the BGP sessions from Device B to Device D and Device E automatically recover, and you do not need to modify the BGP-related settings.

Figure 11 Schematic diagram for the BGP session state to collaborate with the monitor link downlink interfaces

For more information about monitor link, see monitor link configuration in High Availability Configuration Guide. For more information about the monitor bgp, monitor-link group, port, and port monitor-link group commands, see monitor link commands in High Availability Command Reference.

Restrictions and guidelines

To prevent BGP sessions flappings from causing frequent downlink switchovers in a monitor link group, execute the downlink up-delay command in the monitor link group to set the switchover delay for the downlink interfaces in the monitor link group.

For more information about the downlink up-delay command, see monitor link commands in High Availability Command Reference.

Procedure

1. Enter system view.

system-view

2. Create a monitor link group and enter its view.

monitor-link group group-id

For more information about this command, see monitor link commands in High Availability Command Reference.

3. Configure downlink interfaces for the monitor link group. Choose one of the following tasks:

¡ Configure downlink interfaces for the monitor link group in monitor link group view.

port interface-type { interface-number | interface-number.subnumber } downlink

¡ Execute the following commands in sequence to configure downlink interfaces for the monitor link group in interface view.

quit

interface interface-type { interface-number | interface-number.subnumber }

port monitor-link group group-id downlink

By default, a monitor link group does not have member ports.

For more information about these commands, see monitor link commands in High Availability Command Reference.

4. (Optional.) Configure the uplink interface threshold for triggering state switchover in the monitor link group.

uplink up-port-threshold number-of-port

By default, the uplink interface threshold for triggering state switchover in the monitor link group is 1.

This command is supported only in monitor link group view.

For more information about this command, see monitor link commands in High Availability Command Reference.

5. Return to system view.

quit

6. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view.

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

7. Configure the BGP session state to collaborate with the monitor link downlink interfaces.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } monitor-link group group-id

By default, the BGP session state does not collaborate with the monitor link downlink interfaces.

Setting the delay time for responding to recursive next hop changes

About this task

Next hop changes include the following types:

· Critical next hop changes—Changes that cause route unreachability and service interruption. For example, a BGP route cannot find a recursive next hop (a physical interface or tunnel interface) because of network failures.

· Noncritical next hop changes—A recursive or related route changes but the change does not cause route unreachability or service interruption. For example, the recursive next hop (a physical interface or tunnel interface) of a BGP route changes but traffic forwarding is not affected.

When recursive or related routes change frequently, configure this feature to reduce unnecessary path selection and update messages and prevent traffic loss.

Restrictions and guidelines

To avoid traffic loss, do not configure this feature if only one route is available to a specific destination.

Set an appropriate delay time based on your network condition. A short delay time cannot reduce unnecessary path selection or update messages, and a long delay time might cause traffic loss.

Procedure (IPv4 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Set the delay time for responding to recursive next hop changes.

nexthop recursive-lookup [ non-critical-event ] delay [ delay-value ]

By default, BGP responds to recursive next hop changes immediately.

Procedure (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Set the delay time for responding to recursive next hop changes.

nexthop recursive-lookup [ non-critical-event ] delay [ delay-value ]

By default, BGP responds to recursive next hop changes immediately.

Configuring route recursion suppression

About this task

BGP performs nexthop recursion for a BGP route to obtain a route or tunnel for real traffic forwarding. When the obtained route or tunnel changes, BGP performs nexthop recursion for the BGP route again. Upon frequent network flapping, BGP also performs route recursion repeatedly, which causes high CPU usage. To resolve this issue, configure BGP route recursion suppression. BGP can obtain the nexthop recursion result of a route only after the suppression timer expires. This feature helps reduce nexthop recursion frequency and CPU usage.

After you configure the suppression timer for BGP route recursion, the process of BGP route recursion is as follows:

Figure 12 BGP route recursion suppression

‌

BGP can obtain the nexthop recursion result of a route only after the suppression timer expires. BGP does not update the route recursion result unless the suppression timer expires. If the route recursion result of a BGP route changes later, BGP performs route recursion for that route again.

To dynamically suppress route recursion, configure the maximum suppression timer. If the route recursion results keep changing, the suppression time increases until the maximum suppression timer expires or the recursion results stop changing.

The calculation of dynamic suppression time (T) is based on the number of route recursions (N) as follows:

· When N is 1, T equals minimum-interval.

· When N is not less than 2, T equals minimum-interval + incremental-interval × [ 2 ^ ( N - 2 ) ], and T cannot exceed maximum-interval.

· When T reaches maximum-interval for three consecutive times, T equals minimum-interval and N is reset to 1 in the next recursion.

· If the recursion results remain unchanged within two times the maximum-interval, T equals minimum-interval and N is reset to 1 in the next recursion.

Restrictions and guidelines

· You can execute the nexthop recursive-lookup restrain command multiple times with different configurations to modify the suppression timer settings. However, only the most recent configuration can take effect. The suppression timer modification does not takes effect immediately. Instead, it takes effect on the next-round route recursion.

· The view in which you should execute the nexthop recursive-lookup restrain command varies by next hop location as follows:

¡ If the next hop of a BGP route is on the public network, execute this command in BGP instance view.

¡ If the next hop of a BGP route is on a VPN instance, execute this command in the BGP-VPN instance view of that VPN instance.

To determine the location of a next hop, perform the following task:

a. Execute the display ip routing-table verbose or display ipv6 routing-table verbose command, find the target BGP route in the command output, and then check the value of the NibID field.

b. Execute the display rib nib or display ipv6 rib nib command with the NIB ID obtained above, and then check the value of the VrfNthp field. This field displays index of the VPN instance to which a next hop belongs.

For more information about the following commands, see IP routing basics commands in Layer 3—IP Routing Command Reference:

¡ display ip routing-table verbose

¡ display ipv6 routing-table verbose

¡ display rib nib

¡ display ipv6 rib nib

· If you use the following commands together, BGP must wait the sum of the suppression timer and the delay timer before using the route recursion result for traffic forwarding:

¡ nexthop recursive-lookup restrain (in BGP instance view or BGP-VPN instance view)

¡ nexthop recursive-lookup delay

· Configuring this feature can result in low route recursion efficiency and slow route convergence. As a best practice, use this feature according to the network condition and make sure the suppression timer settings are appropriate.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Configure BGP route recursion suppression.

nexthop recursive-lookup restrain { maximum-interval [ minimum-interval [ incremental-interval ] ] | millisecond interval }

By default, BGP route recursion suppression is disabled.

The value for the minimum-interval or incremental-interval argument cannot be greater than that for the maximum-interval argument.

Specifying the longest match principle for next hop recursion

About this task

By default, BGP first looks up in its directly connected routes for a recursive route during a route recursion. If no matching routes exist, BGP will look up in routes generated by all routing protocols based on the longest match principle. The device considers the next hop of a received BGP route as directly connected when the next hop belongs to the same subnet as a direct route. As a result, packet forwarding failure will occur when the device uses this BGP route to forward matching packets.

As shown in Figure 13, Device B has established an IBGP session to Device A and Device C respectively. All devices use a loopback interface as the source port for TCP connection. On receipt of BGP route 8.0.0.0/24 from Device C, Device B reflects the route to Device A. The addresses of the interfaces that connect Device A and Device B belong to subnet 3.3.0.0/16.

If the next hop information exchanged between IBGP peers remains unchanged, the next hop of BGP route 8.0.0.0/24 is 3.3.3.3. Device A considers 3.3.3.3 as a directly connected next hop because 3.3.3.3 belongs to subnet 3.3.0.0/16 and a direct route to 3.3.0.0/16 exists. Packet forwarding failure will occur if Device A forwards packets destined for subnet 8.0.0.0/24 over 3.3.3.3.

Figure 13 Next hop recursion error

‌

To resolve this issue, you can specify the longest match principle for next hop recursion to ensure the recursive route is reachable. BGP will directly look up in routes generated by all routing protocols and select a matching route based on the longest match principle.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Specify the longest match principle for BGP next hop recursion.

nexthop recursive-lookup longest-match [ route-policy route-policy-name ]

By default, BGP first looks up in its directly connected routes for a recursive route during a route recursion.

This command applies to all BGP routes received from peers in one of the following scenarios:

¡ The route-policy route-policy-name option is not specified.

¡ The specified routing policy does not exist.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Specify the longest match principle for BGP next hop recursion.

nexthop recursive-lookup longest-match [ route-policy route-policy-name ]

By default, BGP first looks up in its directly connected routes for a recursive route during a route recursion.

This command applies to all BGP routes received from peers in one of the following scenarios:

¡ The route-policy route-policy-name option is not specified.

¡ The specified routing policy does not exist.

E nabling routing policy-based nexthop recursion

About this task

When BGP performs nexthop recursion for a route without any constraints, the route might be iterated to an incorrect traffic forwarding path. To resolve this issue, perform this task to enable routing policy-based nexthop recursion. BGP can then iterate routes to the desired forwarding paths under the constraints of the specified routing policy.

With this task performed, a BGP route can take effect only when some of its nexthop recursion results can match a permit node of the specified routing policy. If the recursion results of a route are all filtered out by the specified routing policy, the route is considered unreachable and cannot take effect.

To disable route recursion policy control for the routes received from a peer or peer group, use the peer nexthop-recursive-policy disable command. The nexthop recursive-lookup route-policy command and the protocol nexthop recursive-lookup command then does not take effect on the peer.

Restrictions and guidelines

· The nexthop recursive-lookup route-policy command does not take effect on the routes learned from directly-connected EBGP peers.

· When you execute the nexthop recursive-lookup route-policy command and the protocol nexthop recursive-lookup command, follow these restrictions and guidelines:

¡ If the following conditions exist, only the nexthop recursive-lookup route-policy command takes effect on the routes in a BGP address family:

- You execute t he nexthop recursive-lookup route-policy command in the view of the BGP address family.

- You execute the protocol nexthop recursive-lookup command in RIB IPv4 or IPv6 address family view.

¡ If the following conditions exist, BGP performs nexthop recursion for the routes in a BGP address family according to the configuration of the protocol nexthop recursive-lookup command in RIB IPv4 or IPv6 address family view:

- You do not execute the nexthop recursive-lookup route-policy command in the view of the BGP address family.

- You execute the protocol nexthop recursive-lookup command in RIB IPv4 or IPv6 address family view.

For more information about the protocol nexthop recursive-lookup command, see IP routing basics commands in Layer 3—IP Routing Command Reference.

Configuration tasks at a glance

· Enabling routing policy-based nexthop recursion (IPv4 unicast/multicast address family)

· Enabling routing policy-based nexthop recursion (IPv6 unicast/multicast address family)

· (Optional.) Disabling route recursion policy control for routes received from a peer or peer group

Enabling routing policy-based nexthop recursion (IPv4 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view, BGP-VPN IPv4 unicast address family view, or BGP IPv4 multicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP IPv4 multicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 multicast

3. Enable routing policy-based nexthop recursion.

nexthop recursive-lookup route-policy route-policy-name

By default, BGP does not perform routing policy-based nexthop recursion for routes.

CAUTION:

Before executing this command, make sure that BGP routes can be iterated to the desired paths under the constraints of the specified routing policy. If the recursion results of a BGP route are all filtered out by the specified routing policy, BGP considers the route unreachable.

‌

Enabling routing policy-based nexthop recursion (IPv6 unicast/multicast address family)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view, BGP-VPN IPv6 unicast address family view, or BGP IPv6 multicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP IPv6 multicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 multicast

3. Enable routing policy-based nexthop recursion.

nexthop recursive-lookup route-policy route-policy-name

By default, BGP does not perform routing policy-based nexthop recursion for routes.

CAUTION:

‌

(Optional.) Disabling route recursion policy control for routes received from a peer or peer group

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Disable route recursion policy control for routes received from the specified peer or peer group.

peer { group-name | ip-address [ mask-length ] | ipv6-address [ prefix-length ] } nexthop-recursive-policy disable

By default, the route recursion policy applies to routes received from the peer or peer group.

After you configure this command for a peer or peer group, the following commands then does not take effect on the peer or peer group:

¡ nexthop recursive-lookup route-policy

¡ protocol nexthop recursive-lookup

Configuring peer flap dampening

About this task

Perform this task to dampen a BGP peer when the peer state frequently changes between up and down. BGP increases the idle time of the peer each time the peer comes up until the maximum idle time is reached. To exit the dampened state, the peer must remain in Established state for a time period longer than the minimum established time. After the peer exits the dampened state, BGP resets the idle time of the peer when the peer comes up again.

Set a maximum idle time and a minimum established time based on your network condition.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Configure flap dampening for a peer or peer group.

peer { group-name | ipv4-address | ipv6-address } flap-dampen [ max-idle-time max-time | min-established-time min-time ]*

By default, flap dampening is disabled for all peers and peer groups.

Protecting an EBGP peer when memory usage reaches level 2 threshold

About this task

Memory usage includes the following threshold levels: normal, level 1, level 2, and level 3. When the level 2 threshold is reached, BGP periodically tears down an EBGP session to release memory resources until the memory usage falls below the level 2 threshold. You can configure this feature to avoid tearing down the EBGP session to an EBGP peer when the memory usage reaches the level 2 threshold.

For more information about memory usage thresholds, see device management configuration in Fundamentals Configuration Guide.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Configure BGP to protect an EBGP peer or peer group when the memory usage reaches level 2 threshold.

peer { group-name | ipv4-address [ mask-length ] } low-memory-exempt

By default, BGP periodically tears down an EBGP session to release memory resources when level 2 threshold is reached.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Configure BGP to protect an EBGP peer or peer group when the memory usage reaches level 2 threshold.

peer { group-name | ipv6-address [ prefix-length ] } low-memory-exempt

By default, BGP tears down an EBGP session to release memory resources periodically when level 2 threshold is reached.

Setting a DSCP value for outgoing BGP packets

About this task

The DSCP value of an IP packet specifies the priority level of the packet and affects the transmission priority of the packet.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Set a DSCP value for outgoing BGP packets.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } dscp dscp-value

By default, the DSCP value for outgoing BGP packets is 48.

Flushing the suboptimal BGP route to the RIB

About this task

This feature flushes the suboptimal BGP route to the RIB when the following conditions are met:

· The optimal route is generated by the network command or is redistributed by the import-route command.

· The suboptimal route is received from a BGP peer.

After the suboptimal route is flushed to the RIB on a network, BGP immediately switches traffic to the suboptimal route when the optimal route fails.

For example, the device has a static route to the subnet 1.1.1.0/24 that has a higher priority than a BGP route. BGP redistributes the static route and receives a route to 1.1.1.0/24 from a peer. After the flush suboptimal-route command is executed, BGP flushes the received BGP route to the RIB as the suboptimal route. When the static route fails, BGP immediately switches traffic to the suboptimal route if inter-protocol FRR is enabled. For more information about inter-protocol FRR, see "Configuring basic IP routing."

Procedure

1. Enter system view.

system-view

2. Enter BGP view.

bgp as-number [ instance instance-name ]

3. Flush the suboptimal BGP route to the RIB.

flush suboptimal-route

By default, BGP is disabled from flushing the suboptimal BGP route to the RIB, and only the optimal route is flushed to the RIB.

Configuring a peer monitoring group

About this task

A peer monitoring group is mainly used in traffic switchover scenarios. For example, when the local device receives mu ltiple BGP routes to the same destination from multiple BGP peers in AS 10 and AS 20, the traffic to that destination can be load shared between AS 10 and AS 20. If multiple BGP peers within AS 10 are disconnected from the local device, the network administrator might perceive a risk in the network status within AS 10 even if there are still running BGP sessions within the AS. The administrator might need to switch all traffic passing through AS 10 to other ASs. You can configure this feature to implement automatic traffic switchover in such scenarios.

Execute the monitor-group command to create a peer monitoring group, and then execute the peer monitor-group command to add shared-risk BGP peers to the group. The state of a BGP peer in a peer monitoring group depends on the state of the BGP session between the local device and that peer:

· If the BGP session is in Established state when you add the peer to the peer monitoring group, the peer is in UP state. If the BGP session is not in Established state, the peer is in INIT state.

· If the BGP session state transitions from INIT to Established after you add the peer to the peer monitoring group, the peer state will change to UP.

· If the BGP session state transitions from Established to another state, the peer state will change from UP to DOWN. This rule does not apply to the following scenarios where BGP configurations bring about BGP session state changes:

¡ The BGP session is terminated during a normal GR process. In this situation, the state of the BGP peer does not change in the peer monitoring group.

¡ The BGP session is terminated due to other BGP configurations (for example, the peer ignore command). In this situation, if the number of DOWN-state BGP peers in the peer monitoring group does not reach the specified threshold, the state of the disconnected peer will change to INIT. If the specified threshold is reached, the state of the disconnected peer remains DOWN.

When the number of DOWN-state BGP peers in the peer monitoring group reaches the specified threshold, the local device will disconnect from all BGP peers in the group to avoid potential traffic loss.

With the peer monitoring group feature configured, when the number of DOWN-state BGP peers reaches the specified threshold, the local device disconnects from all peers in the peer monitoring group. The local device will not proactively establish sessions to the devices in the group. To re-establish BGP sessions to the devices in the peer monitoring group, execute the reset monitor-group command. This command places the entire peer monitoring group in INIT state. The state of each normal BGP session will be restored to Established in the group, and the state of BGP peers corresponding to those BGP sessions will be restored to UP in the group.

Restrictions and guidelines

The number of BGP sessions in a peer monitoring group depends on the number of BGP peers in the group. Each BGP peer is counted as one BGP session, regardless of whether the peer has established sessions in multiple address families. The BGP sessions created by using the same IP address in different BGP-VPN instances and the public instance are considered as different sessions.

A BGP peer or peer group can be added to only one peer monitoring group.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create a peer monitoring group.

monitor-group monitor-group-name threshold number

By default, no peer monitoring groups exist.

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

ip vpn-instance vpn-instance-name

5. Add the specified peer or peer group to the peer monitoring group.

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

By default, a peer or peer group does not belong to any peer monitoring group.

6. (Optional.) Restore the normal sessions in the peer monitoring group.

reset bgp [ instance instance-name ] monitor-group monitor-group-name

Display and maintenance commands for peer monitoring group configuration

To display peer monitoring group information, execute the following command in any view:

display bgp [ instance instance-name ] monitor-group { all | group-name monitor-group-name }

D isabling BGP from flushing specific routes to the IP routing table

About this task

Perform this task to d isable BGP from flushing specific routes to the routing table.

This feature applies to the following scenarios:

· In an MPLS L3VPN network, all the optimal private BGP routes will be flushed to the routing table of a PE by default. You can configure this feature to prevent unnecessary routes from being flushed to the IP routing table and improve the forwarding performance of the PE.

· In a route reflection network, configure this feature to disable BGP from flushing specific routes to the IP routing table of the RR. Then, the RR only advertises and receives routes but does not forward service traffic, which saves the system resources of the RR.

Procedure (IPv4 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

3. Disable BGP from flushing specific routes to the IP routing table.

routing-table bgp-rib-only [ all ] [ route-policy route-policy-name ]

By default, BGP flushes the optimal routes to the IP routing table.

Procedure (IPv6 unicast)

1. Enter system view.

system-view

2. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

3. Disable BGP from flushing specific routes to the IP routing table.

routing-table bgp-rib-only [ all ] [ route-policy route-policy-name ]

By default, BGP flushes the optimal routes to the IP routing table.

Enabling peer unreachability detection

About this task

Peer unreachability detection enables BGP to discover link failures quickly. With this feature enabled, BGP will disconnect from the specified peer or peer group if that peer or peer group is detected unreachable.

BGP considers a peer unreachable if one of the following conditions exists:

· BGP cannot find a route to that peer in the routing table of the current public-network instance or VPN instance.

· BGP finds the route to that peer in the routing table of the current public-network instance or VPN instance is a blackhole route.

Restrictions and guidelines

If you do not set the delay time of peer disconnection, BGP disconnects from the specified peer or peer group immediately if that peer or peer group is detected unreachable.

When you set the delay time of peer disconnection, follow these guidelines to improve network stability:

· To avoid BGP session flappings caused by unstable traffic, make sure the delay time of peer disconnection is longer than the convergence time of IGP routes.

· With peer unreachability detection enabled, the GR helper can detect whether the GR restarter is reachable. To ensure successful GR, make sure the delay time of peer disconnection is longer than the GR timer plus the extra timer to wait.

For more information about the GR timer and the extra timer to wait, see "Configuring BGP GR."

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Enter BGP-VPN instance view.

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable peer unreachability detection for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } tracking [ delay delay-time ]

By default, peer unreachability detection is disabled.

This command does not take effect if you enter a link-local address for the ipv6-address argument.

Enabling fast host route update upon user migration

About this task

As shown in Figure 14, the host roams between AP 1 and AP 2 frequently, and both Device A and Device C save the host route. The host route entries on Device A and Device C are not updated in real time, so traffic forwarding might be affected. To resolve this issue, perform this task to enable fast host route update upon user migration.

Figure 14 Network diagram

‌

As shown in Figure 14, after you enable fast host route update upon user migration on Device A and Device C, Device A and Device C process the host route as follows:

1. When the host comes online on AP 1 for the first time, Device A generates a route for the host and advertises the route to Device C through Device B.

2. When the host roams to AP 2, Device C generates a route for the host, and it has two routes for the host. In this case, BGP selects the locally generated route as the optimal route, increases the host migration serial number by one, and then advertises the optimal route to Device A through Device B.

3. After receiving the host route advertised by Device C, Device B compares the host migration serial number carried in the routes advertised by Device C and Device A. Device B selects the route with the larger host migration serial number as the optimal route and advertises the optimal route to Device A.

4. After receiving the host route from Device B, Device A checks whether the ARP or ND entry corresponding to the received route exists. If the ARP or ND entry does not exist, Device A deletes the local ARP or ND entry and the direct route, and then advertises the received route to all peers. If the ARP or ND entry exists, Device A determines that the host has migrated to it. Then, Device A takes the following actions:

a. Compares the host migration serial number in the received route with that in the local host route.

b. Increases the larger host migration serial number by one.

c. Advertises the local route with the new host migration serial number to its peers.

When the host roams frequently, devices in the network might receive host routes with the same host migration serial number. In this case, a device selects the optimal route as follows:

· When the device receives multiple host routes with the same serial number, it selects the route received from the peer with the smallest route ID as the optimal route.

· When the device receives a host route with the same serial number as that in the local host route, it selects the optimal route based on the ARP or ND entry, as described in step 4.

Host migration serial numbers are advertised through the extended community attribute. Enabling this feature also enables BGP to advertise the extended community attribute to all peers and peer groups.

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 fast host route update upon user migration.

user-move fast-update

By default, fast host route update upon user migration 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 fast host route update upon user migration.

user-move fast-update

By default, fast host route update upon user migration is disabled.

E nabling conversational remote host route learning

About this task

By default, BGP generates FIB entries for all host routes received from peers (remote host routes) and issues the routes to the FIB. To conserve device resources, you can enable conversational remote host route learning. This feature enables BGP to issue a remote host route to the FIB only if it is required for forwarding a packet.

Restrictions and guidelines

This feature takes effect only on remote host routes generated based on ARP or ND entries and does not take effect on local host routes and other BGP routes. Host routes generated based on ARP or ND entries carry a special mark advertised through the extended community attribute. Enabling this feature also enables BGP to advertise the extended community attribute to all peers and peer groups.

This feature takes effect only when you execute the ip forwarding-conversational-learning command. For more information about this command, see EVPN commands in EVPN Command Reference.

The device can perform conversational learning for a remote host route only if a local interface belongs to a network segment that contains the destination address of the host route.

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 conversational remote host route learning.

forwarding-conversational-learning [ route-policy route-policy-name ]

By default, conversational remote host route learning 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 conversational remote host route learning.

forwarding-conversational-learning [ route-policy route-policy-name ]

By default, conversational remote host route learning is disabled.

Resetting BGP sessions

About this task

A reset operation terminates and re-establishes BGP sessions in order to validate configuration changes and update routing information.

Restrictions and guidelines

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

Procedure

Perform reset tasks in user view.

· Resets BGP sessions for the IPv4 unicast address family.

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

reset bgp [ instance instance-name ] ipv6-address [ prefix-length ] ipv4 [ unicast ] [ vpn-instance vpn-instance-name ]

· Resets BGP sessions for the IPv4 multicast address family.

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

· Resets BGP sessions for the IPv6 unicast address family.

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

reset bgp ipv4-address [ mask-length ] ipv6 [ unicast ] [ vpn-instance vpn-instance-name ]

· Resets all BGP sessions.

reset bgp [ instance instance-name ] all

For more information about the reset commands, see Basic BGP commands in Layer 3—IP Routing Command Reference.

BGP network tuning and optimization configuration examples

Example: Configuring BGP load balancing

Network configuration

As shown in Figure 15, run EBGP between Switch A and Switch B, and between Switch A and Switch C. Run IBGP between Switch B and Switch C.

Figure 15 Network diagram

‌

Procedure

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

2. Configure BGP connections:

¡ On Switch A, establish EBGP connections with Switch B and Switch C. Configure BGP to advertise network 8.1.1.0/24 to Switch B and Switch C, so that Switch B and Switch C can access the internal network connected to Switch A. Configure load balancing over the two EBGP links on Switch A.

¡ On Switch B, establish an EBGP connection with Switch A and an IBGP connection with Switch C. Configure BGP to advertise network 9.1.1.0/24 to Switch A, so that Switch A can access the intranet through Switch B. Configure a static route to interface loopback 0 on Switch C (or use a routing protocol like OSPF) to establish the IBGP connection.

¡ On Switch C, establish an EBGP connection with Switch A and an IBGP connection with Switch B. Configure BGP to advertise network 9.1.1.0/24 to Switch A, so that Switch A can access the intranet through Switch C. Configure a static route to interface loopback 0 on Switch B (or use another protocol like OSPF) to establish the IBGP connection.

# 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] peer 3.1.2.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] peer 3.1.2.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> system-view

[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] 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.1.1.2 enable

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

[SwitchB-bgp-default-ipv4] network 9.1.1.0 24

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

[SwitchB] ip route-static 3.3.3.3 32 9.1.1.2

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 3.1.2.2 as-number 65008

[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 3.1.2.2 enable

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

[SwitchC-bgp-default-ipv4] network 9.1.1.0 24

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

[SwitchC] ip route-static 2.2.2.2 32 9.1.1.1

# 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

* > 8.1.1.0/24 8.1.1.1 0 32768 i

* >e 9.1.1.0/24 3.1.1.1 0 0 65009i

* e 3.1.2.1 0 0 65009i

¡ The output shows two valid routes to destination 9.1.1.0/24. The route with next hop 3.1.1.1 is marked with a greater-than sign (>), indicating that it is the optimal route (because the ID of Switch B is smaller). The route with next hop 3.1.2.1 is marked with an asterisk (*), indicating that it is a valid route, but not the optimal route.

¡ By using the display ip routing-table command, you can find only one route to 9.1.1.0/24 with next hop 3.1.1.1 and output interface VLAN-interface 200.

3. Configure loading balancing:

Because Switch A has two routes to reach AS 65009, configuring load balancing over the two BGP routes on Switch A can improve link usage.

# Configure Switch A.

[SwitchA] bgp 65008

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

[SwitchA-bgp-default-ipv4] balance 2

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

Verifying the configuration

# 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

* > 8.1.1.0/24 8.1.1.1 0 32768 i

* >e 9.1.1.0/24 3.1.1.1 0 0 65009i

* >e 3.1.2.1 0 0 65009i

· The route 9.1.1.0/24 has two next hops, 3.1.1.1 and 3.1.2.1, both of which are marked with a greater-than sign (>), indicating that they are the optimal routes.

· By using the display ip routing-table command, you can find two routes to 9.1.1.0/24. One has next hop 3.1.1.1 and output interface VLAN-interface 200, and the other has next hop 3.1.2.1 and output interface VLAN-interface 300.

Example: Configuring the BGP Additional Paths feature

Network configuration

As shown in Figure 16, 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, between Switch C and Switch D, and between Switch D and Switch E. Switch D is a route reflector and Switch E is its client.

Configure the BGP Additional Paths feature to enable Switch E to learn routes with the same prefix and different next hops from Switch B and Switch C.

Figure 16 Network diagram

‌

Table 1 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	10.1.1.1/24	Switch D	Vlan-int300	30.1.1.1/24
	Vlan-int200	20.1.1.1/24		Vlan-int400	40.1.1.1/24
Switch B	Vlan-int100	10.1.1.2/24		Vlan-int500	50.1.1.1/24
	Vlan-int300	30.1.1.2/24	Switch E	Vlan-int500	50.1.1.2/24
Switch C	Vlan-int200	20.1.1.2/24
	Vlan-int400	40.1.1.2/24

‌

Procedure

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

2. Configure BGP connections:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 10

[SwitchA-bgp-default] peer 10.1.1.2 as-number 20

[SwitchA-bgp-default] peer 20.1.1.2 as-number 20

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

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

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

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 20

[SwitchB-bgp-default] peer 10.1.1.1 as-number 10

[SwitchB-bgp-default] peer 30.1.1.1 as-number 20

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

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

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

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 20

[SwitchC-bgp-default] peer 20.1.1.1 as-number 10

[SwitchC-bgp-default] peer 40.1.1.1 as-number 20

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

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

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

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 20

[SwitchD-bgp-default] peer 30.1.1.2 as-number 20

[SwitchD-bgp-default] peer 40.1.1.2 as-number 20

[SwitchD-bgp-default] peer 50.1.1.2 as-number 20

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

[SwitchD-bgp-default-ipv4] peer 30.1.1.2 enable

[SwitchD-bgp-default-ipv4] peer 40.1.1.2 enable

[SwitchD-bgp-default-ipv4] peer 50.1.1.2 enable

# Configure Switch E.

<SwitchE> system-view

[SwitchE] bgp 20

[SwitchE-bgp-default] peer 50.1.1.1 as-number 20

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

[SwitchE-bgp-default-ipv4] peer 50.1.1.1 enable

3. Configure Switch A to advertise network 10.1.1.0/24.

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

4. Set the local switch as the next hop for routes sent to a peer:

# Configure Switch B.

[SwitchB-bgp-default-ipv4] peer 30.1.1.1 next-hop-local

# Configure Switch C.

[SwitchC-bgp-default-ipv4] peer 40.1.1.1 next-hop-local

5. Configure Switch D as a route reflector.

[SwitchD-bgp-default-ipv4] peer 50.1.1.2 reflect-client

6. Configure the Additional Paths feature:

# Enable the additional path sending capability on Switch D.

[SwitchD-bgp-default-ipv4] peer 50.1.1.2 additional-paths send

# Set the maximum number to 2 for Add-Path optimal routes that can be advertised.

[SwitchD-bgp-default-ipv4] additional-paths select-best 2

# Set the maximum number to 2 for Add-Path optimal routes that can be advertised to peer 50.1.1.2.

[SwitchD-bgp-default-ipv4] peer 50.1.1.2 advertise additional-paths best 2

# Enable the additional path receiving capability on Switch E.

[SwitchE-bgp-default-ipv4] peer 50.1.1.1 additional-paths receive

Verifying the configuration

# Display BGP routing information on Switch E.

[Switch E] display bgp routing-table ipv4

Total number of routes: 2

BGP local Switch ID is 50.1.1.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 10.1.1.0/24 30.1.1.2 0 100 0 10i

i 40.1.1.2 0 100 0 10i

The output shows that Switch D has learned two routes with the same prefix and different next hops.

Configuring BGP security features

Enabling MD5 authentication for BGP peers

About this task

MD5 authentication provides the following benefits:

· Peer authentication ensures that only BGP peers that have the same password can establish TCP connections.

· Integrity check ensures that BGP packets exchanged between peers are intact.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable MD5 authentication for a BGP peer group or peer.

peer { group-name | ipv4-address [ mask-length ] } password { cipher | simple } password

By default, MD5 authentication is disabled.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable MD5 authentication for a BGP peer group or peer.

peer { group-name | ipv6-address [ prefix-length ] } password { cipher | simple } password

By default, MD5 authentication is disabled.

Improving BGP network reliability

BGP network reliability improvement tasks at a glance

To improve the BGP network reliability, perform the following tasks:

· Configuring BGP GR

· Configuring BFD for BGP

· Configuring BGP FRR

· Configuring BGP maintenance features

¡ Configuring BGP isolation

¡ Configuring BGP shutdown

Configuring BGP GR

About this task

Graceful Restart (GR) ensures forwarding continuous when a routing protocol restarts or an active/standby switchover occurs. Two routers are required to complete a GR process. The following are router roles in a GR process:

· GR restarter—Performs GR upon a BGP restart or active/standby switchover.

· GR helper—Helps the GR restarter to complete the GR process.

A device can act as a GR restarter and GR helper at the same time.

BGP GR works as follows:

1. The BGP GR restarter and helper exchange OPEN messages for GR capability negotiation. If both parties have the GR capability, they establish a GR-capable session. The GR restarter sends the GR timer set by the graceful-restart timer restart command to the GR helper in an OPEN message.

2. When an active/standby switchover occurs or BGP restarts, the GR restarter does not remove existing BGP routes from Routing Information Base (RIB) and Forwarding Information Base (FIB). It still uses these routes for packet forwarding, and it starts the RIB purge timer (set by the graceful-restart timer purge-time command). The GR helper marks all routes learned from the GR restarter as stale instead of deleting them. It continues to use these routes for packet forwarding. During the GR process, packet forwarding is not interrupted.

3. After the active/standby switchover or BGP restart completes, the GR restarter re-establishes a BGP session to the GR helper. If the BGP session fails to be established after both the GR timer and the extra timer to wait expire, the GR helper removes the stale routes. To set the extra timer to wait after the restart timer expires, execute the peer graceful-restart timer restart extra command.

4. If the BGP session is established, routing information is exchanged for the GR restarter to retrieve route entries and for the GR helper to recover stale routes.

5. Both the GR restarter and the GR helper start the End-Of-RIB marker waiting timer.

The End-Of-RIB marker waiting time is set by the graceful-restart timer wait-for-rib command.

¡ If routing information exchange is completed within the waiting timer, the GR restarter and the GR helper act as follows:

- The GR restarter updates its routing table with learned BGP routes, removes the aged routes from the RIB, and quits the GR process.

- The GR helper removes the stale routes and quits the GR process.

¡ If routing information exchange is not completed within the waiting timer, the GR restarter and the GR helper act as follows:

- The GR restarter updates the RIB with the BGP routes already learned, removes the aged routes from the RIB, and quits the GR process.

- The GR helper removes the stale routes and quits the GR process.

The End-Of-RIB marker is an update message that does not contain any NLRI or withdrawn NLRI. After the GR restarter and the GR helper complete route exchange, they additionally send an End-Of-RIB marker to each other. The marker indicates the end of route updates.

6. The GR restarter quits the GR process if routing information exchange is not completed within the RIB purge timer. It updates the RIB with the BGP routes already learned, and removes the aged routes.

When the TCP connection goes down, the hold timer expires, or the address families supporting route exchange change, BGP tears down and then re-establishes the peer sessions, which will cause traffic interruption. To avoid traffic interruption in these cases, enable BGP to reset peer sessions gracefully.

Restrictions and guidelines

Follow these guidelines when you configure BGP GR:

· The maximum time to wait for the End-of-RIB marker configured on the local end is not advertised to the peer. It controls the time for the local end to receive updates from the peer. Set a large value for the maximum time to wait for the End-of-RIB marker when a large number of routes need to be exchanged. When you use the peer graceful-restart timer restart extra command, you can specify the no-limit keyword. In this situation, the GR helper does not start the End-of-RIB marker waiting timer after BGP session re-establishment and keeps waiting for the End-of-RIB marker from the GR restarter.

· As a best practice, perform the BGP GR configuration on both the GR restarter and GR helper.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable GR capability for BGP.

graceful-restart

By default, GR capability is disabled for BGP.

4. Configure the GR timer.

graceful-restart timer restart timer

The default setting is 150 seconds.

The time that a peer waits to re-establish a session must be less than the hold time.

5. (Optional.) Set the extra time to wait after the restart timer expires.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } graceful-restart timer restart extra { time | no-limit }

By default, the extra time to wait after the restart timer expires is 0 seconds.

6. Configure the maximum time to wait for the End-of-RIB marker.

graceful-restart timer wait-for-rib timer

The default setting is 600 seconds.

7. Configure the RIB purge timer.

graceful-restart timer purge-time timer

The default setting is 480 seconds.

8. (Optional.) Enable BGP to reset peer sessions gracefully.

graceful-restart peer-reset [ all ]

By default, BGP does not reset peer sessions gracefully.

9. (Optional.) Configure the time that BGP must wait for other protocols to complete GR after BGP completes GR.

bgp update-delay wait-other-protocol seconds

By default, after BGP completes GR, it must wait a maximum of 300 seconds for other protocols to complete GR.

Configuring BFD for BGP

About this task

BGP maintains neighbor relationships based on the keepalive timer and hold timer in seconds. It requires that the hold time must be at least three times the keepalive interval. This mechanism slows down link failure detection. Once a failure occurs on a high-speed link, a large quantity of packets will be dropped before routing convergence completes. BFD for BGP can solve this problem by fast detecting link failures to reduce convergence time.

Before you enable BFD for a BGP peer or peer group, you must establish a BGP session between the local router and the peer or peer group.

For more information about BFD, see High Availability Configuration Guide.

Restrictions and guidelines

Follow these restrictions and guidelines when you configure echo packet mode BFD:

· Echo packet mode BFD is applicable only to directly connected BGP peers.

· Echo packet mode BFD is not applicable to the BGP peers established by using loopback interfaces.

· For successful BFD session establishment, make sure a source address has been specified for echo packets by using the bfd echo-source-ip or bfd echo-source-ipv6 command.

To detect the link to a BGP peer established through link-local addresses, you must configure single-hop BFD in control packet mode.

To establish a control packet mode BFD session to a BGP peer, you must configure the same BFD detection mode (multi-hop or single-hop) on the local device and the BGP peer.

If you have enabled GR, use BFD with caution because BFD might detect a failure before the system performs GR, which will result in GR failure. If you have enabled both BFD and GR for BGP, do not disable BFD during a GR process to avoid GR failure.

When you configure BFD parameters for a BGP peer or peer group, follow these restrictions and guidelines:

· When you add a peer to a peer group, the peer will inherit the BFD settings of the peer group.

· When you configure BFD parameters for a peer group, the configuration takes effect on all peers in the peer group.

· If you configure a BFD parameter multiple times for a peer or peer group, the most recent configuration takes effect.

For a BGP peer, the most recent configuration of a BFD parameter takes effect regardless of the configuration source.

Procedure (IPv4 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BFD to detect the link to the specified BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } bfd [ echo | multi-hop | single-hop ]

By default, BFD is disabled.

4. (Optional.) Configure BFD parameters for the specified BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } bfd parameters { detect-multiplier detect-multiplier | min-receive-interval min-receive-interval | min-transmit-interval min-transmit-interval } *

By default, no BFD parameters are configured for a peer or peer group.

Procedure (IPv6 peers)

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enable BFD to detect the link to the specified IPv6 BGP peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } bfd [ echo | multi-hop | single-hop ]

By default, BFD is disabled.

4. (Optional.) Configure BFD parameters for the specified BGP peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } bfd parameters { detect-multiplier detect-multiplier | min-receive-interval min-receive-interval | min-transmit-interval min-transmit-interval } *

By default, no BFD parameters are configured for a peer or peer group.

Configuring BGP FRR

About BGP FRR

When a link fails, the packets on the link are discarded, and a routing loop might occur until BGP completes routing convergence based on the new network topology.

You can enable BGP fast reroute (FRR) to resolve this issue.

Figure 17 Network diagram for BGP FRR

‌

After you configure FRR on Router B as shown in Figure 17, BGP generates a backup next hop Router C for the primary route. BGP uses ARP or BFD echo packet mode in an IPv4 network or ND in an IPv6 network to detect the connectivity to Router D. When the link to Router D fails, BGP directs packets to the backup next hop. At the same time, BGP calculates a new optimal route, and forwards packets over the optimal route.

You can use the following methods to configure BGP FRR:

· Method 1—Execute the pic command in BGP address family view. BGP calculates a backup next hop for each BGP route in the address family if there are two or more unequal-cost routes that reach the destination.

· Method 2—Execute the fast-reroute route-policy command to use a routing policy in which a backup next hop is specified by using the command apply [ ipv6 ] fast-reroute backup-nexthop. The backup next hop calculated by BGP must be the same as the specified backup next hop. Otherwise, BGP does not generate a backup next hop for the primary route. You can also configure if-match clauses in the routing policy to identify the routes protected by FRR.

If both methods are configured, Method 2 takes precedence over Method 1.

BGP supports FRR for IPv4 and IPv6 unicast routes, but not for IPv4 and IPv6 multicast routes.

This feature can calculate a shared backup next hop for ECMP BGP routes with the same prefix only if the following conditions exist:

· Both the balance and pic commands are configured.

· The maximum number of BGP ECMP routes configured in the balance command is greater than 1.

· The number of ECMP BGP routes with the same prefix is greater than 1, but does not reach the upper limit.

· The routing table also contains other valid BGP routes with the same prefix as the previous ECMP BGP routes.

Configuring BGP FRR by using a routing policy (IPv4 unicast address family)

1. Enter system view.

system-view

2. Configure the source address of echo packets.

bfd echo-source-ip ipv4-address

By default, no source address is specified for echo packets.

This step is required when BFD echo packet mode is used to detect the connectivity to the next hop of the primary route.

Specify a source IP address that does not belong to any local network.

For more information about this command, see BFD commands in High Availability Command Reference.

3. Create a routing policy and enter routing policy view.

route-policy route-policy-name permit node node-number

For more information about this command, see routing policy commands in Layer 3—IP Routing Command Reference.

4. Set the backup next hop for FRR.

apply fast-reroute backup-nexthop ipv4-address

By default, no backup next hop is set.

For more information about this command, see routing policy commands in Layer 3—IP Routing Command Reference.

5. Return to system view.

quit

6. Enter BGP instance view.

bgp as-number [ instance instance-name ]

7. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

¡ Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

8. Apply a routing policy to FRR for the address family.

fast-reroute route-policy route-policy-name

By default, no routing policy is applied.

The apply fast-reroute backup-nexthop command and apply ipv6 fast-reroute backup-nexthop command can take effect in the applied routing policy. Other apply commands do not take effect.

Configuring BGP FRR by using a routing policy (IPv6 unicast address family)

1. Enter system view.

system-view

2. Create a routing policy and enter routing policy view.

route-policy route-policy-name permit node node-number

For more information about this command, see routing policy commands in Layer 3—IP Routing Command Reference.

3. Set the backup next hop for FRR.

apply ipv6 fast-reroute backup-nexthop ipv6-address

By default, no backup next hop is set.

For more information about this command, see routing policy commands in Layer 3—IP Routing Command Reference.

4. Return to system view.

quit

5. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

6. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

address-family ipv6 [ unicast ]

7. Apply a routing policy to FRR for the address family.

fast-reroute route-policy route-policy-name

By default, no routing policy is applied.

The apply fast-reroute backup-nexthop and apply ipv6 fast-reroute backup-nexthop commands can take effect in the applied routing policy. Other apply commands do not take effect.

Configuring BGP FRR through PIC (IPv4 unicast address family)

Restrictions and guidelines

This feature might result in routing loops. Use it with caution.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enter BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

4. Enable BGP FRR through PIC.

pic

By default, BGP FRR is disabled.

Configuring BGP FRR through PIC (IPv6 unicast address family)

Restrictions and guidelines

This feature might result in routing loops. Use it with caution.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. Enter BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable BGP FRR through PIC.

pic

By default, BGP FRR is disabled.

Configuring BFD-powered nexthop connectivity detection for BGP FRR

About this task

By default, BGP FRR uses ARP to detect next hop connectivity for the primary route. This method is not efficient at detecting the failure of the primary route. As a result, data loss might occur when the primary route fails, because the backup path might not take over to forward traffic in time. To resolve this issue, enable BFD-powered nexthop connectivity detection for BGP FRR. This feature enables BGP to create an IP FRR BFD session that detects next hop connectivity for the primary route. This can speed up primary and backup route switchover when the next hop of the primary route fails.

Restrictions and guidelines

This feature takes effect and creates an IP FRR BFD session only when the primary route has a backup next hop.

BGP does not support backup next hop calculation for the routes used for load balancing. This command cannot take effect when the primary route is an equal-cost route. To enable BFD-based next hop detection for equal-cost routes, use the primary-path-detect bfd protocol-ecmp bgp command or the primary-path-detect bfd protocol-ecmp bgp4+ command. For more information about the two commands, see IP routing basics configuration in Layer 3—IP Routing Command Reference.

BGP can establish a control-mode BFD session with a peer only after negotiation. To use control-mode BFD to detect the next hop of the primary link, perform one of the following tasks:

· Configure the primary-path-detect bfd command on the peer device in the primary link.

This task is applicable when both ends of the primary link are configured with FRR.

· Manually configure a static BFD session that uses the following settings on the peer device in the primary link:

¡ Source IP address: Destination IP address of the BFD session automatically created on the local device in the primary link.

¡ Destination IP address: Source IP address of the BFD session automatically created on the local device in the primary link.

¡ Remote ID: Local ID of the BFD session automatically created on the local device in the primary link.

When you configure echo-mode BFD for nexthop connectivity detection, you only need to configure this feature on the local router.

When another routing protocol (such as RIB, OSPF, or IS-IS) uses BFD to detect next hop connectivity for the primary route, it also creates a BFD session. If the detected link is the same as the link attached to the next hop of the BGP primary route, BGP reuses the BFD session created by the protocol. In this situation, BGP will not create an additional BFD session.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. (Optional.) Enable BFD-powered nexthop connectivity detection for BGP FRR.

primary-path-detect bfd { ctrl | echo }

By default, BGP FRR uses ARP to detect nexthop connectivity for the primary route.

Configuring BGP maintenance features

About BGP isolation and BGP shutdown

For maintenance purposes, you can use either BGP isolation or BGP shutdown to remove the device from the network. The device will not be used for forwarding traffic from its peers after they reselect an optimal route. Both BGP isolation and BGP shutdown retain the device configuration to reduce maintenance cost.

After maintenance, you can disable BGP isolation or BGP shutdown to add the device back to the network.

Configuring BGP isolation

About this task

To maintain a BGP network device, you can use BGP isolation to remove the device from the network. This feature reduces configuration cost and impact on the network by retaining the device configuration during the maintenance. After maintenance, you can disable BGP isolation to add the device back to the network.

BGP isolation works as follows:

1. BGP withdraws all routes advertised by the device except for the directly-connected routes.

2. BGP keeps all routes learned from its peers.

3. Each peer of the device reselects an optimal route and updates the FIB table. During optimal route selection, the peers can still use the routes advertised by the device to forward traffic.

4. After an optimal route is selected and the FIB table is updated, the peers stop forwarding packets except for those destined for the device to the device. The device is fully isolated from the network and you can upgrade it.

5. After the maintenance, disable BGP isolation on the device to gracefully add it back to the network. After returning to the network, the device advertises and learns routes as follows:

¡ Advertises routes to its peers.

¡ Learns routes if BGP was reset during the isolation.

Restrictions and guidelines

To avoid isolation failure, do not use this feature when GR or NSR is enabled for the device.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP isolation to gracefully remove the device from the network.

isolate enable

By default, BGP isolation is disabled.

4. Disable BGP isolation to gracefully add the device to the network.

undo isolate enable

Configuring BGP shutdown

About this task

For maintenance purposes, you can use this feature to temporarily disconnect BGP sessions from all peers and peer groups. After maintenance, you can disable this feature to restore these sessions.

Restrictions and guidelines

With this feature enabled, the device tears down all sessions and clears all routing information.

When you configure the shutdown process command together with the peer ignore or ignore all-peers command, follow these restrictions and guidelines:

· Once BGP shutdown is enabled by the shutdown process command, the device cannot establish BGP sessions with all peers and peer groups.

· To disable BGP session establishment with a peer or peer group if you have disabled BGP shutdown, perform one of the following tasks:

¡ Disable BGP session establishment with that peer or peer group by using the peer ignore command.

¡ Disable BGP session establishment with all peers and peer groups by using the ignore all-peers command.

For more information about disabling BGP session establishment, see "Disabling BGP session establishment."

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Shut down BGP sessions to all peers and peer groups.

shutdown process

By default, BGP does not shut down sessions to any peers or peer groups.

4. Restore the BGP sessions to add the device back to the network.

undo shutdown process

IPv4 BGP network reliability improvement configuration examples

Example: Configuring BGP GR

Network configuration

As shown in Figure 18, all switches run BGP. EBGP runs between Switch A and Switch B. IBGP runs between Switch B and Switch C.

Enable GR capability for BGP so that the communication between Switch A and Switch C is not affected when an active/standby switchover occurs on Switch B.

Figure 18 Network diagram

‌

Procedure

1. Configure Switch A:

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

# Configure the EBGP connection.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp-default] router-id 1.1.1.1

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

# Enable GR capability for BGP.

[SwitchA-bgp-default] graceful-restart

# Inject network 8.0.0.0/8 to the BGP routing table.

[SwitchA-bgp-default] address-family ipv4

[SwitchA-bgp-default-ipv4] network 8.0.0.0

# Enable Switch A to exchange IPv4 unicast routing information with Switch B.

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

2. Configure Switch B:

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

# Configure the EBGP connection.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp-default] router-id 2.2.2.2

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

# Configure the IBGP connection.

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

# Enable GR capability for BGP.

[SwitchB-bgp-default] graceful-restart

# Inject networks 200.1.1.0/24 and 9.1.1.0/24 to the BGP routing table.

[SwitchB-bgp-default] address-family ipv4

[SwitchB-bgp-default-ipv4] network 200.1.1.0 24

[SwitchB-bgp-default-ipv4] network 9.1.1.0 24

# Enable Switch B to exchange IPv4 unicast routing information with Switch A and Switch C.

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

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

3. Configure Switch C:

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

# Configure the IBGP connection.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp-default] router-id 3.3.3.3

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

# Enable GR capability for BGP.

[SwitchC-bgp-default] graceful-restart

# Enable Switch C to exchange IPv4 unicast routing information with Switch B.

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

Verifying the configuration

Ping Switch C on Switch A. Meanwhile, perform an active/standby switchover on Switch B. The ping operation is successful during the whole switchover process. (Details not shown.)

Example: Configuring BFD for BGP

Network configuration

As shown in Figure 19, configure OSPF as the IGP in AS 200.

· Establish two IBGP connections between Switch A and Switch C. When both paths operate correctly, Switch C uses the path Switch A<—>Switch B<—>Switch C to exchange packets with network 1.1.1.0/24.

· Configure BFD over the path. When the path fails, BFD can quickly detect the failure and notify it to BGP. Then, the path Switch A<—>Switch D<—>Switch C takes effect immediately.

Figure 19 Network diagram

‌

Table 2 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	3.0.1.1/24	Switch C	Vlan-int101	3.0.2.2/24
	Vlan-int200	2.0.1.1/24		Vlan-int201	2.0.2.2/24
Switch B	Vlan-int100	3.0.1.2/24	Switch D	Vlan-int200	2.0.1.2/24
	Vlan-int101	3.0.2.1/24		Vlan-int201	2.0.2.1/24

‌

Procedure

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

2. Configure OSPF to ensure that Switch A and Switch C are reachable to each other. (Details not shown.)

3. Configure BGP on Switch A:

# Establish two IBGP connections to Switch C.

<SwitchA> system-view

[SwitchA] bgp 200

[SwitchA-bgp-default] peer 3.0.2.2 as-number 200

[SwitchA-bgp-default] peer 2.0.2.2 as-number 200

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

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

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

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Create IPv4 basic ACL 2000 to permit 1.1.1.0/24 to pass.

[SwitchA] acl basic 2000

[SwitchA-acl-ipv4-basic-2000] rule permit source 1.1.1.0 0.0.0.255

[SwitchA-acl-ipv4-basic-2000] quit

# Create two routing policies to set the MED for route 1.1.1.0/24. The policy apply_med_50 sets the MED to 50, and the policy apply_med_100 sets the MED to 100.

[SwitchA] route-policy apply_med_50 permit node 10

[SwitchA-route-policy-apply_med_50-10] if-match ip address acl 2000

[SwitchA-route-policy-apply_med_50-10] apply cost 50

[SwitchA-route-policy-apply_med_50-10] quit

[SwitchA] route-policy apply_med_100 permit node 10

[SwitchA-route-policy-apply_med_100-10] if-match ip address acl 2000

[SwitchA-route-policy-apply_med_100-10] apply cost 100

[SwitchA-route-policy-apply_med_100-10] quit

# Apply routing policy apply_med_50 to routes outgoing to peer 3.0.2.2, and apply routing policy apply_med_100 to routes outgoing to peer 2.0.2.2.

[SwitchA] bgp 200

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

[SwitchA-bgp-default-ipv4] peer 3.0.2.2 route-policy apply_med_50 export

[SwitchA-bgp-default-ipv4] peer 2.0.2.2 route-policy apply_med_100 export

[SwitchA-bgp-default-ipv4] quit

# Enable BFD for peer 3.0.2.2.

[SwitchA-bgp-default] peer 3.0.2.2 bfd

[SwitchA-bgp-default] quit

4. Configure BGP on Switch C:

# Establish two IBGP connections to Switch A.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp-default] peer 3.0.1.1 as-number 200

[SwitchC-bgp-default] peer 2.0.1.1 as-number 200

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

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

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

[SwitchC-bgp-default-ipv4] quit

# Enable BFD for peer 3.0.1.1.

[SwitchC-bgp-default] peer 3.0.1.1 bfd

[SwitchC-bgp-default] quit

[SwitchC] quit

Verifying the configuration

# Display detailed BFD session information on Switch C.

<SwitchC> display bfd session verbose

Total Session Num: 1 Up Session Num: 1 Init Mode: Active

IPv4 Session Working in control packet mode:

Local Discr: 513 Remote Discr: 513

Source IP: 3.0.2.2 Destination IP: 3.0.1.1

Session State: Up Interface: N/A

Min Tx Inter: 500ms Act Tx Inter: 500ms

Min Rx Inter: 500ms Detect Inter: 2500ms

Rx Count: 135 Tx Count: 135

Connect Type: Indirect Running Up for: 00:00:58

Hold Time: 2457ms Auth mode: None

Detect Mode: Async Slot: 0

Protocol: BGP

Version: 1

Diag Info: No Diagnostic

The output shows that a BFD session has been established between Switch A and Switch C.

# Display BGP peer information on Switch C.

<SwitchC> display bgp peer ipv4

BGP local router ID: 3.3.3.3

Local AS number: 200

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

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

2.0.1.1 200 4 5 0 0 00:01:55 Established

3.0.1.1 200 4 5 0 0 00:01:52 Established

The output shows that Switch C has established two BGP connections with Switch A, and both connections are in Established state.

# Display route 1.1.1.0/24 on Switch C.

<SwitchC> display ip routing-table 1.1.1.0 24 verbose

Summary count : 1

Destination: 1.1.1.0/24

Protocol: BGP Process ID: 0

SubProtID: 0x1 Age: 00h00m09s

Cost: 50 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x1 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x15000001 LastAs: 0

AttrID: 0x1 Neighbor: 3.0.1.1

Flags: 0x10060 OrigNextHop: 3.0.1.1

Label: NULL RealNextHop: 3.0.2.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: Vlan-interface101

BkSRLabel: NULL BkInterface: Invalid

Tunnel ID: Invalid IPInterface: Vlan-interface101

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

The output shows that Switch C communicates with network 1.1.1.0/24 through the path Switch C<—>Switch B<—>Switch A.

# Break down the path Switch C<—>Switch B<—>Switch A and then display route 1.1.1.0/24 on Switch C.

<SwitchC> display ip routing-table 1.1.1.0 24 verbose

Summary count : 1

Destination: 1.1.1.0/24

Protocol: BGP Process ID: 0

SubProtID: 0x1 Age: 00h03m08s

Cost: 100 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x1 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x15000000 LastAs: 0

AttrID: 0x0 Neighbor: 2.0.1.1

Flags: 0x10060 OrigNextHop: 2.0.1.1

Label: NULL RealNextHop: 2.0.2.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: Vlan-interface201

BkSRLabel: NULL BkInterface: Invalid

Tunnel ID: Invalid IPInterface: Vlan-interface201

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

The output shows that Switch C communicates with network 1.1.1.0/24 through the path Switch C<—>Switch D<—>Switch A.

Example: Configuring BGP FRR

Network configuration

As shown in Figure 20, configure BGP FRR so that when Link B fails, BGP uses Link A to forward traffic.

Figure 20 Network diagram

‌

Procedure

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

2. Configure OSPF in AS 200 to ensure connectivity among Switch B, Switch C, and Switch D. (Details not shown.)

3. Configure BGP connections:

# Configure Switch A to establish EBGP sessions to Switch B and Switch C, and advertise network 1.1.1.1/32.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 10.1.1.2 as-number 200

[SwitchA-bgp-default] peer 30.1.1.3 as-number 200

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

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

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

[SwitchA-bgp-default-ipv4] network 1.1.1.1 32

# Configure Switch B to establish an EBGP session to Switch A, and an IBGP session to Switch D.

<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 100

[SwitchB-bgp-default] peer 4.4.4.4 as-number 200

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

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

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

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

[SwitchB-bgp-default-ipv4] peer 4.4.4.4 next-hop-local

[SwitchB-bgp-default-ipv4] quit

[SwitchB-bgp-default] quit

# Configure Switch C to establish an EBGP session to Switch A, and an IBGP session to Switch D.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 30.1.1.1 as-number 100

[SwitchC-bgp-default] peer 4.4.4.4 as-number 200

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

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

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

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

[SwitchC-bgp-default-ipv4] peer 4.4.4.4 next-hop-local

[SwitchC-bgp-default-ipv4] quit

[SwitchC-bgp-default] quit

# Configure Switch D to establish IBGP sessions to Switch B and Switch C, and advertise network 4.4.4.4/32.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp-default] router-id 4.4.4.4

[SwitchD-bgp-default] peer 2.2.2.2 as-number 200

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

[SwitchD-bgp-default] peer 3.3.3.3 as-number 200

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

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

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

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

[SwitchD-bgp-default-ipv4] network 4.4.4.4 32

4. Configure preferred values so Link B is used to forward traffic between Switch A and Switch D:

# Configure Switch A to set the preferred value to 100 for routes received from Switch B.

[SwitchA-bgp-default-ipv4] peer 10.1.1.2 preferred-value 100

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# Configure Switch D to set the preferred value to 100 for routes received from Switch B.

[SwitchD-bgp-default-ipv4] peer 2.2.2.2 preferred-value 100

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

5. Configure BGP FRR:

# On Switch A, set the source address of BFD echo packets to 11.1.1.1.

[SwitchA] bfd echo-source-ip 11.1.1.1

# Create routing policy frr to set a backup next hop 30.1.1.3 (Switch C) for the route destined for 4.4.4.4/32.

[SwitchA] ip prefix-list abc index 10 permit 4.4.4.4 32

[SwitchA] route-policy frr permit node 10

[SwitchA-route-policy] if-match ip address prefix-list abc

[SwitchA-route-policy] apply fast-reroute backup-nexthop 30.1.1.3

[SwitchA-route-policy] quit

# Use BFD echo packet mode to detect the connectivity to Switch D.

[SwitchA] bgp 100

[SwitchA-bgp-default] primary-path-detect bfd echo

# Apply the routing policy to BGP FRR for BGP IPv4 unicast address family.

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

[SwitchA-bgp-default-ipv4] fast-reroute route-policy frr

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

# On Switch D, set the source address of BFD echo packets to 44.1.1.1.

[SwitchD] bfd echo-source-ip 44.1.1.1

# Create routing policy frr to set a backup next hop 3.3.3.3 (Switch C) for the route destined for 1.1.1.1/32.

[SwitchD] ip prefix-list abc index 10 permit 1.1.1.1 32

[SwitchD] route-policy frr permit node 10

[SwitchD-route-policy] if-match ip address prefix-list abc

[SwitchD-route-policy] apply fast-reroute backup-nexthop 3.3.3.3

[SwitchD-route-policy] quit

# Use BFD echo packet mode to detect the connectivity to Switch A.

[SwitchD] bgp 200

[SwitchD-bgp-default] primary-path-detect bfd echo

# Apply the routing policy to BGP FRR for BGP IPv4 unicast address family.

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

[SwitchD-bgp-default-ipv4] fast-reroute route-policy frr

[SwitchD-bgp-default-ipv4] quit

[SwitchD-bgp-default] quit

Verifying the configuration

# Display detailed information about the route to 4.4.4.4/32 on Switch A. The output shows the backup next hop for the route.

[SwitchA] display ip routing-table 4.4.4.4 32 verbose

Summary count : 1

Destination: 4.4.4.4/32

Protocol: BGP Process ID: 0

SubProtID: 0x2 Age: 00h01m52s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 200

NibID: 0x15000003 LastAs: 200

AttrID: 0x5 Neighbor: 10.1.1.2

Flags: 0x10060 OrigNextHop: 10.1.1.2

Label: NULL RealNextHop: 10.1.1.2

BkLabel: NULL BkNextHop: 30.1.1.3

SRLabel: NULL Interface: Vlan-interface 100

BkSRLabel: NULL BkInterface: Vlan-interface 200

Tunnel ID: Invalid IPInterface: Vlan-interface 100

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

# Display detailed information about the route to 1.1.1.1/32 on Switch D. The output shows the backup next hop for the route.

[SwitchD] display ip routing-table 1.1.1.1 32 verbose

Summary count : 1

Destination: 1.1.1.1/32

Protocol: BGP Process ID: 0

SubProtID: 0x1 Age: 00h00m36s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 100

NibID: 0x15000003 LastAs: 100

AttrID: 0x1 Neighbor: 2.2.2.2

Flags: 0x10060 OrigNextHop: 2.2.2.2

Label: NULL RealNextHop: 20.1.1.2

BkLabel: NULL BkNextHop: 40.1.1.3

SRLabel: NULL Interface: Vlan-interface 101

BkSRLabel: NULL BkInterface: Vlan-interface 201

Tunnel ID: Invalid IPInterface: Vlan-interface 101

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

IPv6 BGP network reliability improvement configuration examples

Example: Configuring BFD for IPv6 BGP

Network configuration

As shown in Figure 21, configure OSPFv3 as the IGP in AS 200.

· Configure BFD over the path. When the path fails, BFD can quickly detect the failure and notify it to IPv6 BGP. Then, the path Switch A<—>Switch D<—>Switch C takes effect immediately.

Figure 21 Network diagram

‌

Table 3 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	3000::1/64	Switch C	Vlan-int101	3001::3/64
	Vlan-int200	2000::1/64		Vlan-int201	2001::3/64
Switch B	Vlan-int100	3000::2/64	Switch D	Vlan-int200	2000::2/64
	Vlan-int101	3001::2/64		Vlan-int201	2001::2/64

‌

Procedure

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

2. Configure OSPFv3 so that Switch A and Switch C can reach each other. (Details not shown.)

3. Configure IPv6 BGP on Switch A:

# Establish two IBGP connections to Switch C.

<SwitchA> system-view

[SwitchA] bgp 200

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] peer 3001::3 as-number 200

[SwitchA-bgp-default] peer 2001::3 as-number 200

[SwitchA-bgp-default] address-family ipv6

[SwitchA-bgp-default-ipv6] peer 3001::3 enable

[SwitchA-bgp-default-ipv6] peer 2001::3 enable

[SwitchA-bgp-default-ipv6] quit

# Create IPv6 basic ACL 2000 to permit 1200::0/64 to pass.

[SwitchA] acl ipv6 basic 2000

[SwitchA-acl-ipv6-basic-2000] rule permit source 1200:: 64

[SwitchA-acl-ipv6-basic-2000] quit

# Create two routing policies to set the MED for route 1200::0/64. The policy apply_med_50 sets the MED to 50, and the policy apply_med_100 sets the MED to 100.

[SwitchA] route-policy apply_med_50 permit node 10

[SwitchA-route-policy-apply_med_50-10] if-match ipv6 address acl 2000

[SwitchA-route-policy-apply_med_50-10] apply cost 50

[SwitchA-route-policy-apply_med_50-10] quit

[SwitchA] route-policy apply_med_100 permit node 10

[SwitchA-route-policy-apply_med_100-10] if-match ipv6 address acl 2000

[SwitchA-route-policy-apply_med_100-10] apply cost 100

[SwitchA-route-policy-apply_med_100-10] quit

# Apply routing policy apply_med_50 to routes outgoing to peer 3001::3, and apply routing policy apply_med_100 to routes outgoing to peer 2001::3.

[SwitchA] bgp 200

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

[SwitchA-bgp-default-ipv6] peer 3001::3 route-policy apply_med_50 export

[SwitchA-bgp-default-ipv6] peer 2001::3 route-policy apply_med_100 export

[SwitchA-bgp-default-ipv6] quit

# Enable BFD for peer 3001::3.

[SwitchA-bgp-default] peer 3001::3 bfd

[SwitchA-bgp-default] quit

4. Configure IPv6 BGP on Switch C:

# Establish two IBGP connections to Switch A.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] peer 3000::1 as-number 200

[SwitchC-bgp-default] peer 2000::1 as-number 200

[SwitchC-bgp-default] address-family ipv6

[SwitchC-bgp-default-ipv6] peer 3000::1 enable

[SwitchC-bgp-default-ipv6] peer 2000::1 enable

[SwitchC-bgp-default-ipv6] quit

# Enable BFD for peer 3001::1.

[SwitchC-bgp-default] peer 3000::1 bfd

[SwitchC-bgp-default] quit

[SwitchC] quit

Verifying the configuration

# Display detailed BFD session information on Switch C.

<SwitchC> display bfd session verbose

Total Session Num: 1 Up Session Num: 1 Init Mode: Active

IPv6 Session Working in control packet mode:

Local Discr: 513 Remote Discr: 513

Source IP: 3001::3

Destination IP: 3000::1

Session State: Up Interface: N/A

Min Tx Inter: 500ms Act Tx Inter: 500ms

Min Rx Inter: 500ms Detect Inter: 2500ms

Rx Count: 13 Tx Count: 14

Connect Type: Indirect Running Up for: 00:00:05

Hold Time: 2243ms Auth mode: None

Detect Mode: Async Slot: 0

Protocol: BGP4+

Version:1

Diag Info: No Diagnostic

The output shows that a BFD session has been established between Switch A and Switch C.

# Display BGP peer information on Switch C.

<SwitchC> display bgp peer ipv6

BGP local router ID: 3.3.3.3

Local AS number: 200

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

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

2000::1 200 8 8 0 0 00:04:45 Established

3000::1 200 5 4 0 0 00:01:53 Established

The output shows that Switch C has established two BGP connections with Switch A, and both connections are in Established state.

# Display route 1200::0/64 on Switch C.

<SwitchC> display ipv6 routing-table 1200::0 64 verbose

Summary count : 1

Destination: 1200::/64

Protocol: BGP4+ Process ID: 0

SubProtID: 0x1 Age: 00h01m07s

Cost: 50 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x1 OrigVrf: default-vrf

TableID: 0xa OrigAs: 0

NibID: 0x25000001 LastAs: 0

AttrID: 0x1 Neighbor: 3000::1

Flags: 0x10060 OrigNextHop: 3000::1

Label: NULL RealNextHop: FE80::20C:29FF:FE4A:3873

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: Vlan-interface101

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: Vlan-interface101

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

The output shows that Switch C communicates with network 1200::0/64 through the path Switch C<—>Switch B<—>Switch A.

# Break down the path Switch C<—>Switch B<—>Switch A and then display route 1200::0/64 on Switch C.

<SwitchC> display ipv6 routing-table 1200::0 64 verbose

Summary count : 1

Destination: 1200::/64

Protocol: BGP4+ Process ID: 0

SubProtID: 0x1 Age: 00h00m57s

Cost: 100 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x1 OrigVrf: default-vrf

TableID: 0xa OrigAs: 0

NibID: 0x25000000 LastAs: 0

AttrID: 0x0 Neighbor: 2000::1

Flags: 0x10060 OrigNextHop: 2000::1

Label: NULL RealNextHop: FE80::20C:29FF:FE40:715

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: Vlan-interface201

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: Vlan-interface201

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

The output shows that Switch C communicates with network 1200::0/64 through the path Switch C<—>Switch D<—>Switch A.

Example: Configuring IPv6 BGP FRR

Network configuration

As shown in Figure 22, configure BGP FRR so that when Link B fails, BGP uses Link A to forward traffic.

Figure 22 Network diagram

‌

Procedure

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

2. Configure OSPFv3 in AS 200 to ensure connectivity among Switch B, Switch C, and Switch D. (Details not shown.)

3. Configure BGP connections:

# Configure Switch A to establish EBGP sessions to Switch B and Switch C, and advertise network 1::/64.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA] router-id 1.1.1.1

[SwitchA-bgp-default] peer 3001::2 as-number 200

[SwitchA-bgp-default] peer 2001::2 as-number 200

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

[SwitchA-bgp-default-ipv6] peer 3001::2 enable

[SwitchA-bgp-default-ipv6] peer 2001::2 enable

[SwitchA-bgp-default-ipv6] network 1:: 64

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

# Configure Switch B to establish an EBGP session to Switch A, and an IBGP session to Switch D.

<SwitchB> system-view

[SwitchB] bgp 200

[SwitchB] router-id 2.2.2.2

[SwitchB-bgp-default] peer 3001::1 as-number 100

[SwitchB-bgp-default] peer 3002::2 as-number 200

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

[SwitchB-bgp-default-ipv6] peer 3001::1 enable

[SwitchB-bgp-default-ipv6] peer 3002::2 enable

[SwitchB-bgp-default-ipv6] peer 3002::2 next-hop-local

[SwitchB-bgp-default-ipv6] quit

[SwitchB-bgp-default] quit

# Configure Switch C to establish an EBGP session to Switch A, and an IBGP session to Switch D.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC] router-id 3.3.3.3

[SwitchC-bgp-default] peer 2001::1 as-number 100

[SwitchC-bgp-default] peer 2002::2 as-number 200

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

[SwitchC-bgp-default-ipv6] peer 2001::1 enable

[SwitchC-bgp-default-ipv6] peer 2002::2 enable

[SwitchC-bgp-default-ipv6] peer 2002::2 next-hop-local

[SwitchC-bgp-default-ipv6] quit

[SwitchC-bgp-default] quit

# Configure Switch D to establish IBGP sessions to Switch B and Switch C, and advertise network 4::/64.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp-default] peer 3002::1 as-number 200

[SwitchD-bgp-default] peer 2002::1 as-number 200

[SwitchD-bgp-default] address-family ipv6 unicast

[SwitchD-bgp-default-ipv6] peer 3002::1 enable

[SwitchD-bgp-default-ipv6] peer 2002::1 enable

[SwitchD-bgp-default-ipv6] network 4:: 64

[SwitchD-bgp-default-ipv6] quit

[SwitchD-bgp-default] quit

4. Configure preferred values so Link B is used to forward traffic between Switch A and Switch D:

# Configure Switch A to set the preferred value to 100 for routes received from Switch B.

[SwitchA-bgp-default-ipv6] peer 3001::2 preferred-value 100

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

# Configure Switch D to set the preferred value to 100 for routes received from Switch B.

[SwitchD-bgp-default-ipv6] peer 3002::1 preferred-value 100

[SwitchD-bgp-default-ipv6] quit

[SwitchD-bgp-default] quit

5. Configure BGP FRR:

# On Switch A, create routing policy frr to set a backup next hop 2001::2 (Switch C) for the route destined for 4::/64.

<SwitchA> system-view

[SwitchA] ipv6 prefix-list abc index 10 permit 4:: 64

[SwitchA] route-policy frr permit node 10

[SwitchA-route-policy] if-match ipv6 address prefix-list abc

[SwitchA-route-policy] apply ipv6 fast-reroute backup-nexthop 2001::2

[SwitchA-route-policy] quit

# Apply the routing policy to BGP FRR for BGP IPv6 unicast address family.

[SwitchA] bgp 100

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

[SwitchA-bgp-default-ipv6] fast-reroute route-policy frr

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

# On Switch D, create routing policy frr to set a backup next hop 2002::1 (Switch C) for the route destined for 1::/64.

<SwitchD> system-view

[SwitchD] ipv6 prefix-list abc index 10 permit 1:: 64

[SwitchD] route-policy frr permit node 10

[SwitchD-route-policy] if-match ipv6 address prefix-list abc

[SwitchD-route-policy] apply ipv6 fast-reroute backup-nexthop 2002::1

[SwitchD-route-policy] quit

# Apply the routing policy to BGP FRR for BGP IPv6 unicast address family.

[SwitchD] bgp 200

[SwitchD-bgp-default] address-family ipv6 unicast

[SwitchD-bgp-default-ipv6] fast-reroute route-policy frr

[SwitchD-bgp-default-ipv6] quit

[SwitchD-bgp-default] quit

Verifying the configuration

# Display detailed information about the route to 4::/64 on Switch A. The output shows the backup next hop for the route.

[SwitchA] display ipv6 routing-table 4:: 64 verbose

Summary count : 1

Destination: 4::/64

Protocol: BGP4+ Process ID: 0

SubProtID: 0x2 Age: 00h00m58s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0xa OrigAs: 200

NibID: 0x25000003 LastAs: 200

AttrID: 0x3 Neighbor: 3001::2

Flags: 0x10060 OrigNextHop: 3001::2

Label: NULL RealNextHop: 3001::2

BkLabel: NULL BkNextHop: 2001::2

SRLabel: NULL Interface: Vlan-interface 100

BkSRLabel: NULL BkInterface: Vlan-interface 200

Tunnel ID: Invalid IPInterface: Vlan-interface 100

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

# Display detailed information about the route to 1::/64 on Switch D. The output shows the backup next hop for the route.

[SwitchD] display ipv6 routing-table 1:: 64 verbose

Summary count : 1

Destination: 1::/64

Protocol: BGP4+ Process ID: 0

SubProtID: 0x1 Age: 00h03m24s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0xa OrigAs: 100

NibID: 0x25000003 LastAs: 100

AttrID: 0x4 Neighbor: 3002::1

Flags: 0x10060 OrigNextHop: 3002::1

Label: NULL RealNextHop: 3002::1

BkLabel: NULL BkNextHop: 2002::1

SRLabel: NULL Interface: Vlan-interface 101

BkSRLabel: NULL BkInterface: Vlan-interface 201

Tunnel ID: Invalid IPInterface: Vlan-interface 101

BkTunnel ID: Invalid BKIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BKColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BKTunnelInterface: N/A

Connector: N/A PathID: 0x0

SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

Exp: N/A

VpnPeerId: N/A Dscp: N/A

SID: N/A OrigLinkID: 0x0

BkSID: N/A RealLinkID: 0x0

CommBlockLen: 0

Configuring extended BGP features

Extended BGP feature configuration tasks at a glance

To configure extended BGP features, perform the following tasks:

· Configuring BMP

· Configuring BGP LS

¡ Configuring basic BGP LS

¡ (Optional.) Configuring BGP LS route reflection

¡ (Optional.) Specifying an AS number and a router ID for BGP LS messages

¡ (Optional.) Disabling nexthop changing for BGP LS routes

¡ (Optional.) Preferring routes learned from a peer or peer group during optimal route selection

¡ (Optional.) Performing manual soft-reset for BGP sessions of LS address family

Configuring BMP

About this task

The BGP monitoring protocol (BMP) enables a BGP router (BMP client) to send session status information of the specified peers to BMP servers for monitoring. The session status information includes peer relationship establishment and termination as well as routing information. The BMP client communicates with the BMP servers through TCP connections.

Procedure

1. Enter system view.

system-view

2. Create a BMP server and enter BMP server view.

bmp server server-number

3. Configure an IP address and port number for the BMP server.

server address { ipv4-address | ipv6-address } port port-number

By default, no IP address and port number are configured for the BMP server.

4. Set the interval at which BGP sends statistics information to the BMP server.

statistics-interval value

By default, BGP does not send statistics information to the BMP server.

5. (Optional.) Specify a VPN instance for the BMP server.

server vpn-instance vpn-instance-name

By default, no VPN instance is specified for a BMP server. A BMP server belongs to the public network.

6. (Optional.) Specify the source interface of TCP connections to the BMP server.

server connect-interface interface-type interface-number

By default, BGP uses the primary IPv4 address of the output interface in the optimal route to the BMP server as the source address of TCP connections to the BMP server.

For a BMP server, this command does not take effect if the VPN instance of the specified interface is different from that specified by the server vpn-instance command.

7. (Optional.) Specify the source address of TCP connections to the BMP server.

server source-address { ipv4-address | ipv6-address }

By default, BGP uses the primary IPv4 or IPv6 address of the output interface in the optimal route to the BMP server as the source address of TCP connections to the BMP server.

If you execute both this command and the server connect-interface command for a BMP server, the configuration of this command takes effect.

8. (Optional.) Specify the authentication mode and key for the local device to establish TCP connections to the BMP server.

server password { keychain keychain-name | md5 { cipher | simple } string }

By default, the local device establishes TCP connections to the BMP server without authentication.

9. (Optional.) Enable BGP to send routes to the BMP server globally. Choose the options to configure as needed:

¡ Enable BGP to send routes advertised to all the monitored peers and peer groups to the BMP server.

route-mode adj-rib-out [ pre-policy | post-policy | both ]

By default, BGP does not send routes advertised to a monitored peer or peer group to the BMP server.

¡ Enable BGP to send routes received from all the monitored peers and peer groups to the BMP server.

route-mode adj-rib-in [ pre-policy | post-policy | both ]

By default, BGP sends routes received from a monitored peer or peer group to the BMP server without route filtering.

¡ Configure BGP to send the optimal routes in the routing table to the BMP server.

route-mode loc-rib { vpn-instance-all | vpn-instance vpn-instance-name } { ipv4 [ flowspec | unicast ] | ipv6 [ flowspec | unicast ] }

route-mode loc-rib { ipv4 [ flowspec | unicast ] | ipv6 [ flowspec | unicast ] }

By default, BGP does not send the optimal routes in the routing table to the BMP server.

After you execute this command, BGP sends all routes to the BMP server. If routes update later, BGP sends only the optimal routes to the server.

10. Return to system view.

quit

11. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

12. Specify a peer or peer group to be monitored.

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

By default, no peer or peer group is specified.

If you execute this command multiple times for a peer or peer group, the most recent configuration takes effect.

13. (Optional.) Enable BGP to send routes exchanged with the specified monitored peer or peer group to the BMP server.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } route-mode { adj-rib-in { pre-policy | post-policy | both } | adj-rib-out { pre-policy | post-policy | both } } *

By default, BGP determines whether to send routes exchanged with a peer or peer group to the BMP server based on the following configurations:

¡ Configuration of the route-mode adj-rib-in command in BMP server view.

¡ Configuration of the route-mode adj-rib-out command in BMP server view.

Verifying and maintaining BMP

To display BMP server information, execute the following command in any view:

display bgp [ instance instance-name ] bmp server server-number

To clear BMP server statistics, execute the following command in user view:

reset bgp [ instance instance-name ] bmp server server-number statistics

Configuring BGP LS

About BGP LS

The BGP Link State (LS) feature implements inter-domain and inter-AS advertisement of link state database (LSDB) and TE database (TEDB) information.

The device sends the collected link state information to the controller, which implements end-to-end traffic management and scheduling and meets the requirements of intended applications.

Configuring basic BGP LS

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify an AS number for an LS peer or peer group.

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

By default, no AS number is specified.

4. Create the BGP LS address family and enter its view.

address-family link-state

5. Enable the device to exchange LS information with the peer or peer group.

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

By default, the device cannot exchange LS information with the peer or peer group.

Configuring BGP LS route reflection

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.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP LS address family view.

address-family link-state

4. Configure BGP LS route reflection.

¡ Configure the device 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.

¡ (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

This command can reduce the number of IBGP connections in an AS.

¡ (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.

Specifying an AS number and a router ID for BGP LS messages

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP LS address family view.

address-family link-state

4. Specify an AS number and a router ID for BGP LS messages.

domain-distinguisher as-number:router-id

By default, the AS number and router ID of the current BGP process are used.

Configure this command to ensure that LS messages sent by devices in the same AS have the same AS number and router ID.

D isabling nexthop changing for BGP LS routes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP LS address family view.

address-family link-state

4. Disable nexthop changing for the BGP LS 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.

Enabling routing policy-based nexthop recursion for BGP LS routes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP LS address family view.

address-family link-state

Enable routing policy-based nexthop recursion for BGP LS routes

nexthop recursive-lookup route-policy route-policy-name

By default, BGP does not perform routing policy-based nexthop recursion for routes.

CAUTION:

‌

Preferring routes learned from a peer or peer group during optimal route selection

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP LS address family view.

address-family link-state

4. Prefer routes learned from the specified peer or peer group during optimal route selection.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } high-priority

By default, BGP does not prefer routes learned from any peer or peer groups during optimal route selection.

Performing manual soft-reset for BGP sessions of LS address family

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP route refresh.

¡ Enable BGP route refresh for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise route-refresh

¡ Enable the BGP route refresh, multi-protocol extension, and 4-byte AS number features for a peer or peer group.

undo peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } capability-advertise conventional

By default, the BGP route refresh, multi-protocol extension, and 4-byte AS number features are enabled.

4. Perform manual soft-reset for BGP sessions of LS address family:

a. Return to system view.

quit

b. Return to user view.

quit

c. Perform manual soft-reset for BGP sessions of LS address family.

refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] | all | external | group group-name | internal } { export | import } link-state

Verifying and maintaining BGP LS

Verifying BGP LS configuration and running status

Perform display tasks in any view.

· Display BGP LS peer group information.

display bgp [ instance instance-name ] group link-state [ group-name group-name ]

· Display BGP LS peer or peer group information.

display bgp [ instance instance-name ] peer link-state [ ipv4-address mask-length | ipv6-address prefix-length | { ipv4-address | ipv6-address | group-name group-name } log-info | [ ipv4-address | ipv6-address ] verbose ]

· Display BGP LS route information.

display bgp [ instance instance-name ] link-state [ ls-prefix [ advertise-info | as-path | cluster-list ] | peer { ipv4-address | ipv6-address } { advertised | received } [ statistics ] | statistics ]

display bgp [ instance instance-name ] link-state [ color color-value end-point { ipv4 ipv4-address | ipv6 ipv6-address } ]

· Display BGP update group information for the LS address family.

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

Resetting BGP session in the LS address family

To reset BGP sessions in the LS address family, execute the following command in user view:

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

Extended IPv4 BGP feature configuration examples

Example: Configuring BGP LS

Network configuration

As shown in Figure 23, all switches run BGP. Run IBGP between Switch A and Switch B, between Switch B and Switch C, and between Switch B and Switch D.

Configure Switch B as a route reflector with client Switch A to allow Switch A to learn LS information advertised by Switch C and Switch D.

Figure 23 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces and configure OSPF on Switch C and Switch D. (Details not shown.)

2. Configure BGP connections:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] peer 192.1.1.2 as-number 100

[SwitchA-bgp-default] address-family link-state

[SwitchA-bgp-default-ls] peer 192.1.1.2 enable

[SwitchA-bgp-default-ls] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 100

[SwitchB-bgp-default] peer 192.1.1.1 as-number 100

[SwitchB-bgp-default] peer 193.1.1.1 as-number 100

[SwitchB-bgp-default] peer 194.1.1.1 as-number 100

[SwitchB-bgp-default] address-family link-state

[SwitchB-bgp-default-ls] peer 192.1.1.1 enable

[SwitchB-bgp-default-ls] peer 193.1.1.1 enable

[SwitchB-bgp-default-ls] peer 194.1.1.1 enable

[SwitchB-bgp-default-ls] quit

[SwitchB-bgp-default] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 100

[SwitchC-bgp-default] peer 193.1.1.2 as-number 100

[SwitchC-bgp-default] address-family link-state

[SwitchC-bgp-default-ls] peer 193.1.1.2 enable

[SwitchC-bgp-default-ls] quit

[SwitchC-bgp-default] quit

[SwitchC] ospf

[SwitchC-ospf-1] distribute bgp-ls

[SwitchC-ospf-1] area 0

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

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

[SwitchC-ospf-1] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 100

[SwitchD-bgp-default] peer 194.1.1.2 as-number 100

[SwitchD-bgp-default] address-family link-state

[SwitchD-bgp-default-ls] peer 194.1.1.2 enable

[SwitchD-bgp-default-ls] quit

[SwitchD-bgp-default] quit

[SwitchD] ospf

[SwitchD-ospf-1] distribute bgp-ls

[SwitchD-ospf-1] area 0

[SwitchD-ospf-1-area-0.0.0.0] network 0.0.0.0 0.0.0.0

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

[SwitchD-ospf-1] quit

3. Configure Switch B as the route reflector.

[SwitchB] bgp 100

[SwitchB-bgp-default] address-family link-state

[SwitchB-bgp-default-ls] peer 192.1.1.1 reflect-client

[SwitchB-bgp-default-ls] quit

[SwitchB-bgp-default] quit

Verifying the configuration

# Verify that Switch A has learned LS information advertised by Switch C and Switch D.

[SwitchA] display bgp link-state

Total number of routes: 4

BGP local Switch ID is 192.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

Prefix codes: E link, V node, T4 IPv4 route, T6 IPv6 route, SD SRv6 SID desc

u/U unknown,

I Identifier, N local node, R remote node, L link, P prefix,

L1/L2 ISIS level-1/level-2, O OSPF, O3 OSPFv3,

D direct, S static, B BGP, SS SRv6 SID,

a area-ID, l link-ID, t topology-ID, s ISO-ID,

c confed-ID/ASN, b bgp-identifier, r router-ID,

i if-address, n peer-address, o OSPF Route-type, p IP-prefix

d designated router address/interface, ID Link Descriptor Identifer

i Network : [V][O][I0x0][N[c100][b193.1.1.1][a0.0.0.0][r193.1.1.1]]/376

NextHop : 193.1.1.1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: i

i Network : [V][O][I0x0][N[c100][b194.1.1.1][a0.0.0.0][r194.1.1.1]]/376

NextHop : 194.1.1.1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: i

i Network : [T4][O][I0x0][N[c100][b193.1.1.1][a0.0.0.0][r193.1.1.1]][P[o0x1][p193.1.1.0/24]]/480

NextHop : 193.1.1.1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: i

i Network : [T4][O][I0x0][N[c100][b194.1.1.1][a0.0.0.0][r194.1.1.1]][P[o0x1][p194.1.1.0/24]]/480

NextHop : 194.1.1.1 LocPrf : 100

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: i

06-Layer 3—IP Routing Configuration Guide

Setting the TCP MSS for TCP connections

About this task

Procedure

About this task

Restrictions and guidelines

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure

Enabling BGP ORF capabilities negotiation

Procedure (IPv4 unicast)

Procedure (IPv6 unicast/IPv6 multicast)

About this task

Procedure (IPv4 peers)

Procedure (IPv6 peers)

Enabling BGP to exchange withdrawal ROUTE-REFRESH messages with peers

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

Saving updates (IPv6 unicast/multicast address family)

Configuring manual soft-reset (IPv6 unicast/multicast address family)

About this task

Restrictions and guidelines

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast/multicast address family)

About this task

Restrictions and guidelines

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast address family)

About this task

Restrictions and guidelines

Procedure (IPv4 unicast/multicast address family)

Procedure (IPv6 unicast/multicast address family)

About this task

Restrictions and guidelines

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

Performing local-FIB route check before route update advertisement

About this task

Restrictions and guidelines

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure (IPv4 unicast/multicast address family)

Procedure (IPv6 unicast/multicast address family)

About this task

Restrictions and guidelines

Procedure

About this task

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

About this task

Restrictions and guidelines

Configuration tasks at a glance

Enabling routing policy-based nexthop recursion (IPv4 unicast/multicast address family)

Enabling routing policy-based nexthop recursion (IPv6 unicast/multicast address family)

About this task

Procedure

About this task

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Display and maintenance commands for peer monitoring group configuration

Disabling BGP from flushing specific routes to the IP routing table

About this task

Procedure (IPv4 unicast)

S etting the TCP MSS for TCP connections

D isabling BGP from flushing specific routes to the IP routing table

E nabling conversational remote host route learning