BGP Operating Modes

BGP runs in either of the following modes on the process the router, as shown in Figure 1-1687:

• Internal BGP (IBGP)

• External BGP (EBGP)

When BGP runs within an AS, it is called IBGP; however, when it runs between ASs, it is called EBGP.

Figure 1-1687 BGP operating modes

Roles in Transmitting BGP Messages

• Speaker: Any router that sends BGP messages is called a BGP speaker. The speaker receives or generates new routing information and then advertises the routing information to other BGP speakers. After receiving a route from another AS, the BGP speaker compares the route with its local routes. If the route is better than its local routes, or the route is new, the speaker advertises it to all its other remote BGP speakers except the one that has advertised the route.

• Peer: BGP speakers that exchange messages with each other are called peers.

BGP Messages

BGP runs by sending five types of messages: Open, Update, Notification, Keepalive, and Route-refresh.

• Open: first message sent after a TCP connection is set up. An Open message is used to set up a BGP peer relationship. After a peer receives the Open message and negotiation between the local device and peer succeeds, the peer sends a Keepalive message to confirm and maintain the peer relationship. Then, the peers can exchange Update, Notification, Keepalive, and Route-refresh messages.

• Update: This type of message is used to exchange routes between peers. An Update message can advertise multiple reachable routes with the same attributes and can be used to delete multiple unreachable routes.

  • An Update message can be used to advertise multiple reachable routes that share the same set of attributes. These attributes are applicable to all destinations (expressed by IP prefixes) in the network layer reachability information (NLRI) field of the Update message.

  • An Update message can be used to withdraw multiple unreachable routes. Each route is identified by its destination address (using the IP prefix), which identifies the routes previously advertised between BGP speakers.

  • An Update message can be used only to delete routes. In this case, it does not need to carry the route attributes or NLRI. When an Update message is used only to advertise reachable routes, it does not need to carry information about routes to be withdrawn.

• Notification: If BGP detects an error, it sends a Notification message to its peers. The BGP connections are then torn down immediately.

• Keepalive: BGP periodically sends Keepalive messages to peers to ensure the validity of BGP connections.

• Route-refresh: This type of message is used to request that peers re-send all reachable routes to the local device.

  If all BGP devices are enabled with the route-refresh capability and an import routing policy changes, the local device sends Route-refresh messages to its peers. Upon receipt, the peers re-send their routing information to the local device. This ensures that the local BGP routing table is dynamically updated and the new routing policy is used without tearing down BGP connections.

BGP Finite State Machine

The BGP Finite State Machine (FSM) has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established.

Three common states during the establishment of BGP peer relationships are Idle, Active, and Established.

• In the Idle state, BGP denies all connection requests. This is the initial status of BGP.

• In the Connect state, BGP decides subsequent operations after a TCP connection is established.

• In the Active state, BGP attempts to set up a TCP connection. This is the intermediate status of BGP.

• In the OpenSent state, BGP is waiting for an Open message from the peer.

• In the OpenConfirm state, BGP is waiting for a Notification or Keepalive message.

• In the Established state, BGP peers can exchange Update, Route-refresh, Keepalive, and Notification messages.

The BGP peer relationship can be established only when both BGP peers are in the Established state. Both peers send Update messages to exchange routes.

BGP Processing

• BGP adopts TCP as its transport layer protocol. Therefore, a TCP connection must be available between the peers. BGP peers negotiate parameters by exchanging Open messages to establish a BGP peer relationship.

• After the peer relationship is established, BGP peers exchange BGP routing tables. BGP does not require a periodic update of its routing table. Instead, Update messages are exchanged between peers to update their routing tables incrementally if BGP routes change.

• BGP sends Keepalive messages to maintain the BGP connection between peers.

• If BGP detects an error (for example, it receives an error message), BGP sends a Notification message to report the error, and the BGP connection is torn down accordingly.

BGP Attributes

BGP route attributes are a set of parameters that describe specific BGP routes, and BGP can filter and select routes based on these attributes. BGP route attributes are classified into the following four types:

• Well-known mandatory: This type of attribute can be identified by all BGP devices and must be carried in Update messages. Without this attribute, errors occur in the routing information.

• Well-known discretionary: This type of attribute can be identified by all BGP devices. As this type of attribute is optional, it is not necessarily carried in Update messages.

• Optional transitive: This indicates the transitive attribute between ASs. A BGP device may not recognize this type of attribute, but will still accept messages carrying it and advertise them to other peers.

• Optional non-transitive: If a BGP device does not recognize this type of attribute, the device ignores it and does not advertise messages carrying it to other peers.

The most common BGP route attributes are as follows:

• Origin, which is a well-known mandatory attribute

  The Origin attribute defines the origin of a BGP route and has the following three types:

  • IGP: This type of attribute has the highest priority. IGP is the Origin attribute for routes obtained through an IGP in the AS from which the routes originate. For example, the Origin attribute of the routes imported to the BGP routing table using the network command is IGP.

  • EGP: This type of attribute has the second highest priority. The Origin attribute of the routes obtained through EGP is EGP.

  • Incomplete: This type of attribute has the lowest priority and indicates the routes learned through other modes. For example, the Origin attribute of the routes imported by BGP using the import-route command is Incomplete.

• AS_Path, which is a well-known mandatory attribute

  The AS_Path attribute records the numbers of all ASs through which a route passes from the local end to the destination in the distance-vector order.

  When a BGP speaker advertises a local route:

  • When advertising the route beyond the local AS, the BGP speaker adds the local AS number to the AS_Path list and then advertises this attribute to peer routers through Update messages.

  • When advertising the route within the local AS, the BGP speaker creates an empty AS_Path list in an Update message.

  When a BGP speaker advertises a route learned from the Update message of another BGP speaker:

  • When advertising the route beyond the local AS, the BGP speaker adds the local AS number to the far left side of the AS_Path list. From the AS_Path attribute, the BGP device that receives the route learns the ASs through which the route passes to the destination. The number of the AS closest to the local AS is placed on the far left side of the list, and the other AS numbers are listed next to the former in sequence.

  • When advertising the route within the local AS, the BGP speaker does not change its AS_Path attribute.

  The AS_Path attribute has four types: AS_Sequence, AS_Set, AS_Confed_Sequence, and AS_Confed_Set.

  • AS_Sequence: ordered set of ASs that the route in an Update message has traversed to reach the destination.
  • AS_Set: unordered set of ASs that the route in an Update message has traversed to reach the destination. The AS_Set attribute is used in route summarization scenarios. After route summarization, the device records the unordered set of AS numbers because it cannot sequence the numbers of ASs through which specific routes pass. Regardless of how many AS numbers an AS_Set contains, BGP considers the AS_Set length to be 1 during route selection.
  • AS_Confed_Sequence: ordered set of member ASs in the local confederation that an Update message has traversed.
  • AS_Confed_Set: unordered set of member ASs in the local confederation that an Update message has traversed. This type is primarily used for route summarization in a confederation.

  The AS_Confed_Sequence and AS_Confed_Set attributes are used to prevent routing loops and select routes among the member ASs in a confederation.

• Next_Hop, which is a well-known mandatory attribute

  Different from the Next_Hop attribute in an IGP, the Next_Hop attribute in BGP is not necessarily the IP address of a peer router. In most cases, the Next_Hop attribute 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 used to establish the EBGP peer relationship.

  • 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 used to establish the IBGP peer relationship.

  • When advertising a route learned from an EBGP peer to an IBGP peer, a BGP speaker does not change the Next_Hop of the route.

• MED, which is an optional non-transitive attribute

  The MED is transmitted only between two neighboring ASs, and the AS that receives the MED does not advertise it to a third AS.

  Similar to the metric used by an IGP, the MED is used to determine the optimal route when traffic enters an AS. If the router running BGP obtains multiple routes from different EBGP peers and these routes have the same destination but different next hops, the device selects the route with the smallest MED value.

• Local_Pref attribute, which is a well-known discretionary attribute

  The Local_Pref attribute indicates the preference of a BGP route on the router. It is valid only between IBGP peers and is not advertised to other ASs.

  The Local_Pref attribute determines the optimal route for the traffic that leaves an AS. When a BGP router obtains multiple routes to the same destination address but with different next hops through IBGP peers, the route with the largest Local_Pref value is selected.

Message Header Format

The five types of BGP messages have the same header format. Figure 1-1688 shows the format of a BGP message header.

Figure 1-1688 Message header format

Open Message

Open messages are used to establish BGP connections. The value of the Type field in the header of an Open message is 1. Figure 1-1689 shows the format of an Open message.

Figure 1-1689 Format of an Open message without the header

0               7              15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
|  Parm. Type   | Parm. Length  |  Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Update Message

Update messages are used to transfer routing information between BGP peers. The value of the Type field in the header of an Update message is 2. Figure 1-1690 shows the format of an Update message without the header.

Figure 1-1690 Format of an Update message without the header

Table 1-670 Description of each field in the Update message without the header

Field	Length	Description
Withdrawn Routes Length	2 octets (unsigned integer)	Indicates the length of the Withdrawn Routes field. If the value is 0, no route is withdrawn.
Withdrawn Routes	Variable	Contains a list of routes to be withdrawn. Each entry in the list contains the Length (1 octet) and Prefix (length-variable) fields. Length: indicates the mask length of the route to be withdrawn. The value 0 indicates that all routes are matched. Prefix: The prefix of the transmitted IP address must be represented by an integer byte. For example, consider the withdrawal of the route 192.168.200.200. The Prefix (in hexadecimal encoding) of the route varies according to different mask lengths:
Total Path Attribute Length	2 octets (unsigned integer)	Indicates the total length of the Path Attributes field. If the value is 0, no route or route attributes need to be advertised.
Path Attributes	Variable	Indicates a list of path attributes in the Update message. The type codes of the path attributes are arranged in ascending order. Each path attribute is encoded as a TLV (<attribute type, attribute length, attribute value>) of variable length. Figure 1-1691 Format of the BGP path attribute TLV Attr.TYPE occupies two octets (unsigned integer), including the one-octet Flags field (unsigned integer) and the one-octet Type Code field (unsigned integer). Figure 1-1692 TLV structure-Type Attr.Flags: occupies one octet (eight bits) and indicates the attribute flag. The meaning of each bit is as follows: O (Optional bit): defines whether the attribute is optional. The value 1 indicates an optional attribute, whereas the value 0 indicates a well-known attribute. T (Transitive bit): Defines whether the attribute is transitive. For an optional attribute, the value 1 indicates that the attribute is transitive, whereas the value 0 indicates that the attribute is non-transitive. For a well-known attribute, the value must be set to 1. P (Partial bit): defines whether the attribute is partial. If the optional transitive attribute is partial, the value is set to 1; if the attribute is complete, the value is set to 0. For well-known attributes and for optional non-transitive attributes, the value must be set to 0. E (Extended Length bit): defines whether the length (Attr. Length) of the attribute needs to be extended. If the attribute length does not need to be extended, the value is set to 0 and the Attr. Length is 1 octet. If the attribute length needs to be extended, the value is set to 1 and the Attr. Length is 2 octets. U (Unused bits): Indicates that the lower-order 4 bits are not used. These bits must be set to 0s upon transmission and ignored upon receipt. Attr.Type Code: Indicates the attribute type code and occupies 1 octet (unsigned integer). For details about the type codes, see Table 1-671. Attr.Value: Enter the attribute value based on the attribute type.
Network Layer Reachability Information (NLRI)	Variable	Indicates a list of IP address prefixes in the Update message. Each address prefix in the list is encoded as a 2-tuple LV (<prefix length, the prefix of the reachable route>). The encoding mode is the same as that used for Withdrawn Routes.

Notification Message

Notification messages are used to notify BGP peers of errors in a BGP process. The value of the Type field in the header of a Notification message is 3. Figure 1-1693 shows the format of a Notification message without the header.

Figure 1-1693 Format of a Notification message without the header

Keepalive Message

Keepalive messages are used to maintain BGP connections. The value of the Type field in the header of a Keepalive message is 4. Each Keepalive message has only a BGP header; it does not have a data portion. Therefore, the total length of each Keepalive message is fixed at 19 octets.

Route-refresh Message

Route-refresh messages are used to dynamically request a BGP route advertiser to re-send Update messages. The value of the Type field in the header of a Route-refresh message is 5. Figure 1-1694 shows the format of a Route-refresh message without the header.

Figure 1-1694 Format of a Route-refresh message without the header

Route Import

BGP itself cannot discover routes. Therefore, it needs to import other protocol routes, such as IGP routes or static routes, to the BGP routing table. Imported routes can be transmitted within an AS or between ASs.

BGP Route Selection

For details about BGP route attributes, see BGP Attributes.

For details about BGP route selection, see Figure 1-1696.

Figure 1-1696 BGP route selection process

Route Summarization

On a large-scale network, the BGP routing table can be very large. Route summarization can reduce the size of the routing table.

Route summarization is the process of summarizing specific routes with the same IP prefix into a summary route. After route summarization, BGP advertises only the summary route rather than all specific routes to BGP peers.

IPv4 supports both automatic and manual route summarization, whereas IPv6 supports only manual route summarization.

BGP Route Advertisement

Well-known Community Attributes

Table 1-675 lists well-known BGP community attributes.

Usage Scenario

On the network shown in Figure 1-1698, EBGP connections are established between DeviceA and DeviceB, and between DeviceB and DeviceC. If the No_Export community attribute is configured on DeviceA in AS 10 and DeviceA sends a route with the community attribute to DeviceB in AS20, DeviceB does not advertise the route to other ASs after receiving it.

Figure 1-1698 Networking for BGP communities

Networking Application

On the network shown in Figure 1-1699, Device B establishes an EBGP peer relationship with each of Device A and Device C. By setting the Large-Community attribute to 20:4:30 on Device B, you can disable the routes on Device A from being advertised to AS30.

Figure 1-1699 Networking diagram for configuring the BGP Large-Community attribute

Background

The Accumulated Interior Gateway Protocol Metric (AIGP) attribute is an optional non-transitive Border Gateway Protocol (BGP) path attribute. The attribute type code assigned by the Internet Assigned Numbers Authority (IANA) for the AIGP attribute is 26.

Routing protocols, such as IGPs that have been designed to run within a single administrative domain, generally assign a metric to each link, and then choose the path with the smallest metric as the optimal path between two nodes. BGP, designed to provide routing over a large number of independent administrative domains, does not select paths based on metrics. If a single administrative domain (AIGP domain) consists of several BGP networks, it is desirable for BGP to select paths based on metrics, just as an IGP does. The AIGP attribute enables BGP to select paths based on metrics.

Related Concepts

An AIGP administrative domain is a set of autonomous systems (ASs) in a common administrative domain. The AIGP attribute takes effect only in an AIGP administrative domain.

Implementation

AIGP Attribute Origination

The AIGP attribute can be added to a route only through a route-policy. You can configure a BGP route to add an AIGP value when routes are imported, received, or sent. If no AIGP value is configured, BGP routes do not contain AIGP attributes. Figure 1-1700 shows the typical AIGP application networking.

Figure 1-1700 AIGP application networking

AIGP Attribute Delivery

Role of the AIGP Attribute in BGP Route Selection

Usage Scenario

The AIGP attribute is used to select the optimal route in an AIGP administrative domain.

The AIGP attribute can be transmitted between BGP unicast peers as well as between BGP VPNv4/VPNv6 peers. Transmitting the AIGP attribute between BGP VPNv4/VPNv6 peers allows L3VPN traffic to be transmitted along the path with the smallest AIGP attribute value.

On the inter-AS IPv4 VPN Option B network shown in Figure 1-1701, BGP VPNv4 peer relationships are established between PEs and ASBRs. Two paths with different IGP costs exist between PE1 and PE2. If you want the PEs to select a path with a lower IGP cost to carry traffic, you can enable the AIGP capability in the BGP VPNv4 address family view and configure a route policy to add the same AIGP initial value to BGP VPNv4 routes. Take PE1 as an example. After this configuration, PE1 receives two BGP VPNv4 routes destined for CE2 from ASBR1 and ASBR2, and the BGP VPNv4 route sent by ASBR1 has a lower AIGP value. If higher-priority route selection conditions of the routes are the same, PE1 preferentially selects the BGP VPNv4 route with a lower AIGP value so that traffic can be transmitted over the PE1 -> ASBR1 -> ASBR3 -> PE2 path.

Figure 1-1701 Applying AIGP in inter-AS IPv4 VPN Option B scenarios

Benefits

After the AIGP attribute is configured in an AIGP administrative domain, BGP selects paths based on metrics, just as an IGP. Consequently, all devices in the AIGP administrative domain use the optimal routes to forward data.

Background

As user networks and the scope of network services continue to expand, load-balancing techniques are used to improve bandwidth between nodes. If tunnels are used for load balancing, transit nodes (P) obtain IP content carried in MPLS packets as a hash key. If a transit node cannot obtain the IP content from MPLS packets, the transit node can only use the top label in the MPLS label stack as a hash key. The top label in the MPLS label stack cannot differentiate underlying-layer protocols in packets in detail. As a result, the top MPLS labels are not distinguished when being used as hash keys, resulting in load imbalance. Per-packet load balancing can be used to prevent load imbalance but results in disorder. This drawback adversely affects user experience. The entropy label feature can solve the preceding problems and improve load balancing performance.

Implementation

On the network shown in Figure 1-1702, load balancing is performed on ASBRs (transit nodes) and the result is uneven. To achieve even load balancing, you can configure the entropy label capability of the BGP LSP.

The entropy label is generated by the ingress solely for the purpose of load balancing. To help the egress LSR distinguish the entropy label generated by the ingress LSR from application labels, label 7 is added before an entropy label in the MPLS label stack.

Figure 1-1702 Load balancing performed among transit nodes

The ingress generates an entropy label and encapsulates it into the MPLS label stack. If packets are not encapsulated with MPLS labels on the ingress, the ingress can easily obtain IP or Layer 2 protocol data for use as a hash key. If the ingress detects the entropy label capability enabled for tunnels, the ingress uses IP information carried in packets to compute an entropy label, adds it to the MPLS label stack, and advertises it to an ASBR. The ASBR uses the entropy label as a hash key to load-balance traffic and does not need to parse IP data inside MPLS packets.

The entropy label is pushed into packets by the ingress and removed by the egress. Therefore, the egress needs to notify the ingress of the support for the entropy label capability.

Usage Scenario

• In Figure 1-1702, entropy labels are used when load balancing is performed among transit nodes.
• On the network shown in Figure 1-1703, the BGP labeled routes exchanged between PE1 and ASBR1 are sent through an RR. If the RR needs to advertise the entropy label attribute, BGP LSP Entropy label attribute advertisement needs to be enabled between the RR and PE1, and between the RR and ASBR1. The RR also needs to be enabled to forward BGP LSP entropy labels. If the RR is not enabled to forward BGP LSP entropy labels, it discards the BGP LSP entropy labels carried in routes.
  Figure 1-1703 BGP LSP RR scenario
  

Benefits

Entropy labels help achieve more even load balancing.

Fundamentals of BGP Routing Loop Detection

Once a routing loop occurs on a Layer 3 network, packets cannot be forwarded, which may cause losses to carriers or users.

To detect potential routing loops on the network, BGP defines the Loop-detection attribute. The fundamentals of BGP routing loop detection are as follows:

1. After BGP routing loop detection is enabled, the local device generates a random number, adds the Loop-detection attribute to the routes to be advertised to EBGP peers or the locally imported routes to be advertised to peers, and encapsulates the attribute with the random number and the local vrfID. The local vrfID is automatically generated and globally unique. In the public network scenario, the vrfID is 0. In the private network scenario, the vrfID is automatically generated after a VPN instance is created. When OSPF/IS-IS routes are imported to BGP, the routing loop attributes of the OSPF/IS-IS routes are inherited.
2. When the local device receives a route with the Loop-detection attribute from another device, the local device performs the following checks:
   • Compares the Loop-detection attribute of the received route with the combination of the vrfID and random number that are locally stored.
     • If they are the same, the local device determines that a routing loop occurs.
     • If they are different, the local device determines that no routing loop occurs, and the route participates in route selection.
   • Checks whether the received route has a routing loop record.

     Routing loop records are affected by the following commands:

     • For the routes that already have routing loop records before routing loop alarms are cleared using the clear route loop-detect bgp alarm command, the records always exist.
     • For the routes that have routing loop records but no longer carry the routing loop attribute of the local device after routing loop alarms are cleared using the clear route loop-detect bgp alarm command, the records of these routes are deleted.
     • If the undo route loop-detect bgp enable command is run, the routing loop records of all looped routes are deleted.
     • If a route has a routing loop record, a routing loop once occurred. Such a route is considered to be a looped route even if it does not carry the routing loop attribute of the local device.
     • If there is no routing loop record and the Loop-detection attribute of the received route is different from the combination of the vrfID and random number that are locally stored, the local device determines that no routing loop occurs, and the route participates in route selection normally.
     • If there is no routing loop record but the Loop-detection attribute of the received route is the same as the combination of the vrfID and random number that are locally stored, the local device determines that a routing loop occurs.
3. If a routing loop is detected and the looped route is selected, the local device reports an alarm to notify the user of the routing loop risk, enters the loop prevention state, and performs the following operations:
   • Preferentially selects non-looped routes when the BGP routing table contains multiple routes with the same destination as the looped route.
   • Increases the MED value and reduces the local preference of the looped route when advertising it.
4. After the device processes a looped route, the routing loop may be resolved. If the routing loop persists, you need to locate the cause of the loop and resolve the loop. As the device cannot detect when the loop risk is eliminated, the routing loop alarm will not be cleared automatically. To manually clear the alarm after the loop risk is eliminated, you can run a related command.

Implementation

The Loop-detection attribute is a private BGP attribute. It uses a reserved value (type=255) to implement routing loop detection in some scenarios. Figure 1-1704 shows the Loop-detection attribute TLV, and Table 1-676 describes the fields in it.

Currently, the Loop-detection attribute is supported only in the BGP IPv4 public network, BGP IPv4 private network, BGP IPv6 public network, BGP IPv6 private network, BGP VPNv4, and BGP VPNv6 address families.

Figure 1-1704 Loop-detection attribute TLV extension

BGP also defines a sub-TLV for Attr.Value to identify the device that detects a routing loop. Figure 1-1705 shows the sub-TLV, and Table 1-677 describes the fields in the sub-TLV.

A maximum of four Loop-detection attribute sub-TLVs can be carried. If more than four sub-TLVs exist, they are overwritten according to the first-in-first-out rule.

Figure 1-1705 Loop-detection attribute sub-TLV

0            31            63
+-------------+-------------+
| vrfID | Random number |
+-------------+-------------+

Application Scenarios

BGP routing loops may occur in the following scenarios. You are advised to enable BGP routing loop detection during network planning.

• On the network shown in Figure 1-1706, DeviceA and DeviceC belong to AS 100, and DeviceB belongs to AS 200. An export policy is configured on DeviceB to delete the original AS numbers from the routes to be advertised to DeviceC. After receiving a BGP route that originates from DeviceC, DeviceA advertises the route to DeviceB, which then advertises the route back to DeviceC. As a result, a BGP routing loop occurs on DeviceC. After BGP routing loop detection is enabled on the entire network, DeviceC adds Loop-detection attribute 1 to the BGP route (locally imported) before advertising the route to DeviceA. After receiving the route, DeviceA adds Loop-detection attribute 2 to the route before advertising the route to DeviceB (EBGP peer). After receiving the route, DeviceB adds Loop-detection attribute 3 to the route before advertising the route to DeviceC (EBGP peer). After receiving the Loop-detection attributes, DeviceC discovers that these attributes contain Loop-detection attribute 1 which was added by itself, and then reports a routing loop alarm.
  Figure 1-1706 Typical networking 1 with a BGP routing loop
  
• On the network shown in Figure 1-1707, DeviceA resides in AS 100; DeviceB resides in AS 200; DeviceC and DeviceD reside in AS 300. An export policy is configured on DeviceD to delete the original AS numbers from the routes to be advertised to DeviceB. In this scenario, a BGP routing loop occurs on DeviceB.
  Figure 1-1707 Typical networking 2 with a BGP routing loop
  
• On the network shown in Figure 1-1708, the PE advertises a VPN route through VPN1, and then receives this route through VPN1, indicating that a routing loop occurs on the PE.
  Figure 1-1708 Typical networking 3 with a BGP routing loop
  
• On the network shown in Figure 1-1709, DeviceA, DeviceB, and DeviceC belong to AS 100. An IBGP peer relationship is established between DeviceA and the RR, between the RR and DeviceB, and between the RR and DeviceC. OSPF runs on DeviceB and DeviceC. DeviceB is configured to import BGP routes to OSPF, and DeviceC is configured to import OSPF routes to BGP. An export policy is configured on DeviceA to add AS numbers to the AS_Path attribute for the routes to be advertised to the RR. After receiving a BGP route from DeviceA, the RR advertises this route to DeviceB. DeviceB then imports the BGP route to convert it to an OSPF route and advertises the OSPF route to DeviceC. DeviceC then imports the OSPF route to convert it to a BGP route and advertises the BGP route to the RR. When comparing the route advertised by DeviceA and the route advertised by DeviceC, the RR prefers the one advertised by DeviceC as it has a shorter AS_Path than that of the route advertised by DeviceA. As a result, a stable routing loop occurs.

  To address this problem, enable BGP routing loop detection on DeviceC. After BGP routing loop detection is enabled, DeviceC adds Loop-detection attribute 1 to the BGP route imported from OSPF and advertises the BGP route to the RR. After receiving this BGP route, the RR advertises it (carrying Loop-detection attribute 1) to DeviceB. As OSPF routing loop detection is enabled by default, when the BGP route is imported to become an OSPF route on DeviceB, the OSPF route inherits the routing loop attribute of the BGP route and has an OSPF routing loop attribute added as well before the OSPF route is advertised to DeviceC. Upon receipt of the OSPF route, DeviceC imports it to convert it to a BGP route. Because BGP routing loop detection is enabled, the BGP route inherits the routing loop attributes of the OSPF route. Upon receipt of the route, DeviceC finds that the received route carries its own routing loop attribute and therefore determines that a routing loop has occurred. In this case, DeviceC generates an alarm, and reduces the local preference and increases the MED value of the route before advertising the route to the RR. After receiving the route, the RR compares this route with the route advertised by DeviceA. Because the route advertised by DeviceC has a lower local preference and a larger MED value, the RR preferentially selects the route advertised by DeviceA. The routing loop is then resolved.

  When the OSPF route is transmitted to DeviceC again, DeviceC imports it to convert it to a BGP route, and the route carries only the OSPF routing loop attribute added by DeviceB. However, DeviceC still considers the route as a looped route because the route has a routing loop record. In this case, the RR does not preferentially select the route after receiving it from DeviceC. Then routes converge normally.

  Figure 1-1709 Typical networking 4 with a BGP routing loop
  

This function is not supported in the following scenarios:

• When BGP is configured to advertise the default route, the Loop-detection attribute is not added to the default route.
• When BGP Add-Path is configured, the Loop-detection attribute is not added to routes.
• When the route server function is configured, the Loop-detection attribute is not added to the routes advertised by the server.
• The Loop-detection attribute is not added to the received routes to be advertised to IBGP peers.

Application

On the network shown in Figure 1-1710, an EBGP peer relationship is established between Device A and Device B and between Device A and Device C, and an IBGP peer relationship is established between Device A and Device D and between Device A and Device E.

Figure 1-1710 Dynamic BGP peer groups

Device B and Device C are on the same network segment (10.1.0.0/16). In this case, you can configure a dynamic peer group on Device A to listen for BGP connection requests from this network segment. After the dynamic peer group is configured, Device B and Device C are dynamically added to this peer group, and the devices to be deployed on this network segment will also be dynamically added to the peer group when they request to establish BGP peer relationships with Device A. This process helps reduce the network maintenance workload. In addition, you can configure another dynamic peer group on Device A so that Device D and Device E are dynamically added to this peer group.

Applications and Limitations

The confederation needs to be configured on each router, and the router that joins the confederation must support the confederation function.

BGP speakers need to be reconfigured when a network in non-confederation mode switches to confederation mode. As a result, the logical topology changes accordingly.

On large-scale BGP networks, the RR and confederation can both be used.

Application

After receiving routes from peers, an RR selects the optimal route based on BGP route selection rules and advertises the optimal route to other peers based on the following rules:

• If the optimal route is from a non-client IBGP peer, the RR advertises the route to all clients.

• If the optimal route is from a client, the RR advertises the route to all non-clients and clients.

• If the optimal route is from an EBGP peer, the RR advertises the route to all clients and non-clients.

An RR is easy to configure because it only needs to be configured on the router that needs to function as an RR, and clients do not need to know whether they are clients.

On some networks, if fully meshed connections have already been established among clients of an RR, they can exchange routing information directly. In this case, route reflection among the clients through the RR is unnecessary and occupies bandwidth. For example, on the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M, route reflection through the RR can be disabled, but the routes between clients and non-clients can still be reflected. By default, route reflection between clients through the RR is enabled.

On the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M, an RR can change various attributes of BGP routes, such as the AS_Path, MED, Local_Pref, and community attributes.

Originator_ID

Originator_ID and Cluster_List are used to detect and prevent routing loops.

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 attribute to this route. The Originator_ID attribute is used to identify the router that originates the 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.

Cluster_List

To prevent routing loops between ASs, a BGP router uses the AS_Path attribute to record the ASs through which a route passes. Routes with the local AS number are discarded by the router. To prevent routing loops within an AS, IBGP peers do not advertise routes learned from the local AS.

With RR, IBGP peers can advertise routes learned from the local AS to each other. However, the Cluster_List attribute must be deployed to prevent routing loops within the AS.

An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a Cluster_ID.

To prevent routing loops, the RR uses the Cluster_List attribute to record the Cluster_IDs of all RRs through which a route passes.

Similar to an AS_Path, which records all the ASs through which a route passes, a Cluster_List is composed of a series of Cluster_IDs and records all RRs through which a route passes. The Cluster_List is generated by the RR.

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

Backup RR

To enhance network reliability and prevent single points of failure, more than one route reflector needs to be configured in a cluster. The route reflectors in the same cluster must share the same Cluster_ID to prevent routing loops. Therefore, the same Cluster_ID must be configured for all RRs in the same cluster.

With backup RRs, clients can receive multiple routes to the same destination from different RRs. The clients then apply BGP route selection rules to choose the optimal route.

Figure 1-1713 Backup RR

On the network shown in Figure 1-1713, RR1 and RR2 are in the same cluster. An IBGP connection is set up between RR1 and RR2. The two RRs are non-clients of each other.

• If Client 1 receives an updated route from an external peer, Client 1 advertises the route to RR1 and RR2 through IBGP.

• After receiving the updated route, RR1 adds the local Cluster_ID to the top of the Cluster_List of the route and then reflects the route to other clients (Client 1, Client 2, and Client 3) and the non-client (RR2).

• After receiving the reflected route, RR2 checks the Cluster_List and finds that its Cluster_ID is contained in the Cluster_List. In this case, it discards the updated route and does not reflect it to its clients.

If RR1 and RR2 are configured with different Cluster_IDs, each RR receives both the routes from its clients and the updated routes reflected by the other RR. Therefore, configuring the same Cluster_ID for RR1 and RR2 reduces the number of routes that each RR receives and memory consumption.

The application of Cluster_List prevents routing loops among RRs in the same AS.

Multiple Clusters in an AS

Multiple clusters may exist in an AS. RRs are IBGP peers of each other. An RR can be configured as a client or non-client of another RR. Therefore, the relationship between clusters in an AS can be configured flexibly.

For example, a backbone network is divided into multiple reflection clusters. Each RR has other RRs configured as its non-clients, and these RRs are fully meshed. Each client establishes IBGP connections only to the RR in the same cluster. In this manner, all BGP peers in the AS can receive reflected routes. Figure 1-1714 shows the networking.

Figure 1-1714 Multiple clusters in an AS

Hierarchical Reflector

Hierarchical reflectors are usually deployed if RRs need to be deployed. On the network shown in Figure 1-1715, the ISP provides Internet routes for AS 100. Two EBGP connections are established between the ISP and AS 100. AS 100 is divided into two clusters. The four routers in Cluster 1 are core routers.

• Two Level-1 RRs (RR-1s) are deployed in Cluster 1, which ensures the reliability of the core layer of AS 100. The other two routers in the core layer are clients of RR-1s.

• One Level-2 RR (RR-2) is deployed in Cluster 2. RR-2 is a client of RR-1.

Figure 1-1715 Hierarchical reflector

In Figure 1-1716, all PEs and RRs reside in the same AS, and peer relationships are established between each PE and its RR and between RRs in both VPNv4 and VPN-Target address families; PE1 is a client of the level-1 RR1, and PE2 is a client of the level-1 RR2; RRR is a level-2 RR, with RR1 and RR2 as its clients; RT 1:1 is configured on PE1 and PE2. PE1 receives a VPN route from CE1.

Figure 1-1716 Networking with hierarchical RRs

Application

In some scenarios on the live network, to achieve network traffic interworking, EBGP full-mesh connections may be required. However, establishing full-mesh connections among devices that function as ASBRs is costly and places high requirements on the performance of the devices, which adversely affects the network topology and device expansion. In Figure 1-1717, the route server can advertise routes to all its EBGP peers, without requiring EBGP full-mesh connections among ASBRs. Therefore, the route server function reduces network resource consumption.

Figure 1-1717 Route server networking

Extended Attributes

BGP-4 Update packets carry three IPv4-related attributes: NLRI (Network Layer Reachable Information), Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP speaker that performs route summarization.

To support multiple network layer protocols, BGP-4 needs to carry network layer protocol information in NLRI and Next_Hop. MP-BGP introduces the following two route attributes:

• MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise a reachable route and its next hop.

• MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to delete an unreachable route.

The preceding two attributes are optional non-transitive. Therefore, the BGP speakers that do not support MP-BGP will ignore the information carried in the two attributes and do not advertise the information to other peers.

Address Families

The Address Family Information field consists of a 2-byte Address Family Identifier (AFI) and a 1-byte Subsequent Address Family Identifier (SAFI).

BGP uses address families to distinguish different network layer protocols. For the values of address families, see relevant standards. The NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M supports multiple MP-BGP extension applications, such as VPN extension and IPv6 extension, which are configured in their respective address family views.

The supported address families are subject to the device.

1. For details about how to configure BGP in the IPv4 address family view, see "BGP Configuration." The BGP-IPv4 unicast address family has the following functions:
   • Maintains public network BGP peers and transmits public network IPv4 routing information. When the BGP-IPv4 unicast address family transmits public network IPv4 routes, the SAFI is 1.
   • Transmits public network labeled IPv4 routes. This function is mainly used in inter-AS BGP/MPLS IP VPN Option C or inter-AS BGP/MPLS IPv6 VPN Option C scenarios. When the BGP-IPv4 unicast address family transmits public network labeled IPv4 routes, the SAFI is 4.
2. For details about how to configure BGP in the IPv6 address family view, see "BGP4+ Configuration." The BGP-IPv6 unicast address family has the following functions:
   • Maintains public network IPv6 BGP peers and transmits public network IPv6 routing information. When the BGP-IPv6 unicast address family transmits public network IPv6 routes, the SAFI is 1.
   • Transmits labeled IPv6 routes in 6PE scenarios. When the BGP-IPv6 unicast address family transmits labeled IPv6 routes, the SAFI is 4.
3. Multicast-related address family views, such as the BGP-IPv4 multicast address family view, BGP-MVPN address family view, BGP-IPv6 MVPN address family view, and BGP-MDT address family view, can transmit inter-AS routing information and are mainly used in MBGP, BIER, NG MVPN, BIERv6, and Rosen MVPN scenarios. For details about its application in multicast, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Configuration Guide - IP Multicast.
   1. The BGP-IPv4 multicast address family is used to configure multicast BGP (MBGP) peers. When a multicast source and receivers are located in different autonomous systems (ASs), an inter-AS multicast distribution tree needs to be established. MBGP can be used to transmit inter-AS routing information for multicast.
   2. BGP-MVPN address family view: BGP A-D MVPN has two modes: MDT-SAFI A-D and MCAST-VPN SAFI A-D. In both BGP A-D MVPN modes, MVPN configurations, including RDs and Share-Group addresses, are transmitted between BGP peers to discover PE peer information. In this manner, MVPN services can run on public network tunnels based on PIM-SSM MDTs. Of the two modes, the MCAST-VPN SAFI A-D mode has a broader definition, supports more extensions, and carries more MVPN attributes and information for establishing public network tunnels. Therefore, the MCAST-VPN SAFI A-D mode can be used to support the next-generation MVPN.
   3. The BGP-MDT address family is mainly used in PIM-SSM scenarios. It is used to transmit Share-Group source and group information on PEs through BGP sessions between the PEs. The following problems may occur in actual applications: To deploy PIM SSM on the public network, you must know the source address. The Share-Group is configured on a PE, but the PE does not know the multicast source addresses (addresses of MT interfaces) corresponding to the Share-Groups on other PEs. All PEs in a multicast domain (MD) select an interface address that is used to establish the public network BGP peer relationship as the multicast source IP address.
4. VPN-related address family views, such as the BGP-VPNv4 address family view, BGP-VPNv6 address family view, BGP-VPN instance view, BGP multi-instance VPN instance view, BGP-L2VPN-AD address family view, and BGP-L2VPN-AD address family view, are mainly used in BGP/MPLS IP VPN, VPWS, and VPLS scenarios. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Feature Description - VPN.
   1. The BGP-VPNv4 address family is mainly used to establish BGP VPNv4 peer relationships between PEs to exchange VPNv4 routes in BGP/MPLS IP VPN scenarios. In BGP VPNv4 extension, after a PE receives a CE's local VPN routes, the PE adds a route distinguisher (RD) and an export route target (ERT) to these routes and exchanges VPN routes with other PEs through BGP VPNv4 peer relationships. Routes of different VPNs are distinguished by RD on the public network, and import of routes from different CEs is controlled by RT. A PE maintains only the routing information about the VPNs that are directly connected to the PE but does not maintain all VPN routes on the service provider network.
   2. The BGP-VPNv6 address family is mainly used in BGP/MPLS IPv6 VPN scenarios where PEs establish BGP VPNv6 peer relationships to exchange VPNv6 routes. In BGP VPNv6 extension, after a PE receives a CE's local IPv6 routes, the PE adds an RD and an RT to the routes and exchanges VPN routes with its BGP VPNv6 peers. Routes of different VPNs are distinguished by RD on the public network, and import of routes from different CEs is controlled by RT. A PE maintains only the routing information about the VPNs that are directly connected to the PE but does not maintain all VPN routes on the service provider network.
   3. The BGP VPN instance IPv4 address family is mainly used in BGP/MPLS IP VPN scenarios where PEs and CEs use BGP to exchange VPN IPv4 routes.
   4. The BGP VPN instance IPv6 address family is mainly used in BGP/MPLS IPv6 VPN scenarios where PEs and CEs use IPv6 BGP to exchange VPN IPv6 routes.
   5. The BGP-L2VPN address family is used to manage L2VPN label blocks. MPLS/L2VPN can be implemented in multiple modes. BGP can be used as the exchange signaling. Similar to MPLS L3VPN, MPLS/L2VPN allows PEs to automatically discover L2VPN nodes and transmit VPN information through BGP sessions and use VPN targets to differentiate VPNs.
   6. The BGP L2VPN-AD address family is mainly used to configure BGP AD VPLS. In this address family, information about BGP AD VPLS members is exchanged. BGP AD VPLS combines the advantages of multiple VPLS signaling modes. It uses extended BGP messages to discover VSI members and uses LDP FEC 129 to negotiate PW establishment to implement automatic VPLS PW deployment.
   7. VPLS is a point-to-multipoint L2VPN service provided on a public network. The BGP-VPLS address family is mainly used in VPLS scenarios. After BGP peer relationships are established in the BGP-VPLS address family view of PEs, BGP is used to exchange VPLS label block information.
   8. The BGP-VPN-Target address family is mainly used to configure VPN ORF. VPN ORF enables a PE to receive only desired routes, which reduces the pressure on the routing tables of the PE, the intra-AS RR, and inter-AS ASBR.
5. EVPN-related address families, such as the BGP-EVPN address family view and BGP multi-instance EVPN address family view, are mainly used to configure BGP EVPN peers and apply to EVPN VPLS, EVPN VPWS, and EVPN L3VPN. EVPN is a VPN technology used for Layer 2 network interworking. EVPN is similar to BGP/MPLS IP VPN. EVPN defines a new type of BGP network layer reachability information (NLRI), called the EVPN NLRI. The EVPN NLRI defines new types of BGP EVPN routes to implement MAC address learning and advertisement between Layer 2 networks at different sites. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Feature Description - VPN - EVPN Feature Description.
6. The BGP IPv4 SR Policy address family view and BGP IPv6 SR Policy address family view are mainly used in Segment Routing MPLS and Segment Routing IPv6 scenarios. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Feature Description - Segment Routing.
7. Flow-related address family views, such as the BGP-Flow address family view, BGP-Flow VPNv4 address family view, BGP-Flow VPNv6 address family view, BGP-Flow VPN instance IPv4 address family view, and BGP-Flow VPN instance IPv6 address family view are mainly used to defend against DoS/DDoS attacks and improve network security and availability. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Feature Description - Security - BGP Flow Specification Feature Description.
8. The BGP-labeled address family view and BGP-labeled-VPN instance IPv4 address family view are mainly used for carrier configuration using the BGP label distribution solution. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Configuration - VPN - BGP/MPLS IP VPN Configuration and HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Configuration - VPN - EVPN Configuration.
9. The BGP-LS address family view is mainly used to summarize the topology information collected by an IGP and send the information to the upper-layer controller. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 seriesRouter Feature Description - BGP Feature Description - BGP-LS.

BGP Authentication

BGP can work properly only after BGP peer relationships are established. Authenticating BGP peers can improve BGP security. BGP supports the following authentication modes:

• MD5 authentication

  BGP uses TCP as the transport layer protocol. Message Digest 5 (MD5) authentication can be used when establishing TCP connections to improve BGP security. MD5 authentication sets the MD5 authentication password for the TCP connection, and TCP performs the authentication. If the authentication fails, the TCP connection cannot be established.

  The encryption algorithm used for MD5 authentication poses security risks. Therefore, you are advised to use an authentication mode based on a more secure encryption algorithm.

• Keychain authentication

  Keychain authentication is performed at the application layer. It prevents service interruptions and improves security by periodically changing the password and encryption algorithms. When keychain authentication is configured for BGP peer relationships over TCP connections, BGP messages as well as the process of establishing TCP connections can be authenticated. For details about keychain, see "Keychain" in HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 series Feature Description - Security.

• TCP-AO authentication

  The TCP authentication option (TCP-AO) is used to authenticate received and to-be sent packets during TCP session establishment and data exchange. It supports packet integrity check to prevent TCP replay attacks. TCP-AO authentication improves the security of the TCP connection between BGP peers and is applicable to the network that requires high security.

BGP GTSM

During network attacks, attackers may simulate BGP messages and continuously send them to the router. If the messages are destined for the router, it directly forwards them to the control plane for processing without validating them. As a result, the increased processing workload on the router's control plane results in high CPU usage. The Generalized TTL Security Mechanism (GTSM) defends against attacks by checking the time to live (TTL) value in each packet header. TTL refers to the maximum number of routers through which a packet can pass.

GTSM checks whether the TTL value in each IP packet header is within a pre-defined range, which protects services above the IP layer and improves system security.

After a GTSM policy of BGP is configured, an interface board checks the TTL values of all BGP messages. According to actual networking requirements, you can set the default action (to drop or pass) that GTSM will take on the messages whose TTL values are not within a pre-defined range. If a valid TTL range is specified based on the network topology and the default action that GTSM will take is set to drop, the BGP messages whose TTL values are not within the valid range are discarded directly by the interface board upon receipt. This prevents bogus BGP messages from consuming CPU resources.

You can enable the logging function so that the device can record information about message dropping in logs. The recorded logs facilitate fault locating.

BGP RPKI

Resource Public Key Infrastructure (RPKI) ensures BGP security by verifying the validity of the BGP route source AS or route advertiser.

Attackers can steal user data by advertising routes that are more specific than those advertised by carriers. RPKI can resolve this problem. For example, if a carrier has advertised a route destined for 10.10.0.0/16, an attacker can advertise a route destined for 10.10.153.0/24, which is more specific than 10.10.0.0/16. According to the longest match rule, the route 10.10.153.0/24 is preferentially selected for traffic forwarding. As a result, the attacker succeeds in illegally obtaining user data.

To solve the preceding problems, you can configure Route Origin Authorization (ROA) and regional validation to ensure BGP security.

ROA

ROA stores the mapping between prefix addresses and the origin AS and checks whether the routes with a specified IP address prefix are valid by verifying the AS number.

In Figure 1-1721, a connection is created between Device B and the RPKI server. Device B can download the ROA database from the RPKI database and verify the mapping between 10.1.1.0/24 and AS 100. When AS 200 receives a route with the prefix 10.1.1.0/24 from AS 100 and AS 300, it compares the origin AS with that in the ROA database. If they are the same, the route is considered valid. If they are different, the route is considered invalid. The route to 10.1.1.0/24 learned from AS 100 is valid because it matches the ROA database, and the route advertisement from the origin AS 100 is considered valid. The route to 10.1.1.0/24 learned from AS 300 is invalid because it does not match the ROA database, and the route advertisement from the origin AS 300 is considered invalid.

If no RPKI server is available, a static ROA database can be configured for Device B. In this way, ROA validation can be implemented based on the static ROA database, without relying on an RPKI server, thereby preventing route hijacking to a certain extent.

Figure 1-1721 ROA validation

The ROA validation results for received routes are as follows:

• Valid: indicates that the route advertisement from the origin AS to the specified IP address prefix is valid.
• Invalid: indicates that the route advertisement from the origin AS to the specified IP address prefix is invalid and that the route is not allowed to participate in route selection.
• Not Found: indicates that the origin AS does not exist in the ROA database and that the route participates in route selection.

In addition, ROA validation can be applied to the routes to be advertised to an EBGP peer, which prevents route hijacking. In Figure 1-1722, Device B is configured to perform ROA validation on the routes to be advertised. Before advertising a route that matches the export policy to an EBGP peer, Device B performs ROA validation on the route by matching the origin AS of the route against that of the corresponding route in the ROA database. If the route is not found in the ROA database, the validation result is Not Found. If the route is found in the ROA database and the origin AS of the route is the same as that of the corresponding route in the ROA database, the validation result is Valid. If the origin AS of the route is different from that of the corresponding route in the ROA database, the validation result is Invalid. If the validation result is Valid, the route is advertised by default. If the validation result is Not Found, the route is not advertised by default. If the validation result is Invalid, the route is not advertised by default and an alarm is generated; the alarm is cleared when all routes with the validation result of Invalid are withdrawn.

Figure 1-1722 Outbound ROA validation

Regional validation

Regional validation: Users can manually configure regions by combining multiple trusted ASs into a region and combining multiple regions into a regional confederation. Regional validation controls route selection results by checking whether the routes received from EBGP peers in an external region belong to the local region. This prevents intra-region routes from being hijacked by attackers outside the local region, and ensures that hosts in the local region can securely access internal services.

Regional validation applies to the following typical scenarios: regional validation scenario and regional confederation validation scenario.

• As shown in Figure 1-1723, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 3 connects to AS 100 of another carrier's network. The user accesses the server at 10.1.0.0/16 in AS 2 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 2. If an attacker forges a route 10.1.1.0/24 in AS 100, the user-to-server traffic will be illegally obtained by the attacker because the route advertised by the attacker is more specific. To solve this problem, configure regional validation on the border device of AS 3 to combine AS 1, AS 2, and AS 3 into region 1. AS 3 receives the attack route from AS 100, and the route source is AS 2, indicating that the route belongs to the local region. However, as the route is received from the BGP peer outside region 1, the route is considered illegal by regional validation. As a result, the route is set to be invalid, or the preference of the route is reduced.

Figure 1-1723 Regional validation scenario

• As shown in Figure 1-1724, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 4 and AS 5 belong to a partner carrier's network. Both AS 3 and AS 4 are connected to AS 100 of another carrier. The user accesses the server at 10.1.0.0/16 in AS 5 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 4 -> AS 5. If an attacker forges a route 10.1.1.0/24 in AS 100, the user-to-server traffic will be illegally obtained by the attacker because the route advertised by the attacker is more specific. To solve this problem, configure regional validation on the border device of AS 3. Specifically, combine AS 1, AS 2, and AS 3 into region 1, and AS 4 and AS 5 into region 2, and then group the regions 1 and 2 into regional confederation 1. AS 3 receives the attack route from AS 100, and the route source is AS 5, indicating that the route belongs to the local regional confederation. However, as the route is received from the BGP peer outside the regional confederation, the route is considered illegal by regional validation. As a result, the route is set to be invalid, or the preference of the route is reduced.

Figure 1-1724 Regional confederation validation scenario

SSL/TLS Authentication

Secure Sockets Layer (SSL) is a security protocol that protects data privacy on the Internet. Transport Layer Security (TLS) is a successor of SSL. TLS protects data integrity and privacy by preventing attackers from eavesdropping the data exchanged between a client and server. To ensure data transmission security on a network, SSL/TLS authentication can be enabled for BGP message encryption.

Prerequisite for Implementation

On a traditional device, a processor implements both control and forwarding. The processor finds routes based on routing protocols, and maintains the routing table and forwarding table of the device. Mid-range and high-end devices generally adopt the multi-RP structure to improve forwarding performance and reliability. The processor in charge of routing protocols is located on the main control board, whereas the processor responsible for data forwarding is located on the interface board. The design helps to ensure the continuity of packet forwarding on the interface board during the restart of the main processor. The technology that separates control from forwarding satisfies the prerequisite for GR implementation.

Currently, a GR-capable device must have two main control boards. In addition, the interface board must have an independent processor and memory.

Related Concepts

Fundamentals

Fundamentals of a BGP GR Restarter are as follows:

1. When a BGP process is restarted, a GR-capable device enters the GR Restarter state, starts the Protection timer and Force-Quit timer, and waits for BGP peer relationships to be reestablished.

   • After the first BGP peer relationship is established, the Protection timer is deleted, and the process goes to Step 2.
   • No BGP peer relationship is established, and the Protection timer expires. In this case, the GR Restarter state exits.
2. The GR Restarter continues to wait for the remaining BGP peer relationships to be established, receives routes and EOR messages from the BGP peers with which BGP peer relationships have been established, starts the Wait-All-Peer-Up Timer and Selection-Deferral Timer, and waits for the establishment of all BGP peer relationships and EOR messages. The GR Restarter starts route selection when one of the following conditions is met:
   • The BGP peer relationships are established, and the GR Restarter receives EOR messages from the peers.
   • The Wait-All-Peer-Up timer expires.
   • The Selection-Deferral timer expires.
3. After the GR restarter completes route selection, it re-advertises routes to its BGP peers and exits the GR restarter state.

GR Reset

Currently, BGP does not support dynamic capability negotiation. Therefore, each time a capability in an address family (such as the IPv4, IPv6, VPNv4, and VPNv6 address families) is enabled or disabled on a BGP speaker, a BGP speaker tears down existing sessions with the peer and renegotiates capabilities.

In some scenarios, BGP IPv4 unicast peer sessions have been established and IPv4 services are running properly. If a BGP peer relationship in another address family is established based on this session, the BGP IPv4 unicast peer relationship will be re-established, affecting IPv4 services. To solve the preceding problem, the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M provides the function of resetting a BGP connection in GR mode.

With the function of resetting a BGP connection in GR mode, if a BGP peer relationship in another address family is established based on an IPv4 BGP unicast peer session, BGP enters the GR state and renegotiates BGP capabilities with its peer. Throughout the entire process, BGP re-establishes the BGP IPv4 unicast peer session but retains the original routing entries. The forwarding module forwards packets based on the routing entries, thereby ensuring that IPv4 services are not interrupted.

Benefits

Through BGP GR, the forwarding is not interrupted. In addition, the flapping of BGP occurs only on the peers of the GR Restarter, and does not occur in the entire routing domain. This is important for BGP that needs to process a large number of routes.

Fundamentals

On the network shown in Figure 1-1725, DeviceA and DeviceB belong to AS 100 and AS 200, respectively. An EBGP connection is established between the two routers.

BFD is used to monitor the BGP peer relationship between DeviceA and DeviceB. If the link between them becomes faulty, BFD can quickly detect the fault and notify it to BGP.

Figure 1-1725 Networking diagram of BFD for BGP

On the network shown in 2, indirect multi-hop EBGP connections are established between DeviceA and DeviceC and between DeviceB and DeviceD; a BFD session is established between DeviceA and DeviceC; a BGP peer relationship is established between DeviceA and DeviceB; the bandwidth between DeviceA and DeviceB is low. If the original forwarding path DeviceA->DeviceC goes faulty, traffic that is sent from DeviceE to DeviceA is switched to the path DeviceA->DeviceB->DeviceD->DeviceC. Due to low bandwidth on the link between DeviceA and DeviceB, traffic loss may occur on this path.

BFD for BGP TTL check applies only to the scenario in which DeviceA and DeviceC are indirectly connected EBGP peers.

Figure 1-1726 Networking diagram of setting a TTL value for checking the BFD session with a BGP peer

To prevent this issue, you can set a TTL value on DeviceC for checking the BFD session with DeviceA. If the number of forwarding hops of a BFD packet (TTL value in the packet) is smaller than the TTL value set on DeviceC, the BFD packet is discarded, and BFD detects a session down event and notifies BGP. DeviceA then sends BGP Update messages to DeviceE for route update so that the traffic forwarding path can change to DeviceE->DeviceF->DeviceB->DeviceD->DeviceC. For example, the TTL value for checking the BFD session on DeviceC is set to 254. If the link between DeviceA and DeviceC fails, traffic sent from DeviceE is forwarded through the path DeviceA->DeviceB->DeviceD->DeviceC. In this case, the TTL value in a packet decreases to 252 when the packet reaches DeviceC. Since 252 is smaller than the configured TTL value 254, the BFD packet is discarded, and BFD detects a session down event and notifies BGP. DeviceA then sends BGP Update messages to DeviceE for route update so that the traffic forwarding path can change to DeviceE->DeviceF->DeviceB->DeviceD->DeviceC.

Networking

BGP peer tracking can quickly detect link or peer faults by checking whether routes to peers exist in the IP routing table. If no route is found in the IP routing table based on the IP address of a BGP peer (or a route exists but is unreachable, for example, the outbound interface is a Null0 interface), the BGP session goes down, achieving fast BGP route convergence. If a reachable route can be found in this case, the BGP session does not go down.

On the network shown in Figure 1-1727, IGP connections are established between DeviceA, DeviceB, and DeviceC, a BGP peer relationship is established between DeviceA and DeviceC, and BGP peer tracking is configured on DeviceA. If the link between DeviceA and DeviceB fails, the IGP performs fast convergence first. As no route is found on DeviceA based on the IP address of DeviceC, BGP peer tracking detects that no reachable route to DeviceC is available and then notifies BGP on DeviceA of the fault. As a result, DeviceA terminates the BGP connection with DeviceC.

Figure 1-1727 Network diagram of BGP peer tracking

• If a default route exists on DeviceA and the link between DeviceA and DeviceB fails, BGP peer tracking will not terminate the peer relationship between DeviceA and DeviceC. This is because DeviceA can find the default route in the IP routing table based on the peer's IP address.
• If DeviceA and DeviceC establish an IBGP peer relationship, you are advised to enable BGP peer tracking on both devices to ensure that the peer relationship can be terminated soon after a fault occurs.
• If establishing a BGP peer relationship depends on IGP routes, you need to configure how long BGP peer tracking waits after detecting peer unreachability before it terminates the BGP connection. The configured length of time should be longer than the IGP route convergence time. Otherwise, before IGP route flapping caused by intermittent disconnection is suppressed, the BGP peer relationship may have been terminated. This results in unnecessary BGP convergence.

Background

With the wide application of IPv6 technologies, more and more separate IPv6 networks emerge. IPv6 provider edge (6PE), a technology designed to provide IPv6 services over IPv4 networks, allows service providers to provide IPv6 services without constructing new IPv6 backbone networks. The 6PE solution connects separate IPv6 networks using MPLS tunnels on IPv4 networks. The 6PE solution implements IPv4/IPv6 dual stack on the PEs of Internet service providers (ISPs) and uses MP-BGP to assign labels to IPv6 routes. In this manner, the 6PE solution connects separate IPv6 networks over IPv4 tunnels between PEs.

Related Concepts

Intra-AS 6PE

Figure 1-1728 shows intra-AS 6PE networking. 6PE runs on the edge of an ISP network. PEs that connect to IPv6 networks use the IPv4/IPv6 dual stack. PEs and CEs exchange IPv6 routes using the IPv6 EBGP or an IGP. PEs exchange routes with each other and with Ps using an IPv4 routing protocol. PEs need to establish tunnels to transparently transmit IPv6 packets. The tunnels mainly include MPLS label switched paths (LSPs) and MPLS Local Ifnet tunnels. By default, LSPs are preferentially selected. If no LSPs are available, MPLS Local Ifnet tunnels are used.

Figure 1-1728 Intra-AS 6PE networking diagram

Figure 1-1729 shows an intra-AS 6PE scenario where CE2 sends routes to CE1 and CE1 sends a packet to CE2. I-L indicates the inner label, whereas O-L indicates the outer tunnel label. The outer tunnel label is allocated by MPLS and is used to divert packets to the BGP next hop. The inner label indicates the outbound interface of the packets or the CE to which the packets belong.

The route and packet transmission processes show that CEs are unaware of whether the public network is an IPv4 or IPv6 network.

Figure 1-1729 Route and packet transmission in an intra-AS 6PE scenario

Inter-AS 6PE

Usage Scenario

Each 6PE mode has its advantages and usage scenarios. Intra-AS 6PE applies to scenarios where separate IPv6 networks connect to the same AS. Inter-AS 6PE applies to scenarios where separate IPv6 networks connect to different ASs. Table 1-678 lists the usage scenarios of inter-AS 6PE.

Benefits

6PE offers the following benefits:

• Easy maintenance: All configurations are performed on PEs, and IPv6 networks are unaware of the IPv4 network. The existing IPv4 network is used to carry IPv6 services, simplifying network maintenance.

• Low network construction cost: Carriers can make full use of the existing MPLS network resources and provide IPv6 services for users without upgrading the network. 6PE devices can also provide various types of services, such as IPv6 VPN and IPv4 VPN services.

Applications

On the network shown in Figure 1-1735, DeviceA and DeviceB are directly connected, and prefix-based ORF is enabled on them; after negotiating the prefix-based ORF capability with DeviceB, DeviceA adds the local prefix-based inbound policy to a Route-Refresh packet and then sends the Route-Refresh packet to DeviceB. DeviceB uses the information in the packet to work out an outbound policy to advertise routes to DeviceA.

Figure 1-1735 Applying ORF to directly connected BGP peers

As shown in Figure 1-1736, DeviceA and DeviceB are clients of the RR in the domain. Prefix-based ORF is enabled on all three NEs. After negotiating prefix-based ORF with the RR, DeviceA and DeviceB add the local prefix-based inbound policies Route-Refresh packets and then send the packets to the RR. Based on the Route-Refresh packets, the RR uses the information in the Route-Refresh packets to work out the outbound policies to reflect routes to DeviceA and DeviceB.

Figure 1-1736 Applying ORF to a domain with an RR

Background

As networks develop, users keep increasing. The broadcast export policies used by carriers no longer meet user requirements. Users want to receive only required routes, but it is costly for carriers to maintain an export policy for each user. ORF allows users to receive only desired routes, without requiring the carrier to maintain an export policy for each user. In this case, the ORF can meet the requirements of users and carriers.

Related Concepts

• RT-MEM-NLRI: VPN ORF route.
• PE: provider edge
• RR: route reflector
• ASBR: autonomous system boundary router

Implementation

PEs with VPN instances bound send to their BGP peers VPN ORF routes carrying desired import route targets (IRTs) and the original AS number. Based on the VPN ORF routes, the peers generate an export policy for each corresponding PE so that the PE receives only desired routes. This reduces the burden on the PEs.

On the network shown in Figure 1-1737, before VPN ORF is enabled, the RR sends to PE3 all routes of VPN instances received from PE1. However, among these routes, PE3 only desires the routes with ERT 1:1. In addition, the RR sends to PE1 all routes of VPN instances received from PE3. However, among these routes, PE1 only desires the routes with ERT 1:1.

Figure 1-1737 Basic usage scenario of VPN ORF

After VPN ORF is enabled, BGP peer relationships are established in the VPN-Target address family view. In Figure 1-1737, after BGP peer relationships are established between the RR and PE1 and between the RR and PE3, the peers negotiate the VPN ORF capability, PE1 and PE3 send VPN ORF routes carrying required import route targets (IRTs) and original AS number to their VPN ORF peers. The VPN ORF peers construct export policies based on the VPN ORF routes. After receiving the routes with targets 1:1 and 2:2 from PE1, the RR advertises only the routes with the target 1:1 to PE3. After receiving the routes with targets 1:1 and 3:3 from PE3, the RR advertises only the routes with the target 1:1 to PE1.

Usage Scenario

Benefits

• Reduced bandwidth consumption (because less routes are advertised)

• Reduced configuration workload

Application

On the network shown in Figure 1-1738, DeviceY advertises a learned BGP route to DeviceB and DeviceC in AS 100; DeviceB and DeviceC then advertise the route to the corresponding RR, which then reflects the route to DeviceA. In this case, DeviceA receives two routes whose next hops are DeviceB and DeviceC. Then, DeviceA selects a route based on a configured routing policy. Assume that the route sent by DeviceB is preferred. The route received through Link B functions as a backup link.

Figure 1-1738 Network diagram of BGP Auto FRR

If a node along Link A fails or a fault occurs on Link A, the next hop of the route from DeviceA to DeviceB becomes unavailable. If Auto FRR is enabled on DeviceA, the forwarding plane then quickly switches DeviceA-to-DeviceY traffic to Link B, which ensures uninterrupted traffic transmission. In addition, DeviceA performs route reselection based on prefixes. Consequently, it selects the route sent by DeviceC and then updates its FIB.

Background

Carriers have increasing demands for IP network reliability. Conventional non-stop forwarding (NSF) and graceful restart (GR) techniques cannot prevent traffic interruptions if a peer does not support GR or multiple peers fail simultaneously during a GR process. Traffic is interrupted temporarily before the GR process is complete because a GR-enabled router cannot obtain routing information from or establish control plane connections to its peers during the GR process.

NSR can be used to ensure uninterrupted traffic transmission and retain control plane connections if a software or hardware fault occurs on the control plane of a router. In addition, the fault is transparent to the control planes of its peers.

Related Concepts

Implementation

BGP NSR implements synchronization of the following BGP data between the AMB and SMB to support NSR.

• BGP forwarding entries

• BGP control blocks

The AMB and SMB must be installed on an NSR-enabled node to support NSR.

The NSR process is as follows:

1. Batch backup

   The AMB backs up BGP data in batches to the SMB immediately after the SMB starts.

2. Real-time backup

   The SMB backs up BGP data in real time and receives packets with the AMB simultaneously.

3. Switchover

   If the AMB fails, the SMB takes over services. The SMB retains uninterrupted operation of both the control and forwarding planes because data is synchronous between the AMB and SMB.

For details about NSR, see "Uninterruptible Service Technology" in Feature Description - Reliability.

Other Usages

An NSR device can function as a GR Helper. The GR Helper communicates with NSR-disabled devices and responds to peers' GR requests during an AMB/SMB switchover.

Usage Scenario

Benefits

Usage Scenario

The BGP dynamic update peer-groups feature is applicable to the following scenarios:

• Scenario with an international gateway

• Scenario with an RR

• Scenario where routes received from EBGP peers need to be sent to all IBGP peers

Figure 1-1740 Networking for the international gateway

Figure 1-1741 Networking for RRs with many clients

Figure 1-1742 Networking for a PE connected to multiple IBGP peers

The preceding scenarios have in common that the router needs to send routes to a large number of BGP peers, most of which share the same configuration. This situation is most evident in the networking shown in Figure 1-1741. In addition, when there are a large number of peers and routes, the packet sending efficiency is a performance bottleneck.

The update peer-group feature can overcome this bottleneck. After the feature is applied, each routing update is grouped only once, and the generated Update message is sent to all peers in the group. For example, an RR has 100 clients and needs to reflect 100,000 routes to them. If the RR groups routing updates per peer, it needs to group 100,000 routing updates 100 times (a total of 10 million) before sending Update messages to the 100 clients. The update peer-group feature improves performance 100-fold, because the 100,000 routing updates need to be grouped only once.

Purpose

2-byte autonomous system (AS) numbers used on networks range from 1 to 65535, and the available AS numbers are close to exhaustion as networks expand. Therefore, the AS number range needs to be extended. 4-byte AS numbers ranging from 1 to 4294967295 can address this problem. New speakers that support 4-byte AS numbers can co-exist with old speakers that support only 2-byte AS numbers.

Definition

4-byte AS numbers are extended from 2-byte AS numbers. Border Gateway Protocol (BGP) peers use a new capability code and optional transitive attributes to negotiate the 4-byte AS number capability and transmit 4-byte AS numbers. This mechanism enables communication between new speakers and between old speakers and new speakers.

To support 4-byte AS numbers, an open capability code 0x41 is defined in a standard protocol for BGP connection negotiation. 0x41 indicates that the BGP speaker supports 4-byte AS numbers.

If a new speaker with an AS number greater than 65535 communicates with an old speaker, the old speaker needs to set the peer AS number to AS_TRANS. AS_TRANS is a reserved AS number with the value being 23456.

Related Concepts

Fundamentals

BGP speakers negotiate capabilities by exchanging Open messages. Figure 1-1743 shows the format of Open messages exchanged between new speakers. The header of a BGP Open message is fixed, in which My AS Number is supposed to be the local AS number. However, My AS Number carries only 2-byte AS numbers, and does not support 4-byte AS numbers. Therefore, a new speaker adds the AS_TRANS 23456 to My AS Number and its local AS number to Optional Parameters before it sends an Open message to a peer. After the peer receives the message, it can determine whether the new speaker supports 4-byte AS numbers by checking Optional Parameters in the message.

Figure 1-1743 Format of Open messages sent by new speakers

Figure 1-1744 shows how peer relationships are established between new speakers, and between an old speaker and a new speaker. BGP speakers notify each other of whether they support 4-byte AS numbers by exchanging Open messages. After the capability negotiation, new sessions are established between new speakers, and old sessions are established between a new speaker and an old speaker.

Figure 1-1744 Process of establishing a BGP peer relationship

Figure 1-1745 Process of transmitting a BGP Update message

Format of 4-byte AS numbers

A 4-byte AS number can be an integer or in dotted notation. The system stores 4-byte AS numbers as unsigned integers, regardless of their formats. 4-byte AS numbers in dotted notation are in the format of X.Y. The formula of the conversion between 4-byte AS numbers for the two formats is as follows: Integer 4-byte AS number = X x 65536 + Y. For example, the 4-byte AS number in dotted notation 2.3 can be converted to the integer 4-byte AS number 131075 (2 x 65536 + 3).

The NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M supports 4-byte AS numbers of both formats. The 4-byte AS numbers displayed in the configuration files are in the format configured by users.

By default, the 4-byte AS numbers displayed in the display and debugging command outputs are in dotted notation, regardless of the configured format. If the default display format of 4-byte AS numbers is changed from dotted notation to integer using a command, the 4-byte AS numbers will be displayed as integers automatically.

If you adjust the display format of 4-byte AS numbers, the matching results of AS_Path regular expressions and extended community filters are affected. Specifically, if the display format of 4-byte AS numbers is changed when an AS_Path regular expression or extended community filter is used as an export or import policy, the AS_Path regular expression or extended community filter needs to be reconfigured. If reconfiguration is not performed, routes cannot match the export or import policy, and a network fault occurs.

Benefits

4-byte AS numbers alleviate AS number exhaustion and therefore are beneficial to carriers who need to expand the network scale.

Background

The BGP Monitoring Protocol (BMP) can monitor the BGP running status and trace data of BGP routes on network devices in real time. The BGP running status includes the establishment and termination of peer relationships and update of routing information. The trace data of BGP routes indicates how BGP routes on a device are processed; for example, processing of the routes that match an import or export route-policy.

Before BMP is implemented, only manual query can be used to obtain the BGP running status of devices, resulting in low monitoring efficiency.

After BMP is implemented, a device can be connected to a BMP server and configured to report its BGP running status to the server, significantly improving monitoring efficiency.

BMP Message Types

BMP sessions include Initiation, PU, RM, PD, SR, ROFT, and Termination messages, which are sent in packets. The information reported in these messages mainly includes BGP routing information, BGP peer information, and device vendor and version information.

• Initiation message: sent by a monitored device to the monitoring server to report information such as the device vendor and software version.

• Peer Up Notification (PU) message: sent by a monitored device to notify the monitoring server that a BGP peer relationship has been established.

• Route Monitoring (RM) message: used to provide the monitoring server with a collection of all routes received from a BGP peer and notify the server of route addition or withdrawal in real time.

• Peer Down Notification (PD) message: sent to notify the monitoring server that a BGP peer relationship has been disconnected.

• Stats Reports (SR) message: sent to report statistics about the device running status to the monitoring server.

• Termination message: sent to report the cause for closing a BMP session to the monitoring server.

• Route Policy and Attribute Trace (ROFT) message: used to report the trace data of routes to the monitoring server in real time.

BMP sessions are unidirectional. Devices send messages to the monitoring server but ignore messages sent by the server.

Implementation

On the network shown in Figure 1-1748, TCP connections are established between the monitoring server and monitored devices (PE1 and PE2 shown in the figure). The monitored devices send unsolicited BMP messages to the monitoring server to report information about the BGP running status. Upon receiving these BMP messages, the monitoring server parses them and displays the BGP running status in the monitoring view. By analyzing the headers in the received BMP messages, the monitoring server can determine which BGP peers have advertised the routes carried in these messages.

When establishing a connection between a BGP device and monitoring server, note the following guidelines:

• BMP operates over TCP, and you can specify a port number for the TCP connection between the BGP device and monitoring server.
• One device can connect to multiple monitoring servers, and one monitoring server can also connect to multiple devices.
• Each BMP instance can connect to multiple monitoring servers. The advantages are as follows:
  • Multiple monitoring servers back up each other, improving reliability.
  • The load of a single server in monitoring BGP peers is reduced.
  • Different servers can be used to monitor routes from the same BGP peer in different address families, allowing each BGP service to be monitored by a different server.
• A monitoring server can monitor all BGP peers or a specified one.

Figure 1-1748 Typical BMP networking

Benefits

BMP facilitates the monitoring of the BGP running status and reports security risks on networks in real time so that preventive measures can be taken promptly to improve network stability.

Background

If multiple routes to the same destination are available, a BGP device selects one optimal route based on BGP route selection policies and advertises the route to its BGP peers.

For details about BGP route selection policies, see BGP Fundamentals.

However, in scenarios with master and backup provider edges (PEs), if routes are selected based on the preceding policies, the BGP route convergence takes a long time because no backup route is available. To address this problem, the BGP Best External feature was introduced.

Related Concepts

BGP Best External: After BGP Best External is enabled on a device, if the route preferentially selected by the device is an IBGP route, the device selects the sub-optimal route (EBGP or IBGP route) and advertises it to its peers. BGP Best External implements fast route convergence if the link between the device and a peer fails.

Best External route: The sub-optimal route selected after BGP Best External is enabled.

Networking with Master and Backup PEs

In the networking shown in Figure 1-1749, CE1 is dual-homed to PE1 and PE2. PE1 has a larger Local_Pref value than PE2. EBGP peer relationships are established between CE1 and PE1, and between CE1 and PE2. In addition, IBGP peer relationships are established among PE1, PE2, and PE3. PE1 and PE2 receive the same route to 1.1.1.1/32 from CE1, and PE2 receives the route from PE1. Of the two routes, PE2 preferentially selects the route from PE1 because PE1 has a larger Local_Pref value than CE1. PE2 does not advertise the route received from PE1 to PE3. Therefore, PE3 has only one route, which is advertised by PE1. If the primary link fails, traffic can be switched to the backup link only after routes are re-converged.

Figure 1-1749 Networking with master and backup PEs

BGP Best External can be enabled on PE2 to address this problem. With BGP Best External, PE2 selects the EBGP route from CE1 and advertises it to PE3. In this case, a backup link is available. Table 1-679 lists the differences with and without BGP Best External.

Usage Scenario

The master and backup provider edges (PEs) need to advertise sub-optimal routes (Best External routes) to peers to implement fast route convergence in the case of a link fault.

Benefits

As networks develop, services, such as Voice over Internet Protocol (VoIP), online video, and financial services, pose higher requirements for real-time transmission. After BGP Best External is deployed, if the optimal route selected by a device is an IBGP route, the device selects the suboptimal route and advertises it to BGP peers. This implements fast route convergence in the case of a link fault and reduces the impact of traffic interruption on services.

Background

In a scenario with a route reflector (RR) and clients, if the RR has multiple routes to the same destination (with the same prefix), the RR selects an optimal route from these routes and then sends only the optimal route to its clients. Therefore, the clients have only one route to the destination. If a link along this route fails, route convergence takes a long time, which cannot meet the requirements on high reliability.

To address this issue, deploy the BGP Add-Path feature on the RR. With BGP Add-Path, the RR can send two or more routes with the same prefix to its clients. After reaching the clients, these routes can work in primary/backup or load-balancing mode, which ensures high reliability in data transmission.

• For details about BGP route selection and advertisement policies, see BGP Fundamentals.

• Although BGP Add-Path can be deployed on any router, you are advised to deploy it on RRs.

• With BGP Add-Path, you can configure the maximum number of routes with the same prefix that an RR can send to its clients. The actual number of routes with the same prefix that an RR can send to its clients is the smaller value between the configured maximum number and the number of available routes with the same prefix.

Related Concepts

Add-Path routes: The routes selected by BGP after BGP Add-Path is configured.

Typical Networking

On the network shown in Figure 1-1750, DeviceA, DeviceB, and DeviceC are clients of the RR, and DeviceD is an EBGP peer of DeviceB and DeviceC. Both DeviceB and DeviceC receive a route to 10.1.1.1/32 from DeviceD.

DeviceB and DeviceC advertise the route 10.1.1.1/32 to the RR. The two routes have the same destination address but different next hops. The RR selects an optimal route based on BGP route selection rules and advertises the optimal route to DeviceA. Therefore, Device A has only one route to 10.1.1.1/32.

Figure 1-1750 Networking with BGP Add-Path

BGP Add-Path can be configured on the RR to control the maximum number of routes with the same prefix that the RR can send to DeviceA. Assume that the configured maximum number of routes with the same prefix that the RR can send to DeviceA is 2. Table 1-680 lists the differences with and without BGP Add-Path.

Usage Scenario

BGP Add-Path applies to scenarios in which an RR is deployed and needs to send multiple routes with the same prefix to clients to ensure data transmission reliability. BGP Add-Path supports route attribute-or prefix-based filtering to control Add-Path route advertisement in a refined manner.

BGP Add-Path is used in traffic optimization scenarios and allows multiple routes to be sent to the controller.

Benefits

Deploying BGP Add-Path can improve network reliability.

Background

BGP peer flapping occurs when BGP peer relationships are disconnected and then immediately re-established in a quick sequence that is repeated. Frequent BGP peer flapping is caused by various factors; for example, a link is unstable, or an interface that carries BGP services is unstable. After a BGP peer relationship is established, the local device and its BGP peer usually exchange all routes in their BGP routing tables with each other. If the BGP peer relationship is disconnected, the local device deletes all the routes learned from the BGP peer. Generally, a large number of BGP routes exist, and in this case, a large number of routes change and a large amount of data is processed when BGP peers frequently flap. As a result, a large number of resources are consumed, causing high CPU usage. To prevent this issue, a device supports suppression on BGP peer flapping. With this function enabled, the local device suppresses the establishment of the BGP peer relationship if it flaps continuously.

Related Concepts

ConnectFlaps: indicates the peer flapping count. The peer flapping count increases each time BGP peer flapping occurs. After flapping suppression exits, the statistics are cleared. Otherwise, the accumulated statistics are retained.

Peer flapping suppression period: The peer flapping suppression period is adjusted based on the ConnectFlaps value.

Idle hold timer: indicates the timer used by BGP to determine the waiting period for establishing a peer relationship with a peer. After the Idle hold timer expires, BGP attempts to establish a new connection with the BGP peer.

Half-life period: When the peer flapping counter (ConnectFlaps value) changes, the peer flapping count adjustment timer starts. If the timer expires (more than 1800s), the ConnectFlaps value is reduced by half. This period specified by the peer flapping count adjustment timer is called a half-life period.

Fundamentals

Entering flapping suppression

As shown in Figure 1-1752, when the ConnectFlaps value reaches a certain value (greater than 5), the Idle hold timer is used to suppress the establishment of the BGP peer relationship. The Idle hold timer value is calculated as follows:

Idle hold timer = Initial waiting time + Peer flapping suppression period,

where, if the peer timer connect-retry connect-retry-time command is not run, the initial time that BGP waits to establish the peer relationship is 10s. If this command is run, the configured connect-retry-time value is used as the initial waiting time.

The peer flapping suppression period is processed as follows: If the ConnectFlaps value ranges from 1 to 5, the establishment of the peer relationship is not suppressed. If the ConnectFlaps value ranges from 6 to 10, the peer flapping suppression period increases by 10s each time the ConnectFlaps value is incremented by 1. If the ConnectFlaps value ranges from 11 to 15, the peer flapping suppression period increases by 20s each time the ConnectFlaps value is incremented by 1. For each of the following five-value ranges, the peer flapping suppression period increases by twice the time of the previous range each time the ConnectFlaps value is incremented by 1. The peer flapping suppression period no longer increases until the Idle hold timer reaches 600s. This prevents a BGP negotiation failure due to long-time suppression.

Figure 1-1752 Relationship between the Idle hold timer and ConnectFlaps values when the initial waiting time is 10s

When the ConnectFlaps value changes, the peer flapping count adjustment timer starts. If the timer expires (more than 1800s have passed), the ConnectFlaps value is reduced by half, and a half-life period ends. In this case, if the ConnectFlaps value has not reached 0, the next half-life period will start. This process is cyclically repeated until the ConnectFlaps counter is reset. Assume that the ConnectFlaps value is 10. After four half-life periods elapse, the ConnectFlaps value changes to 0, as shown in Figure 1-1753.

Figure 1-1753 Half-life periods

Exiting flapping suppression

Peer flapping suppression can be canceled in either of the following ways:

• Resetting the involved BGP process or BGP peer relationship
• Running a command that forcibly exits flapping suppression

Background

In some scenarios, a large number of routes may recurse to the same next hop. If the next hop flaps due to a device fault, the system will become occupied processing reselection and re-advertisement of each involved route, leading to excessive resource consumption and high CPU usage. To address this problem, enable BGP recursion suppression in case of next hop flapping. If the next hop frequently flaps, recursion suppression in case of next hop flapping slows down route processing, conserving system resources and reducing CPU usage.

Fundamentals

When the number of recursion suppressions in case of next hop flapping reaches a certain value (greater than 10), route processing is much lower than that without suppression.

Benefits

BGP recursion suppression in case of next hop flapping prevents the system from frequently processing reselection and re-advertisement of a large number of routes that are recursed to a flapping next hop, reducing system resource consumption and CPU usage.

Background

BGP-LS is a new method of collecting topology information.

Related Concepts

BGP-LS provides a simple and efficient method of collecting topology information.

BGP-LS routes carry topology information and are classified into six types of routes that carry node, link, route prefix, IPv6 route prefix, SRv6 SID, and TE Policy information, respectively. These routes work together to transmit topology information.

BGP-LS Routes

Based on BGP, BGP-LS introduces a series of new Network Layer Reachability Information (NLRI) attributes to carry information about links, nodes, and IPv4/IPv6 prefixes. Such new NLRIs are called Link-State NLRIs. BGP-LS includes the MP_REACH_NLRI or MP_UNREACH_NLRI attribute in BGP Update messages to carry Link-State NLRIs.

BGP-LS defines the following types of Link-State NLRI:

• Node NLRI
• Link NLRI
• IPv4 Topology Prefix NLRI
• IPv6 Topology Prefix NLRI

In addition, the BGP-LS attribute is defined for Link-State NLRI to carry link, node, and IPv4/IPv6 prefix parameters and attributes. The BGP-LS attribute is defined as a set of Type, Length, Value (TLV) triplets and carried with Link-State NLRI attributes in BGP-LS messages. All these attributes are optional, non-transitive BGP attributes, including Node Attribute, Link Attribute, and Prefix Attribute.

Node NLRI format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                Local Node Descriptors (variable)            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link NLRI format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Local Node Descriptors (variable)             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Remote Node Descriptors (variable)            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                  Link Descriptors (variable)                //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	

IPv4/IPv6 Topology Prefix NLRI

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //              Local Node Descriptors (variable)              //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                Prefix Descriptors (variable)                //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	

BGP-LS Route Formats

Format of node routes

For example, a node route is in the format of [NODE][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as100][bgp-ls-identifier10.1.1.2][ospf-area-id0.0.0.0][igp-router-id0000.0000.0001.00]].

Node routes carry node information.

Table 1-684 describes the fields in node routes.

Format of link routes

For example, a link route is in the format of [LINK][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as255.255][bgp-ls-identifier192.168.102.4][ospf-area-id0.0.0.0][igp-router-id0000.0000.0002.01]][REMOTE[as255.255][bgp-ls-identifier192.168.102.4][ospf-area-id0.0.0.0][igp-router-id0000.0000.0002.00]][LINK[if-address0.0.0.0][peer-address0.0.0.0][if-address::][peer-address::][mt-id0]].

Link routes carry information about links between devices.

Table 1-685 describes the fields in link routes.

Format of prefix routes

For example, a prefix route is in the format of [IPV4-PREFIX][ISIS-LEVEL-1][IDENTIFIER0][LOCAL[as100][bgp-ls-identifier192.168.102.3][ospf-area-id0.0.0.0][igp-router-id0000.0000.0001.00]][PREFIX[mt-id0][ospf-route-type0][prefix192.168.102.0/24]].

Prefix routes carry information about reachable network segments.

Table 1-686 describes the fields in prefix routes.

Format of TE Policy routes

For example: [TEPOLICY][SEGMENT-ROUTING][IDENTIFIER0][LOCAL[as100][bgp-ls-identifier1.1.1.1][bgp-router-id1.1.1.2][ipv4-router-id1.1.1.9][ipv6-router-id2001:DB8:1::1]][TE[protocol-origin3][Flag0][endpoint2.2.2.2][color123][originator-as0][originator-address0.0.0.0][discriminator500]]

The routes carry information about SR TE Policy-related topology and status.

Table 1-687 describes the fields in TE Policy routes.

Format of IPv6 prefix routes

For example: [IPV6-PREFIX][ISIS-LEVEL-2][IDENTIFIER100][LOCAL[as200][bgp-ls-identifier192.168.11.11][ospf-area-id0.0.0.0][igp-router-id0000.0000.0004.00]][PREFIX[mt-id0][ospf-route-type0][prefix2001:DB8:1::1/64]]

The routes carry information about reachable network segments.

Table 1-688 describes the fields in IPv6 prefix routes.

Format of SRv6 SID routes

For example, an SRv6 SID route is in the format of [SRV6-SID][ISIS-LEVEL-2][IDENTIFIER100][LOCAL[as200][bgp-ls-identifier192.168.11.11][ospf-area-id0.0.0.0][igp-router-id0000.0000.0004.00]][SID[mt-id0][sid2001:db8:1::1]].

Such routes carry information about reachable network segments.

Table 1-689 describes the fields in this type of route.

Typical Networking

Collecting topology information in an IGP area

In Figure 1-1754, DeviceA, DeviceB, DeviceC, and DeviceD use IS-IS to communicate with each other at the IP network layer. DeviceA, DeviceB, DeviceC, and DeviceD are all Level-2 devices in the same area (area 10). After BGP-LS is deployed on any one of the devices (DeviceA, DeviceB, DeviceC, and DeviceD) and this device establishes a BGP-LS peer relationship with the controller, topology information of the entire network can be collected and reported to the controller. Reliability can be improved by deploying BGP-LS on two or more devices and establishing a BGP-LS peer relationship between each BGP-LS device and the controller. Because the BGP-LS devices collect the same topology information, they back up each other. This means that the topology information can be reported promptly if any of the BGP-LS devices fails.

Figure 1-1754 Networking in which topology information is collected within an IGP area

Collecting BGP inter-AS topology information

In Figure 1-1755, DeviceA and DeviceB belong to the same AS, and an IS-IS neighbor relationship is established between them. BGP is not enabled on DeviceA in the AS. An EBGP peer relationship is established between DeviceB and DeviceC. If BGP-LS is not enabled, topology information cannot be transmitted between the ASs. Because the devices collect information about only their own AS, the topology information in AS 100 is different from that in AS 200. In this case, BGP-LS must be enabled on at least one device in each AS and this device must establish a BGP-LS peer relationship with the controller. To ensure that topology information can be collected and reported reliably, enable that two or more devices in each AS are connected to the controller.

Figure 1-1755 Networking 1 in which topology information is collected across BGP ASs

On the network shown in Figure 1-1756, two controllers are each connected to a device in a different AS. If both controllers need to obtain information about the entire network's topology, a BGP-LS peer relationship needs to be established between the controllers or between the devices (DeviceB and DeviceC in this example) connected to the controllers.

Figure 1-1756 Networking 2 in which topology information is collected across BGP ASs

To minimize the number of connections with the controllers, one or more devices can be used as BGP-LS RRs, which then function as proxies to establish BGP-LS peer relationships between the devices and controllers.

Usage Scenario

The router functions as a forwarder and reports topology information to the controller for topology monitoring and traffic control.

Benefits

BGP-LS offers the following benefits:

• Reduces computing capability requirements on the controller.
• Allows the controller to gain the complete inter-AS topology information.
• Requires only one routing protocol (BGP) to report topology information to the controller.

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 specified 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. The local device functions as a forwarder and only receives and executes policies delivered by NCE. No additional configuration is required.

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-690 describes the fields in the routes.

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

Figure 1-1757 WideCommunity format used by RPD routes

Implementation

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

Figure 1-1758 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 1-1758 Typical networking of inbound traffic optimization

In Figure 1-1758, 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.

Background

By default, all BGP routes are stored in the BGP basic instance, and separate route management and maintenance are impossible. To address this problem, BGP multi-instance is introduced. A device can simultaneously run two BGP instances: a BGP basic instance and a BGP multi-instance. The two BGP instances are independent of each other and can have either the same AS number or different AS numbers. BGP multi-instance can achieve separate route management and maintenance by having different address families deployed in the BGP basic instance and BGP multi-instance.

Basic Concepts

Implementation

Figure 1-1759 BGP multi-instance for service isolation

BGP SR LSP Creation

BGP SR LSPs are created primarily based on prefix SIDs. The destination node uses BGP to advertise a prefix SID, creates an LSP, and delivers the forwarding entry to guide data packet forwarding. Each forwarder parses the prefix SID and obtains the outgoing label and outbound interface based on the tunnel forwarding table to guide traffic forwarding. On the network shown in Figure 1-1760, each pair of neighboring nodes — A and B, B and C, and C and D — establish an LDP LSP, and belong to different IGP areas. To ensure service interworking between node A and node D, an E2E BGP SR LSP needs to be established. This section describes only the process of establishing a BGP SR LSP. For details about the process of establishing an LDP LSP, see LDP LSP Establishment.

Figure 1-1760 Prefix SID-based BGP SR LSP creation

Table 1-692 describes the process of establishing a prefix SID-based BGP SR LSP.

Data Forwarding

BGP SR LSPs use the same three types of label operations as those used in MPLS: push, swap, and pop.

Figure 1-1761 Prefix SID-based data forwarding

Table 1-693 describes the process of data forwarding on the network shown in Figure 1-1761.