BGP RPD

Background

Route policy distribution (RPD) is used to distribute route-policies dynamically.

Without RPD, route-policies can be generated only through manual configuration, and then the route-policies are applied to peers. Such a generation mode is not applicable when the route-policies need to be adjusted dynamically and frequently. For example, in the inbound traffic optimization scenario with an NCE, the NCE monitors the traffic bandwidth usage on the network in real time, and users perform traffic optimization based on the analysis result. Specifically, for traffic optimization purposes, route-policies need to be used to modify route attributes to control the route selection on the peer end. However, the traffic bandwidth usage constantly changes, leading to the constant changes of traffic optimization policies. In this case, route-policies configured manually are not suitable. RPD provides a dynamic route-policy distribution mode for the NCE. With RPD, route-policy information is transmitted through the BGP RPD address family.

After RPD is configured, you can use the NCE to monitor and control traffic in real time. The traffic optimization policy configurations are performed on the NCE, not on forwarders. Forwarders receive RPD routes from the NCE, generate route-policies based on the routes, and implement the route-policies.

Related Concepts

RPD route: Carries route-policy information and distributes the information to peers in the BGP RPD address family. After learning the RPD route, the receiver converts it into a route-policy and applies the policy.

RPD Route Format

RPD routes are in the format of policy type (export policy)/peer address/policy ID, for example, 1/1.1.1.1/1.

Table 1 describes the fields in the routes.

Table 1 RPD route description

Field

Description

Policy type

Specifies the policy type. Currently, only export policies are supported.

Peer address

Specifies the peer address used by the policy.

Policy ID

Specifies the ID of a policy.

Route-policies carried in RPD routes are encapsulated through the WideCommunity attribute. Figure 1 shows the WideCommunity format used by RPD routes.

Figure 1 WideCommunity format used by RPD routes
Table 2 Description of fields in the WideCommunity format used by RPD routes

Field Name

Length (in bits)

Description

Container Type

16

The value is 1, indicating the WideCommunity attribute.

Flags

8

The R bit is 0, indicating a private attribute. The T bit is 0, which is not used currently.

HopCount

8

This field is not used currently. The value is 1.

Length

32

Total packet length.

Community

32

Value of WideCommunity. Each value identifies a specific function of WideCommunity. If the value is MATCH AND SET ATTR, the attributes of the routes that match specific conditions are modified. If the value is MATCH AND NOT ADVERTISE, the routes that match specific conditions are not advertised.

OWN AS

32

AS number of the NCE.

Context AS

32

AS number of the local device (forwarder).

Target TLV

8

Target TLV.

Length

16

Target TLV length.

RouteAttr

8

Route attribute type. The TLV has three sub-TLVs: IP Prefix, AS-Path, and Community.

Length

16

Length of the route attribute type.

IP Prefix

8

IP address prefix.

Length

16

Length of IP address prefix.

Type

4

Matching type of the IP address prefix.
  • 0: exact matching
  • 1: matches the routes that carry the prefix and a mask whose length is greater than or equal to the specified mask length.
  • 2: matches the routes that carry the prefix and a mask whose length is less than or equal to the specified mask length.
  • 3: matches the routes that carry the prefix and a mask whose length is within the specified range.

Flags

4

This field is not used currently.

IP Address

32

IP address.

Mask

8

Mask of the IP address.

GeMask

8

Used to specify a range. The value of this field must be less than or equal to the length of the Mask or be 0.

LeMask

8

Used to specify a range. The value of this field must be greater than the length of the Mask or be 0.

AS-Path

8

AS_Path.

Length

16

AS_Path length.

as-path regex string

32

Content of the AS_Path, which is presented using a regular expression. The maximum length of the AS_Path is 1024 bytes.

Community

8

Community attribute.

Length

16

Length of the community attribute.

Flags

8

This field is not used currently.

Community value

32

Community attribute value.

ExcTargetTLV

8

This field is not used currently. Even if this TLV has a value, it is also ignored.

Length

16

ExcTargetTLV length.

Param TLV

8

Content of the action to be performed. The format depends on the Community value, and the TLV content also varies according to the Community value. If the Community value is MATCH AND SET ATTR, the MED, Community, or AS_Path attribute is modified. If the Community value is MATCH AND NOT ADVERTISE, the Param TLV is empty, without any sub-TLV.

Length

16

Param TLV length.

Implementation

In the following example, the typical networking of inbound traffic optimization is used to describe how RPD works to implement traffic optimization:

Figure 2 shows an inbound traffic optimization scenario. NCE collects traffic information from devices and performs analysis and calculation to identify the routes to be adjusted. After a traffic optimization policy is configured on NCE, NCE converts the policy into an RPD route and delivers the route to the devices, which are forwarders in this scenario.

Figure 2 Typical networking of inbound traffic optimization
In Figure 2, the implementation of inbound traffic optimization is as follows:
  1. Before traffic optimization is implemented, the MED values of the BGP routes advertised from DeviceA to DeviceC and from DeviceB to DeviceC are 50, and traffic is balanced.
  2. NCE collects traffic information from devices and performs calculation and finds that the path from DeviceC to DeviceA is congested. In this case, it is expected that the traffic that is from AS 200 and destined for 10.1.1.1/24 enters AS 100 through DeviceB rather than DeviceA. NCE configures a traffic optimization policy, converts it into an RPD route, and delivers the route to DeviceA to instruct DeviceA to increase the MED value of the route advertised to AS 200 to 100. The MED value of the route advertised by DeviceB to AS 200 remains unchanged.
  3. After receiving the RPD route delivered by the NCE, Device A generates a route-policy based on the RPD route and executes the policy.
  4. The RPD route-policy takes effect. After receiving the routes destined for 10.1.1.1/24 from DeviceA and DeviceB, DeviceC selects the route received from DeviceB because its MED value is smaller than the MED value of the route received from DeviceA. In this case, traffic that is from AS 200 and destined for 10.1.1.1/24 enters AS 100 through DeviceB rather than DeviceA.

In this scenario, forwarders receive the policies delivered by NCE and adjust route attributes (MED, Community, or AS_Path) based on the policies. The forwarders follow the policies strictly when advertising routes, but are not responsible for the traffic optimization results. You can check the traffic optimization results in real time through NCE.

Usage Scenario

The IP network optimization solution provides users with a method of on-demand traffic scheduling to make full use of network bandwidth. In the IP network optimization solution, this feature ensures inbound traffic optimization in MAN ingress or IGW scenarios. In this solution, the router functions as a forwarder and needs to be configured with the RPD feature so that the router executes the route-policies carried in the RPD routes delivered by NCE to dynamically adjust traffic for inbound traffic optimization.

Benefits

In traffic optimization scenarios, this feature spares manual BGP route-policy maintenance, which is complex, time-consuming, and error-prone. Therefore, this feature reduces maintenance workload and improves maintenance quality.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >