No relevant resource is found in the selected language.

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

Reminder

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

upgrade

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Principles

Principles

This section describes BGP implementation.

BGP Concepts

This section describes BGP concepts to help you better understand BGP functions.

Autonomous System

An Autonomous System (AS) is a group of Internet Protocol (IP) networks that are controlled by one entity, typically an Internet service provider (ISP), and that have the same routing policy. Each AS is assigned a unique AS number, which identifies an AS on a BGP network. Two types of AS numbers are available: 2-byte AS numbers and 4-byte AS numbers. A 2-byte AS number ranges from 1 to 65535, and a 4-byte AS number ranges from 1 to 4294967295. Devices supporting 4-byte AS numbers are compatible with devices supporting 2-byte AS numbers.

BGP Classification

As shown in Figure 7-93, BGP is classified into two types according to where it runs: Internal BGP (IBGP) and External BGP (EBGP).

Figure 7-93 BGP operating mode

  • EBGP: runs between ASs. To prevent routing loops between ASs, a BGP device discards the routes with the local AS number when receiving the routes from EBGP peers.

  • IBGP: runs within an AS. To prevent routing loops within an AS, a BGP device does not advertise the routes learned from an IBGP peer to the other IBGP peers and establishes full-mesh connections with all the IBGP peers. To address the problem of too many IBGP connections between IBGP peers, BGP uses Route Reflector and BGP Confederation.

    NOTE:
    If a BGP device needs to advertise the route received from an EBGP peer outside an AS through another BGP device, IBGP is recommended.
Device Roles in BGP Message Exchange

There are two device roles in BGP message exchange:

  • Speaker: The device that sends BGP messages is called a BGP speaker. The speaker receives and generates new routes, and advertises the routes to other BGP speakers.

  • Peer: The speakers that exchange messages with each other are called BGP peers. A group of peers sharing the same policies can form a peer group.

BGP Router ID

The BGP router ID is a 32-bit value that is often represented by an IPv4 address to identify a BGP device. It is carried in the Open message sent during the establishment of a BGP session. When two BGP peers need to establish a BGP session, they each require a unique router ID. Otherwise, the two peers cannot establish a BGP session.

The BGP router ID of a device must be unique on a BGP network. It can be manually configured or selected from IPv4 addresses on the device. By default, an IPv4 address of a loopback interface on a device is used as the BGP router ID. If no loopback interface is configured on the device, the system selects the largest IPv4 address from all IPv4 addresses of interfaces as the BGP router ID. Once the BGP router ID is selected, the system retains this router ID even if a larger IPv4 address is configured on the device later. The system changes the BGP router ID only when the corresponding IPv4 address is deleted.

BGP Working Principles

BGP peer establishment, update, and deletion involve five types of messages, six state machine states, and five route exchange rules.

BGP Messages

BGP peers exchange the following messages, among which Keepalive messages are periodically sent and other messages are triggered by events.

  • Open message: is used to establish BGP peer relationships.

  • Update message: is used to exchange routes between BGP peers.

  • Notification message: is used to terminate BGP connections.

  • Keepalive message: is used to maintain BGP connections.

  • Route-refresh message: is used to request the peer to resend routes if routing policies are changed. Only the BGP devices supporting route-refresh can send and respond to Route-refresh messages.

BGP State Machine

As shown in Figure 7-94, a BGP device uses a finite state machine (FSM) to determine its operations with peers. The FSM has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Three common states are involved in BGP peer establishment: Idle, Active, and Established.

Figure 7-94 BGP state machine

  1. The Idle state is the initial BGP state. In Idle state, the BGP device refuses all connection requests from neighbors. The BGP device initiates a TCP connection with its BGP peer and changes its state to Connect only after receiving a Start event from the system.
    NOTE:
    • The Start event occurs when an operator configures a BGP process or resets an existing BGP process or when the router software resets a BGP process.

    • If an error occurs at any state of the FSM, for example, the BGP device receives a Notification packet or TCP connection termination notification, the BGP device returns to the Idle state.

  2. In Connect state, the BGP device starts the Connect Retry timer and waits to establish a TCP connection.

    • If the TCP connection is established, the BGP device sends an Open message to the peer and changes to the OpenSent state.
    • If the TCP connection fails to be established, the BGP device moves to the Active state.
    • If the BGP device does not receive a response from the peer before the Connect Retry timer expires, the BGP device attempts to establish a TCP connection with another peer and stays in Connect state.
  3. In Active state, the BGP device keeps trying to establish a TCP connection with the peer.

    • If the TCP connection is established, the BGP device sends an Open message to the peer, closes the Connect Retry timer, and changes to the OpenSent state.
    • If the TCP connection fails to be established, the BGP device stays in the Active state.
    • If the BGP device does not receive a response from the peer before the Connect Retry timer expires, the BGP device returns to the Connect state.
  4. In OpenSent state, the BGP device waits an Open message from the peer and then checks the validity of the received Open message, including the AS number, version, and authentication password.

    • If the received Open message is valid, the BGP device sends a Keepalive message and changes to the OpenConfirm state.
    • If the received Open message is invalid, the BGP device sends a Notification message to the peer and returns to the Idle state.
  5. In OpenConfirm state, the BGP device waits for a Keepalive or Notification message from the peer. If the BGP device receives a Keepalive message, it transitions to the Established state. If it receives a Notification message, it returns to the Idle state.
  6. In Established state, the BGP device exchanges Update, Keepalive, Route-refresh, and Notification messages with the peer.

    • If the BGP device receives a valid Update or Keepalive message, it considers that the peer is working properly and maintains the BGP connection with the peer.
    • If the BGP device receives a valid Update or Keepalive message, it sends a Notification message to the peer and returns to the Idle state.
    • If the BGP device receives a Route-refresh message, it does not change its status.
    • If the BGP device receives a Notification message, it returns to the Idle state.
    • If the BGP device receives a TCP connection termination notification, it terminates the TCP connection with the peer and returns to the Idle state.
Route Exchange Rules

A BGP device adds optimal routes to the BGP routing table to generate BGP routes. After establishing a BGP peer relationship with a neighbor, the BGP device follows the following rules to exchange routes with the peer:

  • Advertises the BGP routes received from IBGP peers only to its EBGP peers.

  • Advertises the BGP routes received from EBGP peers to its EBGP peers and IBGP peers.

  • Advertises the optimal route to its peers when there are multiple valid routes to the same destination.

  • Sends only updated BGP routes when BGP routes change.

  • Accepts all the routes sent from its peers.

Interaction Between BGP and an IGP

BGP and IGPs use different routing tables. To enable different ASs to communicate, you need to configure interaction between BGP and IGPs so that BGP routes can be imported into IGP routing tables and IGP routes can also be imported to BGP routing tables.

Importing IGP Routes to BGP Routing Tables

BGP does not discover routes and so needs to import the routes discovered by IGPs to BGP routing tables so that different ASs can communicate. When an AS needs to advertise routes to another AS, an Autonomous System Boundary Router (ASBR) imports IGP routes to its BGP routing table. To better plan the network, you can use routing policies to filter routes and set route attributes when BGP imports IGP routes. Alternatively, you can set the multi-exit discriminator (MED) to help EBGP peers select the best path for traffic entering an AS.

BGP imports routes in either import or network mode:

  • In import mode, BGP imports IGP routes, including RIP, OSPF, and IS-IS routes, into BGP routing tables based on protocol type. To ensure the validity of imported IGP routes, BGP can also import static routes and direct routes in import mode.

  • In network mode, BGP imports the routes in the IP routing table one by one to BGP routing tables. The network mode is more accurate than the import mode.

Importing BGP Routes to IGP Routing Tables

When an AS needs to import routes from another AS, an ASBR imports BGP routes to its IGP routing table. To prevent a large number of BGP routes from affecting devices within the AS, IGPs can use routing policies to filter routes and set route attributes when importing BGP routes.

BGP Security

BGP uses authentication, Generalized TTL Security Mechanism (GTSM), and Resource Public Key (RPKI) Infrastructure to ensure exchange security between BGP peers.

BGP Authentication

BGP authentication includes Message Digest 5 (MD5) authentication and keychain authentication, which improves communication security between BGP peers. In MD5 authentication, you can only set the authentication password for a TCP connection. In keychain authentication, you can set the authentication password for a TCP connection and authenticate BGP messages.

BGP GTSM

BGP GTSM checks whether the time to live (TTL) value in the IP packet header is within a predefined range and permits or discards the packets of which the TTL values are out of the predefined range to protect services above the IP layer. BGP GTSM enhances system security.

Assume that the TTL value range of packets from BGP peers is set to 254-255. When an attacker forges valid BGP packets and keeps sending these packets to attack a device, the TTL values of these packets are smaller than 254. If BGP GTSM is not enabled on the device, the device finds that these packets are destined for itself and sends the packets to the control plane for processing. Then the control layer needs to process a large number of such attack packets, causing high CPU usage. If BGP GTSM is enabled on the device, the system checks the TTL values in all BGP packets and discards the attack packets of which the TTL values are smaller than 254. This prevents network attack packets from consuming CPU resources.

BGP Route Selection Rules and Load Balancing

There may be multiple routes to the same destination in a BGP routing table. BGP will select one route as the optimal route and advertise it to peers. To select the optimal route among these routes, BGP compares the BGP attributes of the routes in sequence based on route selection rules.

BGP Attributes

Route attributes describe routes. BGP route attributes are classified into the following types. Table 7-49 lists common BGP attributes.

  • Well-known mandatory attribute

    All BGP devices can identify this type of attributes, which must be carried in Update messages. Without this type of attributes, errors occur in routing information.

  • Well-known discretionary attribute

    All BGP devices can identify this type of attributes, which are optional in Update messages. Without this type of attributes, errors do not occur in routing information.

  • Optional transitive attribute

    BGP devices may not identify this type of attributes but still accepts them and advertises them to peers.

  • Optional non-transitive attribute

    BGP devices may not identify this type of attributes. If a BGP device does not identify this type of attributes, it ignores them and does not advertise them to peers.

Table 7-49 Common BGP attributes
Attribute Type
Origin Well-known mandatory
AS_Path Well-known mandatory
Next_Hop Well-known mandatory
Local_Pref Well-known discretionary
Community Optional transitive
MED Optional non-transitive
Originator_ID Optional non-transitive
Cluster_List Optional non-transitive

The following describes common BGP route attributes:

  • Origin

    The Origin attribute defines the origin of a route and marks the path of a BGP route. The Origin attribute is classified into three types:

    • IGP

      A route with IGP as the Origin attribute is of the highest priority. The Origin attribute of the routes imported into a BGP routing table using the network command is IGP.

    • EGP

      A route with EGP as the Origin attribute is of the secondary highest priority. The Origin attribute of the routes obtained through EGP is EGP.

    • Incomplete

      A route with Incomplete as the Origin attribute is of the lowest priority. The Origin attribute of the routes learned by other means is Incomplete. For example, the Origin attribute of the routes imported by BGP using the import-route command is Incomplete.

  • AS_Path

    The AS_Path attribute records all the ASs that a route passes through from the source to the destination in the vector order. To prevent inter-AS routing loops, a BGP device does not receive the routes of which the AS_Path list contains the local AS number.

    When a BGP speaker advertises an imported route:

    • If the route is advertised to EBGP peers, the BGP speaker creates an AS_Path list containing the local AS number in an Update message.

    • If the route is advertised to IBGP peers, the BGP speaker creates an empty AS_Path list in an Update message.

    When a BGP speaker advertises a route learned in the Update message sent by another BGP speaker:

    • If the route is advertised to EBGP peers, the BGP speaker adds the local AS number to the leftmost of the AS_Path list. According to the AS_Path list, the BGP speaker that receives the route can learn about the ASs through which the route passes to reach the destination. The number of the AS that is nearest to the local AS is placed on the top of the AS_Path list. The other AS numbers are listed according to the sequence in which the route passes through ASs.

    • If the route is advertised to IBGP peers, the BGP speaker does not change the AS_Path attribute of the route.

  • Next_Hop

    The Next_Hop attribute records the next hop that a route passes through. The Next_Hop attribute of BGP is different from that of an IGP because it may not be the neighbor IP address. A BGP speaker processes the Next_Hop attribute based on the following rules:

    • When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop attribute of the route to the address of the local interface through which the BGP peer relationship is established with the peer.

    • When advertising a locally originated route to an IBGP peer, the BGP speaker sets the Next_Hop attribute of the route to the address of the local interface through which the BGP peer relationship is established with the peer.

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

  • Local_Pref

    The Local_Pref attribute indicates the BGP preference of a device and helps determine the optimal route when traffic leaves an AS. When a BGP device obtains multiple routes to the same destination address but with different next hops from different IBGP peers, the BGP device prefers the route with the highest Local_Pref. The Local_Pref attribute is exchanged only between IBGP peers and is not advertised to other ASs. The Local_Pref attribute can be manually configured. If no Local_Pref attribute is configured for a route, the Local_Pref attribute of the route uses the default value 100.

  • MED

    The multi-exit discriminator (MED) attribute helps determine the optimal route when traffic enters an AS. When a BGP device obtains multiple routes to the same destination address but with different next hops from EBGP peers, the BGP device selects the route with the smallest MED value as the optimal route.

    The MED attribute is exchanged only between two neighboring ASs. The AS that receives the MED attribute does not advertise it to any other ASs. The MED attribute can be manually configured. If no MED attribute is configured for a route, the MED attribute of the route uses the default value 0.

  • Community

    The Community attribute identifies the BGP routes with the same characteristics, simplifies the applications of routing policies, and facilitates route maintenance and management.

    The Community attribute includes self-defined community attributes and well-known community attributes. Table 7-50 lists well-known community attributes.

    Table 7-50 Well-known community attributes

    Community Attribute

    Value

    Description

    Internet

    0 (0x00000000)

    A BGP device can advertise the received route with the Internet attribute to all peers.

    No_Advertise

    4294967042 (0xFFFFFF02)

    A BGP device does not advertise the received route with the No_Advertise attribute to any peer.

    No_Export

    4294967041 (0xFFFFFF01)

    A BGP device does not advertise the received route with the No_Export attribute to devices outside the local AS.

    No_Export_Subconfed

    4294967043 (0xFFFFFF03)

    A BGP device does not advertise the received route with the No_Export_Subconfed attribute to devices outside the local AS or to devices outside the local sub-AS.

  • Originator_ID and Cluster_List

    The Originator_ID attribute and Cluster_List attribute help eliminate loops in route reflector scenarios. For details, see Route Reflector.

BGP Route Selection Policies

When there are multiple routes to the same destination, BGP compares the following attributes in sequence to select the optimal route:

  1. Prefers the route with the largest PrefVal value.

    The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it is configured.

  2. Prefers the route with the highest Local_Pref.

    If a route does not have the Local_Pref attribute, the Local_Pref attribute of the route uses the default value 100.

  3. Prefers the manually summarized route, automatically summarized route, route imported using the network command, route imported using the import-route command, and route learned from peers. These routes are in descending order of priority.

  4. Prefers the route with the shortest AS_Path.

  5. Prefers the route with the lowest origin type. IGP is lower than EGP, and EGP is lower than Incomplete.

  6. Prefers the route with the lowest MED if routes are received from the same AS.

  7. Prefers EBGP routes, IBGP routes, LocalCross routes, and RemoteCross routes, which are listed in descending order of priority.

    LocalCross allows a PE to add the VPNv4 route of a VPN instance to the routing table of the VPN instance if the export RT of the VPNv4 route matches the import RT of another VPN instance on the PE. RemoteCross allows a local PE to add the VPNv4 route learned from a remote PE to the routing table of a VPN instance on this local PE if the export RT of the VPNv4 route matches the import RT of the VPN instance.

  8. Prefers the route with the lowest IGP metric to the BGP next hop.
    NOTE:

    If there are multiple routes to the same destination, an IGP calculates the route metric using its routing algorithm.

  9. Prefers the route with the shortest Cluster_List.

  10. Prefers the route advertised by the device with the smallest router ID.

    NOTE:

    If a route carries the Originator_ID attribute, BGP prefers the route with the smallest Originator_ID without comparing the router ID.

  11. Prefers the route learned from the peer with the lowest IP address.

BGP Load Balancing

When there are multiple equal-cost routes to the same destination, you can perform load balancing among these routes to load balance traffic. Equal-cost BGP routes can be generated for traffic load balancing only when the first eight route attributes described in "BGP Route Selection Policies" are the same.

Route Reflector

To ensure connectivity between IBGP peers, you need to establish full-mesh connections between IBGP peers. If there are n devices in an AS, n(n-1)/2 IBGP connections need to be established. When there are a large number of devices, many network resources and CPU resources are consumed. A route reflector (RR) can be used between IBGP peers to solve this problem.

Roles in RR

As shown in Figure 7-95, the following roles are involved in RR scenarios in an AS.

Figure 7-95 Networking diagram of the RR

  • Route reflector (RR): a BGP device that can reflect the routes learned from an IBGP peer to other IBGP peers. An RR is similar to a designated router (DR) on an OSPF network.

  • Client: an IBGP device of which routes are reflected by the RR to other IBGP devices. In an AS, clients only need to directly connect to the RR.

  • Non-client: an IBGP device that is neither an RR nor a client. In an AS, a non-client must establish full-mesh connections with the RR and all the other non-clients.

  • Originator: is a device that originates routes in an AS. The Originator_ID attribute helps eliminate routing loops in a cluster.

  • Cluster: is a set of the RR and clients. The Cluster_List attribute helps eliminate routing loops between clusters.

RR Principles

Clients in a cluster only need to exchange routing information with the RR in the same cluster. Therefore, clients only need to establish IBGP connections with the RR. This reduces the number of IBGP connections in the cluster. As shown in Figure 7-95, in AS 65000, Cluster1 is comprised of an RR and three clients. The number of IBGP connections in AS 65000 is then reduced from 10 to 4, which simplifies the device configuration and reduces the loads on the network and CPU.

The RR allows a BGP device to advertise the BGP routes learned from an IBGP peer to other IBGP peers, and uses the Cluster_List and Originator_ID attributes to eliminate routing loops. The RR advertises routes to IBGP peers based on the following rules:

  • The RR advertises the routes learned from a non-client to all the clients.

  • The RR advertises the routes learned from a client to all the other clients and all the non-clients.

  • The RR advertises the routes learned from an EBGP peer to all the clients and non-clients.

Cluster_List Attribute

An RR and its clients form a cluster, which is identified by a unique cluster ID in an AS. To prevent routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster IDs of all the clusters that a route passes through.

  • When a route is reflected by an RR for the first time, the RR adds the local cluster ID to the top of the cluster list. If there is no cluster list, the RR creates a Cluster_List attribute.

  • When receiving an updated route, the RR checks the cluster list of the route. If the cluster list contains the local cluster ID, the RR discards the route. If the cluster list does not contain the local cluster ID, the RR adds the local cluster ID to the cluster list and then reflects the route.

Originator_ID Attribute

The originator ID identifies the originator of a route and is generated by an RR to prevent routing loops in a cluster. Its value is the same as the router ID.

  • 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 identifies the originator of the route. If the route contains the Originator_ID attribute, the RR retains this Originator_ID attribute.

  • When a device receives a route, the device compares the originator ID of the route with the local router ID. If they are the same, the device discards the route.

Backup RR

To ensure network reliability and prevent single points of failures, redundant RRs are required in a cluster. An RR allows a BGP device to advertise the routes received from an IBGP peer to other IBGP peers. Therefore, routing loops may occur between RRs in the same cluster. To solve this problem, all the RRs in the cluster must use the same cluster ID.

Figure 7-96 Backup RR

As shown in Figure 7-96, RR1 and RR2 reside in the same cluster and have the same cluster ID configured.

  • When Client1 receives an updated route from an EBGP peer, Client1 advertises this route to RR1 and RR2 using IBGP.

  • After RR1 and RR2 receive this route, they add the local cluster ID to the top of the cluster list of the route and then reflect the route to other clients (Client2 and Client3) and to each other.

  • After RR1 and RR2 receive the reflected route from each other, they check the cluster list of the route, finding that the cluster list contains their local cluster IDs. RR1 and RR2 discard this route to prevent routing loops.

RRs of Multiple Clusters in an AS

There may be multiple clusters in an AS. RRs of the clusters establish IBGP peer relationships. When RRs reside at different network layers, an RR at the lower network layer can be configured as a client to implement hierarchical RR. When RRs reside at the same network layer, RRs of different clusters can establish full-mesh connections to implement flat RR.

Hierarchical RR

Figure 7-97 Hierarchical RR

In practice, hierarchical RR is often used. As shown in Figure 7-97, the ISP provides Internet routes to AS 100. AS 100 is divided into two clusters, Cluster1 and Cluster2. Four devices in Cluster1 are core routers and use a backup RR to ensure reliability.

Flat RR

Figure 7-98 Flat RR

As shown in Figure 7-98, the backbone network is divided into multiple clusters. RRs of the clusters are non-clients and establish full-mesh connections with each other. Although each client only establishes an IBGP connection with its RR, all the RRs and clients can receive all routing information.

BGP Confederation

In addition to a route reflector, the confederation is another method that reduces the number of IBGP connections in an AS. A confederation divides an AS into sub-ASs. Full-mesh IBGP connections are established in each sub-AS. EBGP connections are established between sub-ASs. ASs outside a confederation still consider the confederation as an AS. After a confederation divides an AS into sub-ASs, it assigns a confederation ID (the AS number) to each router within the AS. This brings two benefits. First, original IBGP attributes are retained, including the Local_Pref attribute, MED attribute, and Next_Hop attribute. Secondly, confederation-related attributes are automatically deleted when being advertised outside a confederation. Therefore, the administrator does not need to configure the rules for filtering information such as sub-AS numbers at the egress of a confederation.

Figure 7-99 Networking diagram of a confederation

As shown in Figure 7-99, AS 100 is divided into three sub-ASs after a confederation is configured: AS65001, AS65002, and AS65003. The AS number AS 100 is used as the confederation ID. The number of IBGP connections in AS 100 is then reduced from 10 to 4, which simplifies the device configuration and reduces the loads on the network and CPU. In addition, BGP devices outside AS 100 only know the existence of AS 100 but not the confederation within AS 100. Therefore, the confederation does not increase the CPU load.

Comparisons Between a Route Reflector and a Confederation

Table 7-51 compares a route reflector and a confederation in terms of the configuration, device connection, and applications.

Table 7-51 Comparisons between a route reflector and a confederation
Route Reflector Confederation
Retains the existing network topology and ensures compatibility. Requires the logical topology to be changed.
Requires only a route reflector to be configured because clients do not need to know that they are clients of a route reflector. Requires all devices to be reconfigured.
Requires full-mesh connections between clusters. Does not require full-mesh connections between sub-ASs of a confederation because the sub-ASs are special EBGP peers.
Applies to medium and large networks. Applies to large networks.

Route Summarization

The BGP routing table of each device on a large network is large. This burdens devices, increases the route flapping probability, and affects network stability.

Route summarization is a mechanism that combines multiple routes into one route. This mechanism allows a BGP device to advertise only the summarized route but not all the specific routes to peers, therefore reducing the size of the BGP routing table. If the summarized route flaps, the network is not affected, so network stability is improved.

BGP supports automatic summarization and manual summarization on IPv4 networks, and supports only manual summarization on IPv6 networks.

  • Automatic summarization: summarizes the routes imported by BGP. After automatic summarization is configured, BGP summarizes routes based on the natural network segment and advertises only the summarized route to peers. For example, BGP summarizes 10.1.1.1/24 and 10.2.1.1/24 (two Class A addresses with non-natural mask) into 10.0.0.0/8 (Class A address with natural mask).

  • Manual summarization: summarizes routes in the local BGP routing table. Manual summarization can help control the attributes of the summarized route and determine whether to advertise specific routes.

To prevent routing loops caused by route summarization, BGP uses the AS_Set attribute. The AS_Set attribute is an unordered set of all ASs that a route passes through. When the summarized route enters an AS in the AS_Set attribute again, BGP finds that the local AS number has been recorded in the AS_Set attribute of the route and discards this route to prevent a routing loop.

Route Dampening

When BGP is used on complex networks, route flapping occurs frequently. To prevent frequent route flapping, BGP uses route dampening to suppress unstable routes.

Route flapping is a process of adding a route to an IP routing table and then withdrawing this route. When route flapping occurs, a BGP device sends an Update message to its neighbors. The devices that receive the Update message need to recalculate routes and modify routing tables. Frequent route flapping consumes lots of bandwidths and CPU resources and even affects normal network operation.

Figure 7-100 Diagram of BGP route dampening

Route dampening measures the stability of a route using a penalty value. A larger penalty value indicates a less stable route. As shown in Figure 7-100, each time route flapping occurs, BGP increases the penalty of this route by a value of 1000. When the penalty value of a route exceeds the suppression threshold, BGP suppresses this route, and does not add it to the IP routing table or advertise any Update message to peers. After a route is suppressed for a period of time (half life), the penalty value is reduced by half. When the penalty value of a route decreases to the reuse threshold, the route is reusable and is added to the routing table. At the same time, BGP advertises an Update message to peers. The suppression time is the period from when a route is suppressed to when the route is reusable.

Route dampening applies only to EBGP routes but not IBGP routes. IBGP routes may include the routes of the local AS, and an IGP network requires that the routing tables of devices within an AS be the same. If IBGP routes were dampened, routing tables on devices are inconsistent when these devices have different dampening parameters. Therefore, route dampening does not apply to IBGP routes.

BFD for BGP

BGP periodically sends messages to peers to detect the status of the peers. It takes more than 1 second for this detection mechanism to detect a fault. When data is transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot meet high reliability requirements of networks. Bidirectional Forwarding Detection (BFD) provides the millisecond-level fault detection for BGP to improve network reliability.

Figure 7-101 Networking diagram of BFD for BGP

As shown in Figure 7-101, RouterA belongs to AS 100 and RouterB belongs to AS 200. RouterA and RouterB are directly connected and establish the EBGP peer relationship. Association between BGP and BFD is configured on RouterA and RouterB. When a fault occurs on the link between RouterA and RouterB, BFD can rapidly detect that the BFD session changes from Up to Down and notify this fault to RouterA and RouterB. RouterA and RouterB process the neighbor Down event and select routes again using BGP.

BGP Auto FRR

BGP Auto Fast Reroute (FRR) is a protection measure against link failures. It applies to the network topology with primary and backup links and provides sub-second-level switching between two BGP peers or two next hops.

After BGP Auto FRR is enabled on a device, the device selects the optimal route from the routes that carry the same prefix and are learned from multiple peers as the primary link to forward packets, and uses the second optimal route as the backup link. When the primary link becomes faulty, the system rapidly responds to the notification that the BGP route becomes unreachable, and then switches traffic from the primary link to the backup link. After BGP convergence is complete, BGP Auto FRR uses the optimal route selected by BGP to guide traffic forwarding. For details about Auto FRR, see "Auto FRR" in Feature Description - IP Routing.

Applications

As shown in Figure 7-102, RouterD advertises a learned BGP route to RouterB and RouterC in AS 100; RouterB and RouterC then advertise the BGP route to RouterA through a route reflector. RouterA receives two routes whose next hops are RouterB and RouterC respectively. Then RouterA selects a route according to the configured policy. Assume that the route sent from RouterB, namely LinkB, is preferred. The route sent from RouterC, namely LinkC, then functions as the backup link.

Figure 7-102 Networking diagram of BGP Auto FRR

When a router along LinkB fails or faults occur on LinkB, the next hop of the route from RouterA to RouterB becomes invalid. If BGP Auto FRR is enabled on RouterA, the forwarding plane quickly switches traffic sent from RouterA to RouterD to LinkC. This prevents traffic loss. In addition, RouterA reselects the route sent from RouterC and updates the FIB table.

BGP GR and NSR

BGP graceful restart (GR) and non-stop routing (NSR) are high availability solutions that minimize the impact of device failures on user services.

BGP GR

BGP GR ensures that the forwarding plane continues to guide data forwarding during a device restart or active/standby switchover. The operations on the control plane, such as reestablishing peer relationships and performing route calculation, do not affect the forwarding plane. This mechanism prevents service interruptions caused by route flapping and improves network reliability.

GR concepts are as follows:

  • GR restarter: is the device that is restarted by the administrator or triggered by failures to perform GR.

  • GR helper: is the neighbor that helps the GR restarter to perform GR.

  • GR time: is the time during which the GR helper retains forwarding information after detecting the restart or active/standby switchover of the GR restarter.

BGP GR process is as follows:
  1. Using the BGP capability negotiation mechanism, the GR restarter and helper know each other's GR capability and establish a GR session.

  2. When detecting the restart or active/standby switchover of the GR restarter, the GR helper does not delete the routing information and forwarding entries of the GR restarter or notify other neighbors of the restart or switchover, but waits to reestablish a BGP connection with the GR restarter.

  3. The GR restarter reestablishes neighbor relationships with all GR helpers before the GR time expires.

BGP NSR

NSR is a reliability technique that prevents neighbors from detecting the control plane switchover. It applies to the devices that have the active and standby switch modules configured. Compared to GR, NSR does not require the help of neighbors and does not need to deal with interoperability issues. For details about NSR, see "NSR" in the Feature Description - Reliability.

Comparisons Between Active/Standby Switchovers with and Without GR and NSR
Table 7-52 Comparisons between active/standby switchovers with and without GR and NSR
Active/Standby Switchover Without GR and NSR Active/Standby Switchover in GR Mode Active/Standby Switchover in NSR Mode
The BGP peer relationship is reestablished. The BGP peer relationship is reestablished. The BGP peer relationship is reestablished.
Routes are recalculated. Routes are recalculated. Routes are recalculated.
The forwarding table changes. The forwarding table remains unchanged. The forwarding table remains unchanged.
Traffic is lost during forwarding, and services are interrupted. No traffic is lost during forwarding, and services are not affected. No traffic is lost during forwarding, and services are not affected.
The network detects route changes, and route flapping occurs for a short period of time. Except the neighbors of the device where the active/standby switchover occurs, other routers do not detect route changes. The network does not detect route changes.
- The GR restarter requires neighbors to support the GR helper function. The GR helper function does not allow multiple neighbors to perform active/standby switchovers in GR mode simultaneously. Neighbors do not need to support the NSR function.

BGP ORF

RFC 5291 and RFC 5292 define the prefix-based BGP outbound route filtering (ORF) capability to advertise required BGP routes. BGP ORF allows a device to send prefix-based import policies in a Route-refresh message to BGP peers. BGP peers construct export policies based on these import policies to filter routes before sending these routes, which has the following advantages:
  • Prevents the local device from receiving a large number of unnecessary routes.
  • Reduces CPU usage of the local device.
  • Simplifies the configuration of BGP peers.
  • Improves link bandwidth efficiency.
Applications

BGP ORF applies to the scenario when a device wants BGP peers to send only required routes, and BGP peers do not want to maintain different export policies for different devices.

Figure 7-103 Inter-AS EBGP peers

As shown in Figure 7-103, after negotiating the prefix-based ORF capability with RouterB, RouterA adds the local prefix-based import policies to a Route-refresh message and sends the message to RouterB. RouterB constructs export policies based on the received Route-refresh message and sends required routes to RouterA using a Route-refresh message. RouterA receives only required routes, and RouterB does not need to maintain routing policies. This reduces the configuration workload.

Figure 7-104 Intra-AS route reflector

As shown in Figure 7-104, there is a route reflector (RR) in AS 100. RouterA and RouterB are the clients of the RR. RouterA, RouterB, and the RR negotiate the prefix-based ORF capability. RouterA and RouterB then add the local prefix-based import policies to Route-refresh messages and send the messages to the RR. The RR constructs export policies based on the received import policies and reflects required routes in Route-refresh messages to RouterA and RouterB. RouterA and RouterB receive only required routes, and the RR does not need to maintain routing policies. This reduces the configuration workload.

Dynamic Update Peer-Groups

Currently, the rapid growth in the size of the routing table and the complexity of the network topology require BGP to support more peers. Especially in the case of a large number of peers and routes, high-performance grouping and forwarding are required when a router needs to send routes to a large number of BGP peers, most of which share the same outbound policies.

The dynamic update peer-groups feature treats all the BGP peers with the same outbound policies as an update-group. In this case, routes are grouped uniformly and then sent separately. That is, each route to be sent is grouped once and then sent to all peers in the update-group, improving grouping efficiency exponentially. For example, a route reflector (RR) has 100 clients and needs to reflect 100,000 routes to these clients. If the RR sends the routes grouped per peer to 100 clients, the total number of times that all routes are grouped is 10,000,000 (100,000 x 100). After the dynamic update peer-groups feature is used, the total number of grouping times changes to 100,000 (100,000 x 1), improving grouping performance by a factor of 100.

Applications

BGP uses the dynamic update peer-groups technology when a large number of peers and routes exist and most peers share the same outbound policies, improving BGP route grouping and forwarding performance. The dynamic update peer-groups feature applies to the following scenarios:

  • International gateway

    As shown in Figure 7-105, the Internet gateway (IGW) router sends routes to all neighboring ASs. If the IGW router supports the dynamic update peer-groups feature, its BGP route forwarding performance will be greatly improved.

    Figure 7-105 Networking diagram of the international gateway

  • RR

    As shown in Figure 7-106, RRs send routes to all clients. If the RRs support the dynamic update peer-groups feature, their BGP route forwarding performance will be greatly improved.

    Figure 7-106 Networking diagram of RRs

  • ASBR

    As shown in Figure 7-107, RouterB, as an Autonomous System Boundary Router (ASBR), sends all the routes received from an EBGP neighbor RouterA to all IBGP neighbors. If RouterB supports the dynamic update peer-groups feature, its BGP route forwarding performance will be greatly improved.

    Figure 7-107 Networking diagram of a PE connecting to multiple IBGP neighbors

MP-BGP

Traditional BGP-4 manages only IPv4 routing information. Inter-AS transmission of other network layer protocol packets (such as IPv6 and multicast packets) is limited. To support multiple network layer protocols, Multiprotocol BGP (MP-BGP) is designed in RFC 4760 as an extension to BGP-4. MP-BGP uses extended attributes and address families to support IPv6, multicast, and VPN, without changing the existing BGP packet forwarding and routing mechanism.

MP-BGP is called BGP4+ on IPv6 unicast networks or called multicast BGP (MBGP) on IPv4 multicast networks. MP-BGP establishes separate topologies for IPv6 unicast networks and IPv4 multicast networks, and stores IPv6 unicast and IPv4 multicast routing information in different routing tables. This ensures that routing information of IPv6 unicast networks and IPv4 multicast networks is separated from each other, and allows routes of different networks to be maintained using different routing policies.

Extended Attributes

In BGP, an Update message carries three IPv4-related attributes: NLRI, Next_Hop, and Aggregator.

To support multiple network layer protocols, BGP requires NLRI and Next_Hop attributes to carry information about network layer protocols. Therefore, MP-BGP uses the following new optional non-transitive attributes:

  • MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise reachable routes and next hop information.

  • MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to withdraw unreachable routes.

Address Families
MP-BGP uses address families to differentiate network layer protocols. Currently, devices support the following address family views:
  • BGP-IPv4 unicast address family view
  • BGP-IPv4 multicast address family view
  • BGP-VPN instance IPv4 address family view
  • BGP-IPv6 unicast address family view
  • BGP-VPN instance IPv6 address family view
Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59727

Downloads: 3623

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