01-10 BGP Configuration

HUAWEI NetEngine40E Universal Service Router
Configuration Guide - IP Routing 10 BGP Configuration
10 BGP Configuration
About This Chapter
Border Gateway Protocol (BGP) is applicable to complicated large-scale networks and used
to transmit routing information between ASs.
10.1 BGP Overview

The Border Gateway Protocol (BGP) advertises and maintains a large number of routes
between autonomous systems (ASs).
10.2 BGP Precautions
10.3 Configuring Basic BGP Functions
Before building a BGP network, you must configure basic BGP functions.
10.4 Configuring BGP Route Attributes
Configuring route attributes can change route selection results.
10.5 Using Routing Policy to Filter the BGP Routes to Be Advertised
BGP is used to transmit routing information. BGP advertises only the wanted routes which
match a routing policy and modifies route attributes to direct network traffic properly.
10.6 Using Routing Policy to Filter the BGP Routes to Be Received
BGP is used to transmit routing information. BGP accepts only the wanted routes which can
be filtered or applied routing policy flexibly, and modifies route attributes to direct network
traffic properly.
10.7 Using XPL to Filter the BGP Routes to Be Advertised
A BGP device can use a route-filter to filter the routes to be advertised and modify route
attributes to control the network traffic forwarding path.
10.8 Using XPL to Filter the BGP Routes to Be Received
A BGP device can use a route-filter to filter the routes to be received and modify route
10.9 Configuring BGP Route Aggregation
Configuring BGP Route Aggregation on a device can reduce the sizes of routing tables on the
peers of the device.
10.10 Configuring a BGP Peer Group
Issue 02 (2018-06-20) Huawei Proprietary and Confidential 781

Copyright © Huawei Technologies Co., Ltd.
Configuring BGP peer groups simplifies the BGP network configuration and improves the
route advertisement efficiency.
10.11 Configuring a BGP Route Reflector
By configuring a BGP route reflector (RR), you can avoid fully meshed connections between
multiple IBGP peers.
10.12 Configuring a BGP Confederation
On a large BGP network, configuring a BGP confederation reduces the number of IBGP
connections and simplifies routing policy management, which increases the route
advertisement efficiency.
10.13 Configuring BGP Community Attributes
Community attributes simplifies routing policy management.
10.14 Configuring Prefix-based BGP ORF
Prefix-based BGP ORF enables a device to send its peer the local prefix-based import policy
so that the peer can use the policy to filter routes before sending them to the local device.
10.15 Adjusting the BGP Network Convergence Speed
You can adjust the BGP network convergence speed by adjusting BGP peer connection
parameters to adapt to changes on large-scale networks.
10.16 Configuring BGP Route Dampening
BGP route dampening can be configured to suppress unstable routes.
10.17 Configuring a BGP Device to Send a Default Route to Its Peer
After a BGP device is configured to send a default route to its peer, the BGP device sends a
default route with the local address as the next hop address to the specified peer, regardless of
whether there are default routes in the local routing table, which reduces the number of routes
on the network.
10.18 Configuring a Device to Advertise BGP Supernet Unicast Routes to BGP Peers
This section describes how to configure a Border Gateway Protocol (BGP) device to advertise
BGP supernet unicast routes to BGP peers.
10.19 Configuring BGP Load Balancing
BGP load balancing improves network resource usage and reduces network congestion.
10.20 Configuring Path MTU Auto Discovery
Path MTU auto discovery allows BGP to discover the smallest MTU value on a path so that
BGP messages are transmitted based on the path MTU. This function improves transmission
efficiency and BGP performance.
10.21 Configuring BGP Next Hop Iteration Based on a Route-Policy
Configuring BGP next hop iteration based on a route-policy prevents traffic loss if routes
changes.
10.22 Configuring AIGP value on a Route-Policy
BGP prefers the route with the smallest AIGP value during BGP route selection.
10.23 Configuring the POPGO Function
After the POPGO function is configured on the egress of a BGP LSP, the egress forwards
each data packet received from the LSP through the outbound interface found in the ILM
based on the label information carried in the packet.
10.24 Configuring BFD for BGP
BFD for BGP speeds up fault detection and therefore increases the route convergence speed.

10.25 Configuring BGP Auto FRR

BGP Auto FRR, a protection measure against link faults, applies to the network topology with
both primary and backup links. It can be configured for services that are quite sensitive to the
packet loss and delay.
10.26 Configuring the BGP Next Hop iteration Delayed Response
Configuring the BGP next hop iteration delayed response can minimize traffic loss during
route changes.
10.27 Configuring the BGP GR Helper
You can configure a device to function as a Graceful Restart (GR) Helper to help a BGP peer
with the BGP GR process.
10.28 Configuring BGP Best-external
Border Gateway Protocol (BGP) Best-external can speed up route convergence if the primary
link fails.
10.29 Configuring BGP ADD-PATH
BGP ADD-PATH allows a route reflector (RR) to send two or more routes with the same
prefix to a specified IBGP peer. These routes can back up each other or load-balance traffic,
which improves network reliability.
10.30 Configuring BMP
The BGP Monitoring Protocol (BMP) monitors BGP running status, such as the status of
BGP peer relationship establishment and termination and route updates.
10.31 Configuring BGP Iteration Suppression in Case of Next Hop Flapping
BGP iteration suppression in case of next hop flapping prevents the system from frequently
processing changes of a large number of routes that are iterated to a flapping next hop, which
reduces system resource consumption and CPU usage.
10.32 Configuring BGP-LS
BGP-LS provides a simple and efficient method of collecting topology information.
10.33 Improving BGP Security
To improve BGP network security, you can configure BGP authentication and GTSM on the
BGP network.
10.34 Configuring BGP Extensions
Configuring BGP extensions enables BGP to provide routing information for multiple routing
protocols.
10.35 Maintaining BGP
Maintaining BGP involves resetting BGP connections and clearing BGP statistics.
10.36 BGP Route Selection Rules
10.37 BGP Configuration Examples
This section provides BGP configuration examples.
10.1 BGP Overview

The Border Gateway Protocol (BGP) advertises and maintains a large number of routes
between autonomous systems (ASs).

BGP Definition
Border Gateway Protocol (BGP) is a dynamic routing protocol used between Autonomous
Systems (ASs). BGP is widely used by Internet Service Providers (ISPs).
As three earlier-released versions of BGP, BGP-1, BGP-2, and BGP-3 are used to exchange
reachable inter-AS routes, establish inter-AS paths, avoid routing loops, and apply routing
policies between ASs.
Currently, BGP-4 is used.
BGP has the following characteristics:
l Unlike an Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF) and
Routing Information Protocol (RIP), BGP is an Exterior Gateway Protocol (EGP) which
controls route advertisement and selects optimal routes between ASs rather than
discovering or calculating routes.
l BGP uses Transport Control Protocol (TCP) as the transport layer protocol, which
enhances BGP reliability.
– BGP selects inter-AS routes, which poses high requirements on stability. Therefore,
using TCP enhances BGP's stability.
– BGP peers must be logically connected through TCP. The destination port number
is 179 and the local port number is a random value.
l BGP supports Classless Inter-Domain Routing (CIDR).
l When routes are updated, BGP transmits only the updated routes, which reduces
bandwidth consumption during BGP route distribution. Therefore, BGP is applicable to
the Internet where a large number of routes are transmitted.
l BGP is a distance-vector routing protocol.
l BGP is designed to prevent loops.
– Between ASs: BGP routes carry information about the ASs along the path. The
routes that carry the local AS number are discarded to prevent inter-AS loops.
– Within an AS: BGP does not advertise routes learned in an AS to BGP peers in the
AS to prevent intra-AS loops.
l BGP provides many routing policies to flexibly select and filter routes.
l BGP provides a mechanism that prevents route flapping, which effectively enhances
Internet stability.
l BGP can be easily extended.
Purpose
BGP transmits route information between ASs. It, however, is not required in all scenarios.

Figure 10-1 BGP networking
Client AS
IBGP
EBGP EBGP
ISP1 ISP2
Internet
BGP is required in the following scenarios:

l On the network shown in Figure 10-1, users need to be connected to two or more ISPs.
The ISPs need to provide all or part of the Internet routes for the users. Routers,
therefore, need to select the optimal route through the AS of an ISP to the destination
based on the attributes carried in BGP routes.
l The AS_Path attribute needs to be transmitted between users in different organizations.
l Users need to transmit VPN routes through a Layer 3 VPN. For details, see the HUAWEI
NetEngine40E Feature Description - VPN.
l Users need to transmit multicast routes and construct a multicast topology. For details,
see the HUAWEI NetEngine40E Feature Description - IP Multicast.
BGP is not required in the following scenarios:
l Users are connected to only one ISP.
l The ISP does not need to provide Internet routes for users.
l ASs are connected through default routes.

10.2 BGP Precautions

Precautions Preventive Measures Impact
EBGP peers do not support No action is required. None

the following features:
Route reflector
RPKI
Best-external
Add-path
IBGP peers do not support
the following features:
EBGP-max-hop
MPLS local IFNET
Fake AS
Feature exclusiveness:The
ebgp-max-hop and valid-ttl-
hops functions are mutually
exclusive.
If the as-set parameter is Plan the test configurations The service function is
specified when configuring properly. incorrect.
route summarization, the
AS_Sequence of the
summary route is generated
according to the same
AS_Sequence in the
AS_Path attribute of all
specific routes. The rest AS
numbers form the AS_Set.
The number of AS_Path
attributes after
summarization must not
exceed 250; otherwise, the
AS_Path attribute is empty.
The undo peer x.x.x.x group Plan the test configurations The service function is
and undo peer commands properly. incorrect.
have the same function.

Precautions Preventive Measures Impact
If a feature is not configured Plan the test configurations The service function is
for a peer or the default properly. incorrect.
value is configured for the
peer, and then the peer is
added to a peer group which
has a non-default value of
the feature configured, the
peer inherits the feature
configuration from the peer
group.
If a peer in a peer group has
the same configuration of a
feature with the peer group,
and then the feature is
modified for the peer group,
the feature configuration of
the peer changes
accordingly.
If a peer in a peer group and
the peer group have
different configurations of a
feature, and then the feature
is modified for the peer, the
feature configuration of the
peer remains inconsistent
with that of the peer group.
To advertise default routes, Plan the test configurations The service function is
you need to run both the properly. incorrect.
default-route imported and
import-route commands. If
either command is not run,
default routes cannot be
advertised even when they
are available in the routing
table.
Community or extended Plan the test configurations The service function is

community attribute properly. incorrect.
modification through an
export policy applies to the
routes imported using the
network or import-route
command, not to the BGP
routes received from peers.

10.3 Configuring Basic BGP Functions

Before building a BGP network, you must configure basic BGP functions.
Usage Scenario
BGP can be configured on a network to implement communication among ASs. To build a
BGP network, configure basic BGP functions, including the following steps:
l Start a BGP process. This step is a prerequisite for configuring basic BGP functions.
l Establish BGP peer relationships. Devices can exchange BGP routing information only
after peer relationships are established.
l Import routes. BGP itself cannot discover routes. Instead, it imports routes discovered by
other protocols to implement communication between ASs.
NOTE
l The commands in the BGP-IPv4 unicast address family view can be run in the BGP view. These
commands are described in the BGP-IPv4 unicast address family view in configuration files.
Pre-configuration Tasks
Before configuring basic BGP functions, configure parameters of the link layer protocol and
IP addresses for interfaces to ensure that the link layer protocol on the interfaces is Up.
Configuration Procedures
Figure 10-2 Configuring basic BGP functions
10.3.1 Starting a BGP Process

Starting a BGP process is a prerequisite for configuring basic BGP functions. When starting a
BGP process on a device, you need to specify the number of the AS to which the device
belongs.
Procedure
Step 1 Run:
system-view

The system view is displayed.

Step 2 Run:
bgp { as-number-plain | as-number-dot }
A BGP process is enabled (the local AS number is specified) and the BGP view is displayed.
Step 3 (Optional) Run:
router-id ipv4-address
A router ID is set.
Configuring or changing the router ID will reset the BGP peer relationship between routers.
NOTE
By default, BGP automatically selects the router ID in the system view. If the IP address of a physical
interface is used as the router ID, route flapping occurs when the IP address of the physical interface
changes. To enhance network stability, configuring the address of a loopback interface as the router ID is
recommended. For Router ID selection rules in the system view, see descriptions in Command
Reference about the router-id command.
By default, Cluster_List takes precedence over Router ID during BGP route selection. To enable Router
ID to take precedence over Cluster_List during BGP route selection, run the bestroute routerid-prior-
clusterlist command.

shutdown
All sessions between the device and its BGP peers are terminated.
During the system upgrade, or maintenance, you can run the shutdown command to terminate
all sessions between a device and its BGP peers to prevent possible BGP route flapping from
affecting the network.
NOTICE
After the upgrade or maintenance, run the undo shutdown command to restore the BGP peer
sessions; otherwise, BGP functions will be affected.
Step 5 Run:
commit
The configuration is committed.
----End
10.3.2 Configuring a BGP Peer

Devices can exchange BGP routing information only after the BGP peer relationship is
established.
Context
Because BGP uses TCP connections, you need to configure the IP addresses of peers when
configuring BGP. A BGP peer may not be a neighboring node, and the BGP peer relationship
can be created through logical links. To enhance the stability of BGP connections, establish
connections by using loopback interface addresses.

The devices in the same AS establish IBGP peer relationships, and the devices of different
ASs establish EBGP peer relationships.
Procedure
l Configure an IBGP peer.
a. Run:
system-view

b. Run:
bgp as-number
The BGP view is displayed.

c. Run:
peer ipv4-address as-number as-number
The IP address of the peer and the number of the AS where the peer resides are
specified.
The number of the AS where the specified peer resides must be the same as that of
the local AS.
The IP address of the specified peer can be one of the following types:
n IP address of an interface on a directly connected peer
n IP address of a sub-interface on a directly connected peer
n Address of a loopback interface on a reachable peer
d. (Optional) Run:
peer ipv4-address connect-interface interface-type interface-number
[ ipv4-source-address ]
The source interface and source address are specified for TCP connection
establishment.
NOTE
When an IP address of a loopback interface or a sub-interface is used to establish a BGP

connection, run the peer connect-interface command at both ends of the connection to
ensure that the connection is correctly established. If this command is run on only one end,
the BGP connection may fail to be established.
e. (Optional) Run:
peer ipv4-address description description-text
The description of the peer is configured.

You can simplify network management by configuring the descriptions of peers.
f. (Optional) Run:
peer ipv4-address 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.

g. Run:
commit

l Configure an EBGP peer.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
The IP address of the peer and the number of the AS where the peer resides are
specified.
The number of the AS where the specified peer resides must be different from that
of the local AS.
The IP address of the specified peer can be one of the following types:
n IP address of an interface on a directly connected peer
n IP address of a sub-interface on a directly connected peer
n Address of a loopback interface on a reachable peer
d. (Optional)Run:
peer ipv4-address connect-interface interface-type interface-number
[ ipv4-source-address ]
The source interface and source address are specified for establishing a TCP
connection.
NOTE
When an IP address of a loopback interface or a sub-interface is used to establish a BGP

connection, run the peer connect-interface command at both ends of the connection to
ensure that the connection is correctly established. If this command is run on only one end,
the BGP connection may fail to be established.
e. (Optional) Run:
peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops is set for an EBGP connection.

In most cases, a directly connected physical link must be available between EBGP
peers. If you want to establish EBGP peer relationships between indirectly
connected peers, run the peer ebgp-max-hop command. The command also can
configure the maximum number of hops for an EBGP connection.
NOTE
When the IP address of loopback interface to establish an EBGP peer relationship, run the
peer ebgp-max-hop (of which the value of hop-count is not less than 2) command.
Otherwise, the peer relationship fails to be established.
f. (Optional) Run:
peer ipv4-address description description-text

The description of the peer is configured.

g. (Optional) Run:
peer ipv4-address 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.
h. Run:
commit
----End
10.3.3 Configuring BGP to Import Routes

BGP can import the routes from other routing protocols. When BGP needs to import routes
from a dynamic routing protocol, you need to specify the process ID of the protocol.
Context
BGP itself cannot discover routes. Therefore, it needs to import routes from other protocols,
such as IGP or static routes and adds the routes to the BGP routing table so that these
imported routes can be transmitted within an AS or between ASs.
BGP routes are imported in either of the following modes:
l The import command imports routes based on protocol types, such as RIP routes, OSPF
routes, Intermediate System to Intermediate System (IS-IS) routes, static routes, or direct
routes.
l The network command imports a route with the specified prefix and mask to the BGP
routing table, which is more precise than the previous mode.
Procedure
l Run the import command to import routes.
a. Run:
system-view

b. Run:
bgp as-number

c. (Optional) Run:
ipv4-family unicast
The BGP-IPv4 unicast address family view is displayed.

d. Run:

import-route { direct | isis process-id | ospf process-id | rip process-

id | static } [ med med | [ route-policy route-policy-name | route-
filter route-filter-name ] ] * [ non-relay-tunnel ]
BGP is configured to import routes from other routing protocols.
By configuring the parameter med, you can set MED values for the imported routes.
The EBGP peer selects the route with the smallest MED for traffic entering an AS.
By configuring the parameter route-policy route-policy-name or route-filter route-

filter-name, you can filter the routes imported from other protocols.
If non-relay-tunnel is specified, the routes imported by BGP are not iterated to

tunnels. In most cases, the routes imported by BGP can be iterated to tunnels.
However, in some other cases, if the routes imported by BGP are iterated to tunnels,
a problem will occur. For example, in a seamless MPLS scenario, if the egress
protection function is configured on egress MASGs between which a tunnel exists
and a route imported by BGP on one of the MASGs is iterated to the tunnel, this
MASG then iterates the route to another tunnel of a different type. In this case,
traffic is directed to the other MASG, which slows down traffic switchover. As a
result, the egress protection function does not take effect. To address this problem,
specify non-relay-tunnel to prevent the routes imported by BGP from being
iterated to tunnels.
NOTE
When BGP needs to import routes from IS-IS, OSPF, or RIP, specify the process ID of the
protocol.
e. (Optional) Run:
default-route imported
BGP is configured to import default routes.
To import default routes, run both the default-route imported command and the
import-route command. If only the import-route command is used, no default route
can be imported.
f. Run:
commit

l Run the network command to import routes.
a. Run:
system-view

b. Run:
bgp as-number

c. (Optional) Run:
ipv4-family unicast

d. Run:
network ipv4-address [ mask | mask-length ] [ route-policy route-policy-
name | route-filter route-filter-name ] [ non-relay-tunnel ]

BGP is configured to import local routes.
If the mask or mask length of an IPv4 address is not specified, the IPv4 address is
considered as a classful address. The local routes to be imported must be in the
local IP routing table.
By configuring the parameter route-policy route-policy-name, you can use routing

policies to control the routes to be imported.
By configuring the parameter route-filter route-filter-name, you can use routing

filters to control the routes to be imported.
If non-relay-tunnel is specified, the routes imported by BGP are not iterated to

tunnels. In most cases, the routes imported by BGP can be iterated to tunnels.
However, in some other cases, if the routes imported by BGP are iterated to tunnels,
a problem will occur. For example, in a seamless MPLS scenario, if the egress
protection function is configured on egress MASGs between which a tunnel exists
and a route imported by BGP on one of the MASGs is iterated to the tunnel, this
MASG then iterates the route to another tunnel of a different type. In this case,
traffic is directed to the other MASG, which slows down traffic switchover. As a
result, the egress protection function does not take effect. To address this problem,
specify non-relay-tunnel to prevent the routes imported by BGP from being
NOTE
l The destination address and mask specified in the network command must be consistent
with the corresponding entries in the local IP routing table. Otherwise, the specified
route cannot be imported.
l When running the undo network command to clear the existing configuration, you need
to specify the correct mask.
e. Run:
commit
----End
10.3.4 Checking the Configurations

After configuring the basic BGP functions, check BGP peer information.
Prerequisites
Basic BGP functions have been configured.
Procedure
l Run the display bgp router-id [ vpn-instance [ vpn-instance-name ] ] command to
check the router IDs.
l Run the display bgp peer [ verbose ] command to check the information about all BGP
peers.
l Run the display bgp peer ipv4-address { log-info | verbose } command to check the
information about a specified BGP peer.

l Run the display bgp routing-table command to check the information about BGP
routes.
----End
Example
Run the display bgp peer command, and you can view the status of the connection between
BGP peers.
<HUAWEI> display bgp peer
<HUAWEI> display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 65009
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
10.1.1.2 4 65009 16636 16639 0 0277h13m Established 0
10.1.3.2 4 65009 16640 16643 0 0277h17m Established 0
10.2.1.2 4 65008 16984 16984 0 0282h58m Established 1
# Run the display bgp routing-table ipv4-address command to view a specified BGP route.
<HUAWEI> display bgp routing-table 10.1.1.2

Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 10.1.1.0/24:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Route Duration: 11d12h40m33s
Direct Out-interface: GigabitEthernet1/0/0
Original nexthop: 9.1.1.1
Qos information : 0x0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select,
pre 0
Advertised to such 3 peers:
10.1.3.2
10.1.1.2
10.2.1.2
10.4 Configuring BGP Route Attributes

Configuring route attributes can change route selection results.
Usage Scenario
BGP has many route attributes. You can change route selection results by configuring
attributes for routes.
l BGP priority
Setting the BGP priority can control route selection between BGP routes and routes of
other routing protocols.
l Preferred values
After preferred values are set for BGP routes, the route with the greatest value is
preferred when multiple routes to the same destination exist in the BGP routing table.

l Local_Pref
The Local_Pref attribute has the same function as the preferred value of a route. If both
of them are configured for a BGP route, the preferred value takes precedence over the
Local_Pref attribute.
l MED
The MED attribute is used to determine the optimal route for traffic that enters an AS.
The route with the smallest MED value is selected as the optimal route if the other
attributes of the routes are the same.
l Next_Hop
BGP route selection can be controlled by changing Next_Hop attributes for routes.
l AS_Path
The AS_Path attribute is used to prevent rooting loops and control route selection.
l AIGP
Before configuring BGP route attributes, configure basic BGP functions.
Perform one or more of the following configurations as required.
10.4.1 Setting the BGP Priority

Setting the BGP priority can control route selection between BGP routes and routes of another
routing protocol.
Context
Multiple dynamic routing protocols can be run on a device. In this case, there is a problem of
route sharing and selecting among routing protocols. To address this problem, the system sets
a default priority for each routing protocol. If different protocols have routes to the same
destination, the protocol with the highest priority is selected to forward IP packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
The IPv4 unicast address family view is displayed.

Step 4 Run:
preference { external internal local | route-policy route-policy-name | route-
filter route-filter-name }
The BGP preference is set.

The smaller the value, the higher the priority.
BGP has the following types of routes:
l Routes learned from external peers (EBGP)
l Routes learned from internal peers (IBGP)
l Routes generated locally using the summary automatic or aggregate command.
You can set different priorities for the three types of routes.
You can also apply routing policies to set preferences for the specified routes that meet the
requirements. You can set default preferences for the routes that do not meet the requirements.
NOTE
Currently, you cannot run the peer route-policy or peer route-filter command to apply routing policies
to set the priority for BGP.
Step 5 Run:
commit
----End
10.4.2 Setting the Preferred Values for BGP Routes

After the preferred values are set for BGP routes, the route with the largest preferred value is
preferred when multiple routes to the same destination exist in the BGP routing table.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

Step 4 Run:
peer { group-name | ipv4-address } preferred-value value
The preferred values of all the routes learned from a specified peer are set.
After the peer preferred-value command is run, all the routes learned from a peer have the
same preferred value.

Step 5 Run:
commit
----End
10.4.3 Setting the Default Local_Pref Attribute for the Local

Device
The function of the Local_Pref attribute is similar to that of the preferred value. The priority
of the Local_Pref attribute, however, is lower than that of the preferred value.
Context
The Local_Pref attribute is used to determine the optimal route for the traffic that leaves 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 route with the largest
Local_Pref.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
default local-preference local-preference
The default Local_Pref attribute is set for the local device.
Step 5 Run:
commit
----End
10.4.4 Configuring MED Attributes for BGP Routes

The MED attribute equals the metric used by an IGP. After the MED attributes of routes are
set, an EBGP peer selects the route with the smallest MED value for the traffic that enters an
AS if the other attributes of the routes are the same.

Context
If a BGP device obtains multiple routes from different EBGP peers and these routes have
different next hops but the same destination, the BGP device selects the route with the
smallest MED value.
Procedure
l Set the default MED value on a device.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
default med med
The default MED value is set.
NOTE
The default med command is valid only for routes imported using the import-route
command and BGP summarized routes on the local device.
e. Run:
commit

l Compare the MED values of the routes from different ASs.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
compare-different-as-med
The MED values of routes from different ASs are compared.
By default, the BGP device compares the MED values of only routes from different
peers in the same AS.

e. Run:
commit

l Configure the deterministic-MED function.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
deterministic-med
The deterministic-MED function is enabled.
If the deterministic-MED function is not enabled and the device receives multiple
routes with the same prefix from different ASs, the sequence in which routes are
received determines the route selection. After the deterministic-MED function is
enabled, these routes are first grouped based on the leftmost AS number in the
AS_Path attribute. Routes with the same leftmost AS number are grouped together
and compared, and an optimal route is selected in the group. The optimal route in
this group is then compared with the optimal routes from other groups to determine
the final optimal route. With the deterministic-MED function, the route selection
result is independent of the sequence in which routes are received.
e. Run:
commit

l Configure the maximum MED value (4294967295) as the MED during route selection
when a route carries no MED.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
bestroute med-none-as-maximum
The maximum MED value is used as the MED when a route carries no MED.

If the bestroute med-none-as-maximum command is not run and a route carries

no MED, 0 is used as the MED value of the route.
e. Run:
commit

l Compare the MED values of routes in a confederation.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
bestroute med-confederation
The MED values of routes in a confederation are compared.

e. Run:
commit

l Compare the sums of MED multiplied by a MED multiplier and IGP cost multiplied by
an IGP cost multiplier.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
bestroute med-plus-igp [ igp-multiplier igp-multiplier | med-multiplier
med-multiplier ]
The sums of MED multiplied by a MED multiplier and IGP cost multiplied by an
IGP cost multiplier are compared.
e. Run:
commit

l Enable BGP to remove the MED attribute from the imported routes that are locally
crossed and are to be advertised to a specified peer after an export policy for which the
apply cost-type command is run is applied to the peer.

a. Run:
system-view

b. Run:
bgp as-number

c. Run:
local-cross-routing non-med
BGP is enabled to remove the MED attribute from the imported routes that are
locally crossed and are to be advertised to a specified peer after an export policy for
which the apply cost-type command is run is applied to the peer.
By default, in V800R009C00, BGP removes the MED attribute from the imported
routes that are locally crossed and are to be advertised to a specified peer after an
export policy for which the apply cost-type command is run is applied to the peer.
In the current version, BGP does not remove the MED attribute from the routes by
default. Due to the default implementation difference, the route selection result may
change after V800R009C00 is upgraded to the current version. To address this
problem, run the local-cross-routing non-med command to keep the default
implementation of V800R009C00.
d. Run:
commit
----End
10.4.5 Setting Next_Hop Attributes for Routes

Setting Next_Hop attributes for routes controls BGP route selection.
Procedure
l Configure a device to change the next hop address of a route when the device advertises
the route to an IBGP peer.
By default, a device does not change the next hop address of a route learned from an
EBGP peer before forwarding the route to IBGP peers. The next hop address of a route
advertised by an EBGP peer to this device is the address of the EBGP peer. After being
forwarded to IBGP peers, this route is not active because the next hop is unreachable.
The relevant ASBR must be configured to change the next hop address of the route to the
ASBR's own IP address before the ASBR advertises the route to an IBGP peer. The route
is active on the IBGP peer if the next hop is reachable.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
peer { ipv4-address | group-name } next-hop-local
The device is configured to change the next hop address of a route to the device's
own IP address before the device advertises the route to an IBGP peer.
NOTE
If BGP load balancing is configured, the local router changes the next hop address of a route
to its own IP address when advertising the route to IBGP peers or peer groups, regardless of
whether the peer next-hop-local command is used.
e. Run:
commit

l Prevent a device from changing the next hop address of a route imported from an IGP
when the device advertises the route to an IBGP peer.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
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.
e. Run:
commit

l Prevent an ASBR from changing the next hop address of a route when the ASBR
advertises the route to an EBGP peer.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family vpnv4 [ unicast ]

The BGP-VPNv4 sub-address family view is displayed.

d. Run:
peer { group-name | ipv4-address } next-hop-invariable
The device is prevented from changing the next hop address of a route when
advertising the route to an EBGP peer.
In the inter-AS VPN option C networking where RRs are used, the peer next-hop-
invariable command needs to be run to prevent the RRs from changing the next
hop address of a route when the RRs advertise the route to EBGP peers. This
ensures that the remote PE iterates a route to the BGP LSP destined for the local PE
during traffic transmission.
e. Run:
commit

l Configure route-policy-based next hop iteration.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
nexthop recursive-lookup { route-policy route-policy-name | route-filter
route-filter-name }
Route-policy-based next hop iteration is configured.

Next-hop iteration based on a specified route-policy can control the iterated next
hop based on specific conditions. If a route fails to match the specified route-policy,
the route cannot be iterated.
e. Run:
commit

----End
10.4.6 Setting the AS_Path Attribute

The AS_Path attribute is used to prevent routing loops and control route selection.
Procedure
l Allow repeated local AS numbers.
Multiple dynamic routing protocols can be run on a device at the same time. In this case,
there is a problem of route sharing and selecting among routing protocols. To address

this problem, the system sets a default priority for each routing protocol. If different
protocols have routes to the same destination, the protocol with the highest preference is
selected to forward IP packets.
Perform the following steps on a device running BGP.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
peer { ipv4-address | group-name } allow-as-loop [ number ]
Repeated local AS numbers are allowed.

In most cases, a BGP router checks the AS_Path attribute of a route received from a
peer. If the local AS number is carried by the route, the BGP router discards this
route to avoid routing loops.
In some special applications, you can use the peer { ipv4-address | group-name }
allow-as-loop [ number ] command to allow the AS_Path attribute of a route
received from a peer to contain the local AS number. You can also set the allowed
number of repeated local AS numbers.
e. Run:
commit

l Prevent the local device from using the AS_Path attribute as a route selection rule.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
bestroute as-path-ignore
The local device is prevented from using the AS_Path attribute as a route selection
rule.
e. Run:
commit


l Configure a fake AS number.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { ipv4-address | group-name } fake-as fake-as-number [ dual-as ]
[ prepend-global-as ] [ prepend-fake-as ]
A fake AS number is configured.

This command is used to hide the actual AS number. EBGP peers in other ASs can
learn only this fake AS number. The peers in other ASs use the fake AS number as
the AS number of the local peer.
NOTE
The peer fake-as command is applicable only to EBGP peers.

d. Run:
commit

l Substitute the AS number in the AS-Path attribute.
If the AS_Path attribute of a route to be advertised to a peer contains the number of the
AS where the peer resides, the local router substitutes the AS number of the peer with
the local AS number before advertising the route. On a BGP network, two devices have
the same AS number and the same EBGP peer. After one of the two devices learns a
route of the other device from the EBGP peer, the route is discarded because it carries an
AS number that is the same as the local one. To address this problem, run the peer
substitute-as command on the EBGP peer.
NOTICE
Configuring the peer substitute-as command may cause a routing loop. Therefore,
exercise caution when running this command.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family { vpn-instance vpn-instance-name | unicast }

The BGP-VPN instance IPv4 address family view or BGP-IPv4 unicast address
family view is displayed.
d. Run:
peer { ipv4-address | group-name } substitute-as
The AS number in the AS_Path attribute of a route is substituted with the local AS
number.
e. Run:
commit

l Configure the AS_Path attribute to carry only the public AS number.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
peer { ipv4-address | group-name } public-as-only [ force [ replace ]
[ include-peer-as ] | limited [ replace ] [ include-peer-as ] ]
The AS_Path attribute is configured to carry only the public AS number.
In most cases, the AS number ranges from 1 to 4294967295. The public AS number
ranges from 1 to 64511, and from 65536 (1.0 in the format of x.y) to 4294967295
(65535.65535 in the format of x.y), and the private AS number ranges from 64512
to 65534. 65535 is a reserved AS number.
NOTE
If the 4-byte private AS number function is enabled using the private-4-byte-as enable
command, private AS numbers range from 64512 to 65534 and from 4200000000 to
4294967294 (64086.59904 to 65535.65534 in the format of x.y).
The public AS number can be used on the Internet, because Internet addresses are
managed and assigned by the Internet Assigned Number Authority (IANA). The
private AS number cannot be advertised to the Internet and is used only in an
internal routing domain.
In most cases, the route advertised by a BGP router to its peer carries an AS number
(either public or private AS number). If you do not want to transmit the private AS
number, run the command so that the AS_Path attribute carries only the public AS
number.
e. Run:
commit

l Set the maximum number of AS numbers in the AS-Path attribute.

a. Run:
system-view

b. Run:
bgp as-number

c. 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.
After the as-path-limit command is run, a router checks whether the number of AS
numbers in the AS-Path attribute of a received route exceeds the maximum value. If
the number of AS numbers exceeds the maximum value, the router discards the
route. Therefore, if the maximum number of AS numbers in the AS-Path attribute is
set too small, routes may be discarded.
d. Run:
commit

l Prevent a BGP device from checking the first AS number contained in the AS_Path
attribute of an Update message received from an EBGP peer.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
undo check-first-as
The BGP device is prevented from checking the first AS number contained in the
AS_Path attribute of an Update message received from an EBGP peer.
By default, a BGP device checks whether the first AS number contained in the
AS_Path attribute of an Update message received from an EBGP peer is the same
as the number of the AS where the EBGP peer resides. If the numbers are not the
same, the BGP device discards the Update message and terminates the EBGP
connection with the EBGP peer.
NOTICE
Exercise caution when running the undo check-first-as command because use of
this command may cause routing loops.
d. Run:
commit

After the configuration is complete, run the refresh bgp command to check the
received routes again.
l Enable the device to check or disable the device from checking the first AS number in
the AS_Path attribute contained in the update messages received from a specified EBGP
peer or peer group.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { group-name | ipv4-address } check-first-as { enable | disable }
The device is enabled to check or disabled from checking the first AS number in the
AS_Path attribute contained in the update messages received from a specified
EBGP peer or peer group.
If the peer check-first-as enable command is run, the device checks whether the
first AS number in the AS_Path attribute contained in the update messages received
from the specified EBGP peer or peer group is the number of the AS where the
EBGP peer or peer group resides. If the two AS numbers are different, the local
device discards the update messages and disconnects the EBGP connection. If the
peer check-first-as disable command is run, the device accepts all update
messages received from the specified EBGP peer or peer group, regardless whether
the two AS numbers are the same. If the undo peer check-first-as disable
command is run, the default configuration takes effect.
The check function can be configured for a specified EBGP peer, peer group, or for
BGP as a whole. If the function is not configured for a specified EBGP peer, the
device checks whether the function is configured for the related peer group; if the
function is not configured for the peer group, the device checks whether the
function is configured in the BGP view.
d. Run:
commit
After the configuration is complete, run the refresh bgp command to check the
received routes again.
----End
10.4.7 Configuring AIGP Attributes for Routes

The Accumulated Interior Gateway Protocol Metric (AIGP) attribute allows devices in an
AIGP administrative domain to use the optimal routes to forward data.

Context
An AIGP administrative domain is a set of autonomous systems (ASs) in a common
administrative domain.
Routing protocols that have been designed to run within a single administrative domain, such
as various IGPs, generally assign a metric to each link, and then choose the path for which the
total distance (sum of the metric of each link along the path) is minimized as the optimal path
between two nodes. BGP, designed to provide routing over a large number of independent
administrative domains, does not select paths based on metrics. If a single administrative
domain runs several contiguous BGP networks, it is desirable for BGP to select paths based
on metrics, just as an IGP does.
The AIGP attribute enables BGP to select routes based on metrics in an AIGP administrative
domain. As a result, all devices in the AIGP administrative domain can use the optimal routes
to forward data.
Procedure
Step 1 Run:
1. Run:
system-view

2. Run:
bgp as-number

3. Run the ipv4-family unicast command to enter the BGP-IPv4 unicast address family
view, or run the ipv4-family labeled-unicast command to enter the BGP-labeled
address family view.
4. Run:
peer { group-name | ipv4-address | ipv6-address } aigp
The AIGP capability is enabled for a BGP peer or peer group.
BGP allows you to enable the AIGP capability for either a BGP peer or a BGP peer
group. If a BGP peer with the AIGP capability joins a BGP peer group that does not have
the AIGP capability, the BGP peer still retains the AIGP capability. If a BGP peer
without the AIGP capability joins a BGP peer group that has the AIGP capability, the
BGP peer inherits the AIGP capability of the BGP peer group. After a BGP peer inherits
the AIGP capability of a BGP peer group, you can run the undo peer aigp command to
delete the AIGP configuration from the BGP peer.
5. Run:
commit
----End

After configuring BGP route selection, check information about route attributes.

Prerequisites
BGP route attributes have been configured.
Procedure
l Run the display bgp routing-table different-origin-as command to check routes with
different source ASs but the same destination address.
l Run the display bgp routing-table regular-expression as-regular-expression command
to check routes matching the AS regular expression.
l Run the display bgp routing-table [ network ] [ mask | mask-length ] [ longer-prefixes ]
command to check information about the BGP routing table.
l Run the display bgp routing-table community [ community-number | aa:nn ] &<1-13>
[ internet | no-advertise | no-export | no-export-subconfed ] * [ whole-match ]
command to check routes matching a specified BGP community attribute.
l Run the display bgp routing-table community-filter { { community-filter-name | basic-
community-filter-number } [ whole-match ] | advanced-community-filter-number }
command to check the routes matching a specified BGP community filter.
----End
Example
# Run the display bgp routing-table regular-expression as-regular-expression command to
check routes matching the AS regular expression. For example:
<HUAWEI> display bgp routing-table regular-expression ^1
BGP Local router ID is 1.1.1.2
Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V - valid, I - invalid, N - not-found
Total Number of Routes: 4

Network NextHop MED LocPrf PrefVal Path/Ogn
* 1.1.1.0/24 1.1.1.1 0 0 100?

* 1.1.1.2/32 1.1.1.1 0 0 100?
*> 5.1.1.0/24 1.1.1.1 0 0 100?
*> 100.1.1.0/24 1.1.1.1 0 0 100?
# Run the display bgp routing-table [ network ] [ mask | mask-length ] [ longer-prefixes ]

command to check information about the BGP routing table. For example:
<HUAWEI> display bgp routing-table

* 1.1.1.0/24 1.1.1.1 0 0 100?

* 1.1.1.2/32 1.1.1.1 0 0 100?
*> 5.1.1.0/24 1.1.1.1 0 0 100?
*> 100.1.1.0/24 1.1.1.1 0 0 100?

# Run the display bgp routing-table community [ community-number | aa:nn ] &<1-13>

[ internet | no-advertise | no-export | no-export-subconfed ] * [ whole-match ] command to
check routes matching a specified BGP community attribute. For example:
<HUAWEI> display bgp routing-table community

Network NextHop MED LocPrf PrefVal Community
* 1.1.1.0/24 1.1.1.1 0 0 no-export

* 1.1.1.2/32 1.1.1.1 0 0 no-export
*> 5.1.1.0/24 1.1.1.1 0 0 no-export
*> 100.1.1.0/24 1.1.1.1 0 0 no-export
10.5 Using Routing Policy to Filter the BGP Routes to Be

Advertised
BGP is used to transmit routing information. BGP advertises only the wanted routes which
match a routing policy and modifies route attributes to direct network traffic properly.
Usage Scenario
BGP is used to transmit routing information between ASs. Route advertisement directly
affects traffic forwarding.
There are usually a large number of routes in a BGP routing table. Transmitting a great deal of
routing information intensifies the load on devices. To address this issue, control routes to be
advertised. You can configure devices to advertise only routes that these devices want to
advertise or routes that their peers require.
In addition, multiple routes that are destined for the same IP address but traverse different
ASs may exist.
To direct traffic to specific ASs, filter these routes before advertising them. BGP can filter
routes to be advertised to a specific peer or peer group. If multiple filter policies are
configured, BGP advertises only routes that match all the filter policies.
Before controlling BGP to advertise routes, configure basic BGP functions.

Figure 10-3 Configuring to Control BGP to advertise routes
10.5.1 Configuring BGP Filters

By using BGP filters, you can filter routes to be advertised.
Context
BGP uses the following types of filters:
l Access Control List (ACL)
l IP-Prefix
l AS_Path
l Community
l Extcommunity
l Route-Policy
Procedure
l Configure an ACL.
An ACL is a series of sequential rules composed of permit and deny clauses. These
rules specify source addresses, destination addresses, or port numbers of packets. ACL
rules are used to classify packets. After ACL rules are applied to a router, the router uses
the ACL rules to permit or deny packets.
For details on ACL configurations, see the HUAWEI NetEngine40E Universal Service
Router Configuration Guide-IP Services.
An ACL can be used as a filtering condition of a route-policy or used in the filter-policy
{ acl-number | acl-name acl-name } export [ direct | isis process-id | ospf process-id |
rip process-id | static ] or peer { group-name | ipv4-address } filter-policy { acl-number
| acl-name acl-name } export command.
l Configure an IP prefix list.
An IP prefix list is used to filter routes based on destination addresses. An IP prefix list
is identified by its name. An IP prefix list can be used flexibly to implement accurate

filtering. For example, it can be used to filter a route or routes to a network segment. If a
large number of routes with different prefixes need to be filtered, configuring an IP
prefix list to filter the routes is very complex.
An IP prefix list can be used as a matching rule of a route-policy or used in the filter-
policy ip-prefix ip-prefix-name export [ direct | isis process-id | ospf process-id | rip
process-id | static ] or peer { group-name | ipv4-address } ip-prefix ip-prefix-name
export command.
a. Run:
system-view

b. Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-
address mask-length [ greater-equal greater-equal-value ] [ less-equal
less-equal-value ]
An IPv4 prefix list is configured.
The mask length range can be specified as mask-length <= greater-equal-value <=
less-equal-value <= 32. If only greater-equal is specified, the prefix range is
[greater-equal-value, 32]. If only less-equal is specified, the prefix range is [mask-
length, less-equal-value].
An IP prefix list is identified by its name. Each IP prefix list can contain multiple
entries. Each entry can independently specify a matching range in the form of a
network prefix. The matching range is identified by an index number that specifies
the matching sequence. An IPv4 prefix list named abcd is used as an example.
#
ip ip-prefix abcd index 10 permit 1.0.0.0 8
During route matching, the router checks entries that are identified by index
numbers in ascending order. If a route matches an entry, the route does not continue
to match against the next entry.
The NE40E denies all routes that do not match the filtering rule by default. If all
entries in an IPv4 prefix list are in deny mode, all routes will be denied by the IPv4
prefix list. In this case, define an entry permit 0.0.0.0 0 less-equal 32 after the
entries in deny mode to allow all the other IPv4 routes to be permitted by the IPv4
prefix list.
NOTE
If more than one IP prefix entry is defined, at least one entry should be set in permit mode.
c. Run:
commit

l Configure an AS_Path filter.
An AS_Path filter is used to filter BGP routes based on the AS_Path attributes contained
in the BGP routes. If you do not want traffic to pass through an AS, configure an
AS_Path filter to filter out the traffic carrying the AS number. If the BGP routing table of
each device on a network is large, configuring an ACL or an IP prefix list to filter BGP
routes is complex and complicates maintenance of new routes.

NOTE
If the AS_Path information of a summarized route is lost, the AS_Path filter cannot be used to
filter the summarized route, but can still be used to filter the specific routes from which the
summarized route is derived.
An AS_Path filter can be used as a filtering condition of a route-policy or be used in the

peer as-path-filter command.
a. Run:
system-view

b. Run:
ip as-path-filter { as-path-filter-number | as-path-filter-name }
[ index index-number ] { permit | deny } regular-expression
An AS_Path filter is configured.
An AS_Path filter defines matching rules with a regular expression. A regular

expression is composed of the following parts:
n Metacharacter: defines matching rules.

n General character: defines matching objects.
Table 10-1 Description of metacharacters
Special Function
Character
\ Defines an escape character, which is used to mark the next

character (common or special) as a common character.
^ Matches the start position of the string.
$ Matches the end position of the string.
* Matches the preceding element zero or more times.
+ Matches the preceding element once or more times
? Matches the preceding element zero times or once.
. Matches any single character.
() Defines a subexpression, which can be empty. Both the

expression and the subexpression must match.
_ Matches regular expressions with a sign, such as a comma

(,), left brace ({), right brace (}), left parenthesis ((), right
parenthesis ()), or space. The underscore (_) can be used at
the beginning of a regular expression with the same function
as the caret (^) or at the end of a regular expression with the
same function as the dollar sign ($).
x|y Matches x or y.
[xyz] Matches any character in the regular expression.

Special Function
Character
[^xyz] Matches any character that is not contained within the

brackets.
[a-z] Matches any character within the specified range.
[^a-z] Matches any character beyond the specified range.
For example, ^10 indicates that only the AS_Path attribute with the value 10 as the
first character is matched. ^ indicates that the beginning of a string character is
matched.
You can define multiple rules (permit or deny) for the same filter. During the
matching, the relationship between these rules is OR. That is, when a route meets
one of the matching rules, it indicates that the route matches this AS_Path filter.
NOTE
For details on a regular expression, see the HUAWEI NetEngine40E Universal Service
Router Configuration Guide - Basic Configurations.
c. Run:
commit

l Configure a community filter.
A BGP community attribute is used to identify a group of routes with the same
properties. Routes can be classified by community attribute. This facilitates route
management.
Some AS internal routes may not need to be advertised to any other AS, whereas AS
external routes need to be advertised to other ASs. These AS external routes have
different prefixes (as a result, an IP prefix list is inapplicable) and may come from
different ASs (as a result, an AS_Path filter is inapplicable). You can set a community
attribute value for these AS internal routes and another community attribute value for
these AS external routes on an ASBR to control and filter these routes.
a. Run:
system-view

b. Run:
ip community-filter
A community filter is configured.

n To configure the standard community filter, run the ip community-filter basic
comm-filter-name [ index index-number ] { permit | deny } [ community-
number | aa:nn | internet [ strict-match ] | no-export-subconfed | no-
advertise | no-export ] &<1-20> command, or the ip community-filter basic-
comm-filter-num [ index index-number ] { permit | deny } [ community-
number | aa:nn | internet | no-export-subconfed | no-advertise | no-export ]
&<1-20> command.

n To configure the advanced community filter, run the ip community-filter

{ advanced comm-filter-name | adv-comm-filter-num } [ index index-number ]
{ permit | deny } regular-expression command.
c. Run:
commit

l Configure an extended community filter.
Similar to a BGP community filter, a BGP extcommunity filter is used to filter private
network routes.
a. Run:
system-view

b. Perform either of the following operations as required to configure an
extcommunity filter.
To configure a VPN-Target extcommunity filter:
n To configure a basic VPN-Target extcommunity filter, run the ip
extcommunity-filter { basic-extcomm-filter-num | basic basic-extcomm-filter-
name }[ index index-number ] { deny | permit } { rt { as-number:nn | 4as-
number:nn | ipv4-address:nn } } &<1-16> command.
n To configure an advanced VPN-Target extcommunity filter, run the ip
extcommunity-filter { advanced-extcomm-filter-num | advanced advanced-
extcomm-filter-name }[ index index-number ] { deny | permit } regular-
expression command.
To configure an SoO extcommunity filter:
n To configure a basic SoO extcommunity filter, run the ip extcommunity-list
soo basic basic-extcomm-filter-name [ index index-number ] { permit | deny }
{ site-of-origin } &<1-16> command.
n To configure an advanced SoO extcommunity filter, run the ip extcommunity-
list soo advanced advanced-extcomm-filter-name [ index index-number ]
Multiple entries can be defined in an extcommunity filter. The relationship between
the entries is "OR". This means that if a route matches one of the rules, the route
matches the filter.
c. Run:
commit

l Configure a route-policy.
A route-policy is used to match routes or route attributes, and to change route attributes
when specific conditions are met. As the preceding filters can be used as matching
conditions of a route-policy, the route-policy is powerful in functions and can be used
flexibly.
a. Run:
system-view


b. Run:
route-policy route-policy-name { permit | deny } node node
A node is configured for a route-policy, and the view of the route-policy is

displayed.
A route-policy consists of multiple nodes. For example, the route-policy route-

policy-example permit node 10 command specifies node 10 and the route-policy
route-policy-example deny node 20 command specifies node 20. The two nodes
belong to the route-policy specified by route-policy-example. The relationship
between the nodes of a route-policy is "OR". The details are as follows:
n If a route matches one node, the route matches the route-policy and will not be
matched against the next node. For example, there are two nodes defined using
the route-policy route-policy-example permit node 10 and route-policy
route-policy-example deny node 20 commands. If a route matches the node
defined using the route-policy route-policy-example permit node 10
command, the route will not be matched against the node defined using the
route-policy route-policy-example deny node 20 command.
n If a route does not match any node, the route fails to match the route-policy.
When a route-policy is used to filter a route, the route is first matched against the
node with the smallest node value. For example, if two nodes are configured using
the route-policy route-policy-example permit node 10 and route-policy route-
policy-example deny node 20 commands, a route is first matched against the node
configured using the route-policy route-policy-example permit node 10
command.
NOTE
The NE40E considers that each unmatched route fails to match the route-policy by default.
If more than one node is defined in a route-policy, at least one of them must be in permit
mode.
c. (Optional) Perform the following operations as needed to configure if-match
clauses for current nodes of the route-policy.
if-match clauses are used to filter routes. If no if-match clause is specified, all
routes will match the node in the route-policy.
n To match an ACL, run the if-match acl { acl-number | acl-name } command.

n To match an IP prefix list, run the if-match ip-prefix ip-prefix-name
command.
NOTE
The if-match acl and if-match ip-prefix commands cannot be used together in the
same node of a route-policy, because the latest configuration will override the previous
one.
n To match the AS-Path attribute of BGP routes, run the if-match as-path-filter
as-path-filter-number &<1-16> command.
n To match the community attribute of BGP routes, run either of the following
commands:
○ if-match community-filter { basic-comm-filter-num [ whole-match ] |
adv-comm-filter-num } * &<1-16>

○ if-match community-filter comm-filter-name [ whole-match ]

○ if-match community-filter { adv-comm-filter-num sort-match } *
&<1-16>
○ if-match community-filter comm-filter-name sort-match
n To match the VPN-Target extended community attribute of BGP routes, run
the if-match extcommunity-filter { { basic-extcomm-filter-num | adv-
extcomm-filter-num } &<1-16> | basic-extcomm-filter-name | advanced-
extcomm-filter-name } command.
n To match the SoO extended community attribute of BGP routes, run the if-
match extcommunity-list soo extcomm-filter-name command.
The operations in Step 3 can be performed in any order. A node may have multiple
if-match clauses or no if-match clause.
NOTE
The relationship between the if-match clauses in a node of a route-policy is "AND". A route
must match all the rules before the action defined by the apply clause is taken. For example,
if two if-match clauses (if-match acl 2003 and if-match as-path-filter 100) are defined in
the route-policy route-policy-example permit node 10 command, a route is considered to
match node 10 only when it matches the two if-match clauses.
d. (Optional) Perform the following operations as needed to configure apply clauses
for current nodes of the route-policy.
apply clauses can be used to set attributes for routes matching if-match clauses. If
this step is not performed, the attributes of routes matching if-match clauses keep
unchanged.
n To replace or add a specified AS number in the AS_Path attribute of a BGP

route, run the apply as-path as-number command.
n To delete a specified BGP community attribute from a route, run the apply
comm-filter { comm-filter-number | comm-filter-name } delete command.
NOTE
The apply comm-filter delete command deletes a specified community attribute from
a route. An instance of the ip community-filter command can specify only one
community attribute each time. To delete more than one community attribute, run the
ip community-filter command multiple times. If multiple community attributes are
specified in one community filter, none of them can be deleted. For more information,
see the HUAWEI NetEngine40E Universal Service Router Command Reference.
n To delete all community attributes from a BGP route, run the apply
community none command.
n To set community attributes for a BGP route, run the apply community
{ { community-number | aa:nn } &<1-32> | internet | no-advertise | no-
export | no-export-subconfed } * [ additive ], or apply community
community-list community-list-name command.
NOTE
A BGP community list must be configured using the ip community-list command and
community attributes must be configured for the list using the community command
before you run the apply community community-list community-list-name command.
n To set a VPN-Target extended community attribute for a route, run the apply
extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16>
[ additive ] command.

n To set an SoO extended community attribute for a route, run the apply
extcommunity soo { site-of-origin } &<1-16> additive command.
n To set the local preference for a BGP route, run the apply local-preference [ +
| - ] preference command.
n To set the Origin attribute for a BGP route, run the apply origin { egp { as-
number-plain | as-number-dot } | igp | incomplete } command.
n To set a preferred value for a BGP route, run the apply preferred-value
preferred-value command.
n To set dampening parameters for an EBGP route, run the apply dampening
half-life-reach reuse suppress ceiling command.
apply clauses or no apply clause.
e. Run:
commit

----End
10.5.2 Configuring to Control the Advertisement of BGP Routing

Information
After a route advertisement policy is configured on a device, the device advertises only routes
matching the policy to its peers.
Procedure
l 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. Perform the following
steps on a BGP router:
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Perform either of the following operations to configure the BGP device to advertise
routes to all peers or peer groups:
n To filter routes based on a basic ACL, perform the following steps:
1) Run filter-policy { acl-number | acl-name acl-name } export [ direct |
isis process-id | ospf process-id | rip process-id | static ], the advertised
routes is filtered based on an ACL.
2) Run quit, return to the BGP view.

3) Run quit, return to the system view.

4) Run acl { name basic-acl-name { basic | [ basic ] number basic-acl-
number } | [ number ] basic-acl-number } [ match-order { config |
auto } ], the basic ACL view is displayed.
5) Run rule [ rule-id ] [ name rule-name ] { deny | permit } [ fragment-
type { fragment | non-fragment | non-subseq | fragment-subseq |
fragment-spe-first } | source { source-ip-address { source-wildcard | 0 |
src-netmask } | any } | time-range time-name | vpn-instance vpn-
instance-name ] *, a rule is configured for the basic ACL.
When the rule command is run to configure rules for a named ACL, only
the source address range specified by source and the time period
specified by time-range are valid as the rules.
When a filtering policy of a routing protocol is used to filter routes:
○ If the action specified in an ACL rule is permit, a route that matches
the rule will be received or advertised by the system.
○ If the action specified in an ACL rule is deny, a route that matches
the rule will not be received or advertised by the system.
○ If a route has not matched any ACL rules, the route will not be
received or advertised by the system.
○ If an ACL does not contain any rules, all routes matching the route-
policy that references the ACL will not be received or advertised by
the system.
○ If the ACL referenced by the route-policy does not exist, all routes
matching the route-policy will be received or advertised by the
system.
○ In the configuration order, the system first matches a route with a
rule that has a smaller number and then matches the route with a rule
with a larger number. Routes can be filtered using a blacklist or a
whitelist:
Route filtering using a blacklist: Configure a rule with a smaller
number and specify the action deny in this rule to filter out the
unwanted routes. Then, configure another rule with a larger number
in the same ACL and specify the action permit in this rule to receive
or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller
number and specify the action permit in this rule to permit the
routes to be received or advertised by the system. Then, configure
another rule with a larger number in the same ACL and specify the
action deny in this rule to filter out unwanted routes.
n To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-
prefix-name export [ direct | isis process-id | ospf process-id | rip process-id |
static ] command.
If protocol type is specified, only routes discovered by a specific routing protocol
are filtered. If protocol type is not specified, all the routes to be advertised are
filtered, including routes imported using the import-route (BGP) command and
local routes advertised using the network (BGP) command.

NOTE
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.
e. Run:
commit

l Configure a BGP device to advertise routes to a specific peer or peer group.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run the following commands to configure BGP to filter routes according to
different filters for specified peers.
1) Run peer { ipv4-address | group-name } filter-policy { acl-number | acl-
name acl-name } export, the advertised routes is filtered based on an
ACL.

the system.
system.
whitelist:
n To filter routes based on the IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-name export command.
n To filter routes based on the AS_Path filter, run the peer { ipv4-address |
group-name } as-path-filter { as-path-filter-number | as-path-filter-name }
export command.
n To filter routes based on the route-policy filter, run the peer { ipv4-address |
group-name } route-policy route-policy-name export command.
NOTE
The routing policy set in the peer route-policy export command does not support a
certain interface as one of the matching rules. That is, the routing policy does not
support the if-match interface command.
The members of a peer group and the peer group can use different export routing
policies. That is, each member in the peer group can select its policy when
advertising routes.
e. Run:
commit
----End
10.5.3 (Optional) Configuring BGP Soft Resetting

The outbound BGP soft resetting allows the system to apply the new export policies
immediately without tearing down any BGP connection.
Context
The BGP soft setting requires that the peers support the route-refresh capability.

Procedure
l (Optional) Enable the route-refresh capability.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { ipv4-address | group-name } capability-advertise route-refresh
The route-refresh capability is enabled.

d. Run:
commit

l Configure BGP soft reset.
a. Run the refresh bgp [ vpn-instance vpn-instance-name ipv4-family | vpnv4 ] { all
| ipv4-address | group group-name | external | internal } export command in the
user view to trigger outbound BGP soft resetting.
external softly resets an EBGP connection, and internal softly resets an IBGP
connection.
----End

After the configurations of controlling BGP to advertise routes are complete, you can view
filters, routes matching a specified filter, and routes advertised to BGP peers.
Prerequisites
All configurations of controlling BGP to advertise routes are complete.
Procedure
l 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.
l 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.
l Run the display ip extcommunity-filter [ basic-extcomm-filter-num | advanced-
extcomm-filter-num | extcomm-filter-name ] command to check information about a
configured VPN-Target extcommunity filter.
l Run the display ip extcommunity-list soo [ extcomm-filter-name ] command to check
information about a configured SoO extcommunity filter.
l Run the display bgp routing-table as-path-filter as-path-filter-number command to
check information about routes matching a specified AS_Path filter.


command to check information about routes matching a specified BGP community filter.
l Run the display bgp routing-table peer ipv4-address advertised-routes [ statistics ]
command to check information about routes advertised by a BGP device to its peers.
----End
Example
After an AS_Path filter is configured, run the display ip as-path-filter [ as-path-filter-
number | as-path-filter-name ] command in the system view to view information about the
configured AS_Path filter. Run the display bgp routing-table as-path-filter as-path-filter-
number command to view information about routes matching a specified AS_Path filter.
# View information about AS_Path filter 3.
<HUAWEI> display ip as-path-filter 3
As path filter number: 1
index: 10 permit 1.1 100,200
As path filter name: abc
index: 10 deny 2.2 200,400
# View routes matching AS_Path filter 3.

<HUAWEI> display bgp routing-table as-path-filter 3

*>i 1.1.1.1/32 10.1.1.2 0 100 0 ?

*> 10.1.1.0/24 0.0.0.0 0 0 ?
i 10.1.1.2 0 100 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 10.3.1.0/24 0.0.0.0 0 0 ?
*> 10.3.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 192.168.1.0 0.0.0.0 0 0 ?
* i 10.1.1.2 0 100 0 ?
*> 192.168.1.121/32 0.0.0.0 0 0 ?
*>i 192.168.3.0 10.1.1.2 0 100 0 ?
10.6 Using Routing Policy to Filter the BGP Routes to Be

Received
BGP is used to transmit routing information. BGP accepts only the wanted routes which can
be filtered or applied routing policy flexibly, and modifies route attributes to direct network
traffic properly.
Usage Scenario
BGP is used to transmit routing information between ASs. Route reception directly affects
traffic forwarding.

The BGP device may receive routes to the same destination from different BGP peers. To
control traffic forwarding paths, the router needs to filter the received BGP routes.
The router may be attacked and receive a large number of routes from its BGP peers,
consuming lots of resources of the router. Therefore, the administrator must limit the
resources to be consumed based on networking planning and router capacities, no matter
whether too many BGP routes caused by malicious attacks or incorrect configurations.
Filters can be used to filter routes to be received by BGP. BGP can filter the routes received
from all peers or peer groups or only the routes received from a specific peer or peer group. If
multiple filter policies are configured, BGP accepts only routes that match all the filter
policies.
Before controlling BGP to receive routes, complete the following task:
l Configuring Basic BGP Functions
Figure 10-4 Networking diagram of Configuring to Control BGP to receive routes
10.6.1 Configuring BGP Filters

By using BGP filters, you can flexibly filter routes to be received.
Context
BGP uses the following types of filters to filter routes:
l Access Control List(ACL)
l IP-Prefix List
l AS_Path filter
l Community filter
l Extcommunity filter
l route-policy

Procedure
l Configure an ACL.
An ACL is a series of sequential rules composed of permit and deny clauses. These
rules are described based on source addresses, destination addresses, and port numbers of
packets. ACL rules are used to classify packets. After ACL rules are applied to a router,
the router permits or denies packets based on the ACL rules.
For details on ACL configurations, see the HUAWEI NetEngine40E Universal Service
Router Configuration Guide-IP Services.
An ACL can be used as a filtering condition of a route-policy or used in the filter-policy
{ acl-number | acl-name acl-name } import or peer { group-name | ipv4-address }
filter-policy { acl-number | acl-name acl-name } import command.
l Configure an IP prefix list.
An IP prefix list is a type of filter used to filter routes based on destination addresses. An
IP prefix list is identified by its name. An IP prefix list can be used flexibly to implement
accurate filtering. For example, it can be used to filter a route or routes to a network
segment. If a large number of routes that do not have the same prefix need to be filtered,
configuring an IP prefix list to filter the routes is very complex.
An IP prefix list can be used as a filtering condition of a route-policy or used in the
filter-policy ip-prefix ip-prefix-name import or peer { group-name | ipv4-address } ip-
prefix ip-prefix-name import command.
a. Run:
system-view

b. Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-
address mask-length [ greater-equal greater-equal-value ] [ less-equal
less-equal-value ]
An IPv4 prefix list is configured.

The mask length range can be specified as mask-length <= greater-equal-value <=
less-equal-value <= 32. If only greater-equal is specified, the prefix range is
[greater-equal-value, 32]. If only less-equal is specified, the prefix range is [mask-
length, less-equal-value].
An IPv4 prefix list is identified by its name, and each IP prefix list can contain
multiple entries. Each entry is identified by an index number, and can specify a
matching range in the form of a network prefix uniquely. An IPv4 prefix list named
abcd is used as an example.
#
During route matching, the system checks the entries by index number in ascending
order. If a route matches an entry, the route will not be matched with the next entry.
The NE40E denies all unmatched routes by default. If all entries in an IPv4 prefix
list are in deny mode, all routes will be denied by the IPv4 prefix list. In this case,
define an entry permit 0.0.0.0 0 less-equal 32 after the entries in deny mode to
allow all the other IPv4 routes to be permitted by the IPv4 prefix list.

NOTE
If more than one IP prefix entry is defined, at least one entry should be set in permit mode.
c. Run:
commit

l Configure an AS_Path filter.
An AS_Path filter is used to filter BGP routes based on the AS_Path attributes contained
in the BGP routes. If you do not want traffic to pass through an AS, configure an
AS_Path filter to filter out the traffic carrying the AS number. If the BGP routing table of
each device on a network is large, configuring an ACL or an IP prefix list to filter BGP
routes may be complicated and make it difficult to maintain new routes.
NOTE
If the AS_Path information of a summarized route is lost, the AS_Path filter cannot be used to
filter the summarized route, but can still be used to filter the specific routes from which the
summarized route is derived.
An AS_Path filter can be used as a filtering condition of a route-policy or be used in the

peer as-path-filter command.
a. Run:
system-view

b. Run:
ip as-path-filter { as-path-filter-number | as-path-filter-name }
[ index index-number ] { permit | deny } regular-expression
An AS_Path filter is configured.
An AS_Path filter defines matching rules with a regular expression. The regular
expression is composed of the following parts:
n Metacharacter: defines matching rules.

n General character: defines matching objects.
Table 10-2 Description of metacharacters
Special Function
Character
\ Defines an escape character, which is used to mark the next

character (common or special) as a common character.
^ Matches the start position of the string.
$ Matches the end position of the string.
* Matches the preceding element zero or more times.
+ Matches the preceding element once or more times
? Matches the preceding element zero times or once.

Special Function
Character
. Matches any single character.
() Defines a subexpression, which can be empty. Both the

expression and the subexpression must match.
_ Matches regular expressions with a sign, such as a comma

(,), left brace ({), right brace (}), left parenthesis ((), right
parenthesis ()), or space. The underscore (_) can be used at
the beginning of a regular expression with the same function
as the caret (^) or at the end of a regular expression with the
same function as the dollar sign ($).
x|y Matches x or y.
[xyz] Matches any character in the regular expression.
[^xyz] Matches any character that is not contained within the

brackets.
[a-z] Matches any character within the specified range.
[^a-z] Matches any character beyond the specified range.
For example, ^10 matches only the AS_Path attribute beginning with 10. ^ indicates
the beginning of a string character.
You can define multiple rules (permit or deny) for the same filter. During the
matching, the relationship between these rules is OR. If a route meets one of the
matching rules, it matches this AS_Path filter.
NOTE
For details on a regular expression, see the HUAWEI NetEngine40E Universal Service
Router Configuration Guide - Basic Configurations.
c. Run:
commit

l Configure a community filter.
A BGP community attribute is used to identify a group of routes with the same
properties. Routes can be classified through the community attribute, which facilitates
route management.
Some AS internal routes may not need to be advertised to any other AS, while AS
external routes need to be advertised to other ASs. These AS external routes have
different prefixes (as a result, an IP prefix list is inapplicable) and may come from
different ASs (as a result, an AS_Path filter is inapplicable). You can set a community
attribute value for these AS internal routes and another community attribute value for
these AS external routes on an ASBR to control and filter these routes.
a. Run:
system-view


b. Run:
ip community-filter
A community filter is configured.

n To configure the standard community filter, run the ip community-filter basic
comm-filter-name [ index index-number ] { permit | deny } [ community-
number | aa:nn | internet [ strict-match ] | no-export-subconfed | no-
advertise | no-export ] &<1-20> command, or the ip community-filter basic-
comm-filter-num [ index index-number ] { permit | deny } [ community-
number | aa:nn | internet | no-export-subconfed | no-advertise | no-export ]
&<1-20> command.
n To configure the advanced community filter, run the ip community-filter
{ advanced comm-filter-name | adv-comm-filter-num } [ index index-number ]
c. Run:
commit

l Configure an extended community filter.
Similar to a BGP community filter, a BGP extcommunity filter is used to filter private
network routes.
a. Run:
system-view

b. Perform either of the following operations as required to configure an
extcommunity filter.
To configure a VPN-Target extcommunity filter:
n To configure a basic VPN-Target extcommunity filter, run the ip
extcommunity-filter { basic-extcomm-filter-num | basic basic-extcomm-filter-
name }[ index index-number ] { deny | permit } { rt { as-number:nn | 4as-
number:nn | ipv4-address:nn } } &<1-16> command.
n To configure an advanced VPN-Target extcommunity filter, run the ip
extcommunity-filter { advanced-extcomm-filter-num | advanced advanced-
extcomm-filter-name }[ index index-number ] { deny | permit } regular-
expression command.
To configure an SoO extcommunity filter:
n To configure a basic SoO extcommunity filter, run the ip extcommunity-list
soo basic basic-extcomm-filter-name [ index index-number ] { permit | deny }
{ site-of-origin } &<1-16> command.
n To configure an advanced SoO extcommunity filter, run the ip extcommunity-
list soo advanced advanced-extcomm-filter-name [ index index-number ]
Multiple entries can be defined in an extcommunity filter. The relationship between
the entries is "OR". This means that if a route matches one of the rules, the route
matches the filter.

c. Run:
commit

A route-policy is used to match routes or route attributes, and to change route attributes
when specific conditions are met. As the preceding filters can be used as matching
conditions of a route-policy, the route-policy is powerful in functions and can be used
flexibly.
a. Run:
system-view

b. Run:
A node is configured for a route-policy, and the view of the route-policy is

displayed.
A route-policy consists of multiple nodes. For example, the route-policy route-

policy-example permit node 10 command specifies node 10 and the route-policy
route-policy-example deny node 20 command specifies node 20. The two nodes
belong to the route-policy specified by route-policy-example. The relationship
between the nodes of a route-policy is "OR". The details are as follows:
n If a route matches one node, the route matches the route-policy and will not be
matched against the next node. For example, there are two nodes defined using
the route-policy route-policy-example permit node 10 and route-policy
route-policy-example deny node 20 commands. If a route matches the node
defined using the route-policy route-policy-example permit node 10
command, the route will not be matched against the node defined using the
route-policy route-policy-example deny node 20 command.
n If a route does not match any node, the route fails to match the route-policy.
When a route-policy is used to filter a route, the route is first matched against the
node with the smallest node value. For example, if two nodes are configured using
the route-policy route-policy-example permit node 10 and route-policy route-
policy-example deny node 20 commands, a route is first matched against the node
configured using the route-policy route-policy-example permit node 10
command.
NOTE
The NE40E considers that each unmatched route fails to match the route-policy by default.
If more than one node is defined in a route-policy, at least one of them must be in permit
mode.
c. (Optional) Perform the following operations as needed to configure if-match
clauses for current nodes of the route-policy.
if-match clauses are used to filter routes. If no if-match clause is specified, all
routes will match the node in the route-policy.
n To configure an ACL as the if-match clause, run the if-match acl { acl-
number | acl-name } command.

n To configure an IP prefix list as the if-match clause, run the if-match ip-
prefix ip-prefix-name command.
NOTE
The if-match acl and if-match ip-prefix commands cannot be used together in the
same node of a route-policy, because the latest configuration will override the previous
one.
n To match the AS-Path attribute of BGP routes, run the if-match as-path-filter
as-path-filter-number &<1-16> command.
n To match the community attribute of BGP routes, run either of the following
commands:
○ if-match community-filter { basic-comm-filter-num [ whole-match ] |
adv-comm-filter-num } * &<1-16>
○ if-match community-filter comm-filter-name [ whole-match ]
○ if-match community-filter { adv-comm-filter-num sort-match } *
&<1-16>
○ if-match community-filter comm-filter-name sort-match
n To match the VPN-Target extended community attribute of BGP routes, run
the if-match extcommunity-filter { { basic-extcomm-filter-num | adv-
extcomm-filter-num } &<1-16> | basic-extcomm-filter-name | advanced-
extcomm-filter-name } command.
n To match the SoO extended community attribute of BGP routes, run the if-
match extcommunity-list soo extcomm-filter-name command.
if-match clauses or no if-match clause.
NOTE
The relationship between the if-match clauses in a node of a route-policy is "AND". A route
must match all the rules before the action defined by the apply clause is taken. For example,
if two if-match clauses (if-match acl 2003 and if-match as-path-filter 100) are defined in
the route-policy route-policy-example permit node 10 command, a route is considered to
match node 10 only when it matches the two if-match clauses.
d. (Optional) Perform the following operations as needed to configure apply clauses
for current nodes of the route-policy.
apply clauses can be used to set attributes for routes matching if-match clauses. If
this step is not performed, the attributes of routes matching if-match clauses keep
unchanged.
n To replace or add a specified AS number in the AS_Path attribute of a BGP

route, run the apply as-path as-number command.
n To delete a specified BGP community attribute from a route, run the apply
comm-filter { comm-filter-number | comm-filter-name } delete command.
NOTE
The apply comm-filter delete command deletes a specified community attribute from
a route. An instance of the ip community-filter command can specify only one
community attribute each time. To delete more than one community attribute, run the
ip community-filter command multiple times. If multiple community attributes are
specified in one community filter, none of them can be deleted. For more information,
see the HUAWEI NetEngine40E Universal Service Router Command Reference.

n To delete all community attributes from a BGP route, run the apply
community none command.
n To set community attributes for a BGP route, run the apply community
{ { community-number | aa:nn } &<1-32> | internet | no-advertise | no-
export | no-export-subconfed } * [ additive ], or apply community
community-list community-list-name command.
NOTE
A BGP community list must be configured using the ip community-list command and
community attributes must be configured for the list using the community command
before you run the apply community community-list community-list-name command.
n To set a VPN-Target extended community attribute for a route, run the apply
extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16>
[ additive ] command.
n To set an SoO extended community attribute for a route, run the apply
extcommunity soo { site-of-origin } &<1-16> additive command.
n To set the local preference for a BGP route, run the apply local-preference [ +
| - ] preference command.
n To set the Origin attribute for a BGP route, run the apply origin { egp { as-
number-plain | as-number-dot } | igp | incomplete } command.
n To set a preferred value for a BGP route, run the apply preferred-value
preferred-value command.
n To set dampening parameters for an EBGP route, run the apply dampening
half-life-reach reuse suppress ceiling command.
apply clauses or no apply clause.
e. Run:
commit
----End
10.6.2 Controlling the Acceptance of BGP Routing Information

After an import policy is configured, only the routes that match the import policy can be
accepted.
Procedure
l Configure BGP to receive routes from all its peers or peer groups.
You can configure a BGP device to filter routes to be received.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Perform either of the following operations to configure the BGP device to filter the
routes received from all its peers or peer groups:
1) Run filter-policy { acl-number | acl-name acl-name } import, the
received routes is filtered based on an ACL.
the system.
system.
whitelist:

n To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-
prefix-name import command.
NOTE
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.
e. Run:
commit

l Configure a BGP device to receive routes from a specific peer or peer group.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Perform any of the following configurations to configure the BGP device to filter
the routes received from a specific peer or peer group:
1) Run peer { ipv4-address | group-name } filter-policy { acl-number | acl-
name acl-name } import, the advertised routes is filtered based on an
ACL.

the system.
system.
whitelist:
n To filter routes based on the IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-name import command.
n To filter routes based on the AS_Path filter, run the peer { ipv4-address |
group-name } as-path-filter { as-path-filter-number | as-path-filter-name }
import command.
n To filter routes based on the route-policy filter, run the peer { ipv4-address |
group-name } route-policy route-policy-name import command.
NOTE
The routing policy set in the peer route-policy import command does not support a
certain interface as one of the matching rules. That is, the routing policy does not
support the if-match interface command.
A peer group and its members can use different import policies when receiving
routes. This means that each member in a peer group can select its own policy to
filter received routes.
e. Run:
commit

l Limit the number of the routes received from a peer.
When the router running BGP is attacked or network configuration errors occur, the
router receives a large number of routes from its neighbor. As a result, a large number of
resources of the router are consumed. Therefore, the administrator must limit the
resources used by the router based on network planning and the capacity of the router.
BGP provides peer-based route control to limit the number of routes to be sent by a
neighbor. Thus, the preceding problem is addressed.
a. Run:

system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
peer { group-name | ipv4-address } route-limit limit [ percentage ]
[ alert-only | idle-forever | idle-timeout minutes ]
The number of routes that can be received from a peer or peer group is set.
The command provides the limit on the number of received routes based on peers.
You can configure specific parameters as required to control BGP after the number
of the routes received from a peer exceeds the threshold.
n alert-only: The peer relationship is kept. No route is received after the number
of received routes exceeds the threshold, and an alarm is generated and
recorded in the log.
n idle-forever: The peer relationship is interrupted. The router does not retry
setting up a connection. An alarm is generated and recorded in the log. In this
case, run the display bgp peer [ verbose ] command, and you can find that the
status of the peer is Idle. To restore the BGP connection, run the reset bgp
command.
n idle-timeout: The peer relationship is interrupted. The router retries setting up
a connection after the timer expires. An alarm is generated and recorded in the
log. In this case, run the display bgp peer [ verbose ] command, and you can
find that the status of the peer is Idle. To restore the BGP connection before the
timer expires, run the reset bgp command.
n If none of the preceding parameters is set, the peer relationship is
disconnected. The router retries setting up a connection after 30 seconds. An
alarm is generated and recorded in the log.
NOTE
If the number of routes received by the local router exceeds the upper limit and the peer route-
limit command is used for the first time, the local router and its peer reestablish the peer
relationship, regardless of whether alert-only is set.
e. Run:
commit
----End
10.6.3 (Optional) Configuring BGP Soft Reset

The inbound BGP soft reset allows the system to apply the new import policies immediately
and refresh BGP routing table dynamically without tearing down any BGP connection.

Context
After changing a BGP import policy, you can reset BGP connections for the new import
policy to take effect, interrupting these BGP connections temporarily. BGP route-refresh
allows the system to refresh a BGP routing table dynamically without tearing down any BGP
connection if routing policies are changed.
l If a device's peer supports route-refresh, the refresh bgp command can be used on the
device to softly reset the BGP connection with the peer and update the BGP routing
table.
l If a device's peer does not support route-refresh, the peer keep-all-routes command can
be used on the device to remain all routing updates received from the peer so that the
device can refresh its routing table without closing the connection with the peer.
Procedure
l If the device's peers support route-refresh, perform the following operations:
a. (Optional) Enable route-refresh.
i. Run:
system-view

ii. Run:
bgp as-number

iii. Run:
peer { ipv4-address | group-name } capability-advertise route-refresh
Route-refresh is enabled.
iv. Run:
commit

If route-refresh is enabled on all BGP peers and the import policy of the local router
is changed, the local router sends a route-refresh message to peers or peer groups.
After receiving the message, the peers or peer groups resend routing information to
the local BGP device. This enables the local router to dynamically refresh its BGP
routing table and apply the new routing policy without terminating any BGP
connections.
b. Configure BGP soft reset.
i. Run the refresh bgp [ vpn-instance vpn-instance-name ipv4-family | vpnv4 ]
{ all | ipv4-address | group group-name | external | internal } import
command in the user view to trigger inbound BGP soft resetting.
external softly resets an EBGP connection, and internal softly resets an IBGP
connection.
l If the device's peers do not support route-refresh, perform the following operations:
– Configure the device to store all the routing updates received from its peers or peer
groups.
i. Run:
system-view

ii. Run:
bgp as-number

iii. Run:
ipv4-family unicast

iv. Run:
peer { ipv4-address | group-name } keep-all-routes
The device is configured to store all the routing updates received from its peers
or peer groups.
After this command is used, all routing updates sent by a specified peer or peer
group are stored, regardless of whether an import policy is used. When the
local routing policy changes, the information can be used to regenerate BGP
routes again.
NOTE
This command must be run on the local device and its peers. If the peer keep-all-
routes command is run on the device for the first time, the sessions between the device
and its peers are reestablished.
The peer keep-all-routes command does not need to be run on the router that supports
route-refresh. If the peer keep-all-routes command is run on the router, the sessions
between the router and its peers will not be reestablished but the refresh bgp
command does not take effect on the router.
v. Run:
commit
----End

After controlling BGP to receive routes, check imported routes matching a specified filter.
Prerequisites
Configurations have been performed to control BGP to receive routes.
Procedure
l 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.
l 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.
l Run the display ip extcommunity-filter [ basic-extcomm-filter-num | advanced-
extcomm-filter-num | extcomm-filter-name ] command to check information about a
configured VPN-Target extcommunity filter.
l Run the display ip extcommunity-list soo [ extcomm-filter-name ] command to check
information about a configured SoO extcommunity filter.
l Run the display bgp routing-table as-path-filter as-path-filter-number command to
check information about routes matching a specified AS_Path filter.


command to check information about routes matching a specified BGP community filter.
l Run the display bgp routing-table peer ipv4-address received-routes [ statistics ]
command to check information about routes received by a BGP device from its peers.
l Run the display bgp routing-table peer ipv4-address received-routes network { mask |
mask-length } original-attributes command to check information about the original
attributes of specified routes.
----End
Example
After an community filter is configured, run the display ip community-filter [ basic-comm-
filter-num | adv-comm-filter-num | comm-filter-name ]command in the system view to view
information about the configured community filter. Run the display bgp routing-table peer
ipv4-address received-routes command to view information about the routes that are received
by a BGP device from a specified peer
# View information about a configured community filter.

<HUAWEI> display ip community-filter
Community filter Number 10

index: 10 deny no-export
Community filter Number 110
index: 10 permit 110:110
Named Community basic filter: aa (ListID = 200)
index: 10 permit 1 internet
Named Community advanced filter: bb (ListID = 700)
index: 10 permit 20
# View the routes that are received by a BGP device from its peer at 2.2.2.2.
<HUAWEI> display bgp routing-table peer 2.2.2.2 received-routes


*> 1.1.1.1/32 2.2.2.2 0 0 200?

*> 4.4.4.4/32 2.2.2.2 1 0 200i
10.7 Using XPL to Filter the BGP Routes to Be Advertised

A BGP device can use a route-filter to filter the routes to be advertised and modify route
Usage Scenario
BGP is used to transmit routing information between ASs, and route advertisement directly

In most cases, a BGP routing table has a large number of routes. Transmitting them will
intensify the load of a device. To address this problem, configure the device to advertise only
desired routes.
In addition, multiple routes to the same destination may exist and travel through different
ASs. To direct routes to specific ASs, you also need to filter the routes to be advertised.
You can use XPL route-filters to control the BGP routes to be advertised to all peers or peer
groups or to a specified peer or peer group.
Before using XPL to filter the BGP routes to be advertised, configure basic BGP functions.
Procedure
l Use XPL to filter the BGP routes to be advertised to all peers or peer groups.
Perform the following steps on the BGP device:
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
route-filter route-filter-name export [ direct | isis process-id | ospf
process-id | rip process-id | static ]
The BGP device is configured to filter the routes to be advertised to all peers or
peer groups.
e. Run:
commit

l Use XPL to filter the BGP routes to be advertised to a specific peer or peer group.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast


d. Run:
peer { group-name | ipv4-address } route-filter route-filter-name export
The BGP device is configured to filter the routes to be advertised to the specified
peer or peer group.
e. Run:
commit
----End
Checking the Configuration

Run the following commands to check configurations:
l Run the display xpl route-filter state [ attached | unattached ] command to check
information about the configured route-filter.
l Run the display bgp routing-table [ peer ipv4-address advertised-routes [ statistics ] ]
command to check the routes in the BGP routing table.
# Run the display xpl route-filter state command to view information about the configured
route-filter.
<HUAWEI> display xpl route-filter state
Attached :Applied by at least one attach point

Unattached : Not applied by any attach point
Attached
---------------------------------------------------------------
r1
Unattached
---------------------------------------------------------------
# Run the display bgp routing-table peer ipv4-address advertised-routes command to view
routes in the BGP routing table.
<HUAWEI> display bgp routing-table peer 1.1.1.1 advertised-routes


*> 3.3.3.3/32 1.1.1.2 0 0 200?

*> 1.1.1.0/30 1.1.1.2 0 0 200?
*> 1.1.1.1/32 1.1.1.2 0 0 200?
*> 1.3.1.0/30 1.1.1.2 0 0 200?
*> 1.3.1.1/32 1.1.1.2 0 0 200?
*> 1.4.1.0/30 1.1.1.2 0 0 200?
*> 1.4.1.1/32 1.1.1.2 0 0 200?

10.8 Using XPL to Filter the BGP Routes to Be Received

A BGP device can use a route-filter to filter the routes to be received and modify route
Usage Scenario
BGP is used to transmit routing information between ASs, and route advertisement directly
A BGP device may receive multiple routes to the same destination network from different
peers. To control the network traffic forwarding path, filter the routes to be received.
In addition, a BGP device may receive a large number of routes during an attack, which may
consume lots of device resources. In this case, the administrator must limit the resource
consumption based on the network planning and device performance.
You can use XPL route-filters to control the BGP routes to be received from all peers or peer
groups or from a specified peer or peer group.
Before using XPL to filter the BGP routes to be received, configure basic BGP functions.
Procedure
l Use XPL to filter the BGP routes to be received from all peers or peer groups.
a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
route-filter route-filter-name import
The BGP device is configured to filter the routes to be received from all peers or
peer groups.
e. Run:
commit

l Use XPL to filter the BGP routes to be received from a specific peer or peer group.

a. Run:
system-view

b. Run:

c. Run:
ipv4-family unicast

d. Run:
peer { group-name | ipv4-address } route-filter route-filter-name import
The BGP device is configured to filter the routes to be received from the specified
peer or peer group.
e. Run:
commit

----End

l Run the display xpl route-filter state [ attached | unattached ] command to check
information about the configured route-filter.
l Run the display bgp routing-table [ peer ipv4-address received-routes [ statistics ] ]
command to check the routes in the BGP routing table.
# Run the display xpl route-filter state command to view information about the configured
route-filter.
<HUAWEI> display xpl route-filter state
Attached :Applied by at least one attach point

Unattached : Not applied by any attach point
Attached
---------------------------------------------------------------
r1
Unattached
---------------------------------------------------------------
# Run the display bgp routing-table peer ipv4-address received-routes command to view
routes in the BGP routing table.
<HUAWEI> display bgp routing-table peer 1.1.1.2 received-routes


*> 1.3.1.0/30 11.1.1.2 0 0 200?

*> 1.3.1.1/32 11.1.1.2 0 0 200?
10.9 Configuring BGP Route Aggregation

Configuring BGP Route Aggregation on a device can reduce the sizes of routing tables on the
peers of the device.
Usage Scenario
The BGP routing table of a device on a medium or large BGP network contains a large
number of routing entries. Storing the routing table consumes a large number of memory
resources, and transmitting and processing routing information consume lots of network
resources. Configuring route aggregation can reduce the size of a routing table, prevent
specific routes from being advertised, and minimize the impact of route flapping on network
performance. BGP route aggregation and routing policies enable BGP to effectively transmit
and control routes.
BGP supports automatic and manual aggregation. Manual aggregation takes precedence over
automatic aggregation.
Before configuring BGP route aggregation, complete the following task:
Procedure
l Configure automatic route aggregation.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Run:
summary automatic
Automatic aggregation is configured for imported routes.
The summary automatic command aggregates routes imported by BGP. The routes
can be direct routes, static routes, RIP routes, OSPF routes, or IS-IS routes. After
this command is run, BGP aggregates routes based on natural network segments.
The command, however, cannot aggregate routes imported using the network
command.

e. Run:
commit

l Configure manual route aggregation.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

d. Configure manual aggregation according to the actual networking.
n To advertise both the aggregated route and specific routes, run the aggregate
ipv4-address { mask | mask-length } command.
n To advertise only the aggregated route, run the aggregate ipv4-address { mask
| mask-length } detail-suppressed command.
n To advertise a specific route, run the aggregate ipv4-address { mask | mask-
length } suppress-policy route-policy-name command.
To advertise a specific route, you can also run the peer route-policy
command.
n To generate an aggregated route used to detect a loop, run the aggregate ipv4-
address { mask | mask-length } as-set command.
n To set the attributes of an aggregated route, run the aggregate ipv4-address
{ mask | mask-length } attribute-policy route-policy-name command.
To set the attributes of an aggregated route, you can also run the peer route-
policy command.
If as-set is set in the aggregate command and the apply as-path command is
run to set the AS_Path attribute, the AS_Path attribute does not take effect.
n To generate an aggregated route according to certain specific routes, run the
aggregate ipv4-address { mask | mask-length } origin-policy route-policy-
name command.
Manual aggregation is valid for the existent routing entries in the local BGP routing
table. For example, if the route with the mask length longer than 16 such as
10.1.1.1/24, does not exist in the BGP routing table, BGP does not advertise the
aggregated route after the aggregate 10.1.1.1 16 command is used to aggregate
routes.
e. Run:
commit
----End

Checking the Configurations

After route aggregation is configured, you can check whether the configuration is correct.
l Run the display bgp routing-table [ network [ mask | mask-length ] ] command to check
information about BGP aggregated routes.
# Run the display bgp routing-table network command to view information about BGP
aggregated routes.

From: 10.2.1.2 (3.3.3.3)
Relay IP Nexthop: 10.2.1.2
Relay IP Out-interface: GigabitEthernet1/0/0
AS-path 100, origin incomplete, pref-val 0, valid, external, best, select, pre
255
Aggregator: AS 100, Aggregator ID 3.3.3.3, Atomic-aggregate
10.1.1.1
10.2.1.2
10.10 Configuring a BGP Peer Group

Configuring BGP peer groups simplifies the BGP network configuration and improves the
route advertisement efficiency.
Usage Scenario
A BGP peer group consists of BGP peers that have the same update policies and
configurations.
A large-scale BGP network has a large number of peers. Configuring and maintaining these
peers is difficult. To address this problem, configure a BGP peer group for BGP peers with the
same configurations. Configuring BGP peer groups simplifies peer management and
improves the route advertisement efficiency.
Based on the ASs where peers reside, peer groups are classified as follows:
l IBGP peer group: The peers of an IBGP peer group are in the same AS.
l Pure EBGP peer group: The peers of a pure EBGP peer group are in the same external
AS.
l Mixed EBGP peer group: The peers of a mixed EBGP peer group are in different
external ASs.
If a function is configured on a peer and its peer group, the function configured on the peer
takes effect. After a peer group is created, peers can be added to the peer group. If these peers
are not configured separately, they will inherit the configurations of the peer group. If a peer
in a peer group has a specific configuration requirement, the peer can be configured
separately. The configuration of this peer will override the configuration that the peer has
inherited from the peer group.

Before configuring BGP peer groups, configure basic BGP functions.
10.10.1 Creating an IBGP Peer Group

If multiple IBGP peers exist, adding them to an IBGP peer group can simplify the BGP
network configuration and management. When creating an IBGP peer group, you do not need
to specify an AS number for the IBGP peer group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
group group-name internal
An IBGP peer group is created.
Step 4 Run:
peer ipv4-address group group-name
A peer is added to the peer group.
NOTE
You can repeat step 4 to add multiple peers to the peer group. If the local device has not established a
peer relationship with this peer, the device will attempt to establish a peer relationship with this peer, and
set the AS number of this peer to the AS number of the peer group.
When creating an IBGP peer group, you do not need to specify the AS number.
After configuring a peer group, you can configure BGP functions for the peer group. By
default, all peers in a peer group inherit the entire configuration of the peer group. If you
configure a peer in a peer group independently. The configuration of this peer will override
the configuration that the peer has inherited from the peer group.

peer group-name description description-text
The description of the peer group is configured.
Step 6 Run:
commit

----End
10.10.2 Creating a Pure EBGP Peer Group

If multiple EBGP peers exist in an AS, adding them to an EBGP peer group can simplify the
BGP network configuration and management. All the peers in a pure EBGP peer group must
have the same AS number.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
group group-name external
A pure EBGP peer group is created.
Step 4 Run:
peer group-name as-number as-number
An AS number is set for the EBGP peer group. If peers already exist in a peer group, you can
neither change the AS number of the peer group nor delete the AS number of the peer group
using the undo peer as-number command.
Step 5 Run:
A peer is added to the peer group.
NOTE
You can repeat step 5 to add multiple peers to the peer group. If the local device has not established a
peer relationship with this peer, the device will attempt to establish a peer relationship with this peer, and
set the AS number of this peer to the AS number of the peer group.

Step 7 Run:
commit

----End
10.10.3 Creating a Mixed EBGP Peer Group

If multiple EBGP peers exist in different ASs, adding them to a mixed EBGP peer group can
simplify the BGP network configuration and management. When creating a mixed EBGP peer
group, you need to specify an AS number for each peer.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
group group-name external
A mixed EBGP peer group is created.

Step 4 Run:
A peer is created and an AS number is set for this peer.

Step 5 Run:
The peer is added to the peer group.
NOTE
You can repeat Steps 4 and 5 to add multiple peers to the peer group.
You need to specify an AS number for each peer in a mixed EBGP peer group.

Step 7 Run:
commit
----End


After configuring a BGP peer group, check information about BGP peers and BGP peer
groups.
Prerequisites
A BGP peer group has been configured.
Procedure
l Run the display bgp peer [ ipv4-address ] verbose command to check detailed
information about BGP peers.
l Run the display bgp group [ group-name ] command to check information about BGP
peer groups.
NOTE
This command is applied only to devices on which BGP peer groups are created.
If a peer group is specified in this command, detailed information about this peer group
will be displayed. If no peer group is specified in this command, information about all
BGP peer groups is displayed.
----End
Example
Run the display bgp group [ group-name ] command in the system view to view information
about a specified peer group.
# View information about a peer group named my-peer.
<HUAWEI> display bgp group my-peer
BGP peer-group: my-peer
Remote AS 200
Group's BFD has been enabled
Type : internal
Maximum allowed route limit: 150000
Threshold: 75%
Configured hold timer value: 180
Keepalive timer value: 60
Minimum route advertisement interval is 15 seconds
listen-only has been configured
PeerSession Members:
2.2.2.2
Peer Preferred Value: 0
No routing policy is configured
Peer Members:
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
2.2.2.2 4 200 0 0 0 00:00:47 Active 0
10.11 Configuring a BGP Route Reflector

By configuring a BGP route reflector (RR), you can avoid fully meshed connections between
multiple IBGP peers.
Usage Scenario
Fully meshed connections need to be established between IBGP peers to ensure the
connectivity between IBGP peers. If there are n routers in an AS, n x (n-1)/2 IBGP

connections need to be established. When there are a lot of IBGP peers, network resources
and CPU resources are greatly consumed. Route reflection can solve the problem.
RRs can reduce the total number of IBGP connections. On a large network, to reduce the
number of clients of each route reflector, you need to configure multiple RRs. Because fully
meshed connections need to be established between RRs, there are still a large number of
IBGP connections on the network. In this situation, configure hierarchical RRs to further
reduce the number of IBGP connections.
Figure 10-5 shows typical networking with hierarchical RRs. In this networking, R1, R2, R3,
and R4 function as Level-1 RRs; R5, R6, R7, and R8 function as level-2 RRs and the clients
of level-1 RRs. Level-1 RRs are not the clients of any RR and must be fully meshed. Level-2
RRs function as the clients of Level-1 RRs and do not need to be fully meshed.
Figure 10-5 Typical networking with hierarchical RRs
AS 100
Level-1 RR
R1 R2 AS 200
R13
R3 R4
R14
Level-2 RR
R6
R5 R8
R7
R9 Client R10 R11 R12

Client
Before configuring a BGP route reflector, configure basic BGP functions.

Figure 10-6 Flowchart for configuring a BGP route reflector
Configuring a Route Reflector and

Specifying Clients
Disabling Route Reflection Between

Clients
Setting the Cluster ID of a Route

Reflector
Preventing BGP Routes from Being

Added into the IP Routing Table
Enabling the RR to Modify the Route

Attributes Using the Export Policy
Mandatory
procedure
Optional
procedure
10.11.1 Configuring a Route Reflector and Specifying Clients

RRs can reflect routes between clients, and clients do no need to establish IBGP connections.
Context
In an AS, one router functions as an RR, the other routers function as clients. IBGP
connections are established between the RR and its clients. The RR and its clients form a
cluster. The RR transmits (or reflects) routes between clients, and clients do not need to
establish IBGP connections.
An RR simplifies configurations because all configurations need to be configured only on the
RR and clients do not need to know that they are clients.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

Step 4 Run:
peer { ipv4-address | group-name } reflect-client
An RR and its client are configured.

The router on which the peer reflect-client command is run serves as the RR, and the
specified peer or peer group functions as a client.
NOTE
The configurations of RRs and clients in an address family are valid only in this address family and
cannot be inherited by other address families. Therefore, configure RRs and clients in the required
address family.
Step 5 Run:
commit
----End
10.11.2 (Optional) Disabling Route Reflection Between Clients

Through the RR
If the clients of a route reflector are fully connected, you need to disable route reflection
among them through the RR to reduce bandwidth consumption.
Context
On some networks, if fully meshed IBGP connections have been established between clients,
they can directly exchange routing information. Therefore, route reflection between clients
through the RR is unnecessary, which also occupies bandwidth. In this case, disable route
reflection among them through the RR.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

Step 4 Run:
undo reflect between-clients
Route reflection is disabled among clients through the RR.

If the clients of the route reflector are fully connected, you can use the undo reflect between-
clients command to disable route reflection among the clients through the RR. This command
is applicable to only the route reflector.

Step 5 Run:
commit
----End
10.11.3 (Optional) Setting the Cluster ID of a Route Reflector

When there are multiple route reflectors in a cluster, you need to configure the same cluster
ID for all the route reflectors in this cluster to avoid routing loops.
Context
To enhance network reliability and avoid single points of failure, more than one route
reflector can be configured in a cluster. In this case, you need to set the same cluster ID for all
the route reflectors in the same cluster. This can reduce the number of routes to be received by
each route reflector and save the memory.
NOTE
To ensure that a client can learn the routes reflected by a route reflector, the cluster ID of the route
reflector must be different from the router ID of the client. If they are the same, the client discards the
received routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
reflector cluster-id cluster-id
The cluster ID of a route reflector is set.
When there are multiple route reflectors in a cluster, you need to run the command to
configure the same cluster-id for all the route reflectors in this cluster.
The reflector cluster-id command can be configured on only route reflectors.
Step 5 Run:
commit
----End

10.11.4 (Optional) Enabling an RR to Modify Route Attributes

Using an Export Policy
You can enable an RR to modify route attributes using an export policy to control BGP route
selection.
Context
The route attributes on an RR cannot be modified using an export policy. This is because it
may cause route loops. By default, the RR is disabled from modifying the route attributes
using an export policy. But if you need to re-plan the network traffic, you can enable the RR
to modify the route attributes using an export policy.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
reflect change-path-attribute
You can enable the RR to modify BGP route attributes using an export policy.
After you enable the reflect change-path-attribute command on an RR, the configurations
of the RR attributes modified using the export policy takes effect immediately. Perform the
following operations:
l Run the apply as-path command to modify the AS-Path attributes of BGP routes.
l Run the apply comm-filter delete command to delete all community attributes from a
BGP route.
l Run the apply community command modifies the community attributes of BGP routes.
l Run the apply cost command to modify the cost of BGP routes, that is, to modify its
MED.
l Run the apply ip-address nexthop command to modify the next hop of the BGP routes.
l Run the apply local-preference command to modify the local preference of BGP routes.
l Run the apply origin command to modify the Origin attributes of BGP routes.
l Run the apply extcommunity command to modify the VPN-Target extended community
attributes of BGP routes.
l Run the apply extcommunity soo { Site-of-origin &<1-16> } additive command to
modify the SoO extended community attributes of BGP routes.

NOTE
After the reflect change-path-attribute command is run on the RR, the peer route-policy export
command takes precedence over the peer next-hop-invariable and peer next-hop-local commands.
Step 5 Run:
commit
----End

After configuring a BGP route reflector, check information about BGP routes and BGP peer
groups.
Prerequisites
A BGP route reflector has been configured.
Procedure
peer groups.
----End
Example
Run the display bgp routing-table [ network ] command to view information about the BGP
routing table.

From: 10.1.4.1 (2.2.2.2)
Route Duration: 00h00m14s
Relay IP Out-Interface:
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 1.1.1.1
Cluster list: 0.0.0.1
Not advertised to any peer yet
10.12 Configuring a BGP Confederation

On a large BGP network, configuring a BGP confederation reduces the number of IBGP
connections and simplifies routing policy management, which increases the route
advertisement efficiency.

Usage Scenario
A confederation is a solution to the increasing number of IBGP connections in an AS. The
confederation divides an AS into multiple sub-ASs. In each sub-AS, IBGP peer relationships
are set up or an RR is configured on one of the IBGP peers. EBGP connections are set up
between sub-ASs.
NOTE
Compared with RRs, confederations facilitate IGP extensions.
Before configuring a BGP confederation, complete the following tasks:
l Configure link layer protocol parameters and assigning IP addresses to the interfaces to
ensure that the status of the link layer protocol of the interface is Up.
l Configure basic BGP functions.
Procedure
l Configure a BGP Confederation.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
confederation id as-number
The confederation ID is set.

d. Run:
confederation peer-as as-number &<1-32>
The number of the sub-AS of other EBGP peers is set.
The parameter as-number used is valid only in the confederation.
The confederation id and confederation peer-as commands must be run for all the
EBGP peers in a confederation, and the EBGP peers must have the same
confederation ID.
NOTE
The old speaker supporting 2-byte AS numbers and the new speaker supporting 4-byte AS
numbers cannot exist in the same confederation. Otherwise, routing loops may occur
because AS4_Path does not support confederations.
e. Run:
commit

l Configure the compatibility of the confederation.

If some routers in a confederation do not comply with the standard protocols, you can
perform the following steps so that the local device is compatible with them:
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
confederation nonstandard
The compatibility of the confederation is configured.

d. Run:
commit

----End

Run the following command to check the previous configuration:
information about the peer.
# Run the display bgp routing-table network command to view the confederation
information contained in a BGP route.
From: 10.1.3.1 (1.1.1.1)
Relay IP Out-Interface: GigabitEthernet1/0/0
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-
confed, best, select, active, pre 255
10.13 Configuring BGP Community Attributes

Community attributes simplifies routing policy management.
Usage Scenario
Community attributes are used to simplify routing policy application and facilitate network
maintenance. They allow a group of BGP devices in different ASs to share the same routing

policies. Before advertising a route with the community attribute to peers, a BGP device can
change the original community attribute of this route. Community attributes are route
attributes, which are transmitted between BGP peers, and the transmission is not restricted
within an AS.
Before configuring BGP community attributes, configure basic BGP functions.
Figure 10-7 Configuring BGP community attributes
Configuring Community
Attribute-Related Routing Policies
Configuring a BGP Device to Send

Community Attributes to Its Peer
Mandatory
procedure
Optional
procedure
10.13.1 Configuring a Community Attribute-Related Routing

Policy
A routing policy that references a community attribute needs to be configured before the
community attribute is advertised.
Procedure
Step 1 Run:
system-view

Step 2 Run:
A node is configured for a routing policy, and the view of the routing policy is displayed.
Step 3 (Optional) Configure filtering conditions (if-match clauses) for a routing policy.
Community attributes can be added only to the routes that match the policy, and the
community attributes of only the routes that match the policy can be modified.
For configuration details, see (Optional) Configuring if-match Clauses.
Step 4 Configure community or extended community attributes for BGP routes.
l Run:
apply community { { community-number | aa:nn } &<1-32> | internet | no-
advertise | no-export | no-export-subconfed }* [ additive ]

Community attributes are configured for BGP routes.

l Run:
apply extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16>
[ additive ]
VPN-Target extended community attributes are configured for BGP routes.

l Run:
apply extcommunity soo { site-of-origin } &<1-16> additive
Site-of-Origin (SoO) extended community attributes are configured for BGP routes.
Step 5 Run:
commit
----End
10.13.2 Configuring Community Attribute Advertisement

A community attribute referenced by a routing policy takes effect only after the community is
advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
peer { ipv4-address | group-name } route-policy route-policy-name export
An export routing policy is configured.
NOTE
When configuring a BGP community, use a routing policy to define the community attribute, and
advertise routes based on the routing policy.
For details about routing policy configurations, see the chapter "Routing Policy Configuration."
Step 5 Run one of the following commands as required to advertise community attributes to a
specified peer or peer group.
l To advertise a standard community attribute to a specified peer or peer group, run:
peer { ipv4-address | group-name } advertise-community
l To advertise an extended community attribute to a specified peer or peer group, run:

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

NOTE
After the peer advertise-ext-community command is enabled, BGP sends the routes with
extended community attributes to its peer or peer group. If the peer or peer group does not want to
receive the extended community attributes, you can configure the peer discard-ext-community
command on the peer or peer group to discard the extended community attribute from the received
routing information.
Step 6 Run:
commit
----End

After configuring BGP community attributes, check the configured BGP community
attributes.
Prerequisites
A BGP community attribute has been configured.
Procedure
l Run the display bgp routing-table network [ mask | mask-length ] command to check
information about BGP routes.
l Run the display bgp routing-table community [ community-number | aa:nn ] &<1-29>
[ internet | no-advertise | no-export | no-export-subconfed ] * [ whole-match ]
command to check information about the routes carrying specified BGP community
attributes.
----End
Example
# Run the display bgp routing-table community command to view the routes carrying
specified BGP community attributes.
<HUAWEI> display bgp routing-table community
Network NextHop MED LocPrf PrefVal Community
* 1.1.1.0/24 1.1.1.1 0 0 no-export
* 1.1.1.2/32 1.1.1.1 0 0 no-export
*> 192.168.10.0 10.2.1.2 0 0 no-export-
subconfed
*> 192.168.15.0 10.2.1.2 0 0 internet
*> 192.168.18.0 10.2.1.2 0 0 no-advertise
10.14 Configuring Prefix-based BGP ORF

Prefix-based BGP ORF enables a device to send its peer the local prefix-based import policy
so that the peer can use the policy to filter routes before sending them to the local device.

Usage Scenario
When a device expects to receive only required routes from the remote device and the remote
end does not want to maintain a separate export policy for each connected peer, you can
configure prefix-based ORF which supports on-demand route advertisement.
Before configuring prefix-based BGP ORF, complete the following tasks:

l Configure an IPv4 prefix list.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
peer { group-name | ipv4-address } ip-prefix ip-prefix-name import
A prefix-based import policy is configured to filer routes advertised by the specified peer or
peer group.
Step 5 Run:
peer { group-name | ipv4-address } capability-advertise orf [ non-standard-
compatible ] ip-prefix { both | receive | send }
The prefix-based ORF is configured for the specified peer or peer group.
Step 6 Run:
commit
----End

Run the following command to check the previous configuration.
l Run the display bgp peer ipv4-address orf ip-prefix command to check routes received
from a specified peer after the prefix-based ORF is configured.

10.15 Adjusting the BGP Network Convergence Speed

You can adjust the BGP network convergence speed by adjusting BGP peer connection
parameters to adapt to changes on large-scale networks.
Usage Scenario
BGP is used to transmit routing information on large-scale networks. Frequent network
changes affect the establishment and maintenance of BGP peer relationships, which in turn
affects the BGP network convergence speed.
The route dampening and triggered update functions of BGP suppress frequent route changes
to a certain extent, but cannot minimize the impact of network flapping on BGP connections.
You can configure BGP timers and disable rapid EBGP connection reset to suppress BGP
network flapping and speed up BGP network convergence.
l BGP Keepalive and Hold timers
BGP uses Keepalive messages to maintain BGP peer relationships and monitor
connection status. After establishing a BGP connection, two peers send Keepalive
messages periodically to each other to detect the BGP connection status based on the
Keepalive timer. If a router does not receive any Keepalive message or any other types of
packets from its peer within the hold time set by the Hold timer, the router considers the
BGP connection interrupted and terminates the BGP connection.
l BGP MinRouteAdvertisementIntervalTimer
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 route changes frequently, to prevent the router from sending Update messages upon
every change, set the interval at which Update messages are sent.
l Rapid EBGP peer reset
Rapid EBGP connection reset is enabled by default so that EBGP can quickly detect the
status of interfaces used to establish EBGP connections. If the interface status changes
frequently, you can disable rapid EBGP connection reset so that direct EBGP sessions
will not be reestablished and deleted as interface alternates between Up and Down,
which speeds up network convergence.
l BGP ConnectRetry Timer
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 re-establishes 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, which speeds up the establishment of the TCP connection.
Setting a long connectRetry interval suppresses routing flapping caused by peer
relationship flapping.
After slow peer detection is configured on a device, the device identifies the slow BGP peer
(if any) and removes it from the update peer-group to prevent this slow peer from affecting
route advertisement to other peers in this update peer-group. Slow peer detection speeds up
BGP network convergence.

Before setting parameters for a BGP peer connection, configure basic BGP functions.
10.15.1 Configuring BGP Keepalive and Hold Timers

The values of BGP Keepalive and Hold timers determine the speed at which BGP detects
network faults. You can adjust the values of these timers to improve network performance.
Context
BGP uses Keepalive messages to maintain peer relationships. After establishing a BGP
connection, two peers periodically send Keepalive messages to each other to detect BGP peer
relationship status. If a device receives no Keepalive message from its peer after the Hold
timer expires, the device considers the BGP connection interrupted.
l If short Keepalive time and holdtime are set, BGP can fast detect link faults. This speeds
up BGP network convergence, but increases the number of Keepalive messages on the
network and loads of routers, and consumes more network bandwidth resources.
l If long Keepalive time and holdtime are set, the number of Keepalive messages on the
network and loads of routers are reduced. If the Keepalive time is too long, BGP cannot
fast detect link status changes, which slows down BGP network convergence and may
cause packet loss.
NOTICE
Changing timer values using the timer command or the peer timer command interrupts BGP
peer relationships between routers. Therefore, exercise caution before running either of the
command.
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.
Procedure
l Configure BGP timers for all peers or peer groups.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
timer keepalive keepalive-time hold hold-time [ min-holdtime min-hold-
value ]
BGP timers are configured.

The proper maximum interval at which Keepalive messages are sent is one third the
holdtime and is not less than one second. Therefore, set the holdtime to 3s at least.
NOTE
Setting the Keepalive time to 20s is recommended. If the Keepalive time is smaller than 20s,
sessions between peers may be closed.
When setting values of keepalive-time and hold-time, note the following points:
n The keepalive-time and hold-time values cannot be both set to 0. Otherwise,
the BGP timers become invalid, and BGP will not send Keepalive messages to
detect connection status.
n The hold-time value cannot be much greater than the keepalive-time value. For
example, keepalive-time cannot be set to 1 while hold-time is set to 65535. If
the hold-time value is too large, BGP cannot detect connection status in time.
After a connection is established between peers, the peers negotiate the keepalive-
time and hold-time values. The smaller one of the hold-time values carried by Open
messages of both peers is used as the hold-time value. The smaller value of one
third of the negotiated hold-time value and the locally configured keepalive-time
value is used as the keepalive-time value.
d. Run:
commit

l Configure timers for a specific peer or peer group.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { ipv4-address | group-name } timer keepalive keepalive-time hold
hold-time [ min-holdtime min-hold-value ]
The Keepalive and Hold timer values are set for a specific peer or peer group.
For details about the relationship between the keepalive-time and hold-time values,
see Configure BGP timers for all peers or peer groups.
NOTE
Setting the Keepalive time to 20s at least is recommended. If the Keepalive time is less than
20s, sessions between peers may be interrupted.
d. Run:
commit

----End

10.15.2 Configuring a MinRouteAdvertisementIntervalTimer

A proper MinRouteAdvertisementIntervalTimer can be configured to suppress frequent route
changes, improving BGP network stability.
Context
BGP peers use update messages to exchange routing information. Update messages can be
used to advertise reachable routes with the same attributes or delete unreachable routes.
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 route changes
frequently, to prevent the router from sending Update messages upon every change, configure
a MinRouteAdvertisementIntervalTimer at which Update messages are sent.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
peer { ipv4-address | group-name } route-update-interval interval
A MinRouteAdvertisementIntervalTimer is configured.
ipv4-address specifies the address of a specific peer. while group-name specifies the name of
a peer group. The MinRouteAdvertisementIntervalTimer configured for a peer takes
precedence over that configured for a peer group.
Step 4 Run:
commit
----End
10.15.3 Disabling Fast Reset of EBGP Connections

Disabling rapid EBGP connection reset can prevent frequent reestablishment and deletion of
EBGP sessions if route flapping occurs, which speeds up BGP network convergence.
Context
With rapid EBGP connection reset, BGP can 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, which speeds up BGP network convergence. Rapid EBGP connection reset is enabled
by default.

NOTE
Rapid EBGP connection reset enables BGP to quickly respond to interface faults, but not interface
recovery. After the interface recovers, BGP uses its state machine to restore relevant sessions.
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. To
address this issue, disable rapid EBGP connection reset so that BGP will not delete direct
EBGP sessions on the interface until the hold timer expires. Therefore, disabling rapid EBGP
connection reset suppresses BGP network flapping, speed up BGP network convergence, and
reduce network bandwidth consumption.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
undo ebgp-interface-sensitive
Rapid EBGP connection reset is disabled.
NOTE
Disable rapid EBGP connection reset only when 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.
Step 4 Run:
commit
----End
10.15.4 Configuring a BGP ConnectRetry Timer

You can control the speed at which BGP peer relationships are established by changing the
BGP ConnectRetry timer value.
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 re-establishes the TCP connection after the ConnectRetry timer expires.
l Setting a short ConnectRetry interval reduces the period BGP waits between attempts to
establish a TCP connection, which speeds up the establishment of the TCP connection.
l 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
l Configure a BGP ConnectRetry timer for all peers or peer groups.
Perform the following steps on a BGP router:
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
timer connect-retry connect-retry-time
A BGP ConnectRetry timer is configured for all peers or peer groups.

d. Run:
commit

l Configure a BGP ConnectRetry timer for a peer or peer group.
Perform the following steps on a BGP router:
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { group-name | ipv4-address } timer connect-retry connect-retry-time
A BGP ConnectRetry timer is configured for a peer or peer group.

d. Run:
commit
----End
10.15.5 Enabling Slow Peer Detection

After slow peer detection is configured on a device, the device identifies the slow BGP peer
(if any) and removes it from the update peer-group to prevent this slow peer from affecting
route advertisement to other peers in this update peer-group. Slow peer detection speeds up
BGP network convergence.

Context
An update peer-group may consist of multiple BGP peers. If a network problem (congestion
for example) occurs and slows down the speed at which the local device advertises routes to a
BGP peer in the update peer-group, the speed at which the local device advertises routes to
other BGP peers in the update peer-group is affected. To address this problem, enable slow
peer detection.
After slow peer detection is enabled, the local device calculates the difference between the
time taken to send packets to each BGP peer and the shortest time taken to send packets to a
BGP peer in the group. If the difference between the time taken to send packets to BGP peer 1
and the shortest time is greater than the threshold, the local device considers BGP peer 1 as a
slow peer and removes it from the update peer-group, which prevents this slow peer from
affecting route advertisement to other peers in the group.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 (Optional) Enter a desired address family view using one of the following commands.
l ipv4-family { unicast | vpnv4-multicast | multicast | vpnv4 [ unicast ] | vpn-instance
vpn-instance-name | mvpn | mdt }
l ipv6-family [ [ vpnv6 ] [ unicast ] | vpn-instance vpn-instance-name ]
l l2vpn-ad-family
l l2vpn-family evpn
l link-state-family unicast
Step 4 Run:
slow-peer detection threshold threshold-value
Slow peer detection is enabled.

threshold threshold-value specifies a slow peer detection threshold. If the difference between
the time taken to send packets to BGP peer 1 and the shortest time taken to send packets to
BGP peer 2 is greater than the threshold-value, the local device considers BGP peer 1 as a
slow peer and removes it from the update peer-group.
Step 5 Run:
commit
----End

After the BGP network convergence speed is adjusted, you can view information about BGP
peers and peer groups.

Prerequisites
Adjusting the BGP network convergence speed has been configured.
Procedure
l Run the display bgp peer [ verbose ] command to check information about BGP peers.
peer groups.
l Run the display bgp slow-peer command to check information about slow BGP peers.
----End
10.16 Configuring BGP Route Dampening

BGP route dampening can be configured to suppress unstable routes.
Usage Scenario
The main cause of route instability is route flapping. A route is considered to be flapping
when it repeatedly appears and then disappears in the routing table. BGP is generally applied
to complex networks where routes change frequently. Frequent route flapping consumes lots
of bandwidth and CPU resources and even seriously affects network operations.
BGP route dampening prevents frequent route flapping by using a penalty value to measure
route stability. When a route flaps for the first time, a penalty value is assigned to the route.
Later, each time the route flaps, the penalty value of the route increases by a specific value.
The greater the penalty value, the less stable the route. If the penalty value of a route exceeds
the pre-defined threshold, the route will not be advertised until the penalty value of the route
reduces to the reuse threshold.
Route dampening applies only to EBGP routes and VPNv4 IBGP routes. IBGP routes (except
VPNv4 IBGP routes) cannot be dampened because IBGP routing tables contain the routes
from the local AS, which require that the forwarding entries be the same on IBGP peers in the
AS. If IBGP routes are dampened, the forwarding entries may be inconsistent because
dampening parameters may vary among these IBGP peers.
Before configuring BGP route dampening, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

Step 4 Configuring BGP route dampening parameters
l Configuring EBGP route dampening parameters
a. Run the ipv4-family unicast command to display the IPv4 unicast address family
view.
b. Run the dampening [ half-life-reach reuse suppress ceiling | route-policy route-
policy-name ] * [ update-standard ] command to set the EBGP route dampening
parameters.
l Configuring IBGP route dampening parameters
a. Run the ipv4-family vpnv4 command to display the BGP-VPNv4 address family
view.
b. Run the dampening ibgp [ half-life-reach reuse suppress ceiling | route-policy
route-policy-name ] * [ update-standard ] command to set the IBGP route
dampening parameters.
When you configure BGP route dampening, the values of reuse, suppress, and ceiling should
meet the relationship of reuse<suppress<ceiling.
If routes are differentiated based on policies and the dampening command is run to reference
a route-policy, BGP can use different route dampening parameters to suppress different
routes.
Step 5 Run:
commit
----End

After BGP route dampening is configured, you can check whether the configuration is correct.
l Run the display bgp routing-table flap-info [ regular-expression as-regular-
expression | as-path-filter { as-path-filter-number | as-path-filter-name } | network-
address [ { mask | mask-length } [ longer-match ] ] ] command to check route flapping
statistics.
l Run the display bgp routing-table time-range start-time end-time command to view
BGP routes that flap within the specified time period.
l Run the display bgp routing-table dampened command to check dampened BGP
routes.
l Run the display bgp routing-table dampening parameter command to check
configured BGP route dampening parameters.
# Run the display bgp routing-table flap-info command to view BGP route flapping
statistics. For example:
<HUAWEI> display bgp routing-table flap-info


h - history, i - internal, s - suppressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

Network From Flaps Duration Reuse Path/Ogn
d 129.1.1.0 20.20.200.200 5 00:00:36 00:40:47 600i

*> 129.1.1.0 20.20.200.202 1 00:04:07 100?
d 129.1.2.0 20.20.200.200 5 00:00:36 00:40:47 600i
*> 129.1.2.0 20.20.200.202 1 00:04:07 100?
d 129.1.3.0 20.20.200.200 5 00:00:36 00:40:47 600i
d 129.1.4.0 20.20.200.200 5 00:00:36 00:40:47 600i
d 129.1.5.0 20.20.200.200 5 00:00:36 00:40:47 600i
# Run the display bgp routing-table dampened command to view dampened BGP routes.
For example:
<HUAWEI> display bgp routing-table dampened


Network From Reuse Path/Origin
d 8.6.244.0/23 223.1.41.247 01:06:25 65534 4837 174 11096 6356i
d 9.17.79.0/24 223.1.41.247 01:06:25 65534 837 3356 23504 29777i
d 9.17.110.0/24 223.1.41.247 01:06:25 65534 837 3356 23504 29777i
d 61.57.144.0/20 223.1.41.247 01:06:25 65534 4837 10026 9924
18429,18429i
d 63.76.216.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
d 63.78.142.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
d 63.115.136.0/23 223.1.41.247 01:06:25 65534 4837 701 26956i
d 65.243.170.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
# Run the display bgp routing-table dampening parameter command to view configured
BGP route dampening parameters. For example:
<HUAWEI> display bgp routing-table dampening parameter
Maximum Suppress Time(in second) : 3973

Ceiling Value : 16000
Reuse Value : 750
HalfLife Time(in second) : 900
Suppress-Limit : 2000
10.17 Configuring a BGP Device to Send a Default Route

to Its Peer
After a BGP device is configured to send a default route to its peer, the BGP device sends a
default route with the local address as the next hop address to the specified peer, regardless of
whether there are default routes in the local routing table, which reduces the number of routes
on the network.
Usage Scenario
The BGP routing table of a device on a medium or large BGP network contains a large
number of routing entries. Storing the routing table consumes a large number of memory
resources, and transmitting and processing routing information consume lots of network
resources. If a device needs to send multiple routes to its peer, you can configure the device 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 greatly reduces the number
of routes on the network and the consumption of memory resources on the peer and network
resources.
Figure 10-8 Configuring a BGP device to send a default route to its peer
20.1.1.0/24
DeviceA
192.168.2.2/24
20.2.1.0/24
192.168.2.1/24
DeviceB
20.3.1.0/24
On the network shown in Figure 10-8, Device A and Device B have established a BGP peer
relationship. Device B has added routes to 20.1.1.0/24, 20.2.1.0/24, and 20.3.1.0/24 to its
BGP routing table. Device A needs to learn these routes from Device B. To reduce the
memory consumption on Device A and bandwidth used by Device B for sending routing
information to Device A, configure Device B to send a default route to its peer (Device A)
and use a routing policy to prevent Device B from sending all the routes to 20.1.1.0/24,
20.2.1.0/24, and 20.3.1.0/24 to Device A. Then, Device A stores only one default route but
can still send traffic to the three network segments.
Before configuring a BGP device to send a default route to its peer, configure basic BGP
functions.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

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

The device is configured to send a default route to the specified peer or a peer group.
If route-policy route-policy-name or route-filter route-filter-name is set, the BGP device
changes attributes of the default route based on the specified route policy.
If conditional-route-match-all { ipv4-address1 { mask1 | mask-length1 } } &<1-4> is set,
the BGP device sends the default route to the peer only when routes that match all the all
specified conditions exist in the local routing table.
If conditional-route-match-any { ipv4-address2 { mask2 | mask-length2 } } &<1-4> is set,
the local device sends a default route to the peer when routes that match any of the specified
conditions exist in the local routing table.
NOTE
After the peer default-route-advertise command is used on a device, the device sends a default route
with the local address as the next-hop address to a specified peer, regardless of whether there is a default
route in the routing table.
Step 5 Run:
commit
----End

After configuring a BGP device to send a default route to a peer, check whether the
configuration is correct.
l Run the display bgp routing-table [ ipv4-address [ mask | mask-length ] ] command on
a peer to check information about the received BGP default route.
# Run the display bgp routing-table command on a peer to view information about the
received BGP default route.


*>i 0.0.0.0 10.1.1.2 0 0 i

*> 1.1.1.1/32 10.3.1.1 0 0 20?
*>i 4.0.0.0 10.2.1.2 100 0 100?
*>i 10.0.0.0 10.2.1.2 100 0 100?
*>i 10.2.1.0/24 10.1.1.2 0 100 0 i
*> 10.3.1.0/24 0.0.0.0 0 0 i
10.3.1.1 0 0 20?
*>i 192.168.0.0/16 10.2.1.2 100 0 100?
*>i 192.168.15.0 10.2.1.2 100 0 100?

10.18 Configuring a Device to Advertise BGP Supernet

Unicast Routes to BGP Peers
This section describes how to configure a Border Gateway Protocol (BGP) device to advertise
BGP supernet unicast routes to BGP peers.
Applicable Environment
A BGP supernet route has the same destination address and next hop address or has a more
detailed destination address than the next hop address. Any route that meets one of the
following conditions is a BGP supernet route.
l If you perform bitwise AND operations on the destination address mask with the
destination address and next hop address, respectively, the calculated network addresses
are the same, and the destination address mask is greater than or equal to the next hop
address mask.
l If you perform bitwise AND operations on the destination address mask with the
destination address and next hop address, respectively, the calculated network addresses
are different. However, if you perform bitwise AND operations on the next hop address
mask with the destination address and next hop address, respectively, the calculated
network addresses are the same.
By default, when a BGP device receives a BGP supernet unicast route, the BGP device sets
the route invalid and does not advertise it to other BGP peers. If a Huawei device is connected
to a non-Huawei device and you want the Huawei device to advertise BGP supernet unicast
routes that it receives from the non-Huawei device to other BGP peers, configure the Huawei
device to advertise BGP supernet unicast routes to BGP peers.
Before you configure a BGP device to send BGP supernet unicast routes to BGP peers,
configure basic BGP functions.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ipv4-family unicast

Step 4 Run:
supernet unicast advertise enable
The BGP device is enabled to advertise BGP supernet unicast routes to BGP peers.

Step 5 Run:
commit
----End

After you configure a BGP device to advertise BGP supernet unicast routes, check whether
the configuration takes effect.
l Run the display bgp routing-table command to check BGP supernet unicast routes.
l Run the display bgp routing-table network command to check information about a
specified BGP supernet unicast route advertised to BGP peers.
# Run the display bgp routing-table command to view received BGP supernet unicast
routes.
Status codes: * - valid, > - best, d - damped,

*>i 1.1.1.1/32 1.1.1.1 0 100 0 ?
# Run the display bgp routing-table network command to view information about a specified
BGP supernet unicast route advertised to BGP peers.
<HUAWEI> display bgp routing-table peer 1.1.1.1

From: 1.1.1.1 (11.1.1.1)
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, pre 20, IGP cost 10
15.1.1.1
10.19 Configuring BGP Load Balancing

BGP load balancing improves network resource usage and reduces network congestion.
Usage Scenario
On large networks, there may be multiple valid routes to the same destination. BGP, however,
advertises only the optimal route to its peers, which may result in load imbalance.
Either of the following methods can be used to address the problem:

l Use BGP routing policies to allow traffic to be balanced. For example, use a routing
policy to modify the Local_Pref, AS_Path, Origin, or MED attribute of BGP routes to
control traffic forwarding and implement load balancing.
l Use equal-cost routes to balance traffic by configuring the maximum number of routes
for load balancing. Load balancing can be implemented globally or based on a specified
peer or peer group.
NOTE
l Traffic can be balanced among BGP routes only when the first eight attributes described in "Route
Selection" in BGP Route Processing and the AS_Path of the routes are the same.
l You can change load balancing rules through configurations. For example, you can prevent the
device from comparing AS_Path attributes or IGP costs. When performing these configurations,
ensure that no routing loops will occur.
l Local cross routes and routes imported between public network and VPN instances do not support
load balancing.
The next section describes how to configure load balancing globally or based on a specified
peer or peer group.
Pre-configuration tasks
Before configuring BGP load balancing, configure basic BGP functions.
Procedure
l Configure BGP peer or peer group-based load balancing.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
ipv4-family unicast

NOTE
The BGP-IPv4 unicast address family view is used as an example, and you can also
configure load balancing in the BGP view, BGP-IPv4 unicast address family view, BGP-
IPv6 unicast address family view, BGP-VPN instance IPv4 address family view, or BGP-
VPN instance IPv6 address family view.
d. Run:
peer { ipv4-address | ipv6–address | group-name } load-balancing [ as-
path-ignore | as-path-relax ]
BGP peer or peer group-based load balancing is configured.

After the peer load-balancing command is run, BGP peer-based load balancing is
implemented only when the following conditions are met:
n The routes are received from the specified peer or peer group.
n The optimal route and optimal equal-cost routes exist.
n The AS_Path attribute is the same as that of the optimal route, or as-path-
ignore or as-path-relax is specified in the peer load-balancing command.

○ If as-path-ignore is specified, the device ignores comparing AS_Path

attributes when selecting routes for load balancing. In this case, routes
can participate in load balancing even if their AS_Path attributes are
different.
○ If as-path-relax is specified, the device ignores comparing the AS_Path
attributes of the same length when selecting routes for load balancing. In
this case, routes cannot participate in load balancing if their AS_Path
attributes are of different lengths. For example, the AS_Path attribute of
route A is 10, and the AS_Path attribute of route B is 10, 20. Because the
two AS_Path attributes are of different lengths, the two routes cannot
participate in load balancing.
e. (Optional) Change load balancing rules.
n Run the load-balancing as-path-ignore command to prevent the device from
comparing AS_Path attributes when selecting routes for load balancing.
n Run the load-balancing as-path-relax command to configure the device to
ignore comparing the AS_Path attributes of the same length when selecting
routes for load balancing.
n Run the load-balancing igp-metric-ignore command to prevent the device
from comparing IGP costs when selecting routes for load balancing.
NOTE
The address family views supported by the preceding commands are different. When
running any of the commands, ensure that the command is run in the correct address family
view.
Change load balancing rules based on network requirements and exercise caution when
running the commands.
f. Run:
commit

l Configure global BGP load balancing.
– Set the maximum number of BGP routes for load balancing.
i. Run:
system-view

ii. Run:
bgp as-number

iii. Run:
ipv4-family unicast
The IPv4-unicast address family view is displayed.

iv. Run:
maximum load-balancing [ ebgp | ibgp ] number [ ecmp-nexthop-
changed ]
The maximum number of BGP equal-cost routes for load balancing is set.
○ ebgp indicates that load balancing is implemented only among EBGP
routes.
○ ibgp indicates that load balancing is implemented only among IBGP
routes.

○ If neither ebgp nor ibgp is specified, both EBGP and IBGP routes can
balance traffic, and the number of EBGP routes for load balancing is the
same as the number of IBGP routes for load balancing.
NOTE
By default, traffic cannot be balanced among IBGP and EBGP routes on the public
network. If multiple routes with the same destination address exist on the public
network, the system selects the optimal route first. If the optimal route is an IBGP
route, only IBGP routes carry out load balancing. If the optimal route is an EBGP
route, only EBGP routes carry out load balancing.
The BGP-IPv4 unicast address family view is used as an example, and you can also
configure load balancing in the BGP view, BGP-IPv6 unicast address family view,
BGP-VPN instance IPv4 address family view, or BGP-VPN instance IPv6 address
family view.
v. (Optional) Change load balancing rules.
○ Run the load-balancing as-path-ignore command to prevent the device
from comparing AS_Path attributes when selecting routes for load
balancing.
○ Run the load-balancing as-path-relax command to configure the device
to ignore comparing the AS_Path attributes of the same length when
selecting routes for load balancing.
○ Run the load-balancing igp-metric-ignore command to prevent the
device from comparing IGP costs when selecting routes for load
balancing.
NOTE
running any of the commands, ensure that the command is run in the correct address
family view.
Change load balancing rules based on network requirements and exercise caution
when running the commands.
vi. Run:
commit

– Set the maximum number of EBGP and IBGP routes for load balancing.
This configuration is used in a VPN where a CE is dual-homed to two PEs. When
the CE resides in the same AS as only one of the PEs, you can set the maximum
number of EBGP and IBGP routes for load balancing so that VPN traffic can be
balanced among EBGP and IBGP routes.
i. Run:
system-view

ii. Run:
bgp as-number

iii. Run:
ipv4-family vpn-instance vpn-instance-name
The BGP VPN instance address family view is displayed.

iv. Run:
maximum load-balancing eibgp number [ ecmp-nexthop-changed ]

The maximum number of EBGP and IBGP routes for load balancing is set.
After the maximum load-balancing eibgp number command is run on a
device, the device, by default, changes the next hop of each route to itself
before advertising the route to a peer, regardless of whether the route is to be
used for load balancing. However, in RR or BGP confederation scenarios, the
device does not change the next hop addresses of non-local routes to be
advertised to a local address. As a result, besides the routes for load-balancing,
those routes that are not supposed to participate in load balancing deliver
traffic to the device, which overburdens the device. To address this problem,
you can set ecmp-nexthop-changed so that the device changes the next hop of
only routes that are to be used for load balancing to itself before advertising
them to peers.
v. (Optional) Change load balancing rules.
○ Run the load-balancing as-path-ignore command to prevent the device
from comparing AS_Path attributes when selecting routes for load
balancing.
○ Run the load-balancing as-path-relax command to configure the device
to ignore comparing the AS_Path attributes of the same length when
selecting routes for load balancing.
○ Run the load-balancing eibgp command to enable load balancing among
EBGP and IBGP routes.
○ Run the load-balancing igp-metric-ignore command to prevent the
device from comparing IGP costs when selecting routes for load
balancing.
NOTE
running any of the commands, ensure that the command is run in the correct address
family view.
Change load balancing rules based on network requirements and exercise caution
when running the commands.
vi. Run:
commit

----End

After configuring BGP load balancing, check the configurations.
l Run the display ip routing-table [ verbose ] command to check information about the
IP routing table.
# Run the display bgp routing-table command. The command output shows that more than
one BGP route is selected to balance traffic.
<HUAWEI>display bgp routing-table 10.1.1.0 24


Paths : 2 available, 1 best, 2 select

From: 10.2.1.2 (2.2.2.2)
AS-path 200 300, origin igp, pref-val 0, valid, external, best, select, pre 255
Advertised to such 2 peers
10.2.1.2
10.2.2.2

From: 10.2.2.2 (3.3.3.3)
AS-path 200 300, origin igp, pref-val 0, valid, external, select, pre 255, not
preferred for router ID
Not advertised to any peers yet
10.20 Configuring Path MTU Auto Discovery

Path MTU auto discovery allows BGP to discover the smallest MTU value on a path so that
BGP messages are transmitted based on the path MTU. This function improves transmission
efficiency and BGP performance.
Usage Scenario
The link-layer MTUs of different networks through which a path traverses may vary from
each other. The smallest MTU on the path is called the path MTU.
Path MTUs vary with the path, and the path MTUs may be different in opposite directions.
With path MTU auto discovery, BGP can discover the Path MTU from the source to the
destination. The path MTU will be encapsulated into TCP IP data during BGP message
transmission.
In Figure 10-9, a BGP peer relationship is set up between Device A and Device D. BGP
messages are encapsulated into TCP data packets for transmission. Therefore, Device A sends
TCP data packets to Device D based on the default maximum segment size (MSS). As a
result, a lot of BGP messages are fragmented into different packets, and the number of ACK
messages corresponding to these messages increases, leading to a low transmission efficiency.
To resolve this issue, configure Path MTU auto discovery. In Figure 10-9, the path MTU
between Device A and Device D is 1496. With path MTU auto discovery, BGP messages are
transmitted based on the path MTU (1496), which speeds up BGP message transmission and
improves BGP performance.
Figure 10-9 Networking with path MTU auto discovery

MTU=1500 MTU=1496 MTU=1500
DeviceA DeviceB DeviceC DeviceD

Before configuring path MTU auto discovery, configure basic BGP functions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
peer { group-name | ipv4-address } path-mtu auto-discovery
Path MTU auto discovery is enabled.
After the command is run, a BGP peer learns the path MTU, preventing BGP messages from
being fragmented during transmission.
NOTE
A BGP message from one end to the other may travel a path different from the path used by the ACK
message that is responded by the other end. Therefore, running this command on both ends is
recommended so that both peers exchange messages based on the path MTU.
Step 4 Run:
quit
Return to the system view.
Step 5 Run:
tcp timer pathmtu-age age-time
The aging time is set for an IPv4 path MTU.
The path MTUs vary with the path. If there are multiple routes between two communication
hosts and the routes selected for packet transmission change frequently, configure the path
MTU aging time so that the system updates path MTUs based on the path MTU aging time,
increasing the transmission efficiency.
Step 6 Run:
commit
----End

After configuring path MTU auto discovery, run the following commands to check the
previous configuration.
l Run the display bgp peer [ ipv4-address ] verbose command to check whether path
MTU auto discovery has been successfully configured.

# After configuring path MTU auto discovery, view detailed information about the BGP peer
at 10.1.1.2.
<HUAWEI> display bgp peer 10.1.1.2 verbose
BGP Peer is 10.1.1.2, remote AS 65009

Type: IBGP link
BGP version 4, Remote router ID 4.4.4.4
Update-group ID: 1
BGP current state: Established, Up for 1d00h25m21s
BGP current event: KATimerExpired
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 0
Received active routes total: 0
Advertised total routes: 0
Port: Local - 179 Remote - 50450
Configured: Connect-retry Time: 32 sec
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 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 1467 messages
Update messages 0
Open messages 1
KeepAlive messages 1466
Notification messages 0
Refresh messages 0
Sent: Total 1468 messages
Update messages 0
Open messages 2
Refresh messages 0
Authentication type configured: None
Last keepalive received: 2011/04/19 17:13:09 UTC-11728:00
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Routing policy configured:
Path MTU discovery has been configured
NOTE
The message of Path MTU discovery has been configured will be displayed only after the display
bgp peer ipv4-address verbose command is run on the router where path MTU auto discovery has been
enabled.
10.21 Configuring BGP Next Hop Iteration Based on a

Route-Policy
Configuring BGP next hop iteration based on a route-policy prevents traffic loss if routes
changes.
Usage Scenario
When BGP routes change, BGP needs to perform route iteration on the BGP routes with
indirect next hops. If no route-policies are configured to filter the routes on which a BGP

route with an indirect next hop depends for iteration, the BGP route may be iterated to an
incorrect route, which may cause traffic loss. To address this problem, configure BGP next
hop iteration based on a route-policy. If no routes match the route-policy, the BGP route with
an indirect next hop is considered unreachable. In this situation, incorrect route iteration and
traffic loss are prevented.
Before configuring BGP next hop iteration based on a route-policy, complete the following
tasks:

NOTICE
Before configuring a route-policy, ensure that the routes on which BGP routes with indirect
next hops depend for iteration will not be filtered out by the route-policy. Otherwise, route
iteration fails, and traffic cannot be forwarded.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
nexthop recursive-lookup { route-policy route-policy-name | route-filter route-
filter-name }
BGP next hop iteration based on a route-policy or route-filter is configured.
NOTE
The command does not apply to the routes received from directly connected EBGP peers or LinkLocal
peers.
Step 4 Run:
commit
----End

Run the following commands to check the previous configuration.

l Run the display bgp routing-table network [ mask | mask-length ] command to check
detailed information about a specified route in the BGP routing table.
# Run the display bgp routing-table network [ mask | mask-length ] command to view
detailed information about a specified route in the BGP routing table. The command output
shows that the next hop of the route that is filtered out by the route-policy has been set to
0.0.0.0 and that the outbound interface has been set to null.
<HUAWEI> display bgp routing-table 4.4.4.4 32

From: 3.3.3.3 (3.3.3.3)
AS-path 200, origin igp, MED 1, pref-val 0, valid, external, best, select, pre
255
3.3.3.3
2.2.2.2

From: 2.2.2.2 (2.2.2.2)
Relay IP Out-interface:
AS-path 200, origin igp, MED 1, pref-val 0, external, pre 255
10.22 Configuring AIGP value on a Route-Policy

The Accumulated Interior Gateway Protocol Metric (AIGP) attribute is an optional non-
transitive Border Gateway Protocol (BGP) path attribute. After the AIGP attribute is
configured in an AIGP administrative domain, BGP selects paths based on costs in the same
manner as an IGP, and all devices in the domain forward data along the optimal routes.
During BGP route selection, the AIGP attribute is used as follows:
l The priority of a route that carries the AIGP attribute is higher than the priority of a route
that does not carry the AIGP attribute.
l If two BGP routes both carry the AIGP attribute, the device selects the BGP route whose
AIGP value plus the cost of the IGP route to which the BGP route is iterated is smaller.
The AIGP attribute can be added to routes only through route-policies. You can configure an
apply clause for a route-policy using the apply aigp { cost | inherit-cost } command to
modify the AIGP value during BGP route import, acceptance, or advertisement. If no AIGP
value is configured, the IGP routes imported by BGP do not carry the AIGP attribute.
In Figure 10-10, OSPF runs in AS 65002, an EBGP peer relationship is established between
Device A and Device E and between Device B and Device E. Device A and Device B are
configured to import OSPF routes in AS 65002 and advertise the routes to AS 65001.

Figure 10-10 AIGP application networking
AS 65001
Router E
10.1.1.1/30 10.1.3.1/30
EBGP EBGP
10.1.1.2/30 10.1.3.2/30
Router A Router B
10.1.2.1/30 10.1.5.1/30
AS 65002
10.1.2.2/30 10.1.5.2/30
10.1.4.1/30
Router C 10.1.4.2/30 Router D
Run the display bgp routing-table [ ip-address ] command on Device E to check the
configurations. The route 10.1.4.0/30 is used in this example.
# Display the routing table of Device E.

[DeviceE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.1.2 2 0 65002?
* 10.1.3.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[DeviceE] display bgp routing-table 10.1.4.0



From: 10.1.1.2 (10.1.1.2)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, best,
select, active, pre 255
10.1.1.2
10.1.3.2
From: 10.1.3.2 (10.1.5.1)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, pre 255,
not preferred for router ID
The command output shows that Device E selects the route learned from Device A because
the AIGP attribute has not been configured and the router ID of Device A is smaller than that
of Device B. To change the route selection on Device E, perform the following operations to
configure the AIGP attribute.
Configurations on Device A:
#
bgp 65002
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy //Apply route-policy
named aigp_policy to locally imported OSPF routes and use aigp_policy to modify
the AIGP value.
peer 10.1.1.1 aigp //Enable AIGP on the
local device and the peer 10.1.1.1.
#
route-policy aigp_policy permit node 10 //Define the first node
of aigp_policy and set the AIGP value of the route 10.1.4.0/30 to 10.
if-match ip-prefix prefix1
apply aigp 10
#
route-policy aigp_policy permit node 20 //Define the second node
of aigp_policy and allow aigp_policy to permit all routes.
#
ip ip-prefix prefix1 index 10 permit 10.1.4.0 30 //Configure IP prefix
list named prefix1 to match the route 10.1.4.0/30.
#
Configurations on Device B:
bgp 65002
peer 10.1.3.1 as-number 65001
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy1 //Apply route-policy
named aigp_policy1 to locally imported OSPF routes and use aigp_policy1 to modify
the AIGP value.
#
route-policy aigp_policy1 permit node 10 //Define the first node
of aigp_policy1 and set the AIGP value of the route 10.1.4.0/30 to 5.
apply aigp 5
#
route-policy aigp_policy1 permit node 20 //Define the second node
of aigp_policy1 and allow aigp_policy1 to permit all routes.

#
#
Configurations on Device E:
#
bgp 65001
#
ipv4-family unicast
#
configurations.

[DeviceE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.3.2 2 0 65002?
* 10.1.1.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[DeviceE] display bgp routing-table 10.1.4.0

From: 10.1.3.2 (10.1.5.1)
select, active, pre 255, AIGP 5
10.1.1.2
10.1.3.2
From: 10.1.1.2 (10.1.1.2)
AIGP 10, not preferred for AIGP
The preceding command output shows that Device E selects the route 10.1.4.0/30 learned
from Device B because its AIGP value is smaller than that of the route learned from Device
A.

Table 10-3 shows the attribute comparison of the routes 10.1.4.0/30 learned from Device A
and Device B.
Table 10-3 Attribute comparison of the routes 10.1.4.0/30 learned from Device A and Device
B.
Route Attribute Route Learned Route Learned Comparison
from Device A from Device B
PrefVal 0 0 The same.
Local_Pref - - The same.
Route type Learned from a peer Learned from a peer The same.
AIGP 10 5 The different.
10.23 Configuring the POPGO Function

After the POPGO function is configured on the egress of a BGP LSP, the egress forwards
each data packet received from the LSP through the outbound interface found in the ILM
based on the label information carried in the packet.
Usage Scenario
On the network shown in Figure 10-11, DeviceC has two static routes, 20.1.1.0/24 and
20.1.1.0/30, and the next hops of the two routes are DeviceA and DeviceB respectively.
DeviceC only imports route 20.1.1.0/24 to BGP and then sends this route to DeviceD. A BGP
LSP is established between DeviceC and DeviceD. By default, after DeviceC receives a data
packet addressed to 20.1.1.0 from DeviceD, DeviceC removes the LSP label from the packet,
searches for an outbound interface in the IP forwarding table according to the longest-match
principle, and incorrectly sends the packet to DeviceB.
To solve the preceding problem, configure the apply-label per-route pop-go command on
DeviceC. After the apply-label per-route pop-go command is configured, when DeviceC
sends route 20.1.1.0/24 to DeviceD, DeviceC records in the ILM the mapping between the
label assigned to the route and the outbound interface of the route. Then, after the DeviceC
receives a data packet from DeviceD, DeviceC directly searches the ILM for an outbound
interface based on label information carried in the packet and forwards the packet through the
found outbound interface after removing the packet label. This implementation ensures
correct packet forwarding.
Figure 10-11 POPGO networking

20.1.1.0/24
BGP LSP
Device A
20.1.1.0/30 Device C Device D
Device B

Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
apply-label per-route pop-go
The POPGO function is configured.

Step 4 Run:
commit
----End

After configuring the POPGO function, you can run the following command to check the
configuration.
Run the display mpls lsp protocol bgp command. The command output shows detailed BGP
LSP information. If POPGO is displayed in the Label Operation field, the POPGO function
is successfully configured.
<HUAWEI> display mpls lsp protocol bgp verbose
-------------------------------------------------------------------------------
LSP Information: BGP LSP
-------------------------------------------------------------------------------
No : 1
VrfIndex :
RD Value : 0:0
Fec : 1.1.1.1/32
Nexthop : 0.0.0.0
In-Label : 32828
Out-Label : NULL
In-Interface : ------
Out-Interface : ------
LspIndex : 17039360
Type : Primary
OutSegmentIndex : ------
LsrType : Egress
Outgoing TunnelID : 0x0
Label Operation : POPGO
Mpls-Mtu : ------
LspAge : ------
Exp-Mode : ---
10.24 Configuring BFD for BGP

BFD for BGP speeds up fault detection and therefore increases the route convergence speed.

Usage Scenario
Currently, voice and video services are widely applied. These services are quite sensitive to
the packet loss and delay.BGP periodically sends Keepalive packets to its peers to detect the
status of its peers. The detection mechanism, however, takes more than one second. When the
data transmission rate reaches the level of Gbit/s, such slow detection will cause a large
amount of data to be lost. As a result, the requirement for high reliability of carrier-class
networks cannot be met.
BFD for BGP can be used to reduce packet loss and delay. BFD for BGP detects faults on
links between BGP peers within milliseconds. The fast detection speed ensures fast BGP
route convergence and minimizes traffic loss.
Before configuring BFD for BGP, complete the following task:
l Configuring parameters of the link layer protocol and IP addresses for interfaces to
ensure that the link layer protocol on the interfaces is Up
Data Preparation
To configure BFD for BGP, you need the following data.
No. Data
1 IP address of the BGP peer or name of the peer group for which BFD needs to be
configured
2 BFD parameters, including the minimum and maximum intervals for receiving
BFD packets, Wait-to-Restore (WTR) time of a BFD session, and the detection
multiplier
3 Name of the VPN instance for which BFD needs to be configured
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is enabled globally.

Step 3 Run:
quit
Return to the system view.

Step 4 Run:
bgp as-number


ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.
NOTE
BFD for BGP can be configured for the VPN in this view. To configure BFD for BGP for the public
network, skip this step.
Step 6 Run:
peer { group-name | ipv4-address } bfd enable [ single-hop-prefer ]
BFD is enabled for the peer or peer group and a BFD session is established using default
parameters.
After BFD is enabled for a peer group, BFD sessions will be created on the peers that belong
to this peer group and are not configured with the peer bfd block command.

peer { group-name | ipv4-address } bfd { min-tx-interval min-tx-interval | min-rx-
interval min-rx-interval | detect-multiplier multiplier } *
BFD session parameters are modified.
NOTE
The BFD parameters of peers take precedence over those of peer groups. If BFD parameters are
configured on peers, they will be used in BFD session establishment.
When changing the default values, pay attention to the network status and the network
reliability requirement. A short interval for transmitting BFD packets can be configured for a
link that has a higher reliability requirement. A long interval for transmitting BFD packets can
be configured for a link that has a lower reliability requirement.
NOTE
There are three formulas: Actual interval for the local device to send BFD packets = max {Locally
configured interval for transmitting BFD packets, Remotely configured interval for receiving BFD
packets}, Actual interval for the local device to receive BFD packets = max {Remotely configured
interval for transmitting BFD packets, Locally configured interval for receiving BFD packets}, and
Local detection period = Actual interval for receiving BFD packets x Remotely configured BFD
detection multiplier.
For example:
l On the local device, the configured interval for transmitting BFD packets is 200 ms, the interval for
receiving BFD packets is 300 ms, and the detection multiplier is 4.
l On the peer device, the configured interval for transmitting BFD packets is 100 ms, the interval for
receiving BFD packets is 600 ms, and the detection multiplier is 5.
Then:
l On the local device, the actual interval for transmitting BFD packets is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval for receiving BFD packets is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying
300 ms by 5.
l On the peer device, the actual interval for transmitting BFD packets is 300 ms calculated by using
the formula max {100 ms, 300 ms}; the interval for receiving BFD packets is 600 ms calculated by
using the formula max {200 ms, 600 ms}; the detection period is 2400 ms calculated by multiplying
600 ms by 4.


peer ipv4-address bfd block
A peer is prevented from inheriting the BFD function of the peer group to which it belongs.
If a peer joins a peer group enabled with BFD, the peer inherits the BFD configuration of the
group and creates a BFD session. To prevent the peer from inheriting the BFD function of the
peer group, perform this step.
NOTE
The peer bfd block command and the peer bfd enable command are mutually exclusive. After the peer
bfd block command is run, the BFD session is automatically deleted.
Step 9 Run:
commit
----End

After configuring BFD for BGP, you can run the following command to check the
configurations.
l Run the display bgp bfd session { [ vpnv4 vpn-instance vpn-instance-name ] peer
ipv4-address | all } command to check information about the BFD session between BGP
peers.
# View information about the BFD session between BGP peers.

<HUAWEI> display bgp bfd session peer 10.1.1.2
Local_Address Peer_Address LD/RD Interface
10.1.1.1 10.1.1.2 8192/8192 GigabitEthernet1/0/2
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 3 Up
Wtr-interval(m)
0
10.25 Configuring BGP Auto FRR

BGP Auto FRR, a protection measure against link faults, applies to the network topology with
both primary and backup links. It can be configured for services that are quite sensitive to the
packet loss and delay.
Usage Scenario
As networks evolve continuously, voice, on-line video, and financial services raise
increasingly high requirements for real-time performance. Usually, primary and backup links
are deployed on a network to ensure the stability of these services. In a traditional forwarding
mode, the router selects a route out of several routes that are bound for the same destination
network as the optimal route and delivers the route to the FIB table to guide data forwarding.
If the optimal route fails, the router has to wait for route convergence to be completed before
reselecting an optimal route. During this period, services are interrupted. After the router
delivers the reselected optimal route to the FIB table, services are restored. Service
interruption in this mode lasts a long time, which cannot meet services' requirements.

After BGP Auto FRR is enabled on a router, the router selects the optimal route from the
routes that are bound for the same destination network. In addition, the router automatically
adds information about the second optimal route to the backup forwarding entries of the
optimal route. If the primary link fails, the router quickly switches traffic to the backup link.
The switchover does not depend on route convergence. Therefore, the service interruption
time is very short, reaching the sub-second level.
Before configuring BFD Auto FRR, complete the following task:

l Configuring BFD for BGP
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast
The BGP IPv4 unicast address family view is displayed.

Step 4 Run:
auto-frr
BGP Auto FRR for unicast routes is enabled.

route-select delay delay-value
A delay for selecting a route to the intermediate device on the primary path is configured.
After the primary path recovers, an appropriate delay ensures that traffic switches back to the
primary path after the intermediate device completes refreshing forwarding entries.
Step 6 Run:
commit
----End

After configuring BGP Auto FRR, you can run the following commands to check the
previous configuration.
l Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-

prefixes ] ] ] command to check information in a BGP routing table.

l Run the display ip routing-table [ ip-address [ mask | mask-length ] [ longer-match ] ]

verbose command to check backup forwarding entries in an IP routing table.
# Run the display bgp routing-table ip-address mask-length longer-prefixes command. The
command output shows that there are two next hops to reach 4.4.4.4/32. The route with the
next hop of 10.1.1.2 has a smaller MED value and therefore becomes the optimal route.
<HUAWEI> display bgp routing-table 4.4.4.4 32 longer-prefixes

*> 4.4.4.4/32 10.1.1.2 80 0 200i

* 4.4.4.4/32 10.2.1.2 120 0 200i
# Run the display ip routing-table ip-address mask-length verbose command. The command
output shows that there are two next hops to reach 4.4.4.4/32, and 10.2.1.2 is the backup next
hop.
<HUAWEI> display ip routing-table 4.4.4.4 32 verbose
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination: 4.4.4.4/32
Protocol: EBGP Process ID: 0
Preference: 255 Cost: 80
NextHop: 10.1.1.2 Neighbour: 10.1.1.2
State: Active Adv Age: 00h05m41s
Tag: 0 Priority: low
Label: NULL QoSInfo: 0x0
IndirectID: 0x2
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet1/0/0
TunnelID: 0x0 Flags: D
BkNextHop: 10.2.1.2 BkInterface: GigabitEthernet1/0/1
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x1
10.26 Configuring the BGP Next Hop iteration Delayed

Response
Configuring the BGP next hop iteration delayed response can minimize traffic loss during
route changes.
Usage Scenario
As shown in Figure 10-12, PE1, PE2, and PE3 are the clients of the RR. CE2 is dual-homed
to PE1 and PE2. PE1 and PE2 advertise their routes to CE2 to the RR. The RR advertises the
route from PE1 to PE3. PE3 has a route to CE2 only and advertises this route to CE1. After
the route exchange, CE1 and CE2 can communicate. If PE1 fails, PE3 detects that the next
hop is unreachable and instructs CE1 to delete the route to CE2. Traffic is interrupted. After
BGP route convergence is complete, the RR selects the route advertised by PE2 and sends a
route update message to PE3. PE3 then advertises this route to CE1, and traffic forwarding is

restored to the normal state. A high volume of traffic will be lost during traffic interruption
because BGP route convergence is rather slow.
If the BGP next hop iteration changes delayed response is enabled on PE3, PE3 does not
reselect a route or instruct CE1 to delete the route to CE2 immediately after detecting that the
route to PE1 is unreachable. After BGP convergence is complete, the RR selects the route
advertised by PE2 and sends the route to PE3. PE3 then reselects a route and sends a route
update message to CE1. Traffic forwarding is restored to the normal state. After the BGP next
hop iteration changes delayed response is enabled on PE3, PE3 does not need to delete the
route or instruct CE1 to delete the route. This delayed response speeds up BGP route
convergence and minimizes traffic loss.
Figure 10-12 Networking diagram for configuring the BGP next hop iteration changes
delayed response
CE1 PE3 P PE1
CE2
RR PE2
NOTE
The BGP next hop delayed response applies to a scenario where the next hop has multiple links to reach
the same destination. If there is only one link between the next hop and the destination, configuring the
BGP next hop delayed response may cause heavier traffic loss when the link fails because link switching
is impossible.
Before configuring the BGP next hop iteration changes delayed response, complete the
following task:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
nexthop recursive-lookup delay [ delay-time ]
A delay in responding to a next hop iteration change is set.
After the nexthop recursive-lookup delay command is run, the device delays responses to all
iteration changes. After the nexthop recursive-lookup non-critical-event delay command is
run, the device delays responses only to non-critical BGP iteration changes. If both
commands are run, the nexthop recursive-lookup non-critical-event delay command takes
precedence over the nexthop recursive-lookup delay command.
The delay time specified in the nexthop recursive-lookup non-critical-event delay

command must be greater than or equal to that specified in the nexthop recursive-lookup
delay command if both commands are run.
Step 4 Run:
commit
----End

After configuring the BGP next hop iteration changes delayed response, you can run the
following command to check the previous configuration.
l Run the display current-configuration configuration bgp | include nexthop

recursive-lookup delay command to view information about the delay in responding to
a next hop iteration change.
l Run the display current-configuration configuration bgp | include nexthop
recursive-lookup non-critical-event delay command to view information about the
delay in responding to non-urgent next hop iteration changes.
# Display the delay in responding to a next hop iteration change.

<HUAWEI> display current-configuration configuration bgp | include nexthop
recursive-lookup delay
nexthop recursive-lookup delay 20
# Display the delay in responding to non-urgent next hop iteration changes.

<HUAWEI> display current-configuration configuration bgp | include nexthop
recursive-lookup non-critical-event delay
nexthop recursive-lookup non-critical-event delay 25
10.27 Configuring the BGP GR Helper

You can configure a device to function as a Graceful Restart (GR) Helper to help a BGP peer
with the BGP GR process.
Usage Scenario
When BGP restarts, the peer relationship is re-established, and traffic forwarding is
interrupted. To address this issue, enable GR.

GR takes effect only when BGP GR is enabled and a GR-capable BGP session is established
between the GR restarter and its peers.
Before configuring the BGP GR helper, configure basic BGP functions.
Figure 10-13 Configuring the BGP GR helper
Enable BGP GR
Configure parameters
for a BGP GR session
Mandatory
procedure
Optional
procedure
10.27.1 Enabling BGP GR

Enabling or disabling GR may delete and reestablish all sessions and instances.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
graceful-restart
BGP GR is enabled.
graceful-restart peer-reset
The router is enabled to reset a BGP session in GR mode.

Currently, BGP does not support dynamic capability negotiation. As a result, each time the
BGP capability changes, the BGP peer relationship is re-established. In some scenarios where
a BGP IPv4 unicast peer relationship is established and IPv4 services are running, if the BGP
capability changes, the BGP IPv4 unicast peer relationship will be re-established. This
process will interrupt ongoing IPv4 services. To prevent the service interruptions, run the
graceful-restart peer-reset command to enable the router to reset a BGP session in GR
mode.

Step 5 Run:
commit
----End
10.27.2 Configuring the Parameter for a BGP GR Session

Changing the parameter of a BGP GR session may re-establish BGP peer relationships.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
graceful-restart timer wait-for-rib timer
The period during which the restarting speaker and receiving speaker wait for End-Of-RIB
messages is set.
Step 4 Run:
commit
----End

After configuring a BGP GR helper, check the BGP GR status.
Prerequisites
The BGP GR helper has been configured.
Procedure
l Run the display bgp peer verbose command to check the BGP GR status.
l Run the display bgp graceful-restart status command to check the GR information
about a BGP speaker.
----End
Example
Run the display bgp peer verbose command to view the BGP GR status.

BGP Peer is 2.2.2.2, remote AS 200,

Type: EBGP link
Group ID : 0
Peer Local Interface Name: GigabitEthernet1/0/0
Local Ifnet Tunnel: 0xb0010000
BGP current state: Established, Up for 20h21m17s
Graceful Restart Capability: advertised

Update messages 0
Open messages 5
Refresh messages 0

Update messages 0
Open messages 10
Refresh messages 0
Last keepalive received: 2009-03-30 09:14:14
Listen-only has been configured
Run the display bgp graceful-restart status command to view the GR information about a
BGP speaker.
<HUAWEI> display bgp graceful-restart status
-------------------- BGP SYSTEM GR STATUS -------------
GR is configured, TimerValues (RESTARTER: 150, EOR:600)
-------------------------------------------------------
IPv4-UNC (_public_)
Peers:
200.1.1.2
GR capability is not negotiated
Peer state: Active
GR state: false
-------------------------------------------------------
IPv4-VPN (_public_)
Peers:
2.2.2.2
GR capability is negotiated
Peer state: Established
GR state: false
-------------------------------------------------------
IPv4-MVPN (_public_)

Peers:
2.2.2.2
GR capability is negotiated
Peer state: Established
GR state: false
10.28 Configuring BGP Best-external

Border Gateway Protocol (BGP) Best-external can speed up route convergence if the primary
link fails.
Usage Scenario
If multiple routes to the same destination are available, a BGP device selects one optimal
route based on BGP route selection policies and advertises the route to its BGP peers. This
optimal route may be advertised by either an External Border Gateway Protocol (EBGP) peer
or an Internal Border Gateway Protocol (IBGP) peer.
However, in scenarios with master and backup provider edges (PEs) or route reflectors (RRs),
if routes are selected based on the preceding policies and the primary link fails, the BGP route
convergence takes a long time because no backup route is available. To address this problem,
configure BGP Best-external on the backup PE or RR.
The following figures show the networking with master and backup PEs or RRs.
Figure 10-14 Networking with master and backup PEs

PE1
Backbone
1.1.1.1/32 AS 100
CE1 PE3 CE2
PE2
Figure 10-15 Networking with master and backup RRs

RR1
DeviceB DeviceC
1.1.1.1/32 AS 100
DeviceA DeviceD
RR2
In the preceding networkings, BGP Best-external must be enabled on PE2 and RR2.

Before configuring BGP Best-external, configure basic BGP functions.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:
bestroute best-external
The device is enabled to select BGP Best-external routes.

4. Run:
peer { ipv4-address | group-name } advertise best-external
The device is enabled to advertise Best-external routes to the specified peer or peer
group.
5. Run:
commit

After route summarization is configured, you can check whether the configuration is correct.
l Run the display bgp peer verbose command to check whether the device has been
enabled to advertise BGP Best-external routes to a specified peer or peer group.
# Run the display bgp peer verbose command to view whether the device has been enabled
to advertise BGP Best-external routes to the specified peer or peer group. The command
output shows that the device has been enabled to advertise BGP Best-external routes to the
specified peer or peer group.
Type: IBGP link
Update-group ID: 2


Update messages 2
Open messages 1
Refresh messages 0
Update messages 3
Open messages 1
Refresh messages 0
Last keepalive received: 2013-03-17 12:28:05+00:00
Send community has been configured
Send best-external has been configured
TCP MSS configured value: 200
10.29 Configuring BGP ADD-PATH

BGP ADD-PATH allows a route reflector (RR) to send two or more routes with the same
prefix to a specified IBGP peer. These routes can back up each other or load-balance traffic,
which improves network reliability.
Usage Scenario
In a scenario with an RR and clients, if the RR has multiple routes to the same destination
(with the same prefix), the RR selects an optimal route from these routes and then sends only
the optimal route to its clients. Therefore, the clients have only one route to the destination. If
a link along this route fails, route convergence takes a long time, which cannot meet the
requirements for high reliability.
To address this issue, deploy the BGP ADD-PATH feature on the RR. With BGP ADD-PATH,
the RR can send two or more routes with the same prefix to a specified IBGP peer. These
routes can back up each other or load-balance traffic, which ensures high reliability in data
transmission. The BGP ADD-PATH feature does not affect BGP route selection rules.
NOTE
The RR can send ADD-PATH routes only to IBGP peers.

BGP ADD-PATH is not supported in BGP confederation scenarios.
Enable BGP ADD-PATH on the RR, enable the RR to send ADD-PATH routes to a specified
IBGP peer, configure the number of routes that the RR can send to the IBGP peer, and enable
the IBGP peer to receive BGP ADD-PATH routes from the RR so that such routes are
available to the IBGP peer. In Figure 10-16, you can enable BGP ADD-PATH on the RR,
enable Device A to receive BGP ADD-PATH routes from the RR so that Device A can
receive two routes destined for 1.1.1.1/32, with next hops of 9.1.2.1 and 9.1.1.1. The two
routes can back up each other or load-balance traffic.

Figure 10-16 Networking for configuring BGP ADD-PATH
AS 65008
9.1.2.1/24
DeviceC
1.1.1.1/32
DeviceA DeviceD
RR
AS 65009
9.1.1.1/24
DeviceB
Before configuring BGP ADD-PATH, configure basic BGP functions.
Procedure
l Perform the following steps on the RR:
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
bestroute add-path path-number path-number
BGP ADD-PATH is enabled, and the number of routes that the RR can select is
configured.
d. Run:
peer { ipv4-address1 | group-name1 } capability-advertise add-path send
The RR is enabled to send ADD-PATH routes to the specified IBGP peer (Device
A).
e. Run:
peer { ipv4-address1 | group-name1 } advertise add-path path-number path-
number
The number of routes that the RR can send to the IBGP peer is configured.
f. Run:
commit

l Perform the following steps on Device A:
a. Run:
system-view

b. Run:
bgp as-number


c. Run:
peer { ipv4-address2 | group-name2 } capability-advertise add-path
receive
Device A is enabled to receive ADD-PATH routes from the RR.

d. Run:
commit

----End

Run the following commands on the RR to check configurations:
l Run the display bgp peer verbose command to check information about BGP ADD-
PATH.
# Display information about BGP ADD-PATH on the RR using the display bgp peer verbose
command.
BGP Peer is 100.0.0.4, remote AS 1.1
Type: IBGP link
Update-group ID: 1
BGP current event: RecvUpdate
Peer supports bgp add-path capability
IPv4-UNC address-family: both
Negotiated bgp add-path capability
Update messages 10
Open messages 3
Refresh messages 0
Update messages 125139
Open messages 4
Refresh messages 0
Last keepalive received: 2013-07-30 05:56:07+00:00


Add-path capability has been enabled
Add-path number : 2
Send community has been configured
Send extend community has been configured
It's route-reflector-client
Connect-interface has been configured
The command output shows that BGP ADD-PATH has been enabled at both ends and that the
configured number of routes (including optimal and ADD-PATH routes) that the RR can send
to its peer is 2.
10.30 Configuring BMP

The BGP Monitoring Protocol (BMP) monitors BGP running status, such as the status of
BGP peer relationship establishment and termination and route updates.
Usage Scenario
Without BMP, manual query is required if you want to know about BGP running status. To
improve the network monitoring efficiency, you can configure BMP on a router to use a
monitoring server on the network to monitor BGP running status.
Before configuring BMP, configure basic BGP functions.
Procedure
l Configuring BMP.
a. Run:
system-view

b. Run:
bmp
BMP is started and the BMP view is displayed.

c. (Optional) Run:
statistics-timer time
An interval is set, at which the router sends BGP running statistics to a monitoring
server.
Configure the interval based on the network stability requirements. If BGP requires
high stability, configure a small interval. However, if the router sends BGP running
statistics frequently, a large amount of bandwidth resources will be consumed.
d. (Optional) Set the type of route whose statistics are to be sent to the monitoring
server.
n To configure a global type, run the route-mode { pre-policy | post-policy }
command.

n To configure a route type for the public-network or VPN peers, run the peer
ipv4-address [ vpn-instance vpn-instance-name ] route-mode { pre-policy |
post-policy } command.
To configure a type of route whose statistics are to be sent by BMP to the
monitoring server, run the peer route-mode command. To configure BMP to send
statistics about all the routes received from a specified peer to the monitoring
server, specify pre-policy in the command. To configure BMP to send statistics
about only the accepted routes (the ones that match the import policy) received
from a specified peer to the monitoring server, specify post-policy in the command.
The route type configured using the route-mode command applies to all BGP
peers. That is, pre-policy or post-policy applies to the routes received from all BGP
peers. The route type configured using the peer route-mode command applies to
only the specified type of BGP peer. That is, pre-policy can be configured for some
BGP peers, and post-policy is configured for other BGP peers.
NOTE
If you specify pre-policy in the command, run the keep-all-routes command in the BGP
view to save the routes carried in the BGP Update messages that are advertised by all BGP
peers or peer groups after BGP connections are established, or run the peer keep-all-routes
command to save the routes carried in the BGP Update messages that are advertised by a
specified BGP peer or peer group after the BGP connection is established.
e. Run:
session ipv4-address [ alias alias-name ]
An IPv4 address of the monitoring server is specified for TCP connections to be set
up between the router and the monitoring server.
If the alias alias-name parameter is specified in the command, the alias of a session
is specified. If the parameter is specified, multiple TCP connections can be
established with servers using different interfaces and the same IP address.
f. Run:
tcp connect port port-number [ password md5 cipher-password | keychain
keychain-name ]
Parameters are configured for TCP connections to be set up between the router and
the monitoring server.
g. (Optional) Run:
monitor address-family all disable
Monitoring of all BGP peers is disabled.

By default, all BGP peers are monitored in BMP scenarios. To allow each server to
monitor BGP peers in a unique address family so that different BGP services can be
controlled, run the monitor peer command. Before you run the monitor peer
command, you need to run the monitor address-family all disable command to
disable monitoring of all BGP peers.
h. (Optional) Run:
monitor ipv4-family { unicast | vpn-instance vpn-instance-name | vpnv4 }
peer ipv4-address
Monitoring of BGP peers in a specified address family is enabled.

By default, all BGP peers are monitored in BMP scenarios. To allow each server to
monitor BGP peers in a unique address family so that different BGP services can be
controlled, run the monitor peer command.

i. Run:
commit
NOTE
After configuring BMP session parameters, run the reset bmp session command to reset the
BMP session for the new BMP session parameters to take effect.
----End

l Run the display bmp session [ ipv4-address [ alias alias-name ] verbose ] command to
check configurations of a BMP session.
l Run the display bgp bmp-monitor { all | { ipv4 | vpnv4 vpn-instance vpn-instance-
name | vpnv4 } ipv4-address } command to check information about the BGP peers
monitored by a BMP session in all address families or in a specified address family.
# Run the display bmp session [ ipv4-address [ alias alias-name ] verbose ] command to
view BMP session configurations.
<HUAWEI> display bmp session 1.1.1.1 verbose
BMP session 1.1.1.1, port 0

Current state: Down (Reason: Manual Stop), Age: 11m55s
VPN-instance name: _public_
Local address: 0.0.0.0, Local port: 0
Route Mode: post-policy
Statistics timeout: 3600(s)
ConnectRetry Timer Remainder: 15(s)
Statistics-report Timer Remainder: 1884(s)
Bmp monitoring all peers
# Run the display bgp bmp-monitor { all | { ipv4 | vpnv4 vpn-instance vpn-instance-name |
vpnv4 } ipv4-address } command to view information about the BGP peers monitored by a
BMP session in all address families or in a specified address family.
<HUAWEI> display bgp bmp-monitor all
*>BGP ipv4-family unicast :
Peer : 10.1.1.1 route-mode : post-policy
Session Ip Alias State
2.2.2.2 b down
*>BGP ipv4-family vpn-instance ABC :
2.2.2.2 b down
2.2.2.2 b down
10.31 Configuring BGP Iteration Suppression in Case of

Next Hop Flapping
BGP iteration suppression in case of next hop flapping prevents the system from frequently
processing changes of a large number of routes that are iterated to a flapping next hop, which
reduces system resource consumption and CPU usage.

Usage Scenario
If a large number of routes are iterated to the same next hop that flaps frequently, the system
will be busy processing changes of these routes, which consumes excessive system resources
and leads to high CPU usage. To address this problem, configure BGP iteration suppression in
case of next hop flapping.
By default, BGP iteration suppression in case of next hop flapping is enabled. After this
function is enabled, BGP calculates the penalty value that starts from 0 by comparing the
flapping interval with configured intervals if next hop flapping occurs. When the penalty
value exceeds 10, BGP suppresses route iteration to the corresponding next hop. For example,
if the intervals for increasing, retaining, and clearing the penalty value are T1, T2, and T3,
respectively, BGP calculates the penalty value as follows:
l Increases the penalty value by 1 if the flapping interval is less than T1.
l Retains the penalty value if the flapping interval is greater than or equal to T1, but less
than T2.
l Reduces the penalty value by 1 if the flapping interval is greater than or equal to T2, but
less than T3.
l Clears the penalty value if the flapping interval is greater than or equal to T3.
Pre-configuration tasks
Before configuring BGP iteration suppression in case of next hop flapping, configure basic
BGP functions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
undo nexthop recursive-lookup restrain disable
BGP iteration suppression in case of next hop flapping is enabled.
If you do not care about whether the system is busy processing route selection and
advertisement and the possible high CPU usage, run the nexthop recursive-lookup restrain
disable command to disable BGP iteration suppression in case of next hop flapping.
Step 5 Run:
quit
Return to the BGP view.

Step 6 Run:
nexthop recursive-lookup restrain suppress-interval add-count-time hold-interval
hold-count-time clear-interval clear-count-time
The intervals are configured for increasing, retaining, and clearing the penalty value for BGP
iteration suppression in case of next hop flapping.
Step 7 Run:
commit
----End

After configuring BGP iteration suppression in case of next hop flapping, check the
configurations.
l Run the display bgp routing-table command to check BGP public network route
information.
l Run the display bgp vpnv4 routing-table command to check BGP VPNv4 and BGP
VPN route information.
# Run the display bgp routing-table network command to view BGP public network route
information. The command output shows that route iteration to a specified next hop is
suppressed because the next hop flaps. If only a small number of routes are iterated to the next
hop, the suppression is very short; therefore, the Relay is delayed as nexthop flapped
frequently field may not be displayed in this case.
Paths: 1 available, 1 best, 1 select, 0 best-external, 0 add-path
From: 11.1.1.2 (11.1.1.2)
Relay is delayed as nexthop flapped frequently
Primary Routing Table: vrf1
11.1.1.2
# Run the display bgp vpnv4 routing-table network command to view BGP VPNv4 route
information. The command output shows that route iteration to a specified next hop is
suppressed because the next hop flaps. If only a small number of routes are iterated to the next
hop, the suppression is very short; therefore, the Relay is delayed as nexthop flapped
frequently field may not be displayed in this case.
<HUAWEI> display bgp vpnv4 vpn-instance vrf1 routing-table 2.2.2.2

VPN-Instance vrf1, Router ID 10.99.1.111:

Remote-Cross route

Label information (Received/Applied): 33142/NULL

From: 3.3.3.9 (10.99.2.113)
Relay Tunnel Out-Interface:
Ext-Community: RT <1 : 1>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, best, select, pre 255
10.32 Configuring BGP-LS

BGP-LS provides a simple and efficient method of collecting topology information.
Usage Scenario
Without BGP-LS, the router uses an IGP (OSPF or IS-IS) to collect topology information of
each AS, and the IGP reports the information to the controller. This topology information
collection method has the following disadvantages:
l The controller must have high computing capabilities and support the IGP and its
algorithm.
l The controller cannot gain the complete inter-AS topology information and therefore is
unable to calculate optimal E2E paths.
l Different IGPs report topology information separately to the controller, which
complicates the controller's analysis and processing.
With powerful routing capabilities of BGP, BGP-LS has the following advantages:
l Reduces computing capability requirements and spares the necessity of IGPs on the
controller.
l Facilitates route selection and calculation on the controller by using BGP to summarize
process or AS topology information and report the complete information to the
controller.
l Requires only one routing protocol (BGP) to report topology information to the
controller.
BGP-LS needs to be deployed on the controller and the devices connected to it.
Before configuring BGP-LS, configure basic IPv4 IS-IS functions or basic OSPF functions.
Procedure
1. Enable IGP topology advertisement to BGP. You can determine to enable IS-IS topology
advertisement to BGP, OSPF topology advertisement to BGP, or both based on network
configurations.
– Enable IS-IS topology advertisement to BGP.
i. Run the system-view command to enter the system view.
ii. Run the isis [ process-id ] command to configure an IS-IS process.
iii. Run the bgp-ls enable [ level-1 | level-2 | level-1–2 ] command to enable IS-
IS topology advertisement to BGP.

iv. (Optional) Run the bgp-ls identifier identifier command to configure a BGP-
LS identifier.
v. Run the commit command to commit the configuration.
– Enable OSPF topology advertisement to BGP.
i. Run the system-view command to enter the system view.
ii. Run the ospf [ process-id | router-id router-id | vpn-instance vpn-instance-
name ] * command to configure an OSPF process.
iii. Run the bgp-ls enable command to enable OSPF topology advertisement to
BGP.
iv. (Optional) Run the bgp-ls identifier identifier-value command to configure a
BGP-LS identifier.
v. Run the commit command to commit the configuration.
2. Enable BGP-LS.
a. Run the system-view command to enter the system view.
b. Run the bgp { as-number-plain | as-number-dot } command to enable BGP and
enter the BGP view.
c. Run the peer { group-name | ipv4-address } as-number { as-number-plain | as-
number-dot } command to specify the IP address and AS number of a BGP peer.
A BGP-LS peer relationship needs to be established between each router that
collects topology information and the controller, and between routers on which
BGP-LS is enabled.
d. Run the link-state-family unicast command to enable BGP-LS and enter the BGP-
LS address family view.
e. Run the peer { group-name | ipv4-address } enable command to enable BGP-LS
route exchange with the specified peer or peer group.
f. (Optional) Run the domain identifier domain-id command to configure a BGP-LS
domain ID.
A BGP-LS domain ID indicates that BGP-LS is enabled on a device. If no BGP-LS
domain ID is configured, a BGP router ID is used as the BGP-LS domain ID by
default. One BGP-LS domain ID can be configured for multiple devices so that the
controller calculates routes based on the combined topology information reported
by the devices.
g. (Optional) Run the domain as { domain as-plain | domain as-dot } command to
configure a BGP-LS domain AS number.
Two devices with different BGP AS numbers must have the same BGP-LS domain
AS number configured using the domain as command so that the controller can
obtain combined topology information about the two ASs for route calculation.
h. (Optional) Run the peer { group-name | ipv4-address } reflect-client command to
configure an RR and specify a client for it.
The device where the peer reflect-client command is run functions as the RR, and
the specified peer or peer group functions as a client.

NOTE
If the clients of an RR are fully meshed, you can run the undo reflect between-clients
command to disable route reflection among these clients through the RR to reduce
bandwidth consumption.
If a cluster has multiple RRs configured, run the reflector cluster-id cluster-id command to
configure the same cluster ID for all the RRs. This command is applicable only to RRs.
i. (Optional) Run the peer { group-name | ipv4-address } route-limit limit
[ percentage ] [ alert-only | idle-forever | idle-timeout minutes ] command to set
the maximum number of BGP-LS routes that can be received from a specified peer.
In most cases, the BGP-LS routing table contains a large number of BGP-LS routes.
If a lot of BGP-LS routes are received from peers, many system resources will be
consumed. To reduce system resource consumption, you can configure the
maximum number of routes that a router can receive from a BGP-LS peer.
j. (Optional) Run the peer { group-name | ipv4-address } route-policy route-policy-
name { import | export } command to specify a route-policy for the BGP-LS
routes to be received from or advertised to a specified BGP peer or peer group.
After a route-policy is created, you can run the peer route-policy command to use
the route-policy to filter the BGP-LS routes to be received from or advertised to a
specified BGP peer or peer group. The command configuration ensures that only
desired routes are accepted or advertised, which helps manage routes and reduces
the BGP-LS routing table size and system resource consumption.
k. (Optional) Run the peer { group-name | ipv4-address } route-update-interval
interval command to configure an interval at which the device sends Update
messages carrying the same route prefix to a specified peer or peer group.
When BGP-LS routes change, the router sends Update messages to notify its peers.
If a route changes frequently, to prevent the router from sending Update messages
for every change, you can run this command to set an interval at which the device
sends Update messages carrying the same route prefix to a specified peer or peer
group.
l. Run the commit command to commit the configuration.

After configuring BGP-LS, check the configurations:
l Run the display bgp link-state unicast peer command to check information about
BGP-LS peers and their status.
l Run the display bgp link-state unicast routing-table command to check BGP-LS route
information.
l Run the display bgp link-state unicast routing-table statistics command to check
BGP-LS route statistics.
# Run the display bgp link-state unicast peer [ [ ipv4-address ] verbose ] command to view
information about BGP-LS peers and their status.
<HUAWEI> display bgp link-state unicast peer


PrefRcv
192.168.102.4 4 100 52 55 0 00:39:10
Established 4
# Run the display bgp link-state unicast routing-table [ peer ipv4-address received-
routes ] [ type { node | link | ipv4-prefix | ipv6-prefix } | bgp-ls-prefix ] command to view
BGP-LS route information.
<HUAWEI> display bgp link-state unicast routing-table

Total Number of Node Routes: 5

*> Network : [NODE][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as100][bgp-ls-
identifier11.1.1.2][ospf-area-id0.0.0.0][igp-router-id0000.0000.0001.00]]
NextHop : 0.0.0.0 LocPrf :
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
Total Number of Link Routes: 8

*> Network : [LINK][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as100][bgp-ls-
[REMOTE[as100][bgp-ls-identifier11.1.1.2][ospf-area-id0.0.0.0][igp-router-
id0000.0000.0001.01]][LINK[if-address0.0.0.0][peer-address0.0.0.0][if-address::]
[peer-address::][mt-id0]]
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?

MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
Total Number of IPv4 Prefix Routes: 5

*> Network : [IPV4-PREFIX][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as100][bgp-ls-
[PREFIX[mt-id0][ospf-route-type0][prefix11.1.1.0/24]]
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?

MED : 0 PrefVal : 0
Path/Ogn : ?
# Run the display bgp link-state unicast routing-table statistics [ peer ipv4-address
received-routes ] [ type { node | link | ipv4-prefix | ipv6-prefix } ] statistics command to
view BGP-LS route statistics.
<HUAWEI> display bgp link-state unicast routing-table statistics

10.33 Improving BGP Security

To improve BGP network security, you can configure BGP authentication and GTSM on the
BGP network.
Usage Scenario
By performing authentication for BGP peer connections and configuring BGP GTSM, you
can improve BGP network security.
l MD5 authentication
BGP uses TCP as the transport protocol and considers a packet valid if the source
address, destination address, source port, destination port, and TCP sequence number of
the packet are correct. However, most parameters in a packet are easily accessible to
attackers. To protect BGP against attacks, configure MD5 authentication for TCP
connections established between BGP peers.
To prevent the MD5 password set on a BGP peer from being decrypted, update the MD5
password periodically.
l Keychain authentication
A keychain consists of multiple authentication keys, each of which contains an ID and a
password. Each key has a lifecycle, and keys are dynamically selected based on the life
cycle of each key. After a keychain with the same rules is configured on the two ends of
a BGP connection, the keychains can dynamically select authentication keys to enhance
BGP attack defense.
l BGP GTSM
The GTSM mechanism protects a router by checking whether the TTL value in an IP
packet header is within a pre-defined range, which enhances the system security.
l BGP RPKI
Resource Public Key Infrastructure (RPKI) improves BGP security by validating the
origin ASs of BGP routes.
NOTE
GTSM supports only unicast addresses. Therefore, configure GTSM on all the routers configured with
routing protocols.
Before configuring BGP security, complete the following tasks:

l configure basic BGP functions.

l Configure a keychain
10.33.1 Configuring MD5 Authentication

In MD5 authentication, an Message Digest 5 (MD5) authentication password is set for a TCP
connection, and the MD5 authentication is performed by TCP. If authentication fails, no TCP
connection will be established.
Procedure
l Configuring MD5 Authentication.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
peer { ipv4-address | group-name } password { cipher cipher-password |
simple simple-password }
The MD5 authentication password is set.
An MD5 authentication password can be set in either a ciphertext or plaintext.
n cipher cipher-password indicates that a password is set using a ciphertext

string.
n simple simple-password indicates that a password is set using a plaintext
string.
NOTE
l The new password is at least eight characters long and contains at least two of upper-
case letters, lower-case letters, digits, and special characters.
l When configuring an authentication password, select the ciphertext mode becasue the
password is saved in configuration files in simple text if you select simple text mode,
which has a high risk. To ensure device security, change the password periodically.
l When this command is used in the BGP view, it is also applicable to the extended
address family view because they use the same TCP connection.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive.
d. Run:
commit
----End


l Run the display bgp peer [ ipv4-address ] verbose command to view the authentication
# Run the display bgp peer [ ipv4-address ] verbose command to view the authentication
<HUAWEI> display bgp peer verbose
Type: IBGP link
Group ID : 1
BGP current event: RecvUpdate
BGP last state: Established
Update messages 5
Open messages 3
Refresh messages 0
Update messages 5
Open messages 4
Refresh messages 0
Authentication type configured: MD5
10.33.2 Configuring Keychain Authentication

After a keychain with the same rules is configured on the two ends of a BGP connection, the
keychain can dynamically select the authentication keys to enhance BGP attack defense.
Procedure
l Configuring Keychain Authentication.
a. Run:
system-view

b. Run:

bgp as-number

c. Run:
peer { ipv4-address | group-name } keychain keychain-name
Keychain authentication is configured.

To ensure the setup of a TCP connection and BGP exchange between on both ends
of a BGP connection, configure keychain authentication specified for TCP-based
applications and the same password and encryption algorithms on both ends.
keychain-name specified in this command must exist; otherwise, the TCP
connection cannot be established. For keychain configuration details, see the
"Keychain Configuration" chapter in HUAWEI NetEngine40E Configuration Guide
- Security.
NOTE
l When this command is used in the BGP view, it is also applicable to the extended
address family view because they use the same TCP connection.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive.
d. Run:
commit

----End

l Run the display bgp peer [ ipv4-address ] verbose command to view the authentication
# Run the display bgp peer [ ipv4-address ] verbose command to view the authentication
<HUAWEI> display bgp peer verbose
Type: IBGP link
Group ID : 1
BGP current event: RecvKeepalive
BGP last state: Established
Update messages 3
Open messages 2

Refresh messages 0
Update messages 3
Open messages 2
Refresh messages 0
Authentication type configured: Key-Chain(abc)
10.33.3 Configuring BGP GTSM

BGP GTSM must be configured on both peers.
Usage Scenario
GTSM prevents attacks through TTL detection. An attacker simulates real BGP packets and
sends the packets in a large quantity to the router. After receiving the packets, an interface
board of the router directly sends the packets to the BGP module of the control plane if the
interface board finds that the packets are sent by the local router, without checking the
validity of the packets. The control plane of the router needs to process the "legal" packets. As
a result, the system becomes abnormally busy and the CPU usage is high.
GTSM protects the router by checking whether the TTL value in an IP packet header is within
a pre-defined range to enhance the system security.
NOTE
l GTSM supports only unicast addresses; therefore, GTSM must be configured on all the routers
configured with routing protocols.
Before configuring the BGP GTSM, complete the following task:
Perform the following steps on both BGP peers:
Procedure
Step 1 Configure the basic BGP GTSM functions.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:
peer { group-name | ipv4-address } valid-ttl-hops [ hops ]

The BGP GTSM is configured.
The valid TTL range of detected packets is [255 - hops + 1, 255]. For example, for an
EBGP direct route, the number of hops is 1, that is, the valid TTL value is 255. By
default, the valid TTL range is [1, 255], that is, the value of hops is 255.
NOTE
– When being configured in the BGP view, GTSM is also applicable to MP-BGP VPNv4
extensions because they use the same TCP connection.
– The GTSM and EBGP-MAX-HOP functions both affect the TTL values of sent BGP
messages and they conflict with each other. Thus, for a peer or a peer group, you can use only
either of them.
A BGP router that is enabled with GTSM checks the TTL values in all BGP packets. As
required by the actual networking, packets whose TTL values are not within the
specified range are discarded. If GTSM is not configured on a BGP router, the received
BGP packets are forwarded if the BGP peer configuration is matched. Otherwise, the
received BGP packets are discarded. This prevents bogus BGP packets from consuming
CPU resources.
4. Run:
commit
Step 2 Set the default action for packets that do not match the GTSM policy.
GTSM only checks the TTL values of packets that match the GTSM policy. Packets that do
not match the GTSM policy can be allowed or dropped. If "drop" is set as the default GTSM
action for packets, you need to configure TTL values for all the packets sent from valid peers
in the GTSM policy. If TTL values are not configured for the packets sent from a peer, the
device will discard the packets sent from the peer and cannot establish a connection to the
peer. Therefore, GTSM enhances security but reduces the ease of use.
You can enable the log function to record packet drop for troubleshooting.
Perform the following configurations on the GTSM-enabled router:
1. Run:
system-view

2. Run:
gtsm default-action { drop | pass }
The default action for packets that do not match the GTSM policy is configured.
NOTE
If the default action is configured but no GTSM policy is configured, GTSM does not take effect.
This command is supported only on the Admin-VS and cannot be configured in other VSs. This
command takes effect on all VSs.
3. Run:
commit
----End


Run the following command to check the previous configurations.
l Run the display gtsm statistics { slot-id | all } command to check the statistics about
GTSM.
NOTE
This command is supported only on the Admin-VS.
Run the display gtsm statistics command. Then, you can view the statistics about GTSM,
including the numbers of protocol packets, the number of packets that are allowed to pass
through, and the number of dropped packets. For example:
<HUAWEI> display gtsm statistics all
GTSM Statistics Table
---------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
---------------------------------------------------------------
2 BGP 18 0 18
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
2 OSPFv3 0 0 0
2 RIP 0 0 0
---------------------------------------------------------------
10.33.4 Configuring RPKI

Resource Public Key Infrastructure (RPKI) is used to secure BGP by validating the origin
ASs of BGP routes.
Usage Scenario
When an RPKI server is available on the network and you want to validate the origin ASs of
BGP routes, configure RPKI on a client to accept only the routes that originate from the
specified ASs. In addition, you can apply the validation result to BGP route selection to
ensure that hosts in the local AS can securely communicate with hosts in other ASs.
For the RPKI function to take effect, you need to start RPKI and configure RPKI session
parameters and apply the BGP origin AS validation result to route selection.
Before configuring RPKI, configure basic BGP functions.
Procedure
l Start RPKI and configure RPKI session parameters on a client.
a. Run:
system-view

b. Run:
rpki
RPKI is started, and the RPKI view is displayed.

c. Run:
session ipv4-address
An address of the RPKI server is specified for TCP connections to be set up

between the client and RPKI server.
d. Run:
tcp port-number [ password md5 cipher-password ]
A port number and authentication password are configured for TCP connections to
be set up between the client and RPKI server.
NOTE
l The new password is at least eight characters long and contains at least two of upper-
case letters, lower-case letters, digits, and special characters.
l When configuring an authentication password, select the ciphertext mode because the
password is saved in configuration files in simple text if you select simple text mode,
which has a high risk. To ensure device security, change the password periodically.
e. (Optional) Run:
timer { aging aging-time | refresh refresh-time }
Timers are configured for the RPKI session between the client and the RPKI server.
aging-time specifies the aging time of validation information, and refresh-time
specifies the interval at which validation information is updated. You can configure
the two timers to achieve the desired level of BGP security. If stronger BGP
security is desired, configure a small value for each timer. Note that frequent
validation information updates will lead to higher bandwidth resource consumption.
f. (Optional) Run:
rpki-limit limit [ alert-only | idle-forever | idle-timeout times ]
The maximum number of Route Origination Authorization (ROA) entries that the
device is allowed to receive from an RPKI session is configured.
In most cases, a large number of ROA entries are saved on an RPKI server. If the
device receives a a large number of ROA entries from the RPKI server, excessive
system resources will be consumed. In this situation, run the rpki-limit command
to configure the maximum number of ROA entries that the device is allowed to
receive from an RPKI session.
g. Run:
commit
NOTE
After configuring RPKI session parameters, run the reset rpki session command to reset the
RPKI session for the new RPKI session parameters to take effect.
l Apply the BGP origin AS validation result to route selection.
a. Run:
system-view

b. Run:
bgp as-number

c. Run:
prefix origin-validation enable
BGP origin AS validation is enabled.
After BGP origin AS validation is enabled, the client periodically queries Route
Origin Authorizations (ROAs) from the RPKI server and matches the origin AS of
each received BGP route against the ROAs. The validation result can be Valid, Not
Found, or Invalid.
NOTE
Run the display rpki table command to view the Route Origin Authorizations (ROAs).
d. Run:
bestroute origin-as-validation [ allow-invalid ]
The BGP origin AS validation result is applied to route selection.
BGP selects routes in the order of Valid, Not Found, and Invalid. If allow-invalid is
not specified in the command, BGP ignores the routes with the validation result
being Invalid during route selection.
e. Run:
peer { ipv4-address | group-name } advertise origin-as-validation
The BGP origin AS validation result is advertised to the specified BGP peer or peer
group.
f. Run:
commit
----End

Run the display rpki session ipv4-address verbose command to check RPKI session
configurations.
<HUAWEI> display rpki session 1.2.3.4 verbose
RPKI server is 1.2.3.4, port 8282

RPKI current state: Established, Age: 04s
VPN-instance name: _public_
Local host: 1.2.3.1, Local port: 51979
Remote host: 1.2.3.4, Remote port: 8282
Refresh time : 180
Aging time : 3600
Session ID : 23100
Serial number : 8
Session Statistics:
IPv4 record : 5
IPv6 record : 3
10.34 Configuring BGP Extensions

Configuring BGP extensions enables BGP to provide routing information for multiple routing
protocols.

Usage Scenario
The section does not describe the commands that are associated with specific applications and
used in the MP-BGP address family view in details.
For the BGP configurations in the IPv6 address family view, see chapter "BGP4+
Configuration."
For the BGP configurations in the BGP-IPv4 address family view and the BGP-VPN instance
address family view, see the HUAWEI NetEngine40E Universal Service Router Configuration
Guide - VPN.
For the applications of MP-BGP on multicast networks, see chapter "MBGP Configuration"
in the HUAWEI NetEngine40E Universal Service Router Configuration Guide - IP Multicast.
Before configuring BGP extensions, complete the following task:
None.
10.35 Maintaining BGP

Maintaining BGP involves resetting BGP connections and clearing BGP statistics.
10.35.1 Resetting BGP Connections

Resetting a BGP connection will interrupt peer relationships.
Context
NOTICE
The BGP peer relationship between routers is interrupted after you reset BGP connections
with the reset bgp command. Therefore, exercise caution when running the command.
When the BGP routing policy on a device that does not support the router -fresh capability
changes, you need to reset BGP connections so that the change can take effect. To reset BGP
connections, run the following reset commands in the user view:
Procedure
l To reset all BGP connections, run the reset bgp all command.
l To reset BGP connections with a specified AS, run the reset bgp as-number command.
l To reset BGP connections with a specified peer, run the reset bgp ipv4-address
command.

l To reset all EBGP connections, run the reset bgp external command.
l To reset BGP connections with a specified peer group, run the reset bgp group group-
name command.
l To reset all IBGP connections, run the reset bgp internal command.
----End
10.35.2 Clearing BGP Statistics

This section describes how to clear the statistics about flapping routes and dampened routes.
Context
NOTICE
BGP statistics cannot be restored after being cleared. Therefore, exercise caution when
running the command.
Procedure
l To clear statistics about flapping routes, run the reset bgp flap-info [ regexp as-path-
regexp | as-path-filter { as-path-filter-number | as-path-filter-name } | ipv4-address
[ mask | mask-length ] ] command in the user view.
l To clear statistics about flapping routes of a specified peer, run the reset bgp ipv4-
address flap-info command in the user view.
l To clear statistics about dampened routes and release dampened routes, run the reset bgp
dampening [ ipv4-address [ mask | mask-length ] ] command in the user view.
----End
10.35.3 Configuring BGP to Record Peer Status Changes and

Event Information
After you configure BGP to record peer status changes and event information, BGP logs
every peer status change or event.
Context
If an error occurs on a BGP peer, BGP generates an error code and a subcode. If the error
occurs on the local device, the local device disconnects the BGP peer and sends a BGP
Notification message to the BGP peer. After the BGP peer receives the Notification message,
it records the error code and subcode carried in the message and changes its state machine.
By default, BGP records peer status changes and event information in the system log files.
The record includes BGP error codes and subcodes, BGP state machine changes, and whether
BGP Notification messages are sent. The system log files serve as a reference to locate
network connectivity faults.
If you do not want BGP to record peer status changes or event information, run the undo peer
log-change command. After you run the undo peer log-change command, BGP records only

the last peer status change in the log file. To check this log, run the display bgp peer loginfo
command.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family unicast

Step 4 Run:
peer { ipv4-address | group-name } log-change
BGP is configured to record peer status changes and event information.

Step 5 Run:
commit
----End
10.36 BGP Route Selection Rules
10.36.1 Route Processing on the BGP router

This section describes the route processing on the BGP router.
Figure 10-17 shows the route processing on the BGP router. BGP routes can be imported
from other protocols or learned from BGP peers. Route summarization can be configured to
reduce the routing table size before routes are selected, advertised, and delivered to the IP
routing table.

Figure 10-17 Route processing on the BGP router
1 2
Direct Routing 3 4 5 2
Static policy
IGP Route BGP
Route Export
summarizati routing BGP
selection policy
on table peers
2
BGP 入口
Import
peers 策略
policy
6
Routes learned from BGP
peers
IP routing
table
Table 10-4 lists some key points for Figure 10-17.
Table 10-4 Key points for route processing

No. Remarks
1 BGP can import direct routes, static routes, user network routes, and IGP routes
based on the import-route (BGP) or network command configuration.
2 BGP can use routing polices when importing routes from other protocols, receiving
routes from BGP peers, or advertising routes to BGP peers. Routing polices can be
used to filter routes or modify route attributes.
3 BGP supports automatic and manual summarization. Multiple routing policies can
be used during manual summarization.
4 BGP selects routes based on strict route selection rules, which is the key point to be
discussed in the following part.
5 BGP adds the optimal route to the BGP routing table and advertises it to BGP peers.
6 BGP adds the routes learned from peers and the optimal route in the BGP routing
table to the IP routing table for traffic forwarding.
10.36.2 BGP Route Selection Rules

When multiple routes are available to the same destination, BGP selects one optimal route
based on BGP route selection rules and adds it to the IP routing table for traffic forwarding.
Figure 10-18 shows how the optimal route is selected.

Figure 10-18 BGP route selection process

BGP selects routes by comparing route attributes in a fixed order. When a route attribute is a
sufficient condition for determining the optimal route, BGP does not compare the other
attributes; If BGP fails to select the optimal route after comparing all route attributes, the
route that was first received is selected as the optimal route.Table 10-5 lists the abbreviated
alias, route selection rules, and remarks of each matching item. Table 10-5 shows that the
route priority is directly proportional to the PreVal or Local_Pref value and inversely
proportional to the rest of the attribute values or lengths. In addition, the first column can be
summarized as a character string (OPPAAA OMTCC RA), which helps memorize the
matching sequence.
Table 10-5 BGP route selection process

Abbr Matching Route Selection Rules Remarks
eviate Item
d
Alias
O Origin AS Valid > NotFound > BGP origin AS validation states are
Invalid applied to route selection in a
scenario where the device is
connected to an RPKI server.
P PrefVal The route with the PrefVal is Huawei-specific and valid

largest PreVal value is only on the device where it is
preferred. configured.
The default value is 0.
P Local_Pref The route with the To modify the default Local_Pref

largest Local_Pref value value of BGP routes, run the default
is preferred. local-preference command.
The default value is 100.


eviate Item
d
Alias
A Route type A > S > N > I > L, in -

NOTE which:
A is l A: indicates that
the
routes are
initia
l of summarized using the
the aggregate command.
chara l S: indicates that
cter
routes are
strin
g summarized using the
(AS summary automatic
NIL). command.
l N: indicates that
routes are imported
using the network
command.
l I: indicates that
routes are imported
using the import-
route command.
l L: indicates that
routes are learned
from BGP peers.
A Accumulated The route with the -

Interior smallest AIGP value is
Gateway preferred.
Protocol The route with AIGP to
(AIGP) the route without AIGP
is preferred.
A AS_Path The route with the If the bestroute as-path-ignore

shortest AS_Path length command is configured, BGP does
is preferred. not compare the AS_Path attribute.
O Origin IGP > EGP > Incomplete -
M Multi Exit The route with the If the bestroute med-none-as-

Discriminator smallest MED value is maximum command is configured,
(MED) preferred. BGP considers the largest MED
The default value is 0. value (4294967295) as the MED of
the route that does not carry an MED.
For details about MED usage, see
MED.
T Peer type EBGP > IBGP -


eviate Item
d
Alias
C IGP metric The route with the If the bestroute igp-metric-ignore

smallest IGP cost is command is configured, BGP does
preferred. not compare the IGP cost.
C Cluster_List The route with the By default, Cluster_List takes

shortest Cluster_List precedence over Originator_ID
length is preferred. during BGP route selection. To
enable Originator_ID to take
precedence over Cluster_List during
BGP route selection, run the
bestroute routerid-prior-clusterlist
command.
R Router ID The route with the If routes carry the Originator_ID, the
smallest router ID is originator ID is substituted for the
preferred. router ID during route selection. The
route with the smallest Originator_ID
is preferred.
A Peer IP The route learned from -

address the peer with the
smallest IP address is
preferred.
Selection of the Routes for Load Balancing

After BGP load balancing is configured, the BGP routes that meet the following conditions
are used as equal-cost routes for load balancing:
l The routes have the same Origin AS.
l The routes have the same PrefVal value.
l The routes have the same Local_Pref value.
l All the routes are summarized or non-summarized routes.
l The routes have the same AIGP value.
l The routes have the same AS_Path length.
l The routes have the same origin type (IGP, EGP, or incomplete).
l The routes have the same MED value.
l All the routes are EBGP or IBGP routes. After the maximum load-balancing eibgp
command is run, BGP ignores this limitation when selecting the optimal VPN route.
l The costs of the IGP routes to which the BGP routes are iterated within an AS are the
same. After the maximum load-balancing eibgp command is run, BGP ignores this
limitation when selecting the optimal VPN route.
In addition, BGP labeled routes and non-labeled routes cannot load-balance traffic even if
they meet the preceding conditions.

VPN Route Selection Rules

BGP VPN routes are selected in the same way as BGP public routes except that VPN target-
based route crossing is implemented first on BGP VPN routes. For details about BGP VPN
route crossing, see "Route Crossing" in NE40E Feature Description - IP Routing - BGP.
10.36.3 BGP Routing Table

This section describes how to check route attributes.
Table 10-6 lists all the common route attributes that affect route selection and the commands
that are used to check them.
Table 10-6 Commands used to check route attributes

Route Command Used to Check the Route Attribute
Attribute
Origin AS display bgp routing-table [ network ]
PrefVal display bgp routing-table [ network ]
Local_Pref display bgp routing-table [ network ]
Route type display bgp routing-table network
AIGP display bgp routing-table network
AS_Path display bgp routing-table [ network ]
Origin display bgp routing-table [ network ]
MED display bgp routing-table [ network ]
Peer type display bgp routing-table network
IGP Metric l display bgp routing-table network

l display ip routing-table ip-address [ mask | mask-length ] [ verbose ],
in which ip-address is the next hop IP address of a BGP route
Cluster_List display bgp routing-table network
Originator_ID display bgp routing-table network
Router ID display bgp routing-table network
Peer IP display bgp routing-table network

address
The following example describes how to check BGP route attributes in the display bgp
routing-table command output.


* 1.1.1.0/24 1.1.1.1 0 0 100?

* 1.1.1.2/32 1.1.1.1 0 0 100?
*> 5.1.1.0/24 1.1.1.1 0 0 100?
*> 100.1.1.0/24 1.1.1.1 0 0 100?
Table 10-7 Description of the display bgp routing-table command output

Item Description
BGP Local
router ID is
1.1.1.2 Router ID: 1.1.1.2, in the same format as an IPv4 address

Item Description
Route status code, displayed in front of each route entry:

l *: indicates a valid route with a reachable next hop address.
l >: indicates an optimal route selected by BGP.
l d: indicates a dampened route.
l x: indicates a Best-external route.
l a: indicates an ADD-PATH route.
l h: indicates a History route.
l i: indicates a route learned from an IBGP peer.
l s: indicates a suppressed route. If specific routes for route
summarization are suppressed, s is displayed in front of each specific
route.
l S: indicates a route in Stale status, and the route is being deleted. Such
routes may occur during a BGP GR process.
BGP dampening measures route stability using a penalty value. The greater
the penalty value, the less stable a route. Each time route flapping occurs (a
device receives a Withdraw or an Update packet), BGP adds a penalty
value to the route carried in the packet.
When the penalty value of a route exceeds the Suppress value, BGP
suppresses the route by replacing the > sign of the route with the d or h
sign. The route is ignored and its Update packets are not advertised to other
BGP peers until the penalty value of the route decreases to the Reuse value.
l If d is displayed in front of a route, the route is carried in an Update
packet.
l If h is displayed in front of a route, the route is carried in a Withdraw
packet.
The penalty value is not increased after it reaches the suppression
threshold. The penalty value of a suppressed route reduces by half after a
half-life period.
l When the penalty value of a route with the d sign decreases to the
Reuse value, the route becomes reusable, and BGP removes the d sign,
adds the route to the IP routing table, and advertises an Update packet
carrying the route to BGP peers.
l When the penalty value of a route with the h sign decreases to 0, BGP
Status codes deletes this route from the BGP routing table.
Route origin code:

l IGP: indicates that routes are added to the BGP routing table using the
network (BGP) command.
l EGP: indicates that routes are learned through the EGP protocol.
l Incomplete: indicates that routes are added to the BGP routing table
Origin using the import-route (BGP) command.

Item Description
Route origin AS validation code.

l V: indicates a valid route.
RPKI
validation l I: indicates an invalid route.
codes l N: indicates a not-found route.
Network Network address in the BGP routing table
NextHop Next hop address
MED MED value of a BGP route, similar to the cost of IGP routes
LocPrf Local_Pref
PrefVal PrefVal
Path/Ogn AS_Path and Origin attributes
Information about Next_Hop, MED, Local_Pref, PrefVal, AS_Path, and Origin can be
displayed using the display bgp routing-table command. To check information about the
route type, AIGP, peer type, IGP cost, Cluster_List, router ID, and peer IP address, run the
display bgp routing-table network command.

From: 10.1.3.1 (192.168.2.3)
Primary Routing Table: vrf1
10.1.3.1
Table 10-8 Description of the display bgp routing-table command output

Item Description
BGP local router Router ID of the local device, in the same format as an IPv4 address.
ID
Local AS number Local AS number.
Paths BGP route information.
BGP routing table Information about the BGP route 10.1.1.1/32:

entry information
of 10.1.1.1/32

Item Description
From IP address of the device that advertised the route. In this example,
10.1.3.1 is the IP address of the interface used by the peer to establish
the BGP peer relationship (peer IP address), and 192.168.2.3 is the
router ID of the peer.
Route Duration Duration of a route.
Direct Out- Directly connected interface.

interface
Relay is delayed as Route iteration to a specified next hop is suppressed because the next
nexthop flapped hop flaps. If only a small number of routes are iterated to the next
frequently hop, the suppression is very short; therefore, this field may not be
displayed in this case.
Original nexthop Original next hop IP address.
Qos information QoS information.
Primary Routing The source routing table

Table
AS-path AS_Path attribute. If Nil is displayed, the AS_Path attribute is null.
origin incomplete Origin attribute:

l IGP: indicates that routes are added to the BGP routing table using
the network (BGP) command.
l EGP: indicates that routes are learned through the EGP protocol.
l Incomplete: indicates that routes are imported using the import-
route (BGP) command.
MED MED value of a BGP route, similar to the cost of IGP routes.
pref-val PrefVal
valid Valid route with a reachable next hop address.
external Type of the peer from which the route is learned.

l external: indicates that the route is learned from an EBGP peer.
l internal: indicates that the route is learned from an IBGP peer.
best Optimal route.
select Selected route to be delivered to the IP routing table.

NOTE
According to BGP selection rules, BGP selects only one optimal route, and
this route is marked with best. In load balancing or FRR scenarios, more than
one route needs to be added to the IP routing table, and each of the route is
marked with select. Therefore, the number of the route marked with best is 1,
and the number of the routes marked with select is the actual number of routes
added to the IP routing table.
active Active route.

Item Description
pre 255 Protocol priority of the route: 255
Advertised to such The BGP route has been advertised to one peer.
1 peers
The display bgp routing-table network [ { mask | mask-length } [ longer-prefixes ] ]

command output varies with the route generation mode and transmission mode, and not all
BGP attributes are necessarily displayed. In the preceding example, the route type is not
displayed because the route 12.13.14.15/32 is an IBGP route. If you run the display bgp
routing-table network [ { mask | mask-length } [ longer-prefixes ] ] command, the route type
will be displayed. For example:

Aggregated route.
Direct Out-interface: NULL0
AS-path {65001 10 100}, origin incomplete, pref-val 0, valid, local, best,
Aggregator: AS 200, Aggregator ID 192.168.2.4, Atomic-aggregate
10.1.7.2
172.16.1.2
192.168.1.2
The route 10.0.0.0/8 was manually summarized using the aggregate command. Therefore,
Aggregated route is displayed in the command output. The route type varies as follows:
l If the route is automatically summarized using the summary automatic command,
Summary automatic route will be displayed.
l If the route is imported using the network command, Network route will be displayed.
l If the route is imported using the import-route command, Imported route will be
displayed.
In the following example, an RR and a cluster are configured. Therefore, the Cluster_List
attribute is displayed in the display bgp routing-table network [ { mask | mask-length }
[ longer-prefixes ] ] command output.

From: 10.1.4.1 (2.2.2.2)
Originator: 1.1.1.1


10.36.4 Route Attributes
10.36.4.1 Next_Hop
BGP ignores routes with an unreachable next hop address during BGP route selection.
Unlike the Next_Hop attribute in an IGP, the Next_Hop attribute in BGP is not necessarily the
IP address of a neighboring device. In most cases, the Next_Hop attribute in BGP complies
with the following rules:
l When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop of the
route to the address of the local interface through which the BGP peer relationship is
established.
l When advertising a locally generated route to an IBGP peer, a BGP speaker sets the
Next_Hop of the route to the address of the local interface through which the BGP peer
relationship is established.
l When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker
does not modify the Next_Hop of the route.
Modifying the Next_Hop

In some scenarios, the Next_Hop needs to be modified. Table 10-9 describes whether the
Next_Hop needs to be modified in specific scenarios.

Table 10-9 Next_Hop processing

Objectives Command Usage Scenarios Remarks
To enable an peer { ipv4-address | By default, when an If BGP load

ASBR to group-name } next- ASBR forwards a route balancing has been
modify the hop-local learned from an EBGP configured using the
Next_Hop of peer to its IBGP peers, the maximum load-
the routes to ASBR does not change balancing number
be advertised the Next_Hop of the command, the router
to an IBGP route. Therefore, the modifies the
peer. Next_Hop address of the Next_Hop of each
route remains the EBGP route to the local IP
peer IP address. After address through
being forwarded to the which the IBGP peer
IBGP peers, the route relationship is
cannot become active as established before it
the Next_Hop is advertises the route
unreachable. To address to the IBGP peer,
this issue, configure the regardless of
ASBR to modify the whether the peer
Next_Hop of the route to next-hop-local
the local IP address before command is
advertising the route to an configured.
IBGP peer. After being
forwarded to the IBGP
peer, the route can be
active because the
Next_Hop is reachable (an
IGP is configured in the
AS).
To configure a peer { ipv4-address | In an intra-AS scenario, if By default, a device

device to group-name } next- a device is configured to modifies the
retain the hop-invariable retain the original Next_Hop of the
original Next_Hop of imported routes imported
Next_Hop of IGP routes when from an IGP to the
imported IGP advertising the routes to local IP address
routes when an IBGP peer, the peer before advertising
advertising the can use the original the routes to IBGP
routes to an Next_Hop for iteration, peers.
IBGP peer. which reduces the number
of hops.

To prevent a peer { group-name | In an inter-AS VPN By default, a device

device from ipv4-address } next- Option C scenario where modifies the
modifying the hop-invariable an RR is used, the peer Next_Hops of routes
Next_Hops of next-hop-invariable to the local IP
routes before command needs to be run address before
advertising the on the RR to prevent the advertising the
routes to RR from modifying the routes to EBGP
EBGP peers. Next_Hops of routes peers.
before advertising the In addition, a device
routes to EBGP peers. does not modify the
This ensures that the Next_Hops of non-
remote PE iterates routes labeled routes if the
to the LSP destined for the routes are learned
local PE during traffic from EBGP peers
transmission. and are to be
advertised to IBGP
peers; the device
sets its interface IP
address as the
Next_Hops of
labeled routes if the
routes are learned
from EBGP peers
and are to be
advertised to IBGP
peers.
To configure nexthop recursive- To enable a device to By default,

BGP lookup route-policy iterate only desired routes, Next_Hop iteration
Next_Hop route-policy-name configure Next_Hop based on a specified
iteration based iteration based on a route-policy is not
on a route- specified route-policy so configured.
policy. that only the routes that
match the route-policy are
iterated.

To enable a apply ip-address The Next_Hops of BGP If a route-policy has

device to next-hop { ipv4- routes can be modified been specified in the
modify the address | peer- using a route-policy in the import-route or
Next_Hops of address } following situations: network command,
BGP routes l For IBGP peers, the the apply clause
using a route- route-policy can be an configured for the
policy. import or export route-policy using
policy. Even if the next the apply ip-
hop address configured address next-hop
in the route-policy is command does not
unreachable, the IBGP take effect.
peers still add the
routes whose next hop
addresses have been
changed to the address
configured in the
route-policy to the
BGP routing table.
However, the routes
are invalid.
l For EBGP peers, the
route-policy can only
be an import policy in
most cases. If the
route-policy is
configured as an
export policy, the
routes whose next hop
addresses have been
changed to the address
configured in the
route-policy are
discarded by the
EBGP peers because
the next hop address is
unreachable.
Obtaining a Reachable Next Hop

During route selection, BGP first checks whether the next hop addresses of routes are
reachable. Routes carrying unreachable next hop addresses are invalid and are not selected.
Table 10-10 shows how to obtain a reachable next hop IP address or tunnel.

Table 10-10 Unreachable next hop

Item Description Solutions
Unreachable next hop IP A next hop IP address is Common solutions are as

address obtained through route follows:
iteration, but no active l Configure static routes or
routes to the IP address are an IGP.
available in the IP routing
table. l Run the import-route
command.
l Run the network
command.
Alternatively, you can run
the peer next-hop-local
command to change the
Next_Hop to the local IP
address.
Unreachable next hop tunnel Routes fail to be iterated to Configure a tunnel policy or
tunnels. a tunnel selector to ensure
that the routes can be
A next hop tunnel is Ensure that the tunnel is

obtained through route correctly configured and is
iteration, but the tunnel is Up.
unavailable.
The following example shows how to obtain a reachable next hop IP address. In Figure
10-19, an IBGP peer relationship is established between Device A and Device B, and an
EBGP peer relationship is established between Device B and Device C. Device A imports the
route 1.1.1.9/32, and Device C imports the route 3.3.3.9/32.
Figure 10-19 Networking
3.3.3.9/32
1.1.1.9/32
10.1.1.1/30 10.1.2.1/30
10.1.1.2/30 10.1.2.2/30
DeviceA DeviceB DeviceC
AS 300 AS 65001
# Display the BGP routing table of Device A.

[~DeviceA] display bgp routing-table



*> 1.1.1.9/32 0.0.0.0 0 0 i

i 3.3.3.9/32 10.1.2.1 0 100 0 65001i
The preceding command output shows that no asterisk (*) is in front of the route 3.3.3.9/32,
which indicates that the route is invalid.
# Display the IP routing table of Device A.
[~DeviceA] display ip routing-table
------------------------------------------------------------------------------
Routing Tables: _public_
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack1

10.1.1.0/30 Direct 0 0 D 10.1.1.1
GigabitEthernet1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
The preceding command output shows that the next hop IP address (10.1.2.1) of the route
3.3.3.9/32 is not in the IP routing table, which indicates that the route is not selected due to
the unreachable next hop IP address. The following solutions can address this issue:
l Configure a static route destined for 10.1.2.1/30 on Device A.
l Configure an IGP on Device B and Device C and configure BGP to import the route
10.1.2.1 on Device B. This solution is not applicable to this specific scenario because
Device B and Device C are located in different ASs.
l Run the import-route direct command on Device B. This solution is not optimal
because unnecessary routes may be imported.
l Run the network 10.1.2.0 30 command on Device B to advertise the route 10.1.2.0/30 to
Device A.
l Run the peer 10.1.1.1 next-hop-local command on Device B to configure Device B to
modify the Next_Hop of the route 3.3.3.9/32 before advertising the route to Device A.
In this example, the network 10.1.2.0 30 command is configured on Device B. After the
command is configured, check the BGP routing table of Device A.


*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 3.3.3.9/32 10.1.2.1 0 100 0 65001i
*>i 10.1.2.0/30 10.1.1.2 0 100 0 i
The preceding command output shows that both * and > are in front of the route 3.3.3.9/32,
which indicates that the route is valid and optimal.

10.36.4.2 PrefVal
BGP prefers the route with the largest PreVal value during BGP route selection.
PrefVal is Huawei-specific and valid only on the device where it is configured. The PreVal
attribute is set by customers. Therefore, BGP first compares the PreVal values during route
selection.
To configure a PreVal value for the routes learned from a peer or peer group, run the peer
{ group-name | ipv4-address } preferred-value value command.
If multiple routes are available to the same destination, the route with the largest PreVal value
is selected as the optimal route. By default, the PreVal of the routes learned from BGP peers is
0.
Table 10-11 lists two methods to modify the PreVal value.
Table 10-11 Methods to modify the PreVal value

Method Usage Scenario
Run the peer { group-name | ipv4-address } This method sets a PreVal value for the
preferred-value value command. routes learned from a peer or peer group.
Configure an import policy and run the This method sets different PreVal values for
apply preferred-value preferred-value different routes learned from a peer or peer
command to configure an apply clause for group.
the policy. NOTE
If both the methods are used, the method with the
import policy takes effect if routes match the
conditions specified in the peer preferred-value
command and the import policy.
The following example shows how the PreVal value is used during route selection. In Figure
10-20, both ISP1 and ISP2 advertise the routes 10.11.0.0/16 and 10.22.0.0/16 to AS 65001.

Figure 10-20 PreVal application networking
Internet
10.11.0.0/16
10.22.0.0/16
AS 100
10.1.1.1/30 10.1.4.1/30
ISP2
ISP1 EBGP IBGP AS 200
10.1.1.2/30 10.1.4.2/30
AS 300
10.1.2.2/30 10.1.3.2/30
EBGP EBGP
10.1.2.1/30 10.1.3.1/30
DeviceA
Client Network
AS 65001
Scenario 1: When no PreVal value is configured on Device A, check the BGP routing table of
Device A.


*> 10.11.0.0/16 10.1.3.2 0 200?

* 10.1.2.2 0 300 100?
*> 10.22.0.0/16 10.1.3.2 0 200?
* 10.1.2.2 0 300 100?
The BGP routing table of Device A shows that Device A receives the routes 10.11.0.0/16 and
10.22.0.0/16 from ISP1 and ISP2. Check the information about the route 10.11.0.0/16 on
Device A.
[~DeviceA] display bgp routing-table 10.11.0.0


From: 10.1.3.2 (10.1.3.2)
AS-path 200, origin incomplete, pref-val 0, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.2.2
From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for AS-Path
The preceding command output shows that the AS_Path of the route learned from ISP2 is
shorter than that of the route learned from ISP1. Therefore, the route learned from ISP2 is
selected as the optimal route. Table 10-12 shows the route attribute comparison of the routes
10.11.0.0/16 learned from ISP1 and ISP2.
Table 10-12 Route attribute comparison of the route learned from ISP1 and that learned from
ISP2

from ISP1 from ISP2

NOTE
If a route does not
carry Local_Pref, the
default value 100
takes effect.
AIGP - - The same.
AS_Path 300 100 200 The route learned

from ISP2 is
selected as the
optimal route
because its AS_Path
is shorter than that
of the route learned
from ISP1.
Scenario 2: The administrator of AS 65001 requires that ISP1 be active and ISP2 be backup
for the traffic to 10.11.0.0/16 and 10.22.0.0/16.

To meet the preceding requirements, run the peer { group-name | ipv4-address } preferred-
value value command on Device A to increase the PrefVal values of the routes learned from
ISP1. This configuration ensures that the routes learned from ISP1 are selected as the optimal
routes. Detailed configurations are as follows:
bgp 65001
#
ipv4-family unicast
peer 10.1.2.2 preferred-value 120 //Set the PrefVal of the
routes learned from AS 300 to 120.
Run the display bgp routing-table [ ip-address ] command to check the configurations.
# Display the routing table of Device A.


*> 10.11.0.0/16 10.1.2.2 120 300 100?

* 10.1.3.2 0 200?
*> 10.22.0.0/16 10.1.2.2 120 300 100?
* 10.1.3.2 0 200?
The preceding command output shows that Device A selects the routes learned from ISP1.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Device A. The
route 10.11.0.0/16 is used as an example.

From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 120, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.2.2
From: 10.1.3.2 (10.1.3.2)
AS-path 200, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for PreVal
The preceding command output shows that the PrefVal value of the route learned from ISP1 is
greater than that of the route learned from ISP2 and that the route learned from ISP1 is
selected as the optimal route.
Scenario 3: The expected configurations of the administrator of AS 65001 are as follows:

l For the traffic destined to 10.11.0.0/16, ISP1 is active and ISP2 is backup.
l For the traffic destined to 10.22.0.0/16, ISP2 is active and ISP1 is backup.
To meet the preceding requirements, ensure that Device A selects the route 10.11.0.0/16
learned from ISP1 and the route 10.22.0.0/16 learned from ISP2. In this situation, the peer
preferred-value command can no longer be used because different PrefVal values are
required for the routes learned from the same ISP. To allow different PrefVal values for the
routes learned from the same ISP, configure import policies. Detailed configurations are as
follows:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.2.2 route-policy for_isp1_in import //Apply import policy
named for_isp1_in to the routes learned from 10.1.2.2 and use for_isp1_in to
modify the PrefVal value.
peer 10.1.3.2 route-policy for_isp2_in import //Apply import policy
named for_isp2_in to the routes learned from 10.1.3.2 and use for_isp2_in to
modify the PrefVal value.
#
route-policy for_isp1_in permit node 10 //Define the first node of
for_isp1_in and set the PrefVal value of the route 10.11.0.0/16 to 80.
if-match ip-prefix for_isp1
apply preferred-value 80
#
route-policy for_isp1_in permit node 20 //Define the second node
of for_isp1_in and allow for_isp1_in to permit all routes.
#
route-policy for_isp2_in permit node 10 //Define the first node of
for_isp2_in and set the PrefVal value of the route 10.22.0.0/16 to 120.
if-match ip-prefix for_isp2
apply preferred-value 120
#
route-policy for_isp2_in permit node 20 //Define the second node
of for_isp2_in and allow for_isp2_in to permit all routes.
#
ip ip-prefix for_isp1 index 10 permit 10.11.0.0 16 //Configure an IP prefix
list to match the route 10.11.0.0/16.
ip ip-prefix for_isp2 index 10 permit 10.22.0.0 16 //Configure an IP prefix
list to match the route 10.22.0.0/16.
#


*> 10.11.0.0/16 10.1.2.2 80 300 100?

* 10.1.3.2 0 200?
*> 10.22.0.0/16 10.1.3.2 120 200?
* 10.1.2.2 0 300 100?
The preceding command output shows that Device A selects the route 10.11.0.0/16 learned
from ISP1 and the route 10.22.0.0/16 learned from ISP2.
# Display detailed information about the route 10.22.0.0/16 on Device A.


From: 10.1.3.2 (10.1.3.2)
AS-path 200, origin incomplete, pref-val 120, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.2.2
From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for PreVal
The preceding command output shows that two routes 10.22.0.0/16 are available in the BGP
routing table of Device A and that the route with the next hop address 10.1.3.2 is selected
because its PrefVal (120) is greater than the PrefVal (0) of the route with next hop address
10.1.2.2. The PrefVal value is sufficient enough to determine the optimal route, and therefore,
Device A does not compare other route attributes.
The preceding examples show that PrefVal values can be configured as required to control the
traffic forwarding path.
10.36.4.3 Local_Pref
BGP prefers the route with the highest Local_Pref during BGP route selection.
The Local_Pref attribute is used to determine the optimal route when traffic leaves an AS.
The Local_Pref attribute is available only to IBGP peers and is not advertised to other ASs.
Table 10-13 lists two methods to modify the Local_Pref value.
Table 10-13 Methods to modify the Local_Pref value

Run the default local-preference This method sets a default Local_Pref for
command. the routes that the local device advertises to
IBGP peers.
Configure an import or export policy and This method sets different Local_Pref
run the apply local-preference command to values for different routes that the local
configure an apply clause for the policy. device advertises to IBGP peers.
NOTE
If both the methods are used, the method with the
import policy takes effect if routes match the
conditions specified in the apply local-
preference command and the policy.

The following example shows how the Local_Pref value is used during route selection. In
Figure 10-21, both ISP1 and ISP2 advertise the routes 10.11.0.0/16 and 10.22.0.0/16 to AS
65001.
Figure 10-21 Local_Pref application networking
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
10.1.1.1/30 10.1.2.1/30
EBGP EBGP
Client Network
AS 65001
10.1.1.2/30 10.1.2.2/30
10.1.3.1/30
DeviceA DeviceB
IBGP 10.1.3.2/30
10.1.4.1/30 10.1.5.1/30
IBGP IBGP
10.1.4.2/30 10.1.5.2/30
DeviceC
Scenario 1: When no Local_Pref value is configured on Device A and Device B, check the
BGP routing tables of Device A and Device B.


*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
The BGP routing table of Device A shows that Device A receives the routes 10.11.0.0/16 and
10.22.0.0/16 from ISP1 and Device B. Check the information about the route 10.11.0.0/16 on
Device A.


From: 10.1.1.1 (192.168.2.5)
AS-path 100 10, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
10.1.3.2
10.1.4.2
From: 10.1.3.2 (192.168.2.2)
AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, pre 255,
not preferred for peer type
The preceding command output shows that the route learned from ISP1 is selected as the
optimal route because it is an EBGP route and the route learned from Device B is an IBGP
route. Table 10-14 shows the route attribute comparison of the routes 10.11.0.0/16 learned
from ISP1 and Device B.
Table 10-14 Route attribute comparison of the routes 10.11.0.0/16 learned from ISP1 and
Device B
from ISP1 from Device B
Local_Pref - 100 The same.

NOTE
If a route does not
default value 100
takes effect.
AIGP - - The same.
AS_Path 100 10 200 10 The same length.
Origin IGP IGP The same.
MED - - The same.
Peer type EBGP IBGP Route 10.11.0.0/16

learned from ISP1 is
optimal.

The route selection process on Device B is the same as that on Device A. Then, Device A and
Device B advertise the optimal routes to Device C. Check the routing table of Device C.
[~DeviceC] display bgp routing-table

*>i 10.1.1.0/30 10.1.4.1 0 100 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.2.1 100 0 200 10i
* i 10.1.1.1 100 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 100 0 200 10i
* i 10.1.1.1 100 0 100 10i
The preceding command output shows that Device C selects the routes advertised by Device
B.
Check the reason why the routes learned from Device A are not selected on Device C. The
[~DeviceC] display bgp routing-table 10.11.0.0

From: 10.1.5.1 (192.168.2.2)
AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, best,

From: 10.1.4.1 (192.168.2.3)
The preceding command output shows that Device C selects the route 10.11.0.0/16 learned
from Device B because the router ID (192.168.2.2) of Device B is smaller than that
(192.168.2.3) of Device A. Table 10-15 shows the route attribute comparison of the routes
10.11.0.0/16 learned from Device A and Device B.

Table 10-15 Route attribute comparison of the routes 10.11.0.0/16 learned from Device A and
Device B
Local_Pref 100 100 The same.
AIGP - - The same.
AS_Path 100 10 200 10 The same length.
MED - - The same.
Peer type IBGP IBGP The same.
IGP cost - - The same.
Cluster_List - - The same length.
Router ID 192.168.2.3 192.168.2.2 Route 10.11.0.0/16

learned from Device
B is optimal.
Scenario 2: The administrator of AS 65001 requires that ISP1 be active and ISP2 be backup
for the traffic to 10.11.0.0/16 and 10.22.0.0/16.
To meet the preceding requirements, run the default local-preference command on Device A
to increase the Local_Pref values of the routes learned from Device A. This configuration
ensures that the routes learned from ISP1 are selected as the optimal routes. Detailed
configurations are as follows:
#
bgp 65001
#
ipv4-family unicast
default local-preference 120 //Set the Local_Pref of the routes
to be advertised to 120.
#



*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
# Display the routing table of Device B.
[~DeviceB] display bgp routing-table


*>i 10.1.1.0/30 10.1.3.1 0 120 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 0 200 10i
*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 0 200 10i
The preceding command output shows that Device B selects the routes learned from Device
A. Device B does not advertise the routes learned from ISP2 to its IBGP peers because those
routes are not selected.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Device B. The
[~DeviceB] display bgp routing-table 10.11.0.0

From: 10.1.3.1 (192.168.2.3)
10.1.2.1
From: 10.1.2.1 (192.168.2.4)
AS-path 200 10, origin igp, pref-val 0, valid, external, pre 255, not preferred
for Local_Pref
The preceding command output shows that the Local_Pref value of the route learned from
Device A is greater than that of the route learned from ISP2 and that the route learned from
Device A is selected as the optimal route. Table 10-16 shows the route attribute comparison
of the routes 10.11.0.0/16 learned from Device A and ISP2.

Table 10-16 Route attribute comparison of the routes 10.11.0.0/16 learned from Device A and
ISP2
from Device A from ISP2
Local_Pref 120 - Route 10.11.0.0/16

learned from Device
A is optimal.
NOTE
If a route does not
default value 100
takes effect.
# Display the routing table of Device C.


*>i 10.1.1.0/30 10.1.4.1 0 120 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i
Device C selects the routes advertised by ISP1 because Device B did not advertise the routes
learned from ISP2 to Device C.
Scenario 3: The requirements of the administrator of AS 65001 are as follows:
l ISP1 is active and ISP2 is backup for the traffic to 10.11.0.0/16.
l ISP2 is active and ISP1 is backup for the traffic to 10.22.0.0/16.
To meet the preceding requirements, ensure that AS 65001 selects the route 10.11.0.0/16
learned from Device A and the route 10.22.0.0/16 learned from Device B. Detailed

Figure 10-22 Local_Pref-based BGP route selection networking (1)
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
Set Local_Pref: EBGP EBGP Set Local_Pref:

120 for 10.11.0.0/16 Client Network 200 for 10.22.0.0/16
80 for 10.22.0.0/16 AS 65001 60 for 10.11.0.0/16
To: 11.0.0.0/8
DeviceA DeviceB
To: 22.0.0.0/8
To: 11.0.0.0/8 IBGP To: 22.0.0.0/8
IBGP IBGP
DeviceC
Best route
In this situation, different Local_Pref values are required for the routes learned from the same
ISP. Detailed configurations are as follows:
l Configurations on Device A
#
bgp 65001
#
ipv4-family unicast
peer 10.1.1.1 route-policy rp1 import //Apply import policy
named rp1 to the routes learned from 10.1.1.1 and use rp1 to modify the
Local_Pref.
#
route-policy rp1 permit node 10 //Define the first
node of rp1 and set the Local_Pref value of the route 10.11.0.0/16 to 80.
if-match ip-prefix reducepref
apply local-preference 80
#
route-policy rp1 permit node 20 //Define the second
if-match ip-prefix addpref
#
route-policy rp1 permit node 30 //Define the third
node of rp1 and allow rp1 to permit all routes.
#
ip ip-prefix addpref index 10 permit 10.11.0.0 16 //Configure an IP
prefix list to match the route 10.11.0.0/16.
ip ip-prefix reducepref index 10 permit 10.22.0.0 16 //Configure an IP


#
l Configurations on Device B
bgp 65001
#
ipv4-family unicast
peer 10.1.2.1 route-policy rp2 import //Apply import policy
named rp2 to the routes learned from 10.1.1.1 and use rp2 to modify the
Local_Pref.
#
route-policy rp2 permit node 10 //Define the first
if-match ip-prefix addpref
#
route-policy rp2 permit node 20 //Define the second
if-match ip-prefix reducepref
#
route-policy rp2 permit node 30 //Define the third
node of rp2 and allow rp2 to permit all routes.
#
ip ip-prefix addpref index 10 permit 10.22.0.0 16 //Configure an IP
ip ip-prefix reducepref index 10 permit 10.11.0.0 16 //Configure an IP
#


*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 200 0 200 10i
* 10.1.1.1 80 0 100 10i
# Display detailed information about the route 10.22.0.0/16 on Device A.


From: 10.1.3.2 (192.168.2.2)
10.1.1.1

From: 10.1.1.1 (192.168.2.5)

AS-path 100 10, origin igp, localpref 80, pref-val 0, valid, external, pre 255,
not preferred for Local_Pref
routing table of Device A and that the route with next hop address 10.1.2.1 is selected because
its Local_Pref (200) is greater than the Local_Pref (80) of the route with next hop address
10.1.1.1.
Table 10-17 shows the route attribute comparison of the routes 10.22.0.0/16 learned from
ISP1 and Device B.
Table 10-17 Route attribute comparison of the routes 10.22.0.0/16 learned from ISP1 and
Device B.
from ISP1 from Device B
Local_Pref 200 80 Route 10.22.0.0/16

learned from ISP1 is
optimal.
The route with next hop address 10.1.1.1 is not optimal, and therefore, it is not advertised to
Device B and Device C. In addition, the route 10.11.0.0/16 with next hop address 10.1.2.1 is
not optimal on Device B, and therefore, Device B does not advertise this route to Device A
and Device C. As a result, only one route 10.11.0.0/16 with next hop address 10.1.1.1 is
available in the BGP routing table of Device A.


*>i 10.1.1.0/30 10.1.3.1 0 100 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 60 0 200 10i
*> 10.22.0.0/16 10.1.2.1 200 0 200 10i
# Display detailed information about the route 10.11.0.0/16 on Device B.




From: 10.1.3.1 (192.168.2.3)
10.1.2.1
From: 10.1.2.1 (192.168.2.4)
AS-path 200 10, origin igp, localpref 60, pref-val 0, valid, external, pre 255,
routing table of Device B and that the route with next hop address 10.1.1.1 is selected because
its Local_Pref (120) is greater than the Local_Pref (60) of the route with next hop address
10.1.2.1. The route with next hop address 10.1.2.1 is not advertised to Device A and Device C
because it is not optimal.

*>i 10.1.1.0/30 10.1.4.1 0 100 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 200 0 200 10i
The preceding command output shows that the next hop address of the route 10.11.0.0/16 is
10.1.1.1 and that the next hop address of the route 10.22.0.0/16 is 10.1.2.1.
l ISP1 is active and ISP2 is backup for the traffic from Device A and Device C to
10.11.0.0/16 and 10.22.0.0/16.
l ISP2 is active and ISP1 is backup for the traffic from Device B to 10.11.0.0/16 and
10.22.0.0/16.
To meet the preceding requirements, ensure that Device A and Device C select the routes
learned from ISP1. Detailed configurations are as follows:

Figure 10-23 Local_Pref-based BGP route selection networking (2)
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
To: To:
10.11.0.0/16 EBGP EBGP
10.11.0.0/16
10.22.0.0/16 10.22.0.0/16
Client Network
AS 65001
IBGP
DeviceA DeviceB
To:
11.0.0.0/8
22.0.0.0/8
IBGP IBGP
DeviceC
Best route
You can perform either of the following operations:

l Configure an export policy on Device A to modify the Local_Pref of the routes to be
advertised to Device C.
l Configure an import policy on Device C to modify the Local_Pref of the routes learned
from Device A.
The configurations on Device A are used as an example. Detailed configurations are as
follows:
bgp 65001
#
ipv4-family unicast
default local-preference 120 //Set the Local_Pref of the routes
to be advertised to 120.



*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i


*>i 10.1.1.0/30 10.1.3.1 0 100 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*> 10.11.0.0/16 10.1.2.1 0 200 10i
* i 10.1.1.1 100 0 100 10i
*> 10.22.0.0/16 10.1.2.1 0 200 10i
* i 10.1.1.1 100 0 100 10i
The preceding command output shows that Device B selects the routes learned from ISP2.

*>i 10.1.1.0/30 10.1.4.1 0 120 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* i 10.1.2.1 100 0 200 10i
*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i
* i 10.1.2.1 100 0 200 10i
The preceding command output shows that Device C selects the routes learned from ISP1.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Device C. The

From: 10.1.4.1 (192.168.2.3)



From: 10.1.5.1 (192.168.2.2)
The preceding command output shows that Device C selects the routes learned from ISP1
because the Local_Pref of the routes learned from ISP1 is greater than that of the route
learned from ISP2.
The preceding examples show that the modification of the Local_Pref values affects not only
BGP route advertisement but also BGP route selection with an AS. We can configure
Local_Pref values as required to control the forwarding path of the traffic that leaves an AS.
10.36.4.4 Route Type

BGP prefers locally imported routes to the routes learned from peers during BGP route
selection.
BGP routes can be locally imported or learned from peers. The locally imported routes take
precedence over the routes learned from peers during BGP route selection. It is unusual for
locally imported routes and the routes learned from peers to carry the same destination IP
address and coexist in the routing table. Generally, locally imported routes can be the routes
imported using the network or import-route command and the automatically and manually
summarized routes. Precedences of these routes are described as follows:
1. Summarized routes take precedence over non-summarized routes.
2. Summarized routes that are manually generated using the aggregate command take
precedence over summarized routes that are automatically generated based on the
summary automatic command settings.
3. The routes imported using the network command take precedence over the routes
imported using the import-route command.
In Figure 10-24, Device A and Device B are EBGP peers, and Device B, Device C, and
Device D are IBGP peers.

Figure 10-24 Networking
AS 100 AS 65001
DeviceA DeviceB DeviceD
10.1.1.1/30 10.1.1.2/30 10.1.3.1/30
IBGP 10.1.3.2/30
10.1.2.1/30 10.1.4.1/30
IBGP IBGP
DeviceC
10.1.2.2/30 10.1.4.2/30
The configurations on Device C are as follows:

#
bgp 65001
#
ipv4-family unicast
network 10.1.2.0 255.255.255.252 //Advertise the route
10.1.2.0/30.
10.1.3.0/30.
import-route direct //Import direct routes.
#
The configurations on Device D are as follows:

#
bgp 65001
#
ipv4-family unicast
10.1.3.0/30.
10.1.4.0/30.
#
# Display the routing table of Device D.
[~DeviceD] display bgp routing-table


*>i 10.1.2.0/30 10.1.4.2 0 100 0 i

*> 10.1.3.0/30 0.0.0.0 0 0 i
* 0.0.0.0 0 0 ?
*> 10.1.3.2/32 0.0.0.0 0 0 ?
*> 10.1.4.0/30 0.0.0.0 0 0 i
* 0.0.0.0 0 0 ?
i 10.1.4.2 0 100 0 ?
*> 10.1.4.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?

The preceding command output shows that three routes 10.1.4.0/30 are available in the
routing table. The route with the next hop address 10.1.4.2 is learned from a peer (Device C).
Therefore, BGP first excludes this route from route selection.
[~DeviceD] display bgp routing-table 10.1.4.0 30

Network route.
From: 0.0.0.0 (0.0.0.0)
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, select, pre 0
10.1.3.1
10.1.4.2
Imported route.
From: 0.0.0.0 (0.0.0.0)
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, pre 0, not
preferred for route type

From: 10.1.4.2 (10.1.2.2)
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, internal, pre
255
The preceding command output shows that the route imported using the network command is
selected as the optimal route.
The configurations on Device B are as follows:
bgp 65001
#
ipv4-family unicast
summary automatic
aggregate 10.0.0.0 255.0.0.0
import-route direct
#



*> 10.0.0.0 127.0.0.1 0 ?

* 127.0.0.1 0 ?
s> 10.1.1.0/30 0.0.0.0 0 0 ?
*> 10.1.1.2/32 0.0.0.0 0 0 ?
s> 10.1.2.0/30 0.0.0.0 0 0 ?
i 10.1.2.2 0 100 0 i
*> 10.1.2.1/32 0.0.0.0 0 0 ?
s> 10.1.3.0/30 0.0.0.0 0 0 ?
i 10.1.3.2 0 100 0 i
*> 10.1.3.1/32 0.0.0.0 0 0 ?
*>i 10.1.4.0/30 10.1.3.2 0 100 0 i
* i 10.1.2.2 0 100 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
The preceding command output shows that two summarized routes 10.0.0.0 are available in
the routing table.

Aggregated route.
AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, active,
pre 255
Aggregator: AS 65001, Aggregator ID 10.1.1.2
10.1.1.1
10.1.3.2
10.1.2.2
Summary automatic route
AS-path Nil, origin incomplete, pref-val 0, valid, local, pre 255, not preferred
for route type
Aggregator: AS 65001, Aggregator ID 10.1.1.2
The preceding command output shows that the route generated using the aggregate command
is selected as the optimal route.
10.36.4.5 AIGP
The Accumulated Interior Gateway Protocol Metric (AIGP) attribute is an optional non-
transitive Border Gateway Protocol (BGP) path attribute. After the AIGP attribute is
configured in an AIGP administrative domain, BGP selects paths based on costs in the same
manner as an IGP, and all devices in the domain forward data along the optimal routes.
During BGP route selection, the AIGP attribute is used as follows:
l The priority of a route that carries the AIGP attribute is higher than the priority of a route
that does not carry the AIGP attribute.
l If two BGP routes both carry the AIGP attribute, the device selects the BGP route whose
AIGP value plus the cost of the IGP route to which the BGP route is iterated is smaller.

The AIGP attribute can be added to routes only through route-policies. You can configure an
apply clause for a route-policy using the apply aigp { cost | inherit-cost } command to
modify the AIGP value during BGP route import, acceptance, or advertisement. If no AIGP
value is configured, the IGP routes imported by BGP do not carry the AIGP attribute.
In Figure 10-25, OSPF runs in AS 65002, an EBGP peer relationship is established between
Device A and Device E and between Device B and Device E. Device A and Device B are
configured to import OSPF routes in AS 65002 and advertise the routes to AS 65001.
Figure 10-25 AIGP application networking
AS 65001
Device E
10.1.1.1/30 10.1.3.1/30
EBGP EBGP
10.1.1.2/30 10.1.3.2/30
Device A Device B
10.1.2.1/30 10.1.5.1/30
AS 65002
10.1.2.2/30 10.1.5.2/30
10.1.4.1/30
Device C 10.1.4.2/30 Device D
configurations. The route 10.1.4.0/30 is used in this example.

[~DeviceE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.1.2 2 0 65002?
* 10.1.3.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[~DeviceE] display bgp routing-table 10.1.4.0


From: 10.1.1.2 (10.1.1.2)
10.1.1.2
10.1.3.2
From: 10.1.3.2 (10.1.5.1)
The command output shows that Device E selects the route learned from Device A because
the AIGP attribute has not been configured and the router ID of Device A is smaller than that
of Device B. To change the route selection on Device E, perform the following operations to
configure the AIGP attribute.
Configurations on Device A:
#
bgp 65002
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy //Apply route-policy
named aigp_policy to locally imported OSPF routes and use aigp_policy to modify
the AIGP value.
#
route-policy aigp_policy permit node 10 //Define the first node
of aigp_policy and set the AIGP value of the route 10.1.4.0/30 to 10.
apply aigp 10
#
route-policy aigp_policy permit node 20 //Define the second node
of aigp_policy and allow aigp_policy to permit all routes.
#
#
Configurations on Device B:
bgp 65002
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy1 //Apply route-policy
named aigp_policy1 to locally imported OSPF routes and use aigp_policy1 to modify
the AIGP value.
#
route-policy aigp_policy1 permit node 10 //Define the first node
of aigp_policy1 and set the AIGP value of the route 10.1.4.0/30 to 5.

apply aigp 5
#
route-policy aigp_policy1 permit node 20 //Define the second node
of aigp_policy1 and allow aigp_policy1 to permit all routes.
#
#
Configurations on Device E:
#
bgp 65001
#
ipv4-family unicast
#
configurations.

[~DeviceE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.3.2 2 0 65002?
* 10.1.1.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[~DeviceE] display bgp routing-table 10.1.4.0

From: 10.1.3.2 (10.1.5.1)
select, active, pre 255, AIGP 5
10.1.1.2
10.1.3.2
From: 10.1.1.2 (10.1.1.2)
AIGP 10, not preferred for AIGP

The preceding command output shows that Device E selects the route 10.1.4.0/30 learned
from Device B because its AIGP value is smaller than that of the route learned from Device
A.
Table 10-18 shows the attribute comparison of the routes 10.1.4.0/30 learned from Device A
and Device B.
Table 10-18 Attribute comparison of the routes 10.1.4.0/30 learned from Device A and
Device B.
AIGP 10 5 The different.
10.36.4.6 AS_Path
BGP prefers the route with the shortest AS_Path length (the number of included ASs) during
BGP route selection.
Four types of AS_Path attributes are available:
l AS_Sequence: records in reverse order all the ASs through which a route passes from the
local device to the destination.
l AS_Set: records in random order all the ASs through which a route passes from the local
device to the destination. The AS_Set attribute is used in route summarization scenarios.
l AS_Confed_Sequence: records in reverse order all the sub-ASs within a BGP
confederation through which a route passes from the local device to the destination.
l AS_Confed_Set: records in random order all the sub-ASs within a BGP confederation
through which a route passes from the local device to the destination.
Table 10-19 describes the AS_Path-based route selection rules.

Table 10-19 AS_Path-based route selection rules

Item Description
AS_Set BGP takes an AS_Set as one AS number even if the

AS_Set contains multiple AS numbers.
When the aggregate (BGP) command is configured to
generate a manually summarized route, if as-set is
specified in the command, AS_Set will be carried in the
summarized route. The information in the AS_Set is as
follows:
l If the routes used in the summarization carry the same
AS_Sequence, this AS_Sequence is carried in the
summarized route, and the AS_Set of the summarized
route is null.
l If the routes used in the summarization carry different
AS_Sequences, all the AS numbers carried in the
AS_Sequences are included in the AS_Set of the
summarized route.
AS_Confed_Sequence and BGP ignores AS_Confed_Sequence and AS_Confed_Set

AS_Confed_Set when calculating the AS_Path length.
bestroute as-path-ignore After the command is configured, BGP does not compare
the AS_Path attribute during route selection.
apply as-path The command can be run to configure an apply clause for
a route-policy so that the ASs in the AS_Path of the route
that matches the route-policy are cleared or replaced, or
new ASs are added.
NOTE
The configuration of the apply as-path command may change
the traffic forwarding path, or cause routing loops or route
selection errors. Therefore, exercise caution when configuring the
command.
peer public-as-only After the command is configured, BGP deletes private AS

numbers (if any) from the AS_Path attribute before
sending Update packets. Private AS numbers range from
64512 to 65534.
NOTE
If the 4-byte private AS number function is enabled using the
private-4-byte-as enable command, private AS numbers range
from 64512 to 65534 and from 4200000000 to 4294967294
(64086.59904 to 65535.65534 in the format of x.y).

Item Description
peer fake-as After the command is configured, BGP can use a fake AS
number to set up a BGP peer relationship.
If the local device uses the actual AS number to establish
an EBGP peer relationship with a remote device, the
actual AS number is carried in the AS_Path of the route
sent to the remote device. If the local device uses the fake
AS number to establish the EBGP peer relationship, the
fake AS number is carried in the AS_Path of the route sent
to the remote device.
peer substitute-as If the command is configured and an AS in the AS_Path

carried in the route sent by a PE to the CE of the specified
peer is the same as the AS of the CE, the PE replaces the
AS with the local AS.
NOTE
The peer substitute-as command applies only to PEs in BGP
MPLS IP/VPN scenarios and may cause routing loops if it is
improperly configured. Therefore, exercise caution when using
the command.
During BGP route selection, BGP compares the AS_Path length by calculating the number of
ASs included in the AS_Sequence if AS_Sequence is carried in a route. If both AS_Sequence
and AS_Set are carried in the route, BGP considers the AS_Path length to be the number of
ASs included in the AS_Sequence plus 1.
Deleting Private AS Numbers

As public AS resources are limited, carriers generally use private AS numbers when
deploying VPNs. Private AS numbers, however, must not be advertised to the Internet
because they may cause routing loops. In Figure 10-26, both ISP1 and ISP2 use 65001 as a
private AS number.
Figure 10-26 Networking in which a private AS needs to be deleted
On B: peer C public-as-only
ISP1 ISP2
AS 65001 AS 100 AS 200 AS 65001
10.0.0.0/8
Device A Device B Device C Device D
Update Update
10.0.0.0/8 10.0.0.0/8
AS_Path: 65001 AS_Path: 100
In Figure 10-26, Device A advertises the route 10.0.0.0/8 to Device D through ISP1 and
ISP2. After receiving this route, Device D checks its AS_Path. This AS_Path carries AS
65001, which is the same as the AS of Device D. As a result, Device D discards this route.

To address this problem, run the peer public-as-only command on Device B so that Device B
deletes AS 65001 before adding AS 100 (public AS) to the AS_Path and forwarding the route
to Device C.
In the following situations, after the peer public-as-only command is configured, BGP does
not delete any private AS number from the AS_Path:
l The AS_Path of a route carries the AS number of the remote peer. In this case, deleting
private AS numbers may lead to a routing loop.
l The AS_Path carries both public and private AS numbers, which indicates that the route
has passed through the public network. In this case, deleting private AS numbers may
lead to incorrect traffic forwarding.
The preceding limitations also apply to confederation scenarios.
Adding AS Numbers
In Figure 10-27, AS 65005 imports three routes and advertises them to AS 65001 through
two paths.
Figure 10-27 Networking in which new AS numbers are added to the AS_Path
AS 65002
AS 65004
10.1.2.2/30
10.1.1.2/30 10.1.2.1/30 10.1.4.1/30
DeviceB DeviceD
10.1.4.2/30
10.1.1.1/30
AS 65005
172.16.1.0/24
AS 65001 DeviceA DeviceE
172.16.2.0/24
10.1.5.2/30
172.16.3.0/24
10.1.3.1/30 DeviceC
10.1.3.2/30 10.1.5.1/30
AS 65003
BGP
Update


*> 172.16.1.0/24 10.1.3.2 0 65003 65005?

* 10.1.1.2 0 65002 65004

65005?
*> 172.16.2.0/24 10.1.3.2 0 65003 65005?
* 10.1.1.2 0 65002 65004
65005?
*> 172.16.3.0/24 10.1.3.2 0 65003 65005?
* 10.1.1.2 0 65002 65004
65005?

From: 10.1.3.2 (10.1.5.1)
AS-path 65003 65005, origin incomplete, pref-val 0, valid, external, best,
10.1.3.2
10.1.1.2
From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, pre
255, not preferred for AS-Path
The preceding command output shows that Device A selects the route learned from Device C
because this route has a shorter AS_Path length than that learned from Device B. To enable
Device A to select the route learned from Device B, configure Device B to reduce the
AS_Path length of the route or configure Device C to increase the AS_Path length of the
route. In the following example, Device C is configured to increase the AS_Path length of the
route. The detailed configurations on Device C are as follows:
#
bgp 65003
#
ipv4-family unicast
undo synchronization
peer 10.1.3.1 route-policy add_asn export //Apply export policy
named add_asn to routes to be advertised to 10.1.3.1.
#
route-policy add_asn permit node 10 //Define the first node
of add_asn.
if-match ip-prefix prefix1 //Configure IP prefix
list named prefix1.
apply as-path 65003 65003 65003 additive //Add 65003, 65003, 65003
to the AS_Path of the route that matches prefix1.
#
route-policy add_asn permit node 20 //Define the second node
of add_asn to permit all other routes.
#
ip ip-prefix prefix1 index 10 permit 172.16.1.0 24 //Define the first index
of prefix1 to match the route 172.16.1.0/24.
ip ip-prefix prefix1 index 20 permit 172.16.2.0 24 //Define the second index
ip ip-prefix prefix1 index 30 permit 172.16.3.0 24 //Define the third index
#




*> 172.16.1.0/24 10.1.1.2 0 65002 65004

65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?
*> 172.16.2.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?
*> 172.16.3.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?

From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best,
10.1.3.2
10.1.1.2
From: 10.1.3.2 (10.1.5.1)
AS-path 65003 65003 65003 65003 65005, origin incomplete, pref-val 0, valid,
external, pre 255, not preferred for AS-Path
The preceding command output shows that the AS_Path length of the route learned from
Device B is shorter than that of the route learned from Device C and that the route learned
from Device B is selected as the optimal route. Table 10-20 shows the attribute comparison of
the routes 172.16.1.0 learned from Device B and Device C.
Table 10-20 Attribute comparison of the routes 172.16.1.0 learned from Device B and Device
C

from Device B from Device C


AIGP - - The same.
AS_Path 65002 65004 65005 65003 65003 65003 The route learned
65003 65005 from Device B is
optimal.
AS numbers can be added to the AS_Path as required. However, if an AS number is added to

the AS_Path of a route, the route cannot be received by devices in this AS. Therefore, the
local AS number is added in most cases. For example in Figure 10-27, if Device C adds AS
65001 to the AS_Path of a route before advertising the route to Device A, Device A will
discard the route upon receipt because the route carries Device A's AS number.
Replacing AS Numbers
When the apply as-path command is configured, if overwrite is specified in the command,
the device will replace the AS numbers in the original AS_Path attribute to achieve the
following goals:
l Hide the actual path information.
l Prevent a route from being discarded by replacing the AS_Path of the route with a
shorter one if the as-path-limit command is configured on the device that receives this
route.
l Reduce the AS_Path length.
AS number replacement can also be used for the purpose of load balancing. For example in
Figure 10-27, the apply as-path 65002 65004 65005 overwrite command can be configured
on Device A to replace the AS_Path of the route learned from Device C so that the route has
the same AS_Path as that of the route learned from Device B, and the two routes are used to
load-balance traffic. Detailed configurations on Device A are as follows:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.2 route-policy replace_asn import //Apply export policy
named replace_asn to routes to be advertised to 10.1.3.1.
#
route-policy replace_asn permit node 10 //Define the first node
of replace_asn.
if-match as-path-filter filter1 //Configure AS_Path
filter named filter1.
apply as-path 65002 65004 65005 overwrite //Replace the AS_Path of
the route that matches filter1 with 65002, 65004, 65005.
#
route-policy replace_asn permit node 20 //Define the second node
of replace_asn to permit all other routes.
#
ip as-path-filter filter1 permit ^65003 //Define AS_Path filter
named filter1 to match all the routes learned from AS 65003.
#




*> 172.16.1.0/24 10.1.1.2 0 65002 65004

65005?
* 10.1.3.2 0 65002 65004
65005?
*> 172.16.2.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65002 65004
65005?
*> 172.16.3.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65002 65004
65005?
The preceding command output shows that the AS_Path of the route received from AS 65003
has been replaced, after which the routes received from AS 65002 and AS 65003 have the
same AS_Path. Run the maximum load-balancing 2 command on Device A to set the
maximum number of routes for load balancing to 2. Then, check the detailed route
information. The route 172.16.1.0/24 is used in the following example:

From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best,
10.1.1.2
10.1.3.2
From: 10.1.3.2 (10.1.5.1)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external,
select, active, pre 255, not preferred for router ID
The preceding command output shows that the route learned from Device B is optimal and is
used along with the route learned from Device C (not optimal) for load balancing. Check the
information about the route 172.16.1.0/24 in the IP routing table.
[~DeviceA] display ip routing-table
------------------------------------------------------------------------------
Routing Tables: _Public_

10.1.1.0/30 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/30 Direct 0 0 D 10.1.3.1
10.1.3.1/32 Direct 0 0 D 127.0.0.1
172.16.1.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2
172.16.2.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2
172.16.3.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2
The preceding command output shows that BGP has delivered the two routes with the same
route prefix to the IP routing table for load balancing.
Clearing the AS_Path

When the apply as-path command is configured, if none overwrite is specified in the
command, the device clears the AS_Path to hide the actual path information. If the AS_Path
is null, BGP considers its length as 0 during route selection.
10.36.4.7 Origin
The Origin attribute indicates how routes become BGP routes.
Three types of Origin attributes are available:

l IGP: indicates that routes are added to the BGP routing table using the network
command. IGP has the highest priority.
l EGP: indicates that routes are learned through the EGP protocol. EGP has the second
highest priority.
NOTE
The NE40E can receive and send BGP routes with EGP as the Origin. However, the NE40E does
not support the EGP protocol; therefore, to set the Origin of routes to EGP, you need to run the
apply origin { egp { as-number-plain | as-number-dot } | igp | incomplete } command to
configure an apply clause for a route-policy.
l Incomplete: indicates that routes are added to the BGP routing table using the import-
route command. Incomplete has the lowest priority.
The routes imported using the network command are more specific than those imported using
the import-route command. Therefore, IGP takes precedence over Incomplete in route
selection. In Figure 10-28, Device A and Device B are EBGP peers, and Device B, Device C,
and Device D are IBGP peers.

Figure 10-28 Networking diagram with Origin configurations
AS 100 AS 65001
Device A Device B Device D
10.1.1.1/30 10.1.1.2/30 10.1.3.1/30
IBGP 10.1.3.2/30
10.1.2.1/30 10.1.4.1/30
IBGP IBGP
Device C
10.1.2.2/30 10.1.4.2/30
The configurations on Device D are as follows:

#
bgp 65001
#
ipv4-family unicast
10.1.4.0/30.
#
The configurations on Device C are as follows:

#
bgp 65001
#
ipv4-family unicast
#


i 10.1.2.0/30 10.1.2.2 0 100 0 ?

*>i 10.1.4.0/30 10.1.3.2 0 100 0 i
* i 10.1.2.2 0 100 0 ?
The preceding command output shows that two active routes 10.1.4.0/30 are available in the
routing table.

From: 10.1.3.2 (10.1.3.2)


best, select, active, pre 255
10.1.1.1
From: 10.1.2.2 (10.1.2.2)
internal, pre 255, not preferred for Origin
The preceding command output shows that the route learned from Device D is selected
because it is imported using the network command and its Origin priority is higher than that
of the route learned from Device C. Table 10-21 describes the attribute comparison of the
routes learned from Device C and Device D.
Table 10-21 Attribute comparison of the routes learned from Device C and Device D
from Device C from Device D
AIGP - - The same.
AS_Path - - The same length.
Origin Incomplete IGP The route learned

from Device D is
optimal.
The Origin attribute can be modified using a route-policy. In the following example, a route-
policy is configured on Device B to modify the Origin attribute, and the detailed
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.2 route-policy for_d import //Apply import policy
named for_d to the routes learned from 10.1.3.2 and use for_d to modify the
Origin value.
#
route-policy for_d permit node 10 //Define the route-policy
named for_d.
apply origin incomplete //Set the Origin type to
Incomplete.



i 10.1.2.0/30 10.1.2.2 0 100 0 ?

*>i 10.1.4.0/30 10.1.2.2 0 100 0 ?
* i 10.1.3.2 0 100 0 ?
The preceding command output shows that the route learned from Device C becomes the
optimal route.

From: 10.1.2.2 (10.1.2.2)
internal, best, select, active, pre 255
10.1.1.1
From: 10.1.3.2 (10.1.3.2)
internal, pre 255, not preferred for router ID
The preceding command output shows that the route learned from Device C becomes the
optimal route because it has a smaller router ID than the route learned from Device D. Table
10-22 shows the attribute comparison of the routes learned from Device C and Device D.

AIGP - - The same.
AS_Path - - The same.
Origin Incomplete Incomplete The same.


MED 0 0 The same.
Cluster_List - - The same.
Router ID 10.1.2.2 10.1.3.2 The route learned

from Device C is
optimal.
10.36.4.8 MED
MED attributes of routes can be configured as required to control traffic forwarding path for
the purpose of load balancing.
The MED attribute is transmitted only within an AS or between two neighboring ASs. The
AS that receives the MED attribute does not advertise it to a third AS.
Similar to the cost used by an IGP, the MED is used to determine the optimal route when
traffic enters an AS. When a BGP peer learns multiple routes that have the same destination
address but different next hop addresses from EBGP peers, the route with the smallest MED
value is selected as the optimal route if all the other attributes are the same.
Table 10-23 lists three methods used to modify the MED value.
Table 10-23 Methods to modify the MED value

Run the default med command. This method sets a default MED for all the
routes that the local device advertises to its
BGP peers. The default med command
takes effect only with the routes imported
locally using the import-route command
and BGP summarized routes.
Configure an import or export policy and This method sets different MED values for
run the apply cost command to configure an different routes advertised by the local
apply clause for the policy. device to its EBGP peers.
Configure an export policy and run the This method enables a device to set MED
apply cost-type internal command to values for the BGP routes that are learned
configure an apply clause for the export from IBGP peers and to be advertised to
policy. EBGP peers and match the export policy to
the costs of the IGP routes to which the
BGP routes are iterated.
The major points about MED attributes that require consideration are as follows:

l If routes are received from different ASs, traffic will be sent to different ASs. In addition,
BGP selects the optimal route only from the routes destined for the same address.
Therefore, BGP only compares the MEDs of routes that are from the same AS
(excluding confederation sub-ASs). MEDs of two routes are compared only if the
leftmost AS number in the AS_Sequence (excluding AS_Confed_Sequence) of one route
is the same as its counterpart in the other route.
l If the compare-different-as-med command is run, BGP compares MEDs of routes even
when the routes are received from peers in different ASs. Do not run this command
unless the ASs use the same IGP and route selection mode. Otherwise, a routing loop
may occur.
l If a route does not carry MED, BGP uses the default value (0) as the MED of the route
during route selection. If the bestroute med-none-as-maximum command is run, BGP
considers the largest MED value (4294967295) to be the MED of the route. After route
selection is complete, the MED is restored to the original value.
l After the bestroute med-confederation command is configured, BGP compares the
MEDs of routes only when the AS_Path attributes of the routes carry no external AS
numbers (ASs that do not belong to the confederation) and the leftmost AS numbers in
each AS_Confed_Sequence are the same.
l After the deterministic-med command is configured, routes will not be selected in the
same sequence they are received.
In Figure 10-29, ISP1 and ISP2 can learn the route 1.1.1.9/32 from Device C or Device D.

Figure 10-29 Networking diagram for MED applications
Internet
ISP1 ISP2
AS 100 AS 200
10
Device A Device B
0
.1
3
1/
.3
.
.1
.4
10.1.1.1/30 /3 10.1.2.1/30
.1
0
10
EBGP EBGP
10
. 1.
0
3
/3
.2
2
Client Network /3
4.
0
.
.1
10.1.1.2/30 AS 65001 10.1.2.2/30

10
10.1.5.1/30
Device C Device D
IBGP 10.1.5.2/30
10.1.6.1/30 10.1.7.1/30
IBGP 1.1.1.9/32 IBGP

10.1.6.2/30 10.1.7.2/30
Device E
Scenario 1: Check the BGP routing tables of Device A and Device B before Device C and
Device D are configured to modify the MED of the route 1.1.1.9/32.


*> 1.1.1.9/32 10.1.1.2 0 65001i

* 10.1.3.2 0 65001i



*> 1.1.1.9/32 10.1.4.2 0 65001i

* 10.1.2.2 0 65001i
The preceding command output shows that both ISP1 and ISP2 select the route learned from
Device C as the optimal route. As a result, Device C and Device D cannot load-balance the
traffic from ISP1 or ISP2 to 1.1.1.1/32.
Run the display bgp routing-table ip-address command on Device B to check the reason
why Device B chooses the route learned from Device C.

From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
10.1.2.2
10.1.4.2
From: 10.1.2.2 (10.1.2.2)
AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred
for router ID
The preceding command output shows that Device B selects the route learned from Device C
because the router ID (10.1.1.2) of Device C is smaller than that (10.1.2.2) of Device D.
Table 10-24 describes the attribute comparison of the routes learned from Device C and
Device D.

AIGP - - The same.
AS_Path 65001 65001 The same length.
MED - - The same.
Peer type EBGP EBGP The same.


Cluster_List - - The same length.
Router ID 10.1.1.2 10.1.2.2 The route learned

from Device C is
optimal.

l For the traffic from ISP1 to 1.1.1.9/32, the link Device A -> Device C is active and the
link Device A -> Device D is backup.
l For the traffic from ISP2 to 1.1.1.9/32, the link Device B -> Device D is active and the
link Device B -> Device C is backup.
To meet the preceding requirements, ensure that ISP1 selects the route learned from Device C
and that ISP2 selects the route learned from Device D. Figure 10-30 shows the networking in
which MED is used to control route selection.
Figure 10-30 Networking diagram for MED applications
Internet
ISP1 ISP2
AS 100 AS 200
Device A Device B
Set MED: EBGP EBGP Set MED:

100 for 1.1.1.9/32 to 200 for 1.1.1.9/32 to
ISP2 ISP1
Client Network
AS 65001
Device C Device D
IBGP
To: 1.1.1.9/ To: 1.1.1.9/
32 32
1.1.1.9/32
IBGP IBGP
Device E
Best route

Configure route-policies to set different MED values for the routes learned from different
peers. Detailed configurations are as follows:
l Configurations on Device C:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.4.1 route-policy addmed100 export //Apply export policy
named addmed100 to the routes to be advertised to 10.1.4.1 and use addmed100
to modify the MED value.
#
route-policy addmed100 permit node 10 //Define the first
node of addmed100 and set the MED of the route 1.1.1.9/32 to 100.
if-match ip-prefix p1
apply cost 100
#
route-policy addmed100 permit node 20 //Define the second
node of addmed100 to allow addmed100 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32 //Configure an IP
l Configurations on Device D:
NOTE
The following configurations are intended to ensure that Device A selects the route learned from
Device C. However, Device A has already selected the route learned from Device C because the
router ID of Device C is smaller than that of Device D. Therefore, the following configurations on
Device D are optional.
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.1 route-policy addmed200 export //Apply export policy
named addmed200 to the routes to be advertised to 10.1.3.1 and use addmed200
to modify the MED value.
#
route-policy addmed200 permit node 10 //Define the first
node of addmed200 and set the MED of the route 1.1.1.9/32 to 200.
if-match ip-prefix p1
apply cost 200
#
route-policy addmed200 permit node 20 //Define the second
node of addmed200 to allow addmed200 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32 //Configure an IP
Run the display bgp routing-table [ ip-address ] command to check the configurations. Use
Device B as an example.




*> 1.1.1.9/32 10.1.2.2 0 65001i

* 10.1.4.2 100 0 65001i
# Display detailed information about the route 1.1.1.9/32 on Device B.

[~DeviceB] display bgp routing-table 1.1.1.9 32

From: 10.1.2.2 (10.1.2.2)
AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
10.1.2.2
10.1.4.2
From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, pre 255, not
preferred for MED
routing table of Device B and that only the route with next hop address 10.1.2.2 is selected as
the optimal route.
Table 10-25 describes the attribute comparison of the routes learned from Device C and
Device D.
AIGP - - The same.


MED 100 - The route learned

from Device D
carries no MED
value, and therefore,
the default value (0)
is used.
The route learned
from Device D is
optimal.
Figure 10-30 shows that the route learned from Device D does not carry the MED value.
During route selection, BGP uses the default value (0) as the MED of the route. Therefore,
this route is selected as the optimal route. To change the route selection result on Device B,
run the bestroute med-none-as-maximum command on Device B. Detailed configurations
are as follows:


*> 1.1.1.9/32 10.1.4.2 100 0 65001i

* 10.1.2.2 0 65001i

From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, best, select,
active, pre 255
10.1.2.2
10.1.4.2
From: 10.1.2.2 (10.1.2.2)
AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred
for MED
routing table of Device B. The MED of the route with the next hop address 10.1.4.2 is 100,
and the MED of the route with the next hop address 10.1.2.2 is considered as 4294967295

because it carries no MED. Therefore, the route with the next hop address 10.1.4.2 is selected
as the optimal route.
In addition, BGP selects routes in the same sequence they are received. Therefore, the route
selection result is relevant to the sequence in which the routes are received. For example, the
following three BGP routes are available on a device:
l Route A1: AS_Path { 65001 200 }, med 100, igp cost 13, internal, Router id 4.4.4.4
l Route A2: AS_Path { 65001 100 }, med 150, igp cost 11, internal, Router id 5.5.5.5
l Route B: AS_Path { 65002 300 }, med 0, igp cost 12, internal, Router id 6.6.6.6
If the compare-different-as-med (BGP) command is run, route B is the optimal route,
regardless of the sequence in which the routes are received. If the compare-different-as-med
(BGP) command is not configured, BGP does not compare the MED values of routes learned
from different ASs. The route selection is described in the following cases:
l Case 1: Route A1 is received first, followed by route B, and then route A2.
– BGP first compares route A1 and route B. The leftmost AS number in the AS_Path
of route A1 is 65001, which is different from its counterpart in route B (65002).
Therefore, BGP does not compare the MED values, and prefers route B to route A1
because the IGP cost (12) of route B is smaller than that of route A1 (13).
– BGP then compares route A2 and route B. The leftmost AS number in the AS_Path
Therefore, BGP does not compare the MED values, and selects route A2 as the
optimal route because its IGP cost (11) is smaller than that of route B (12).
l Case 2: Route A2 is received first, followed by route B, and then route A1.
Therefore, BGP does not compare the MED values and prefers route A2 to route B
because the IGP cost (11) of route A2 is smaller than that of route B (12).
– BGP then compares route A1 and route A2. The leftmost AS number in the
AS_Path of route A1 is the same as its counterpart in route A2 (65001). In this
situation, BGP selects route A1 as the optimal route because its MED value (100) is
smaller than that of route A2 (150).
l Case 3: If the deterministic-med command is run, BGP groups the routes that are
learned from different ASs but are destined for the same network segment based on the
leftmost AS number in the AS_Path, selects one optimal route from each group, and then
compares the optimal routes of all the groups. Detailed steps are as follows:
– BGP first compares route A1 and route A2. The leftmost AS number in the
AS_Path of route A1 is the same as its counterpart in route A2 (65001). In this
situation, BGP selects route A1 as the optimal route because its MED value (100) is
smaller than that of route A2 (150).
Therefore, BGP does not compare the MED values and selects route B as the
optimal route because the IGP cost (12) of route B is smaller than that of route A1
(13).
Case 1 and case 2 show that the route selection result is relevant to the sequence in which
routes are received if the deterministic-med is not configured. Case 3 shows that the route
selection result is irrelevant to the sequence in which routes are received if the deterministic-
med is configured.

10.36.4.9 Peer Type

When IBGP routes (routes learned from IBGP peers) and EBGP routes (routes learned from
EBGP peers) are available, BGP preferentially selects EBGP routes.
When one EBGP route and multiple IBGP routes are available, BGP selects the optimal route
based on the peer type. If no EBGP route is available or multiple EBGP routes are available,
BGP is unable to select the optimal route based on the peer type.
When multiple egress devices reside on a carrier network and receive routes from the Internet,
the egress devices select the optimal route based on the peer type in most cases. In Figure
10-31, all devices reside in the same AS, Device A and Device B function as egress devices
and are IBGP peers of all devices in the AS. In addition, Device A and Device B receive
routes from the Internet and advertise EBGP routes to all their IBGP peers. Therefore, Device
A and Device B have an IBGP route and an EBGP route, and the two routes have the same
AS_Path. In this situation, Device A and Device B select the EBGP route as the optimal
route.
Figure 10-31 Peer type application networking
Internet
EBGP EBGP
Device A Device B
IBGP
The EBGP route is selected as the optimal route, which prevents the traffic that leaves Device
A or Device B for the Internet from being forwarded to the other egress device.
For more peer type-based route selection examples, see 10.36.4.3 Local_Pref.
10.36.4.10 IGP Cost

BGP prefers the route with the smallest IGP cost during BGP route selection.
This rule helps BGP to choose the route with the smallest cost to its iterated next hop address
quickly. If the bestroute igp-metric-ignore command is configured, BGP does not compare
the IGP cost. In Figure 10-32, OSPF runs in AS 65001, an EBGP peer relationship is
established between Device E and Device A and between Device E and Device B, and an
IBGP peer relationship is established between Device A and Device C, between Device A and

Device D, between Device B and Device C, and between Device B and Device D; Device E is
configured to import routes (1.1.1.9/32 for example) from AS 100 to BGP.
Figure 10-32 Networking diagram with IGP cost configurations
ISP
AS 100
1.1.1.9/32
10.1.5.2/30 10.1.6.2/30
EBGP DeviceE EBGP

10.1.5.1/30 10.1.6.1/30
10.1.4.1/30
DeviceA 10.1.4.2/30 DeviceB
10.1.3.2/30 10.1.2.2/30
AS 65001
10.1.3.1/30 10.1.2.1/30
10.1.1.1/30
DeviceC 10.1.1.2/30 DeviceD
Run the display bgp routing-table [ ip-address ] command on Device C and Device D to
check the configurations. Device C is used as an example.


*>i 1.1.1.9/32 10.1.5.2 0 100 0 100i

* i 10.1.6.2 0 100 0 100i
*>i 10.1.5.0/30 10.1.3.2 0 100 0 i
*>i 10.1.6.0/30 10.1.2.2 0 100 0 i
The preceding command output shows that two routes 1.1.1.9/32 are available in the routing
table of Device C and that Device C selects the route learned from Device A.

From: 10.1.3.2 (2.2.2.9)


AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, active, pre 255

From: 10.1.2.2 (10.1.2.2)
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 2, not preferred for IGP cost
The preceding command output shows that the route with next hop address 10.1.6.2 is ignored
because its IGP cost is larger than that of the other route. Table 10-26 describes the attribute
comparison of the routes learned from Device A and Device B.
Table 10-26 Attribute comparison of the routes learned from Device A and Device B.
AIGP - - The same.
MED 0 0 The same.


IGP cost - 2 The route learned

from Device A is
optimal.
NOTE
If a BGP route carries
no IGP cost value,
BGP considers its
IGP cost to be 0. If
no IGP routes are
used during BGP
peer relationship
establishment or the
costs of used IGP
routes are 0, the IGP
cost is not displayed
in the display bgp
routing-table ip-
address command
output.
10.36.4.11 Cluster_List
BGP prefers the route with the shortest Cluster_List length during BGP route selection.
An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a
Cluster_ID.
Similar to an AS_Path, a Cluster_List is composed of a series of Cluster_IDs and is generated
by an RR. The Cluster_List records all the RRs through which a route passes.
l Before an RR reflects a route between its clients or between its clients and non-clients,
the RR adds the local Cluster_ID to the leftmost position of the Cluster_List. If a route
does not carry any Cluster_List, the RR creates one for the route.
l After the RR receives an updated route, it checks the Cluster_List of the route. If the RR
finds that its cluster ID is included in the Cluster_List, the RR discards the route. If its
cluster ID is not included in the Cluster_List, the RR adds its cluster ID to the
Cluster_List and then reflects the route.
The following example shows how Cluster_List is used in BGP route selection. In Figure
10-33, an IBGP peer relationship is established between each two neighboring devices in AS
65001. Device B functions as a level-1 RR, and Device D is its client. Device D functions as a
level-2 RR, and Device E is its client. Device C functions as an RR, and Device E is its client.
Device E is configured to import the route 1.1.1.9/32 to BGP.

Figure 10-33 Networking diagram with Cluster_List configurations
Cluster2 Cluster1
RR2 RR1
10.1.2.1/30 10.1.2.2/30
10.1.1.2/30 10.1.4.1/30
DeviceB DeviceD
10.1.1.1/30
10.1.4.2/30
1.1.1.9/32
AS 65001
DeviceA DeviceE
10.1.5.2/30
10.1.3.1/30
DeviceC
10.1.3.2/30 10.1.5.1/30
RR3 BGP Update
Cluster3
Run the display bgp routing-table [ ip-address ] command on Device A to check the
configurations.


*>i 1.1.1.9/32 10.1.5.2 0 100 0 i

* i 10.1.4.2 0 100 0 i
table of Device C and that Device A selects the route learned from Device C.

From: 10.1.3.2 (2.2.2.9)
best, select, active, pre 255, IGP cost 3
Originator: 1.1.1.9

From: 10.1.1.2 (10.1.2.1)


AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 3, not preferred for Cluster List
Originator: 1.1.1.9
Cluster list: 0.0.0.2, 0.0.0.1
The preceding command output shows that the route learned from Device B is ignored
because its Cluster_List is longer than that of the route learned from Device C. Table 10-27
describes attribute comparison of the routes learned from Device B and Device C.
Table 10-27 Attribute comparison of the routes learned from Device B and Device C
AIGP - - The same.
MED 0 0 The same.
IGP cost 3 3 The same.
Cluster_List 0.0.0.2, 0.0.0.1 0.0.0.3 The route learned

from Device C is
optimal.
In most cases, BGP does not advertise the routes learned from an AS to the AS again. When
RRs are deployed, such routes may be advertised to the AS again although routing loops may
occur. Using the Cluster_List attribute can prevent such routing loops.
10.36.4.12 Originator_ID
If routes carry the Originator_ID, the originator ID is substituted for the router ID during
route selection. The route with the smallest Originator_ID is preferred.
The Originator_ID attribute is four bytes long and is generated by an RR. It carries the router
ID of the route originator in the local AS.
l When a route is reflected by an RR for the first time, the RR adds the Originator_ID to
this route. If a route already carries the Originator_ID attribute, the RR does not create a
new one.

l After receiving the route, a BGP speaker checks whether the Originator_ID is the same
as its router ID. If Originator_ID is the same as its router ID, the BGP speaker discards
this route.
The following example shows how Originator_ID is used during BGP route selection. In
Figure 10-34, an IBGP peer relationship is established between each two neighboring devices
in AS 65001. The router IDs of Device B and Device C are 2.2.2.9 and 3.3.3.9, respectively,
and they function as RRs. Device D is a client of Device B, and Device E is a client of Device
C. Device D and Device E are configured to import the route 10.1.4.0/30 to BGP.
Figure 10-34 Networking diagram with Originator_ID configurations
Cluster2
RR2
10.1.2.1/30 10.1.2.2/30
10.1.1.2/30 10.1.4.2/30
DeviceB DeviceD
10.1.1.1/30
10.1.4.1/30
AS 65001
DeviceA DeviceE
10.1.5.2/30
10.1.3.1/30
DeviceC
10.1.3.2/30 10.1.5.1/30
RR3 BGP Update
Cluster3
Run the display bgp routing-table [ ip-address ] command on Device A to check the
configurations.


*>i 10.1.4.0/30 10.1.5.2 0 100 0 i

* i 10.1.2.2 0 100 0 i
table of Device A and that Device A selects the route learned from Device C.

From: 10.1.3.2 (3.3.3.9)


best, select, pre 255, IGP cost 2
Originator: 10.1.4.1

From: 10.1.1.2 (2.2.2.9)
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 2, not preferred for router ID
Originator: 10.1.4.2
The preceding command output shows that the route learned from Device B is not selected
due to a router ID issue. In fact, the router ID of Device B is 2.2.2.9, smaller than that
(3.3.3.9) of Device C. The route learned from Device B should be selected if the router IDs
are used to determine the optimal route. However, the routes carry Originator_ID attributes. In
this situation, the Originator_ID attributes (rather than router IDs) are compared. Device A
selects the route learned from Device C because its Originator_ID (10.1.4.1) is smaller than
that (10.1.4.2) of the route learned from Device B.
Table 10-28 describes the attribute comparison of the routes learned from Device B and
Device C.
Table 10-28 Attribute comparison of the routes learned from Device B and Device C
AIGP - - The same.
MED 0 0 The same.
IGP cost 2 2 The same.
Cluster_List 0.0.0.2 0.0.0.3 The same length.


Originator_ID 10.1.4.2 10.1.4.1 The route learned

from Device C is
optimal.
If routes carry Originator_ID attributes, the Originator_ID attributes (rather than router IDs)
are compared.
10.36.4.13 Router ID
If multiple routes to the same destination are available, BGP preferentially selects the route
advertised by the device with the smallest router ID.
A router ID uniquely identifies a router in an AS, and the router ID can be configured as
follows:
l Run the router-id { ipv4-address | vpn-instance auto-select } command. If no router ID
is configured in the BGP view, BGP selects a router ID configured in the system view.
For details on how a router ID configured in the system view is selected.
l Run the router-id (BGP) { ipv4-address | auto-select } command in the BGP VPN
instance IPv4/IPv6 address family view. The router-id (BGP VPN instance IPv4/IPv6
address family view) command takes precedence over the router-id (BGP) command.
If each route carries an Originator_ID, the Originator_IDs rather than router IDs are compared
during route selection. The route with the smallest Originator_ID is preferred. By default,
Cluster_List takes precedence over Originator_ID during BGP route selection. To enable
Originator_ID to take precedence over Cluster_List during BGP route selection, run the
bestroute router id-prior-clusterlist command.
For more router ID-based route selection examples, see 10.36.4.3 Local_Pref, 10.36.4.7
Origin, and MED.
10.36.4.14 Peer IP Address

BGP prefers the route learned from the peer with the smallest IP address during BGP route
selection.
The peer IP address is the IP address specified in ipv4-address or ipv6-address in the peer
{ group-name | ipv4-address | ipv6-address } as-number { as-number-plain | as-number-dot }
command. The group-name parameter specified in the command is the one specified in the
peer { ipv4-address | ipv6-address } group group-name command.
If the optimal route has not been selected yet before BGP begins to compare peer IP
addresses, the local device may have established multiple BGP peer relationships with another
device through equal-cost links. In most cases, if a backup physical link is available between
two devices, using loopback interfaces to establish a BGP peer relationship is recommended
although multiple BGP peer relationships may be established between the two devices
through the physical links.
In Figure 10-35, two physical links are available between Device A and Device B. Device A
and Device B can use loopback interfaces to establish a BGP peer relationship or use the two
links to establish two BGP peer relationships. In the following example, the two links are

used to establish two BGP peer relationships to show how peer addresses are used in route
selection.
Figure 10-35 Networking in which two links are used to establish two BGP peer relationships
AS 65001 AS 65002
10.1.1.1/30 10.1.1.2/30
1.1.1.9/32 2.2.2.9/32
10.1.2.1/30 10.1.2.2/30
Device A Device B
The configurations on Device A are as follows:

#
bgp 65001
#
ipv4-family unicast
peer 10.1.1.2 enable
#
The configurations on Device B are as follows:

#
bgp 65002
#
ipv4-family unicast
network 2.2.2.9 255.255.255.255
#


*> 2.2.2.9/32 10.1.1.2 0 0 65002i

* 10.1.2.2 0 0 65002i
table and that the route with the next hop address 10.1.1.2 is selected as the optimal route.

From: 10.1.1.2 (192.168.2.4)


AS-path 65002, origin igp, MED 0, pref-val 0, valid, external, best, select,
active, pre 255
10.1.1.2
10.1.2.2
From: 10.1.2.2 (192.168.2.4)
preferred for peer address
The preceding command output shows that the route with the next hop address 10.1.1.2 is
selected as the optimal route because its peer IP address is smaller than that of the other route.
10.37 BGP Configuration Examples

This section provides BGP configuration examples.
10.37.1 Example for Configuring Basic BGP Functions

Before building BGP networks, you need to configure basic BGP functions.
Networking Requirements
If multiple ASs want to access each other, these ASs must exchange their local routes. If
multiple routers exist in the ASs, a great deal of routing information will be exchanged
between ASs, which consumes lots of bandwidth resources. To address this issue, you can
configure basic BGP functions.
In Figure 10-36, Device A is in AS 65008. Device B, C, and D are in AS 65009. The routing
tables of these routers store many routes, and the routes change frequently. After BGP is
enabled on the routers, they can exchange routing information. If routes of one router
changes, the router sends Update messages carrying only changed routing information to its
peers, which greatly reduces bandwidth consumption.
Figure 10-36 Configuring basic BGP functions

NOTE
Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.

LoopBack0
LoopBack0 interface3 interface2

interface2 DeviceC
LoopBack0
interface1
interface3 interface2
DeviceA
interface2 DeviceD
interface1
AS 65008 DeviceB interface1
LoopBack0
AS 65009
Device Name Interface IP Address
DeviceA Loopback 0 1.1.1.1/32
GE 1/0/0 8.1.1.1/8
GE 2/0/0 200.1.1.2/24
DeviceB Loopback 0 2.2.2.2/32
GE 1/0/0 9.1.1.1/24
GE 2/0/0 200.1.1.1/24
GE 3/0/0 9.1.3.1/24
DeviceC Loopback 0 3.3.3.3/32
GE 2/0/0 9.1.2.1/24
GE 3/0/0 9.1.3.2/24
DeviceD Loopback 0 4.4.4.4/32
GE 1/0/0 9.1.1.2/24
GE 2/0/0 9.1.2.2/24
Precautions
When configuring basic BGP functions, note the following rules:
l When establishing a peer relationship, if the specified IP address of the peer is a
loopback interface address or a sub-interface address, run the peer connect-interface
command on the two ends to ensure that the two ends are correctly connected.
l If there is no directly connected physical link between EBGP peers, run the peer ebgp-
max-hop command to allow EBGP peers to establish TCP connections through multiple
hops.

Configuration Roadmap
The configuration roadmap is as follows:
1. Establish IBGP connections between Device B, Device C, and Device D.
2. Establish an EBGP connection between Device A and Device B.
3. Advertise routes using the network command on Device A, and then check the routing
tables of Device A, Device B, and Device C.
4. Configure BGP on Device B to import direct routes, and then check the routing tables of
Device A and Device C.
Data Preparation
To complete the configuration, you need the following data:
l Router ID and AS number of Device A
l Router IDs and AS numbers of Device B, Device C, and Device D
Procedure
Step 1 Configure an IP address for each interface. For configuration details, see Configuration File
in this section.
Step 2 Configure OSPF.
# Configure Device B.
[~DeviceB] ospf 1
[*DeviceB-ospf-1] area 0
[*DeviceB-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] commit
[~DeviceB-ospf-1-area-0.0.0.0] quit
[~DeviceB-ospf-1] quit
# Configure Device C.
[~DeviceC] ospf 1
[*DeviceC-ospf-1] area 0
[*DeviceC-ospf-1-area-0.0.0.0] network 9.1.2.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.0] commit
[~DeviceC-ospf-1-area-0.0.0.0] quit
[~DeviceC-ospf-1] quit
# Configure Device D.
[~DeviceD] ospf 1
[*DeviceD-ospf-1] area 0
[*DeviceD-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[*DeviceD-ospf-1-area-0.0.0.0] commit
[~DeviceD-ospf-1-area-0.0.0.0] quit
[~DeviceD-ospf-1] quit
Step 3 Configure IBGP connections.

[~DeviceB] bgp 65009

[*DeviceB-bgp] router-id 2.2.2.2

[*DeviceB-bgp] peer 3.3.3.3 as-number 65009
[*DeviceB-bgp] peer 3.3.3.3 connect-interface LoopBack0
[*DeviceB-bgp] commit
[~DeviceB-bgp] quit
[~DeviceC] bgp 65009
[*DeviceC-bgp] router-id 3.3.3.3
[*DeviceC-bgp] peer 2.2.2.2 as-number 65009
[*DeviceC-bgp] peer 2.2.2.2 connect-interface LoopBack0
[*DeviceC-bgp] commit
[~DeviceC-bgp] quit
[~DeviceD] bgp 65009
[*DeviceD-bgp] router-id 4.4.4.4
[*DeviceD-bgp] peer 2.2.2.2 as-number 65009
[*DeviceD-bgp] peer 2.2.2.2 connect-interface LoopBack0
[*DeviceD-bgp] commit
[~DeviceD-bgp] quit
Step 4 Configure an EBGP connection.

# Configure Device A.
[~DeviceA] bgp 65008
[*DeviceA-bgp] router-id 1.1.1.1
[*DeviceA-bgp] peer 200.1.1.1 as-number 65009
[*DeviceA-bgp] commit
[~DeviceA-bgp] quit
[~DeviceB-bgp] quit
# Check the status of BGP connections.

[~DeviceB] display bgp peer
3.3.3.3 4 65009 5 5 0 00:44:58 Established 0
4.4.4.4 4 65009 4 4 0 00:40:54 Established 0
200.1.1.2 4 65008 3 3 0 00:44:03 Established 0
The command output shows that Device B has established BGP connections with other
routers and that the connection status is Established.
Step 5 Configure Device A to advertise the route to 8.0.0.0/8.
# Configure Device A to advertise the route.
[*DeviceA-bgp] ipv4-family unicast
[*DeviceA-bgp-af-ipv4] network 8.0.0.0 255.0.0.0
[*DeviceA-bgp-af-ipv4] commit

[~DeviceA-bgp-af-ipv4] quit
[~DeviceA-bgp] quit
# Check the routing table of Device A.

*> 8.0.0.0 0.0.0.0 0 0 i
# Check the routing table of Device B.

*> 8.0.0.0 200.1.1.2 0 0 65008i
# Check the routing table of Device C.

i 8.0.0.0 200.1.1.2 0 100 0 65008i
NOTE
The command output shows that Device C has learned the route to 8.0.0.0 from AS 65008. However,
this route is invalid because the next hop 200.1.1.2 is unreachable.
Step 6 Configure BGP to import direct routes.

[*DeviceB-bgp] ipv4-family unicast
[*DeviceB-bgp-af-ipv4] import-route direct
[*DeviceB-bgp-af-ipv4] commit
[~DeviceB-bgp-af-ipv4] quit
[~DeviceB-bgp] quit
# Check the BGP routing table of Device A.


*> 2.2.2.2/32 200.1.1.1 0 0 65009?

*> 8.0.0.0 0.0.0.0 0 0 i
*> 9.1.1.0/24 200.1.1.1 0 0 65009?

*> 9.1.1.2/32 200.1.1.1 0 0 65009?

*> 9.1.3.0/24 200.1.1.1 0 0 65009?
*> 9.1.3.2/32 200.1.1.1 0 0 65009?
* 200.1.1.0 200.1.1.1 0 0 65009?
* 200.1.1.2/32 200.1.1.1 0 0 65009?
# Check the BGP routing table of Device C.


i 2.2.2.2/32 2.2.2.2 0 100 0 ?

*>i 8.0.0.0 200.1.1.2 0 100 0 65008i
*>i 9.1.1.0/24 2.2.2.2 0 100 0 ?
*>i 9.1.1.2/32 2.2.2.2 0 100 0 ?
* i 9.1.3.0/24 2.2.2.2 0 100 0 ?
* i 9.1.3.2/32 2.2.2.2 0 100 0 ?
*>i 200.1.1.0 2.2.2.2 0 100 0 ?
*>i 200.1.1.2/32 2.2.2.2 0 100 0 ?
The command output shows that the route to 8.0.0.0 becomes valid and that the next hop is
the address of Device A.
# Verify the configuration using the ping command.
[~DeviceC] ping 8.1.1.1
PING 8.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=254 time=31 ms
--- 8.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 16/31/47 ms
----End
Configuration Files
l Device A configuration file
#
sysname DeviceA
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 8.1.1.1 255.0.0.0
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.0.0.0 255.0.0.0


#
return
l Device B configuration file

#
sysname DeviceB
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
undo shutdown
ip address 9.1.3.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 65009
router-id 2.2.2.2
peer 3.3.3.3 connect-interface LoopBack0
#
ipv4-family unicast
import-route direct
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.3.0 0.0.0.255
#
return
l Device C configuration file

#
sysname DeviceC
#
undo shutdown
ip address 9.1.2.1 255.255.255.0
#
undo shutdown
ip address 9.1.3.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast

peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 9.1.2.0 0.0.0.255
network 9.1.3.0 0.0.0.255
#
return
l Device D configuration file
#
sysname DeviceD
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
undo shutdown
ip address 9.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 65009
router-id 4.4.4.4
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.2.0 0.0.0.255
#
return
10.37.2 Example for Configuring BGP to Interact with an IGP

Configuring BGP to interact with an IGP can enrich routing tables.
As the Internet grows, devices in different networks need to access each other, data needs to
be reliably transmitted, and the traffic interruption time needs to be minimized. This requires
that routing information be transmitted widely and network convergence be accelerated. BGP
can transmit routing information efficiently and widely. BGP, however, does not calculate
routes by itself. An IGP can implement rapid route convergence, but it transmits routing
information with a low efficiency in a limited scope. After BGP is configured to interact with
an IGP, IGP routes can be imported into BGP routing tables and transmitted efficiently, and
BGP routes can also be imported to IGP routing tables so that ASs can access each other.
The network shown in Figure 10-37 is divided into AS 65008 and AS 65009. In AS 65009,
an IGP is used to calculate routes. In this example, OSPF is used as an IGP. BGP can be
configured to enable the two ASs to access each other. Interaction between BGP and the IGP

can be configured on edge routers in the two ASs so that the two ASs can exchange routes
efficiently.
Figure 10-37 Configuring BGP to interact with an IGP

NOTE
Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.
8.1.1.1/24 interface2 interface1 9.1.2.1/24
3.1.1.2/24 9.1.1.1/24
interface1
interface2
DeviceA DeviceB 9.1.1.2/24 DeviceC
3.1.1.1/24
AS 65008
AS 65009
Precautions
None.
1. Configure OSPF on Device B and Device C.
3. Configure BGP and OSPF to import routes from each other on Device B and then check
the routes.
4. Configure BGP route summarization on Device B to simplify the BGP routing table.
Data Preparation
l Router IDs and AS numbers of Device B and Device C
Procedure
Step 1 Configure an IP address for each interface. For configuration details, see Configuration Files
in this section.
[~DeviceB] ospf 1

[~DeviceC] ospf 1
Step 3 Configure an EBGP connection.

Step 4 Configure BGP to interact with an IGP.

# Configure BGP to import OSPF routes on Device B.
[~DeviceB-bgp] ipv4-family unicast
[*DeviceB-bgp-af-ipv4] import-route ospf 1
[~DeviceB-bgp] quit

*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.1.1.0/24 3.1.1.1 1 0 65009?
*> 9.1.2.0/24 3.1.1.1 2 0 65009?
# Configure OSPF to import BGP routes on Device B.

[~DeviceB] ospf
[*DeviceB-ospf-1] import-route bgp
[*DeviceB-ospf-1] commit

[~DeviceC] display ip routing-table
------------------------------------------------------------------------------
Routing Tables : _public_

8.1.1.0/24 O_ASE 150 1 D 9.1.1.1

9.1.1.0/24 Direct 0 0 D 9.1.1.2
9.1.1.1/32 Direct 0 0 D 9.1.1.1
9.1.1.2/32 Direct 0 0 D 127.0.0.1
9.1.1.255/32 Direct 0 0 D 127.0.0.1
9.1.2.0/24 Direct 0 0 D 9.1.2.1
9.1.2.1/32 Direct 0 0 D 127.0.0.1
9.1.2.255/32 Direct 0 0 D 127.0.0.1
Step 5 Configure automatic route summarization.

[*DeviceB-bgp-af-ipv4] summary automatic
# Check the BGP routing table of Device A.

*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.0.0.0 3.1.1.1 0 65009?
# Verify the configuration by using the ping command.

[*DeviceA] ping -a 8.1.1.1 9.1.2.1
PING 9.1.2.1: 56 data bytes, press CTRL_C to break
--- 9.1.2.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 15/37/47 ms
----End
Configuration Files
#
sysname DeviceA

#
undo shutdown
ip address 8.1.1.1 255.255.255.0
#
undo shutdown
ip address 3.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
peer 3.1.1.1 enable
#
return

#
sysname DeviceB
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 3.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
summary automatic
import-route ospf 1
peer 3.1.1.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 9.1.1.0 0.0.0.255
#
return

#
sysname DeviceC
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
undo shutdown
ip address 9.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.2.0 0.0.0.255
#
return

10.37.3 Example for Configuring the MED Attribute to Control

Route Selection
By setting the MED attribute, you can flexibly control BGP route selection.
The MED attribute equals a metric used in an IGP, and is used to determine the optimal route
for traffic that enters an AS. When a BGP device obtains multiple routes to the same
destination address but with different next hops from EBGP peers, the route with the smallest
MED value is selected as the optimal route.
On the network shown in Figure 10-38, BGP is configured on all routers. Device A is in AS
65008. Device B and Device C are in AS 65009. Device A establishes EBGP connections
with Device B and Device C. Device B establishes an IBGP connection with Device C.
Traffic sent by Device A to 9.1.1.0 can enter AS 65009 through Device B or Device C. If the
attributes excluding the MED values of the routes advertised by Devices B and C to Device A
are the same, you can change the MED value of the route to be advertised by Device B or
Device C to Device A to determine the device through which traffic will enter AS 65009.
Figure 10-38 Configuring the MED attribute to control route selection

NOTE
interface2 DeviceB
200.1.1.1/24
AS 65008 200.1.1.2/24 9.1.1.1/24
EBGP
IBGP
DeviceA
AS 65009
interface2
200.1.2.2/24 EBGP interface1
9.1.1.2/24
interface2
200.1.2.1/24 DeviceC
Precautions
None
1. Establish EBGP connections between Device A and Device B, and between Device A
and Device C, and establish an IBGP connection between Device B and Device C.

2. Apply a routing policy to increase the MED value of the route sent by Device B to
Device A so that Device A will send traffic to AS 65009 through Device C.
Data Preparation
l Router ID 1.1.1.1 and AS number 65008 of Device A
l Router IDs 2.2.2.2 and 3.3.3.3, and AS number 65009 of Devices B and C
l New MED value 100 of the route on Device B
Procedure
in this section.
Step 2 Configure BGP connections.
[~DeviceA-bgp] quit
[*DeviceB-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[~DeviceB-bgp] quit
[*DeviceC-bgp] ipv4-family unicast
[*DeviceC-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[*DeviceC-bgp-af-ipv4] commit
[~DeviceC-bgp-af-ipv4] quit
[~DeviceC-bgp] quit

[~DeviceA] display bgp routing-table 9.1.1.0 24

From: 200.1.1.1 (2.2.2.2)

255
200.1.1.1
200.1.2.1

From: 200.1.2.1 (3.3.3.3)
The command output shows that there are two valid routes to 9.1.1.0/24. The route with
200.1.1.1 as the next hop is the optimal route because the router ID of Device B is smaller.
Step 3 Configure the MED attribute.
# Set the MED value for the route sent by Device B to Device A based on a routing policy.
[~DeviceB] route-policy 10 permit node 10
[*DeviceB-route-policy] apply cost 100
[*DeviceB-route-policy] commit
[~DeviceB-route-policy] quit
[*DeviceB-bgp] peer 200.1.1.2 route-policy 10 export


From: 200.1.2.1 (3.3.3.3)
255
200.1.1.1
200.1.2.1

From: 200.1.1.1 (2.2.2.2)
preferred for MED
The command output shows that the MED value of the next hop 200.1.1.1 (Device B) is 100
and that the MED value of the next hop 200.1.2.1 is 0. Therefore, the route with the smaller
MED value is selected.
----End

Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
#
return

#
sysname DeviceB
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.2 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 100
#
return

#
sysname DeviceC
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
bgp 65009
router-id 3.3.3.3


#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.1 enable
#
return
10.37.4 Example for Configuring an AS_Path Filter

AS_Path filters can be used to improve network performance.
Enterprises A, B, and C belong to different ASs. The network of enterprise B communicates
with the networks of the other two enterprises through EBGP. Due to the competition
relationship, enterprises A and C require that the routes that they advertise to enterprise B be
not learned by each other. In this situation, configure an AS_Path filter on enterprise B.
In Figure 10-39, Device B establish EBGP connections with Devices A and C. To disable
devices in AS 10 from communicating with devices in AS 30, you can configure an AS_Path
filter on Device B to prevent devices in AS 20 from advertising routes of AS 30 to AS 10 or
routes of AS 10 to AS 30.
Figure 10-39 Configuring an AS_Path filter

NOTE
interface1
interface2
200.1.4.1/24
200.1.2.1/24
DeviceA
AS 10
EBGP EBGP
interface2 EBGP interface1

200.1.2.2/24 200.1.4.2/24
interface2
AS 20 200.1.3.2/24
interface1 AS 30
200.1.3.1/24 DeviceC
DeviceB
Precautions
The relationship between multiple filtering rules of the same filter is OR.

1. Establish EBGP connections between Device A and Device B, between Device B and
Device C, and between Device C and Device A, and then import direct routes.
2. Configure an AS_Path filter on Device B and then apply its filtering rules.
Data Preparation
l Router IDs and AS numbers of Device A, Device B, and Device C
l Number of the AS_Path filter
Procedure
in this section.
Step 2 Configure EBGP connections.
[~DeviceA] bgp 10
[*DeviceA-bgp] import-route direct
[~DeviceB] bgp 20
[*DeviceB-bgp] import-route direct
[~DeviceB-bgp] quit
[~DeviceC] bgp 30
[*DeviceC-bgp] import-route direct
[~DeviceC-bgp] quit
# Display the routing table advertised by Device B. Use the routes advertised by Device B to
Device C as an example. You can view that Device B advertises the routes destined for the
network segment between Device A and Device C.
<DeviceB> display bgp routing-table peer 200.1.3.2 advertised-routes

*> 200.1.2.0 0.0.0.0 0 0 ?

*> 200.1.2.1/32 0.0.0.0 0 0 ?
*> 200.1.2.2/32 200.1.2.1 0 0 10?
*> 200.1.3.0 0.0.0.0 0 0 ?
*> 200.1.3.1/32 200.1.3.2 0 0 30?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
*> 200.1.4.0 200.1.2.1 0 0 10?
*> 200.1.4.1/32 200.1.3.2 0 0 30?
*> 200.1.4.2/32 200.1.2.1 0 0 10?
Check the routing table of Device C. The command output shows that Device C has learned
the two routes advertised by Device B.
<DeviceC> display bgp routing-table

*> 200.1.2.0 200.1.4.1 0 0 10?

* 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.2.2/32 200.1.4.1 0 0 10?
* 200.1.3.1 0 20 10?
*> 200.1.3.0 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.3.1/32 0.0.0.0 0 0 ?
*> 200.1.3.2/32 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.4.0 0.0.0.0 0 0 ?
* 200.1.4.1 0 0 10?
* 200.1.3.1 0 20 10?
*> 200.1.4.1/32 0.0.0.0 0 0 ?
*> 200.1.4.2/32 200.1.4.1 0 0 10?
* 200.1.3.1 0 20 10?
Step 3 Configure the AS_Path filter on Device B and then apply the filter on the outbound interface
of Device B.
# Create AS_Path filter 1 to deny the routes carrying AS 30. The regular expression "_30_"
indicates any AS list that contains AS 30 and "*" matches any character.
[~DeviceB] ip as-path-filter 1 deny _30_
[*DeviceB] ip as-path-filter 1 permit .*
[*DeviceB] commit
# Create AS_Path filter 2 to deny the routes carrying AS 10. The regular expression "_10_"
indicates any AS list that contains AS 10 and "*" matches any character.
[~DeviceB] ip as-path-filter 2 deny _10_
[*DeviceB] ip as-path-filter 2 permit .*
[*DeviceB] commit
# Apply the AS_Path filter on two outbound interfaces of Device B.

[~DeviceB] bgp 20
[*DeviceB-bgp] peer 200.1.2.1 as-path-filter 1 export
[*DeviceB-bgp] peer 200.1.3.2 as-path-filter 2 export
[~DeviceB-bgp] quit

Step 4 Verify the configuration.
# Display the routing table advertised by Device B. The command output shows that the
advertised routes to the network segment between Device A and Device C do not exist. Use
the routes advertised by Device B to Device C as an example.


*> 200.1.2.0 0.0.0.0 0 0 ?

*> 200.1.2.1/32 0.0.0.0 0 0 ?
*> 200.1.3.0 0.0.0.0 0 0 ?
*> 200.1.3.1/32 200.1.3.2 0 0 30?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
*> 200.1.4.1/32 200.1.3.2 0 0 30?
Similarly, the BGP routing table of Device C does not have these routes.
<DeviceC> display bgp routing-table


*> 200.1.2.0 200.1.4.1 0 0 10?

* 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.2.2/32 200.1.4.1 0 0 10?
*> 200.1.3.0 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.3.1/32 0.0.0.0 0 0 ?
*> 200.1.3.2/32 200.1.3.1 0 0 20?
* 200.1.4.1 0 10 20?
*> 200.1.4.0 0.0.0.0 0 0 ?
* 200.1.4.1 0 0 10?
*> 200.1.4.1/32 0.0.0.0 0 0 ?
*> 200.1.4.2/32 200.1.4.1 0 0 10?
Check the routing table advertised by Device B, and you can view that the advertised routes to
the network segment between Device A and Device C do not exist. Use the routes advertised
by Device B to Device A as an example.



*> 200.1.2.0 0.0.0.0 0 0 ?

*> 200.1.2.1/32 0.0.0.0 0 0 ?
*> 200.1.2.2/32 200.1.2.1 0 0 10?
*> 200.1.3.0 0.0.0.0 0 0 ?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
*> 200.1.4.0 200.1.2.1 0 0 10?
*> 200.1.4.2/32 200.1.2.1 0 0 10?
Similarly, the BGP routing table of Device A does not have these routes.
<DeviceA> display bgp routing-table


*> 200.1.2.0 0.0.0.0 0 0 ?

* 200.1.2.2 0 0 20?
*> 200.1.2.1/32 200.1.2.2 0 0 20?
* 200.1.4.2 0 30 20?
*> 200.1.2.2/32 0.0.0.0 0 0 ?
*> 200.1.3.0 200.1.2.2 0 0 20?
* 200.1.4.2 0 0 30?
*> 200.1.3.1/32 200.1.4.2 0 0 30?
*> 200.1.3.2/32 200.1.2.2 0 0 20?
* 200.1.4.2 0 30 20?
*> 200.1.4.0 0.0.0.0 0 0 ?
* 200.1.4.2 0 0 30?
*> 200.1.4.1/32 200.1.4.2 0 0 30?
*> 200.1.4.2/32 0.0.0.0 0 0 ?
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.4.1 255.255.255.0
#
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
import-route direct
#
return

#
sysname DeviceB

#
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 200.1.2.1 as-path-filter 1 export
peer 200.1.3.2 as-path-filter 2 export
#
ip as-path-filter 1 deny _30_
ip as-path-filter 1 permit .*
ip as-path-filter 2 deny _10_
ip as-path-filter 2 permit .*
#
return

#
sysname DeviceC
#
undo shutdown
ip address 200.1.4.2 255.255.255.0
#
undo shutdown
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
import-route direct
#
return
10.37.5 Example for Configuring BGP RRs

With BGP RRs, IBGP peers do not have to be fully meshed, which reduces configuration
workload and facilitates network maintenance.
On a large-scale network, multiple routers that run BGP are deployed within an AS. These
routers need to use BGP to advertise routes to each other. To meet this need, IBGP peer
relationships need to be set up between all the routers. However, fully meshed connections
between all routers imposes a heavy burden on configurations and increases the link cost on
routers. In addition, fully meshed connections are difficult to maintain.

To address this issue, configure RRs. In Figure 10-40, AS 65010 is divided into two clusters,
Cluster 1 and Cluster 2. Device B is configured as an RR in Cluster 1, and Device D and
Device E are its clients. Device C is configured as an RR in Cluster 2, and Device F, Device
G, and Device H are its clients. Device A is the non-client of Device B and Device C. Device
B and Device C are non-clients of each other.
It is required that peer groups be configured to facilitate configuration and management.
Figure 10-40 Configuring BGP RRs

NOTE
Interfaces 1 through 5 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, GE 1/0/1, GE 1/0/2,
respectively.
interface3
9.1.1.1/24
AS 65010
DeviceA interface2
interface4 interface1 interface5
DeviceB
interface2 DeviceC interface4
DeviceH
interface3
interface3 Cluster
Cluster1
interface1 interface3 2
interface2
interface2
DeviceD DeviceE DeviceF DeviceG
Device Interface IP Address Device Interface IP Address
Device A GE 3/0/0 9.1.1.1/24 Device C GE 1/0/1 11.1.8.1/24
GE 1/0/0 11.1.1.2/24 GE 1/0/2 11.1.9.1/24
GE 2/0/0 11.1.3.2/24 Device D GE 1/0/0 11.1.4.2/24
Device B GE 1/0/0 11.1.1.1/24 GE 2/0/0 11.1.6.1/24
GE 2/0/0 11.1.4.1/24 Device E GE 2/0/0 11.1.6.2/24
GE 3/0/0 11.1.5.1/24 GE 3/0/0 11.1.5.2/24
GE 1/0/1 11.1.2.1/24 Device F GE 1/0/0 11.1.7.2/24
Device C GE 1/0/0 11.1.2.2/24 Device G GE 1/0/0 11.1.8.2/24
GE 2/0/0 11.1.3.1/24 Device H GE 2/0/0 11.1.9.2/24
GE 3/0/0 11.1.7.1/24

Precautions
When configuring a BGP RR, note the following rules:
l If a cluster has multiple RRs, run the reflector cluster-id command to set the same
cluster ID for these RRs to prevent routing loops.
l The name of a peer group is case sensitive.
1. Configure IBGP connections between the clients and the RR, and between the non-client
and the RR.
2. Configure Device B and Device C as RRs, specify their clients, and check routes.
Data Preparation
l Router IDs and AS numbers of Device A, Device B, Device C, Device D, Device E,
Device F, Device G, and Device H
l Cluster ID of Device B
Procedure
in this section.
Step 2 Configure IBGP connections between the clients and the RR, and between the non-client and
the RR.
Step 3 Configure RRs.
[*DeviceB-bgp] group in_rr internal
[*DeviceB-bgp] peer 11.1.4.2 group in_rr
[*DeviceB-bgp] peer 11.1.5.2 group in_rr
[*DeviceB-bgp-af-ipv4] peer in_rr reflect-client
[*DeviceB-bgp-af-ipv4] undo reflect between-clients
[*DeviceB-bgp-af-ipv4] reflector cluster-id 1
[*DeviceC-bgp] group in_rr internal
[*DeviceC-bgp] peer 11.1.7.2 group in_rr
[*DeviceC-bgp-af-ipv4] peer in_rr reflect-client
[*DeviceC-bgp-af-ipv4] reflector cluster-id 2

# Check the routing table of Device D.

[~DeviceD] display bgp routing-table 9.1.1.0
From: 11.1.4.1 (2.2.2.2)
Originator: 1.1.1.1
The command output shows that Device D has learned from Device B the route advertised by
Device A and that the Originator and Cluster_ID attributes of this route are displayed.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 11.1.1.2 255.255.255.0
#
undo shutdown
ip address 11.1.3.2 255.255.255.0
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
bgp 65010
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return

#
sysname DeviceB
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
#
undo shutdown
ip address 11.1.4.1 255.255.255.0
#
undo shutdown

ip address 11.1.5.1 255.255.255.0

#
undo shutdown
ip address 11.1.2.1 255.255.255.0
#
bgp 65010
router-id 2.2.2.2
group in_rr internal
peer 11.1.4.2 group in_rr
#
ipv4-family unicast
undo reflect between-clients
reflector cluster-id 1
peer in_rr enable
peer in_rr reflect-client
#
return
#
sysname DeviceC
#
undo shutdown
ip address 11.1.2.2 255.255.255.0
#
undo shutdown
ip address 11.1.3.1 255.255.255.0
#
undo shutdown
ip address 11.1.7.1 255.255.255.0
#
undo shutdown
ip address 11.1.8.1 255.255.255.0
#
undo shutdown
ip address 11.1.9.1 255.255.255.0
#
bgp 65010
router-id 3.3.3.3
group in_rr internal
#
ipv4-family unicast
reflector cluster-id 2


peer in_rr enable
peer in_rr reflect-client
#
return

#
sysname DeviceD
#
undo shutdown
ip address 11.1.4.2 255.255.255.0
#
undo shutdown
ip address 11.1.6.1 255.255.255.0
#
bgp 65010
router-id 4.4.4.4
#
ipv4-family unicast
#
return
NOTE
Configuration files of other routers are similar to the Device D configuration file.
10.37.6 Example for Configuring a BGP Confederation

BGP confederations can be used to reduce the number of IBGP connections.
If multiple devices are deployed in an AS and fully meshed IBGP connections must be
implemented between every two devices in the AS, a large number of IBGP connections will
be established, increasing operation and maintenance costs. To address this issue, configure
BGP confederations.
On the network shown in Figure 10-41, configure confederations in AS 200 to reduce the
number of IBGP connections to be established. After confederations are configured, AS 200
is divided into three sub-ASs: AS 65001, AS 65002, and AS 65003. AS 65001 establishes
EBGP connections with AS 65002 and AS 65003. The three routers in AS 65001 establish
IBGP fully meshed connections with each other.
Figure 10-41 Configuring the confederation

NOTE
respectively.

AS AS
65002 65003
interface1
DeviceB
11.1.2.2/24
interface1
11.1.1.2/24 DeviceC

GE1/0/0 11.1.1.1/24 11.1.2.1/24 AS 65001
9.1.1.1/24
200.1.1.2/24 interface4 DeviceD
DeviceA 11.1.3.1/24
interface1
interface1 interface5 11.1.3.2/24
DeviceF 200.1.1.1/24 11.1.4.1/24 interface2
AS 100 11.1.5.1/24
interface5
11.1.4.2/24
interface2
11.1.5.2/24
AS 200
DeviceE
1. Configure a BGP confederation on each router in AS 200.
2. Configure the IBGP connection in AS 65001.
3. Configure the EBGP connection between AS 100 and AS 200, and check the routes.
Data Preparation
l The Router IDs of Device A, Device B, Device C, Device D, Device E, and Device F
(1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5, and 6.6.6.6)
l The AS number (100), and the three sub-ASs of AS 200 (AS 65001, AS 65002, and AS
65003)
Procedure
Step 1 Assign an IP address to each interface.
For configuration details, see Configuration Files in this section.
Step 2 Configure the BGP confederation.
[*DeviceA-bgp] confederation id 200
[*DeviceA-bgp] confederation peer-as 65002 65003


[*DeviceA-bgp-af-ipv4] peer 11.1.1.2 next-hop-local
[~DeviceA-bgp] quit
[*DeviceB-bgp] confederation id 200
[*DeviceB-bgp] confederation peer-as 65001
[~DeviceB-bgp] quit
[*DeviceC-bgp] confederation id 200
[*DeviceC-bgp] confederation peer-as 65001
[~DeviceC-bgp] quit
Step 3 Configure IBGP connections inside AS 65001.

[~DeviceA-bgp] quit
[*DeviceD-bgp] confederation id 200
[~DeviceD-bgp] quit
# Configure Device E.
[~DeviceE] bgp 65001
[*DeviceE-bgp] router-id 5.5.5.5
[*DeviceE-bgp] confederation id 200
[*DeviceE-bgp] peer 11.1.4.1 as-number 65001
[*DeviceE-bgp] commit
[~DeviceE-bgp] quit
Step 4 Configure the EBGP connection between AS 100 and AS 200.

[~DeviceA-bgp] quit

# Configure Device F.
[~DeviceF] bgp 100
[*DeviceF-bgp] router-id 6.6.6.6
[*DeviceF-bgp] peer 200.1.1.1 as-number 200
[*DeviceF-bgp] ipv4-family unicast
[*DeviceF-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[*DeviceF-bgp-af-ipv4] commit
[~DeviceF-bgp-af-ipv4] quit
[~DeviceF-bgp] quit

*>i 9.1.1.0/24 11.1.1.1 0 100 0 (65001) 100i
From: 11.1.1.1 (1.1.1.1)
AS-path (65001) 100, origin igp, MED 0, localpref 100, pref-val 0, valid,
external-confed, best, select, active, pre 255
# Check the BGP routing table of Device D.

[~DeviceD] display bgp routing-table
*>i 9.1.1.0/24 11.1.3.1 0 100 0 100i
[~DeviceD] display bgp routing-table 9.1.1.0
From: 11.1.3.1 (1.1.1.1)
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-
confed, best, select, active, pre 255
----End

Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
#
undo shutdown
ip address 11.1.2.1 255.255.255.0
#
undo shutdown
ip address 11.1.3.1 255.255.255.0
#
undo shutdown
ip address 11.1.4.1 255.255.255.0
#
bgp 65001
router-id 1.1.1.1
confederation id 200
confederation peer-as 65002 65003
#
ipv4-family unicast
peer 11.1.1.2 next-hop-local
#
return

#
sysname DeviceB
#
undo shutdown
ip address 11.1.1.2 255.255.255.0
#
bgp 65002
router-id 2.2.2.2
confederation peer-as 65001
#
ipv4-family unicast
#
return

NOTE
The configuration file of Device C is similar to that of Device B.

#
sysname DeviceD
#
undo shutdown
ip address 11.1.3.2 255.255.255.0
#
undo shutdown
ip address 11.1.5.1 255.255.255.0
#
bgp 65001
router-id 4.4.4.4
#
ipv4-family unicast
#
return
NOTE
The configuration file of Device E is similar to that of Device D.

l Device F configuration file
#
sysname DeviceF
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
bgp 100
router-id 6.6.6.6
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
Return
10.37.7 Example for Configuring the BGP Community Attribute

By setting the community attribute, you can flexibly control BGP route selection.
Enterprises A, B, and C are in three ASs, the network of enterprise B is connected to the
networks of the other two enterprises. Enterprise A and C are rivals, and enterprise A requires
that the routes it sends to enterprise B be transmitted only within enterprise B. In this
situation, you can configure the community attribute on the router in enterprise A that sends
routes to enterprise B.

In Figure 10-42, EBGP connections are established between Device B and Device A, and
between Device B and Device C. It is required that the routes advertised from AS 10 to AS 20
are not advertised to other ASs by AS 20. In this situation, configure the community attribute
No_Export on Device A.
Figure 10-42 Configuring the BGP community attribute

NOTE
interface1
AS 10 9.1.1.1/24
interface2
200.1.2.1/24
DeviceA
EBGP
200.1.2.2/24 EBGP 200.1.3.2/24
interface3 DeviceC
DeviceB 200.1.3.1/24
AS 20 AS 30
Precautions
None
1. Establish EBGP connections between Device A andDevice B, and between Device B

and Device C.
2. Configure a routing policy on Device A to advertise the community attribute No_Export.
Data Preparation

l Router ID and AS number of Device B
l Router ID and AS number of Device C
Procedure
in this section.

Step 2 Configure EBGP connections.

[~DeviceA] bgp 10
[~DeviceB] bgp 20
[~DeviceB-bgp] quit
[~DeviceC] bgp 30
[~DeviceC-bgp] quit

From: 200.1.2.1 (1.1.1.1)
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, pre 255
200.1.2.1
200.1.3.2
The command output shows that Device B advertises the received routes to Device C in AS
30.
*> 9.1.1.0/24 200.1.3.1 0 20 10i
In the routing table, you can view that Device C learns the route to 9.1.1.0/24 from Device B.
Step 3 Configure the BGP community attribute.
# Configure a routing policy on Device A to ensure that the routes advertised by Device A to
Device B are not advertised by Device B to any other AS.
[~DeviceA] route-policy comm_policy permit node 10

[*DeviceA-route-policy] apply community no-export

[*DeviceA-route-policy] commit
[~DeviceA-route-policy] quit
# Apply the routing policy.

[~DeviceA] bgp 10
[*DeviceA-bgp-af-ipv4] peer 200.1.2.2 route-policy comm_policy export
[*DeviceA-bgp-af-ipv4] peer 200.1.2.2 advertise-community

From: 200.1.2.1 (1.1.1.1)
Community:no-export
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, pre 255
The command output shows the configured community attribute and that route to 9.1.1.0/24
has not been advertised to Device C.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 200.1.2.2 route-policy comm_policy export
peer 200.1.2.2 advertise-community
#
route-policy comm_policy permit node 10
apply community no-export
#
return

#
sysname DeviceB
#

undo shutdown
ip address 200.1.2.2 255.255.255.0
#
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname DeviceC
#
undo shutdown
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
#
return
10.37.8 Example for Configuring Prefix-based BGP ORF

Prefix-based BGP ORF is used to implement on-demand BGP route advertisement.
On the network shown in Figure 10-43, Devices A and B are in AS 100. Devices C, D, and E
are in AS 200. Device A requires Device C to send only routing information matching the
import policy of Device A, but Device C does not want to maintain a separate export policy
for Device A. Prefix-based BGP ORF can be configured in such a situation.
Figure 10-43 Networking diagram for configuring prefix-based BGP ORF

NOTE

Loopback1
4.4.4.4/32
DeviceD
Loopback1 Loopback1 Loopback1

2.2.2.2/32 1.1.1.1/32 3.3.3.3/32 interface1
interface1 11.3.1.1/30
11.2.1.1/30 interface2
interface3
11.2.1.2/30 11.1.1.1/30 11.1.1.2/30
DeviceB DeviceA 11.4.1.2/30
AS100 DeviceC
interface1
11.4.1.1/30
DeviceE
Loopback1
AS200 5.5.5.5/32
1. Establish an EBGP peer relationship between Devices A and C, and establish IBGP peer
relationships between Devices A and B, between Devices C and D, and between Devices
C and E.
2. Configure a prefix-based import policy on Device A, and enable prefix-based BGP ORF
on Devices A and C.
Data Preparation
l Router IDs 1.1.1.1 and 2.2.2.2 and AS number 100 of Devices A and B respectively
l Router IDs 3.3.3.3, 4.4.4.4, and 5.5.5.5 and AS number 200 of Devices C, D, and E
respectively
Procedure
Step 1 Configure an IP address for each interface.
Configure an IP address for each interface, as shown in Figure 10-43. For details on
configuration procedures, see corresponding configuration files.
Step 2 Establish BGP peer relationships.
[~DeviceA] bgp 100


[*DeviceA-bgp-af-ipv4] import-route direct
[*DeviceA-bgp-af-ipv4] quit
[~DeviceA-bgp] quit
[~DeviceB] bgp 100
[~DeviceB-bgp] quit
[~DeviceC] bgp 200
[*DeviceC-bgp-af-ipv4] import-route direct
[*DeviceC-bgp-af-ipv4] quit
[~DeviceC-bgp] quit
[~DeviceD] bgp 200
[~DeviceD-bgp] quit
[~DeviceE] bgp 200
[~DeviceE-bgp] quit
Step 3 Configure a prefix-based import policy on Device A.

[~DeviceA] ip ip-prefix 1 index 10 permit 11.3.1.0 24 less-equal 32
[*DeviceA] bgp 100
[*DeviceA-bgp] peer 11.1.1.2 ip-prefix 1 import
[~DeviceA-bgp] quit
# View routing information sent by Device C.

[~DeviceC] display bgp routing-table peer 11.1.1.1 advertised-routes


*> 3.3.3.3/32 11.1.1.2 0 0 200?

*> 11.1.1.0/30 11.1.1.2 0 0 200?

*> 11.1.1.1/32 11.1.1.2 0 0 200?

*> 11.3.1.0/30 11.1.1.2 0 0 200?
*> 11.3.1.1/32 11.1.1.2 0 0 200?
*> 11.4.1.0/30 11.1.1.2 0 0 200?
*> 11.4.1.1/32 11.1.1.2 0 0 200?
# View routing information accepted by Device A.

[~DeviceA] display bgp routing-table peer 11.1.1.2 received-routes


*> 11.3.1.0/30 11.1.1.2 0 0 200?

*> 11.3.1.1/32 11.1.1.2 0 0 200?
When prefix-based BGP ORF is not enabled, Device C sends seven routes, but Device A
accepts only two routes because Device A applies the prefix-based import policy to the seven
routes.
Step 4 Enable prefix-based BGP ORF.
[~DeviceA] bgp 100
[*DeviceA-bgp] peer 11.1.1.2 capability-advertise orf ip-prefix both
[~DeviceA-bgp] quit
[~DeviceC] bgp 200
[*DeviceC-bgp] peer 11.1.1.1 capability-advertise orf ip-prefix both
[~DeviceC-bgp] quit

# View prefix-based BGP ORF negotiation information on Device A.
[~DeviceA] display bgp peer 11.1.1.2 verbose

Type: EBGP link
Update-group ID: 1
BGP current event: RecvRouteRefresh
Peer supports bgp outbound route filter capability
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both


Update messages 1
Open messages 1
Refresh messages 1
Update messages 5
Open messages 2
Refresh messages 1
Last keepalive received: 2012-03-06 19:17:37 UTC-8:00
Last keepalive sent : 2012-03-06 19:17:37 UTC-8:00
Last update received: 2012-03-06 19:17:43 UTC-8:00
Last update sent : 2012-03-06 19:17:37 UTC-8:00
Outbound route filter capability has been enabled
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
Multi-hop ebgp has been enabled
No import update filter list
No export update filter list
Import prefix list is: 1
No export prefix list
No import route policy
No export route policy
No import distribute policy
No export distribute policy
# View routing information sent by Device C.

[~DeviceC] display bgp routing-table peer 11.1.1.1 advertised-routes


*> 11.3.1.0/30 11.1.1.2 0 0 200?

*> 11.3.1.1/32 11.1.1.2 0 0 200?
# View routing information accepted by Device A.

[~DeviceA] display bgp routing-table peer 11.1.1.2 received-routes


*> 11.3.1.0/30 11.1.1.2 0 0 200?

*> 11.3.1.1/32 11.1.1.2 0 0 200?

After BGP ORF is enabled, Device C sends only two routes based on the prefix-based import
policy provided by Device A, and Device A accepts only the two routes.
----End
Configuration Files
l Configuration file of Device A
#
sysname
RouterA
#
interface
ip address 11.2.1.2
255.255.255.252
#
interface
ip address 11.1.1.1
255.255.255.252
#
interface
LoopBack1
ip address 1.1.1.1
255.255.255.255
#
bgp
100
router-id
1.1.1.1
peer 11.1.1.2 as-number
200
100
ipv4-family
unicast
undo
synchronization
import-route
direct
peer 11.1.1.2
enable
peer 11.1.1.2 ip-prefix 1
import
peer 11.1.1.2 capability-advertise orf ip-prefix
both
peer 11.2.1.1
enable
#
ip ip-prefix 1 index 10 permit 11.3.1.0 24 greater-equal 24 less-equal

32
#
return

l Configuration file of Device B

#
sysname
RouterB
#
interface
ip address 11.2.1.1
255.255.255.252
#
interface
LoopBack1
ip address 2.2.2.2
255.255.255.255
#
bgp
100
router-id
2.2.2.2
100
ipv4-family
unicast
undo
synchronization
peer 11.2.1.2
enable
#
return
l Configuration file of Device C

#
sysname
RouterC
#
interface
ip address 11.3.1.2
255.255.255.252
#
interface
ip address 11.1.1.2
255.255.255.252
#
interface
ip address 11.4.1.2
255.255.255.252
#
interface

LoopBack1
ip address 3.3.3.3
255.255.255.255
#
bgp
200
router-id
3.3.3.3
100
200
200
ipv4-family
unicast
undo
synchronization
import-route
direct
peer 11.1.1.1
enable
peer 11.1.1.1 capability-advertise orf ip-prefix
both
peer 11.3.1.1
enable
peer 11.4.1.1
enable
#
return
l Configuration file of Device D

#
sysname
RouterD
#
interface
ip address 11.3.1.1
255.255.255.252
#
interface
LoopBack1
ip address 4.4.4.4
255.255.255.255
#
bgp
200
router-id
4.4.4.4
200
ipv4-family
unicast
undo
synchronization

peer 11.3.1.2
enable
#
return
l Configuration file of Device E

#
sysname
RouterE
#
interface
ip address 11.4.1.1
255.255.255.252
#
interface
LoopBack1
ip address 5.5.5.5
255.255.255.255
#
bgp
200
router-id
5.5.5.5
200
ipv4-family
unicast
undo
synchronization
peer 11.4.1.2
enable
#
return
10.37.9 Example for Configuring BGP Route Dampening

Configuring BGP route dampening can improve network stability.
In Figure 10-44, all routers are configured with BGP; Device A resides in AS 100; Device B
resides in AS 200; Device C resides in AS 300; Device D resides in AS 400. EBGP runs
between Device C and Device A, between Device C and Device B, and between Device C
and Device D. For routes from different EBGP neighbors, Device C applies different route
dampening policies. It is required that BGP route dampening be configured to suppress
unstable routes and improve network stability.
Figure 10-44 Configuring BGP route dampening

NOTE

AS100 AS200
DeviceA 8.1.1.1/8 9.1.1.1/24 DeviceB
200.1.1.1/24 200.1.2.1/24
200.1.1.2/24 200.1.2.2/24
DeviceC
interface3
200.1.3.2/24 AS300
interface2
200.1.3.1/24
DeviceD
AS400
Precautions
When configuring BGP route dampening, note the following rules:
l BGP route dampening takes effect only on EBGP routes.
l Set a small MaxSuppressTime for routes with the small masks.
1. Establish EBGP connections between Device A and Device C, between Device B and
Device C, and between Device D and Device C.
2. Configure route dampening policies on Device C and then check routes.
Data Preparation
l Router IDs and AS numbers of Device A, Device B, Device C, and Device D
l Name of the route flap dampening policy to be applied to Device C
Procedure
in this section.

[~DeviceA] bgp 100

[~DeviceA-bgp] quit
[~DeviceB] bgp 200
[*DeviceB-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[~DeviceB-bgp] quit
[~DeviceC] bgp 300
[~DeviceC-bgp] quit
[~DeviceD] bgp 400
[~DeviceD-bgp] quit
# Check the BGP peers of Device C.

[~DeviceC] display bgp peer


PrefRcv
200.1.1.1 4 100 3 3 0 00:00:01 Established 0
200.1.2.1 4 200 3 3 0 00:00:00 Established 0
200.1.3.1 4 400 3 3 0 00:00:01 Established 0
The command output shows that the BGP connection status of with each peer is Established.
Step 3 Configure BGP route dampening policies.
# Configure an IP prefix list named prefix-a on Device C to accept only the routes with prefix
8.0.0.0/8.
[~DeviceC] ip ip-prefix prefix-a index 10 permit 8.0.0.0 8
[*DeviceC] commit
# Configure an IP prefix list named prefix-b on Device C to accept only the routes with prefix
9.1.1.0/24.
[~DeviceC] ip ip-prefix prefix-b index 20 permit 9.1.1.0 24
[*DeviceC] commit
# Configure a route-policy named dampen-policy on Device C and then apply different route
dampening policies to the routes with different prefix lengths.

[~DeviceC] route-policy dampen-policy permit node 10

[*DeviceC-route-policy] if-match ip-prefix prefix-a
[*DeviceC-route-policy] apply dampening 10 1000 2000 5000
[*DeviceC-route-policy] commit
[~DeviceC-route-policy] quit
[~DeviceC] route-policy dampen-policy permit node 20
[*DeviceC-route-policy] if-match ip-prefix prefix-b
[*DeviceC-route-policy] apply dampening 10 800 3000 10000
# Apply route dampening policies to the routes that flap.

[~DeviceC] bgp 300
[*DeviceC-bgp-af-ipv4] dampening route-policy dampen-policy
[~DeviceC-bgp] quit
# Check the configured route dampening parameters on Device C.

[~DeviceC] display bgp routing-table dampening parameter
Maximum Suppress Time(in second) : 3973

Ceiling Value : 16000
Reuse Value : 750
HalfLife Time(in second) : 900
Suppress-Limit : 2000
Route-policy : dampen-policy
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
undo shutdown
ip address 8.1.1.1 255.0.0.0
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
network 8.0.0.0 255.0.0.0
#
return

#
sysname DeviceB
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
undo shutdown
ip address 9.1.1.1 255.255.255.0

#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return
#
sysname DeviceC
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
undo shutdown
ip address 200.1.3.2 255.255.255.0
#
bgp 300
router-id 3.3.3.3
#
ipv4-family unicast
dampening route-policy dampen-policy
#
route-policy dampen-policy permit node 10
if-match ip-prefix prefix-a
apply dampening 10 1000 2000 5000
#
route-policy dampen-policy permit node 20
if-match ip-prefix prefix-b
apply dampening 10 800 3000 10000
#
ip ip-prefix prefix-a index 10 permit 8.0.0.0 8
#
ip ip-prefix prefix-b index 20 permit 9.1.1.0 24
#
return
#
sysname DeviceB
#
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
bgp 400
router-id 4.4.4.4
#
ipv4-family unicast

#
return
10.37.10 Example for Configuring BGP Default Route

Advertisement
By controlling the advertising of default routes, you can specify traffic from a specific path to
enter ASs.
In Figure 10-45, all routers run BGP. To ensure that the traffic that leaves AS 200 is
forwarded by Device E and Device F, EBGP connections are established between Device A
and Device B, between Device C and Device E, and between Device D and Device F; IBGP
connections are established between Device B and Device C, and between Device B and
Device D.
Figure 10-45 Configuring BGP default route advertisement

NOTE
AS100
DeviceA
interface1
interface1
DeviceB AS200
DeviceC DeviceD
DeviceE DeviceF
AS300 AS400
Device A GE 1/0/0 200.1.1.1/24
Loopback 0 1.1.1.1/32
Device B GE 1/0/0 200.1.1.2/24
GE 2/0/0 9.1.1.1/24

GE 3/0/0 9.1.3.2/24
Loopback 0 2.2.2.2/32
Device C GE 1/0/0 200.1.2.2/24
GE 2/0/0 9.1.1.2/24
GE 3/0/0 9.1.2.1/24
Loopback 0 3.3.3.3/32
Device D GE 1/0/0 200.1.3.2/24
GE 2/0/0 9.1.3.1/24
GE 3/0/0 9.1.2.2/24
Loopback 0 4.4.4.4/32
Device E GE 1/0/0 200.1.2.1/24
GE 2/0/0 10.1.1.1/24
Loopback 0 5.5.5.5/32
Device F GE 1/0/0 200.1.3.1/24
GE 2/0/0 11.1.1.1/24
Loopback 0 6.6.6.6/32
Precautions
When configuring BGP to advertise default routes, note the following rules:
l Default routes have two functions. They can represent all network routes. For example,
in a stub AS, instead of advertising all network routes, you can use only a default route
to forward traffic destined outside the stub AS. In addition, they can represent all routes
except specific routes; for example, they can be used in the multi-home load balancing
scenario.
l When establishing a peer relationship, if the specified IP address of the peer is a
loopback interface address or a sub-interface address, run the peer connect-interface
command on the both ends to ensure that the two ends are correctly connected.
1. Configure OSPF on Device B, Device C, and Device D.
2. Establish EBGP connections between Device A and Device B, between Device C and
Device E, and between Device D and Device F.

3. Establish IBGP connections between Device B and Device C, and between Device B and
Device D.
4. Configure an import routing policy on Device C to accept only default routes.
5. Configure an import routing policy on Device D to accept default routes and all specific
routes, and then set Local_Pref values for the accepted default routes.
Data Preparation
l Router IDs and AS numbers of Device A, Device B, Device C, Device D, Device E, and
Device F
l Names of the import routing policies to be configured on Device C and Device D
l Local_Pref values to be set for the accepted default routes on Device D
Procedure
in this section.
[~DeviceB] ospf 1
[~DeviceC] ospf 1
[~DeviceD] ospf 1
[*DeviceD-ospf-1] area 0
[*DeviceD-ospf-1-area-0.0.0.0] commit
[~DeviceD-ospf-1-area-0.0.0.0] quit
[~DeviceD-ospf-1] quit

[~DeviceA] bgp 100

[~DeviceA-bgp] quit
[~DeviceB] bgp 200
[*DeviceB-bgp] network 200.1.1.0 24
[~DeviceB-bgp] quit
[~DeviceC] bgp 200
[*DeviceC-bgp] network 200.1.2.0 24
[~DeviceC-bgp] quit
[~DeviceD] bgp 200
[*DeviceD-bgp] network 200.1.3.0 24
[~DeviceD-bgp] quit
[~DeviceE] bgp 300
[*DeviceE-bgp] network 10.1.1.0 24
[~DeviceE-bgp] quit
# Configure Device F.
[~DeviceF] bgp 400
[*DeviceF-bgp] router-id 6.6.6.6
[*DeviceF-bgp] peer 200.1.3.2 as-number 200
[*DeviceF-bgp] network 11.1.1.0 24
[*DeviceF-bgp] commit
[~DeviceF-bgp] quit
Step 4 Configure Device E and Device F to advertise default routes.
# Configure Device E to advertise default routes.

[~DeviceE-bgp] ipv4-family unicast
[*DeviceE-bgp-af-ipv4] peer 200.1.2.2 default-route-advertise
[*DeviceE-bgp-af-ipv4] commit
# Configure Device F to advertise default routes.

[~DeviceF-bgp] ipv4-family unicast
[*DeviceF-bgp-af-ipv4] peer 200.1.3.2 default-route-advertise
[*DeviceF-bgp-af-ipv4] commit




*>i 0.0.0.0 200.1.2.1 0 100 0 300i

* i 200.1.3.1 0 100 0 400i
*>i 10.1.1.0/24 200.1.2.1 0 100 0 300i
*>i 11.1.1.0/24 200.1.3.1 0 100 0 400i
*> 200.1.1.0 0.0.0.0 0 0 i
*>i 200.1.2.0 3.3.3.3 0 100 0 i
*>i 200.1.3.0 4.4.4.4 0 100 0 i
The command output shows that Device B has received the default routes and all specific
routes of AS 300 and AS 400.
Step 5 Configure import routing policies.
# Configure an IP prefix list named default on Device C to accept only default routes.
[~DeviceC] ip ip-prefix default permit 0.0.0.0 0
[*DeviceC] commit
[*DeviceC] bgp 200
[*DeviceC-bgp] peer 200.1.2.1 ip-prefix default import
# Configure a route-policy named set-default-low on Device D to accept default routes and

all specific routes, and set Local_Pref values for the accepted default routes.
[~DeviceD] ip as-path-filter 10 permit ^(400_)+$
[*DeviceD] ip as-path-filter 10 permit ^(400_)+_[0-9]+$
[*DeviceD] ip ip-prefix default permit 0.0.0.0 0
[*DeviceD] route-policy set-default-low permit node 10
[*DeviceD-route-policy] if-match ip-prefix default
[*DeviceD-route-policy] apply local-preference 80
[*DeviceD-route-policy] quit
[*DeviceD] route-policy set-default-low permit node 20
[*DeviceD-route-policy] quit
[*DeviceD] commit
[~DeviceD] bgp 200
[*DeviceD-bgp] peer 200.1.3.1 as-path-filter 10 import
[*DeviceD-bgp] peer 200.1.3.1 route-policy set-default-low import



*>i 0.0.0.0 200.1.2.1 0 100 0 300i

* i 200.1.3.1 0 80 0 400i
*>i 11.1.1.0/24 200.1.3.1 0 100 0 400i
*> 200.1.1.0 0.0.0.0 0 0 i

*>i 200.1.2.0 3.3.3.3 0 100 0 i

*>i 200.1.3.0 4.4.4.4 0 100 0 i
The command output shows that Device B has received only the default routes of AS 300 and
the default routes and all specific routes of AS 400 and that the Local_Pref of the accepted
default routes destined of AS 400 has been set to 80.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
#
return

#
sysname DeviceB
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 9.1.3.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 200.1.1.0 255.255.255.0
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.3.0 0.0.0.255

#
return
#
sysname DeviceC
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
undo shutdown
ip address 9.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 200.1.2.0 255.255.255.0
peer 2.2.2.2 enable
peer 200.1.2.1 ip-prefix default import
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.2.0 0.0.0.255
#
ip ip-prefix default index 10 permit 0.0.0.0 0
#
return
#
sysname DeviceD
#
undo shutdown
ip address 200.1.3.2 255.255.255.0
#
undo shutdown
ip address 9.1.2.2 255.255.255.0
#
undo shutdown
ip address 9.1.3.1 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 200.1.3.0 255.255.255.0
peer 2.2.2.2 enable


peer 200.1.3.1 as-path-filter 10 import
peer 200.1.3.1 route-policy set-default-low import
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 9.1.2.0 0.0.0.255
network 9.1.3.0 0.0.0.255
#
route-policy set-default-low permit node 10
if-match ip-prefix default
#
route-policy set-default-low permit node 20
#
ip ip-prefix default index 10 permit 0.0.0.0 0
#
ip as-path-filter 10 permit ^(400_)+$
ip as-path-filter 10 permit ^(400_)+_[0-9]+$
#
return
l Device E configuration file
#
sysname DeviceE
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
#
bgp 300
#
ipv4-family unicast
network 10.1.1.0 255.255.255.0
peer 200.1.2.2 default-route-advertise
#
return
l Device F configuration file of
#
sysname DeviceF
#
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 6.6.6.6 255.255.255.255
#
bgp 400
#
ipv4-family unicast
network 11.1.1.0 255.255.255.0
peer 200.1.3.2 default-route-advertise

#
return
10.37.11 Example for Configuring BGP Load Balancing

Configuring load balancing can fully utilize network resources and reduce network
congestion.
In Figure 10-46, all routers run BGP; Device A resides in AS 100; Device B and Device C
reside in AS 300; Device D resides in AS 200. EBGP connections are established between
Device A and Device B, between Device A and Device C, between Device D and Device B,
and between Device D and Device C. On Device A, there are two BGP routes to 8.1.1.0/24.
Traffic to 8.1.1.0/24 can reach the destination through Device B and Device C. It is required
that BGP load balancing be configured to fully utilize network resources and reduce network
congestion.
Figure 10-46 Configuring BGP load balancing

NOTE
DeviceA AS100
200.1.1.1/24 200.1.2.1/24
Interface1 interface2
200.1.1.2/24 200.1.2.2/24
DeviceB DeviceC
AS300
200.1.3.2/24 200.1.4.2/24
200.1.3.1/24 200.1.4.1/24
interface3
AS200 8.1.1.1/24
DeviceD

Precautions
You can implement load balancing by setting BGP attributes. For example, you can ignore the
comparison of MED values, route types, or IGP metrics. Perform these configurations only
when you can ensure that no routing loops will occur. This solution is not recommended on
the public network, especially on the transit AS.
1. Establish EBGP connections between Device A and Device B, and between Device A
and Device C, and establish an IBGP connection between Device B and Device C.
2. Establish EBGP connections between Device D and Device B, and between Device D
and Device C.
3. Configure load balancing on Device A and then check routes.
Data Preparation
l Number of routes for load balancing
Procedure
in this section.
[~DeviceA] bgp 100
[~DeviceA-bgp] quit
[~DeviceB] bgp 300
[~DeviceB-bgp] quit
[~DeviceC] bgp 300
[~DeviceC-bgp] quit
[~DeviceD] bgp 200


[*DeviceD-bgp] ipv4-family unicast
[*DeviceD-bgp-af-ipv4] network 8.1.1.0 255.255.255.0
[*DeviceD-bgp-af-ipv4] commit
[~DeviceD-bgp-af-ipv4] quit
[~DeviceD-bgp] quit


From: 200.1.1.2 (2.2.2.2)
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 200 300, origin igp, pref-val 0, valid, external, pre 255, not preferred
for router ID
The command output shows that there are two valid routes from Device A to 8.1.1.0/24. The
route with the next hop 200.1.1.2 is the optimal route because the router ID of Device B is
smaller.
Step 3 Configure load balancing.
# Configure load balancing on Device A.
[~DeviceA] bgp 100
[*DeviceA-bgp-af-ipv4] maximum load-balancing 2
[~DeviceA-bgp] quit


From: 200.1.1.2 (2.2.2.2)

200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 200 300, origin igp, pref-val 0, valid, external, select, pre 255, not
The command output shows that the BGP route to 8.1.1.0/24 has two next hops, 200.1.1.2 and
200.1.2.2, both of which are preferred.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
maximum load-balancing 2
#
return

#
sysname DeviceB
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
ip address 200.1.3.2 255.255.255.0
#
bgp 300
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname DeviceC
#
undo shutdown
ip address 200.1.4.2 255.255.255.0
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
bgp 300
router-id 3.3.3.3
#
ipv4-family unicast
#
return

#
sysname DeviceD
#
undo shutdown
ip address 200.1.4.1 255.255.255.0
#
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
undo shutdown
ip address 8.1.1.1 255.255.255.0
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
#
return
10.37.12 Example for Configuring BGP Next Hop Iteration Based

on a Routing Policy
Configuring BGP next hop iteration based on a routing policy prevents traffic loss in case of
route changes.
As shown in Figure 1, OSPF runs in AS 100. An IBGP peer relationship is established
between Loopback 0s of Device A and Device B, and between Loopback 0s of Device A and
Device C. Device B and Device C both receive BGP routes destined for 200.1.1.0/24.
Because the router ID of Device B is smaller than that of Device C, Device A chooses the

route that is learned from Device B as the optimal route with the original next hop of
2.2.2.2/32.
In most cases, Device A iterates the next hop of the BGP route destined for 200.1.1.0/24 to an
IGP route destined for 2.2.2.2/32 with GE 1/0/00 as the outbound interface. When Device B is
faulty, Device A deletes the IGP route destined for 2.2.2.2/32 immediately. However, Device
A still considers the BGP route with 2.2.2.2/32 as the original next hop the optimal route
because it does not know the BGP route change before the BGP hold timer expires. Based on
the longest matching rule, Device A mistakenly iterates the BGP route destined for
200.1.1.0/24 to the direct route destined for 2.2.2.0/24 with GE 1/0/2 as the outbound
interface, causing traffic loss.
Figure 10-47 Networking diagram for configuring BGP next hop iteration based on a routing
policy
NOTE
Interfaces 1 through 4 in this example are GE 1/0/0, GE 1/0/1, GE 1/0/2, Loopback0, respectively.
interface4
2.2.2.2/32
DeviceB
Interface1
11.1.1.2/24
1.1.1.1/32 11.1.1.1/24
interface3
2.2.2.10/24 200.1.1.0/24
DeviceA interface2
11.1.2.1/24
interface2
11.1.2.2/24 DeviceC
interface4
3.3.3.3/32
To prevent traffic loss, configure BGP next hop iteration based on a routing policy on Device
A to control the iterated routes. In this example, only the iterated routes with a mask length of
32 bits are not filtered out by the routing policy, and the iterated routes that are filtered out by
the routing policy are considered unreachable. Therefore, when Device B is faulty, the route
change can be detected in time, and a correct route is re-selected, preventing traffic loss.
Precautions
When configuring BGP next hop iteration based on a routing policy, note the following:
l Ensure that all desirably iterated routes cannot be filtered out by the routing policy. If
some desirably iterated routes are filtered out by the routing policy, the BGP route may
be considered unreachable by mistake and traffic cannot be forwarded over the route.

1. Configure OSPF on Device A, Device B, and Device C to enable them to communicate

with each other.
2. Establish an IBGP peer relationship between Loopback 0s of Device A and Device B,
and between Loopback 0s of Device A and Device C.
3. Enable Device B and Device C to advertise a BGP route destined for 200.1.1.0/24 to
Device A.
4. Configure BGP next hop iteration based on a routing policy on Device A. This
configuration allows Device A to know the route change in time when Device B is faulty
and re-select a correct BGP route, preventing traffic loss.
Data Preparation
l Router IDs of Device A, Device B, and Device C (1.1.1.1, 2.2.2.2, and 3.3.3.3,
respectively) and AS number (100)
l Routing policy (np-by-rp) configured on Device A to control route iteration.
Procedure
Step 1 Configure an IP address for each interface. For configuration details, see Configuration File.
Step 2 Configure OSPF in AS 100.
[~DeviceA] ospf 1
[*DeviceA-ospf-1] area 0
[*DeviceA-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[*DeviceA-ospf-1-area-0.0.0.0] network 11.1.0.0 0.0.255.255
[*DeviceA-ospf-1-area-0.0.0.0] commit
[~DeviceA-ospf-1-area-0.0.0.0] quit
[~DeviceA-ospf-1] quit
[~DeviceB] ospf 1
[~DeviceC] ospf 1
Step 3 Establish IBGP connections.

[~DeviceA] bgp 100

[*DeviceA-bgp] peer 2.2.2.2 connect-interface Loopback 0

[*DeviceA-bgp] peer 3.3.3.3 connect-interface Loopback 0
[~DeviceA-bgp] quit
[~DeviceB] bgp 100
[*DeviceB-bgp] peer 1.1.1.1 connect-interface Loopback 0
[~DeviceB-bgp] quit
[~DeviceC] bgp 100
[*DeviceC-bgp] peer 1.1.1.1 connect-interface Loopback 0
[~DeviceC-bgp] quit
Step 4 Enable Device B and Device C to advertise a BGP route destined for 200.1.1.0/24 to Device
A.
[~DeviceB] ip route-static 200.1.1.0 24 NULL 0
[*DeviceB] commit
[~DeviceB] bgp 100
[*DeviceB-bgp] import-route static
[~DeviceB-bgp] quit
[~DeviceC] ip route-static 200.1.1.0 24 NULL 0
[*DeviceC] commit
[~DeviceC] bgp 100
[*DeviceC-bgp] import-route static
[~DeviceC-bgp] quit
Step 5 Configure BGP next hop iteration based on a routing policy on Device A.
[~DeviceA] bgp 100
[*DeviceA-bgp] nexthop recursive-lookup route-policy np-by-rp
[~DeviceA-bgp] quit
[~DeviceA] route-policy np-by-rp permit node 0
[*DeviceA-route-policy] if-match ip-prefix np-by-rp-ip
[*DeviceA-route-policy] commit
[~DeviceA-route-policy] quit
[~DeviceA] ip ip-prefix np-by-rp-ip permit 0.0.0.0 32
[*DeviceA] commit

# Display detailed information about the BGP route destined for 200.1.1.0/24 on Device A
when Device B is running properly.



From: 2.2.2.2 (2.2.2.2) Route Duration: 0d00h00m36s

internal, pre 255,
# Run the shutdown command on GE 1/0/0 of Device B to simulate a fault.

[~DeviceB] interface GigabitEthernet 1/0/0
[~DeviceB-GigabitEthernet1/0/0] shutdown
[*DeviceB-GigabitEthernet1/0/0] commit
[~DeviceB-GigabitEthernet1/0/0] quit
# Display detailed information about the BGP route destined for 200.1.1.0/24 on Device A.


Relay IP Out-interface:
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, internal, pre
255
When Device B is faulty, the original next hop (2.2.2.2/32) of the route destined for
200.1.1.0/24 is iterated to 2.2.2.10/24. However, the mask length of 2.2.2.10/24 is not 32 bits,
causing the route is filtered out by the routing policy named np-by-rp. As a result, the route is
considered unreachable. Then, Device A re-selects the correct route with 3.3.3.3/32 as the
original next hop.
----End
Configuration Files
#

sysname DeviceA
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
#
undo shutdown
ip address 11.1.2.1 255.255.255.0
#
undo shutdown
ip address 2.2.2.10 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
nexthop recursive-lookup route-policy np-by-rp
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 11.1.0.0 0.0.255.255
#
route-policy np-by-rp permit node 10
if-match ip-prefix np-by-rp-ip
#
ip ip-prefix np-by-rp-ip index 10 permit 0.0.0.0 32
#
return

#
sysname DeviceB
#
undo shutdown
ip address 11.1.1.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
import-route static
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 11.1.1.0 0.0.0.255
#
ip route-static 200.1.1.0 24 NULL 0

#
return
l Configuration file of Device C

#
sysname DeviceC
#
undo shutdown
ip address 11.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
import-route static
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 11.1.2.0 0.0.0.255
#
ip route-static 200.1.1.0 24 NULL 0
#
return
10.37.13 Example for Configuring BFD for BGP

After BFD for BGP is configured, BFD can fast detect the link fault between BGP peers and
notify it to BGP so that service traffic can be transmitted along the backup link.
Voice and video services have high requirements for network reliability and stability. If a fault
occurs on a network, quick service recovery is required (within 50 ms). BFD for BGP can
meet this requirement.
In Figure 10-48, a primary link and a backup link are deployed on the network to ensure
service transmission reliability. EBGP peer relationships are established between indirectly
connected Device A and Device B, and between indirectly connected Device A and Device C.
In most cases, traffic is transmitted along the primary link between Device A and Device B. If
the primary link fails, it is required that BGP quickly detect this failure and switch traffic to
the backup link (Device A -> Device C -> Device B).
BFD for BGP can be configured to speed up the link switchover. If the primary link between
Device A and Device B fails, BFD can quickly detect the change in the BGP peer relationship
and notify BGP of the change. Service traffic then will be switched to the backup link for
transmission.
Figure 10-48 Configuring BFD for BGP

NOTE

GE 3/0/0
172.16.1.1/24
GE 2/0/0
200.1.1.2/24
EBGP GE 1/0/0
GE 1/0/0 RouterB 9.1.1.1/24
AS 100 200.1.1.1/24
RouterA
IBGP AS 200
GE 2/0/0
200.1.2.1/24 EBGP
GE 1/0/0
9.1.1.2/24
GE 2/0/0
200.1.2.2/24 RouterC
NOTE
If two routers establish an EBGP peer relationship over a direct link, BFD for BGP is not required
because the ebgp-interface-sensitive command is enabled by default for directly connected EBGP
peers.
Precautions
When configuring BFD for BGP, note the following rules:
l Before configuring BFD for BGP, enable BFD globally.

l When configuring BFD for BGP, ensure that parameters configured on the two ends of a
BFD session are consistent.
1. Configure basic BGP functions on each router.

2. Configure the MED attribute to control route selection.
3. Enable BFD on Device A and Device B
Data Preparation
l Router IDs and AS numbers of Device A, Device B, and Device C

l Peer IP address to be detected by BFD
l Minimum interval at which BFD Control packets are received and sent and the local
detection multiplier

Procedure
Step 1 Configure an IP address for each interface on the routers. For configuration details, see
Configuration Files in this section.
Step 2 Configure basic BGP functions, establish EBGP connections between Device A and Device
B, and between Device A and Device C, and establish an IBGP connection between Device B
and Device C.
[~DeviceA] bgp 100
[*DeviceA-bgp] peer 200.1.1.2 ebgp-max-hop
[*DeviceA-bgp] peer 200.1.2.2 ebgp-max-hop
[~DeviceA-bgp] quit
[~DeviceB] bgp 200
[*DeviceB-bgp] peer 200.1.1.1 ebgp-max-hop
[*DeviceB-bgp] network 172.16.1.0 255.255.255.0
[~DeviceB-bgp] quit
[~Devicec] bgp 200
[*Devicec-bgp] router-id 3.3.3.3
[*Devicec-bgp] peer 200.1.2.1 as-number 100
[*Devicec-bgp] peer 200.1.2.1 ebgp-max-hop
[*Devicec-bgp] peer 9.1.1.1 as-number 200
[*Devicec-bgp] commit
[~Devicec-bgp] quit
# Display peer information on Device A. The following command output shows that the BGP
peer relationship has been established.
<DeviceA> display bgp peer
200.1.1.2 4 200 2 5 0 00:01:25 Established 0
200.1.2.2 4 200 2 4 0 00:00:55 Established 0
Step 3 Configure the MED attribute.

# Configure a route-policy to set the MED value for the routes that Device B and Device C
send to Device A.
[~DeviceB] route-policy 10 permit node 10
[*DeviceB-route-policy] commit
[~DeviceB-route-policy] quit
[~DeviceB] bgp 200
[*DeviceB-bgp] peer 200.1.1.1 route-policy 10 export

[~DeviceC] route-policy 10 permit node 10

[*DeviceC-route-policy] apply cost 150
[~DeviceC] bgp 200
[*DeviceC-bgp] peer 200.1.2.1 route-policy 10 export

*> 172.16.1.0/24 200.1.1.2 100 0 200i
* 200.1.2.2 150 0 200i
The command output shows that the next hop address of the route to 172.16.1.0/24 is
200.1.1.2 and that traffic is transmitted on the primary link Device A→Device B.
Step 4 Configure BFD, and set the interval at which BFD Control packets are received and sent and
the local detection multiplier.
# Enable BFD on Device A, set the minimum interval at which BFD Control packets are
received and sent to 100 ms, and set the local detection multiplier to 4.
[~DeviceA] bfd
[*DeviceA-bfd] quit
[*DeviceA] bgp 100
[*DeviceA-bgp] peer 200.1.1.2 bfd enable
[*DeviceA-bgp] peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
# Enable BFD on Device B, set the minimum interval at which BFD Control packets are
received and sent to 100 ms, and set the local detection multiplier to 4.
[~DeviceB] bfd
[*DeviceB-bfd] quit
[*DeviceB] bgp 200
[*DeviceB-bgp] peer 200.1.1.1 bfd enable
[*DeviceB-bgp] peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
# Check all the BFD sessions established on Device A.

<DeviceA> display bgp bfd session all
--------------------------------------------------------------------------------
Local_Address Peer_Address Interface
200.1.1.1 200.1.1.2 GigibitEthernet1/0/0
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 4 Up
Wtr-interval(m)
10
--------------------------------------------------------------------------------

# Run the shutdown command on GE 2/0/0 of Device B to simulate a fault on the primary
link.
[~DeviceB] interface gigabitethernet 2/0/0
[~DeviceB-GigabitEthernet2/0/0] shutdown

[*DeviceB-GigabitEthernet2/0/0] commit

*> 172.16.1.0/24 200.1.2.2 150 0 200i
The command output shows that the backup link Device A→Device C→Device B takes
effect after the primary link fails and that the next hop address of the route to 172.16.1.0/24
has become 200.1.2.2.
----End
Configuration Files
#
sysname DeviceA
#
bfd
#
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
peer 200.1.1.2 ebgp-max-hop 255
peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4
peer 200.1.1.2 bfd enable
#
ipv4-family unicast
#
return

#
sysname DeviceB
#
bfd
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#

undo shutdown
ip address 172.16.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4
#
ipv4-family unicast
network 172.16.1.0 255.255.255.0
peer 9.1.1.2 enable
#
apply cost 100
#
return

#
sysname DeviceC
#
bfd
#
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.1.1 enable
#
apply cost 150
#
return
10.37.14 Example for Configuring BGP Auto FRR

BGP Auto FRR provides backup forwarding entries for the optimal route, minimizing the
delay for important services.
As networks evolve continuously, voice, on-line video, and financial services raise
increasingly high requirements for real-time performance. Usually, primary and backup links
are deployed on a network to ensure the stability of these services. If the primary link fails,

the router needs to wait for route convergence to be completed. After that, the router reselects
an optimal route and delivers the reselected route to the FIB table to start a link switchover.
This is the traditional switchover mode. In this mode, service interruption lasts a long time,
which does not meet the services' requirement.
BGP Auto FRR addresses this problem. After BGP Auto FRR is enabled on a router, the
router selects the optimal route to forward packets. In addition, the router automatically adds
information about the sub-optimal route to the backup forwarding entries of the optimal route
and delivers the backup forwarding entries to the FIB table. If the primary link fails, the router
quickly switches traffic to the backup link. The switchover does not depend on route
convergence and reduces service interruption time. The switchover can be performed within
sub-seconds.
As shown in Figure 10-49, Device A belongs to AS 100; Device B, Device C, and Device D
belong to AS 200. BGP Auto FRR needs to be configured to ensure that the route from
Device A to DeviceD has the backup route.
Figure 10-49 Configuring BGP Auto FRR

NOTE
Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, Loopback1, respectively.
AS200
11.1.1.2/24 11.3.1.1/24
AS100
DeviceB
11.1.1.1/24 11.3.1.2/24
DeviceA interface3
DeviceD
4.4.4.4/32
interface2
DeviceC interface2
11.2.1.1/24
11.4.1.2/24
11.2.1.2/24 11.4.1.1/24
Precautions
When configuring BGP Auto FRR, note the following rules:
l When configuring BGP FRR, ensure that there are at least two routes to the same
destination network segment.
l The name of a route-policy is case sensitive.

1. Configure EBGP connections between Device A and Device B, and between Device A
and Device C. Configure IBGP connections between Device D and Device B, and
between Device D and Device C.
2. Configure route-policies on Device B and Device C to change the MED values of routes
to Device D for route selection.
3. Configure BGP Auto FRR on Device A.
Data Preparation
l Names of route-policies and MED values of routes on Device B and Device C
Procedure
in this section.
Step 2 Configure EBGP connections between Device A and Device B, and between Device A and
Device C, and configure IBGP connections between Device B and Device D, and between
Device C and Device D.
# Configure EBGP connections on Device A.
<DeviceA> system-view
[~DeviceA] bgp 100
NOTE
The configurations on Device B and Device C are similar to the configuration on Device A.
# Configure IBGP connections on Device D.

<DeviceD> system-view
[~DeviceD] bgp 200
NOTE
The configurations on Device B and Device C are similar to the configuration on Device D.
Step 3 Configure BFD for BGP on Device A, Device B, Device C and Device D.
# Configure BFD for BGP on Device A.
[~DeviceA] bfd
[*DeviceA-bfd] quit
[*DeviceA] bgp 100
multiplier 4


multiplier 4
[~DeviceA-bgp] quit
[~DeviceA] quit
NOTE
The configurations on Device B, Device C and Device D are similar to the configuration on Device A.
Step 4 Configure route-policies on Device B and Device C to ensure that the MED values of routes
to Device D are different.
# Configure a route-policy on Device B.
<DeviceB> system-view
[~DeviceB] route-policy rtb permit node 10
[*DeviceB-route-policy] quit
[*DeviceB] bgp 200
[*DeviceB-bgp-af-ipv4] peer 11.1.1.1 route-policy rtb export
# Configure a route-policy on Device C.

<DeviceC> system-view
[~DeviceC] route-policy rtc permit node 10
[*DeviceC-route-policy] apply cost 120
[*DeviceC-route-policy] quit
[*DeviceC] bgp 200
[*DeviceC-bgp-af-ipv4] peer 11.2.1.1 route-policy rtc export
# Advertise a route to 4.4.4.4/32 on Device D.

[~DeviceD] bgp 200
[*DeviceD-bgp] ipv4-family unicast
[*DeviceD-bgp] network 4.4.4.4 32
# Run the display ip routing-table verbose command on Device A to check detailed

information about the route to 4.4.4.4/32 it learns.
<DeviceA> display ip routing-table 4.4.4.4 32 verbose
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1
IndirectID: 0x4
Because the MED value of the route learned from Device B is smaller, Device A selects the
path Device A→Device B→Device D to transmit traffic to 4.4.4.4/32. Because FRR has not
been configured yet, no information about the backup route is available.

Step 5 Enable BGP Auto FRR on Device A, and check the routing information.
# Enable BGP Auto FRR on Device A.
[~DeviceA] bgp 100
[*DeviceA-bgp-af-ipv4] auto-frr
# Run the display ip routing-table verbose command on Device A to check the routing
information.
<DeviceA> display ip routing-table 4.4.4.4 32 verbose
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1
IndirectID: 0x4
BkNextHop: 11.2.1.2 BkInterface: GigabitEthernet2/0/0
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x2
The preceding information shows the backup next hop and outbound interface of the backup
route to 4.4.4.4/32
----End
Configuration Files
#
sysname DeviceA
#
bfd
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
#
undo shutdown
ip address 11.2.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
peer 11.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
ipv4-family unicast

auto-frr
#
return
#
sysname DeviceB
#
bfd
#
undo shutdown
ip address 11.1.1.2 255.255.255.0
#
undo shutdown
ip address 11.3.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
peer 11.1.1.1 route-policy rtb export
#
route-policy rtb permit node 10
apply cost 80
#
return
#
sysname DeviceC
#
bfd
#
undo shutdown
ip address 11.2.1.2 255.255.255.0
#
undo shutdown
ip address 11.4.1.1 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
peer 11.2.1.1 route-policy rtc export
#

route-policy rtc permit node 10

apply cost 120
#
return

#
sysname DeviceD
#
bfd
#
undo shutdown
ip address 11.3.1.2 255.255.255.0
#
undo shutdown
ip address 11.4.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
#
return
10.37.15 Example for Configuring BGP Best-external

BGP Best-external enables a backup device to select the sub-optimal route and send the route
to its BGP peers if the route preferentially selected based on BGP route selection policies is
an IBGP route advertised by the master device. Therefore, BGP Best-external speeds up BGP
route convergence if the primary link fails.
If master and backup provider edges (PEs) or RRs are deployed, routes are selected based on
BGP route selection policies, and the primary link fails, the BGP route convergence takes a
long time because no backup route is available. To address this problem, configure BGP Best-
external.
In the networking shown in Figure 10-50, an EBGP peer relationship is established between
Device A and Device B. In addition, an IBGP peer relationship is established between each
two devices among RR1, RR2, Device B, and Device C except between Device B and Device
C. Device B is a client of RR1 and RR2. RR1 has a greater Local_Pref value than RR2, and
therefore RR1 is the master device while RR2 is the backup device. RR1 and RR2 receive the
same route to 1.1.1.1/24 from Device B.
To ensure that traffic can be immediately switched to a backup link if the primary link fails,
configure BGP Best-external on RR2 so that RR2 can select the Best-external route
(advertised by Device B) and advertise it to its peers.

Figure 10-50 Configuring BGP Best-external

NOTE
respectively.
RR1
AS 65009
AS 65008
DeviceB DeviceC
1.1.1.1 interface1
interface1
DeviceA interface5 interface2 interface3
RR2
Precautions
BGP Best-external route selection and advertisement must be configured so that the BGP
Best-external function takes effect.
2. Configure a route-policy and a Local_Pref value greater than the default value 100 for
RR1.
3. Enable BGP Best-external on RR2.
Data Preparation
l Router IDs of Device A, Device B, Device C, RR1, and RR2, and their AS numbers, as
listed in Table 10-29
l Route-policy and Local_Pref configured for RR1
Table 10-29 Configurations of each device

Device Router ID Interface IP Address AS Number
Number
GigabitEthernet 172.10.1.1/24
Device A 1.1.1.1 3/0/1 AS 65008
LoopBack0 1.1.1.1/32


Number
3/0/1
Device B 2.2.2.2 AS 65009
3/0/2
1/0/2
3/0/1
Device C 3.3.3.3 AS 65009
3/0/3
3/0/2
RR 1 4.4.4.4 AS 65009
3/0/1
1/0/1
1/0/2
RR 2 5.5.5.5 AS 65009
3/0/3
3/0/2
Procedure
Step 1 Configure an IP address for each interface on the router. For configuration details, see
Step 2 Configure basic BGP functions. Establish an EBGP peer relationship between Device A and
Device B, and an IBGP peer relationship between each two devices among RR1, RR2, Device
B, and Device C except between Device B and Device C. Configure Device B as a client of
RR1 and RR2.
[~DeviceA-bgp] quit


[~DeviceB-bgp] quit
[~DeviceC-bgp] quit
[~DeviceC] quit
# Configure RR1.
[~RR1] bgp 65009
[*RR1-bgp] router-id 4.4.4.4
[*RR1-bgp] peer 172.10.2.1 as-number 65009
[*RR1-bgp] peer 172.10.2.1 reflect-client
[*RR1-bgp] import-route direct
[*RR1-bgp] commit
[~RR1-bgp] quit
# Configure RR2.
[~RR2] bgp 65009
[*RR2-bgp] router-id 5.5.5.5
[*RR2-bgp] peer 172.10.3.1 reflect-client
[*RR2-bgp] import-route direct
[*RR2-bgp] commit
[~RR2-bgp] quit
Step 3 Set the Local-Pref value to 130 for RR1.

# Configure RR1.
[~RR1] route-policy policy1 permit node 10
[*RR1-route-policy] apply local-preference 130
[*RR1-route-policy] commit
[~RR1-route-policy] quit
[~RR1] bgp 65009
[*RR1-bgp] peer 172.10.6.2 route-policy policy1 export
[*RR1-bgp] peer 172.10.4.2 route-policy policy1 export
[*RR1-bgp] reflect change-path-attribute
[*RR1-bgp] commit
[~RR1-bgp] quit
# Check information about the route to 1.1.1.1 on Device C.

<DeviceC> display bgp routing-table 1.1.1.1
Paths: 1 available, 1 best, 1 select, 0 best-external
From: 172.10.4.1 (4.4.4.4)


AS-path 65008, origin incomplete, MED 0, localpref 130, pref-val 0, valid,
Originator: 2.2.2.2
The command output shows that Device C has only one BGP route to 1.1.1.1 and that the
route is advertised by RR1.
Step 4 Configure BGP Best-external on RR2.
# Configure RR2.
[~RR2] bgp 65009
[*RR2-bgp] bestroute best-external
[*RR2-bgp] peer 172.10.5.1 advertise best-external
[*RR2-bgp] commit
[~RR2-bgp] quit
# Check information about the route to 1.1.1.1 on Device C.

<DeviceC> display bgp routing-table 1.1.1.1
Paths: 2 available, 1 best, 1 select, 0 best-external
From: 172.10.4.1 (4.4.4.4)
AS-path 65008, origin incomplete, MED 0, localpref 130, pref-val 0, valid,
Originator: 2.2.2.2

From: 172.10.5.2 (5.5.5.5)
AS-path 65008, origin incomplete, MED 0, localpref 100, pref-val 0, valid, inte
rnal, pre 255, not preferred for Local_Pref
Originator: 2.2.2.2
The command output shows that Device C has a BGP route to 1.1.1.1 (the BGP Best-external
route advertised by RR2) in addition to the route advertised by RR1.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
ip address 172.10.1.1 255.255.255.0
#

interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 65008
router-id 1.1.1.1
peer 172.10.1.2 as-number 65009
#
ipv4-family unicast
import-route direct
#
return
#
sysname DeviceB
#
undo shutdown
ip address 172.10.1.2 255.255.255.0
#
undo shutdown
ip address 172.10.2.1 255.255.255.0
#
undo shutdown
ip address 172.10.3.1 255.255.255.0
#
bgp 65009
#
router-id 2.2.2.2
peer 172.10.1.1 as-number 65008
peer 172.10.2.2 as-number 65009
peer 172.10.3.2 as-number 65009
#
ipv4-family unicast
import-route direct
#
return
#
sysname DeviceC
#
undo shutdown
ip address 172.10.4.2 255.255.255.0
#
undo shutdown
ip address 172.10.5.1 255.255.255.0
#
bgp 200
router-id 3.3.3.3
peer 172.10.4.1 as-number 65009
peer 172.10.5.2 as-number 65009
#
ipv4-family unicast
import-route direct
#
return

l RR1 configuration file

#
sysname RR1
#
undo shutdown
ip address 172.10.4.1 255.255.255.0
#
undo shutdown
ip address 172.10.2.2 255.255.255.0
#
undo shutdown
ip address 172.10.6.1 255.255.255.0
#
bgp 65009
router-id 4.4.4.4
peer 172.10.2.1 as-number 65009
peer 172.10.4.2 as-number 65009
peer 172.10.6.2 as-number 65009
#
ipv4-family unicast
reflect change-path-attribute
import-route direct
peer 172.10.2.1 route-policy policy1 export
peer 172.10.2.1 reflect-client
#
route-policy policy1 permit node 10
#
return
l RR2 configuration file

#
sysname RR1
#
undo shutdown
ip address 172.10.6.2 255.255.255.0
#
undo shutdown
ip address 172.10.5.2 255.255.255.0
#
undo shutdown
ip address 172.10.3.2 255.255.255.0
#
router-id 5.5.5.5
peer 172.10.3.1 as-number 65009
peer 172.10.5.1 as-number 65009
peer 172.10.6.1 as-number 65009
#
ipv4-family unicast
import-route direct
bestroute best-external
peer 172.10.5.1 advertise best-external

peer 172.10.6.1 advertise best-external

#
return
10.37.16 Example for Configuring BGP ADD-PATH

With BGP ADD-PATH, a route reflector (RR) can send two or more routes with the same
prefix to a specified IBGP peer. After reaching the IBGP peer, these routes can back up each
other or load-balance traffic, which ensures high reliability in data transmission.
In a scenario with an RR and clients, if the RR has multiple routes to the same destination
(with the same prefix), the RR selects an optimal route from these routes and then sends only
the optimal route to its clients. Therefore, the clients have only one route to the destination. If
a link along this route fails, route convergence takes a long time, which cannot meet the
requirements for high reliability.
To address this issue, deploy the BGP ADD-PATH feature on the RR. With BGP ADD-PATH,
the RR can send two or more routes with the same prefix to a specified IBGP peer. These
routes can back up each other or load-balance traffic, which ensures high reliability in data
transmission.
On the network shown in Figure 10-51, Device A, Device B, and Device C are clients of the
RR, and Device D is an EBGP peer of Device B and Device C.
To ensure high reliability in data transmission, configure BGP ADD-PATH on the RR and
enable Device A to receive ADD-PATH routes from the RR so that Device A can have
multiple routes with the same prefix.
Figure 10-51 Networking for configuring BGP ADD-PATH

NOTE
Interfaces 1 through 6 in this example are GE 3/0/0, GE 3/0/2, GE 3/0/3, GE 1/0/1, GE 1/0/2, GE 1/0/3,
respectively.
DeviceC
interface6
AS 65008
interface3
interface3 AS 65009
interface4
interface5 1.1.1.1
DeviceA RR DeviceD
interface1
interface5
interface2
interface1
DeviceB
Precautions
Enable BGP ADD-PATH on the RR, enable the RR to send ADD-PATH routes to a specified
IBGP peer, configure the number of routes that the RR can send to the IBGP peer, and enable

the IBGP peer to receive BGP ADD-PATH routes from the RR so that such routes are
available to the IBGP peer.
1. Configure an IP address for each interface on each router.
3. Enable BGP ADD-PATH on the RR, enable the RR to send ADD-PATH routes to Device
A, and configure the number of routes that the RR can send to Device A.
4. Enable Device A to receive BGP ADD-PATH routes from the RR.
Data Preparation
l Router IDs of Device A, Device B, Device C, Device D, and the RR, and their AS
numbers, as listed in Table 10-30
Table 10-30 Configurations of each device

3/0/0
Device A 1.1.1.1 AS 65008
1/0/1
1/0/3
3/0/0
Device B 2.2.2.2 AS 65008
3/0/2
1/0/2
3/0/0
Device C 3.3.3.3 AS 65008
3/0/3
1/0/3
3/0/0
Device D 4.4.4.4 AS 65009
3/0/2

LoopBack0 1.1.1.1/32
3/0/3
RR 5.5.5.5 AS 65008
1/0/1
1/0/2
Procedure
Step 1 Configure an IP address for each interface on each router. For configuration details, see
Step 2 Configure basic BGP functions. Configure Device A, Device B, and Device C as clients of
the RR, and configure Device D as an EBGP peer of Device B and Device C.
[~DeviceA-bgp] quit
[~DeviceB-bgp] quit
[~DeviceC-bgp] quit
[*DeviceD-bgp] import-route direct
[~DeviceD-bgp] quit
# Configure the RR.

[~RR] bgp 65008

[*RR-bgp] router-id 5.5.5.5
[*RR-bgp] peer 172.10.2.1 as-number 65008
[*RR-bgp] peer 172.10.2.1 reflect-client
[*RR-bgp] import-route direct
[*RR-bgp] commit
[~RR-bgp] quit
# Display information about the routes to 1.1.1.1 on Device A.

From: 172.10.2.2 (5.5.5.5)
Relay IP Out-interface: 1/0/1
rnal, best, select, pre 255
Originator: 2.2.2.2
The command output shows that Device A received only one BGP route to 1.1.1.1 from the
RR.
Step 3 Enable BGP ADD-PATH on the RR, enable the RR to send ADD-PATH routes to Device A,
configure the number of routes that the RR can send to Device A, and enable Device A to
receive BGP ADD-PATH routes from the RR.
# Configure the RR.
[~RR] bgp 65008
[~RR-bgp] bestroute add-path path-number 2
[*RR-bgp] peer 172.10.2.1 capability-advertise add-path send
[*RR-bgp] peer 172.10.2.1 advertise add-path path-number 2
[*RR-bgp] commit
[~RR-bgp] quit
[~DeviceA-bgp] peer 172.10.2.2 capability-advertise add-path receive
[~DeviceA-bgp] quit
# Display information about the routes to 1.1.1.1 on Device A.

From: 172.10.2.2 (5.5.5.5)

Received path-id: 0
Originator: 2.2.2.2

From: 172.10.2.2 (5.5.5.5)
rnal, pre 255, not preferred for router ID
Received path-id: 1
Originator: 3.3.3.3
The command output shows that Device A received two routes from the RR. The route with
the original nexthop 172.10.7.2 is the optimal route selected by the RR, and the other one with
the original nexthop 172.10.6.2 is an ADD-PATH route.
# Display information about the routes to 1.1.1.1 on the RR.
[~RR] display bgp routing-table 1.1.1.1
RR-client route.
From: 172.10.5.2 (2.2.2.2)
172.10.5.2
172.10.4.2
172.10.2.1

RR-client route.
From: 172.10.4.2 (3.3.3.3)
rnal, add-path, pre 255, not preferred for router ID
172.10.2.1
The command output shows that the RR sent the optimal route to all its clients but sent the
ADD-PATH route only to Device A.
----End
Configuration Files
#
sysname RouterA

#
undo shutdown
ip address 172.10.3.1 255.255.255.0
#
undo shutdown
ip address 172.10.2.1 255.255.255.0
#
undo shutdown
ip address 172.10.1.1 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
peer 172.10.2.2 as-number 65008
#
ipv4-family unicast
import-route direct
peer 172.10.2.2 capability-advertise add-path receive
#
return
#
sysname RouterB
#
undo shutdown
ip address 172.10.3.2 255.255.255.0
#
undo shutdown
ip address 172.10.7.1 255.255.255.0
#
undo shutdown
ip address 172.10.5.2 255.255.255.0
#
bgp 65008
router-id 2.2.2.2
peer 172.10.3.1 as-number 65008
peer 172.10.5.1 as-number 65008
peer 172.10.7.2 as-number 65009
#
ipv4-family unicast
import-route direct
#
return
#
sysname RouterC
#
undo shutdown
ip address 172.10.6.1 255.255.255.0
#
undo shutdown
ip address 172.10.4.2 255.255.255.0
#
undo shutdown

ip address 172.10.1.2 255.255.255.0

#
bgp 65008
router-id 3.3.3.3
peer 172.10.1.1 as-number 65008
peer 172.10.4.1 as-number 65008
peer 172.10.6.2 as-number 65009
#
ipv4-family unicast
import-route direct
#
return
#
sysname RouterD
#
undo shutdown
ip address 172.10.6.2 255.255.255.0
#
undo shutdown
ip address 172.10.7.2 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 65009
router-id 4.4.4.4
peer 172.10.6.1 as-number 65008
peer 172.10.7.1 as-number 65008
#
ipv4-family unicast
import-route direct
#
return
l RR configuration file
#
sysname RR
#
undo shutdown
ip address 172.10.4.1 255.255.255.0
#
undo shutdown
ip address 172.10.2.2 255.255.255.0
#
undo shutdown
ip address 172.10.5.1 255.255.255.0
#
bgp 65008
router-id 5.5.5.5
peer 172.10.2.1 as-number 65008
peer 172.10.4.2 as-number 65008
peer 172.10.5.2 as-number 65008
#
ipv4-family unicast
import-route direct

bestroute add-path path-number 2

peer 172.10.2.1 capability-advertise add-path send
peer 172.10.2.1 advertise add-path path-number 2
#
return
10.37.17 Example for Configuring BGP Keychain Authentication

By configuring keychain authentication between BGP peers, you can enhance the security of
BGP connections.
On the network shown in Figure 10-52, Device A belongs to AS 100, and Device B belongs
to AS 200. BGP runs on the network, and BGP keychain authentication is used to protect
EBGP connections against attacks.
Figure 10-52 Networking diagram of configuring BGP keychain authentication

NOTE
Interfaces 1 in this example is GE 1/0/0.
AS100 Interface1 interface1 AS200

200.1.1.1/24 200.1.1.2/24
DeviceA DeviceB
Precautions
When configuring BGP keychain authentication, pay attention to the following:
l You need to configure keychain authentication on both BGP peers, and ensure that
encryption algorithms and passwords configured for keychain authentication on both
peers are the same. Otherwise, TCP connections cannot be established between BGP
peers, and BGP messages cannot be exchanged.
2. Configure keychain authentication on Device A and Device B.
Data Preparation

l Router IDs and AS numbers of Device A and Device B

l Name of keychain authentication between Device A and Device B
Procedure
in this section.
Step 2 Establish an EBGP connection.
[~DeviceA] bgp 100
[~DeviceA-bgp] quit
[~DeviceB] bgp 200
[~DeviceB-bgp] quit
Step 3 Configure keychain authentication.
[~DeviceA] keychain Huawei mode absolute
[*DeviceA-keychain] tcp-kind 179
[*DeviceA-keychain] tcp-algorithm-id md5 17
[*DeviceA-keychain] receive-tolerance 100
[*DeviceA-keychain] key-id 1
[*DeviceA-keychain-keyid-1] algorithm md5
[*DeviceA-keychain-keyid-1] key-string hello
[*DeviceA-keychain-keyid-1] send-time 11:00 2009-12-24 to 12:00 2009-12-24
[*DeviceA-keychain-keyid-1] receive-time 11:00 2009-12-24 to 12:00 2009-12-24
[*DeviceA-keychain-keyid-1] commit
[~DeviceA-keychain-keyid-1] quit
[~DeviceA-keychain] quit
[~DeviceB] keychain Huawei mode absolute
[*DeviceB-keychain] tcp-kind 179
[*DeviceB-keychain] tcp-algorithm-id md5 17
[*DeviceB-keychain] receive-tolerance 100
[*DeviceB-keychain] key-id 1
[*DeviceB-keychain-keyid-1] algorithm md5
[*DeviceB-keychain-keyid-1] key-string hello
[*DeviceB-keychain-keyid-1] send-time 11:00 2009-12-24 to 12:00 2009-12-24
[*DeviceB-keychain-keyid-1] receive-time 11:00 2009-12-24 to 12:00 2009-12-24
[*DeviceB-keychain-keyid-1] commit
[~DeviceB-keychain-keyid-1] quit
[~DeviceB-keychain] quit
Step 4 Apply keychain authentication on the EBGP connection between Device A and Device B.
[~DeviceA] bgp 100
[*DeviceA-bgp] peer 200.1.1.2 keychain Huawei
[~DeviceA-bgp] quit

[~DeviceB] bgp 200
[*DeviceB-bgp] peer 200.1.1.1 keychain Huawei
[~DeviceB-bgp] quit

# On Device A, check the BGP connection status after keychain authentication is configured.
<DeviceA> display bgp peer

PrefRcv
200.1.1.2 4 200 21 24 0 00:00:23
Established 0
You can view that the status of the BGP connection is Established after keychain
authentication is configured.
----End
Configuration Files
#
sysname DeviceA
#
keychain Huawei mode absolute
receive-tolerance 100
tcp-kind 179
tcp-algorithm-id md5 17
#
key-id 1
algorithm md5
key-string cipher %#%#e^1}%%w;/C[M)OQc7"j+,2)}%#%#
send-time 11:00 2009-12-24 to 12:00 2009-12-24
receive-time 11:00 2009-12-24 to 12:00 2009-12-24
#
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
peer 200.1.1.2 keychain Huawei
#
ipv4-family unicast
#
return

#
sysname DeviceB
#
keychain Huawei mode absolute
receive-tolerance 100
tcp-kind 179
tcp-algorithm-id md5 17
#
key-id 1

algorithm md5
key-string cipher %#%#ub(70WJ"^=i(kxPK@*fK,)}t%#%#
send-time 11:00 2009-12-24 to 12:00 2009-12-24
receive-time 11:00 2009-12-24 to 12:00 2009-12-24
#
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
bgp 200
router-id 2.2.2.2
peer 200.1.1.1 keychain Huawei
#
ipv4-family unicast
#
return
10.37.18 Example for Configuring BGP-LS

BGP-link state (LS) enables BGP to report topology information collected by IGPs to the
controller.
BGP-LS is a new method of collecting topology information. With powerful routing
capabilities of BGP, BGP-LS has the following advantages:
l Reduces computing capability requirements and spares the necessity of IGPs on the
controller.
l Facilitates route selection and calculation on the controller by using BGP to summarize
process or AS topology information and report the complete information to the
controller.
l Requires only one routing protocol (BGP) to report topology information to the
controller.
In Figure 10-53, Device A is connected to the controller and reports topology information to
the controller. Device A, Device B, Device C, and Device D use IS-IS to communicate with
each other at the network layer. Device A, Device B, and Device C reside in area 10, whereas
Device D resides in area 20. Device A and Device B are Level-1 devices, Device C is a
Level-1-2 device, and Device D is a Level-2 device.
Figure 10-53 Configuring BGP-LS

NOTE
In this example, the configurations are performed on Device A, Device B, Device C, Device D, and the
controller. The HUAWEI NetEngine40E can act as Device A, Device B, Device C, or Device D.
In this example, interface 1, interface 2, interface 3, and interface 4 stand for GE 3/0/0, GE 1/0/1, GE
1/0/2, and GE 1/0/3, respectively.

Controller
Device B
L1
interface1 interface4 Loopback0
1.1.1.2/24 11.1.2.2/24 interface4 172.15.1.1/32
interface1 11.1.1.2/24 interface2 interface3 interface3
1.1.1.1/24
11.1.1.1/24 192.158.0.1/24 192.158.0.2/24
Device C Device D
Device A
L1 L1/2 L2
IS-IS
IS-IS
Area1
Area20
0
1. Configure an IP address for each interface on each router.

2. Configure basic IS-IS functions.
3. Deploy BGP-LS on Device A and the controller.
Data Preparation
l Area addresses of Device A, Device B, Device C, and Device D

l Levels of Device A, Device B, Device C, and Device D
l BGP-LS identifier of Device A
l BGP AS numbers, BGP-LS domain AS numbers, and BGP-LS domain IDs of Devices
and the controller
Procedure
Step 1 Assign an IP address to each interface on each router. For configuration details, see
Step 2 Configure basic IS-IS functions.
[~DeviceA] isis 1
[*DeviceA-isis-1] is-level level-1
[*DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[*DeviceA-isis-1] quit
[*DeviceA] interface gigabitethernet 2/0/0
[*DeviceA-GigabitEthernet2/0/0] isis enable 1
[*DeviceA-GigabitEthernet2/0/0] commit
[~DeviceA-GigabitEthernet2/0/0] quit

[~DeviceB] isis 1
[*DeviceB-isis-1] is-level level-1
[*DeviceB-isis-1] network-entity 10.0000.0000.0002.00
[*DeviceB-isis-1] quit
[*DeviceB] interface gigabitethernet 4/0/0
[*DeviceB-GigabitEthernet4/0/0] isis enable 1
[*DeviceA-GigabitEthernet4/0/0] commit
[~DeviceB-GigabitEthernet4/0/0] quit
[~DeviceC] isis 1
[*DeviceC-isis-1] network-entity 10.0000.0000.0003.00
[*DeviceC-isis-1] quit
[*DeviceC] interface gigabitethernet 2/0/0
[*DeviceC-GigabitEthernet2/0/0] isis enable 1
[*DeviceC-GigabitEthernet2/0/0] quit
[*DeviceC-GigabitEthernet3/0/0] quit
[*DeviceC-GigabitEthernet4/0/0] commit
[~DeviceC-GigabitEthernet4/0/0] quit
[~DeviceD] isis 1
[*DeviceD-isis-1] is-level level-2
[*DeviceD-isis-1] network-entity 20.0000.0000.0004.00
[*DeviceD-isis-1] quit
[*DeviceD] interface gigabitethernet 3/0/0
[*DeviceD-GigabitEthernet3/0/0] isis enable 1
[*DeviceD-GigabitEthernet3/0/0] quit
[*DeviceD] interface LoopBack0
[*DeviceD-LoopBack0] isis enable 1
[*DeviceD-LoopBack0] commit
[~DeviceD-LoopBack0] quit
# Display IS-IS routes on each router.

[~DeviceA] display isis route
Route information for ISIS(1)

-----------------------------
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL GE2/0/0 11.1.1.1 A/-/-/-
11.1.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
11.1.2.0/24 20 NULL GE2/0/0 11.1.1.1 A/-/-/-
192.158.0.0/24 20 NULL GE2/0/0 11.1.1.1 A/-/-/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
[~DeviceB] display isis route

-----------------------------

--------------------------------

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL GE4/0/0 11.1.2.1 A/-/-/-
11.1.1.0/24 20 NULL GE4/0/0 11.1.2.1 A/-/-/-
11.1.2.0/24 10 NULL GE4/0/0 Direct D/-/L/-

192.158.0.0/24 20 NULL GE4/0/0 11.1.2.1 A/-/-/-

U-Up/Down Bit Set
[~DeviceC] display isis route

-----------------------------

--------------------------------

-------------------------------------------------------------------------------
11.1.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
11.1.2.0/24 10 NULL GE4/0/0 Direct D/-/L/-
192.158.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-
U-Up/Down Bit Set

--------------------------------

-------------------------------------------------------------------------------
11.1.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
11.1.2.0/24 10 NULL GE4/0/0 Direct D/-/L/-
172.15.1.1/32 10 NULL GE3/0/0 192.158.0.2 A/-/-/-
192.158.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-
U-Up/Down Bit Set
[~DeviceD] display isis route

-----------------------------

--------------------------------

-------------------------------------------------------------------------------
11.1.1.0/24 20 NULL GE3/0/0 192.158.0.1 A/-/-/-
11.1.2.0/24 20 NULL GE3/0/0 192.158.0.1 A/-/-/-
172.15.1.1/32 0 NULL Loop0 Direct D/-/L/-
192.158.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-
U-Up/Down Bit Set
Step 3 Deploy BGP-LS on Device A and the controller.

# Enable IS-IS topology advertisement to BGP on Device A.
[~DeviceA] isis 1
[*DeviceA-isis-1] bgp-ls enable
[*DeviceA-isis-1] bgp-ls identifier 20
[*DeviceA-isis-1] commit
[~DeviceA-isis-1] quit
# Enable BGP-LS on Device A and configure the controller as a BGP-LS peer of Device A.
[~DeviceA] bgp 100
[*DeviceA-bgp] link-state-family unicast
[*DeviceA-bgp-af-ls] peer 1.1.1.2 enable
[*DeviceA-bgp-af-ls] commit
[~DeviceA-bgp-af-ls] quit
[~DeviceA-bgp] quit
# Enable BGP-LS on the controller and configure Device A as a BGP-LS peer of the
controller.

[~Controller] bgp 100

[*Controller-bgp] peer 1.1.1.1 as-number 100
[*Controller-bgp] link-state-family unicast
[*Controller-bgp-af-ls] peer 1.1.1.1 enable
[*Controller-bgp-af-ls] commit
[~Controller-bgp-af-ls] quit
[~Controller-bgp] quit

# Display BGP-LS peers and their status on Device A.
[~DeviceA] display bgp link-state unicast peer


PrefRcv
1.1.1.2 4 100 27 48 0 00:29:11
Established 17
# Display BGP-LS routes on Device A.

[~DeviceA] display bgp link-state unicast routing-table


MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?

MED : 0 PrefVal : 0
Path/Ogn : ?

MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?

MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?


MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
MED : 0 PrefVal : 0
Path/Ogn : ?
The preceding command output shows that Device A obtains the topology information on the
whole IS-IS network. Device A can use BGP-LS routes to report the topology information to
its BGP-LS peer (the controller).
----End
Configuration Files
#
sysname DeviceA
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
bgp-ls enable level-1-2
bgp-ls identifier 20
#
undo shutdown
ip address 11.1.1.2 255.255.255.0
isis enable 1
#
bgp 100
ipv4-family unicast
peer 1.1.1.2 enable
link-state-family unicast
peer 1.1.1.2 enable
#
return

#
sysname DeviceB
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 11.1.2.2 255.255.255.0
isis enable 1
#
return


#
sysname DeviceC
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 11.1.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 192.158.0.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 11.1.2.1 255.255.255.0
isis enable 1
#
return

#
sysname DeviceD
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
undo shutdown
ip address 192.158.0.2 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 172.15.1.1 255.255.255.255
isis enable 1
#
return
l Controller configuration file

#
sysname Controller
#
undo shutdown
ip address 1.1.1.2 255.255.255.0
#
bgp 100
ipv4-family unicast
peer 1.1.1.1 enable
link-state-family unicast
peer 1.1.1.1 enable
#
return


01-10 BGP Configuration

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

01-10 BGP Configuration

Caricato da

Copyright:

Formati disponibili

HUAWEI NetEngine40E Universal Service Router

Configuration Guide - IP Routing 10 BGP Configuration

About This Chapter

10.1 BGP Overview

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 781

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 782

10.25 Configuring BGP Auto FRR

10.1 BGP Overview

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 783

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 784

Figure 10-1 BGP networking

BGP is required in the following scenarios:

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 785

10.2 BGP Precautions

EBGP peers do not support No action is required. None

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 786

Precautions Preventive Measures Impact

Community or extended Plan the test configurations The service function is

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 787

10.3 Configuring Basic BGP Functions

Figure 10-2 Configuring basic BGP functions

10.3.1 Starting a BGP Process

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 788

The system view is displayed.

Step 4 (Optional) Run:

The configuration is committed.

10.3.2 Configuring a BGP Peer

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 789

The system view is displayed.

The BGP view is displayed.

When an IP address of a loopback interface or a sub-interface is used to establish a BGP

The description of the peer is configured.

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 790

The configuration is committed.

The system view is displayed.

The BGP view is displayed.

When an IP address of a loopback interface or a sub-interface is used to establish a BGP

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

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 791

The description of the peer is configured.

You can simplify network management by configuring the descriptions of peers.

The configuration is committed.

10.3.3 Configuring BGP to Import Routes

BGP routes are imported in either of the following modes:

The system view is displayed.

The BGP view is displayed.

The BGP-IPv4 unicast address family view is displayed.

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 792

import-route { direct | isis process-id | ospf process-id | rip process-

BGP is configured to import routes from other routing protocols.

By configuring the parameter route-policy route-policy-name or route-filter route-

If non-relay-tunnel is specified, the routes imported by BGP are not iterated to

BGP is configured to import default routes.

The configuration is committed.

The system view is displayed.

The BGP view is displayed.

The BGP-IPv4 unicast address family view is displayed.

Issue 02 (2018-06-20) Huawei Proprietary and Confidential 793

BGP is configured to import local routes.

By configuring the parameter route-policy route-policy-name, you can use routing

By configuring the parameter route-filter route-filter-name, you can use routing

If non-relay-tunnel is specified, the routes imported by BGP are not iterated to

The configuration is committed.

10.3.4 Checking the Configurations