huawei routing & switching elite training – bgp basics

www.huawei.com

HUAWEI TECHNOLOGIES CO., LTD.

Huawei Routing & Switching Elite Training – BGP Basics

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential 2

Foreword

I. BGP is short for Border Gateway Protocol.

II. BGP is an enhanced path-vector routing protocol and an Exterior

Gateway Protocol (EGP) that has a variety of policy control

technologies.

III. BGP is an inter-Autonomous System (AS) routing protocol.

2


Objectives

Understand BGP principles.

Master BGP configuration commands.

Improve BGP troubleshooting capabilities.

Enhance BGP comprehensive capabilities.

Strengthen BGP exam skills.


BGP Principles

BGP Configuration Commands

BGP Troubleshooting

BGP Case Analysis

BGP Exam Preparation

ContentsPrinciples Commands CasesTroubleshooting Suggestions


BGP Principles

BGP Principles

BGP Overview

BGP Concepts

BGP Working Principles

Interaction Between BGP and IGPs

BGP Route Attributes

BGP Routing Rules

BGP Load Balancing

BGP Extensions


BGP Troubleshooting

BGP Case Analysis


Principles Commands CasesTroubleshooting Suggestions


BGP Overview

BGP Overview

An EGP.

Uses TCP as the transport layer protocol.

Supports Classless Inter-Domain Routing (CIDR).

Supports incremental updates.

A path-vector routing protocol.

Eliminates routing loops.

Has rich routing policies.

Prevents route flapping.

Easy to extend.


BGP is a dynamic routing protocol used between ASs. BGP-1 (defined in RFC 1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267) are three earlier-released BGP versions. BGP exchanges reachable inter-AS routes, establishes inter-AS paths, avoids routing loops, and applies routing policies between ASs. The current BGP version is BGP-4 defined in RFC 4271.

As an external routing protocol on the Internet, BGP is widely used among Internet Service Providers (ISPs).BGP has the following characteristics:

BGP is an EGP. Different from Interior Gateway Protocols (IGPs) such as Open Shortest Path First (OSPF) and Routing Information Protocol (RIP), BGP controls route advertisement and selects optimal routes between ASs rather than discover or calculate routes.

BGP uses the Transport Control Protocol (TCP) with listening port 179 as the transport layer protocol. TCP enhances BGP reliability with requiring a dedicated mechanism to ensure connectivity.

• BGP needs to select inter-AS routes, which requires high protocol stability. TCP with high reliability therefore is used to enhance BGP stability.

• BGP peers must be logically connected and establish TCP connections. The destination port number is 179, and the local port number is random.

When routes are updated, BGP transmits only the updated routes. This greatly reduces the bandwidth occupied by BGP route advertisements. Therefore, BGP applies to the transmission of a large number of routes on the Internet.

BGP is designed to avoid loops.• Inter-AS: BGP routes carry information about the ASs along the path.

The routes that carry the local AS number are discarded to avoid inter-AS loops.

• Intra-AS: BGP does not advertise the routes learned in an AS to BGP peers in the AS. In this manner, intra-AS loops are avoided.

BGP provides rich routing policies to flexibly filter and select routes. BGP provides a route flapping prevention mechanism, which effectively

improves Internet stability. BGP is easy to extend and adapts to network development. It is mainly

extended using TLVs.


BGP Concepts – AS

R1

R2

R3

AS 200

AS 100

R4

AS

An AS is a group of routers that are managed by a single technical

administration and use the same routing policy.

BGP

RIPIS-ISOSPF


An AS is a group of routers that are managed by a single technical administration and use the same routing policy.

An AS is a group of routers that are managed by a single technical administration and use the same routing policy.

Each AS has a unique AS number, which is assigned by the Internet Assigned Numbers Authority (IANA).

An AS number ranges from 1 to 65535. Values 1 to 64511 are registered Internet numbers, while values 64512 to 65535 are private AS numbers.

Each AS on a BGP network is assigned a unique AS number to identify the AS. Currently, 2-byte AS and 4-byte AS numbers are available. A 2-byte AS number ranges from 1 to 65535, while 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 Concepts – EBGP and IBGP

R2 R3

R1 R4

AS 100

AS 200 AS 300

IBGPEBGP EBGP

External BGP (EBGP) and internal BGP (IBGP)

When BGP runs within an AS, BGP is called IBGP.

When BGP runs between ASs, BGP is called EBGP.


EBGP and IBGP 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 other IBGP peers, and establishes full-mesh connections with all the IBGP peers.

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

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 Working Principles – Message Types

Open message

Negotiate BGP parameters.

Update message

Exchange routes.

Keepalive message

Maintain BGP neighbor relationships

Notification message

Notify of errors.

Route-Refresh message

Request the BGP peer resend routes after routing policies are changed.


BGP Message

Format

BGP peers exchange five types of messages: Open, Update, Keepalive, Notification, and Route-Refresh messages. Open message: is used to establish BGP peer relationships. It is the first message sent after a TCP connection is set up. After a BGP peer receives an Open message and the peer

negotiation succeeds, the BGP peer sends a Keepalive message to confirm and maintain the peer relationship. Subsequently, BGP peers can exchange Update, Notification, Keepalive, and Route-refresh messages.

Update message: is used to exchange routes between BGP peers. Update messages can be used to advertise multiple reachable routes with the same attributes or to withdraw multiple unreachable routes.

• An Update message can be used to advertise multiple reachable routes with the same attributes. These routes can share a group of route attributes. The route attributes in an Update message apply to all the destination addresses (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 (expressed by an IP prefix), which identifies the routes previously advertised between BGP speakers.

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

Keepalive message: is periodically sent to the BGP peer to maintain the peer relationship. Notification message: is sent to the BGP peer when an error is detected. The BGP connection is then terminated immediately. Route-Refresh message: is used to request the BGP peer resend routes when the BGP inbound routing policy changes. If all BGP routers have the Route-Refresh capability, the local BGP

router sends a Route-Refresh message to BGP peers when the BGP inbound routing policy changes. After receiving the Route-Refresh message, the BGP peers resend their routing information to the local BGP router. In this manner, the BGP routing table can be dynamically updated, and the new routing policy can be used without terminating BGP connections. A BGP peer notifies its peer of its Route-Refresh capability by sending an Open message.

BGP message applications BGP uses TCP port 179 to set up a connection. BGP connection setup requires a series of dialogues and handshakes. TCP advertises parameters such as the BGP version, BGP connection

holdtime, local router ID, and authorization information in an Open message during handshake negotiation. After a BGP connection is set up, a BGP router sends the BGP peer an Update message that carries the attributes of a route to be advertised. This helps the BGP peer select the optimal

route. When local BGP routes change, a BGP router sends an Update message to notify the BGP peer of the changes. After two BGP peers exchange routes for a period of time, they do not have new routes to be advertised and need to periodically send Keepalive messages to maintain the validity of the BGP

connection. If the local BGP router does not receive any BGP message from the BGP peer within the holdtime, the local BGP router considers that the BGP connection has been terminated, tears down the BGP connection, and deletes all the BGP routes learned from the peer.

When the local BGP router detects an error during the operation, for example, it does not support the peer BGP version or receives an invalid Update message, it sends the BGP peer a Notification message to report the error. Before terminating a BGP connection with the peer, the local BGP router also needs to send a Notification message to the peer.

BGP message header Marker: A 16-byte field fixed to a value of 1. Length: A 2-byte unsigned integer that indicates the total length of a message, including the header. Type: A 1-byte field that specifies the type of a message:

• Open• Update• Keepalive• Notification• Route-Refresh

Open message format Version: Indicates the BGP version number. For BGPv4, the value is 4. My Autonomous System: Indicates the local AS number. Comparing the AS numbers on both ends, you can determine whether a BGP connection is an IBGP or EBGP connection. Hold Time: Indicates the time during which two BGP peers maintain a BGP connection between them. During the peer relationship setup, two BGP peers need to negotiate the holdtime and

keep the holdtime consistent. If two BGP peers have different holdtime periods configured, the shorter holdtime is used. If the local BGP router does not receive a Keepalive message from the peer within the holdtime, it considers that the BGP connection is terminated. If the holdtime is 0, no Keepalive message is sent.

BGP Identifier: Indicates the router ID of a BGP router. It is expressed as an IP address to identify a BGP router. Opt Parm Len (Optional Parameters Length): Indicates the optional parameter length. The value 0 indicates that no optional parameters are available. Optional Parameters: These are used for BGP authentication or Multiprotocol Extensions. Each parameter is a 3-tuple (Parameter Type-Parameter Length-Parameter Value).

Update message format Withdrawn Routes Length: A 2-byte unsigned integer that indicates the total length of the Withdrawn Routes field. The value 0 indicates that the Withdrawn Routes field is not present in this

Update message. Withdrawn Routes: A variable-length field that contains a list of IP address prefixes for the routes to be withdrawn. Each IP address prefix is in <length, prefix> format. For example,

<19,198.18.160.0> indicates a network at 198.18.160.0 255.255.224.0. Path Attribute Length: A 2-byte unsigned integer that indicates the total length of the Path Attribute field. The value 0 indicates that the Path Attribute field is not present in an Update message. Network Layer Reachability Information: Contains a list of IP address prefixes. This variable length field is in the same format as the Withdrawn Routes: <length, prefix>.

Keepalive message format A Keepalive message has only the message header. By default, the interval for sending Keepalive messages is 60 seconds, and the holdtime is 180 seconds. Each time a BGP router receives a Keepalive message from its peer, it resets the

hold timer. If the hold timer expires, it considers the peer to be 'down'.

Notification message format Errorcode: A 1-byte field that uniquely identifies an error. Each error code may have one or more error subcodes. If no error subcode is defined for an error code, the Error Subcode Field is all

0s. Errsubcode: Indicates an error subcode.


BGP Working Principles – Finite State Machine

Idle

Connect

OpenSent

OpenConfirm

Active

Established

Start

TCP Established

Receive Correct Open

Receive Correct Keepalive

Error

Error

Error

Connect Retry Timeout

TCP Failed

TCP Established

Error


A BGP finite state machine (FSM) has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. The Idle state is the initial BGP state. In Idle state, a BGP device refuses all the 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.

• A start event occurs when an operator configures a BGP process, resets an existing BGP process or when the router software resets a BGP process.

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

In the connect state, the BGP device starts the ConnectRetry timer and waits to establish a TCP connection. The ConnectRetry timer defaults to 32 seconds.

• If a TCP connection is established, the BGP device sends an open message to the peer and changes to the OpenSent state.

• If a 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 ConnectRetry

timer expires, the BGP device attempts to establish a TCP connection with another peer and stays in the connect state.

• If another event (started by the system or operator) occurs, the BGP device returns to the Idle state.

In the Active state, the BGP device keeps trying to establish a TCP connection with the peer.• If a TCP connection is established, the BGP device sends an open message to the peer,

closes the ConnectRetry timer, and changes to the OpenSent state.• If a 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 ConnectRetry

timer expires, the BGP device returns to the connect state. In the OpenSent state, the BGP device waits for 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.

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.

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


BGP Working Principles – Route Exchange Rules Between BGP Peers

A BGP device exchanges routes with the peer according to the following

rules:

Advertises IBGP routes only to its EBGP peers.

Advertises EBGP routes to all its EBGP peers and IBGP peers.

Advertises only optimal routes to its peers.

Sends only updated BGP routes.


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


BGP Working Principles – Database

IP routing table (IP-RIB)

Global routing information base, including all the IP routes

BGP routing table (Loc-RIB)

BGP routing information base, including the routes selected by the local

BGP speaker

Neighbor table

List of BGP peers

Adj-RIB-In

Unprocessed routing information base advertised by the peer to the local

BGP speaker

Adj-RIB-Out

Routing information base advertised by the local BGP speaker to the

specified peer



BGP Working Principles – BGP Route Information Processing

Route selection

Update information from the peer

Update information sent to the peer

(1)

(2)(3)

(4)(5)

Adj-RIB-In

Inbound policy engine

Loc-RIB

IP-RIBOutbound policy engine

Adj-RIB-Out


BGP routing information processing When receiving Update messages from peers, a BGP router

saves the Update messages to the routing information base (RIB) and specifies the Adj-RIB-In of the peer from which the Update messages are received. After these Update messages are filtered by the inbound policy engine, the BGP router determines the optimal route for each prefix according to the route selection algorithm.

The optimal routes are saved in the local BGP RIB (Loc-RIB) and then submitted to the local IP route selection table (IP-RIB).

In addition to the optimal routes received from peers, Loc-RIB also contains the BGP prefixes that are selected as the optimal routes and injected by the current router (locally originated routes). Before the routes in Loc-RIB are advertised to other peers, these routes must be filtered by the outbound policy engine. Only the routes that pass the filtering of the outbound policy engine can be installed to the RIB (Adj-RIB-Out).


Interaction Between BGP and IGPs –BGP Synchronization

BGP synchronization

Before a BGP router adds IBGP routes to IGP routing tables and

advertises the routes to EBGP peers, it checks the IGP routing tables. It

adds IBGP routes to the IGP routing tables and advertises the routes to

EBGP peers only when the IGP routing tables contain the IBGP routes.

R1

R2 R4

EBGPIBGP

IGP

R3

R5

EBGP

IGP

AS 100

AS 200

AS 300

10.0.0.0/24


Synchronization is performed between IBGP and IGP to prevent misleading routers in other ASs.

Topology description (when synchronization is enabled) R4 learns the route to 10.0.0.0/24 advertised by R1 through

BGP and checks whether local IGP routing tables contain the route. If so, R4 advertises the route to R5. If not, R4 does not advertise the route to R5.

Precautions: By default synchronization is disabled on VRP platform, and it can not be changed. Only under two conditions,we can disable the synchronization:

The local AS is not a transit AS. All the routers within the local AS set up full-mesh IBGP

connections.


BGP Route AttributesBGP route attributes are a set of parameters that further describe BGP routes.

Well-known mandatory

• This type of attribute can be identified by all the BGP routers and must be

carried in Update messages.

• Without this type of attribute, errors occur in route information.

Well-known discretionary

• This type of attribute can be identified by all the BGP routers and is not

necessarily carried in Update messages.

• Errors do not occur in routing information even if this type of attribute is not

available.

Optional transitive

• This type of attribute is a transitive attribute between BGP Speaks.

• A BGP router may not recognize this type of attribute, but it still accepts these

attributes and advertises them to other peers.

Optional non-transitive

• If a BGP router does not recognize this type of attribute, it ignores these

attributes and does not advertise them to other peers.


BGP route attributes are a set of parameters that further describe BGP routes. Using BGP route attributes, BGP can filter and select routes.

Common attributes are as follows: Origin: A well-known mandatory attribute. AS_Path: A well-known mandatory attribute. Next_Hop: A well-known mandatory attribute. Local_Pref: A well-known discretionary attribute. Community: An optional transitive attribute. MED: An optional non-transitive attribute. Originator_ID: An optional non-transitive attribute. Cluster_List: An optional non-transitive attribute.


BGP Route Attributes – Origin

The Origin attribute defines the origin of a route and is a well-known

mandatory attribute. The Origin attribute is classified into three types:

IGP

• A route with the Origin attribute IGP is obtained through an IGP.

• The Origin attribute of an IGP route is labeled as i.

EGP

• A route with the Origin attribute EGP is obtained through EGP.

• The Origin attribute of an EGP route is labeled as e.

Incomplete

• A route with the Origin attribute Incomplete is learned by other means.

• The Origin attribute of a route learned by other means is labeled as ?.


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

IGP: A route with the Origin attribute IGP is an IGP route and has the highest priority. For example, the Origin attribute of the routes injected to the BGP routing table using the networkcommand is IGP.

EGP: A route with the Origin attribute EGP is an EGP route and has the secondary highest priority.

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


BGP Route Attributes – AS_PathThe AS_Path attribute records all the ASs that a route passes

through from a source to a destination in the distance-vector order.

This attribute is a well-known mandatory attribute.


R1

R2 R3

R4R5

IBGP

EBGP

EBGP

EBGP

10.0.0.0/24

AS 100

AS 300

AS 400 AS_Path（300）NLRI 10.0.0.0/24

AS_Path（400,300）NLRI 10.0.0.0/24

AS_Path（300）NLRI 10.0.0.0/24

AS_Path（300）NLRI 10.0.0.0/24

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

When advertising the route to other ASs, the BGP speaker adds the local AS number to the AS_Path list, and then advertises it to neighboring routers in Update messages.

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

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

When advertising the route to other ASs, the BGP speaker adds the local AS number to the leftmost of the AS_Path list. According to the AS_Path attribute, the BGP router that receives the route can determine the ASs through which the route has passed to the destination. The number of the AS that is nearest to the local AS is placed on the leftmost of the list, and the other AS numbers are listed according to the sequence in which the route passes through ASs.

When advertising the route to the local AS, the BGP speaker does not change the AS_Path attribute of the route.

Topology description When R4 advertises route 10.0.0.0/24 to AS 400 and AS 100, it adds

the local AS number to the AS_Path list. When R5 advertises the route to AS 100, it also adds the local AS number to the AS_Path list. When R1 and R3 in AS 100 advertise the route to R2 in the same AS, they keep the AS_Path attribute of the route unchanged. R2 selects the route with the shortest AS_Path when other BGP routing rules are the same. That is, R2 reaches 10.0.0.0/24 through R3.


BGP Route Attributes – Next_HopThe Next_Hop attribute records the next hop that a route passes

through. It is a well-known mandatory attribute.

R2R112.1.1..0/24

AS 100R3

.1 .210.0.0.0/24

IBGP

EBGPAS 200

Next_Hop 12.1.1.1 NLRI 10.0.0.0/24

23.1.1..0/24.1 .2

R2R112.1.1..0/24

AS 100R3

.1 .210.0.0.0/24

EBGP

IBGPAS 200

Next_Hop 23.1.1.1 NLRI 10.0.0.0/24

23.1.1..0/24.1 .2

R2R112.1.1..0/24

AS 100

R3.1 .2

10.0.0.0/24IBGP

23.1.1..0/24.1 .2

Next_Hop 12.1.1.1NLRI 10.0.0.0/24

IBGP


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 locally originated route to an IBGP peer, the BGP speaker sets the Next_Hop attribute of the route to be the IP address of the local interface through which the BGP peer relationship is established.

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

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


BGP Route Attributes – Local_PrefThe Local_Pref attribute indicates the BGP preference of a router and

helps determine the optimal route when traffic leaves an AS. This

attribute is a well-known discretionary attribute.

R2

R3

R1

R4

R5

R6

10.0.0.0/24

AS 100

AS 200

AS 300

AS 400

Local_Pref 300 NLRI 10.0.0.0/24

Local_Pref 200 NLRI 10.0.0.0/24


Local_Pref attribute This attribute indicates the BGP preference of a router. It is

exchanged only between IBGP peers and not advertised to other ASs.

This attribute helps determine the optimal route when traffic leaves an AS. When a BGP router obtains multiple routes to the same destination address but with different next hops from IBGP peers, the router prefers the route with the highest Local_Pref.

Topology descriptionR1,R2,R3 are IBGP Peers of each other in AS 100, R2 establish EBGP Peer with AS 200 and R3 establish EBGP Peer with AS 300. So R2 and R3 will learn route 10.0.0.0/24 from EBGP, R1 learns two routes to 10.0.0.0/24 from two IBGP peers (R2 and R3) in the local AS. Prefers R2 routing 10.0.0.0/24 to other ASs in AS100, it need configure the Local_Pref with R2 and R3: one with Local_Pref value 300 from R2 and the other with Local_Pref value 200 from R3. R1 prefers the route learned from R2.


BGP Route Attributes – MED

The Multi-Exit-Discriminator (MED) attribute helps determine the optimal

route when traffic enters an AS. It functions as the IGP metric and

affects the optimal route of traffic from neighboring ASs to the local AS.

This attribute is an optional non-transitive attribute.

R1

R2

R3

R4

10.0.0.0/24

AS 100

AS 200

MED 200 NLRI 10.0.0.0/24

MED 300 NLRI 10.0.0.0/24


The MED attribute helps determine the optimal route when traffic enters an AS. When a BGP router obtains multiple routes to the same destination address but with different next hops from EBGP peers, the router selects the route with the smallest MED value as the optimal route if the other attributes of the routes are the same.

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

Topology description R1 and R2 advertise routes 10.0.0.0/24 to their respective

EBGP peers R3 and R4. When other routing rules are the same, R3 and R4 prefer the route with a smaller MED value. That is, R3 and R4 access network 10.0.0.0/24 through R1.


BGP Route Attributes – Community

The Community attribute identifies the BGP routes with the same

characteristics. This attribute is an optional transitive attribute.

The Community attribute includes the following types of attributes:

Self-defined community attributes

Well-known community attributes

• Internet

• No_Advertise

• No_Export

• No_Export_Subconfed

R3

R1

R2

AS 200

AS 100

10.0.0.0/24

R4

AS 300

172.16.0.0/24

No_AdvertiseNLRI 10.0.0.0/24

No_ExportNLRI 172.16.0.0/24

No_ExportNLRI 172.16.0.0/24

No ExportNLRI 172.16.0.0/24

No_AdvertiseNLRI 10.0.0.0/24


The Community attribute is a set of destination addresses with the same characteristics. It is expressed as a 4-byte list and in the aa:nn or community number format.

aa:nn: The value of aa or nn ranges from 0 to 65535. The administrator can set a specific value as required. Generally, aa indicates the AS number and nn indicates the community identifier defined by the administrator. For example, if a route is from AS 100 and its community identifier defined by the administrator is 1, the Community attribute is 100:1.

Community number: An integer that ranges from 0 to 4294967295. As defined in RFC 1997, numbers from 0 (0x00000000) to 65535 (0x0000FFFF) and from 4294901760 (0xFFFF0000) to 4294967295 (0xFFFFFFFF) are reserved.

The Community attribute helps simplify application, maintenance, and management of routing policies. With the community, a group of BGP routers in multiple ASs can share the same routing policy. This attribute is a route attribute and is transmitted between BGP peers without being restricted by ASs. Before advertising a route with the Community attribute to peers, a BGP router can change the original Community attribute of this route.

Well-known community attributes Internet: All routes belong to the Internet community by default. A route

with this attribute can be advertised to all BGP peers. No_Advertise: A device does not advertise a received route with the

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

No_Export attribute to devices outside the local AS. If a confederation is defined, the route with the No_Export attribute cannot be advertised to ASs outside of the confederation but to other sub-ASs in the confederation.

No_Export_Subconfed: 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 in a confederation.


BGP Routing RulesWhen there are multiple routes to the same destination, BGP compares the

following attributes in sequence to select the optimal route:

If the next hop of a route is unreachable, BGP ignores the route.

Prefers the route with the largest PrefVal value.

Prefers the route with the highest Local_Pref.

Prefers the locally generated route.

Prefers the route with the shortest AS_Path.

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

lower than Incomplete.

Prefers the route with the lowest MED.

Prefers EBGP routes (the preference of an EBGP route is higher than that of an

IBGP route).

Prefers the route with the lowest IGP metric

Prefers the route with the shortest Cluster_List.

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

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


BGP routing rules The next-hop addresses of routes must be reachable. The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it is

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

value 100. You can use the default local-preference command to change the default local preference of BGP routes.

Locally generated routes include the routes imported using the network or import-route command, manually summarized routes, and automatically summarized routes.

• Summarized routes have a higher priority than non-summarized routes.• Manually summarized routes generated using the aggregate command have a higher

priority than automatically summarized routes generated using the summary automatic command.

• Routes imported using the network command have a higher priority than routes imported using the import-route command.

Prefers the route with the shortest AS_Path.• The AS_Path length does not include AS_CONFED_SEQUENCE and

AS_CONFED_SET.• An AS_SET counts as 1 no matter how many AS numbers the AS_SET contains.• BGP does not compare the AS_Path attributes of routes after the bestroute as-path-

ignore command is executed. Prefers the route with the lowest MED.

• BGP compares only the MED values of routes sent from the same AS (excluding a confederation sub-AS). That is, BGP compares the MED values of two routes only when the first AS numbers in the AS_SEQUENCE attributes (excluding the AS_CONFED_SEQUENCE) of the two routes are the same.

• If a route does not have the MED attribute, BGP considers the MED value of the route as the default value 0. After the bestroute med-none-as-maximum command is executed, BGP considers the MED value of the route as the maximum value 4294967295.

• After the compare-different-as-med command is executed, BGP compares the MEDs in the routes sent from peers in different ASs. Do not use this command unless different ASs use the same IGP and route selection mode, otherwise routing loops may occur.

• After the bestroute med-confederation command is executed, BGP compares the MED values of routes only when the AS_Path does not contain external AS numbers (sub-ASs that do not belong to a confederation) and the first AS number in AS_CONFED_SEQUENCE is the same.

• After the deterministic-med command is executed, routes are not selected in the sequence in which routes are received.

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 rules before the

attibutes "Prefers the route with the lowest IGP metric“ are the same.


BGP Extended Feature – Security

BGP security

Message Digest 5 (MD5) authentication

Generalized TTL Security Mechanism (GTSM)

Limiting the number of routes received from peers

Limiting the AS_Path length


BGP security MD5: BGP uses TCP as the transport layer protocol. To ensure

BGP security, you can perform MD5 authentication during the TCP connection setup. MD5 authentication, however, does not authenticate BGP messages. Instead, it sets the MD5 authentication password for a TCP connection, and the authentication is performed by TCP. If the authentication fails, no TCP connection is set up.

After GTSM is enabled for BGP, an interface board checks the TTL values in all BGP messages. In actual networking, packets whose TTL values are not within the specified range are either allowed to pass through or discarded by GTSM. To configure GTSM to discard packets by default, you can set a correct TTL value range according the network topology. Subsequently, messages whose TTL values are not within the specified range are discarded. This function avoids attacks from bogus BGP messages. This function is mutually exclusive to multi-hop EBGP.

The number of routes received from peers is limited to prevent resource exhaustion attacks.

The AS_Path lengths on the inbound and outbound interfaces are limited. Packets that exceed the limit of the AS_Path lengthare discarded.


BGP Extended Feature – Route Dampening

Route dampening helps solve the problem of route instability.

Half life Time

Penalty value

Suppression threshold

Reuse threshold


Route dampening helps solve the problem of route instability. In most cases, BGP is used on complex networks where route flapping occurs frequently. To prevent frequent route flapping, BGP uses route dampening to suppress unstable routes.

Route dampening measures the stability of a route using a penalty value. A larger penalty value indicates a less stable route. Each time route flapping occurs, BGP increases the penalty of a route by a value of 1000. During route flapping, a route changes from active to inactive. When the penalty value of the 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 BGP 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 becomes reusable and is added to the routing table. At the same time, BGP advertises an Update message to peers. The penalty value, suppression threshold, and half life can be manually configured.

Route dampening applies only to EBGP routes but not IBGP routes. IBGP routes often include the routes from the local AS, which requires that the forwarding tables of devices within an AS be the same. In addition, IGP fast convergence aims to achieve information synchronization. If IBGP routes were dampened, forwarding tables on devices would be inconsistent when these devices have different dampening parameters. Route dampening therefore does not apply to IBGP routes.



BGP Principles


Configuring Basic BGP Functions

Configuring the BGP Local_Pref Attribute

Configuring the BGP MED Attribute

Configuring the BGP Community Attribute

Configuring the BGP AS_Path Attribute

Configuring BGP Load Balancing

Optimizing a BGP Network

BGP Troubleshooting

BGP Case Analysis


Commands CasesTroubleshooting SuggestionsPrinciples


Configuring Basic BGP Functions (1)Assume that you are the network administrator of Company A. The following

figure shows the network of Company A. Company A has the following

requirements:

Establish stable IBGP peer relationships between R1 and R2, between R1 and R3,

and between R6 and R7. Configure static routes in AS 100 and AS 400(not contain

net segment of 10)

Advertise 10.0.X.0/24 to BGP.

Establish peer relationships between all EBGP neighbors.


bgp.topo

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

10.0.2.0/24

AS 100AS 200

AS 300AS 400

AS 500

Loopback 02.2.2.2

Loopback 03.3.3.3

Loopback 01.1.1.1

Loopback 06.6.6.6

Loopback 07.7.7.7

Case description IP addresses used to interconnect devices are designed as

follows:• If RTX connects to RTY, interconnected addresses are

XY.1.1.X and XY.1.1.Y.Network mask is 24.• Loopback interface addresses of R1, R2, R3, R6, and

R7 are shown in the figure.

Case analysis To establish stable IBGP peer relationships, use loopback

interface addresses and static routes within an AS. To establish EBGP peer relationships, use physical interface

addresses.


Configuring Basic BGP Functions (2)Commands CasesTroubleshooting SuggestionsPrinciples

R1

R2

R3

R4

R5

R6

R7R8

10.0.1.0/2410.0.0.0/24

10.0.2.0/24

AS 100AS 200

AS 300AS 400

AS 500bgp 100peer 1.1.1.1 as-number 100 peer 1.1.1.1 connect-interface LoopBack0peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack0peer 24.1.1.4 as-number 200peer 1.1.1.1 next-hop-local#ospf 1 area 0.0.0.0 network 2.2.2.2 0.0.0.0 network 12.1.1.0 0.0.0.255 network 23.1.1.0 0.0.0.255

bgp 400peer 7.7.7.7 as-number 400 peer 7.7.7.7 connect-interface LoopBack0peer 46.1.1.4 as-number 200 peer 68.1.1.8 as-number 500peer 7.7.7.7 next-hop-localospf 1 area 0.0.0.0 network 6.6.6.6 0.0.0.0 network 67.1.1.0 0.0.0.255 network 76.1.1.0 0.0.0.255

[R3]display bgp peer BGP local router ID : 34.1.1.3Local AS number : 100Total number of peers : 3 Peers in established state : 3Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv1.1.1.1 4 100 55 59 0 00:52:13 Established 12.2.2.2 4 100 38 39 0 00:34:54 Established 234.1.1.4 4 200 56 54 0 00:50:22 Established 2

bgp27.rar

Command usage The peer as-number command sets the AS number of a specified peer (or

peer group). The peer connect-interface command specifies a source interface that sends

BGP messages and a source address used to initiate a connection. The peer next-hop-local command configures a BGP device to set its IP

address as the next hop of routes when it advertises the routes to an IBGP peer or peer group.

View BGP process view

Parameters peer ipv4-address as-number as-number

ip-address: specifies the IPv4 address of a peer.as-number: specifies the AS number of the peer.

peer ipv4-address connect-interface interface-type interface-number [ ipv4-source-address ]

ip-address: specifies the IPv4 address of a peer.interface-type interface-number: specifies the interface type and number.ipv4-source-address: specifies the IPv4 source address used to set up a connection.

peer ipv4-address next-hop-localip-address: specifies the IPv4 address of a peer.

Precautions When using a loopback interface to send BGP messages:

• Ensure that the loopback interface address of the BGP peer is reachable.

• In the case of an EBGP connection, you need to run the peer ebgp-max-hop command to enable EBGP to establish the peer relationship in indirect mode.

The peer next-hop-local and peer next-hop-invariable commands are mutually exclusive.

The PrefRcv field in the display bgp peer command output indicates the number of route prefixes received from the peer.


Configuring the BGP Local_Pref Attribute (1)To improve link usage efficiency, Company A needs to adjust the

network:

Ensure that R1 reaches network 10.0.2.0/24 through R3, and perform

the configuration on R2.

[R1]display ip routing-table Destination/Mask Proto Pre Cost Flags NextHop Interface

10.0.1.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/010.0.2.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0

…..//The following information is omitted.


R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24 10.0.2.0/24

AS 100

AS 200

AS 300AS 400

AS 500

Case description The topology in this case is the same as that in the previous

case. Perform the configuration based on the configuration in the previous case.

R1 prefers routes to 10.0.X.0/24 with next hop R2 because BGP prefers the route advertised by the router with the smallest router ID.


Configuring the BGP Local_Pref Attribute (2)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24 10.0.2.0/24

AS 100

AS 200

AS 300AS 400

AS 500

Do faults occur on the network?


bgpp29.rar

bgp 100peer 24.1.1.4 route-policy 10 import#route-policy 10 permit node 10if-match ip-prefix 10apply local-preference 50route-policy 10 permit node 20ip ip-prefix 10 index 10 permit 10.0.2.0 24

[R1]display bgp routing-table Network NextHop MED LocPrf PrefVal Path/Ogn

*> 10.0.0.0/24 0.0.0.0 0 0 i*>i 10.0.1.0/24 2.2.2.2 100 0 200 400i* i 3.3.3.3 100 0 200 400i*>i 10.0.2.0/24 3.3.3.3 100 0 200 400 500i* i 2.2.2.2 50 0 200 400 500i…..// The following information is omitted.

Command usage The peer route-policy command specifies a route-policy to

control routes received from, or to be advertised to a peer or peer group.

View BGP view

Parameters peer ipv4-address route-policy route-policy-

name { import | export }ipv4-address: specifies an IPv4 address of a peer.route-policy-name: specifies a route-policy name.import: applies a route-policy to routes to be imported from

a peer or peer group.export: applies a route-policy to routes to be advertised to

a peer or peer group.

Configuration verification Run the display bgp routing-table command to view the BGP

routing table.


Configuring the BGP MED Attribute (1)The round-trip paths between network 10.0.0.0/24 and network 10.0.1.0/24 are

inconsistent and not the optimal routes.

Perform the configurations on R6 and do not modify the AS_Path.

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24 10.0.2.0/24

AS 100

AS 200

AS 300AS 400

AS 500

<R1>tracert -a 10.0.0.1 10.0.1.11 12.1.1.2 70 ms 50 ms 50 ms 2 24.1.1.4 60 ms 80 ms 60 ms 3 46.1.1.6 90 ms 100 ms 80 ms 4 67.1.1.7 110 ms 110 ms 90 ms

[R4]display bgp routing-table Network NextHop MED LocPrf PrefVal Path/Ogn*> 10.0.0.0/24 24.1.1.2 0 100i* 34.1.1.3 0 100i*> 10.0.1.0/24 46.1.1.6 0 400i* 47.1.1.7 0 0 400i*> 10.0.2.0/24 46.1.1.6 0 400 500i* 47.1.1.7 0 400 500i



case. Company A requires that R1 access network 10.0.1.0/24 through R7. To meet this requirement, you can enable R4 to access network 10.0.1.0/24 through R7 using the MED attribute.


Configuring the BGP MED Attribute (2)Commands CasesTroubleshooting SuggestionsPrinciples

bgpp31.rar

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24 10.0.2.0/24

AS 100AS 200

AS 300AS 400

AS 500

<R1>tracert -a 10.0.0.1 10.0.1.11 12.1.1.2 30 ms 40 ms 30 ms 2 24.1.1.4 70 ms 60 ms 60 ms 3 47.1.1.7 130 ms 90 ms 80 ms

[R4]display bgp routing-tableNetwork NextHop MED LocPrf PrefVal Path/Ogn

*> 10.0.0.0/24 24.1.1.2 0 100i* 34.1.1.3 0 100i*> 10.0.1.0/24 47.1.1.7 0 0 400i* 46.1.1.6 100 0 400i*> 10.0.2.0/24 46.1.1.6 0 400 500i* 47.1.1.7 0 400 500i

bgp 400peer 46.1.1.4 route-policy MED export#route-policy MED permit node 10if-match ip-prefix 10apply cost 100route-policy MED permit node 20ip ip-prefix 10 index 10 permit 10.0.1.0 24



View BGP view





Configuration verification Run the display bgp routing-table command to view the BGP

routing table.


Company A adjusts AS 500, adds some network segments, and needs

to control routes to network 10.0.3.0/24:

Prevent AS 100, AS 200, and AS 300 from accessing network

10.0.3.0/24, and perform the configuration on R8.

Configuring the BGP Community Attribute (1)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400 AS 500

[R4]display bgp routing-tableNetwork NextHop MED LocPrf PrefVal Path/Ogn*> 10.0.3.0/24 46.1.1.6 0 400 500i* 47.1.1.7 0 400 500i

10.0.2.0/2410.0.3.0/2410.0.4.0/24



case. To meet the requirement, use the Community attribute.


Configuring the BGP Community Attribute (2)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

10.0.2.0/2410.0.3.0/2410.0.4.0/24


bgpp33.rar


10.0.0.0/24 EBGP 255 0 D 24.1.1.2 GigabitEthernet0/0/110.0.1.0/24 EBGP 255 0 D 47.1.1.7 GigabitEthernet2/0/010.0.2.0/24 EBGP 255 0 D 46.1.1.6 GigabitEthernet1/0/010.0.4.0/24 EBGP 255 0 D 46.1.1.6 GigabitEthernet1/0/0

….// The following information is omitted.

[R6]display bgp routing-table communityNetwork NextHop MED LocPrf PrefVal Community

*> 10.0.3.0/24 68.1.1.8 0 0 no-export

[R7]display bgp routing-table communityNetwork NextHop MED LocPrf PrefVal Community

*>i 10.0.3.0/24 6.6.6.6 0 100 0 no-export

bgp 500peer 68.1.1.6 route-policy COMM exportpeer 68.1.1.6 advertise-community

#route-policy COMM permit node 10if-match ip-prefix 10apply community no-exportroute-policy COMM permit node 20#ip ip-prefix 10 index 10 permit 10.0.3.0 24



View BGP view





Configuration verification Run the display bgp routing-table community command to

view the attributes in the BGP routing table.


Company A needs to optimize the path of AS 300 and has the following

requirements:

Prevent R5 from receiving EBGP routes originated from AS 100 and AS 400, avoid

using ACLs and IP prefix list, and perform the configuration on R5.

Enable R5 to access external networks through default BGP routes, and perform

the configuration on R4.

Configuring the BGP AS_Path Attribute (1)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

10.0.2.0/2410.0.3.0/2410.0.4.0/24


Case description This case is an extension to the previous case. Perform the

configuration based on the configuration in the previous case.


Configuring the BGP AS_Path Attribute (2)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

10.0.2.0/2410.0.3.0/2410.0.4.0/24


bgpp35.rar

bgp 200peer 45.1.1.5 default-route-advertise


0.0.0.0/0 EBGP 255 0 D 45.1.1.4 GigabitEthernet0/0/210.0.2.0/24 EBGP 255 0 D 45.1.1.4 GigabitEthernet0/0/210.0.4.0/24 EBGP 255 0 D 45.1.1.4 GigabitEthernet0/0/2

bgp 300peer 45.1.1.4 route-policy AS_PATH import#route-policy AS_PATH permit node 10if-match as-path-filter AS_Filter#ip as-path-filter AS_Filter deny _100|400$ip as-path-filter AS_Filter permit .*

Command usage The peer route-policy command specifies a route-policy to control

routes received from, or to be advertised to a peer or peer group. The peer default-route-advertise command configures a BGP device

to advertise a default route to its peer or peer group.View

peer route-policy: BGP view peer default-route-advertise: BGP view

Parameters peer ipv4-address route-policy route-policy-name { import | export }

ipv4-address: specifies an IPv4 address of a peer.route-policy-name: specifies a route-policy name.import: applies a route-policy to routes to be imported from a

peer or peer group.export: applies a route-policy to routes to be advertised to a peer

or peer group.

peer { group-name | ipv4-address } default-route-advertise [ route-policy route-policy-name ] [ conditional-route-match-all{ ipv4-address1 { mask1 | mask-length1 } } &<1-4> | conditional-route-match-any { ipv4-address2 { mask2 | mask-length2 } } &<1-4> ]

ipv4-address: specifies an IPv4 address of a peer.route-policy route-policy-name: specifies a route-policy name.conditional-route-match-all ipv4-address1{ mask1 | mask-length1 }: specifies the IPv4 address and mask/mask length for conditional routes. The default routes are sent to the peer or peer group only when all conditional routes are matched.conditional-route-match-any ipv4-address2{ mask2 | mask-length2 }: specifies the IPv4 address and mask/mask length for conditional routes. The default routes are sent to the peer or peer group only when any conditional route is matched.

Configuration verification Run the display ip routing-table command to view IP routing table

information.


Company A has the following requirement:

Implement load balancing on R1, and leave the existing configuration

unchanged.

Configuring BGP Load Balancing (1)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24 10.0.2.0/24

10.0.3.0/2410.0.4.0/24

AS 100

AS 200

AS 300AS 400 AS 500

[R1]display ip routing-table protocol bgpDestination/Mask Proto Pre Cost Flags NextHop Interface

10.0.1.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/010.0.2.0/24 IBGP 255 0 RD 3.3.3.3 GigabitEthernet0/0/110.0.4.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0



configuration based on the configuration in the previous case.


Configuring BGP Load Balancing (2)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

bgp 100ipv4-family unicastmaximum load-balancing ibgp 2

[R1-bgp]display ip routing-table protocol bgp Route Flags: R - relay, D - download to fib------------------------------------------------------------------------------Public routing table : BGP

Destinations : 3 Routes : 5 BGP routing table status : <Active>

Destinations : 3 Routes : 5Destination/Mask Proto Pre Cost Flags NextHop Interface

10.0.1.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0IBGP 255 0 RD 3.3.3.3 GigabitEthernet0/0/1

10.0.2.0/24 IBGP 255 0 RD 3.3.3.3 GigabitEthernet0/0/110.0.4.0/24 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0

IBGP 255 0 RD 3.3.3.3 GigabitEthernet0/0/1

10.0.2.0/2410.0.3.0/2410.0.4.0/24


bgpp37.rar

Command usage The maximum load-balancing command configures the

maximum number of equal-cost routes.

View BGP view

Parameters maximum load-balancing [ ebgp | ibgp ] number

ebgp: implements load balancing among EBGP routes.ibgp: implements load balancing among IBGP routes.number: specifies the maximum number of equal-cost

routes in the BGP routing table.

Precautions The maximum load-balancing number command cannot be

used together with the maximum load-balancing ebgp numberor maximum load-balancing ibgp number command. If the maximum load-balancing ebgp number or maximum load-balancing ibgp number command is executed, the maximum load-balancing number command does not take effect.

Configuration verification Run the display ip routing-table protocol bgp command to

view the load-balanced routes learned by BGP.


Company A needs to strengthen its network and has the following

requirements:

Use MD5 authentication in AS 100, and set the password to Huawei.

Enable GTSM between R6 and R8, set the hop count, and discard

invalid packets. If packets are discarded, logs are recorded.

Optimizing a BGP Network (1)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

10.0.2.0/2410.0.3.0/2410.0.4.0/24



configuration based on the configuration in the previous case. After GTSM is enabled between R6 and R8, the hop count should be 1.


Optimizing a BGP Network (2)

R1

R2

R3

R4

R5

R6

R7

R8

10.0.1.0/2410.0.0.0/24

AS 100

AS 200

AS 300AS 400

AS 500

10.0.2.0/2410.0.3.0/2410.0.4.0/24

bgp 100peer 2.2.2.2 password cipher Huaweipeer 3.3.3.3 password cipher Huawei

[R1]display bgp peer 2.2.2.2 verbose | in AuthenticationAuthentication type configured: MD5

gtsm default-action dropgtsm log drop-packet all#bgp 500peer 68.1.1.6 valid-ttl-hops 1

[R8]display bgp peer 68.1.1.6 verbose | in GTSMGTSM has been enabled, valid-ttl-hops: 1


bgpp39.rar

Command usage The peer valid-ttl-hops command applies the GTSM function on the

peer or peer group. The gtsm default-action command configures the default action to be

taken on the packets that do not match the GTSM policy. The gtsm log drop-packet command enables the log function on a

board to log information about the packets discarded by GTSM on the board.

View peer valid-ttl-hops: BGP view gtsm default-action: system view gtsm log drop-packet: system view

Parameters peer ipv4-address valid-ttl-hops [ hops ]

ipv4-address: specifies the IPv4 address of a peer.hops: specifies the number of TTL hops to be checked. The value

is an integer that ranges from 1 to 255. The default value is 255. If the value is configured as hops, the valid TTL range of the detected packet is [255 - hops + 1, 255].

gtsm default-action { drop | pass }drop: discards the packets that do not match the GTSM policy.pass: allows the packets that do not match the GTSM policy to

pass through.

Precautions GTSM and EBGP-MAX-HOP affect the TTL values of sent BGP

packets. The two functions are mutually exclusive. If the default action is configured but the GTSM policy is not configured,

GTSM does not take effect.


BGP Troubleshooting

BGP Principles


BGP Troubleshooting

BGP Case Analysis


Troubleshooting Cases SuggestionsCommandsPrinciples


R2

10.0.0.0/2410.0.1.0/2410.0.2.0/2410.0.3.0/2410.1.0.0/24

172.16.0.0/24172.16.1.0/24172.16.2.0/24172.16.3.0/24172.16.4.0/24

.1 .2

R1

192.168.1.0/24

After BGP is established on the entire network, the user at 10.0.0.5

cannot communicate with the user at 172.16.0.5.

Analyze and rectify the fault.

BGP TroubleshootingTroubleshooting Cases SuggestionsCommandsPrinciples


Troubleshooting Flow (1)

Assume that the fault exists in BGP:

The BGP peer relationship cannot enter the Established state.

• IGPs cannot work properly.

• An ACL is configured to filter packets with the destination TCP port 179.

• The peer router ID conflicts with the local router ID.

• The peer AS number is incorrect.

• Loopback interfaces are used to establish the BGP peer relationship, but the

peer connect-interface command is not configured.

• Loopback interfaces are used to establish the EBGP peer relationship, but

the peer ebgp-max-hop command is not configured.

• The peer valid-ttl-hops command configuration is incorrect.

• The number of routes sent by the peer exceeds the upper limit configured

using the peer route-limit command.

• The peer ignore command is configured on the peer.

• The address families of devices on both ends are inconsistent.




The BGP peer relationship is normal, but the BGP routing table does

not contain the routing entry.

• Check whether the next-hop address is reachable.

• Check whether an inbound routing policy is configured to limit routes.

• Check whether a route-policy is configured to limit the route of the prefix.

• Check whether an outbound routing policy is configured on the peer to limit

routes.

• Check whether the prefix is the optimal route in the peer BGP routing table.

• Check whether the active-route-advertise command is configured on the

peer.




The BGP peer relationship is normal, but the BGP routing table

contains some non-optimal routes.

• Some routes are not optimal according to BGP routing rules.

• Some prefixes are suppressed.


huawei routing & switching elite training – bgp basics

Documents