BGP path attribute classification and experiment (Huawei equipment)

Property classification:

The path attribute of BGP is a specific description of BGP routing. It is a part of each BGP Update packet and describes the path information of related prefixes. The BGP decision process combines the attributes and the described prefixes, compares all the paths to the target network, and selects the best one. Path attributes provide information necessary for basic routing functions, such as Next_Hop, AS_PATH, etc. of the route. There are 10 commonly used BGP path attributes, which can be divided into 4 categories. As shown below:

1. Well known Mandatory: All BGP devices can recognize this type of attribute and must be present in the Update message. If such attributes are missing in the received update message, the BGP neighbor relationship will be reset. Currently, there are only 3 attributes that are recognized as mandatory.
2. Well-known Discretionary: All BGP devices can recognize this type of attribute, but it is not required to carry this attribute in the update. Even if such attributes are lacking, the neighbor relationship will not be affected, and equipment manufacturers can freely decide whether to realize such attributes.
3. Optional Transitive: BGP devices may not recognize such attributes. If the BGP device recognizes the attribute, it forwards the update of the attribute. If the BGP device does not recognize the attribute, check whether the attribute has been set with a transition mark. If the mark is set, the route forwards and advertises the attribute to the downstream device.
4. Optional Non-transitive: BGP devices may not recognize such attributes. If the BGP device does not recognize this type of attribute and the transition flag is not set, the attribute is not advertised during the update, and the route continues to be advertised to other peers.

note:

1. The BGP protocol has many attributes, and different attributes play different roles. The purpose of the IETF to define different attribute classifications is to unify the processing of attributes by BGP devices of different manufacturers.
2. Among the commonly used optional attributes, MED, Originator_ID, and Cluster_list are non-transitional attributes, but almost no manufacturer does not recognize this attribute, so all BGP devices pass this attribute to neighbors.

There are 10 commonly used BGP attributes. Refer to the following table for their attribute types and values:

Origin attribute:

The Origin attribute is used to define the source of path information and mark how a route becomes a BGP route. It has the following 3 types:

1. IGP: Has the highest priority. The routing information obtained through the IGP of the route originating AS, such as the route injected into the BGP routing table through the network command, has an Origin attribute of IGP.
2. EGP: The priority is second. The Origin attribute of the routing information obtained through EGP is EGP. (Note that it is the EGP protocol, not eBGP)
3. Incomplete: The lowest priority. Routing information learned through other methods. For example, the Origin attribute of routes imported by BGP through the import-route command is Incomplete.

Description:

1. In the BGP routing table, i represents the route learned by IGP. e means that the logo can only be adjusted manually. Since the EGP protocol is almost not used, it is difficult to see the logo. ? Indicates routes imported into BGP from outside. For example: 100.1.1.0/24-bit network is imported, 200.1.1.0 is imported.
   

2. When there are multiple routes with the same range from different sources, select them in the order of IGP>EGP>incomplete.

3. The origin attribute of the aggregated route can be IGP or incomplete, which depends on the origin attribute of the member route of the aggregated route. If the origin attribute of the member route is IGP, the origin attribute of the aggregated route is IGP. If the origin attribute of the member route is incomplete, the origin attribute of the aggregate route is incomplete. If some member routes are IGP, and the attribute of some member routes is incomplete, the origin attribute of the generated aggregated route is incomplete.

4. When a routing entry is generated, the origin will not change unless it is modified manually (for example, it will not change to i due to BGP neighbor relationship transfer).

AS-Path attributes:

The AS_Path attribute records all the AS numbers that a route must pass through from the local to the destination address in vector order. When a BGP router receives a route from an EBGP peer, if it finds the AS number in the AS_Path list, it will not receive the route, thus avoiding routing loops between ASs. When the BGP Speaker advertises a route locally:

1. When the BGP Speaker advertises this route to other ASs, it adds the local AS number to the AS_Path list and advertises it to neighboring routers through Update messages.
2. When the BGP Speaker advertises this route to the local AS, it will create an empty AS_Path list in the Update message (because it must carry this attribute).

When the BGP speaker propagates the routes learned from the Update messages of other BGP speakers:

1. When the BGP Speaker advertises this route to other ASs, it will add the local AS number to the front (leftmost) of the AS_Path list. According to the AS_Path attribute, the BGP router that receives the route can know the AS to pass through to the destination address. The neighboring AS numbers closest to the local AS are listed first, and the other AS numbers are listed in order.
2. When the BGP Speaker advertises this route to the local AS, it will not change the AS_Path attributes related to this route.

Therefore, in the above figure, when R4 advertises the network segment 10.0.0.0/24 to AS400 and AS100, it will add its own AS number to AS_PATH. When R5 advertises the network segment 10.0.0.0/24 to AS100, it will also add its own AS number. When R1, R3, and R2 in AS100 advertise the network segment 10.0.0.0/24 to each other, the AS_PATH attribute will not change. Under the premise that other BGP routing conditions are the same, BGP will choose the shortest AS_PATH path, that is, select Route directly to R4 through R3. In addition, AS_Path also has the function of anti-loop, and the entry with the same AS number is marked as invalid.

In addition to being able to prevent loops, AS_PATH can also determine the optimal route based on the length of AS_PATH. The content of the AS_PATH attribute of BGP is composed of segments. There are 4 segment types, namely AS_ SET, AS_ SEQUENCE, AS_CONFED_SET, AS_ CONFED_ SEQUENCE . The latter two segment types only appear in the BGP alliance, and each segment type can only appear once in the AS_PATH attribute. The AS_ PATH attributes are shown in the following table:

important point:

1. Generally, it is not recommended to delete/modify AS_PATH, which is easy to cause routing loops. However, the administrator can add repeated AS numbers to AS_ PATH as needed to increase the length of AS_ PATH, which in turn affects remote device routing.
2. When using the command peer [ipv4-address] public-as-only to send eBGP packets, only the public AS number is carried.
3. In the Internet, only public AS numbers can be used directly on the Internet. Directly publishing private AS numbers on the Internet may cause loops. In order to solve the above situation, you can configure the AS_PATH attribute to carry only the public AS number when sending eBGP update messages before advertising the route to the Internet.
4. Generally, a device supports only one BGP process, that is, only supports one AS number. However, in some special cases, such as when the AS number is changed during network migration, in order to ensure the smooth progress of the network switch, a pseudo AS number can be set for the designated peer, and the other party will use the forged AS number to establish neighbors with it. It can hide its real AS. Run the command peer [ipv4-address] fake-as fake-as-number to configure the pseudo AS number of the eBGP peer. For example: the original BGP process is 200, use the command peer 2.2.2.2 fake-as 100, it will establish neighbors with peer 2.2.2.2 using fake AS 100.
5. If the AS_ PATH_limit command is configured in the routing process, it will check whether the AS_ PATH attribute length exceeds the limit when receiving the route, if it exceeds, the route will be discarded. By default, the length of AS_PATH is 255, and the maximum limit can be adjusted to 2000.

Next_Hop attributes:

The Next_Hop attribute records the next hop information of the route. The next hop attribute of BGP is different from that of IGP, and it is not necessarily the IP address of the neighboring device. Under normal circumstances, the Next_Hop attribute follows the following rules:

1. When the BGP speaker advertises the locally originated route to the IBGP peer, it will set the next hop attribute of the routing information to the address of the interface that establishes the BGP neighbor relationship between the local and the peer.
2. When a BGP speaker advertises a route to an EBGP peer, it will set the next hop attribute of the routing information to the address of the local interface that establishes a BGP neighbor relationship with the peer.
3. When BGP Speaker advertises routes learned from EBGP peers to IBGP peers, it does not change the next hop attribute of the routing information.

Experiment:

Purpose:
The AS number of R1 and R4 is 1, the AS number of R2 is 2, and the AS number of R3 is 3. Directly connected routers establish EBGP or IBGP neighbor relationships, and create corresponding loopback ports and announce them to enter BGP. Now check the change process of the nexthop attribute after the EBGP and IBGP peers interact.

Process: The
message sent by R4 to R2: When R4 generates by itself, the next hop is: 0.0.0.0, which represents a locally generated routing entry.

When sending to R2, the next hop changes to itself:

When R2 sends to EBGP peers, the next hop will be changed to its own IP address:

Of course, when R2 sends the routing entry of R1 to R4 , The next hop will not change. IBGP neighbors change the next hop except for the corresponding command. Otherwise, the route 0.0.0.0 advertised by itself is changed to the IP address of the next hop that establishes the neighbor relationship between itself and the other party. The following is the routing information sent by R4 to R2:

the next hop of the routing entry received from R1 and R3 has not changed to itself. When you modify the next hop, you modify the corresponding attributes on your own device.

Why do the next hops of IBGP neighbors generally do not change, while those between EBGP neighbors need to change? Generally, if the next hop between EBGP neighbors is not set to itself, and the other party does not have an IP address corresponding to the next hop after receiving the entry, then the entry will be considered invalid and discarded. IBGP is generally in one AS. Generally, routers have all the routes in this AS (calculated by IGP), so iterative calculation of BGP entries is enough, and there is no need to modify each time it is sent. Of course, it is possible in some cases. There is no routing entry for the next hop. For example, this entry is sent from an EBGP neighbor and then sent to an internal device through an IBGP neighbor. At this time, it needs to be configured on the edge BGP router of the AS:
[R2-bgp]peer 10.1.24.4 next-hop-local //Take R2 to R4 as an example

Regarding the problems caused by the nexthop attribute:

1. Routing black hole problem:
   From the data plane analysis, if the data flow accesses the target BGP network, R5 sends it to R2 according to the next hop, but the intermediate IGP routers R3 and R4 do not have corresponding BGP routes, so routing black holes will appear.
   
   The solution to the routing black hole problem is as follows:
   Method 1: Create an LSP tunnel between R2 and R5 for the route corresponding to the next hop address to ensure that all data packets sent to the next hop address are forwarded through the intermediate network. The method requires MPLS label switching to be turned on.
   Method 2: In AS200, R3 and R4 are also configured as BGP routers. At this time, the IGP protocol is no longer needed. This kind of realization is used more in operator networks.
   Method 3: Redesign the network topology, connect R2 and R5 directly, and make the topology as shown in the figure below, so that the data access traffic between ASs will not need to pass through the IGP router, and use the BGP backbone router to access completely, bypassing the IGP:
   
   Method 4: Import BGP routes into IGP on R2 to ensure that the routes are reachable across the entire network. This method is not recommended. Excessive BGP routing will increase the load of IGP routers. At the same time, IGP routing is not suitable for carrying excessive inter-AS data access traffic. You can import a small number of routes or summarize the imported routes as necessary.

2. Load sharing problem
   BGP also provides load sharing technology similar to IGP, but the default BGP route can only appear-one route is in the IP route. If IGP is a load-sharing path, it can ensure that data reaches R2 through multiple paths from R5 to R2.

Loacl_Pref attributes:

1. This attribute is only valid between IBGP peers and is not advertised to other ASs (it will not be transmitted between EBGP neighbors). It indicates the BGP priority of the router.
2. This attribute is used to determine the best route when traffic leaves the AS. When a BGP router obtains multiple routes with the same destination address but different next hops through different IBGP peers, the route with the higher Local_Pref attribute value is preferred.
3. The default is 100. If it does not exist, it will be processed as 100. When does it not exist: When the entries imported by oneself and EBGP neighbors are sent, the default value is 100 after IBGP neighbors send and receive them. The value range is 0~2^32-1, the larger the value, the better the route.
4. For example, in the above topology, the route from R1 to R6 is generally modified on R2 and R3, and the local priority is generally used when out of the stack, which is also more convenient.

In the above figure: In AS100, R1, R2, and R3 establish IBGP peer relationships in pairs, and R2 and R3 establish EBGP peer relationships with routers located in AS200 and AS300, respectively. In this way, routers R2 and R3 will receive the route 10.0.0.0/24 from their EBGP peers. In order to make the three routers in AS100 prefer R2 as the route of 10.0.0.0/24 at the egress of this AS, we You only need to appropriately modify the Local Pref attribute of the route on R2 and R3. The priority of the route on R2 is higher than that of R3. After sending to R1, R1 will select the route sent by R2 to achieve the goal.

Experiment:

Purpose:
The AS number of R1 and R4 is 1, the AS number of R2 is 2, and the AS number of R3 is 3. Directly connected routers establish EBGP or IBGP neighbor relationships, and create corresponding loopback ports and advertise them into BGP. Now Verify which entries have no local priority.

Process:
All entries on R1 do not have local priority because there is no entry generated by IBGP neighbors:

on R4 there should be only 4.4.4.4 without local priority (self-generated), and other entries have local priority because it is IBGP Produced by the peer:

MED attributes:

MED (Multi Exit Discriminator) is an optional non-transitional attribute. It is also called an external metric. It is similar to the cost value of IGP. MED is a number of 4 Bytes and the value range is 0-4294967295. It is mostly used to determine the best route when traffic enters the AS. Under the same other conditions, the smaller the MED value, the higher the priority of the route.

The MED attribute is only transferred between two adjacent ASs. The AS that receives this attribute will not advertise it to any other third-party AS. The MED attribute can be configured manually. If the route is not configured with the MED attribute, the MED value of the route is treated as the default value of 0 when BGP selects the route. If there is no manual configuration, when will the MED value exist? That is, when the entry is introduced by itself or the MED value is passed to the first AS area through the EBGP neighbor relationship, it will be carried, but it will not be passed to the third AS.

In the above figure, R1 and R2 pass the network segment 10.0.0.0/24 to their EBGP neighbors R3 and R4. Under other conditions, R3 and R4 prefer the path with the lower MED value, that is, both choose to access via R1 Network 10.0.0.0/24.

Note:
By default , the router only compares the MED of the routes passed by the same AS, and does not compare the routes passed by different ASs. Huawei equipment can use the command compare-diferent-as-med to compare the routes passed by different ASs.

experiment:

Purpose:
The AS number of R1 and R4 is 1, the AS number of R2 is 2, and the AS number of R3 is 3. Directly connected routers establish EBGP or IBGP neighbor relationships, and create corresponding loopback ports and notify them to enter BGP. Now verify which ones Routes carry MED, which ones do not carry.

Process:
Check on R4, the MED value should have all the entries, the default is 0, because the local generation in 4.4.4.4, and the other three return routes learned from EBGP neighbors.

Check the routing entry (MED value) sent to R2 on R1:

you can see that only the self-generated entry 1.1.1.1 has the MED value, which is 0, and the routes received from other ASs will not be sent again. MED value (MED value transmission cannot be transmitted across multiple ASs).

Community attributes:

Community is an optional transition attribute, used to identify BGP routes with the same characteristics, making the application of routing strategies more flexible, and reducing the difficulty of maintenance and management. A destination address is a member of a destination community. These destinations share one or more characteristics. The Community attribute has 4 bytes, and the value can be customized. RFC1997 defines the first 2 bytes as autonomous system numbers, and the latter Two Bytes are the indicator on the management. The format is AA:NN, and the attribute can be expressed in decimal and hexadecimal. Among the community attribute values, 0 (00000000) ~ 65535 (0x000FFFF) and 4294901760 (0FxFF0000) ~ 4294967295 (0xFFFFFF) are reserved. In addition to this reservation, several recognized community attributes are defined. As shown in the table:

In addition to the recognized community attributes, private community attributes can also be defined for special purposes. RFC1998 defines it. This RFC describes the use of community attributes to manipulate BGP path selection in service provider networks. When controlling BGP routing, you can use the first two bytes of the community attribute as the AS number, and use the following two bytes to define the value related to the AS. For example, if the AS number of the service provider is 100, the provider can use 100: 1 to indicate, 100 indicates the characteristic service provider of the group, and 1 indicates the address of a group of peer routers. Multiple routes can have the same community attribute. The router can match the community attribute when implementing policies on these routes. In fact, it is to modify the policy of the route with the community attribute. -A route can also have multiple community attributes. If a route with multiple community attributes is found, the BGP router can take corresponding policy actions based on some or all of the attributes, and when it is passed to other peers, BGP can also Add or modify community attributes.

Expand community attributes:

The extended community attribute is an extension of the BGP community attribute. The main differences are as follows. The length is 8Byte, unlike the standard community attribute that only represents the value, the extended community attribute is composed of the type field and the value part; the type field of 1~2Byte, the rest is the value part, as shown in the figure below.

Example: Route Target, the first 2Byte represents the type, and the latter 6Byte represents the value. The extended community attribute is mainly involved in the MPLS VPN part, but I will not introduce it here.

Originator_ ID attribute and Cluster_ List attribute:

Originator_ID and Cluster_List are optional non-transitional attributes, which are used by route-reflector. Route-reflector is also referred to as RR. RR will be described in detail in the following chapters. These two attributes are specially developed for RR. Used to prevent loops in the AS.

The Originator_ID attribute value is the Router_ID of the first BGP router in the AS that advertises the route. This value is added to the routing update by the RR and passed along with the route in the AS until it is stripped off when it leaves the AS. The Originator_ID attribute is used to prevent loops in the Cluster. If the router sees that the Originator_ID in the received route is equal to its own BGP Router_ID, it means that there is a loop and the route will be discarded.

Cluster_List is a cluster list added by the RR when the route is reflected by the RR, and it records the Cluster_ID (cluster ID) passed by the route. If the route reflector finds its own cluster ID in the Cluster_list of the received route, it indicates that there is a loop, and the route is discarded. The Cluster_List attribute is used to prevent routing loops between clusters.

PrefVal properties:

PrefVal is the abbreviation of Preferred-Value, which is different from the other attributes described above. The preferred weight is the weight assigned to the route internally by Huawei equipment. It is not a BGP standard attribute that can be transmitted in route updates.

Any route that appears in the Huawei BGP table will be assigned PrefVal. It is only used inside one router and will not be passed to other routers. This value is a number in the range of 0 to 65535. The larger the value, the more preferred. The default The preferred weight of all the routes under it is 0. This value can be set for an independent route or a route learned from a specific neighbor to influence the routing of the router. This attribute is meaningful locally, and its effect only affects the routing of this router, not the routing of other routers.

Aggregator and Atomic Aggregate properties:

Atomic-Aggregate attribute: It is a recognized arbitrary attribute and is mainly used for route aggregation. If the aggregated route suppresses all detailed routes, this attribute will be generated for the aggregated route. The use of this attribute also has a warning effect, which is used to inform the peer that the original detailed route AS_PATH has been lost.

Aggregator attribute: It is an optional transitional attribute. This attribute is used as a supplement to Atomic-Aggregate to indicate where the routing information is lost. This attribute includes the AS number that initiated the aggregated route and the RouterID of the BGP advertiser that generated the aggregated route (also Called Aggregator ID).

Reference materials: Huawei hedex document, "HCIE Routing Exchange Learning Guide"