No relevant resource is found in the selected language.

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

Reminder

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

upgrade

ME60 V800R010C10SPC500 Configuration Guide - IP Routing 01

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

BGP Route Selection Rules

Route Processing on the BGP ME device

This section describes the route processing on the BGP ME device.

Figure 10-18 shows the route processing on the BGP ME device. 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-18 Route processing on the BGP ME device
Table 10-4 lists some key points for Figure 10-18.
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.

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-19 shows how the optimal route is selected.
Figure 10-19 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

Abbreviated Alias

Matching Item

Route Selection Rules

Remarks

O

Origin AS

Valid > NotFound > Invalid

BGP origin AS validation states are applied to route selection in a scenario where the device is connected to an RPKI server.

P

PrefVal

The route with the largest PreVal value is preferred.

The default value is 0.

PrefVal is Huawei-specific and valid only on the device where it is configured.

P

Local_Pref

The route with the largest Local_Pref value is preferred.

The default value is 100.

To modify the default Local_Pref value of BGP routes, run the default local-preference command.

A

NOTE:
A is the initial of the character string (ASNIL).

Route type

A > S > N > I > L, in which:
  • A: indicates that routes are summarized using the aggregate command.
  • S: indicates that routes are summarized using the summary automatic command.
  • N: indicates that routes are imported using the network command.
  • I: indicates that routes are imported using the import-route command.
  • L: indicates that routes are learned from BGP peers.

-

A

Accumulated Interior Gateway Protocol (AIGP)

The route with the smallest AIGP value is preferred.

The route with AIGP to the route without AIGP is preferred.

-

A

AS_Path

The route with the shortest AS_Path length is preferred.

If the bestroute as-path-ignore command is configured, BGP does not compare the AS_Path attribute.

O

Origin

IGP > EGP > Incomplete

-

M

Multi Exit Discriminator (MED)

The route with the smallest MED value is preferred.

The default value is 0.

If the bestroute med-none-as-maximum command is configured, BGP considers the largest MED 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

-

C

IGP metric

The route with the smallest IGP cost is preferred.

If the bestroute igp-metric-ignore command is configured, BGP does not compare the IGP cost.

C

Cluster_List

The route with the shortest Cluster_List length 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 routerid-prior-clusterlist command.

R

Router ID

The route with the smallest router ID is preferred.

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.

A

Peer IP address

The route learned from 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:

  • The routes have the same Origin AS.

  • The routes have the same PrefVal value.

  • The routes have the same Local_Pref value.

  • All the routes are summarized or non-summarized routes.

  • The routes have the same AIGP value.

  • The routes have the same AS_Path length.

  • The routes have the same origin type (IGP, EGP, or incomplete).

  • The routes have the same MED value.

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

  • 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 ME60 Feature Description - IP Routing - BGP.

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 Attribute

Command Used to Check the Route 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

  • display bgp routing-table network

  • 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 address

display bgp routing-table network

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

<HUAWEI> display bgp routing-table
 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?
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

Status codes

Route status code, displayed in front of each route entry:
  • *: indicates a valid route with a reachable next hop address.
  • >: indicates an optimal route selected by BGP.
  • d: indicates a dampened route.
  • x: indicates a Best-external route.
  • a: indicates an ADD-PATH route.
  • h: indicates a History route.
  • i: indicates a route learned from an IBGP peer.
  • s: indicates a suppressed route. If specific routes for route summarization are suppressed, s is displayed in front of each specific route.
  • 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.
  • If d is displayed in front of a route, the route is carried in an Update packet.
  • 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.
  • 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.
  • When the penalty value of a route with the h sign decreases to 0, BGP deletes this route from the BGP routing table.

Origin

Route origin code:
  • IGP: indicates that routes are added to the BGP routing table using the network (BGP) command.

  • EGP: indicates that routes are learned through the EGP protocol.

  • Incomplete: indicates that routes are added to the BGP routing table using the import-route (BGP) command.

RPKI validation codes

Route origin AS validation code.
  • V: indicates a valid route.

  • I: indicates an invalid route.

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

<HUAWEI> display bgp routing-table 10.1.1.1
 BGP local router ID : 192.168.2.2
 Local AS number : 100
 Paths:   1 available, 1 best, 1 select, 0 best-external, 0 add-path
 BGP routing table entry information of 10.1.1.1/32:
 From: 10.1.3.1 (192.168.2.3)
 Route Duration: 0d00h01m33s
 Direct Out-interface: GigabitEthernet1/0/0
 Relay is delayed as nexthop flapped frequently
 Original nexthop: 10.1.3.1
 Qos information : 0x0
 Primary Routing Table: vrf1
 AS-path 200, origin incomplete, MED 0, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.3.1
Table 10-8 Description of the display bgp routing-table command output

Item

Description

BGP local router ID

Router ID of the local device, in the same format as an IPv4 address.

Local AS number

Local AS number.

Paths

BGP route information.

BGP routing table entry information of 10.1.1.1/32

Information about the BGP route 10.1.1.1/32:

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

Directly connected interface.

Relay is delayed as nexthop flapped frequently

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, this field may not be displayed in this case.

Original nexthop

Original next hop IP address.

Qos information

QoS information.

Primary Routing Table

The source routing table

AS-path

AS_Path attribute. If Nil is displayed, the AS_Path attribute is null.

origin incomplete

Origin attribute:
  • IGP: indicates that routes are added to the BGP routing table using the network (BGP) command.
  • EGP: indicates that routes are learned through the EGP protocol.
  • 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.
  • external: indicates that the route is learned from an EBGP peer.
  • 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.

pre 255

Protocol priority of the route: 255

Advertised to such 1 peers

The BGP route has been advertised to one peer.

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:

<HUAWEI> display bgp routing-table 10.0.0.0
 BGP local router ID : 192.168.2.4
 Local AS number : 200
 Paths:   1 available, 1 best, 1 select
 BGP routing table entry information of 10.0.0.0/8:
 Aggregated route.
 Route Duration: 04h50m46s
 Direct Out-interface: NULL0
 Original nexthop: 127.0.0.1
 Qos information : 0x0
 AS-path {65001 10 100}, origin incomplete, pref-val 0, valid, local, best, select, active, pre 255
 Aggregator: AS 200, Aggregator ID 192.168.2.4, Atomic-aggregate
 Advertised to such 3 peers:
    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:
  • If the route is automatically summarized using the summary automatic command, Summary automatic route will be displayed.
  • If the route is imported using the network command, Network route will be displayed.
  • 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.

<HUAWEI> display bgp routing-table 10.2.1.0
BGP local router ID : 4.4.4.4
 Local AS number : 65010
 Paths:   1 available, 0 best, 0 select
 BGP routing table entry information of 10.2.1.0/24:
 From: 10.1.4.1 (2.2.2.2)
 Route Duration: 00h00m14s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface:
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 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

Route Attributes

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:

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

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

  • 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 ASBR to modify the Next_Hop of the routes to be advertised to an IBGP peer.

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

By default, when an ASBR forwards a route learned from an EBGP peer to its IBGP peers, the ASBR does not change the Next_Hop of the route. Therefore, the Next_Hop address of the route remains the EBGP peer IP address. After being forwarded to the IBGP peers, the route cannot become active as the Next_Hop is unreachable. To address this issue, configure the ASBR to modify the Next_Hop of the route to the local IP address before advertising the route to an 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).

If BGP load balancing has been configured using the maximum load-balancing number command, the ME device modifies the Next_Hop of each route to the local IP address through which the IBGP peer relationship is established before it advertises the route to the IBGP peer, regardless of whether the peer next-hop-local command is configured.

To configure a device to retain the original Next_Hop of imported IGP routes when advertising the routes to an IBGP peer.

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

In an intra-AS scenario, if a device is configured to retain the original Next_Hop of imported IGP routes when advertising the routes to an IBGP peer, the peer can use the original Next_Hop for iteration, which reduces the number of hops.

By default, a device modifies the Next_Hop of the routes imported from an IGP to the local IP address before advertising the routes to IBGP peers.

To configure a device to retain the original Next_Hop of imported static routes when advertising the routes to an IBGP peer.

peer { ipv4-address | group-name } next-hop-invariable include-static-route

In an intra-AS scenario, if a device is configured to retain the original Next_Hop of imported static routes when advertising the routes to an IBGP peer, the peer can use the original Next_Hop for iteration, which reduces the number of hops.

By default, a device modifies the Next_Hop of imported static routes to the local interface's IP address when advertising the routes to IBGP peers.

To prevent a device from modifying the Next_Hops of routes before advertising the routes to EBGP peers.

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

In an inter-AS VPN Option C scenario where an RR is used, the peer next-hop-invariable command needs to be run on the RR to prevent the RR from modifying the Next_Hops of routes before advertising the routes to EBGP peers. This ensures that the remote PE iterates routes to the LSP destined for the local PE during traffic transmission.

By default, a device modifies the Next_Hops of routes to the local IP address before advertising the routes to EBGP peers.

In addition, a device does not modify the Next_Hops of non-labeled routes if the routes are learned from EBGP peers 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 BGP Next_Hop iteration based on a route-policy.

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

To enable a device to iterate only desired routes, configure Next_Hop iteration based on a specified route-policy so that only the routes that match the route-policy are iterated.

By default, Next_Hop iteration based on a specified route-policy is not configured.

To enable a device to modify the Next_Hops of BGP routes using a route-policy.

apply ip-address next-hop { ipv4-address | peer-address }

The Next_Hops of BGP routes can be modified using a route-policy in the following situations:

  • For IBGP peers, the route-policy can be an import or export policy. Even if the next hop address configured in the route-policy is unreachable, the IBGP 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.

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

If a route-policy has been specified in the import-route or network command, the apply clause configured for the route-policy using the apply ip-address next-hop command does not take effect.
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 address

A next hop IP address is obtained through route iteration, but no active routes to the IP address are available in the IP routing table.

Common solutions are as follows:
  • Configure static routes or an IGP.
  • Run the import-route command.
  • 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 tunnels.

Configure a tunnel policy or a tunnel selector to ensure that the routes can be iterated to tunnels.

A next hop tunnel is obtained through route iteration, but the tunnel is unavailable.

Ensure that the tunnel is correctly configured and is Up.

The following example shows how to obtain a reachable next hop IP address. In Figure 10-20, 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-20 Networking

# Display the BGP routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
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       GigabitEthernet1/0/0
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  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:
  • Configure a static route destined for 10.1.2.1/30 on Device A.
  • 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.
  • Run the import-route direct command on Device B. This solution is not optimal because unnecessary routes may be imported.
  • Run the network 10.1.2.0 30 command on Device B to advertise the route 10.1.2.0/30 to Device A.
  • 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.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 3
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

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 } preferred-value value command.

This method sets a PreVal value for the routes learned from a peer or peer group.

Configure an import policy and run the apply preferred-value preferred-value command to configure an apply clause for the policy.

This method sets different PreVal values for different routes learned from a peer or peer group.

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-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 PreVal application networking

Scenario 1: When no PreVal value is configured on Device A, check the BGP routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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

 *>   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
 BGP local router ID : 10.1.2.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.3.2 (10.1.3.2)
 Route Duration: 00h08m35s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 200, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.2.2
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h04m38s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for AS-Path
 Not advertised to any peer yet
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

Route Attribute

Route Learned from ISP1

Route Learned from ISP2

Comparison

PrefVal

0

0

The same.

Local_Pref

-

-

The same.

NOTE:

If a route does not carry Local_Pref, the default value 100 takes effect.

Route type

Learned from a peer

Learned from a peer

The same.

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.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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

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

[~DeviceA] display bgp routing-table 10.11.0.0
 BGP local router ID : 10.1.2.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h05m36s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 300 100, origin incomplete, pref-val 120, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.2.2
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.3.2 (10.1.3.2)
 Route Duration: 00h23m11s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 200, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for PreVal
 Not advertised to any peer yet

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:

  • For the traffic destined to 10.11.0.0/16, ISP1 is active and ISP2 is backup.
  • 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.
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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

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

[~DeviceA] display bgp routing-table 10.22.0.0
 
 BGP local router ID : 10.1.2.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.22.0.0/16:
 From: 10.1.3.2 (10.1.3.2)
 Route Duration: 00h14m14s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 200, origin incomplete, pref-val 120, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.2.2
 BGP routing table entry information of 10.22.0.0/16:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h07m54s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for PreVal
 Not advertised to any peer yet

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.

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

Method

Usage Scenario

Run the default local-preference command.

This method sets a default Local_Pref for the routes that the local device advertises to IBGP peers.

Configure an import or export policy and run the apply local-preference command to configure an apply clause for the policy.

This method sets different Local_Pref values for different routes that the local 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-22, both ISP1 and ISP2 advertise the routes 10.11.0.0/16 and 10.22.0.0/16 to AS 65001.

Figure 10-22 Local_Pref application networking

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.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 192.168.2.3
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

[~DeviceA] display bgp routing-table 10.11.0.0
 BGP local router ID : 192.168.2.3
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.1.1 (192.168.2.5)
 Route Duration: 04h41m03s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.4.2
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.3.2 (192.168.2.2)
 Route Duration: 01h42m40s
 Relay IP Nexthop: 10.1.3.2
 Relay IP Out-Interface: GigabitEthernet1/0/3
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for peer type
 Not advertised to any peer yet

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

Route Attribute

Route Learned from ISP1

Route Learned from Device B

Comparison

PrefVal

0

0

The same.

Local_Pref

-

100

The same.

NOTE:

If a route does not carry Local_Pref, the default value 100 takes effect.

Route type

Learned from a peer

Learned from a peer

The same.

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
 Total Number of Routes: 6

 BGP Local router ID is 192.168.2.1
 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

      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>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 route 10.11.0.0/16 is used as an example.

[~DeviceC] display bgp routing-table 10.11.0.0
 BGP local router ID : 192.168.2.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.5.1 (192.168.2.2)
 Route Duration: 00h12m46s
 Relay IP Nexthop: 10.1.5.1
 Relay IP Out-Interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
 Not advertised to any peer yet

 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.4.1 (192.168.2.3)
 Route Duration: 00h17m30s
 Relay IP Nexthop: 10.1.4.1
 Relay IP Out-Interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for router ID
 Not advertised to any peer yet

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

Route Attribute

Route Learned from Device A

Route Learned from Device B

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

100 10

200 10

The same length.

Origin

IGP

IGP

The same.

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

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 192.168.2.3
 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

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

The preceding command output shows that Device A selects the routes learned from ISP1.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 192.168.2.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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>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 route 10.11.0.0/16 is used as an example.

[~DeviceB] display bgp routing-table 10.11.0.0
 BGP local router ID : 192.168.2.2
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.3.1 (192.168.2.3)
 Route Duration: 00h22m16s
 Relay IP Nexthop: 10.1.3.1
 Relay IP Out-Interface: GigabitEthernet1/0/4
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, localpref 120, pref-val 0, valid, internal, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.2.1
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.2.1 (192.168.2.4)
 Route Duration: 00h22m23s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, pref-val 0, valid, external, pre 255, not preferred for Local_Pref
 Not advertised to any peer yet  

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

Route Attribute

Route Learned from Device A

Route Learned from ISP2

Comparison

PrefVal

0

0

The same.

Local_Pref

120

-

Route 10.11.0.0/16 learned from Device A is optimal.

NOTE:

If a route does not carry Local_Pref, the default value 100 takes effect.

# Display the routing table of Device C.

[~DeviceC] display bgp routing-table
 Total Number of Routes: 4

 BGP Local router ID is 192.168.2.1
 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

      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>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:

  • ISP1 is active and ISP2 is backup for the traffic to 10.11.0.0/16.
  • 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 configurations are as follows:

Figure 10-23 Local_Pref-based BGP route selection networking (1)
In this situation, different Local_Pref values are required for the routes learned from the same ISP. Detailed configurations are as follows:
  • 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 node of rp1 and set the Local_Pref value of the route 10.22.0.0/16 to 120.
     if-match ip-prefix addpref
     apply local-preference 120
    #
    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 prefix list to match the route 10.22.0.0/16.
    #
  • 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 node of rp2 and set the Local_Pref value of the route 10.22.0.0/16 to 200.
     if-match ip-prefix addpref
     apply local-preference 200
    #
    route-policy rp2 permit node 20                         //Define the second node of rp2 and set the Local_Pref value of the route 10.11.0.0/16 to 60.
     if-match ip-prefix reducepref
     apply local-preference 60
    #
    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 prefix list to match the route 10.22.0.0/16.
    ip ip-prefix reducepref index 10 permit 10.11.0.0 16      //Configure an IP prefix list to match the route 10.11.0.0/16.
    #

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 192.168.2.3
 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: 5
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

[~DeviceA] display bgp routing-table 10.22.0.0
 BGP local router ID : 192.168.2.3
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.22.0.0/16:
 From: 10.1.3.2 (192.168.2.2)
 Route Duration: 00h20m12s
 Relay IP Nexthop: 10.1.3.2
 Relay IP Out-Interface: GigabitEthernet1/0/3
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, localpref 200, pref-val 0, valid, internal, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.1.1
 BGP routing table entry information of 10.22.0.0/16:
 From: 10.1.1.1 (192.168.2.5)
 Route Duration: 00h19m40s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, localpref 80, pref-val 0, valid, external, pre 255, not preferred for Local_Pref
 Not advertised to any peer yet

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

Route Attribute

Route Learned from ISP1

Route Learned from Device B

Comparison

PrefVal

0

0

The same.

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.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 192.168.2.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: 5
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

[~DeviceB] display bgp routing-table 10.11.0.0
 BGP local router ID : 192.168.2.2
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.3.1 (192.168.2.3)
 Route Duration: 00h40m28s
 Relay IP Nexthop: 10.1.3.1
 Relay IP Out-Interface: GigabitEthernet1/0/4
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, localpref 120, pref-val 0, valid, internal, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.2.1
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.2.1 (192.168.2.4)
 Route Duration: 00h41m00s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, localpref 60, pref-val 0, valid, external, pre 255, not preferred for Local_Pref
 Not advertised to any peer yet

The preceding command output shows that two routes 10.11.0.0/16 are available in the BGP 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.

# Display the routing table of Device C.

[~DeviceC] display bgp routing-table
 Total Number of Routes: 4

 BGP Local router ID is 192.168.2.1
 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

      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

Scenario 4: The requirements of the administrator of AS 65001 are as follows:
  • 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.
  • 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-24 Local_Pref-based BGP route selection networking (2)
You can perform either of the following operations:
  • Configure an export policy on Device A to modify the Local_Pref of the routes to be advertised to Device C.
  • 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.

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 192.168.2.3
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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 preceding command output shows that Device A selects the routes learned from ISP1.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 192.168.2.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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

# Display the routing table of Device C.

[~DeviceC] display bgp routing-table
 Total Number of Routes: 6

 BGP Local router ID is 192.168.2.1
 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

      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>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 route 10.11.0.0/16 is used as an example.

[~DeviceC] display bgp routing-table 10.11.0.0
 BGP local router ID : 192.168.2.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.4.1 (192.168.2.3)
 Route Duration: 00h06m26s
 Relay IP Nexthop: 10.1.4.1
 Relay IP Out-Interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.1.1
 Qos information : 0x0
 AS-path 100 10, origin igp, localpref 120, pref-val 0, valid, internal, best, select, active, pre 255
 Not advertised to any peer yet

 BGP routing table entry information of 10.11.0.0/16:
 From: 10.1.5.1 (192.168.2.2)
 Route Duration: 00h08m05s
 Relay IP Nexthop: 10.1.5.1
 Relay IP Out-Interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.2.1
 Qos information : 0x0
 AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for Local_Pref
 Not advertised to any peer yet

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.

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 summary routes. Precedences of these routes are described as follows:

  1. Summary routes take precedence over non-summary routes.

  2. Summary routes that are manually generated using the aggregate command take precedence over summary 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-25, Device A and Device B are EBGP peers, and Device B, Device C, and Device D are IBGP peers.

Figure 10-25 Networking

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.
  network 10.1.3.0 255.255.255.252                       //Advertise the route 10.1.3.0/30.
  import-route direct                                    //Import direct routes.
#

The configurations on Device D are as follows:

#
bgp 65001
 #
 ipv4-family unicast
  network 10.1.3.0 255.255.255.252                       //Advertise the route 10.1.3.0/30.
  network 10.1.4.0 255.255.255.252                       //Advertise the route 10.1.4.0/30.
  import-route direct                                    //Import direct routes.
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device D.

[~DeviceD] display bgp routing-table
 BGP Local router ID is 10.1.3.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: 10
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>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
 BGP local router ID : 10.1.3.2
 Local AS number : 65001
 Paths:   3 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 Network route.
 From: 0.0.0.0 (0.0.0.0)
 Route Duration: 00h03m51s
 Direct Out-interface: GigabitEthernet1/0/4
 Original nexthop: 10.1.4.1
 Qos information : 0x0
 AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, select, pre 0
 Advertised to such 2 peers:
    10.1.3.1
    10.1.4.2
 BGP routing table entry information of 10.1.4.0/30:
 Imported route.
 From: 0.0.0.0 (0.0.0.0)
 Route Duration: 00h04m10s
 Direct Out-interface: GigabitEthernet1/0/4
 Original nexthop: 10.1.4.1
 Qos information : 0x0
 AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, pre 0, not preferred for route type
 Not advertised to any peer yet

 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.4.2 (10.1.2.2)
 Route Duration: 00h02m24s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface: GigabitEthernet1/0/4
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, internal, pre 255
 Not advertised to any peer yet

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
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.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: 14
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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 summary routes 10.0.0.0 are available in the routing table.

[~DeviceB] display bgp routing-table 10.0.0.0
 BGP local router ID : 10.1.1.2
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.0.0.0/8:
 Aggregated route.
 Route Duration: 00h17m04s
 Direct Out-interface: NULL0
 Original nexthop: 127.0.0.1
 Qos information : 0x0
 AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, active, pre 255
 Aggregator: AS 65001, Aggregator ID 10.1.1.2
 Advertised to such 3 peers:
    10.1.1.1
    10.1.3.2
    10.1.2.2
 BGP routing table entry information of 10.0.0.0/8:
 Summary automatic route
 Route Duration: 00h17m04s
 Direct Out-interface: NULL0
 Original nexthop: 127.0.0.1
 Qos information : 0x0
 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
 Not advertised to any peer yet

The preceding command output shows that the route generated using the aggregate command is selected as the optimal route.

AIGP

BGP prefers the route with the smallest AIGP value during BGP route selection.

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:

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

  • 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-26, 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-26 AIGP application networking

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
 BGP Local router ID is 10.1.1.1
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.1.2 (10.1.1.2)
 Route Duration: 00h02m29s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.1.2
    10.1.3.2
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.3.2 (10.1.5.1)
 Route Duration: 00h03m58s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, pre 255, not preferred for router ID
 Not advertised to any peer yet

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.
  peer 10.1.3.1 aigp                                    //Enable AIGP on the local device and the peer 10.1.3.1.
#
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.
 if-match ip-prefix prefix2
 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.
#
ip ip-prefix prefix2 index 10 permit 10.1.4.0 30        //Configure IP prefix list named prefix2 to match the route 10.1.4.0/30.
#

Configurations on Device E:

#
bgp 65001
 #
 ipv4-family unicast
  peer 10.1.1.2 aigp                                    //Enable AIGP on the local device and the peer 10.1.1.2.
  peer 10.1.3.2 aigp                                    //Enable AIGP on the local device and the peer 10.1.3.2.
#

Run the display bgp routing-table [ ip-address ] command on Device E to check the configurations.

# Display the routing table of Device E.

[~DeviceE] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.3.2 (10.1.5.1)
 Route Duration: 00h00m14s
 Direct Out-interface: GigabitEthernet1/0/0
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, best, select, active, pre 255, AIGP 5
 Advertised to such 2 peers:
    10.1.1.2
    10.1.3.2
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.1.2 (10.1.1.2)
 Route Duration: 01h01m15s
 Direct Out-interface: GigabitEthernet1/0/1
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, pre 255, AIGP 10, not preferred for AIGP
 Not advertised to any peer yet

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.

Route Attribute

Route Learned from Device A

Route Learned from Device B

Comparison

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.

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:

  • AS_Sequence: records in reverse order all the ASs through which a route passes from the local device to the destination.

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

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

  • 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:
  • 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.
  • 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 AS_Confed_Set

BGP ignores AS_Confed_Sequence and 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).

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-27, both ISP1 and ISP2 use 65001 as a private AS number.
Figure 10-27 Networking in which a private AS needs to be deleted

In Figure 10-27, 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:
  • 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.

  • 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-28, AS 65005 imports three routes and advertises them to AS 65001 through two paths.
Figure 10-28 Networking in which new AS numbers are added to the AS_Path

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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?
[~DeviceA] display bgp routing-table 172.16.1.0
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.3.2 (10.1.5.1)
 Route Duration: 00h00m56s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 65003 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.1.2
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.1.2 (10.1.1.2)
 Route Duration: 00h34m43s
 Direct Out-interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for AS-Path
 Not advertised to any peer yet

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 of prefix1 to match the route 172.16.2.0/24.
ip ip-prefix prefix1 index 30 permit 172.16.3.0 24      //Define the third index of prefix1 to match the route 172.16.3.0/24.
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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?
[~DeviceA] display bgp routing-table 172.16.1.0
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.1.2 (10.1.1.2)
 Route Duration: 00h33m30s
 Direct Out-interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.3.2
    10.1.1.2
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.3.2 (10.1.5.1)
 Route Duration: 00h02m12s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 65003 65003 65003 65003 65005, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for AS-Path
 Not advertised to any peer yet
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

Route Attribute

Route Learned from Device B

Route Learned from Device C

Comparison

PrefVal

0

0

The same.

Local_Pref

-

-

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

65002 65004 65005

65003 65003 65003 65003 65005

The route learned 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-28, 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:
  • Hide the actual path information.

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

  • Reduce the AS_Path length.

AS number replacement can also be used for the purpose of load balancing. For example in Figure 10-28, 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
  undo synchronization
   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.
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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:

[~DeviceA] display bgp routing-table 172.16.1.0
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 2 select
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.1.2 (10.1.1.2)
 Route Duration: 19h57m51s
 Direct Out-interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.1.2
    10.1.3.2
 BGP routing table entry information of 172.16.1.0/24:
 From: 10.1.3.2 (10.1.5.1)
 Route Duration: 00h10m21s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, select, active, pre 255, not preferred for router ID
 Not advertised to any peer yet

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
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Tables: _Public_
         Destinations : 9        Routes : 12

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

       10.1.1.0/30  Direct  0    0           D   10.1.1.1        GigabitEthernet0/0/1
       10.1.1.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/1
       10.1.3.0/30  Direct  0    0           D   10.1.3.1        GigabitEthernet0/0/0
       10.1.3.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/0
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0
     172.16.1.0/24  EBGP    255  0           D   10.1.1.2        GigabitEthernet0/0/1
                    EBGP    255  0           D   10.1.3.2        GigabitEthernet0/0/0
     172.16.2.0/24  EBGP    255  0           D   10.1.1.2        GigabitEthernet0/0/1
                    EBGP    255  0           D   10.1.3.2        GigabitEthernet0/0/0
     172.16.3.0/24  EBGP    255  0           D   10.1.1.2        GigabitEthernet0/0/1
                    EBGP    255  0           D   10.1.3.2        GigabitEthernet0/0/0

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.

Origin

The Origin attribute indicates how routes become BGP routes.

Three types of Origin attributes are available:
  • IGP: indicates that routes are added to the BGP routing table using the network command. IGP has the highest priority.
  • EGP: indicates that routes are learned through the EGP protocol. EGP has the second highest priority.
    NOTE:

    The ME60 can receive and send BGP routes with EGP as the Origin. However, the ME60 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.

  • 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-29, Device A and Device B are EBGP peers, and Device B, Device C, and Device D are IBGP peers.
Figure 10-29 Networking diagram with Origin configurations

The configurations on Device D are as follows:

#
bgp 65001
 #
 ipv4-family unicast
  network 10.1.4.0 255.255.255.252                       //Advertise the route 10.1.4.0/30.
#

The configurations on Device C are as follows:

#
bgp 65001
 #
 ipv4-family unicast
  import-route direct                                   //Import direct routes.
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.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: 3
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

   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.

[~DeviceB] display bgp routing-table 10.1.4.0
 
 BGP local router ID : 10.1.1.2
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.3.2 (10.1.3.2)
 Route Duration: 01h14m48s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface: GigabitEthernet0/0/2
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.1.1
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 01h13m20s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for Origin
 Not advertised to any peer yet

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

Route Attribute

Route Learned from Device C

Route Learned from Device D

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

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 configurations are as follows:

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

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.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: 3
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

   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.

[~DeviceB] display bgp routing-table 10.1.4.0
 BGP local router ID : 10.1.1.2
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 01h28m19s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
 Advertised to such 1 peers:
    10.1.1.1
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.3.2 (10.1.3.2)
 Route Duration: 00h03m18s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface: GigabitEthernet0/0/2
 Original nexthop: 10.1.3.2
 Qos information : 0x0
 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for router ID
 Not advertised to any peer yet

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.

Table 10-22 Attribute comparison of the routes learned from Device C and Device D

Route Attribute

Route Learned from Device C

Route Learned from Device D

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

-

-

The same.

Origin

Incomplete

Incomplete

The same.

MED

0

0

The same.

Peer type

IBGP

IBGP

The same.

IGP cost

-

-

The same.

Cluster_List

-

-

The same.

Router ID

10.1.2.2

10.1.3.2

The route learned from Device C is optimal.

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

Method

Usage Scenario

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 run the apply cost command to configure an apply clause for the policy.

This method sets different MED values for different routes advertised by the local device to its EBGP peers.

Configure an export policy in which the apply cost-type internal command is run.

The ME device sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route is iterated. This method takes effect only on EBGP peers.

Configure an export policy in which the apply cost-type internal-inc-ibgp command is run.

The ME device sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route is iterated. This method takes effect both on IBGP and EBGP peers.

Configure an export policy in which the apply cost-type med-plus-igp command is run.

The ME device sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route is iterated plus the original MED. This method takes effect both on IBGP and EBGP peers.

The major points about MED attributes that require consideration are as follows:

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

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

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

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

  • After the deterministic-med command is configured, routes will not be selected in the same sequence they are received.

In Figure 10-30, ISP1 and ISP2 can learn the route 1.1.1.9/32 from Device C or Device D.

Figure 10-30 Networking diagram for MED applications

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.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.1.2                              0      65001i
 *                       10.1.3.2                              0      65001i
[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

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

[~DeviceB] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 00h00m58s
 Direct Out-interface: GigabitEthernet0/0/2
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h01m07s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for router ID
 Not advertised to any peer yet

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.

Table 10-24 Attribute comparison of the routes learned from Device C and Device D

Route Attribute

Route Learned from Device C

Route Learned from Device D

Comparison

PrefVal

0

0

The same.

Local_Pref

-

-

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

65001

65001

The same length.

Origin

IGP

IGP

The same.

MED

-

-

The same.

Peer type

EBGP

EBGP

The same.

IGP cost

-

-

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.

Scenario 2: The requirements of the administrator of AS 65001 are as follows:
  • 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.
  • 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-31 shows the networking in which MED is used to control route selection.

Figure 10-31 Networking diagram for MED applications
Configure route-policies to set different MED values for the routes learned from different peers. Detailed configurations are as follows:
  • Configurations on Device C:

    #
    bgp 65001
     #
     ipv4-family unicast
      undo synchronization
      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 prefix list to match the route 1.1.1.9/32.
  • 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
      undo synchronization
      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 prefix list to match the route 1.1.1.9/32.

Run the display bgp routing-table [ ip-address ] command to check the configurations. Use Device B as an example.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   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
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 01h20m38s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 01h16m28s
 Direct Out-interface: GigabitEthernet0/0/2
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, pre 255, not preferred for MED
 Not advertised to any peer yet

The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP 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.

Table 10-25 Attribute comparison of the routes learned from Device C and Device D

Route Attribute

Route Learned from Device C

Route Learned from Device D

Comparison

PrefVal

0

0

The same.

Local_Pref

-

-

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

65001

65001

The same length.

Origin

IGP

IGP

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-31 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:

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.4.2        100                   0      65001i
 *                       10.1.2.2                              0      65001i
[~DeviceB] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 00h08m42s
 Direct Out-interface: GigabitEthernet0/0/2
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 16h33m10s
 Direct Out-interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for MED
 Not advertised to any peer yet

The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP 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:

  • Route A1: AS_Path { 65001 200 }, med 100, igp cost 13, internal, Router id 4.4.4.4

  • Route A2: AS_Path { 65001 100 }, med 150, igp cost 11, internal, Router id 5.5.5.5

  • 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:
  • 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 of route A2 is 65001, which is different from its counterpart in route B (65002). 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).
  • Case 2: Route A2 is received first, followed by route B, and then route A1.
    • BGP then compares route A2 and route B. The leftmost AS number in the AS_Path of route A2 is 65001, which is different from its counterpart in route B (65002). 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).
  • 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).
    • BGP then 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 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.

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-32, 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-32 Peer type application networking

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

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-33, 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-33 Networking diagram with IGP cost configurations

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.

# Display the routing table of Device C.

[~DeviceC] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 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

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

[~DeviceC] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.1.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.3.2 (2.2.2.9)
 Route Duration: 00h00m44s
 Relay IP Nexthop: 10.1.3.2
 Relay IP Out-Interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.5.2
 Qos information : 0x0
 AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
 Not advertised to any peer yet

 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h00m39s
 Relay IP Nexthop: 10.1.1.2
 Relay IP Out-Interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.6.2
 Qos information : 0x0
 AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre 255, IGP cost 2, not preferred for IGP cost
 Not advertised to any peer yet

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.

Route Attribute

Route Learned from Device A

Route Learned from Device B

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

100

100

The same length.

Origin

IGP

IGP

The same.

MED

0

0

The same.

Peer type

IBGP

IBGP

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.

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.

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

  • 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-34, 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-34 Networking diagram with Cluster_List configurations

Run the display bgp routing-table [ ip-address ] command on Device A to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.3.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>i  1.1.1.9/32         10.1.5.2        0          100        0      i
 * i                     10.1.4.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 A selects the route learned from Device C.

[~DeviceA] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.3.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.3.2 (2.2.2.9)
 Route Duration: 00h53m08s
 Relay IP Nexthop: 10.1.3.2
 Relay IP Out-Interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.5.2
 Qos information : 0x0
 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255, IGP cost 3
 Originator:  1.1.1.9
 Cluster list: 0.0.0.3
 Not advertised to any peer yet

 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.1.2 (10.1.2.1)
 Route Duration: 00h28m05s
 Relay IP Nexthop: 10.1.1.2
 Relay IP Out-Interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 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
 Not advertised to any peer yet

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

Route Attribute

Route Learned from Device B

Route Learned from Device C

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

-

-

The same length.

Origin

IGP

IGP

The same.

MED

0

0

The same.

Peer type

IBGP

IBGP

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.

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.

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

  • 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-35, 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-35 Networking diagram with Originator_ID configurations

Run the display bgp routing-table [ ip-address ] command on Device A to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.3.1
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>i  10.1.4.0/30        10.1.5.2        0          100        0      i
 * i                     10.1.2.2        0          100        0      i

The preceding command output shows that two routes 10.1.4.0/30 are available in the routing table of Device A and that Device A selects the route learned from Device C.

[~DeviceA] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.3.1
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.3.2 (3.3.3.9)
 Route Duration: 00h00m01s
 Relay IP Nexthop: 10.1.3.2
 Relay IP Out-Interface: GigabitEthernet0/0/1
 Original nexthop: 10.1.5.2
 Qos information : 0x0
 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 2
 Originator:  10.1.4.1
 Cluster list: 0.0.0.3
 Not advertised to any peer yet

 BGP routing table entry information of 10.1.4.0/30:
 From: 10.1.1.2 (2.2.2.9)
 Route Duration: 00h00m17s
 Relay IP Nexthop: 10.1.1.2
 Relay IP Out-Interface: GigabitEthernet0/0/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 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
 Cluster list: 0.0.0.2
 Not advertised to any peer yet

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

Route Attribute

Route Learned from Device B

Route Learned from Device C

Comparison

PrefVal

0

0

The same.

Local_Pref

100

100

The same.

Route type

Learned from a peer

Learned from a peer

The same.

AIGP

-

-

The same.

AS_Path

-

-

The same length.

Origin

IGP

IGP

The same.

MED

0

0

The same.

Peer type

IBGP

IBGP

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.

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:
  • 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.
  • 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 Local_Pref, Origin, and MED.

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-36, 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-36 Networking in which two links are used to establish two BGP peer relationships

The configurations on Device A are as follows:

#
bgp 65001
 peer 10.1.1.2 as-number 65002
 peer 10.1.2.2 as-number 65002
 #
 ipv4-family unicast
  peer 10.1.1.2 enable
  peer 10.1.2.2 enable
#

The configurations on Device B are as follows:

#
bgp 65002
 peer 10.1.1.1 as-number 65001
 peer 10.1.2.1 as-number 65001
 #
 ipv4-family unicast
  network 2.2.2.9 255.255.255.255
  peer 10.1.1.1 enable
  peer 10.1.2.1 enable
#

Run the display bgp routing-table [ ip-address ] command to check the configurations.

# Display the routing table of Device A.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 192.168.2.3
 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: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   2.2.2.9/32         10.1.1.2        0                     0      65002i
 *                       10.1.2.2        0                     0      65002i

The preceding command output shows that two routes 2.2.2.9/32 are available in the routing table and that the route with the next hop address 10.1.1.2 is selected as the optimal route.

[~DeviceA] display bgp routing-table 2.2.2.9
 BGP local router ID : 192.168.2.3
 Local AS number : 65001
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 2.2.2.9/32:
 From: 10.1.1.2 (192.168.2.4)
 Route Duration: 00h19m10s
 Direct Out-interface: GigabitEthernet1/0/5
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path 65002, origin igp, MED 0, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.1.2
    10.1.2.2
 BGP routing table entry information of 2.2.2.9/32:
 From: 10.1.2.2 (192.168.2.4)
 Route Duration: 00h19m05s
 Direct Out-interface: GigabitEthernet1/0/10
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65002, origin igp, MED 0, pref-val 0, valid, external, pre 255, not preferred for peer address
 Not advertised to any peer yet

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.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059437

Views: 20747

Downloads: 15

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next