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 (or interface 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.

Restrictions and guidelines

This task might cause BGP session re-establishment. Make sure you understand the potential impact before performing this task.

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.

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.

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.

Enabling 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. After you enable this feature, BGP immediately tears down the session to that peer, and then recreates the session.

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.

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 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.

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

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.

Restrictions and guidelines

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 (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.

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.

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.

Executing the ignore all-peers command or the peer ignore command might cause traffic forwarding interruption. To avoid this issue, make sure you configure the related parameters in the command to decrease the priority value for the routes that BGP re-advertises. BGP peers then select optimal routes from the routes learned from other peers.

When you specify the graceful keyword in the peer ignore command, follow these restrictions and guidelines:

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

¡ Starts the timer for graceful session teardown. This timer is specified with the graceful keyword.

¡ Advertises all routes to the specified peer or peer group and changes the attributes of the advertised routes to the specified values.

¡ Advertises routes from the specified peer or peer group to other IBGP peers and peer groups and changes the attributes of the advertised routes to the specified values.

After the timer for graceful session teardown expires, BGP tears down the session to the specified peer or peer group.

· To decrease the priority of the routes advertised by BGP without tearing down BGP sessions, set the value for the graceful-time argument to 0.

When you specify the graceful keyword in the ignore all-peers command, follow these restrictions and guidelines:

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

¡ Starts the timer for graceful session teardown. This timer is specified with the graceful keyword.

¡ Advertises all routes to all peers and peer groups and changes the attributes of the advertised routes to the specified values.

After the timer for graceful session teardown expires, BGP tears down the sessions to peers and peer groups.

· To decrease the priority of the routes advertised by BGP without tearing down BGP sessions, set the value for the graceful-time argument to 0.

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 the peer ignore command for the peer tears down the session and clears all related routing information.

· If sessions have been established to a peer group, executing the peer ignore 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 the peer ignore command for the peer tears down the session 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 the ignore all-peers 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.

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

Saving updates (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. 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.

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 [ [ 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 [ [ unicast ] [ vpn-instance vpn-instance-name ] ]

Configuring manual soft-reset (IPv6 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 | 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 [ [ 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 [ [ 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.

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

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.

Procedure (IPv6 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 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

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.

Configuring the BGP Additional Paths feature

About this task

By default, BGP advertises only one optimal route. When the optimal route fails, traffic forwarding will be interrupted until route convergence completes.

The BGP Additional Paths (Add-Path) feature enables BGP to advertise multiple routes with the same prefix and different next hops to a peer or peer group. When the optimal route fails, the suboptimal route becomes the optimal route, which shortens the traffic interruption time.

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 1, 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 1 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 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 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.

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 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 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.

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 configure 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 configure t he nexthop recursive-lookup route-policy command in the view of the BGP address family.

- You configure 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 configure the nexthop recursive-lookup route-policy command in the view of the BGP address family.

- You configure 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 address family)

· Enabling routing policy-based nexthop recursion (IPv6 unicast 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 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. 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 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. 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 hardware resource management configuration in System Management 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 the 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.

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 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 2, run EBGP between Switch A and Switch B, and between Switch A and Switch C. Run IBGP between Switch B and Switch C.

Figure 2 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 3, 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 3 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

BGP security feature configuration tasks at a glance

To configure BGP security features, perform the following tasks:

· Enabling MD5 authentication for BGP peers

· Configuring GTSM for BGP

· Enabling keychain authentication for BGP peers

· Configuring IPsec for IPv6 BGP

· Configuring BGP RPKI

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.

Configuring GTSM for BGP

About this task

The Generalized TTL Security Mechanism (GTSM) protects a BGP session by comparing the TTL value in the IP header of incoming BGP packets against a valid TTL range. If the TTL value is within the valid TTL range, the packet is accepted. If not, the packet is discarded.

The valid TTL range is from 255 – the configured hop count + 1 to 255.

When GTSM is configured, the BGP packets sent by the device have a TTL of 255.

GTSM provides best protection for directly connected EBGP sessions, but not for multihop EBGP or IBGP sessions because the TTL of packets might be modified by intermediate devices.

Restrictions and guidelines

When GTSM is configured, the local device can establish an EBGP session to the peer after both devices pass GTSM check, regardless of whether the maximum number of hops is reached.

To use GTSM, you must configure GTSM on both the local and peer devices. You can specify different hop-count values for them.

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 GTSM for the specified BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } ttl-security hops hop-count

By default, GTSM 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. Configure GTSM for the specified BGP peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } ttl-security hops hop-count

By default, GTSM is disabled.

Enabling keychain authentication for BGP peers

About this task

Keychain authentication enhances the security of BGP in the following ways:

· BGP peers can establish TCP connections only when they use the same key for keychain authentication.

· The keys used by the BGP peers at the same time must have the same ID.

· The keys with the same ID must use the same authentication algorithm and key string.

For more information about keychains, see Security 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. Enable keychain authentication for a BGP peer or peer group.

peer { group-name | ip-address [ mask-length ] } keychain keychain-name

By default, keychain 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 keychain authentication for a BGP peer or peer group.

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

By default, keychain authentication is disabled.

Configuring IPsec for IPv6 BGP

About this task

Perform this task to configure IPsec for IPv6 BGP. IPsec can protect IPv6 BGP packets from data eavesdropping, tampering, and attacks caused by forged IPv6 BGP packets.

When two IPv6 BGP peers are configured with IPsec (for example, Device A and Device B), Device A encapsulates an IPv6 BGP packet with IPsec before sending it to Device B. If Device B successfully receives and de-encapsulates the packet, it establishes an IPv6 BGP peer relationship with Device A and learns IPv6 BGP routes from Device A. If Device B receives but fails to de-encapsulate the packet, or receives a packet not protected by IPsec, it discards the packet.

Procedure

1. Enter system view.

system-view

2. Configure an IPsec transform set and a manual IPsec profile.

For more information about this task, see IPsec configuration in IP Tunneling Configuration Guide.

3. 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

4. Apply the IPsec profile to an IPv6 BGP peer or peer group.

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

By default, no IPsec profile is configured for any IPv6 BGP peer or peer group.

This command supports only IPsec profiles in manual mode.

Configuring BGP RPKI

About BGP RPKI

The AS_PATH attribute identifies the ASs through which a route has passed, and the AS that originated the route is the origin AS of the route. If the origin AS number of a route is incorrect, traffic transmission failure or even network collapse might occur.

To avoid this problem, you can configure the BGP Resource Public Key Infrastructure (RPKI) feature. It enables BGP to validate the origin AS of a route and determine whether to use and advertise the route based on the validation state.

Configuring RPKI connection parameters

About this task

A router establishes a TCP connection with an RPKI server to obtain the Route Origin Authorization (ROA) information used for RPKI validation. The router checks the connection to the RPKI server at the specified interval. If the router does not receive a response from the RPKI server within the specified time period, it tears down the connection to the RPKI server.

When the connection between a router and an RPKI server goes down (except when the shutdown command is executed), the router takes the following actions:

· Attempts to reconnect to the server.

· Places the ROA information obtained from the server in aging state, and starts the aging timer for the ROA information.

If the router reconnects to the server before the aging timer expires, it releases the ROA information from the aging state. If the router fails to reconnect to the server when the aging timer expires, it deletes the ROA information obtained from the server.

Restrictions and guidelines

Follow these restrictions and guidelines when you configure RPKI connection parameters:

· As a best practice, set an ROA information aging time longer than the time to wait for the response from the RPKI server.

· To tear down the connection to an RPKI server, execute the undo port command in RPKI server view.

· If you execute the undo rpki command, all configurations in RPKI view are removed.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP RPKI view.

rpki

4. Specify an RPKI server by its IP address and enter RPKI server view.

server [ vpn-instance vpn-instance-name ] tcp { ipv4-address | ipv6-address }

By default, no RPKI server is specified.

5. Specify the port number of the RPKI server.

port port-number

By default, the port number of the RPKI server is not specified.

To enable a router to establish a TCP connection with the RPKI server, you must configure the port number of the RPKI server on the router.

6. (Optional.) Specify the MD5 authentication password.

passwords { cipher | simple } string

By default, the RPKI server does not perform MD5 authentication.

The MD5 authentication password must be the same as the authentication password configured on the RPKI server.

MD5 authentication ensures the validity of the RPKI server and the security of BGP RPKI packets.

7. (Optional.) Set the RPKI connection check interval.

refresh-time refresh-time

By default, the RPKI connection check interval is 600 seconds.

8. (Optional.) Set the time to wait for the response from the RPKI server.

response-time response-time

By default, the time to wait for the response from the RPKI server is 30 seconds.

9. (Optional.) Set the aging time for the ROA information.

purge-time purge-time

By default, the aging time for the ROA information is 60 seconds.

Enabling BGP RPKI validation

About this task

After you configure this feature, BGP validates the prefix and origin AS number of a received route and places the route to one of the following validation states:

· Not-found—No ROA matches the prefix.

· Valid—One or multiple ROAs match both the prefix and origin AS number.

· Invalid—One or multiple ROAs match the prefix, but none of the ROAs matches the origin AS number.

Restrictions and guidelines

If you configure this feature, BGP uses the local RPKI validation states. If you do not configure this feature, BGP uses the validation states in the received BGP routes.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP RPKI view.

rpki

4. Enable BGP RPKI validation.

check-origin-validation

By default, BGP RPKI validation is disabled.

Applying the BGP RPKI validation state to optimal route selection

About this task

If multiple routes to the same destination are available, BGP first discards routes with unreachable next hops, and then selects the optimal route according to the following rules:

· Routes with a BGP RPKI validation state of Valid takes precedence over routes with a validation state of Not-found or Invalid.

· Routes with a BGP RPKI validation state of Not-found takes precedence over routes with a validation state of Invalid.

· Routes without a BGP RPKI validation state have the same priority as routes with a BGP RPKI validation state of Not-found.

· For routes that have the same BGP RPKI validation state, BGP selects the optimal route according to the BGP path selection rules. For more information about BGP path selection rules, see "BGP overview."

You can configure a routing policy to filter routes based on the BGP RPKI validation state. For more information about routing policies, see "Configuring routing policies."

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. Apply the BGP RPKI validation state to optimal route selection.

bestroute origin-as-validation [ allow-invalid ]

By default, BGP ignores the BGP RPKI validation state during optimal route selection.

To allow routes with a validation state of Invalid to participate in optimal route selection, you must specify the allow-invalid keyword.

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. Apply the BGP RPKI validation state to optimal route selection.

bestroute origin-as-validation [ allow-invalid ]

By default, BGP ignores the BGP RPKI validation state during optimal route selection.

To allow routes with a validation state of Invalid to participate in optimal route selection, you must specify the allow-invalid keyword.

Advertising BGP RPKI validation state to a peer or peer group

Restrictions and guidelines

BGP advertises the BGP RPKI validation state to a peer or peer group through the extended community attribute. To enable this feature, you must first enable BGP to advertise the extended community attribute to the peer or peer group and make sure RPKI settings are correct.

In the current software version, BGP can advertise the BGP RPKI validation state only to IBGP peers and peer groups.

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. Advertise the extended community attribute to a peer or peer group.

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

By default, BGP does not advertise the extended community attribute.

4. Advertise the BGP RPKI validation state to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise origin-as-validation

By default, BGP does not advertise the BGP RPKI validation state.

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. Advertise the extended community attribute to a peer or peer group.

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

By default, BGP does not advertise the extended community attribute.

4. Advertise the BGP RPKI validation state to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise origin-as-validation

By default, BGP does not advertise the BGP RPKI validation state.

Verifying and maintaining BGP security features

Verifying and maintaining BGP RPKI

Verifying RPKI server configuration and running status (IPv4 unicast address family)

Perform display tasks in any view.

· Display information about connections to RPKI servers.

display bgp [ instance instance-name ] rpki server [ [ vpn-instance vpn-instance-name ] ipv4-address ]

· Display the ROA information obtained from RPKI servers.

display bgp [ instance instance-name ] rpki table ipv4 [ ipv4-address min min-length max max-length ]

Verifying RPKI server configuration and running status (IPv6 unicast address family)

Perform display tasks in any view.

· Display information about connections to RPKI servers.

display bgp [ instance instance-name ] rpki server [ [ vpn-instance vpn-instance-name ] ipv6-address ]

· Display the ROA information obtained from RPKI servers.

display bgp [ instance instance-name ] rpki table ipv6 [ ipv6-address min min-length max max-length

Resetting BGP RPKI sessions

To reset BGP RPKI sessions, execute the following command in user view:

reset bgp [ instance instance-name ] rpki server [ vpn-instance vpn-instance-name ] tcp { ipv4 address | ipv6 address }

CAUTION:

After you execute this command, the device will delete and re-establish the specified BGP RPKI session and cause temporary session interruption.

‌

Verifying and maintaining BGP GTSM

To display BGP GTSM discarded packet statistics, execute the following command in any view:

display ttl-security statistics [ slot slot-number ]

To clear BGP GTSM discarded packet statistics, execute the following command in user view:

reset ttl-security statistics [ slot slot-number ]

IPv4 BGP security feature configuration examples

Example: Configuring BGP RPKI

Network configuration

As shown in Figure 4, all switches run BGP. Establish a TCP connection between Switch A and the RPKI server, and establish an IBGP connection between Switch A and Switch B.

Configure Switch A to advertise the BGP RPKI validation state to Switch B, and configure a routing policy to filter routes based on the validation state for Switch B.

Figure 4 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces and establish an IBGP connection between Switch A and Switch B. (Details not shown.)

2. Configure Switch A to establish a TCP connection to the RPKI server.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] rpki

[SwitchA-bgp-default-rpki] server tcp 1.1.1.2

[SwitchA-bgp-default-rpki-server] port 1234

[SwitchA-bgp-default-rpki-server] quit

3. Enable BGP RPKI validation on Switch A.

[SwitchA-bgp-default-rpki] check-origin-validation

[SwitchA-bgp-default-rpki] quit

4. Apply the BGP RPKI validation state to optimal route selection.

[SwitchA-bgp-default] address-family ipv4

[SwitchA-bgp-default-ipv4] bestroute origin-as-validation

5. Configure Switch A to advertise the BGP RPKI validation state to peer 1.2.3.2.

[SwitchA-bgp-default-ipv4] peer 1.2.3.2 advertise-ext-community

[SwitchA-bgp-default-ipv4] peer 1.2.3.2 advertise origin-as-validation

[SwitchA-bgp-default-ipv4] quit

[SwitchA-bgp-default] quit

6. Configure Switch B to permit routes with a BGP RPKI validation state of Valid:

# Configure a routing policy.

<SwitchB> system-view

[SwitchB] route-policy rpki_policy permit node 0

[SwitchB-route-policy-rpki_policy-0] if-match rpki valid

[SwitchB-route-policy-rpki_policy-0] quit

# Apply the routing policy.

[SwitchB] bgp 100

[SwitchB-bgp-default] address-family ipv4

[SwitchB-bgp-default-ipv4] peer 1.2.3.1 route-policy rpki_policy import

Verifying the configuration

# Display information about the connection between Switch A and the RPKI server.

[SwitchA] display bgp rpki server

Server VPN-index Port State Time ROAs(IPv4/IPv6)

1.1.1.2 0 1234 Establish 00:04:43 5/4

The output shows that Switch A has established a TCP connection to the RPKI server.

# Display the ROA information on Switch A.

[SwitchA] display bgp rpki table ipv4

Total number of entries: 5

Status codes: S - stale, U - used

Network Mask-range Origin-AS Server Status

1.2.3.4 8-24 100 1.1.1.2 U

2.2.3.6 8-32 100 1.1.1.2 U

2.2.3.6 10-24 4294967295 1.1.1.2 U

2.2.3.9 20-24 4294967295 1.1.1.2 U

3.2.3.5 8-26 200 1.1.1.2 U

The output shows that Switch A has obtained the ROA information from the RPKI server.

# Display the BGP RPKI validation state on Switch A.

[SwitchA] display bgp routing-table ipv4 1.2.3.0

BGP local router ID: 2.2.2.2

Local AS number: 100

Paths: 1 available, 1 best

BGP routing table information of 1.2.3.0/24:

Imported route.

Original nexthop: 0.0.0.0

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

Org-validation : Valid

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, pref-val 32768

State : valid, local, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

The route to 1.2.3.0 matches the ROA with a prefix of 1.2.3.4, a mask length range of 8 to 24, and an origin AS number of 100. Therefore, the BGP RPKI validation state of the route to 1.2.3.0 is Valid.

# On Switch B, display detailed information about the BGP IPv4 unicast route to 1.2.3.0.

[SwitchB] display bgp routing-table ipv4 1.2.3.0

RR-client route.

From : 1.2.3.1 (192.168.56.22)

Rely nexthop : 1.2.3.1

Original nexthop: 1.2.3.1

OutLabel : NULL

Ext-Community : <Origin Valid State: Valid >

RxPathID : 0x0

TxPathID : 0x0

Org-validation : Valid

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

The output displays information about the BGP IPv4 unicast route to 1.2.3.0 because Switch B permits routes with a BGP RPKI validation state of Valid.

IPv6 BGP security feature configuration examples

Example: Configuring IPsec for IPv6 BGP packets

Network configuration

As shown in Figure 5, all switches run IPv6 BGP. Establish an IBGP connection between Switch A and Switch B, and establish an EBGP connection between Switch B and Switch C.

To enhance security, configure IPsec to protect IPv6 BGP packets.

Figure 5 Network diagram

‌

Procedure

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

2. Establish an IBGP connection between Switch A and Switch B:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp-default] router-id 1.1.1.1

[SwitchA-bgp-default] group ibgp internal

[SwitchA-bgp-default] peer 1::2 group ibgp

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

[SwitchA-bgp-default-ipv6] peer ibgp enable

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65008

[SwitchB-bgp-default] router-id 2.2.2.2

[SwitchB-bgp-default] group ibgp internal

[SwitchB-bgp-default] peer 1::1 group ibgp

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

[SwitchB-bgp-default-ipv6] peer ibgp enable

[SwitchB-bgp-default-ipv6] quit

3. Establish an EBGP connection between Switch B and Switch C:

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp-default] router-id 3.3.3.3

[SwitchC-bgp-default] group ebgp external

[SwitchC-bgp-default] peer 3::1 as-number 65008

[SwitchC-bgp-default] peer 3::1 group ebgp

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

[SwitchC-bgp-default-ipv6] peer ebgp enable

[SwitchC-bgp-default-ipv6] quit

[SwitchC-bgp-default] quit

# Configure Switch B.

[SwitchB-bgp-default] group ebgp external

[SwitchB-bgp-default] peer 3::2 as-number 65009

[SwitchB-bgp-default] peer 3::2 group ebgp

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

[SwitchB-bgp-default-ipv6] peer ebgp enable

[SwitchB-bgp-default-ipv6] quit

[SwitchB-bgp-default] quit

4. Configure IPsec transform sets and IPsec profiles:

# On Switch A, create an IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

# Set the encapsulation mode to transport mode.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode transport

# Set the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm des

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create an IPsec profile named policy001, and specify the manual mode for it.

[SwitchA] ipsec profile policy001 manual

# Use IPsec transform set tran1.

[SwitchA-ipsec-profile-policy001-manual] transform-set tran1

# Set the SPIs of the inbound and outbound SAs to 12345.

[SwitchA-ipsec-profile-policy001-manual] sa spi outbound esp 12345

[SwitchA-ipsec-profile-policy001-manual] sa spi inbound esp 12345

# Set the keys for the inbound and outbound SAs using ESP to abcdefg.

[SwitchA-ipsec-profile-policy001-manual] sa string-key outbound esp simple abcdefg

[SwitchA-ipsec-profile-policy001-manual] sa string-key inbound esp simple abcdefg

[SwitchA-ipsec-profile-policy001-manual] quit

# On Switch B, create an IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

# Set the encapsulation mode to transport mode.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode transport

# Set the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm des

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create IPsec profile named policy001, and specify the manual mode for it.

[SwitchB] ipsec profile policy001 manual

# Use IPsec transform set tran1.

[SwitchB-ipsec-profile-policy001-manual] transform-set tran1

# Set the SPIs of the inbound and outbound SAs to 12345.

[SwitchB-ipsec-profile-policy001-manual] sa spi outbound esp 12345

[SwitchB-ipsec-profile-policy001-manual] sa spi inbound esp 12345

# Set the keys for the inbound and outbound SAs using ESP to abcdefg.

[SwitchB-ipsec-profile-policy001-manual] sa string-key outbound esp simple abcdefg

[SwitchB-ipsec-profile-policy001-manual] sa string-key inbound esp simple abcdefg

[SwitchB-ipsec-profile-policy001-manual] quit

# Create an IPsec transform set named tran2.

[SwitchB] ipsec transform-set tran2

# Set the encapsulation mode to transport mode.

[SwitchB-ipsec-transform-set-tran2] encapsulation-mode transport

# Set the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1.

[SwitchB-ipsec-transform-set-tran2] esp encryption-algorithm des

[SwitchB-ipsec-transform-set-tran2] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran2] quit

# Create IPsec profile named policy002, and specify the manual mode for it.

[SwitchB] ipsec profile policy002 manual

# Use IPsec transform set tran2.

[SwitchB-ipsec-profile-policy002-manual] transform-set tran2

# Set the SPIs of the inbound and outbound SAs to 54321.

[SwitchB-ipsec-profile-policy002-manual] sa spi outbound esp 54321

[SwitchB-ipsec-profile-policy002-manual] sa spi inbound esp 54321

# Set the keys for the inbound and outbound SAs using ESP to gfedcba.

[SwitchB-ipsec-profile-policy002-manual] sa string-key outbound esp simple gfedcba

[SwitchB-ipsec-profile-policy002-manual] sa string-key inbound esp simple gfedcba

[SwitchB-ipsec-profile-policy002-manual] quit

# On Switch C, create an IPsec transform set named tran2.

[SwitchC] ipsec transform-set tran2

# Set the encapsulation mode to transport mode.

[SwitchC-ipsec-transform-set-tran2] encapsulation-mode transport

# Set the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1.

[SwitchC-ipsec-transform-set-tran2] esp encryption-algorithm des

[SwitchC-ipsec-transform-set-tran2] esp authentication-algorithm sha1

[SwitchC-ipsec-transform-set-tran2] quit

# Create IPsec profile named policy002, and specify the manual mode for it.

[SwitchC] ipsec profile policy002 manual

# Use IPsec transform set tran2.

[SwitchC-ipsec-profile-policy002-manual] transform-set tran2

# Set the SPIs of the inbound and outbound SAs to 54321.

[SwitchC-ipsec-profile-policy002-manual] sa spi outbound esp 54321

[SwitchC-ipsec-profile-policy002-manual] sa spi inbound esp 54321

# Set the keys for the inbound and outbound SAs using ESP to gfedcba.

[SwitchC-ipsec-profile-policy002-manual] sa string-key outbound esp simple gfedcba

[SwitchC-ipsec-profile-policy002-manual] sa string-key inbound esp simple gfedcba

[SwitchC-ipsec-profile-policy002-manual] quit

5. Configure IPsec to protect IPv6 BGP packets between Switch A and Switch B:

# Configure Switch A.

[SwitchA] bgp 65008

[SwitchA-bgp-default] peer 1::2 ipsec-profile policy001

[SwitchA-bgp-default] quit

# Configure Switch B.

[SwitchB] bgp 65008

[SwitchB-bgp-default] peer 1::1 ipsec-profile policy001

[SwitchB-bgp-default] quit

6. Configure IPsec to protect IPv6 BGP packets between Router B and Switch C:

# Configure Switch C.

[SwitchC] bgp 65009

[SwitchC-bgp-default] peer ebgp ipsec-profile policy002

[SwitchC-bgp-default] quit

# Configure Switch B.

[SwitchB] bgp 65008

[SwitchB-bgp-default] peer ebgp ipsec-profile policy002

[SwitchB-bgp-default] quit

Verifying the configuration

# Display detailed information about IPv6 BGP peers on Switch B.

[SwitchB] display bgp peer ipv6 verbose

Peer: 1::1 Local: 2.2.2.2

Type: IBGP link

BGP version 4, remote router ID 1.1.1.1

BGP current state: Established, Up for 00h05m54s

BGP current event: KATimerExpired

BGP last state: OpenConfirm

Port: Local - 24896 Remote - 179

Configured: Active Hold Time: 180 sec Keepalive Time: 60 sec

Received : Active Hold Time: 180 sec

Negotiated: Active Hold Time: 180 sec Keepalive Time: 60 sec

Peer optional capabilities:

Peer supports BGP multi-protocol extension

Peer supports BGP route refresh capability

Peer supports BGP route AS4 capability

Address family IPv6 Unicast: advertised and received

InQ updates: 0, OutQ updates: 0

NLRI statistics:

Rcvd: UnReach NLRI 0, Reach NLRI 0

Sent: UnReach NLRI 0, Reach NLRI 3

Message statistics:

Msg type Last rcvd time/ Current rcvd count/ History rcvd count/

Last sent time Current sent count History sent count

Open 18:59:15-2013.4.24 1 1

18:59:15-2013.4.24 1 2

Update - 0 0

18:59:16-2013.4.24 1 1

Notification - 0 0

18:59:15-2013.4.24 0 1

Keepalive 18:59:15-2013.4.24 1 1

18:59:15-2013.4.24 1 1

RouteRefresh - 0 0

- 0 0

Total - 2 2

- 3 5

Maximum allowed prefix number: 4294967295

Threshold: 75%

Minimum time between advertisements is 15 seconds

Optional capabilities:

Multi-protocol extended capability has been enabled

Route refresh capability has been enabled

Peer preferred value: 0

IPsec profile name: policy001

Routing policy configured:

No routing policy is configured

Peer: 3::2 Local: 2.2.2.2

Type: EBGP link

BGP version 4, remote router ID 3.3.3.3

BGP current state: Established, Up for 00h05m00s

BGP current event: KATimerExpired

BGP last state: OpenConfirm

Port: Local - 24897 Remote - 179

Configured: Active Hold Time: 180 sec Keepalive Time: 60 sec

Received : Active Hold Time: 180 sec

Negotiated: Active Hold Time: 180 sec Keepalive Time: 60 sec

Peer optional capabilities:

Peer supports BGP multi-protocol extension

Peer supports BGP route refresh capability

Peer supports BGP route AS4 capability

Address family IPv6 Unicast: advertised and received

Maximum allowed prefix number: 4294967295

Threshold: 75%

Minimum time between advertisements is 30 seconds

Optional capabilities:

Multi-protocol extended capability has been enabled

Route refresh capability has been enabled

Peer preferred value: 0

IPsec profile name: policy002

Routing policy configured:

No routing policy is configured

Example: Configuring BGP RPKI

Network configuration

As shown in Figure 6, all switches run IPv6 BGP. Establish a TCP connection between Switch A and the RPKI server, and establish an IBGP connection between Switch A and Switch B.

Configure Switch A to advertise the BGP RPKI validation state to Switch B, and configure a routing policy to filter routes based on the validation state for Switch B.

Figure 6 Network diagram

‌

Procedure

1. Configure IPv6 addresses for interfaces and establish an IBGP connection between Switch A and Switch B. (Details not shown.)

2. Configure Switch A to establish a TCP connection to the RPKI server.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp-default] rpki

[SwitchA-bgp-default-rpki] server tcp 1::2

[RouterA-bgp-default-rpki-server] port 1234

[RouterA-bgp-default-rpki-server] quit

3. Enable BGP RPKI validation on Switch A.

[SwitchA-bgp-default-rpki] check-origin-validation

[SwitchA-bgp-default-rpki] quit

4. Apply the BGP RPKI validation state to optimal route selection.

[SwitchA-bgp-default] address-family ipv6

[SwitchA-bgp-default-ipv6] bestroute origin-as-validation

5. Configure Switch A to advertise the BGP RPKI validation state to peer 2001::2.

[SwitchA-bgp-default-ipv6] peer 2001::2 advertise-ext-community

[SwitchA-bgp-default-ipv6] peer 2001::2 advertise origin-as-validation

[SwitchA-bgp-default-ipv6] quit

[SwitchA-bgp-default] quit

6. Configure Switch B to permit routes with a BGP RPKI validation state of Valid:

# Configure a routing policy.

<SwitchB> system-view

[SwitchB] route-policy rpki_policy permit node 0

[SwitchB-route-policy-rpki_policy-0] if-match rpki valid

# Apply the routing policy.

<SwitchB> system-view

[SwitchB] bgp 100

[SwitchB-bgp-default] address-family ipv6

[SwitchB-bgp-default-ipv6] peer 2001::1 route-policy rpki_policy import

Verifying the configuration

# Display information about the connection between Switch A and the RPKI server.

[SwitchA] display bgp rpki server

Server VPN-index Port State Time ROAs(IPv4/IPv6)

1::2 0 1234 Establish 00:04:43 5/5

The output shows that Switch A has established a TCP connection to the RPKI server.

# Display the ROA information on Switch A.

[SwitchA] display bgp rpki table ipv6

Total number of entries: 5

Status codes: S - stale, U - used

Network Mask-range Origin-AS Server Status

2001:4860:: 32-32 100 1::2 U

2404:6800:: 32-32 100 1::2 U

2607:F8B0:: 28-28 4294967295 1::2 U

2A03:ACE0:: 40-40 4294967295 1::2 U

2001::1 64-64 200 1::2 U

The output shows that Switch A has obtained ROAs from the RPKI server.

# Display the BGP RPKI validation state on Switch A.

[SwitchA] display bgp routing-table ipv6 2001::1 64

BGP local router ID: 2.2.2.2

Local AS number: 100

Paths: 1 available, 1 best

BGP routing table information of 2001::1/64:

Imported route.

Original nexthop: 0.0.0.0

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

Org-validation : Valid

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, pref-val 32768

State : valid, local, best

IP precedence : N/A

QoS local ID : N/A

The route to 2001::1 matches the ROA with a prefix of 2001::1, a prefix length range of 64 to 64, and an origin AS number of 200. Therefore, the BGP RPKI validation state of the route to 2001::1 is Valid.

# On Switch B, display detailed information about the BGP IPv6 unicast route to network 2001::1.

[SwitchB] display bgp routing-table ipv6 2001::1 64

RR-client route.

From : 2001::1 64 (192.168.56.22)

Rely nexthop : 2001::1

Original nexthop: 2001::1

OutLabel : NULL

Ext-Community : <Origin Valid State: Valid >

RxPathID : 0x0

TxPathID : 0x0

Org-validation : Invalid

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

The output displays information about the BGP IPv6 unicast route to 2001::1 because Switch B permits routes with a BGP RPKI validation state of Valid.

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 not completed within the time, the GR restarter does not receive new routes. The GR restarter updates the RIB with the BGP routes already learned, and removes the aged routes from the RIB. The GR helper removes the stale routes.

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 End-Of-RIB indicates the end of route updates.

· 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.

· 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 BGP peers established through 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 BGP 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 BGP 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 7 Network diagram for BGP FRR

‌

After you configure FRR on Router B as shown in Figure 7, 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.

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 ECMP route. To use BFD sessions to detect nexthop reachability for BGP ECMP routes, configure the primary-path-detect bfd protocol-ecmp bgp or primary-path-detect bfd protocol-ecmp bgp4+ command. For more information about the two commands, see IP routing basics commands 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 route, perform one of the following tasks:

· Configure the primary-path-detect bfd command on the peer device of the primary route.

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

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

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

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

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

To use echo-mode BFD for nexthop connectivity detection, you can configure this feature only on the local device.

When another routing protocol (such as 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 next hop 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 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 8, 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 8 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 9, 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 9 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 10, configure BGP FRR so that when Link B fails, BGP uses Link A to forward traffic.

Figure 10 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 11, 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 11 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 12, configure BGP FRR so that when Link B fails, BGP uses Link A to forward traffic.

Figure 12 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 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

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

06-Layer 3—IP Routing Configuration Guide

Setting the TCP MSS for TCP connections

About this task

Restrictions and guidelines

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)

About this task

Restrictions and guidelines

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast address family)

About this task

Procedure (IPv4 unicast address family)

Procedure (IPv6 unicast address family)

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 address family)

Procedure (IPv6 unicast address family)

About this task

Restrictions and guidelines

Configuration tasks at a glance

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

Procedure

About this task

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure

About this task

Procedure

Resetting BGP sessions

About this task

Restrictions and guidelines

Procedure

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

About this task

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Restrictions and guidelines

Procedure (IPv4 peers)

Procedure (IPv6 peers)

Enabling keychain authentication for BGP peers

About this task

Procedure (IPv4 peers)

Procedure (IPv6 peers)

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

Restrictions and guidelines

Procedure (IPv4 unicast)

Procedure (IPv6 unicast)

Verifying RPKI server configuration and running status (IPv4 unicast address family)

S etting the TCP MSS for TCP connections