Three early versions of BGP are BGP-1 (RFC1105), BGP-2 (RFC1163) and BGP-3 (RFC1267). The current version in use is BGP-4 (RFC1771). BGP-4 is rapidly becoming the defacto Internet exterior routing protocol standard and is commonly used between ISPs.

The characteristics of BGP are as follows:

l Focusing on the control of route propagation and the selection of optimal routes rather than the discovery and calculation of routes, which makes BGP, an exterior routing protocol different from interior routing protocols such as OSPF and RIP

l Using TCP as its transport layer protocol to enhance reliability

l Supporting CIDR

l Substantially reducing bandwidth occupation by advertising updating routes only and applicable to advertising a great amount of routing information on the Internet

l Eliminating route loops completely by adding AS path information to BGP routes

l Providing abundant routing policies, allowing for implementing flexible route filtering and selection

l Easy to extend, satisfying new network developments

A router advertising BGP messages is called a BGP speaker, which exchanges new routing information with other BGP speakers. When a BGP speaker receives a new route or a route better than the current one from another AS, it will advertise the route to all the other BGP speakers in the local AS.

BGP speakers call each other peers, and several associated peers form a peer group.

BGP runs on a router in one of the following two modes:

l IBGP (Interior BGP)

l EBGP (External BGP)

BGP is called IBGP when it runs within an AS and is called EBGP when it runs between ASs.

1.1.1 Formats of BGP Messages

I. Header

BGP message involves five types:

l Open message

l Update message

l Notification message

l Keep-alive message

l Route-refresh message

They have the same header, as shown below:

Figure 1-1 BGP message header

l Marker: The 16-octet field is used for BGP authentication calculation. If no authentication information is available, then the Marker must be all ones.

l Length: The 2-octet unsigned integer indicates the total length of the message.

l Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined: 1–Open, 2-Update, 3-Notification, 4–Keepalive, and 5–Route-refresh. The former four are defined in RFC1771, the last one defined in RFC2918.

II. Open

After a TCP connection is established, the first message sent by each side is an Open message for peer relationship establishment. The Open message contains the following fields:

Figure 1-2 BGP open message format

l Version: This 1-octet unsigned integer indicates the protocol version number of the message. The current BGP version is 4.

l My autonomous system: This 2-octet unsigned integer indicates the Autonomous System number of the sender.

l Hold time: When establishing peer relationship, two parties negotiate an identical Hold time. If no Keepalive or Update is received from a peer after the Hold time, the BGP connection is considered down.

l BGP identifier: In IP address format, identifying the BGP router

l Opt Parm Len (Optional Parameters Length): Length of optional parameters, set to 0 if no optional parameter is available

l Optional parameters: Used for BGP authentication, multiprotocol extensions, and so on.

III. Update

Update message is used to exchange routing information between peers. It can advertise a feasible route or remove multiple unfeasible routes. Its format is shown below:

Figure 1-3 BGP Update message format

Each Update message can advertise a group of feasible routes with similar attributes, which are contained in the network layer reachable information (NLRI) field. The Path Attributes field carries attributes of these routes that are used by BGP for routing. Each message can also carry multiple withdrawn routes in the Withdrawn Routes field.

l Unfeasible routes length: The total length of the Withdrawn routes field in octets. A value of 0 indicates neither any route is being withdrawn from service, nor Withdrawn routes field is present in this Update message.

l Withdrawn routes: This is a variable length field that contains a list of IP prefixes of routes that are being withdrawn from service.

l Total path attribute length: Total length of the Path attributes field in octets. A value of 0 indicates that no Network Layer Reachability Information field is present in this Update message.

l Path attributes: List of path attributes related to NLRI. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length. BGP uses these attributes to avoid routing loops, perform routing and protocol extension.

l NLRI (Network Layer Reachability Information): Reachability information is encoded as one or more 2-tuples of the form <length, prefix>.

IV. Notification

A Notification message is sent when an error is detected. The BGP connection is closed immediately after sending it. Notification message format is shown below:

Figure 1-4 BGP Notification message format

l Error code: Type of Notification.

l Error subcode: Specific information about the nature of the reported error.

l Data: Used to diagnose the reason for the Notification. The contents of the Data field depend upon the Error Code and Error Subcode. Erroneous part of data is recorded. The Data field length is variable.

V. Keepalive

Keepalive messages are sent between peers to maintain connectivity. Its format contains only the message header.

VI. Route-refresh

A route-refresh message is sent to a peer to request the resending of the specified address family routing information. Its format is shown below:

Figure 1-5 BGP Route-refresh message format

AFI: Address Family Identifier.

Res: Reserved. Set to 0.

SAFI: Subsequent Address Family Identifier.

1.1.2 BGP Path Attributes

I. Classification of path attributes

Path attributes fall into four categories:

l Well-known mandatory: Must be recognized by all BGP routers and must be included in every update message. Routing information error occurs without this attribute.

l Well-known discretionary: Can be recognized by all BGP routers and optional to be included in every update message as needed.

l Optional transitive: Transitive attribute between ASs. A BGP router not supporting this attribute can still receive routes with this attribute and advertise them to other peers.

l Optional non-transitive: If a BGP router does not support this attribute, it will not advertise routes with this attribute.

The usage of each BGP path attributes is described in the following table.

Table 1-1 Usage of BGP path attributes

Name	Category
ORIGIN	Well-known mandatory
AS_PATH	Well-known mandatory
NEXT_HOP	Well-known mandatory
LOCAL_PREF	Well-known discretionary
ATOMIC_AGGREGATE	Well-known discretionary
AGGREGATOR	Optional transitive
COMMUNITY	Optional transitive
MULTI_EXIT_DISC (MED)	Optional non-transitive
ORIGINATOR_ID	Optional non-transitive
CLUSTER_LIST	Optional non-transitive

II. Usage of BGP path attributes

1) ORIGIN

ORIGIN is a well-known mandatory attribute and defines the origin of routing information and how a route becomes a BGP route. It involves three types:

l IGP: Has the highest priority. Routes added to the BGP routing table using the network command have the IGP attribute.

l EGP: Has the second highest priority. Routes obtained via EGP have the EGP attribute.

l incomplete: Has the lowest priority. The source of routes with this attribute is unknown, which does not mean such routes are unavailable. The routes redistributed from other routing protocols have the incomplete attribute.

2) AS_PATH

AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this Update message has passed. When a route is advertised from the local AS to another AS, each passed AS number is added into the AS_PATH attribute, thus the receiver can determine ASs to route massages back. The number of the AS closest with the receiver’s AS is leftmost, as shown below:

Figure 1-6 AS_PATH attribute

In general, a BGP router does not receive routes containing the local AS number to avoid routing loops.

& Note:

The current implementation supports using the peer allow-as-loop command to receive routes containing the local AS number to meet special requirements.

AS_PATH attribute can be used for route selection and filtering. BGP gives priority to the route with the shortest AS_PATH length if other factors are the same. As shown in the above figure, the BGP router in AS 50 gives priority to the route passing AS 40 for sending information to the destination 8.0.0.0.

In some applications, you can apply a routing policy to control BGP route selection by modifying the AS path length.

By configuring an AS path filtering list, you can filter routes based on AS numbers contained in the AS_PATH attribute.

3) NEXT_HOP

Different from IGP, the NEXT_HOP attribute of BGP may not be the IP address of a neighboring router. It involves three types of values, as shown in Figure 1-7.

l When advertising a self-originated route to an EBGP peer, a BGP speaker sets the NEXT_HOP for the route to the address of its sending interface.

l When sending a received route to an EBGP peer, a BGP speaker sets the NEXT_HOP for the route to the address of the sending interface.

l When sending a route received from an EBGP peer to an IBGP peer, a BGP speaker does not modify the NEXT_HOP attribute. If load-balancing is configured, the NEXT_HOP attribute will be modified. For load-balancing information, refer to BGP Route Selection.

Figure 1-7 NEXT_HOP attribute

4) MED (MULTI_EXIT_DISC)

The MED attribute is exchanged between two neighboring ASs, each of which will not advertise the attribute to any other AS.

Similar with metrics used by IGP, MED is used to determine the best route for traffic going into an AS. When a BGP router obtains multiple routes to the same destination but with different next hops, it considers the route with the smallest MED value the best route if other conditions are the same. As shown below, traffic from AS 10 to AS 20 travels through Router B that is selected according to MED.

Figure 1-8 MED attribute

In general, BGP compares MEDs of routes to the same AS only.

& Note:

The current implementation supports using the compare-different-as-med command to force BGP to compare MED values of routes to different ASs.

5) LOCAL_PREF

This attribute is exchanged between IBGP peers only, thus not advertised to any other AS. It indicates the priority of a BGP router.

LOCAL_PREF is used to determine the best route for traffic leaving the local AS. When a BGP router obtains from several IBGP peers multiple routes to the same destination but with different next hops, it considers the route with the highest LOCAL_PREF value as the best route. As shown below, traffic from AS 20 to AS 10 travels through Router C that is selected according to LOCAL_PREF.

Figure 1-9 LOCAL_PREF attribute

6) COMMUNITY

The COMMUNITY attribute is used to simplify routing policy usage and ease management and maintenance. It is a collection of destination addresses having identical attributes, without physical boundaries in between, having nothing to do with local AS. Well known community attributes include:

l Internet: By default, all routes belong to the Internet community. Routes with this attribute can be advertised to all BGP peers.

l No_Export: After received, routes with this attribute cannot be advertised out the local AS or out the local confederation but can be advertised to other sub ASs in the confederation (for confederation information, refer to Settlements for Problems Caused by Large Scale BGP Networks).

l No_Advertise: After received, routes with this attribute cannot be advertised to other BGP peers.

l No_Export_Subconfed: After received, routes with this attribute cannot be advertised out the local AS or other ASs in the local confederation.

1.1.3 BGP Route Selection

I. Route selection rule

The current BGP implementation supports the following route selection rule:

l Discard routes with unreachable NEXT_HOP first

l Select the route with the highest Preferred_value

l Select the route with the highest LOCAL_PREF

l Select the route originated by the local router

l Select the route with the shortest AS-PATH

l Select ORIGIN IGP, EGP, Incomplete routes in turn

l Select the route with the lowest MED value

l Select routes learned from EBGP, confederation, IBGP in turn

l Select the route with the smallest next hop cost

l Select the route with the shortest CLUSTER_LIST

l Select the route with the smallest ORIGINATOR_ID

l Select the route advertised by the router with the smallest Router ID

& Note:

l CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that contains its own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing loop.

l If load balancing is configured, the system selects available routes to implement load balancing.

II. Route selection with BGP load balancing

The next hop of a BGP route may not be a directly connected neighbor. One of the reasons is next hops in routing information exchanged between IBGPs are not modified. In this case, the router finds the direct route via IGP route entries to reach the next hop. The direct route is called reliable route. The process of finding a reliable route to reach a next hop is route recursion.

Currently, the system supports BGP load balancing based on route recursion, namely if reliable routes are load balanced (suppose three next hop addresses), BGP generates the same number of next hops to forward packets. Note that BGP load balancing based on route recursion is always enabled by the system rather than configured using command.

BGP differs from IGP in the implementation of load balancing in the following:

l IGP routing protocols such as RIP, OSPF compute metrics of routes, and then implement load balancing on routes with the same metric and to the same destination. The route selection criterion is metric.

l BGP has no route computation algorithm, so it cannot implement load balancing according to metrics of routes. However, BGP has abundant route selection rules, through which, it selects available routes for load balancing and adds load balancing to route selection rules.

& Note:

l BGP implements load balancing only on routes that have the same AS_PATH attribute, ORIGIN attribute, LOCAL_PREF and MED.

l BGP load balancing is applicable between EBGPs, IBGPs and between confederations.

l If multiple routes to the same destination are available, BGP selects routes for load balancing according to the configured maximum number of load balanced routes.

Figure 1-10 Network diagram for BGP load balancing

In the above figure, Router D and Router E are IBGP peers of Router C. Router A and Router B both advertise a route destined for the same destination to Router C. If load balancing is configured and the two routes have the same AS_PATH attribute, ORIGIN attribute, LOCAL_PREF and MED, Router C adds both the two routes to its route table for load balancing. After that, Router C forwards routes to Router D and Router E only once, with AS_PATH unchanged, NEXT_HOP changed to Router C’s address. Other BGP transitive attributes apply according to route selection rules.

III. BGP route advertisement rule

The current BGP implementation supports the following route advertisement rules:

l When multiple available routes exist, a BGP speaker advertises only the best route to its peers.

l A BGP speaker advertises only routes used by itself.

l A BGP speaker advertises routes learned from EBGPs to all BGP peers, including both EBGP and IBGP peers.

l A BGP speaker does not advertise routes learned from IBGPs to IBGP peers.

l A BGP speaker advertises routes learned from IBGPs to EBGP peers. Note that if information synchronization is disabled between BGP and IGP, IBGP routes are advertised to EBGP peers. If enabled, only IGP advertises the IBGP routes can these routes be advertised to EBGP peers.

l A BGP speaker advertises all routes to a newly connected peer.

1.1.4 IBGP and IGP Information Synchronization

The routing Information synchronization between IBGP and IGP is for avoidance of giving wrong directions to routers outside of the local AS.

If a non-BGP router works in an AS, a packet forwarded via the router may be discarded due to unreachable destination. As shown in Figure 1-11, Router E learned a route of 8.0.0.0/8 from Router D via BGP. Then Router E sends a packet to Router A through Router D, which finds from its routing table that Router B is the next hop (configured using the peer next-hop-local command). Since Router D learned the route to Router B via IGP, it forwards the packet to Router C using route recursion. Router C has no idea about the route 8.0.0.0/8, so it discards the packet.

Figure 1-11 IBGP and IGP synchronization

If synchronization is configured in this example, the IBGP router (Router D) checks the learned IBGP route from its IGP routing table first. Only the route is available in the IGP routing table can the IBGP router add the route into its BGP routing table and advertise the route to the EBGP peer.

You can disable the synchronization feature in the following cases:

l The local AS is not a transitive AS (AS 20 is a transitive AS in the above figure).

l IBGP routers in the local AS are fully meshed.

1.1.5 Settlements for Problems Caused by Large Scale BGP Networks

I. Route summarization

The size of BGP routing tables on a large network is very large. Using route summarization can reduce the routing table size.

By summarizing multiple routes with one route, a BGP router advertises only the summary route rather than all routes.

Currently, the system supports both manual and automatic summarization. The latter provides for controlling the attribute of a summary route and deciding whether to advertise the route.

II. Route dampening

BGP route dampening is used to solve the issue of route instability such as route flaps, that is, a route comes up and disappears in the routing table frequently.

When a route flap occurs, the routing protocol sends an update to its neighbor, and then the neighbor needs to recalculate routes and modify the routing table. Therefore, frequent route flaps consume large bandwidth and CPU resources even affect normal operation of the network.

In most cases, BGP is used in complex networks, where route changes are very frequent. To solve the problem caused by route flaps, BGP uses route dampening to suppress unstable routes.

BGP route dampening uses a penalty value to judge the stability of a route. The bigger the value, the less stable the route. Each time a route flap occurs (the state change of a route from active to inactive is a route flap.), BGP adds a penalty value (1000, which is a fixed number and cannot be changed) to the route. When the penalty value of the route exceeds the suppress value, the route is suppressed, that is, it is neither added into the routing table, nor advertised to other BGP peers.

The penalty value of the suppressed route will reduce to half of the suppress value after a period of time. This period is called Half-life. When the value decreases to the reusable threshold value, the route is added into the routing table and advertised to other BGP peers in update packets.

Figure 1-12 BGP route dampening

III. Peer group

A peer group is a collection of peers with the same attributes. When a peer joins the peer group, the peer obtains the same configuration as the peer group. If configuration of the peer group is changed, configuration of group members is also changed.

There are many peers in a large BGP network. Some of these peers may be configured with identical commands. The peer group feature simplifies configuration of this kind.

When a peer is added into a peer group, the peer enjoys the same route update policy as the peer group, improving route distribution efficiency.

Caution:

If an option is configured both for a peer and for the peer group, the latest configuration takes effect.

IV. Community

A peer group makes peers in it enjoy the same policy, while a community makes a group of BGP routers in several ASs enjoy the same policy. Community is a path attribute and advertised between BGP peers, without being limited by AS.

A BGP router can modify the community attribute for a route before sending it to other peers.

Besides using the well-known community attribute, you can define the extended community attribute using a community list to help define a routing policy.

V. Route reflector

IBGP peers should be fully meshed to maintain connectivity. Suppose there are n routers in an AS, the number of IBGP connections is n(n-1)/2. If there are many IBGP peers, most network and CPU resources will be consumed.

Using route reflectors can solve the issue. In an AS, a router acts as a route reflector, and other routers act as clients connecting to the route reflector. The route reflector forwards (reflects) routing information between clients. BGP connections between clients need not be established.

The router neither a route reflector nor a client is a non-client, which has to establish connections to all the route reflector and non-clients, as shown below.

Figure 1-13 Network diagram for route reflector

The route reflector and clients form a cluster. In some cases, you can configure more than one route reflector in a cluster to improve network reliability and prevent single point failure, as shown in the following figure. The configured route reflectors must have the same Cluster_ID to avoid routing loops.

Figure 1-14 Network diagram for route reflectors

When clients of a route reflector are fully meshed, route reflection is unnecessary because it consumes more bandwidth resources. The system supports using related commands to disable route reflection in this case.

& Note:

After route reflection is disabled between clients, routes between clients and non-clients can still be reflected.

VI. Confederation

Confederation is another method to deal with growing IBGP connections in ASs. It splits an AS into multiple sub ASs. In each sub AS, IBGP peers are fully meshed, and EBGP connections are established between sub ASs, as shown below:

Figure 1-15 Confederation network diagram

From the perspective of a non-confederation speaker, it needs not know sub ASs in the confederation. The ID of the confederation is the number of the AS, in the above figure, AS 200 is the confederation ID.

The deficiency of confederation is: when changing an AS into a confederation, you need to reconfigure your routers, and the topology will be changed.

In large-scale BGP networks, both route reflector and confederation can be used.

1.1.6 MP-BGP

I. Overview

The legacy BGP-4 supports IPv4, but does not support some other network layer protocols like IPv6.

To support more network layer protocols, IETF extended BGP-4 by introducing Multiprotocol Extensions for BGP-4 (MP-BGP), which is defined in RFC2858.

Routers supporting MP-BGP can communicate with routers not supporting MP-BGP.

II. MP-BGP extended attributes

In BGP-4, the three types of attributes for IPv4, namely NLRI, NEXT_HOP and AGGREGATOR (contains the IP address of the speaker generating the summary route) are all carried in updates.

To support multiple network layer protocols, BGP-4 puts information about network layer into NLRI and NEXT_HOP. MP-BGP introduced two path attributes:

l MP_REACH_NLRI: Multiprotocol Reachable NLRI, for advertising available routes and next hops

l MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI, for withdrawing unfeasible routes

The above two attributes are both Optional non-transitive, so BGP speakers not supporting multi-protocol ignore the two attributes, not forwarding them to peers.

III. Address family

MP-BGP employs address family to differentiate network layer protocols. For address family values, refer to RFC 1700 (Assigned Numbers). Currently, the system supports multiple MP-BGP extensions, including VPN extension, IPv6 extension. Different extensions are configured in respective address family view.

& Note:

l For information about the VPN extension application, refer to MPLS L3VPN Configuration in the MPLS VPN Volume.

l For information about the IPv6 extension application, refer to IPv6 BGP Configuration in the IP Routing Volume.

l This chapter gives no detailed commands related to any specific extension application in MP-BGP address family view.

1.1.7 Protocols and Standards

RFC1771: A Border Gateway Protocol 4 (BGP-4)

RFC2858: Multiprotocol Extensions for BGP-4

RFC3392: Capabilities Advertisement with BGP-4

RFC2918: Route Refresh Capability for BGP-4

RFC2439: BGP Route Flap Damping

RFC1997: BGP Communities Attribute

RFC2796: BGP Route Reflection

RFC3065: Autonomous System Confederations for BGP

Features in draft stage include Graceful Restart and extended community attributes.

1.2 BGP Configuration Task List

Complete the following tasks to configure BGP:

Task		Description
Configuring BGP Basic Functions		Required
Controlling Route Distribution and Reception	Configuring BGP Route Redistribution	Optional
	Configuring BGP Route Summarization	Optional
	Advertising a Default Route to a Peer or Peer Group	Optional
	Configuring BGP Route Distribution Policy	Optional
	Configuring BGP Route Reception Policy	Optional
	Enabling BGP and IGP Route Synchronization	Optional
	Configuring BGP Route Dampening	Optional
Configuring BGP Routing Attributes		Required
Tuning and Optimizing BGP Networks		Required
Configuring a Large Scale BGP Network	Configuring BGP Peer Groups	Optional
	Configuring BGP Community	Optional
	Configuring a BGP Route Reflector	Optional
	Configuring a BGP Confederation	Optional

1.3 Configuring BGP Basic Functions

The section describes BGP basic configuration.

& Note:

l This section does not differentiate between BGP and MP-BGP.

l Since BGP employs TCP, you need to specify IP addresses of peers, which may not be neighboring routers.

l Using logical links can also establish BGP peer relationships.

l In general, IP addresses of loopback interfaces are used to improve stability of BGP connections.

1.3.1 Prerequisites

The neighboring nodes are accessible to each other at the network layer.

1.3.2 Configuration Procedure

Follow these steps to configure BGP basic functions:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enable BGP and enter BGP view		bgp as-number	Required Not enabled by default
Specify a Router ID		Router-id ip-address	Optional If no IP addresses are configured for loopback interface and other interfaces, the task becomes required
Specify the AS number for a peer or a peer group		peer { group-name \| ip-address } as-number as-number	Required Not specified by default
Configure a description for a peer or a peer group		peer { group-name \| ip-address } description description-text	Optional Not configured by default
Enable IPv4 unicast address family for all peers		default ipv4-unicast	Optional Enabled by default
Enable a peer		peer ip-address enable	Optional Enabled by default
Disable session with a peer or peer group		peer { group-name \| ip-address } ignore	Optional Not disabled by default
Enable the logging on peer state changes	Enable BGP logging globally	log-peer-change	Optional Enabled by default
Enable the logging on peer state changes	Enable logging for a peer or peer group	peer { group-name \| ip-address } log-change	Optional Enabled by default
Specify a preferred value for routes from a peer or peer group		peer { group-name \| ip-address } preferred-value value	Optional The preferred value defaults to 0
Specify the source interface for establishing TCP connections to a peer or peer group		peer { group-name \| ip-address } connect-interface interface-type interface-number	Optional By default, BGP uses the outbound interface of the best route to the BGP peer as the source interface for establishing a TCP connection to the peer/peer group.
Allow the establishment of EBGP connection to a non directly connected peer/peer group		peer { group-name \| ip-address } ebgp-max-hop [ hop-count ]	Optional Not allowed by default. By specifying hop-count, you can specify the max hops for the EBGP connection

Caution:

l It is required to specify for a BGP router a router ID, a 32-bit unsigned integer and the unique identifier of the router in the AS.

l You must create a peer group before configuring basic functions for it. For information about creating a peer group, refer to Configuring BGP Peer Groups.

l You can specify a router ID manually. If not, the system selects an IP address as the router ID. The selection sequence is the highest IP address among loopback interface addresses; if not available, then the highest IP address of interfaces. It is recommended to specify a loopback interface address as the router ID to enhance network reliability. Only when the interface with the selected Router ID or the manual Router ID is deleted will the system select another ID for the router.

l To enable the BGP peer or peer group to receive/send route updates normally even when the local interface goes down, you can specify the source interface for establishing TCP connections to the peer or peer group as a loopback interface.

l To establish multiple BGP connections between two BGP routers, you need to specify on the local router the source interfaces for establishing TCP connections to the peers on the peering BGP router respectively; otherwise, the local BGP router may fail to establish TCP connections to the peers when using the outbound interfaces of the best routes as the source interfaces.

l In general, direct physical links should be available between EBGP peers. If not, you can use the peer ebgp-max-hop command to establish a TCP connection over multiple hops between two peers. You do not need to use this command for directly connected EBGP peers, which employ loopback interfaces for peer relationship establishment.

l If you both reference a routing policy and use the peer { group-name | ip-address } preferred-value value command to set a preferred value for routes from a peer, the routing policy sets a non-zero preferred value for routes matching it. Other routes not matching the routing policy uses the value set with the peer { group-name | ip-address } preferred-value value command. If the preferred value in the routing policy is zero, the routes matching it will use the value set with the command. For information about using a routing policy to set a preferred value, refer to the peer { group-name | ip-address } route-policy route-policy-name { export | import } command and the apply preferred-value preferred-value command.

1.4 Controlling Route Distribution and Reception

1.4.1 Prerequisites

Before configuring this task, you have completed BGP basic configuration.

1.4.2 Configuring BGP Route Redistribution

BGP can advertise the routing information of the local AS to peering ASs, but it redistributes routing information from IGP into BGP routing table rather than self-finding. During route redistribution, BGP can filter routing information according to different routing protocols.

Follow these steps to configure BGP route redistribution:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Enable BGP to redistribute default route into the BGP routing table	default-route imported	Optional Not enabled by default
Redistribute routes from another routing protocol for advertisement	import-route protocol [ process-id [ med med-value \| route-policy route-policy-name ] * ]	Required Not redistributed by default
Advertise a network to the BGP routing table	network ip-address [ mask \| mask-length ] [ short-cut \| route-policy route-policy-name ]	Optional Not advertised by default

& Note:

l The ORIGIN attribute of routes redistributed using the import-route command is Incomplete.

l The ORIGIN attribute of networks advertised into the BGP routing table with the network command is IGP and these networks must exist in the local IP routing table. Using a routing policy makes routes control more flexible.

1.4.3 Configuring BGP Route Summarization

To reduce the routing table size on medium and large BGP networks, you need to configure route summarization on peers. BGP supports two summarization types: automatic and manual.

l Automatic summarization: Summarizes redistributed IGP subnets. With the feature configured, BGP advertises only summary natural networks rather than subnets. The default route and routes imported using the network command can not be summarized.

l Manual summarization: Summarizes BGP local routes. The manual summary routes have higher priority than automatic ones.

Follow these steps to configure BGP route summarization:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter BGP view		bgp as-number	—
Configure BGP route summarization	Configure automatic route summarization	summary automatic	Required No route summarization is configured by default Choose either as needed; if both are configured, the manual route summarization takes effect.
Configure BGP route summarization	Configure manual route summarization	aggregate ip-address { mask \| mask-length } [ as-set \| attribute-policy route-policy-name \| detail-suppressed \| origin-policy route-policy-name \| suppress-policy route-policy-name ]*

1.4.4 Advertising a Default Route to a Peer or Peer Group

Follow these steps to advertise a default route to a peer or peer group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Advertise a default route to a peer or peer group	peer { group-name \| ip-address } default-route-advertise [ route-policy route-policy-name ]	Required Not advertised by default

& Note:

With the peer default-route-advertise command executed, the router sends a default route with the next hop being itself to the specified peer/peer group, regardless of whether the default route is available in the routing table.

1.4.5 Configuring BGP Route Distribution Policy

Follow these steps to configure BGP route distribution policy:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Filter redistributed routes when advertising them	filter-policy { acl-number \| ip-prefix ip-prefix-name } export [ direct \| isis process-id \| ospf process-id \| rip process-id \| \| static ]	Required to choose any; The filtering is not configured by default; You can configure a filtering policy as needed; If several filtering policies are configured, they are applied in the following sequence: l filter-policy export l peer filter-policy export l peer as-path-acl export l peer ip-prefix export l peer route-policy export Only routes passing the first policy, can they go through the next; and only routes passing all the configured policies, can they be advertised.
Reference a routing policy to filter routes to a peer/peer group	peer { group-name \| ip-address } route-policy route-policy-name export
Reference an ACL to filer routing information to a peer/peer group	peer { group-name \| ip-address } filter-policy acl-number export
Reference an AS path ACL to filer routing information to a peer/peer group	peer { group-name \| ip-address } as-path-acl as-path-acl-number export
Reference an IP prefix list to filer routing information to a peer/peer group	peer { group-name \| ip-address } ip-prefix ip-prefix-name export

Caution:

Only routes passing the filters can be advertised.

1.4.6 Configuring BGP Route Reception Policy

Follow these steps to configure BGP routing reception policy:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Filter incoming routes	filter-policy { acl-number \| ip-prefix ip-prefix-name } import	Required to choose any; No inbound filtering is configured by default; You can configure a filtering policy as needed; If several filtering policies are configured, they are applied in the following sequence: l filter-policy import l peer filter-policy import l peer as-path-acl import l peer ip-prefix import l peer route-policy import Only routes passing the first policy, can they go through the next; and only routes passing all the configured policies, can they be received.
Reference a routing policy to filter routes from a peer/peer group	peer { group-name \| ip-address } route-policy policy-name import
Reference an ACL to filter routing information from a peer/peer group	peer { group-name \| ip-address } filter-policy acl-number import
Reference an AS path ACL to filter routing information from a peer/peer group	peer { group-name \| ip-address } as-path-acl as-path-acl-number import
Reference an IP prefix list to filter routing information from a peer/peer group	peer { group-name \| ip-address } ip-prefix ip-prefix-name import
Specify the maximum number of routes that can be received from a peer/peer group	peer { group-name \| ip-address } route-limit limit [ percentage ]	The number is unlimited by default.

Caution:

l Only routes permitted by the specified filter policy can be added into the local BGP routing table.

l Members of a peer group can have different inbound route filter policies from the peer group.

1.4.7 Enabling BGP and IGP Route Synchronization

With this feature enabled, if a non BGP router is responsible for forwarding packets in the AS, the BGP speaker in the AS cannot advertise routes to external ASs unless all the routers in the AS know the latest routing information.

By default, when a BGP router receives an IBGP route, it only checks the reachability of the route’s next hop. With BGP and IGP synchronization enabled, the BGP router cannot advertise the route to EBGP peers unless the route is also advertised by the IGP.

Follow these steps to configure BGP and IGP synchronization:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Enable synchronization between BGP and IGP	synchronization	Required Not enabled by default

1.4.8 Configuring BGP Route Dampening

Through configuring BGP route dampening, you can suppress unstable routes to neither add them to the local routing table nor advertise them to BGP peers.

Follow these steps to configure BGP route dampening:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Configure BGP route dampening	dampening [ half-life-reachable half-life-unreachable reuse suppress ceiling \| route-policy route-policy-name ] *	Optional Not configured by default

1.5 Configuring BGP Routing Attributes

1.5.1 Prerequisites

Before configuring this task, you have configured BGP basic functions.

1.5.2 Configuration Procedure

You can use BGP route attributes to adjust BGP route selection policy.

Follow these steps to configure BGP route attributes:

To do…			Use the command…	Remarks
Enter system view			system-view	—
Enter BGP view			bgp as-number	—
Configure preferences for external, internal, local routes			preference { external-preference internal-preference local-preference \| route-policy route-policy-name }	Optional The default preferences of external, internal and local routes are 255, 255, and 130 respectively.
Configure the default value of local preference			default local-preference value	Optional The value defaults to 100
Configure the MED attribute	Configure the default MED value		default med med-value	Optional The value defaults to 0
	Enable to compare MED values of routes from different ASs		compare-different-as-med	Optional Not enabled by default
	Enable to compare MED values of routes from each AS		bestroute compare-med	Optional Not enabled by default
	Enable to compare MED values of routes from confederation peers		bestroute med-confederation	Optional Not enabled by default
Specify the router as the next hop of routes to a peer/peer group			peer { group-name \| ip-address } next-hop-local	Optional By default, routes to an EBGP peer/peer group take the router as the next hop, while routes to an IBGP peer/peer group do not take the local router as the next hop.
Configure the AS_PATH attribute		Configure repeating times of local AS number in routes from a peer/peer group	peer { group-name \| ip-address } allow-as-loop [ number ]	Optional The local AS number can not be repeated in routes from the peer/peer group.
		Disable the router from taking AS_PATH as a factor for best route selection	bestroute as-path-neglect	Optional By default, the router takes AS_PATH as a factor for best route selection
		Specify a fake AS number for a peer/peer group	peer { group-name \| ip-address } fake-as as-number	Optional Not specified by default This command is only applicable to an EBGP peer or peer group.
		Substitute the local AS number for the AS number of a peer/peer group in the AS_PATH attribute	peer { group-name \| ip-address } substitute-as	Optional The substitution is not configured by default.
		Configure BGP to not keep private AS numbers in the AS_PATH attribute of updates to a peer/peer group	peer { group-name \| ip-address } public-as-only	Optional By default, BGP updates carry private AS numbers.

Caution:

l Using a routing policy can set a preference for routes meeting its filtering conditions. Routes not meeting the conditions use the default preference.

l If other conditions are identical, the route with the smallest MED value is selected as the best external route of the AS.

l Using the peer next-hop-local command can specify the router as the next hop for a peer/peer group. If BGP load balancing is configured, the router specify itself as the next hop for routes to a peer/peer group regardless of whether the peer next-hop-local command is configured.

l In a “third party next hop" network, that is , the two EBGP peers reside in a common broadcast subnet, the BGP router does not specify itself as the next hop for routes to the EBGP peer, unless the peer next-hop-local command is configured.

l In general, BGP checks whether the AS_PATH attribute of a route from a peer contains the local AS number. If so, it discards the route to avoid routing loops.

l You can specify a fake AS number to hide the real one as needed. The fake AS number applies to EBGP peers only, that is, EBGP peers in other ASs can only find the fake AS number.

l The peer substitute-as command is used only in specific networking environments. Inappropriate use of the command may cause routing loops.

1.6 Tuning and Optimizing BGP Networks

This task involves the following parts:

1) Configure BGP timers

After establishing a BGP connection, two routers send keepalive messages periodically to each other to keep the connection. If a router receives no keepalive message from the peer after the holdtime elapses, it tears down the connection.

When establishing a BGP connection, the two parties compare their holdtime values, taking the shorter one as the common holdtime.

2) Reset BGP connections

After modifying a route selection policy, you have to reset BGP connections to make the new one take effect, causing a short time disconnection. The current BGP implementation supports the route-refresh capability. With this capability enabled on all BGP routers in a network, when a policy is modified on a router, the router advertises a route-refresh message to its peers, which then resend their routing information to the router. Therefore, the local router can perform dynamic route update and apply the new policy without tearing down BGP connections.

If a router not supporting route-refresh exists in the network, you need to configure the peer keep-all-routes command to save all route updates, and then use the refresh bgp command to soft reset BGP connections, which can refresh the BGP routing table and apply the new policy without tearing down BGP connections.

3) Configure BGP authentication

BGP employs TCP as the transport protocol. To enhance security, you can configure BGP to perform MD5 authentication when establishing a TCP connection. BGP MD5 authentication is not for BGP packets. It is used to set passwords for TCP connections. If the authentication fails, the TCP connection can not be established.

1.6.1 Prerequisites

Before configuring this task, you have configured BGP basic functions

1.6.2 Configuration Procedure

Follow these steps to tune and optimize BGP networks:

To do…			Use the command…	Remarks
Enter system view			system-view	—
Enter BGP view			bgp as-number	—
Configure BGP timers	Configure keepalive interval and holdtime		timer keepalive keepalive hold holdtime	Optional The keepalive interval defaults to 60 seconds, holdtime defaults to 180 seconds.
Configure BGP timers	Configure keepalive interval and holdtime for a peer/peer group		peer { group-name \| ip-address } timer keepalive keepalive hold holdtime
Configure the interval for sending the same update to a peer/peer group			peer { group-name \| ip-address } route-update-interval seconds	Optional The intervals for sending the same update to an IBGP peer and an EBGP peer default to 15 seconds and 30 seconds respectively.
Configure BGP soft reset		Disable BGP route-refresh and multi-protocol extensions for a peer/peer group	peer { group-name \| ip-address } capability-advertise conventional	Optional Enabled by default
		Enable BGP route refresh for a peer/peer group	peer { group-name \| ip-address } capability-advertise route-refresh	Optional Enabled by default
		Keep all original routes imported from a peer/peer group regardless of whether they pass the inbound filtering policy	peer { group-name \| ip-address } keep-all-routes	Optional Not kept by default
		Return to user view	return	—
		Perform manual soft reset on BGP connections	refresh bgp { all \| ip-address \| group group-name \| external \| internal } { export \| import }	Required
		Enter system view	system-view	—
		Enter BGP view	bgp as-number	—
Clear the direct EBGP session on any interface that becomes down			ebgp-interface-sensitive	Optional The function is enabled by default
Perform MD5 authentication when establishing a TCP connection			peer { group-name \| ip-address } password { cipher \| simple } password	Optional Not performed by default
Configure the number of BGP load balanced routes			balance number	Optional Load balancing is not enabled by default.

Caution:

l The maximum keepalive interval should be 1/3 of the holdtime and no less than 1 second. The holdtime is no less than 3 seconds unless it is set to 0.

l The intervals set with the peer timer command are preferred to those set with the timer command.

l Use of the peer keep-all-routes command saves all routing updates from the peer regardless of whether the filtering policy is configured. The system uses these updates to rebuild the routing table after a soft reset is triggered.

l Performing BGP soft reset can refresh the routing table and apply the new policy without tearing down BGP sessions.

l BGP soft reset requires all routers in the network have the route-refresh capability. If not, you need use the peer keep-all-routes command to keep all routing information from a BGP peer to perform soft reset.

l Configured in BGP view, MD5 authentication also applies to the MP-BGP VPNv4 extension, because the same TCP connection is used.

1.7 Configuring a Large Scale BGP Network

In a large-scale BGP network, configuration and maintenance become difficult due to so many peers. In this case, configuring peer groups makes management easier and improves route distribution efficiency. Peer group includes IBGP peer group, where peers belong to the same AS, and EBGP peer group, where peers belong to different ASs. If peers in an EBGP group belong to the same external AS, the EBGP peer group is a pure EBGP peer group, and if not, a mixed EBGP peer group.

Configuring a BGP community can also help simplify routing policy management, and a community has much larger management range than a peer group by controlling routing policies of multiple BGP routers.

To guarantee connectivity between IBGP peers, you need to make them fully meshed, but it becomes unpractical when there are too many IBGP peers. Using a route reflector or confederation can solve it. In a large-scale AS, both of them can be used.

1.7.1 Configuration Prerequisites

Before configuring this task, you have made network layer accessible on peering nodes.

1.7.2 Configuring BGP Peer Groups

Follow these steps to configure a BGP peer group:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter BGP view		bgp as-number	—
Configure an IBGP peer group	Create an IBGP peer group	group group-name [ internal ]	Optional You can add multiple peers into the group. The system will create these peers automatically and specify the local AS number as their AS in BGP view.
Configure an IBGP peer group	Add a peer into the IBGP peer group	peer ip-address group group-name [ as-number as-number ]
Configure a pure EBGP peer group	Create an EBGP peer group	group group-name external	Optional You can add multiple peers into the group. The system will create these peers automatically and specify the local AS number as their AS in BGP view.
	Specify the AS number for the group	peer group-name as-number as-number
	Add a peer into the group	peer ip-address group group-name [ as-number as-number ]
Configure a mixed EBGP peer group	Create an EBGP peer group	group group-name external	Optional You can add multiple peers into the group.
	Specify a peer and the AS number for the peer respectively	peer ip-address as-number as-number
	Add a peer into the group	peer ip-address group group-name [ as-number as-number ]

Caution:

l You need not specify the AS number when creating an IBGP peer group.

l If there are peers in a peer group, you can neither change the AS number of the group nor use the undo command to remove the AS number

l You need to specify the AS number for each peer in a mixed EBGP peer group respectively.

1.7.3 Configuring BGP Community

Follow these steps to configure BGP community:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter BGP view		bgp as-number	—
Advertise the community attribute to a peer/peer group	Advertise the community attribute to a peer/peer group	peer { group-name \| ip-address } advertise-community	Required Not configured by default
Advertise the community attribute to a peer/peer group	Advertise the extended community attribute to a peer/peer group	peer { group-name \| ip-address } advertise-ext-community	Required Not configured by default
Apply a routing policy to routes advertised to a peer/peer group		peer { group-name \| ip-address } route-policy route-policy-name export	Required Not configured by default

Caution:

l When configuring BGP community, you need to configure a routing policy to define the community attribute, and apply the routing policy to route advertisement.

l For routing policy configuration, refer to Routing Policy Configuration.

1.7.4 Configuring a BGP Route Reflector

Follow these steps to configure a BGP route reflector:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter BGP view	bgp as-number	—
Configure the router as a route reflector and specify a peer/peer group as its client	peer { group-name \| ip-address } reflect-client	Required Not configured by default
Enable route reflection between clients	reflect between-clients	Optional Enabled by default
Configure the cluster ID of the route reflector	reflector cluster-id cluster-id	Optional By default, a route reflector uses its router ID as the cluster ID

Caution:

l In general, it is not required to make clients of a route reflector fully meshed. The route reflector forwards routing information between clients. If clients are fully meshed, you can disable route reflection between clients to reduce routing costs.

l In general, a cluster has only one route reflector, and the router ID is used to identify the cluster. You can configure multiple route reflectors to improve network stability. In this case, you need to specify the same cluster ID for these route reflectors to avoid routing loops.

1.7.5 Configuring a BGP Confederation

Follow these steps to configure a BGP confederation:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter BGP view		bgp as-number	—
Configure a BGP confederation	Configure a confederation ID	confederation id as-number	Required Not configured by default
Configure a BGP confederation	Specify sub ASs contained in the confederation	confederation peer-as as-number-list	Required Not configured by default
Enable compatibility with AS confederation not compliant with RFC 3065		confederation nonstandard	Optional By default, a confederation complies with RFC 3065.

Caution:

l A confederation contains 32 sub ASs at most. The as-number of a sub AS takes effect in the confederation only.

l If routers not compliant with RFC 3065 exist in the confederation, you can use the confederation nonstandard command to make the local router compatible with these routers.

1.8 Displaying and Maintaining BGP Configuration

1.8.1 Displaying BGP Configuration

To do…	Use the command…	Remarks
Display peer group information	display bgp group [ group-name ]	Available in any view
Display advertised BGP routing information	display bgp network
Display AS path information	display bgp paths [ as-regular-expression ]
Display BGP peer/peer group information	display bgp peer [ ip-address { log-info \| verbose } \| group-name log-info \| verbose ]
Display BGP routing information	display bgp routing-table [ ip-address [ { mask \| mask-length } [ longer-prefixes ] ] ]
Display routing information matching the AS path ACL	display bgp routing-table as-path-acl as-path-acl-number
Display BGP CIDR routing information	display bgp routing-table cidr
Display BGP routing information matching the specified BGP community	display bgp routing-table community [ aa:nn&<1-13> ] [ no-advertise \| no-export \| no-export-subconfed ]* [ whole-match ]
Display routing information matching a BGP community list	display bgp routing-table community-list { basic-community-list-number [ whole-match ] \| adv-community-list-number }&<1-16>
Display BGP dampened routing information	display bgp routing-table dampened
Display BGP dampening parameter information	display bgp routing-table dampening parameter
Display BGP routing information originating from different ASs	display bgp routing-table different-origin-as
Display BGP routing flap statistics	display bgp routing-table flap-info [ regular-expression as-regular-expression \| as-path-acl as-path-acl-number \| ip-address [ { mask \| mask-length } [ longer-match ] ] ]
Display routing information to or from a peer	display bgp routing-table peer ip-address { advertised-routes \| received-routes } [ network-address [ mask \| mask-length ] \| statistic ]
Display routing information matching a regular expression	display bgp routing-table regular-expression as-regular-expression
Display BGP routing statistics	display bgp routing-table statistic

1.8.2 Resetting BGP Connections

To do…	Use the command…	Remarks
Reset all BGP connections	reset bgp all	Available in user view
Reset the BGP connections to an AS	reset bgp as-number
Reset the BGP connection to a peer	reset bgp ip-address [ flap-info ]
Reset all EBGP connections	reset bgp external
Reset the BGP connections to a peer group	reset bgp group group-name
Reset all IBGP connections	reset bgp internal
Reset all IPv4 unicast BGP connections	reset bgp ipv4 all

1.8.3 Clearing BGP Information

To do…	Use the command…	Remarks
Clear dampening routing information and release suppressed routes	reset bgp [ vpn-instance vpn-instance-name ] dampening [ network-address [ mask \| mask-length ] ]	Available in user view
Clear route flap information	reset bgp [ vpn-instance vpn-instance-name ] flap-info { regexp as-path-regexp \| as-path-acl as-path-acl-number \| ip-address [ mask \| mask-length ] }	Available in user view

1.9 BGP Configuration Examples

1.9.1 BGP Basic Configuration

I. Network requirements

In the following figure are all BGP switches. Between Switch A and Switch B is an EBGP connection. Switch B, Switch C and Switch D are IBGP fully meshed.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	8.1.1.1/8	Switch D	Vlan-int400	9.1.1.2/24
	Vlan-int200	200.1.1.2/24		Vlan-int500	9.1.2.2/24
Switch B	Vlan-int400	9.1.1.1/24	Switch C	Vlan-int500	9.1.2.1/24
	Vlan-int200	200.1.1.1/24		Vlan-int300	9.1.3.2/24
	Vlan-int300	9.1.3.1/24

Figure 1-16 Network diagram for BGP basic configuration (on switches)

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted)

2) Configure IBGP connections

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp] router-id 2.2.2.2

[SwitchB-bgp] peer 9.1.1.2 as-number 65009

[SwitchB-bgp] peer 9.1.3.2 as-number 65009

[SwitchB-bgp] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp] router-id 3.3.3.3

[SwitchC-bgp] peer 9.1.3.1 as-number 65009

[SwitchC-bgp] peer 9.1.2.2 as-number 65009

[SwitchC-bgp] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 65009

[SwitchD-bgp] router-id 4.4.4.4

[SwitchD-bgp] peer 9.1.1.1 as-number 65009

[SwitchD-bgp] peer 9.1.2.1 as-number 65009

[SwitchD-bgp] quit

3) Configure the EBGP connection

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] peer 200.1.1.1 as-number 65009

# Advertise network 8.0.0.0/8 to the BGP routing table.

[SwitchA-bgp] network 8.0.0.0

[SwitchA-bgp] quit

# Configure Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp] peer 200.1.1.2 as-number 65008

[SwitchB-bgp] quit

# Display peer information on Switch B.

[SwitchB] display bgp peer

BGP local router ID : 2.2.2.2

Local AS number : 65009

Total number of peers : 3 Peers in established state : 3

Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

9.1.1.2 4 65009 56 56 0 0 00:40:54 Established

9.1.3.2 4 65009 49 62 0 0 00:44:58 Established

200.1.1.2 4 65008 49 65 0 1 00:44:03 Established

You can find Switch B has established BGP connections to other routers.

# Display BGP routing table information on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 0.0.0.0 0 0 i

# Display BGP routing table information on Switch B.

[SwitchB] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 200.1.1.2 0 0 65008i

# Display routing table information on Switch C.

[SwitchC] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

i 8.0.0.0 200.1.1.2 0 100 0 65008i

& Note:

From the above outputs, you can find Switch A learned no route to AS 65009, and Switch C learned network 8.0.0.0 but the next hop 200.1.1.2 is unreachable, thus the route is invalid.

4) Redistribute direct routes

# Configure Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp] import-route direct

# Display BGP routing table information on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 7

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009?

*> 9.1.1.2/32 200.1.1.1 0 0 65009?

*> 9.1.3.0/24 200.1.1.1 0 0 65009?

*> 9.1.3.2/32 200.1.1.1 0 0 65009?

* 200.1.1.0 200.1.1.1 0 0 65009?

* 200.1.1.2/32 200.1.1.1 0 0 65009?

# Display BGP routing table information on Switch C.

[SwitchC] display bgp routing-table

Total Number of Routes: 7

BGP Local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 8.0.0.0 200.1.1.2 0 100 0 65008i

*>i 9.1.1.0/24 9.1.3.1 0 100 0 ?

*>i 9.1.1.2/32 9.1.3.1 0 100 0 ?

* i 9.1.3.0/24 9.1.3.1 0 100 0 ?

* i 9.1.3.2/32 9.1.3.1 0 100 0 ?

*>i 200.1.1.0 9.1.3.1 0 100 0 ?

*>i 200.1.1.2/32 9.1.3.1 0 100 0 ?

You can find the route 8.0.0.0 becomes valid with the next hop being Switch A.

# Ping 8.1.1.1 on Switch C.

[SwitchC] ping 8.1.1.1

PING 8.1.1.1: 56 data bytes, press CTRL_C to break

Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=254 time=31 ms

Reply from 8.1.1.1: bytes=56 Sequence=2 ttl=254 time=47 ms

Reply from 8.1.1.1: bytes=56 Sequence=3 ttl=254 time=31 ms

Reply from 8.1.1.1: bytes=56 Sequence=4 ttl=254 time=16 ms

Reply from 8.1.1.1: bytes=56 Sequence=5 ttl=254 time=31 ms

--- 8.1.1.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 16/31/47 ms

1.9.2 BGP and IGP Interaction Configuration

I. Network requirements

As shown below, OSPF is used as the IGP protocol in AS 65009, where Switch C is a non-BGP switch. Between Switch A and Switch B is an EBGP connection.

II. Network diagram

Figure 1-17 Network diagram for BGP and IGP interaction

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted).

2) Configure OSPF (omitted).

3) Configure the EBGP connection.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] peer 3.1.1.1 as-number 65009

# Advertise network 8.1.1.0/24 to the BGP routing table.

[SwitchA-bgp] network 8.1.1.0 24

[SwitchA-bgp] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp] peer 3.1.1.2 as-number 65008

[SwitchB-bgp] quit

4) Configure BGP and IGP interaction

# Configure BGP to redistribute routes from OSPF on Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp] import-route ospf 1

[SwitchB-bgp] quit

# Display routing table information on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 3

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.1.1.0/24 3.1.1.1 0 0 65009?

*> 9.1.2.0/24 3.1.1.1 2 0 65009?

# Configure OSPF to redistribute routes from BGP on Switch B.

[SwitchB] ospf

[SwitchB-ospf-1] import-route bgp

[SwitchB-ospf-1] quit

# Display routing table information on Switch C.

<SwitchC> display ip routing-table

Routing Tables: Public

Destinations : 7 Routes : 7

Destination/Mask Proto Pre Cost NextHop Interface

8.1.1.0/24 O_ASE 150 1 9.1.1.1 Vlan300

9.1.1.0/24 Direct 0 0 9.1.1.2 Vlan300

9.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

9.1.2.0/24 Direct 0 0 9.1.2.1 Vlan400

9.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

5) Configure route automatic summarization

# Configure route automatic summarization on Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp] summary automatic

# Display BGP routing table information on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 2

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.0.0.0 3.1.1.1 0 65009?

# Use ping for verification.

[SwitchA] ping -a 8.1.1.1 9.1.2.1

PING 9.1.2.1: 56 data bytes, press CTRL_C to break

Reply from 9.1.2.1: bytes=56 Sequence=1 ttl=254 time=15 ms

Reply from 9.1.2.1: bytes=56 Sequence=2 ttl=254 time=31 ms

Reply from 9.1.2.1: bytes=56 Sequence=3 ttl=254 time=47 ms

Reply from 9.1.2.1: bytes=56 Sequence=4 ttl=254 time=46 ms

Reply from 9.1.2.1: bytes=56 Sequence=5 ttl=254 time=47 ms

--- 9.1.2.1 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 15/37/47 ms

1.9.3 BGP Load Balancing and MED Attribute Configuration

I. Network requirements

l Configure BGP on all switches; Switch A is in AS 65008, Switch B and C in AS 65009.

l Between Switch A and B, Switch A and C are EBGP connections, and IBGP runs between Switch B and C.

II. Network diagram

Figure 1-18 Network diagram for BGP path selection configuration

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted).

2) Configure BGP connections.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65008

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] peer 200.1.1.1 as-number 65009

[SwitchA-bgp] peer 200.1.2.1 as-number 65009

# Advertise route 8.0.0.0/8 to BGP routing table.

[SwitchA-bgp] network 8.0.0.0 255.0.0.0

[SwitchA-bgp] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65009

[SwitchB-bgp] router-id 2.2.2.2

[SwitchB-bgp] peer 200.1.1.2 as-number 65008

[SwitchB-bgp] peer 9.1.1.2 as-number 65009

[SwitchB-bgp] network 9.1.1.0 255.255.255.0

[SwitchB-bgp] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65009

[SwitchC-bgp] router-id 3.3.3.3

[SwitchC-bgp] peer 200.1.2.2 as-number 65008

[SwitchC-bgp] peer 9.1.1.1 as-number 65009

[SwitchC-bgp] network 9.1.1.0 255.255.255.0

[SwitchC-bgp] quit

# Display the routing table on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 3

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i

* 200.1.2.1 0 0 65009i

Two routes to 9.1.1.0/24 are available, and the one with the next hop being 200.1.1.1 is the optimal because the ID of Switch B is smaller.

3) Configure loading balancing

# Configure Switch A.

[SwitchA] bgp 65008

[SwitchA-bgp] balance 2

[SwitchA-bgp] quit

# Display the routing table on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 3

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i

*> 200.1.2.1 0 0 65009i

The route 9.1.1.0/24 has two next hops 200.1.1.1 and 200.1.2.1, and both are the optimal.

4) Configure MED

# Configure the default MED of Switch B.

[SwitchB] bgp 65009

[SwitchB-bgp] default med 100

# Display the routing table on Switch A.

[SwitchA] display bgp routing-table

Total Number of Routes: 3

BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.2.1 0 0 65009i

* 200.1.1.1 100 0 65009i

From the above information, you can find the route with the next hop 200.1.2.1 is the best route, because its MED (0) is smaller than the MED (100) of the other route with the next hop 200.1.1.1 (Switch B).

1.9.4 BGP Community Configuration

I. Network requirements

Switch B establishes EBGP connections with Switch A and C. Configure No_Export community attribute on Switch A to make routes from AS 10 not advertised by AS 20 to any other AS.

II. Network diagram

Figure 1-19 Network diagram for BGP community configuration (on switches)

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted).

2) Configure EBGP

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 10

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] peer 200.1.2.2 as-number 20

[SwitchA-bgp] network 9.1.1.0 255.255.255.0

[SwitchA-bgp] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 20

[SwitchB-bgp] router-id 2.2.2.2

[SwitchB-bgp] peer 200.1.2.1 as-number 10

[SwitchB-bgp] peer 200.1.3.2 as-number 30

[SwitchB-bgp] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 30

[SwitchC-bgp] router-id 3.3.3.3

[SwitchC-bgp] peer 200.1.3.1 as-number 20

[SwitchC-bgp] quit

# Display the BGP routing table on Switch B.

[SwitchB] display bgp routing-table 9.1.1.0

BGP local router ID : 2.2.2.2

Local AS number : 20

Paths: 1 available, 1 best

BGP routing table entry information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)

Original nexthop: 200.1.2.1

AS-path : 10

Origin : igp

Attribute value : MED 0, pref-val 0, pre 255

State : valid, external, best,

Advertised to such 1 peers:

200.1.3.2

Switch B advertised routes to Switch C in AS 30.

# Display the routing table on Switch C.

[SwitchC] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 9.1.1.0/24 200.1.3.1 0 20 10i

Switch C learned route 9.1.1.0/24 from Switch B.

3) Configure BGP community

# Configure a routing policy

[SwitchA] route-policy comm_policy permit node 0

[SwitchA-route-policy] apply community no-export

[SwitchA-route-policy] quit

# Apply the routing policy

[SwitchA] bgp 10

[SwitchA-bgp] peer 200.1.2.2 route-policy comm_policy export

[SwitchA-bgp] peer 200.1.2.2 advertise-community

# Display the routing table on Switch B.

[SwitchB] display bgp routing-table 9.1.1.0

BGP local router ID : 2.2.2.2

Local AS number : 20

Paths: 1 available, 1 best

BGP routing table entry information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)

Original nexthop: 200.1.2.1

Community : No-Export

AS-path : 10

Origin : igp

Attribute value : MED 0, pref-val 0, pre 255

State : valid, external, best,

Not advertised to any peers yet

The route 9.1.1.0/24 is not available in the routing table of Switch C.

1.9.5 BGP Confederation Configuration

I. Network requirements

To reduce IBGP connections in AS 200, split it into three sub ASs, AS 65001, AS 65002 and AS 65003. Switches in AS 65001 are fully meshed.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	200.1.1.1/24	Switch D	Vlan-int100	10.1.3.2/24
	Vlan-int200	10.1.1.1/24		Vlan-int200	10.1.5.1/24
	Vlan-int300	10.1.2.1/24	Switch E	Vlan-int100	10.1.4.2/24
	Vlan-int400	10.1.3.1/24		Vlan-int200	10.1.5.2/24
	Vlan-int500	10.1.4.1/24	Switch F	Vlan-int100	9.1.1.1/24
Switch B	Vlan-int100	10.1.1.2/24		Vlan-int200	200.1.1.2/24
Switch C	Vlan-int100	10.1.2.2/24

Figure 1-20 Network diagram for BGP confederation configuration (on switches)

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted).

2) Configure BGP confederation.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 65001

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] confederation id 200

[SwitchA-bgp] confederation peer-as 65002 65003

[SwitchA-bgp] peer 10.1.1.2 as-number 65002

[SwitchA-bgp] peer 10.1.1.2 next-hop-local

[SwitchA-bgp] peer 10.1.2.2 as-number 65003

[SwitchA-bgp] peer 10.1.2.2 next-hop-local

[SwitchA-bgp] quit

# Configure Switch B.

<SwitchB> system-view

[SwitchB] bgp 65002

[SwitchB-bgp] router-id 2.2.2.2

[SwitchB-bgp] confederation id 200

[SwitchB-bgp] confederation peer-as 65001 65003

[SwitchB-bgp] peer 10.1.1.1 as-number 65001

[SwitchB-bgp] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 65003

[SwitchC-bgp] router-id 3.3.3.3

[SwitchC-bgp] confederation id 200

[SwitchC-bgp] confederation peer-as 65001 65002

[SwitchC-bgp] peer 10.1.2.1 as-number 65001

[SwitchC-bgp] quit

3) Configure IBGP connections in AS 65001.

# Configure Switch A.

[SwitchA] bgp 65001

[SwitchA-bgp] peer 10.1.3.2 as-number 65001

[SwitchA-bgp] peer 10.1.3.2 next-hop-local

[SwitchA-bgp] peer 10.1.4.2 as-number 65001

[SwitchA-bgp] peer 10.1.4.2 next-hop-local

[SwitchA-bgp] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 65001

[SwitchD-bgp] router-id 4.4.4.4

[SwitchD-bgp] confederation id 200

[SwitchD-bgp] peer 10.1.3.1 as-number 65001

[SwitchD-bgp] peer 10.1.5.2 as-number 65001

[SwitchD-bgp] quit

# Configure Switch E.

<SwitchE> system-view

[SwitchE] bgp 65001

[SwitchE-bgp] router-id 5.5.5.5

[SwitchE-bgp] confederation id 200

[SwitchE-bgp] peer 10.1.4.1 as-number 65001

[SwitchE-bgp] peer 10.1.5.1 as-number 65001

[SwitchE-bgp] quit

4) Configure the EBGP connection between AS 100 and AS 200.

# Configure Switch A.

[SwitchA] bgp 65001

[SwitchA-bgp] peer 200.1.1.2 as-number 100

[SwitchA-bgp] quit

# Configure Switch F.

<SwitchF> system-view

[SwitchF] bgp 100

[SwitchF-bgp] router-id 6.6.6.6

[SwitchF-bgp] peer 200.1.1.1 as-number 200

[SwitchF-bgp] network 9.1.1.0 255.255.255.0

[SwitchF-bgp] quit

5) Verify above configuration.

# Display the routing table of Switch B.

[SwitchB] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 9.1.1.0/24 10.1.1.1 0 100 0 (65001) 100i

[SwitchB] display bgp routing-table 9.1.1.0

BGP local router ID : 2.2.2.2

Local AS number : 65002

Paths: 1 available, 1 best

BGP routing table entry information of 9.1.1.0/24:

From : 10.1.1.1 (1.1.1.1)

Relay Nexthop : 0.0.0.0

Original nexthop: 10.1.1.1

AS-path : (65001) 100

Origin : igp

Attribute value : MED 0, localpref 100, pref-val 0, pre 255

State : valid, external-confed, best,

Not advertised to any peers yet

# Display the BGP routing table on Switch D.

[SwitchD] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 4.4.4.4

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i

[SwitchD] display bgp routing-table 9.1.1.0

BGP local router ID : 4.4.4.4

Local AS number : 65001

Paths: 1 available, 1 best

BGP routing table entry information of 9.1.1.0/24:

From : 10.1.3.1 (1.1.1.1)

Relay Nexthop : 0.0.0.0

Original nexthop: 10.1.3.1

AS-path : 100

Origin : igp

Attribute value : MED 0, localpref 100, pref-val 0, pre 255

State : valid, internal, best,

Not advertised to any peers yet

1.9.6 BGP Route Reflector Configuration

I. Network requirements

In the following figure, all switches run BGP.

l Between Switch A and Switch B is an EBGP connection, between Switch C and Switch B, Switch C and Switch D are IBGP connections.

l Switch C is a route reflector with clients Switch B and D.

l Switch D can learn route 1.0.0.0/8 from Switch C.

II. Network diagram

Figure 1-21 Network diagram for BGP route reflector configuration

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted)

2) Configure BGP connections

# Configure Switch A,

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp] router-id 1.1.1.1

[SwitchA-bgp] peer 192.1.1.2 as-number 200

# Advertise network 1.0.0.0/8 to the BGP routing table.

[SwitchA-bgp] network 1.0.0.0

[SwitchA-bgp] quit

# Configure Switch B

<SwitchB> system-view.

[SwitchB] bgp 200

[SwitchB-bgp] router-id 2.2.2.2

[SwitchB-bgp] peer 192.1.1.1 as-number 100

[SwitchB-bgp] peer 193.1.1.1 as-number 200

[SwitchB-bgp] peer 193.1.1.1 next-hop-local

[SwitchB-bgp] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] bgp 200

[SwitchC-bgp] router-id 3.3.3.3

[SwitchC-bgp] peer 193.1.1.2 as-number 200

[SwitchC-bgp] peer 194.1.1.2 as-number 200

[SwitchC-bgp] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp] router-id 4.4.4.4

[SwitchD-bgp] peer 194.1.1.1 as-number 200

[SwitchD-bgp] quit

3) Configure the route reflector.

# Configure Switch C.

[SwitchC] bgp 200

[SwitchC-bgp] peer 193.1.1.2 reflect-client

[SwitchC-bgp] peer 194.1.1.2 reflect-client

[SwitchC-bgp] quit

4) Verify the above configuration

# Display the BGP routing table of Switch B.

[SwitchB] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 200.1.2.2

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*> 1.0.0.0 192.1.1.1 0 0 100i

# Display the BGP routing table of Switch D.

[SwitchD] display bgp routing-table

Total Number of Routes: 1

BGP Local router ID is 200.1.2.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

i 1.0.0.0 193.1.1.2 0 100 0 100i

Switch D learned route 1.0.0.0/8 from Switch C.

1.9.7 BGP Path Selection Configuration

I. Network requirements

l In the figure below, all switches run BGP. Between Switch A and Switch B, Switch A and Switch C are EBGP connections. Between Switch B and Switch D, Switch D and Switch C are IBGP connections.

l OSPF is the IGP protocol in AS 200.

l Configure routing policies, making Switch D give priority to the route 1.0.0.0/8 from Switch C.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int101	1.0.0.0/8	Switch D	Vlan-int400	195.1.1.1/24
	Vlan-int100	192.1.1.1/24		Vlan-int300	194.1.1.1/24
	Vlan-int200	193.1.1.1/24	Switch C	Vlan-int400	195.1.1.2/24
Switch B	Vlan-int100	192.1.1.2/24		Vlan-int200	193.1.1.2/24
	Vlan-int300	194.1.1.2/24

Figure 1-22 Network diagram for BGP path selection configuration (on switches)

III. Configuration procedure

1) Configure IP addresses for interfaces (omitted).

2) Configure OSPF on Switch B, C, and D.

# Configure Switch B.

<SwitchB> system-view

[SwitchB] ospf

[SwitchB-ospf] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] ospf

[SwitchC-ospf] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

# Configure Switch D.

<SwitchD> system-view

[SwitchD] ospf

[SwitchD-ospf] area 0

[SwitchD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255

[SwitchD-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255

[SwitchD-ospf-1-area-0.0.0.0] quit

[SwitchD-ospf-1] quit

3) Configure BGP connections.

# Configure Switch A.

<SwitchA> system-view

[SwitchA] bgp 100

[SwitchA-bgp] peer 192.1.1.2 as-number 200

[SwitchA-bgp] peer 193.1.1.2 as-number 200

# Advertise network 1.0.0.0/8 to the BGP routing table of Switch A.

[SwitchA-bgp] network 1.0.0.0 8

[SwitchA-bgp] quit

# Configure Switch B.

[SwitchB] bgp 200

[SwitchB-bgp] peer 192.1.1.1 as-number 100

[SwitchB-bgp] peer 194.1.1.1 as-number 200

[SwitchB-bgp] quit

# Configure Switch C.

[SwitchC] bgp 200

[SwitchC-bgp] peer 193.1.1.1 as-number 100

[SwitchC-bgp] peer 195.1.1.1 as-number 200

[SwitchC-bgp] quit

# Configure Switch D.

[SwitchD] bgp 200

[SwitchD-bgp] peer 194.1.1.2 as-number 200

[SwitchD-bgp] peer 195.1.1.2 as-number 200

[SwitchD-bgp] quit

4) Configure attributes for route 1.0.0.0/8, making Switch D give priority to the route learned from Switch C.

l Configure a higher MED value for the route 1.0.0.0/8 advertised from Switch A to peer 192.1.1.2.

# Define an ACL numbered 2000 to permit route 1.0.0.0/8.

[SwitchA] acl number 2000

[SwitchA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255

[SwitchA-acl-basic-2000] quit

# Define two routing policies, apply_med_50, which sets the MED for route 1.0.0.0/8 to 50, and apply_med_100, which sets the MED for route 1.0.0.0/8 to 100.

[SwitchA] route-policy apply_med_50 permit node 10

[SwitchA-route-policy] if-match acl 2000

[SwitchA-route-policy] apply cost 50

[SwitchA-route-policy] quit

[SwitchA] route-policy apply_med_100 permit node 10

[SwitchA-route-policy] if-match acl 2000

[SwitchA-route-policy] apply cost 100

[SwitchA-route-policy] quit

# Apply routing policy apply_med_50 to the route advertised to peer 193.1.1.2 (Switch C), and apply_med_100 to the route advertised to peer 192.1.1.2 (Switch B).

[SwitchA] bgp 100

[SwitchA-bgp] peer 193.1.1.2 route-policy apply_med_50 export

[SwitchA-bgp] peer 192.1.1.2 route-policy apply_med_100 export

[SwitchA-bgp] quit

# Display the BGP routing table of Switch D.

[SwitchD] display bgp routing-table

Total Number of Routes: 2

BGP Local router ID is 194.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 1.0.0.0 193.1.1.1 50 100 0 100i

* i 192.1.1.1 100 100 0 100i

You can find route 1.0.0.0/8 learned from Switch C is the optimal.

l Configure different local preferences on Switch B and C for route 1.0.0.0/8, making Switch D give priority to the route from Switch C.

# Define an ACL numbered 2000 on Router C, permitting route 1.0.0.0/8.

[SwitchC] acl number 2000

[SwitchC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255

[SwitchC-acl-basic-2000] quit

# Configure a routing policy named localpref on Switch C, set the local preference of route 1.0.0.0/8 to 200 (the default is 100).

[SwitchC] route-policy localpref permit node 10

[SwitchC-route-policy] if-match acl 2000

[SwitchC-route-policy] apply local-preference 200

[SwitchC-route-policy] quit

# Apply the routing policy localpref to routes from peer 193.1.1.1.

[SwitchC] bgp 200

[SwitchC-bgp] peer 193.1.1.1 route-policy localpref import

[SwitchC-bgp] quit

# Display the routing table on Switch D.

[SwitchD] display bgp routing-table

Total Number of Routes: 2

BGP Local router ID is 194.1.1.1

Status codes: * - valid, > - best, d - damped,

h - history, i - internal, s - suppressed, S - Stale

Origin : i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 1.0.0.0 193.1.1.1 0 200 0 100i

* i 192.1.1.1 0 100 0 100i

You can find route 1.0.0.0/8 learned from Switch C is the optimal.

1.10 Troubleshooting BGP Configuration

1.10.1 No BGP Peer Relationship Established

I. Symptom

Display BGP peer information using the display bgp peer command. The state of the connection to the peer cannot become established.

II. Analysis

To become BGP peers, any two routers need to establish a TCP session using port 179 and exchange open messages successfully.

III. Processing steps

1) Use the display current-configuration command to verify the peer’s AS number.

2) Use the display bgp peer command to verify the peer’s IP address.

3) If the loopback interface is used, check whether the peer connect-interface command is configured.

4) If the peer is a non-direct EBGP peer, check whether the peer ebgp-max-hop command is configured.

5) Check whether a route to the peer is available in the routing table.

6) Use the ping command to check connectivity.

7) Use the display tcp status command to check the TCP connection.

8) Check whether an ACL disabling TCP port 179 is configured.

H3C S9500 Operation Manual-Release2132[V2.03]-03 IP Routing Volume

Chapter 1 BGP Configuration

1.1 BGP Overview

I. Header

II. Open

III. Update

IV. Notification

V. Keepalive

VI. Route-refresh

I. Classification of path attributes

II. Usage of BGP path attributes

1.1.3 BGP Route Selection

I. Route selection rule

II. Route selection with BGP load balancing

III. BGP route advertisement rule

1.1.5 Settlements for Problems Caused by Large Scale BGP Networks

I. Route summarization

II. Route dampening

III. Peer group

IV. Community

V. Route reflector

VI. Confederation

I. Overview

II. MP-BGP extended attributes

III. Address family

1.2 BGP Configuration Task List

1.3 Configuring BGP Basic Functions

1.3.2 Configuration Procedure

1.4 Controlling Route Distribution and Reception

1.4.2 Configuring BGP Route Redistribution

1.4.3 Configuring BGP Route Summarization

1.4.4 Advertising a Default Route to a Peer or Peer Group

1.4.5 Configuring BGP Route Distribution Policy

1.4.6 Configuring BGP Route Reception Policy

1.4.7 Enabling BGP and IGP Route Synchronization

1.4.8 Configuring BGP Route Dampening

1.5 Configuring BGP Routing Attributes

1.5.2 Configuration Procedure

1.6 Tuning and Optimizing BGP Networks

1.6.2 Configuration Procedure

1.7 Configuring a Large Scale BGP Network

1.7.2 Configuring BGP Peer Groups

1.7.3 Configuring BGP Community

1.7.4 Configuring a BGP Route Reflector

1.7.5 Configuring a BGP Confederation

1.8 Displaying and Maintaining BGP Configuration

1.8.1 Displaying BGP Configuration

1.9 BGP Configuration Examples

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

1.9.5 BGP Confederation Configuration

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

1.10 Troubleshooting BGP Configuration

I. Symptom

II. Analysis

III. Processing steps

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help