No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

### Reminder

To have a better experience, please upgrade your IE browser.

# CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 13

## The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring BGP

# Configuring BGP

## Configuring Basic BGP Functions

Before building a BGP network, you need to configure basic BGP functions.

Before configuring basic BGP functions, complete the following task:

• Configuring IP addresses for interfaces to ensure network-layer communication between neighbor nodes

### Configuration Flowchart

Perform the following operations in sequence and as required.

### (Optional) Configuring the Format of BGP 4-Byte AS Numbers

#### Context

By default, a BGP 4-byte AS number is displayed in dotted notation (x.y). To use integral 4-byte AS numbers, perform this configuration task to display 4-byte AS numbers as integers.

Assume that a 4-byte AS number in dotted notation is x.y. Following is the conversion relationship between an integral 4-byte AS number and a 4-byte AS number in dotted notation:

Integral 4-byte AS number = x x 65536 + y

For example, if a 4-byte AS number in dotted notation is 2.3, the corresponding integral 4-byte AS number is 131075 (2 x 65536 + 3).

Changing the format of 4-byte AS numbers will affect matching results of AS_Path regular expressions and extended community attribute filters. Therefore, if the system is using an AS_Path regular expression or an extended community attribute filter as an import or export policy, you must reconfigure an AS_Path regular expression using the ip as-path-filter command or an extended community attribute filter using the ip extcommunity-filter command after changing the format of 4-byte AS numbers. This reconfiguration ensures that routes match the import or export policy.
• If integral 4-byte AS numbers are configured, you must change 4-byte AS numbers in AS_Path regular expressions and extended community attribute filters to integral 4-byte AS numbers.
• If 4-byte AS numbers in dotted notation are configured, you must change 4-byte AS numbers in AS_Path regular expressions and extended community attribute filters to 4-byte AS numbers in dotted notation.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`as-notation plain`

BGP 4-byte AS numbers are configured to display in integers.

After you run the as-notation plain command, BGP 4-byte AS numbers are displayed in integers in display commands but are still displayed in dotted notation in the configuration file.

3. Run:

`commit`

The configuration is committed.

### Starting a BGP Process

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

BGP is started, the local AS number is specified, and the BGP view is displayed.

After BGP peers are configured, changing the router ID of a BGP peer resets BGP peer relationships.

3. Run:

`router-id ipv4-address`

A router ID of a BGP device is set.

By default, BGP prefers the router ID configured in the system view, highest loopback interface address, highest interface address, and then IP address 0.0.0.0.

To improve network stability, configure the IP address of a loopback interface as the router ID is recommended.

4. (Optional) Run:

`prefix memory-limit`

Configure BGP memory protection.

When the memory usage reaches the overload threshold, if the neighbor continues sending BGP routes, the device restarts and performs active/standby switchover. In this case, the system becomes unstable. After BGP memory protection is configured, the device does not receive routes and reports alarms when the memory usage reaches the overload threshold.

5. Run:

`commit`

The configuration is committed.

### Configuring BGP Peers

#### Context

During the configuration of BGP peers, if the AS number of the specified peer is the same as the local AS number, an IBGP peer is configured. If the AS number of the specified peer is different from the local AS number, an EBGP peer is configured. To enhance the stability of BGP connections, you are advised to use the reachable loopback interface addresses to establish BGP connections.

When loopback interface addresses are used to establish a BGP connection, run the peer connect-interface command on the both ends of the BGP connection to ensure the correctness of interfaces and addresses on the TCP connection. If the command is run on only one end, the BGP connection may fail to be established.

When loopback interface addresses are used to establish an EBGP connection, the peer ebgp-max-hop command with hop-count greater than or equal to 2 must be run. Otherwise, the EBGP connection cannot be established.

To perform the same configuration on a large number of peers, configure a BGP peer group according to (Optional) Configuring a BGP Peer Group to reduce the configuration workload.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`peer { ipv4-address | ipv6-address } as-number as-number`

The BGP peer is created.

By default, BGP does not create BGP peers.

4. (Optional) Run:

`peer ipv4-address connect-interface { interface-type interface-number [ ipv4-source-address ] | ipv4-source-address }`
or run:
`peer ipv6-address connect-interface interface-type interface-number [ ipv6-source-address ]`

A source interface and a source IP address are specified for the peer to establish a TCP connection.

By default, BGP uses the interface that is directly connected to the peer to establish a TCP connection.

5. (Optional) Run:

`peer { ipv4-address | ipv6–address | group-name } tcp-mss tcp-mss-number`

The TCP MSS value used when the local device establishes TCP connections with a peer or peer group is configured.

You can run the peer tcp-mss command to configure a TCP MSS value used for TCP connection establishment so that it is used to encapsulate BGP packets when the path MTU is unavailable. Such configuration improves network performance.

6. (Optional) Run:

`peer { ipv4-address | ipv6-address } ebgp-max-hop [ hop-count ]`

The maximum number of hops allowed for the establishment of an EBGP connection is set.

By default, the maximum number of hops allowed for an EBGP connection is 1. That is, an EBGP connection must be established on a directly connected physical link.

7. (Optional) Run:

`peer { ipv4-address | ipv6-address } description description-text`

The description of the peer is configured.

If a BGP peer group is configured on an IPv4 unicast network, steps 7 and 8 are not required. If a BGP peer group is configured on an IPv4 unicast network and an IPv6 unicast network, steps 8 and 9 are required.

8. (Optional) Run the following commands as required.
• Run:
`ipv4-family multicast`

The BGP-IPv4 multicast address family view is displayed.

• Run:
`ipv6-family [ unicast ]`

The BGP-IPv6 unicast address family view is displayed.

9. (Optional) Run:

`peer { ipv4-address | ipv6-address } enable`

MP-BGP is enabled on the BGP peers to configure them as MP-BGP peers.

10. Run:

`commit`

The configuration is committed.

### (Optional) Configuring a BGP Peer Group

#### Context

A large BGP network has a large number of peers. It is difficult to configure and maintain these peers. You can add the BGP peers with the same configurations to a BGP peer group and then configure the BGP peers in batches. This simplifies peer management and improves route advertisement efficiency.

• If a function is configured on a peer and its peer group, the function configured on the peer takes precedence over that configured on the peer group.
• When loopback interface addresses are used to establish a BGP connection, you are advertised to perform step 6 on the both ends of the BGP connection simultaneously to ensure the correct establishment of the connection. If step 6 is performed on only one end, the BGP connection may fail to be established.

• When loopback interface are used to establish an EBGP connection, step 7 is required and hop-count in the peer ebgp-max-hop command must be greater than or equal to 2. Otherwise, the EBGP connection cannot be established.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`group group-name [ external | internal ]`

A BGP peer group is created.

The AS number of an IBGP peer group is the local AS number. Therefore, step 4 is not required.

4. Run:

`peer group-name as-number as-number`

An AS number is configured for the EBGP peer group.

To add an EBGP peer to a peer group, configure the EBGP peer according to Configuring BGP Peers and then perform step 5.

To add an IBGP peer to a peer group, perform step 5. The system creates an IBGP peer in the BGP view and sets its AS number as the AS number of the peer group.

5. Run:

`peer { ipv4-address | ipv6-address } group group-name`

A peer is added to the peer group.

You can repeat step 5 to add multiple peers to a peer group.

6. (Optional) Run:

`peer group-name connect-interface interface-type interface-number [ ipv4-source-address ]`
or run:
`peer group-name connect-interface interface-type interface-number [ ipv6-source-address ]`

A source interface and a source IP address are specified for the peer to establish a TCP connection.

By default, BGP uses the interface that is directly connected to the peer to establish a TCP connection.

7. (Optional) Run:

`peer group-name ebgp-max-hop [ hop-count ]`

The maximum number of hops allowed for the establishment of an EBGP connection is set.

By default, the maximum number of hops allowed for an EBGP connection is 1. That is, an EBGP connection must be established on a directly connected physical link.

8. (Optional) Run:

`peer group-name description description-text`

The description is configured for the peer group.

If a BGP peer group is configured on an IPv4 unicast network, steps 9 and 10 are not required. If a BGP peer group is configured on an IPv4 unicast network and an IPv6 unicast network, steps 9 and 10 are required.

9. (Optional) Run the following commands as required.
• Run:
`ipv4-family multicast`

The BGP-IPv4 multicast address family view is displayed.

• Run:
`ipv6-family [ unicast ]`

The BGP-IPv6 unicast address family view is displayed.

10. Run:

`peer group-name enable`

MP-BGP is enabled on the BGP peers to configure them as MP-BGP peers.

11. Run:

`commit`

The configuration is committed.

### Configuring BGP to Import Routes

#### Context

BGP cannot discover routes and needs to import routes such as IGP routes into BGP routing tables so that the imported routes can be transmitted within an AS or between ASs. BGP imports routes in either import or network mode:

• In import mode, BGP imports IGP routes, including RIP, OSPF, and IS-IS routes, into BGP routing tables based on protocol type. To ensure the validity of imported IGP routes, BGP can also import static routes and direct routes in import mode.

• In network mode, BGP imports the routes in the IP routing table one by one to BGP routing tables. The network mode is more accurate than the import mode.

#### Procedure

• In import mode
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`import-route protocol [ process-id ] [ med med | route-policy route-policy-name ] *`

BGP is configured to import routes of other routing protocols.

5. (Optional) Run:

`default-route imported`

BGP is allowed to import default routes from the local IP routing table.

By default, BGP does not add default routes to BGP routing tables.

6. Run:

`commit`

The configuration is committed.

• In network mode
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

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

BGP is configured to import routes from the IPv4 or IPv6 routing table one by one.

5. Run:

`commit`

The configuration is committed.

### Checking the Configuration

#### Procedure

• Run the display bgp peer [ verbose ] command to check information about all BGP peers.
• Run the display bgp peer ipv4-address { log-info | verbose } command to check information about the specified BGP peer.
• Run the display bgp routing-table [ ipv4-address [ mask | mask-length ] ] command to check BGP routing information.
• Run the display bgp group [ group-name ] command to check information about the specified BGP peer group.
• Run the display bgp multicast peer [ [ peer-address ] verbose ] command to check information about the specified MBGP peer.
• Run the display bgp multicast group [ group-name ] command to displays the information about an MBGP peer group.
• Run the display bgp multicast network command to check the routing information that MBGP advertises.
• Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.

## Configuring BGP Security

Configuring connection authentication, BGP GTSM and RPKI for BGP peers can improve BGP network security.

Before configuring BGP security, complete the following task:

### Configuration Flowchart

You can perform the following configuration tasks as required. The following configuration tasks (excluding the task of checking the configuration) can be performed at any sequence.

### Configuring MD5 Authentication

#### Context

BGP uses TCP as the transmission protocol, and considers a packet valid as long as the source address, destination address, source port, destination port, and TCP sequence number of the packet are correct. However, most parameters in a packet may be easily obtained by attackers. To protect BGP from attacks, MD5 authentication or keychain authentication can be used between BGP peers to reduce the possibility of attacks. The MD5 algorithm is easy to configure, generates a single password that needs to be manually changed.

If simple is selected during the configuration of the MD5 authentication password, the password is saved in the configuration file in plain text. This brings security risks. It is recommended that you select cipher to save the password in cipher text.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`peer { ipv4-address | group-name | ipv6-address } password { cipher cipher-password | simple simple-password }`

The MD5 authentication password is set.

• To prevent the MD5 password set on BGP peers from being decrypted, update the MD5 password periodically.

• BGP MD5 authentication and BGP keychain authentication are mutually exclusive, and only one of them can be configured for a BGP peer.

4. Run:

`commit`

The configuration is committed.

### Configuring Keychain Authentication

#### Context

BGP uses TCP as the transmission protocol, and considers a packet valid as long as the source address, destination address, source port, destination port, and TCP sequence number of the packet are correct. However, most parameters in a packet may be easily obtained by attackers. To protect BGP from attacks, use MD5 authentication or keychain authentication between BGP peers to reduce the possibility of attacks. The keychain algorithm is complex to configure and generates a set of passwords. Keychain authentication allows automatically changing a password based on the configuration. Therefore, keychain authentication applies to networks requiring high security.

Before configuring BGP keychain authentication, configure a keychain corresponding to keychain-name. Otherwise, the TCP connection cannot be established. For details about configuring a keychain, see "Keychain Configuration" in the CX11x&CX31x&CX91x Series Configuration Guide - Security Configuration.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`peer { ipv4-address | group-name | ipv6-address } keychain keychain-name`

Keychain authentication is configured,

• You must configure keychain authentication on both BGP peers. Encryption algorithms and passwords configured on both peers must be the same; otherwise, the TCP connection cannot be established between BGP peers and BGP messages cannot be transmitted.
• BGP MD5 authentication and BGP keychain authentication are mutually exclusive, and only one of them can be configured for a BGP peer.

4. Run:

`commit`

The configuration is committed.

### Configuring BGP GTSM

#### Context

To protect a device against the attacks of forged BGP packets, you can configure GTSM to check whether the TTL value in the IP packet header is within the specified range. If the TTL value of a packet is within the specified range, the packet is allowed to pass through. Otherwise, the packet is discarded to protect the device.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

The configurations of GTSM and peer ebgp-max-hop affect the TTL values of BGP packets, which may cause a conflict between TTL values. Therefore, you can configure only one of the two functions for a peer or peer group.

3. Run:

`peer { group-name | ipv4-address | ipv6-address } valid-ttl-hops [ hops ]`

BGP GTSM is configured.

By default, GTSM is not configured on any BGP peer or peer group.

4. Run:

`commit`

The configuration is committed.

### Checking the Configuration

#### Procedure

• Run the display bgp peer verbose command to check authentication detailed information about the specified BGP peer.

## Simplifying IBGP Network Connections

Configuring a route reflector and a confederation on an IBGP network can simplify IBGP network connections.

Before simplifying IBGP network connections, complete the following configuration task:

### Configuration Flowchart

Perform the following configuration tasks as required.

### Configuring a BGP Route Reflector

#### Context

To ensure the connectivity between IBGP peers within an AS, you need to establish full-mesh connections between the IBGP peers. When there are many IBGP peers, it is costly to establish a fully-meshed network. A route reflector (RR) can solve this problem.

A cluster ID can help prevent routing loops between multiple RRs within a cluster and between clusters. When a cluster has multiple RRs, the same cluster ID must be configured for all the RRs within the cluster.

If full-mesh IBGP connections are established between clients of multiple RRs, route reflection between clients is not required and wastes bandwidth resources. In this case, prohibit route reflection between clients to reduce the network burden.

Within an AS, an RR transmits routing information and forwards traffic. When an RR connects to a large number of clients and non-clients, many CPU resources are consumed if the RR transmits routing information and forwards traffic simultaneously. This also reduces route transmission efficiency. To improve route transmission efficiency, prohibit BGP from adding preferred routes to IP routing tables on the RR to enable the RR only to transmit routing information.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family unicast`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`peer { ipv4-address | group-name | ipv6-address } reflect-client`

An RR and its client are configured.

5. (Optional) Run:

`reflector cluster-id cluster-id`

A cluster ID is configured for the RR.

By default, each RR uses its router ID as the cluster ID.

6. (Optional) Run:

`undo reflect between-clients`

Route reflection is prohibited between clients.

By default, route reflection is allowed between clients.

7. (Optional) Run:

`routing-table rib-only [ route-policy route-policy-name ]`

BGP is prohibited from adding preferred routes to IP routing tables.

By default, BGP adds preferred routes to IP routing tables.

8. Run:

`commit`

The configuration is committed.

#### Checking the Configuration

• Run the display bgp group [ group-name ] command to check information about the specified BGP peer group.
• Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-prefixes ] ] ] command to check routing information in a BGP routing table.
• Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.

### Configuring a BGP Confederation

#### Context

A confederation divides an AS into sub-ASs. Within each sub-AS, IBGP peers establish full-mesh connections or have an RR configured. Sub-ASs establish EBGP connections. On a large BGP network, configuring a confederation can reduce the number of IBGP connections, simplify routing policy management, and improve route advertisement efficiency.

Other devices may implement the confederation not in accordance with RFC 3065. You can configure confederation compatibility to make standard devices compatible with nonstandard devices.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`confederation id { as-number-plain | as-number-dot }`

A confederation ID is configured.

An old speaker that has a 2-byte AS number cannot be in the same confederation with a new speaker that has a 4-byte AS number. Otherwise, a routing loop may occur. This is because the AS4_Path attribute does not support confederations.

4. Run:

`confederation peer-as { as-number-plain | as-number-dot } &<1-32>`

A sub-AS number is configured for a confederation.

5. (Optional) Run:

`confederation nonstandard`

Confederation compatibility is configured.

By default, confederations comply with RFC 3065.

6. Run:

`commit`

The configuration is committed.

#### Checking the Configuration

• Run the display bgp peer [ ipv4-address ] verbose command to check detailed information about BGP peers.
• Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-prefixes ] ] ] command to check routing information in a BGP routing table.

## Configuring BGP Route Selection and Load Balancing

BGP has many route attributes. You can configure these attributes to change the route selection result.

Before configuring BGP route attributes, complete the following task:

### Configuration Flowchart

You can perform the following configuration tasks as required. The following configuration tasks (excluding the task of checking the configuration) can be performed at any sequence. For detailed route selection rules, see BGP Route Selection Rules and Load Balancing.

### Configuring the BGP Priority

#### Context

The routing protocols may share and select routing information because switch moduleses may run multiple dynamic routing protocols at the same time. The system sets a default priority for each routing protocol. When multiple routing protocols are used to select routes, the route selected by the routing protocol with a higher priority takes effect.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`preference { external internal local | route-policy route-policy-name }`

The BGP priority is set.

The default BGP priority is 255.

You cannot use the peer route-policy command on BGP peers to apply routing policies to set the BGP priority.

5. Run:

`commit`

The configuration is committed.

### Configuring the Next_Hop Attribute

#### Context

When an Autonomous System Boundary Router (ASBR) forwards the route learned from an EBGP peer to an IBGP peer, the ASBR does not change the next hop of the route by default. When the IBGP peer receives this route, it finds the next hop unreachable, sets the route to inactive, and does not use this route to guide traffic forwarding. To enable the IBGP peer to use this route to guide traffic forwarding, configure the ASBR to set its IP address as the next hop of the route when the ASBR forwards this route to the IBGP peer. After the IBGP peer receives the route from the ASBR, it finds the next hop of the route reachable, sets the route to active, and uses this route to guide traffic forwarding.

When a BGP route changes, BGP needs to iterate the indirect next hop of the route again. If no restriction is imposed on the iterated route, BGP may iterate the next hop to an incorrect forwarding path, causing traffic loss. To prevent traffic loss, configure routing policy-based route iteration to prevent traffic loss.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform either of the following operations as required:
• Run:

`peer { ipv4-address | group-name | ipv6-address } next-hop-local`

A BGP device is configured to set its IP address as the next hop when the device advertises routes to an IBGP peer or an IBGP peer group.

By default, a BGP device does not modify the next-hop address when advertising routes to its IBGP peers.

• Run:

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

Routing-policy-based next hop iteration is configured.

By default, routing-policy-based next hop iteration is not configured.

• Run the following command in the IPv4 unicast address family view:

`peer { ipv4-address | group-name } next-hop-invariable`

The device is prevented from changing the next-hop address of a route imported from an IGP before advertising the route to an IBGP peer.

By default, a device changes the next-hop address of a route imported from an IGP to the address of the interface connecting the device to its peer when advertising the route to an IBGP peer.

• Run the following command in the IPv4 unicast address family view:

`nexthop third-party`

The device is prevented from changing the next hop address of a route when the device advertises the route to a peer in the specified scenarios.

The default configurations are as follows:
• Before advertising a route that is learned from a directly connected peer to a directly connected EBGP peer, the device changes the next hop of the route to the IP address of the local interface that is used to establish the BGP peer relationship with the EBGP peer.
• Before advertising a locally imported route to a directly connected IBGP or EBGP peer, the device changes the next hop of the route to the IP address of the local interface that is used to establish the BGP peer relationship with the IBGP or EBGP peer.

The nexthop recursive-lookup route-policy route-policy-name command does not take effect for the routes received from direct connected EBGP peers.

5. Run:

`commit`

The configuration is committed.

### Configuring the PrefVal Attribute

#### Context

The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it is configured. When a BGP routing table contains multiple routes to the same destination, BGP prefers the route with the highest PrefVal.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`peer { group-name | ipv4-address | ipv6-address } preferred-value value`

The PrefVal attribute is configured for all the routes learned from a specified peer.

By default, the PrefVal of a route learned from a peer is 0.

5. Run:

`commit`

The configuration is committed.

### Configuring the Default Local_Pref Attribute

#### Context

The Local_Pref attribute is used to determine the optimal route for outgoing traffic of an AS. When a BGP device obtains multiple routes to the same destination address but with different next hops from different IBGP peers, the BGP device prefers the route with the highest Local_Pref.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`default local-preference local-preference`

The default Local_Pref attribute is configured.

By default, the Local_Pref attribute is 100.

5. Run:

`commit`

The configuration is committed.

### Configuring the AS_Path Attribute

#### Context

The AS_Path attribute records all the ASs that a route passes through from the source to the destination in the vector order. You can configure the AS_Path attribute to implement flexible route selection.

• Generally, BGP compares the AS_Path lists of routes and prefers the route with the shortest AS_Path list. When the AS_Path attribute is not required in route selection, configure BGP not to compare the AS_Path lists of routes during route selection.

• In most cases, BGP detects routing loops based on AS number. However, to ensure correct route transmission on a hub-and-spoke network, you need to configure all the BGP peers that VPN routes advertised from a hub CE to a spoke CE pass through to accept the routes with a repeated AS number.

• Public AS numbers can be used on the Internet, but private AS numbers cannot because they may cause routing loops. To prevent routing loops, configure the AS_Path attribute to carry only public AS numbers in EBGP Update messages.

• When the AS_Path attribute is reconstructed or summarized routes are generated, you can set the maximum number of AS numbers in the AS_Path attribute. Then a BGP device checks whether the number of AS numbers in the AS_Path attribute of a route exceeds the maximum value. If so, the BGP device discards the route.

• A device usually supports only one BGP process. This indicates that a device supports only one AS number. In some cases, for example, when network migration changes an AS number, you can set a fake AS number to ensure successful network migration.

• BGP checks the first AS number in the AS_Path list that is carried in the Update message sent by an EBGP peer. If the first AS number specifies the AS where the EBGP peer resides, BGP accepts the Update message. Otherwise, BGP rejects the Update message and interrupts the EBGP connection. If you do not want BGP to check the first AS number, disable BGP from checking the first AS number.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`route-policy route-policy-name { deny | permit } node node`

A node is configured for a route-policy, and the view of the route-policy is displayed.

3. (Optional) Configure matching rules for the route-policy to change only the community attributes of the routes meet matching rules.

By default, all routes meet matching rules. For details, see (Optional) Configuring an if-match Clause.

4. Run:

`apply as-path { as-number | 4as-number } &<1-10> { additive | overwrite | delete }`

The AS_Path attribute is set for BGP routes.

5. Run:

`quit`

6. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

7. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

8. Add the AS_Path attribute to routes.
• Run:
`peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name export`

The AS_Path attribute is added to the routes advertised to BGP peers or peer groups.

• Run:
`peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name import`

The AS_Path attribute is added to the routes received from BGP peers or peer groups.

• Run:
`import-route protocol [ process-id ] route-policy route-policy-name`

The AS_Path attribute is added to the routes imported by BGP in import mode.

• Run:
`network { ipv4-address [ mask | mask-length ] | ipv6-address prefix-length } route-policy route-policy-name`

The AS_Path attribute is added to the routes imported by BGP in network mode.

9. (Optional) Run one of the following commands to configure the AS_Path attribute as required.

• Run:
`bestroute as-path-ignore`

BGP is configured not to compare the AS_Path attributes of routes during route selection.

By default, BGP compares the AS_Path attributes of routes during route selection.

• Run:
`peer { ipv4-address | group-name | ipv6-address } allow-as-loop [ number ]`

Repeated local AS numbers are allowed in routes.

By default, repeated local AS number is not allowed.

• Run:
`peer { ipv4-address | group-name | ipv6-address } public-as-only`

BGP is configured to carry only public AS numbers in the AS_Path attribute in an EBGP Update message.

By default, the AS_Path attribute can carry both public and private AS numbers in an EBGP Update message.

• Return to the BGP view to configure the AS_Path attribute.
1. Run:
`quit`

2. (Optional) Run one of the following commands to configure the AS_Path attribute as required.
• Run:
`as-path-limit as-path-limit-num`

The maximum number of AS numbers in the AS_Path attribute is set.

By default, the maximum number of AS numbers in the AS_Path attribute is 255.

• Run:
`peer { ipv4-address | group-name | ipv6-address } local-as { as-number-plain | as-number-dot } [ dual-as ] [ prepend-global-as ] [ prepend-local-as ]`

A fake AS number is configured for an EBGP peer group.

By default, EBGP peers establish a connection using a real AS number.

Running the undo check-first-as command increases the probability of routing loops. Therefore, exercise caution when using this command.

• Run:
`undo check-first-as`

BGP is configured not to check the first AS number in the AS_Path list that is carried in the Update message sent by an EBGP peer.

By default, BGP checks the first AS number in the AS_Path list that is carried in the Update message sent by an EBGP peer.

When BGP is disabled from checking the first AS number, run the refresh bgp command in the user view if you want BGP to check the first AS number of received routes.

10. Run:

`commit`

The configuration is committed.

### Configuring the MED Attribute

#### Context

The multi-exit discriminator (MED) helps determine the optimal route for incoming traffic of an AS. It is similar to the metric used in IGP. When a BGP device obtains multiple routes to the same destination address but with different next hops from EBGP peers, the BGP device selects the route with the smallest MED value as the optimal route.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform one of the following operations as required:
• Run:

`default med med`

The default MED value is set.

By default, the MED is 0.

• Run:

`bestroute med-none-as-maximum`

BGP defines the MED value as the maximum value is a route does not have the MED attribute.

By default, BGP uses the default MED value when a route does not have the MED attribute.

• Run:

`compare-different-as-med`

BGP is allowed to compare the MED values of routes received from EBGP peers in any AS.

By default, BGP compares only the MEDs of the routes received from EBGP peers within the same AS.

5. Run:

`commit`

The configuration is committed.

### Configuring the BGP Community Attribute

#### Context

The Community attribute is a private BGP route attribute. It is transmitted between BGP peers and is not restricted within an AS. The Community attribute allows a group of BGP devices in multiple ASs to share the same routing policies, which simplifies routing policy applications and facilitates routing policy management and maintenance. A BGP device can add or change the community attributes of routes to be advertised.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`route-policy route-policy-name { deny | permit } node node`

A node is configured for a route-policy, and the view of the route-policy is displayed.

3. (Optional) Configure matching rules for the route-policy to change only the community attributes of the routes meet matching rules.

By default, all routes meet matching rules. For details, see (Optional) Configuring an if-match Clause.

4. Run either of the following commands to configure the Community attribute.

• Run:

`apply community { community-number | aa:nn | internet | no-advertise | no-export | no-export-subconfed } &<1-32> [ additive ]`

Common community attributes are configured for BGP routes.

This command allows you to configure a maximum of 32 community attributes.

• Run:

`apply extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16> [ additive ]`

An extended community attribute (route-target) is configured.

Extended community attributes are extensions to community attributes in services. Currently, only the route-target attribute is supported in VPN.

5. Run:

`quit`

6. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

7. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

8. Add the Community attribute to routes.
• Run:
`peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name export`

The Community attribute is added to the routes advertised to BGP peers or peer groups.

• Run:
`peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name import`

The Community attribute is added to the routes received from BGP peers or peer groups.

• Run:
`import-route protocol [ process-id ] route-policy route-policy-name`

The Community attribute is added to the routes imported by BGP in import mode.

• Run:
`network { ipv4-address [ mask | mask-length ] | ipv6-address prefix-length route-policy route-policy-name`

The Community attribute is added to the routes imported by BGP in network mode.

Step 9 is required only when the Community attribute needs to be added to the routes advertised to BGP peers or peer groups.

9. (Optional) Allow BGP to advertise community attributes when BGP adds community attributes to the routes advertised to BGP peers or peer groups.

• Run:

`peer { ipv4-address | group-name | ipv6-address } advertise-community`

BGP is allowed to advertise community attributes to BGP peers or peer groups.

By default, BGP does not advertise community attributes to any peer or peer group.

• Run:

`peer { ipv4-address | group-name | ipv6-address } advertise-ext-community`

BGP is allowed to advertise extended community attributes to BGP peers or peer groups.

By default, BGP does not advertise extended community attributes to any peer or peer group.

10. Run:

`commit`

The configuration is committed.

### Configuring BGP Load Balancing

#### Context

On large networks, there may be multiple valid routes to the same destination. BGP, however, advertises only the optimal route to its peers. This may result in unbalanced traffic on different routes. Configuring BGP load balancing better utilizes network resources and reduces network congestion.

Equal-cost BGP routes can be generated for traffic load balancing only when the first eight route attributes described in "BGP Route Selection Policies" are the same, and the AS_Path attributes are also the same. You can change load balancing rules by performing some configurations, for example, ignoring the comparison of the AS_Path attribute. When performing these configurations, ensure that these configurations do not result in routing loops.

If BGP load balancing is configured, the local device changes the next-hop address of routes to its address when advertising routes to IBGP peer groups, regardless of whether the peer next-hop-local command is used.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`maximum load-balancing [ ebgp | ibgp ] number  [ ecmp-nexthop-changed ]`

The maximum number of BGP routes to be used for load balancing is set.

By default, the maximum number of BGP routes to be used for load balancing is 1, indicating that load balancing is not performed.

• On a public network, if the routes to the same destination implement load balancing, the system will determine the type of the optimal route. If the optimal routes are IBGP routes, only IBGP routes carry out load balancing. If the optimal routes are EBGP routes, only EBGP routes carry out load balancing. This means that load balancing cannot be implemented among IBGP and EBGP routes with the same destination address.

• On an IPv4 multicast network, BGP compares the AS_Path attributes of the routes to be used for load balancing. In this case, step 5 is not supported.

Configuring BGP not to compare the AS_Path attributes of the routes to be used for load balancing may cause routing loops.

5. (Optional) Run:

`load-balancing as-path-ignore`

BGP is configured not to compare the AS_Path attributes of the routes to be used for load balancing.

By default, BGP compares the AS_Path attributes of the routes to be used for load balancing.

6. Run:

`commit`

The configuration is committed.

### Checking the Configuration

#### Procedure

• Run the display bgp routing-table different-origin-as command to check the routes with the same destination address but different origin ASs.
• Run the display bgp routing-table regular-expression as-regular-expression command to check information about routes that match the AS regular expression.
• Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-prefixes ] ] ] command to check routing information in a BGP routing table.
• Run the display bgp routing-table community [ community-number | aa:nn ] &<1-33> [ internet | no-advertise | no-export | no-export-subconfed ] * [ whole-match ] command to check routing information with the specified BGP community.
• Run the display bgp routing-table community-filter { { community-filter-name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-number } command to check information about routes matching a specified BGP community filter.
• Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.
• Run the display bgp multicast routing-table statistics command to check statistics about the MBGP routing table.

## Controlling the Receiving and Advertisement of BGP Routes

Controlling the receiving and advertisement of BGP routes can reduce the routing table size and improve network security.

Before controlling the receiving and advertisement of BGP routes, complete the following task:

### Configuration Flowchart

Figure 7-108 Flowchart of controlling the receiving and advertisement of BGP routes

### Configuring a Routing Policy

#### Context

Before controlling the receiving and advertisement of BGP routes, configure routing policies or filters of routing policies for route selection. For details, see "Routing Policy Configuration" in the CX11x&CX31x&CX91x Series Switch Modules Configuration Guide - IP Routing.

### Controlling the Advertisement of BGP Routes

#### Context

There are usually a large number of routes in a BGP routing table. Transmitting a great deal of routing information brings a heavy load to devices. Routes to be advertised need to be controlled to address this problem. You can configure devices to advertise only routes that these devices want to advertise or routes that their peers require. Multiple routes to the same destination may exist and traverse different ASs. Routes to be advertised need to be filtered in order to direct routes to specific ASs.

#### Procedure

• Configure a BGP device to advertise routes to all peers or peer groups.

You can configure a BGP device to filter routes to be advertised.

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp as-number`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform either of the following operations to configure the BGP device to advertise routes to all peers or peer groups:

• To filter routes based on an ACL, run the filter-policy { acl-number | acl-name acl-name } export [ protocol [ process-id ] ] command.
• To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-name export [ protocol [ process-id ] ] or the filter-policy ipv6-prefix ipv6-prefix-name export [ protocol [ process-id ] ] command.

If an ACL has been referenced in the filter-policy command but no VPN instance is specified in the ACL rule, BGP will filter routes including public and private network routes in all address families. If a VPN instance is specified in the ACL rule, only the data traffic from the VPN instance will be filtered, and no route of this VPN instance will be filtered.

5. Run:

`commit`

The configuration is committed.

• Configure a BGP device to advertise routes to a specific peer or peer group.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform any of the following operations to configure the BGP device to advertise routes to a specific peer or peer group:

• To filter routes based on an ACL, run the peer { group-name | ipv4-address | ipv6-address } filter-policy { acl-number | acl-name acl-name | acl6-number | acl6-name acl6-name } export command.

• To filter routes based on an IP prefix list, run the peer { ipv4-address | group-name } ip-prefix ip-prefix-name export or the peer { group-name | ipv6-address } ipv6-prefix ipv6-prefix-name export command.

• To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-name | ipv6-address } as-path-filter { as-path-filter-number | as-path-filter-name } export command.

• To filter routes based on a route-policy, run the peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name export command.

The routing policy applied in the peer route-policy export command does not support a specific interface as one matching rule. That is, the routing policy does not support the if-match interface command.

5. Run:

`commit`

The configuration is committed.

### Controlling the Receiving of BGP Routes

#### Context

When a BGP device is attacked or network configuration errors occur, the BGP device will receive a large number of routes from its neighbor. As a result, many device resources are consumed. Therefore, the administrator must limit the resources used by the device based on network planning and device capacity. BGP provides peer-based route control to limit the number of routes to be sent by a neighbor. This addresses the preceding problem.

#### Procedure

• Configure a BGP device to receive routes from all its peers or peer groups.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform either of the following operations to configure the BGP device to filter the routes received from all its peers or peer groups:

• To filter routes based on an ACL, run the filter-policy { acl-number | acl-name acl-name } import or the filter-policy { acl6-number | acl6-name acl6-name } import command.
• To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-name import or the filter-policy ipv6-prefix ipv6-prefix-name import command.

If an ACL has been referenced in the filter-policy command but no VPN instance is specified in the ACL rule, BGP will filter routes including public and private network routes in all address families. If a VPN instance is specified in the ACL rule, only the data traffic from the VPN instance will be filtered, and no route of this VPN instance will be filtered.

5. Run:

`commit`

The configuration is committed.

• Configure a BGP device to receive routes from a specific peer or peer group.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp as-number`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Perform any of the following operations to configure the BGP device to filter the routes received from a specific peer or peer group:

• To filter routes based on an ACL, run the peer { group-name | ipv4-address | ipv6-address } filter-policy { acl-number | acl-name acl-name | acl6-number | acl6-name acl6-name } import command.

• To filter routes based on an IP prefix list, run the peer { ipv4-address | group-name } ip-prefix ip-prefix-name import or the peer { group-name | ipv6-address } ipv6-prefix ipv6-prefix-name import command.

• To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-name | ipv6-address } as-path-filter { as-path-filter-number | as-path-filter-name } import command.

• To filter routes based on a route-policy, run the peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name import command.

The routing policy applied in the peer route-policy import command does not support a specific interface as one matching rule. That is, the routing policy does not support the if-match interface command.

If the number of routes received by the local device exceeds the upper limit and the peer route-limit command is used for the first time, the local device and its peer reestablish the peer relationship, regardless of whether alert-only is set.

5. (Optional) Run:

`peer { group-name | ipv4-address } route-limit limit [ percentage ] [ alert-only | idle-forever | idle-timeout times ]`

The maximum number of routes that can be received from the peer or peer group is set.

6. Run:

`commit`

The configuration is committed.

### Configuring BGP Soft Reset

#### Context

After changing a BGP import policy, you must reset BGP connections for the new import policy to take effect. This, however, interrupts these BGP connections temporarily. BGP route-refresh allows the system to softly reset BGP connections to refresh a BGP routing table without tearing down any BGP connection. If a device's peer does not support route-refresh, configure the device to remain all routing updates received from the peer so that the device can refresh its routing table without tearing down the BGP connection with the peer.

#### Procedure

• If a device's peer supports route-refresh, configure the device to softly reset the BGP connection with the peer and update the BGP routing table.

1. Run:
`system-view`

The system view is displayed.

2. Run:
`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. (Optional) Run:
`peer { ipv4-address | group-name } capability-advertise route-refresh`
or run:
`peer ipv6-address capability-advertise { 4-byte-as | route-refresh }`

Route-refresh is enabled.

By default, route-refresh is enabled.

4. Run:
`commit`

The configuration is committed.

5. Run:
`quit`

6. Run:
`quit`

7. Run:
`refresh bgp [ vpn-instance vpn-instance-name ipv4-family ] { all | ipv4-address | group group-name | external | internal } { export | import }`
or run :
`refresh bgp ipv6 { all | group group-name | ipv6-address | external | internal } { export | import }`

BGP soft reset is configured.

• If a device's peer does not support route-refresh, configure the device to remain all routing updates received from the peer so that the device can refresh its routing table without tearing down the BGP connection with the peer.

1. Run:
`system-view`

The system view is displayed.

2. Run:
`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

If the peer keep-all-routes command is used on the device for the first time, the sessions between the device and its peers are reestablished.

The refresh bgp command takes effect when the peer keep-all-routes command is used on the device supporting route-refresh.

4. Run:
`peer { ipv4-address | group-name | ipv6-address } keep-all-routes`

The device is configured to store all the routing updates received from its peers or peer groups.

By default, the device stores only the routing updates that are received from peers or peer groups and match a configured import policy.

5. Run:
`commit`

The configuration is committed.

### Checking the Configuration

#### Procedure

• Run the display ip as-path-filter [ as-path-filter-number | as-path-filter-name ] command to check information about a configured AS_Path filter.
• Run the display ip community-filter [ basic-comm-filter-num | adv-comm-filter-num | comm-filter-name ] command to check information about a configured community filter.
• Run the display ip extcommunity-filter [ basic-extcomm-filter-num | advanced-extcomm-filter-num | extcomm-filter-name ] command to check information about a configured extcommunity filter.
• Run the display bgp routing-table as-path-filter as-path-filter { as-path-filter-number | as-path-filter-name } command to check information about routes matching a specified AS_Path filter.
• Run the display bgp routing-table community-filter { { community-filter-name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-number } command to check information about routes matching a specified BGP community filter.
• Run the display bgp routing-table peer ipv4-address received-routes [ active ] [ statistics ] command to check information about routes received by a BGP device from its peers.
• Run the display bgp multicast routing-table different-origin-as command to check information about MBGP routes with different origin ASs.
• Run the display bgp multicast routing-table regular-expression as-regular-expression to check information about MBGP routes matching the AS regular expression.
• Run the display bgp multicast routing-table as-path-filter { as-path-filter-number | as-path-filter-name } command to check information about MBGP routes matching the AS_Path filter.
• Run the display bgp multicast routing-table community-filter { { community-filter-name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-number } command to check information about routes matching a specified MBGP community filter.
• Run the display bgp multicast routing-table peer peer-address { advertised-routes | received-routes [ active ] } [ statistics ] command to check information about routes that are sent by and received from the specified MBGP peer.
• Run the display bgp multicast network command to check the routing information that MBGP advertises.

## Adjusting the BGP Network Convergence Speed

You can configure BGP timers, disable rapid EBGP connection reset, and configure BGP route dampening to speed up BGP network convergence and improve BGP security.

Before configuring adjusting the BGP network convergence speed, complete the following task:

### Configuration Flowchart

You can perform the following configuration tasks as required. The following configuration tasks (excluding the task of checking the configuration) can be performed at any sequence.

### Configuring a BGP ConnectRetry Timer

#### Context

After BGP initiates a TCP connection, the ConnectRetry timer will be stopped if the TCP connection is established successfully. If the first attempt to establish a TCP connection fails, BGP tries again to establish the TCP connection after the ConnectRetry timer expires.
• Setting a short ConnectRetry interval reduces the period BGP waits between attempts to establish a TCP connection. This speeds up the establishment of the TCP connection.
• Setting a long connectRetry interval suppresses routing flapping caused by peer relationship flapping.

A ConnectRetry timer can be configured either for all peers or peer groups, or for a specific peer or peer group. A ConnectRetry timer configured for a specific peer takes precedence over that configured for the peer group of this peer. In addition, a ConnectRetry timer configured for a specific peer or peer group takes precedence over that configured for all peers or peer groups.

#### Procedure

• Configure a BGP ConnectRetry timer for all peers or peer groups.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`timer connect-retry connect-retry-time`

A BGP ConnectRetry timer is configured for all peers or peer groups.

By default, the ConnectRetry timer value is 32s.

4. Run:

`commit`

The configuration is committed.

• Configure a ConnectRetry timer for a specific peer or peer group.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`peer { group-name | ipv4-address | ipv6-address } timer connect-retry connect-retry-time`

A ConnectRetry timer is configured for a specific peer or peer group.

By default, the ConnectRetry timer value is 32s.

4. Run:

`commit`

The configuration is committed.

### Configuring BGP Keepalive and Hold Timers

#### Context

Keepalive messages are used by BGP to maintain peer relationships.

• If short Keepalive time and holdtime are set, BGP can detect a link fault quickly. This speeds up BGP network convergence, but increases the number of Keepalive messages on the network and loads of devices, and consumes more network bandwidth resources.
• If long Keepalive time and holdtime are set, the number of Keepalive messages on the network is reduced, loads of devices are reduced, and fewer network bandwidth are consumed. If the Keepalive time is too long, BGP is unable to detect link status changes in a timely manner. This is unhelpful for implementing rapid BGP network convergence and may cause many packets to be lost.

Keepalive and hold timers can be configured either for all peers or peer groups, or for a specific peer or peer group. Keepalive and hold timers configured for a specific peer take precedence over those configured for the peer group of this peer. In addition, Keepalive and hold timers configured for a specific peer or peer group take precedence over those configured for all peers or peer groups.

Changing timer values using the timer command or the peer timer command interrupts BGP peer relationships between switch moduless.

Setting the Keepalive time to 20s is recommended. If the Keepalive time is smaller than 20s, sessions between peers may be closed.

#### Procedure

• Configure BGP timers for all peers or peer groups.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`timer keepalive keepalive-time hold hold-time`

BGP timers are configured.

The proper maximum interval at which Keepalive messages are sent is one third the holdtime. By default, the Keepalive time is 60s and the holdtime is 180s.

4. Run:

`commit`

The configuration is committed.

• Configure BGP timers for a specific peer or peer group.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp as-number`

The BGP view is displayed.

3. Run:

`peer { ipv4-address | group-name | ipv6-address } timer keepalive keepalive-time hold hold-time`

The Keepalive and hold timers are configured for a specific peer or peer group.

The proper maximum interval at which Keepalive messages are sent is one third the holdtime. By default, the Keepalive time is 60s and the holdtime is 180s.

4. Run:

`commit`

The configuration is committed.

### Configuring a Update Message Timer

#### Context

BGP does not periodically update a routing table. When BGP routes change, BGP updates the changed BGP routes in the BGP routing table by sending Update messages.

• If a short Update message interval is set, BGP can fast detect route changes. This speeds up BGP network convergence, but increases the number of Update messages on the network and loads of devices, and consumes more network bandwidth resources.
• If a long Update message interval is set, the number of Update messages on the network is reduced, loads of devices are reduced, and fewer network bandwidth are consumed. This avoids network flapping. If the Update message interval is too long, BGP is unable to detect route changes in a timely manner. This is unhelpful for implementing rapid BGP network convergence and may cause many packets to be lost.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`peer { ipv4-address | group-name | ipv6-address } route-update-interval interval`

An Update message timer is configured.

By default, the interval at which Update messages are sent to IBGP peers is 15s, and the interval at which Update messages are sent to EBGP peers is 30s.

5. Run:

`commit`

The configuration is committed.

### Disabling Rapid EBGP Connection Reset

#### Context

Rapid EBGP connection reset is enabled by default. This allows BGP to immediately respond to a fault on an interface and delete the direct EBGP sessions on the interface without waiting for the hold timer to expire and implements rapid BGP network convergence.

If the status of an interface used to establish an EBGP connection changes frequently, the EBGP session will be deleted and reestablished repeatedly, causing network flapping. Rapid EBGP connection reset can be disabled in such a situation. BGP will delete direct EBGP sessions on the interface until the hold timer expires. This suppresses BGP network flapping, helps implement rapid BGP network convergence, and reduces network bandwidth consumption.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`undo ebgp-interface-sensitive`

Rapid EBGP connection reset is disabled.

By default, rapid EBGP connection reset is enabled.

Rapid EBGP connection reset enables BGP to quickly respond to interface faults but does not enable BGP to quickly respond to interface recovery. After the interface recovers, BGP uses its state machine to restore relevant sessions.

Rapid EBGP connection reset is disabled in a situation where the status of an interface used to establish an EBGP connection changes frequently. If the status of the interface becomes stable, run the ebgp-interface-sensitive command to enable rapid EBGP connection reset to implement rapid BGP network convergence.

4. Run:

`commit`

The configuration is committed.

### Configuring BGP Route Dampening

#### Context

A route is considered to be flapping when it repeatedly appears and then disappears in the routing table. BGP generally applies to complex networks where routes change frequently. Frequent route flapping consumes lots of bandwidths and CPU resources and even affects normal network operation. BGP route dampening prevents frequent route flapping.

BGP can differentiate routes based on policies and use different route dampening parameters to suppress different routes. For example, on a network, you can set a long suppression time for routes with a long mask and set a short suppression time for routes with a short mask (such as 8-bit mask).

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-name ] *`

BGP route dampening parameters are configured.

5. Run:

`commit`

The configuration is committed.

### Checking the Configuration

#### Procedure

• Run the display bgp peer [ verbose ] command to check information about all BGP peers.
• Run the display bgp group [ group-name ] command to check information about the specified BGP peer group.
• Run the display bgp routing-table dampened command to check dampened BGP routes.
• Run the display bgp routing-table dampening parameter command to check configured BGP route dampening parameters.
• Run the display bgp routing-table flap-info [ regular-expression as-regular-expression | as-path-filter as-path-filter-number | network-address [ { mask | mask-length } [ longer-match ] ] ] command to check route flapping statistics.
• Run the display bgp multicast routing-table dampened command to check dampened MBGP routes.
• Run the display bgp multicast routing-table dampening parameter command to check MBGP route dampening parameters.
• Run the following commands to check statistics about flapping MBGP routes.

• display bgp multicast routing-table flap-info [ ip-address [ mask [ longer-match ] | mask-length [ longer-match ] ] | as-path-filter as-path-filter-number | regular-expression as-regular-expression ]
• display bgp multicast routing-table flap-info regular-expression as-regular-expression

## Configuring BGP Reliability

You can configure association between BGP and BFD, BGP Auto FRR, and BGP GR to speed up BGP network convergence and improve BGP reliability.

Before configuring BGP reliability, complete the following task:

### Configuration Procedures

You can perform the following configuration tasks as required. The following configuration tasks can be performed at any sequence.

### Configuring BFD for BGP

#### Context

BGP periodically sends Keepalive messages to its peers to detect the status of its peers. It takes more than 1 second for this detection mechanism to detect a fault. When data is transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot meet high reliability requirements of carrier-class networks. Association between BGP and BFD can solve this problem. BFD is a millisecond-level fault detection mechanism. It can detect faults on the link between BGP peers within 50 ms. Therefore, BFD can speed up BGP route convergence, ensures fast link switching, and reduces traffic loss.

When a peer joins a peer group on which BFD is enabled, BFD also takes effect on the peer and a BFD session is created on the peer. To prevent BFD from taking effect on the peer, run the peer bfd block command.

By default, Huawei devices establish multi-hop IBGP sessions with each other. When a Huawei device communicates with a non-Huawei device that establishes a single-hop IBGP session by default, you are advised to configure only association between IGP and BFD or association between IBGP and BFD.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bfd`

Global BFD is enabled on the local device.

3. Run:

`quit`

4. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

5. Run:

`peer { group-name | ipv4-address | ipv6-address } bfd enable`

BFD is configured for the peer or peer group, and default BFD parameters are used to establish BFD sessions.

If BFD is configured for a peer group, BFD sessions are created for the peers on which the peer bfd block command is not used.

6. Run:

`peer { group-name | ipv4-address | ipv6-address } bfd { min-tx-interval min-tx-interval | min-rx-interval min-rx-interval | detect-multiplier multiplier } *`

BFD session parameters are configured.

7. (Optional) Run:

`peer { ipv4-address | ipv6-address } bfd block`

The peer is disabled from inheriting the BFD function of the peer group to which the peer belongs.

• BFD sessions are established when they are in Established state.
• If BFD parameters are configured on a peer, BFD sessions are established using these parameters.
• The peer { ipv4-address | ipv6-address } bfd block and peer { ipv4-address | ipv6-address } bfd enable commands are mutually exclusive.

8. Run:

`commit`

The configuration is committed.

#### Checking the Configuration

• Run the display bgp bfd session { [ vpnv4 vpn-instance vpn-instance-name ] peer ipv4-address | all } command to check information about the BFD sessions established between BGP peers.

• Run the display bgp [ vpnv4 vpn-instance vpn-instance-name ] peer [ [ ipv4-address ] verbose ] command to check information about BGP peers.

• Run the display bgp group [ group-name ] command to check information about the specified BGP peer group.

• Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ group-name ] command to check information about the BGP VPNv4 peer group.

### Configuring BGP Auto FRR

#### Context

On a traditional IP network, it often takes the routing system several seconds to complete route convergence after a link fault is detected. This convergence speed cannot meet requirements of the services that require a low delay and low packet loss ratio because it may lead to service interruption. For example, Voice over Internet Protocol (VoIP) services are only tolerant of millisecond-level interruption. BGP Auto Fast Reroute (FRR) implements route convergence at the millisecond level after a fault is detected at the physical layer or link layer. BGP Auto FRR reduces the impact of link faults on services.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family unicast`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`auto-frr`

BGP Auto FRR is enabled for unicast routes.

By default, BGP Auto FRR is not enabled for unicast routes.

5. Run:

`commit`

The configuration is committed.

#### Checking the Configuration

• Run the display ip routing-table [ vpn-instance vpn-instance-name ] [ ipv4-address [ mask | mask-length ] [ longer-match ] ] verbose command to check backup forwarding information about routes in the IP routing table.

### Configuring the BGP GR Function

#### Context

BGP restart causes peer relationships reestablishment and traffic interruption. Graceful restart (GR) ensures uninterrupted traffic interruption in the case of BGP restart.

Currently, devices support only the GR helper function, and the GR restarter function is implemented using non-stop routing (NSR). NSR does not need to be configured.

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Run:

`graceful-restart`

BGP GR is enabled.

By default, BGP GR is disabled.

4. (Optional) Run:

`graceful-restart timer wait-for-rib timer`

The time during which the restarting speaker and receiving speaker wait for End-of-RIB messages is set.

By default, the time for waiting for End-of-RIB messages is 600 seconds.

5. (Optional) Run:

`graceful-restart peer-reset`

The device is enabled to reset a BGP session in GR mode.

By default, a device is not enabled to reset a BGP connection in GR mode.

6. Run:

`commit`

The configuration is committed.

#### Checking the Configuration

• Run the display bgp peer verbose command to check detailed information about BGP GR.

## Configuring BGP Route Summarization

On IPv4 networks, BGP supports automatic route summarization and manual route summarization. Manual route summarization takes precedence over automatic route summarization.

Before configuring BGP route summarization, complete the following task:

#### Procedure

• Configure automatic route summarization.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

4. Run:

`summary automatic`

BGP summarizes subnet routes based on natural mask.

The command summarizes the routes imported by BGP. These routes can be direct routes, static routes, RIP routes, OSPF routes, or IS-IS routes. The command, however, is invalid for the routes imported using the network command.

5. Run:

`commit`

The configuration is committed.

• Configure manual route summarization.
1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp as-number`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

4. Perform any of the following operations to configure manual route summarization.

• To advertise the summarized routes and specific routes, run the aggregate ipv4-address { mask | mask-length } command.

• To advertise only the summarized routes, run the aggregate ipv4-address { mask | mask-length } detail-suppressed command.

• To advertise the summarized routes and specific routes that meet the specified route-policy, run the aggregate ipv4-address { mask | mask-length } suppress-policy route-policy-name command.

• To advertise the summarized routes of which the AS_Set attribute helps detect routing loops, run the aggregate ipv4-address { mask | mask-length } as-set command.

• To set attributes for the summarized routes, run the aggregate ipv4-address { mask | mask-length } attribute-policy route-policy-name command.

• To summarize the specific routes that meet the specified route-policy, run the aggregate ipv4-address { mask | mask-length } origin-policy route-policy-name command.

Manual route summarization is valid for the routes in the local BGP routing table. For example, if the local BGP routing table does not contain routes with mask longer than 16 bits, such as 10.1.1.1/24, BGP will not generate an aggregated route for it even if the aggregate 10.1.1.1 16 command is used.

5. Run:

`commit`

The configuration is committed.

### Checking the Configuration

• Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-prefixes ] ] ] command to check information about summarized routes.

• Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.

## Configuring BGP to Advertise Default Routes to Peers

If a BGP device needs to send multiple routes to its peer, the BGP device can be configured to send only a default route with the local address as the next-hop address to its peer, regardless of whether there are default routes in the local routing table. This function reduces the number of network routes and saves memory and network resources.

Before configuring BGP to send default routes to peers, complete the following task:

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

The BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.

• Run:

`ipv4-family { unicast | multicast }`

The IPv4 address family view is displayed.

• Run:

`ipv6-family [ unicast ]`

The IPv6 address family view is displayed.

4. Run:

`peer { group-name | ipv4-address | ipv6-address } default-route-advertise [ route-policy route-policy-name ] [ conditional-route-match-all { ipv4-address1 { mask1 | mask-length1 } } &<1-4> | conditional-route-match-any { ipv4-address2 { mask2 | mask-length2 } } &<1-4> ]`

A BGP device is configured to send default routes to a peer or peer group.

The conditional-route-match-all and conditional-route-match-any keywords are not supported in the IPv4 multicast address family view and the IPv6 address family view.

5. Run:

`commit`

The configuration is committed.

### Checking the Configuration

• Run the display bgp routing-table [ ipv4-address [ mask | mask-length [ longer-prefixes ] ] ] command to check received BGP default routes.

• Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check received MBGP default routes.

## Configuring MP-BGP

Multiprotocol BGP (MP-BGP) enables BGP to support IPv4 unicast networks, IPv4 multicast networks, and IPv6 unicast networks.

Before configuring MP-BGP, complete the following task:

#### Procedure

1. Run:

`system-view`

The system view is displayed.

2. Run:

`bgp { as-number-plain | as-number-dot }`

BGP is started, the local AS number is specified, and the BGP view is displayed.

3. Enter the corresponding address family view based on network type to configure BGP devices on networks.
• Run:
`ipv4-family unicast`

The BGP-IPv4 unicast address family view is displayed.

• Run:
`ipv4-family vpnv4`

The BGP-VPNv4 address family view is displayed.

• Run:
`ipv4-family vpn-instance vpn-instance-name`

The BGP-VPN instance IPv4 address family view is displayed.

• Run:
`ipv4-family multicast`

The BGP-IPv4 multicast address family view is displayed.

• Run:
`ipv6-family unicast`

The BGP-IPv6 unicast address family view is displayed.

• Different extended BGP functions must be configured in their respective address family views, while common BGP functions are configured in the BGP view.

• The Switch Module supports the following MBGP features: basic BGP functions, BGP security (MD5 authentication and keychain authentication), simplifying IBGP network connections (route reflector and confederation), BGP route selection and load balancing, controlling the receiving and advertisement of BGP routes, adjusting the BGP network convergence speed, BGP reliability, BGP route summarization, and advertising default routs to peers.

Translation
Updated: 2019-12-13

Document ID: EDOC1000041694

Views: 78326