- Table of Contents
-
- 06-Layer 3 - IP Routing Configuration Guide
- 00-Preface
- 01-IP Routing Basics
- 02-Static Routing Configuration
- 03-RIP Configuration
- 04-OSPF Configuration
- 05-IS-IS Configuration
- 06-BGP Configuration
- 07-Policy-Based Routing Configuration
- 08-IPv6 Static Routing Configuration
- 09-RIPng Configuration
- 10-OSPFv3 Configuration
- 11-IPv6 IS-IS Configuration
- 12-IPv6 BGP Configuration
- 13-IPv6 Policy-Based Routing Configuration
- 14-Routing Policy Configuration
- 15-QoS Policy Routing Configuration
- Related Documents
-
Title | Size | Download |
---|---|---|
06-BGP Configuration | 896.25 KB |
Contents
Settlements for problems in large scale BGP networks
Configuring BGP basic functions
Specifying the source interface for TCP connections
Allowing establishment of EBGP connection to an indirectly connected peer/peer group
Configuring BGP route redistribution
Enabling default route redistribution into BGP
Controlling route distribution and reception
Configuring BGP route summarization
Advertising a default route to a peer or peer group
Configuring BGP route distribution/reception filtering policies
Enabling BGP and IGP route synchronization
Limiting prefixes received from a peer/peer group
Configuring BGP route dampening
Configuring BGP route attributes
Specifying a preferred value for routes received
Configuring preferences for BGP routes
Configuring the default local preference
Configuring the next hop attribute
Configuring the AS-PATH attribute
Tuning and optimizing BGP networks
Configuring BGP keepalive interval and holdtime
Configuring the interval for sending the same update
Enabling the BGP ORF capability
Enabling 4-byte AS number suppression
Enabling quick EBGP session reestablishment
Enabling MD5 authentication for TCP connections
Configuring BGP load balancing
Forbiding session establishment with a peer or peer group
Configuring a large scale BGP network
Configuring a BGP route reflector
Configuring a BGP confederation
Enabling logging of peer state changes
Displaying and maintaining BGP
BGP basic configuration example
BGP and IGP synchronization configuration example
BGP load balancing configuration example
BGP community configuration example
BGP route reflector configuration example
BGP confederation configuration example
BGP path selection configuration example
BFD for BGP configuration example
BGP peer relationship not established
The Border Gateway Protocol (BGP) is a dynamic inter-AS Exterior Gateway Protocol.
|
NOTE: BGP refers to BGP-4 in this document. |
BGP overview
The three early BGP versions are BGP-1 (RFC 1105), BGP-2 (RFC 1163) and BGP-3 (RFC 1267). The current version in use is BGP-4 (RFC 4271), and is the Internet exterior gateway protocol.
BGP has the following characteristics:
· Focuses on the control of route propagation and the selection of optimal routes rather than the route discovery and calculation, which makes BGP, an exterior gateway protocol different from interior gateway protocols such as OSPF and RIP.
· Uses TCP to enhance reliability.
· Supports CIDR.
· Reduces bandwidth consumption by advertising only incremental updates and is applicable to advertising a great amount of routing information on the Internet.
· Eliminates routing loops completely by adding AS path information to BGP route advertisements
· Provides abundant policies to implement flexible route filtering and selection.
· Provides good scalability.
A router advertising BGP messages is called a “BGP speaker”. It establishes peer relationships with other BGP speakers to exchange routing information. 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 peers in the local AS.
To simplify configuration, multiple peers using an identical policy can be organized as a peer group.
BGP runs on a router in either of the following modes:
· IBGP (internal BGP)
· EBGP (external BGP)
BGP is called “IBGP” when it runs within an AS and is called “EBGP” when it runs between ASs.
Formats of BGP messages
Header
BGP has the following types of messages:
· Open
· Update
· Notification
· Keepalive
· Route-refresh
They have the same header.
Figure 1 BGP message header
· Marker—The 16-byte field is used to delimit BGP messages. The Marker must be all ones.
· Length—The 2-byte unsigned integer indicates the total length of the message.
· Type—This 1-byte 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, and the last one is defined in RFC2918.
Open
After a TCP connection is established, the first message sent by each side is an Open message for peer relationship establishment. An Open message contains the following fields:
Figure 2 BGP Open message format
· Version—This 1-byte unsigned integer indicates the protocol version number. The current BGP version is 4.
· My autonomous system—This 2-byte unsigned integer indicates the Autonomous System number of the sender.
· Hold time—When establishing a peer relationship, two parties negotiate an identical hold time. If no Keepalive or Update is received from a peer within the hold time, the BGP connection is considered down.
· BGP identifier—An IP address that identifies the BGP router.
· Opt Parm Len (Optional Parameters Length)—Length of optional parameters, which is set to 0 if no optional parameter is available.
· Optional parameters—Used for multiprotocol extensions, and other functions.
Update
The Update messages are used to exchange routing information between peers. It can advertise feasible routes or remove multiple unfeasible routes.
Figure 3 BGP Update message format
Each Update message can advertise a group of feasible routes with identical attributes, and the routes are contained in the Network Layer Reachability Information (NLRI) field. The Path Attributes field carries the attributes of these routes. Each Update message can also carry multiple withdrawn routes in the Withdrawn Routes field.
· Unfeasible routes length—The total length of the Withdrawn Routes field in bytes. A value of 0 indicates no route is withdrawn from service, nor is the Withdrawn Routes field present in this Update message.
· Withdrawn routes—This is a variable length field that contains a list of withdrawn IP prefixes.
· Total path attribute length—Total length of the Path Attributes field in bytes. A value of 0 indicates that no Network Layer Reachability Information field is present in this Update message.
· 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, and perform routing and protocol extensions.
· NLRI—Each feasible route is represented as <length, prefix>.
Notification
A Notification message is sent when an error is detected. The BGP connection is closed immediately after sending it.
Figure 4 BGP Notification message format
· Error code—Type of Notification.
· Error subcode—Specific information about the nature of the reported error.
· Data—Used to diagnose the reason for the Notification. The contents of the Data field depend on the Error Code and Error Subcode. Erroneous part of data is recorded. The Data field length is variable.
Keepalive
Keepalive messages are sent between peers to maintain connectivity. Its format contains only the message header.
Route-refresh
A Route-refresh message is sent to a peer to request resending of the specified address family routing information.
Figure 5 BGP Route-refresh message format
· AFI—Address family identifier.
· Res—Reserved. Set to 0.
· SAFI—Subsequent Address Family Identifier.
BGP path attributes
Classification of path attributes
BGP path attributes are a group of parameters encapsulated in the path attributes field of update messages. They give detailed route attributes information that can be used for route filtering and selection.
Path attributes fall into the following categories:
· Well-known mandatory—Must be recognized by all BGP routers and be included in every Update message. Routing information errors occur without this attribute.
· Well-known discretionary—Can be recognized by all BGP routers and optionally included in every Update message as needed.
· 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.
· 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 attribute is described in the following table.
Table 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 |
BGP path attributes
· ORIGIN
ORIGIN is a well-known mandatory attribute, which defines the origin of routing information (how a route became a BGP route). It involves the following types:
¡ IGP—Has the highest priority. Routes added to the BGP routing table using the network command have the IGP attribute.
¡ EGP—Has the second highest priority. Routes obtained via EGP have the EGP attribute.
¡ Incomplete—Has the lowest priority. The source of routes with this attribute is unknown, which does not mean such routes are unreachable. The routes redistributed from other routing protocols have the incomplete attribute.
· 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, so the receiver can determine ASs to route the message back. The number of the AS closest to the receiver’s AS is leftmost, as shown in Figure 6:
Figure 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 in order to meet special requirements. · The SR8800 check the AS_PATH attribute of EBGP routes rather than IBGP routes, and reject any EBGP route whose AS_PATH attribute contains the local AS number. |
The 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 Figure 6, the BGP router in AS50 gives priority to the route passing AS40 for sending data 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.
· NEXT_HOP
Different from IGP, the NEXT_HOP attribute may not be the IP address of a directly connected router. It involves three types of values, as shown in Figure 7.
¡ 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.
¡ 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.
¡ 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 of the equal-cost routes will be modified. For load-balancing information, see “BGP route selection.“
· MED (MULTI_EXIT_DISC)
The MED attribute is exchanged between two neighboring ASs, each of which does not advertise the attribute to any other AS.
Similar to 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 given that other conditions are the same. As shown in Figure 8, traffic from AS10 to AS20 travels through Router B that is selected according to MED.
Figure 8 MED attribute
In general, BGP compares MEDs of routes received from 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 received from different ASs. |
· LOCAL_PREF
¡ The LOCAL_PREF attribute is exchanged between IBGP peers only, and is 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 in Figure 9, traffic from AS20 to AS10 travels through Router C that is selected according to LOCAL_PREF.
Figure 9 LOCAL_PREF attribute
· COMMUNITY
The COMMUNITY attribute is a group of specific data. A route can carry one or more COMMUNITY attribute values (each of which is represented by a four-byte integer). The receiving router processes the route (for example, determining whether to advertise the route and the scope for advertising the route) based on the COMMUNITY attribute values. This simplifies routing policy usage and facilitates management and maintenance. Well-known community attributes involve:
¡ Internet—By default, all routes belong to the Internet community. Routes with this attribute can be advertised to all BGP peers.
¡ 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, see “Settlements for problems in large scale BGP networks.”
¡ No_Advertise—After received, routes with this attribute cannot be advertised to other BGP peers.
¡ No_Export_Subconfed—After received, routes with this attribute cannot be advertised out the local AS or other ASs in the local confederation.
BGP route selection
Route selection rules
BGP discards routes with unreachable NEXT_HOPs. If multiple routes to the same destination are available, BGP selects the best route in the following sequence:
1. The route with the highest Preferred_value
2. The route with the highest LOCAL_PREF
3. The route originated by the local router
4. The route with the shortest AS-PATH
5. The IGP, EGP, or Incomplete route in turn
6. The route with the lowest MED value
7. The route learned from EBGP, confederation, or IBGP in turn
8. The route with the smallest next hop metric
9. The route with the shortest CLUSTER_LIST
10. The route with the smallest ORIGINATOR_ID
11. The route advertised by the router with the smallest Router ID
12. The route advertised by the peer with the lowest IP address
|
NOTE: · 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 loops. · If load balancing is configured, the system selects available routes to implement load balancing. |
Route selection with BGP load balancing
The next hop of a BGP route may not be directly connected. One of the reasons is next hops in routing information exchanged between iBGPs are not modified. The BGP router needs to find the directly connected next hop via IGP. The matching route with the direct next hop is called the “recursive route”. The process of finding a recursive route is route recursion.
The system supports BGP load balancing based on route recursion. If multiple recursive routes to the same destination are load balanced (suppose three direct next hop addresses), BGP generates the same number of next hops to forward packets. BGP load balancing based on route recursion is always enabled by the system rather than configured using commands.
BGP differs from IGP in the implementation of load balancing in the following ways:
· IGP routing protocols such as RIP and OSPF compute metrics of routes, and then implement load balancing over routes with the same metric and to the same destination. The route selection criterion is metric.
· 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: · BGP implements load balancing only on routes that have the same AS_PATH, ORIGIN, LOCAL_PREF and MED. · BGP load balancing is applicable between EBGP peers, between IBGP peers and between confederations. · If multiple routes to the same destination are available, BGP selects a configurable number of routes for load balancing. |
Figure 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 installs both the two routes to its route table for load balancing. After that, Router C forwards to Router D and Router E the route that has AS_PATH unchanged but has NEXT_HOP changed to Router C; other BGP transitive attributes are those of the best route.
BGP route advertisement rules
The current BGP implementation supports the following route advertisement rules:
· When multiple feasible routes to a destination exist, the BGP speaker advertises only the best route to its peers.
· A BGP speaker advertises only routes that it uses.
· A BGP speaker advertises routes learned through EBGP to all BGP peers, including both EBGP and IBGP peers.
· A BGP speaker does not advertise routes from an IBGP peer to other IBGP peers.
· A BGP speaker advertises routes learned through IBGP to EBGP peers. If BGP and IGP synchronization is disabled, those routes are advertised to EBGP peers directly. If the feature is enabled, only after IGP advertises those routes, can BGP advertise the routes to EBGP peers.
· A BGP speaker advertises all routes to a newly connected peer.
IBGP and IGP synchronization
Routing information synchronization between IBGP and IGP avoids giving wrong directions to routers outside of the local AS.
If a non-BGP router works in an AS, it may discard a packet due to an unreachable destination. As shown in Figure 11, Router E has learned a route of 8.0.0.0/8 from Router D via BGP. Router E then sends a packet to 8.0.0.0/8 through Router D, which finds from its routing table that Router B is the next hop (configured using the peer next-hop-local command). Because Router D has learned the route to Router B via IGP, it forwards the packet to Router C through route recursion. Router C is not aware of the route 8.0.0.0/8, so it discards the packet.
Figure 11 IBGP and IGP synchronization
For this example, if synchronization is enabled, and the route 8.0.0.0/24 received from Router B is available in its IGP routing table, Router D adds the route into its BGP routing table and advertises the route to the EBGP peer.
You can disable the synchronization feature in the following situations:
· The local AS is not a transitive AS (AS20 is a transitive AS in the above figure).
· Routers in the local AS are IBGP fully meshed.
Settlements for problems in large scale BGP networks
Route summarization
Route summarization can reduce the routing table size on a large network, and allow BGP routers to advertise only summary routes rather than more specific routes.
The system supports both manual and automatic route summarization. Manual route summarization allows you to determine the attribute of a summary route and whether to advertise the route.
Route dampening
BGP route dampening solves the issue of route instability such as route flaps—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. Frequent route flaps consume large bandwidth and CPU resources, which could affect network operation.
In most cases, BGP is used in complex networks, where route changes are more frequent. To solve the problem caused by route flaps, BGP route dampening is used 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, 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 from being added into the routing table or being advertised to other BGP peers.
The penalty value of the suppressed route will decrease 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.
Figure 12 BGP route dampening
Peer group
You can organize BGP peers with the same attributes into a group to simplify their configurations.
When a peer joins the peer group, the peer obtains the same configuration as the peer group. If the configuration of the peer group is changed, the configuration of group members is changed.
When a peer is added into a peer group, the peer has the same route update policy as the peer group to improve route distribution efficiency.
|
NOTE: If an option is configured for both a peer and its peer group, the last configuration takes effect. |
Community
A peer group provides each peer in it with the same policy. A community provides a group of BGP routers in several ASs with the same policy. Community is a path attribute 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 well-known community attributes, you can define extended community attributes by using a community list to define a routing policy.
Route reflector
IBGP peers should be fully meshed to maintain connectivity. If n routers exist in an AS, the number of IBGP connections is n (n-1)/2, and large amounts of network and CPU resources will be consumed.
Using route reflectors can solve this 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 routing information between clients, and BGP sessions between clients need not be established.
A router that is neither a route reflector nor a client is a non-client, which has to establish BGP sessions to the route reflector and other non-clients, as shown in Figure 13.
Figure 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 a single point of failure, as shown in the following figure. The configured route reflectors must have the same Cluster_ID in order to avoid routing loops.
Figure 14 Network diagram for route reflectors
When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it consumes more bandwidth resources. You can use related commands to disable route reflection.
|
NOTE: After route reflection is disabled between clients, routes can still be reflected between a client and a non-client. |
Confederation
Confederation is another method to manage growing IBGP connections in ASs. It splits an AS into multiple sub-ASs. In each sub-AS, IBGP peers are fully meshed, and intra-confederation EBGP connections are established between sub-ASs, as shown in Figure 15:
Figure 15 Confederation network diagram
A non-confederation BGP speaker is not required to 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 must reconfigure your routers, and the topology will be changed.
In large-scale BGP networks, both route reflector and confederation can be used.
BGP GR
Graceful Restart (GR) ensures the continuity of packet forwarding when BGP restarts or an active/standby switchover occurs:
· GR Restarter—Graceful restarting router. It must be GR capable.
· GR Helper—A neighbor of the GR Restarter. It helps the GR Restarter to complete the GR process.
1. To establish a BGP session with a peer, a BGP GR Restarter sends an Open message with GR capability to the peer.
2. Upon receipt of this message, the peer is aware that the sending router is capable of Graceful Restart, and sends an Open message with GR Capability to the GR Restarter to establish a GR session. If neither party has the GR capability, the session established between them will not be GR capable.
3. When an active/standby switchover occurs on a router that acts as the GR Restarter, sessions on it will go down. Then, GR capable peers will mark all routes associated with the GR Restarter as stale. However, during the configured GR Time, they still use these routes for packet forwarding.
4. After the restart is completed, the GR Restarter will reestablish GR sessions with its peers and send a new GR message notifying the completion of restart. Routing information is exchanged between them for the GR Restarter to create a new routing table and forwarding table and have stale routing information removed. Then the BGP routing convergence is complete.
MP-BGP
Overview
BGP-4 supports IPv4 unicasts, but does not support 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) in RFC 4760.
Routers supporting MP-BGP can communicate with routers not supporting MP-BGP.
MP-BGP extended attributes
In BGP-4, the attributes for IPv4 address format are NLRI, NEXT_HOP and AGGREGATOR (AGGREGATOR contains the IP address of the speaker generating the summary route). They 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 the following path attributes:
· MP_REACH_NLRI—Multiprotocol Reachable NLRI, for advertising feasible routes and next hops
· MP_UNREACH_NLRI—Multiprotocol Unreachable NLRI, for withdrawing unfeasible routes
These attributes are both optional non-transitive, so BGP speakers not supporting multi-protocol ignore the two attributes and do not forward them to its peers.
Address family
MP-BGP uses address families to differentiate network layer protocols. For address family values, see RFC 1700, Assigned Numbers. The system supports multiple MP-BGP extensions, including VPN extension and IPv6 extension. Different extensions are configured in respective address family view.
Protocols and standards
· RFC 1771, A Border Gateway Protocol 4 (BGP-4)
· RFC 2858, Multiprotocol Extensions for BGP-4
· RFC 3392, Capabilities Advertisement with BGP-4
· RFC 2918, Route Refresh Capability for BGP-4
· RFC 2439, BGP Route Flap Damping
· RFC 1997, BGP Communities Attribute
· RFC 2796, BGP Route Reflection
· RFC 3065, Autonomous System Confederations for BGP
· RFC 4271, A Border Gateway Protocol 4 (BGP-4)
· RFC 5291, Outbound Route Filtering Capability for BGP-4
· RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4
· draft-ietf-idr-restart-08, Graceful Restart Mechanism for BGP
BGP configuration task list
Complete the following tasks to configure BGP:
Task |
Remarks |
|
Required. |
||
Optional. |
||
Allowing establishment of EBGP connection to an indirectly connected peer/peer group |
Optional. |
|
Required. Use at least one approach. |
||
Optional. |
||
Optional. |
||
Configuring BGP route distribution/reception filtering policies |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
Configuring BGP basic functions
|
NOTE: · This section does not differentiate between BGP and MP-BGP. · Since BGP employs TCP, you must specify IP addresses of peers, which may not be neighboring routers. · Using logical links can also establish BGP peer relationships. · In general, IP addresses of loopback interfaces are used to improve stability of BGP connections. |
Configuration prerequisites
The neighboring nodes are accessible to each other at the network layer.
Creating a BGP connection
A router ID is the unique identifier of a BGP router in an AS.
· To ensure the uniqueness of a router ID and enhance network reliability, you can specify in BGP view the IP address of a local loopback interface as the router ID.
· If no router ID is specified in BGP view, the global router ID is used.
· If the global router ID is used and then it is removed, the system will select a new router ID.
· If the router ID is specified in BGP view, using the undo router-id command can make the system select a new router ID.
To create a BGP connection:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure a global router ID. |
router id router-id |
Optional. Not configured by default. If no global router ID is configured, the highest loopback interface IP address—if any—is used as the router ID. If no loopback interface IP address is available, the highest physical interface IP address is used, regardless of the interface status. |
3. Enable BGP and enter BGP view. |
bgp as-number |
Not enabled by default. |
4. Specify a router ID. |
router-id router-id |
Optional. By default, the global router ID is used. |
5. Specify a peer or a peer group and its AS number. |
peer { group-name | ip-address } as-number as-number |
Not specified by default. |
6. Enable the default use of IPv4 unicast address family for the peers that are established using the peer as-number command. |
default ipv4-unicast |
Optional. Enabled by default. |
7. Enable a peer. |
peer ip-address enable |
Optional. Enabled by default. |
8. Configure a description for a peer/peer group. |
peer { group-name | ip-address } description description-text |
Not configured by default. |
|
NOTE: · Since a router can reside in only one AS, the router can run only one BGP process. · You must create a peer group before configuring it. |
Specifying the source interface for TCP connections
BGP uses TCP as the transport layer protocol. By default, BGP uses the output interface of the optimal router to a peer as the source interface for establishing TCP connections to the peer. If a BGP router has multiple links to a peer, when the source interface fails, BGP has to reestablish TCP connections, causing network oscillation. To enhance stability of BGP connections, H3C recommends using a loopback interface as the source interface.
To specify the source interface of TCP connections:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. 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 |
By default, BGP uses the outbound interface of the best route to the BGP peer/peer group as the source interface for establishing a TCP connection to the peer/peer group. |
|
NOTE: To establish multiple BGP connections between two routers, you must specify the source interface for establishing TCP connections to each peer on the local router; otherwise, the local BGP router may fail to establish TCP connections to a peer when using the outbound interface of the best route to the peer as the source interface. |
Allowing establishment of EBGP connection to an indirectly connected peer/peer group
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.
To allow establishment of EBGP connection to an indirectly connected peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Allow the establishment of EBGP connection to an indirectly connected peer/peer group. |
peer { group-name | ip-address } ebgp-max-hop [ hop-count ] |
Optional Not allowed by default |
|
NOTE: The peer ebgp-max-hop command needs not be configured if the two EBGP peers are directly connected. |
Controlling route generation
Different from IGP, BGP focuses on route generation and advertisement control and optimal route selection.
Generating BGP routes can be done in the following ways:
· Configure BGP to advertise local networks.
· Configure BGP to redistribute routes from other routing protocols, including the default route.
Configuration prerequisites
BGP connections have been created.
Injecting a local network
In BGP view, you can inject a local network to allow BGP to advertise the network to BGP peers. The origin attribute of routes advertised in this way is IGP. You can also reference a routing policy to flexibly control route advertisement. The network to be injected must be available in the local IP routing table.
To inject a local network:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Inject a network to the BGP routing table. |
network ip-address [ mask | mask-length ] route-policy route-policy-name |
Optional Not injected by default |
Configuring BGP route redistribution
BGP does not find routes by itself. Rather, it redistributes routing information in the local AS from other routing protocols. During route redistribution, you can configure BGP to filter routing information from specific routing protocols.
The origin attribute of routes redistributed using the import-route command is Incomplete.
To configure BGP route redistribution:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable route redistribution from a routing protocol into BGP. |
import-route protocol [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ] |
Not enabled by default. The allow-direct keyword is available only when the specified routing protocol is OSPF. |
|
NOTE: Only active routes can be redistributed. You can use the display ip routing-table protocol command to display route state information. |
Enabling default route redistribution into BGP
Using the import-route command cannot redistribute a default route.
To enable default route redistribution into BGP:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable route redistribution from a routing protocol into BGP. |
import-route protocol [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ] |
Not redistributed by default. The allow-direct keyword is available only when the specified routing protocol is OSPF. |
4. Enable default route redistribution into BGP. |
default-route imported |
Optional. Not enabled by default. |
Controlling route distribution and reception
Configuration prerequisites
BGP connections have been created.
Configuring BGP route summarization
To reduce the routing table size on medium and large BGP networks, configure route summarization on BGP routers. BGP supports two summarization modes: automatic and manual. Manual summary routes have a higher priority than automatic ones.
Configuring automatic route summarization
After automatic route summarization is configured, BGP summarizes redistributed IGP subnets to advertise only natural networks. Routes injected with the network command cannot be summarized.
To configure automatic route summarization:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure automatic route summarization. |
summary automatic |
Not configured by default |
Configuring manual route summarization
By configuring manual route summarization, you can summarize both redistributed routes and routes injected using the network command and determine the mask length for a summary route as needed.
To configure BGP manual route summarization:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. 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 ]* |
Not configured by default |
Advertising a default route to a peer or peer group
After this task is configured, the BGP 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.
To advertise a default route to a peer or peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Advertise a default route to a peer or peer group. |
peer { group-name | ip-address } default-route-advertise [ route-policy route-policy-name ] |
Not advertised by default |
Configuring BGP route distribution/reception filtering policies
Configuration prerequisites
You must configure following filters as needed.
· ACL
· IP prefix list
· Routing policy
· AS-path ACL
For how to configure an ACL, see ACL and QoS Configuration Guide.
For how to configure an IP prefix list, routing policy, and AS-path ACL, see the chapter “Configuring routing policies.”
Configuring BGP route distribution filtering policies
To configure BGP route distribution filtering policies:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP route distribution filtering policies. |
·
Configure the filtering of redistributed
routes: ·
Reference a routing policy to filter advertisements
to a peer/peer group: ·
Reference an ACL to filter advertisements to a
peer/peer group: ·
Reference an AS path ACL to filter routing
information sent to a peer/peer group: ·
Reference an IP prefix list to filter routing
information sent to a peer/peer group: |
Configure at least one command. 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: 1. filter-policy export 2. peer filter-policy export 3. peer as-path-acl export 4. peer ip-prefix export 5. peer route-policy export Only routes passing the first policy can go to the next, and only routes passing all the configured policies can be advertised. |
Configuring BGP route reception filtering policies
Only routes permitted by the configured filtering policies can be installed into the local BGP routing table. The members of a peer group can have different route reception filtering policies from the peer group.
To configure BGP route reception filtering policies:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP route reception filtering policies. |
·
Filter incoming routes with an ACL or IP
prefix list: ·
Reference a routing policy to filter routes
from a peer/peer group: ·
Reference an ACL to filter routing information
from a peer/peer group: ·
Reference an AS path ACL to filter routing
information from a peer/peer group: ·
Reference an IP prefix list to filter routing
information from a peer/peer group: |
Configure at least one command. By default, no route reception filtering is configured. If several filtering policies are configured, they are applied in the following sequence: 1. filter-policy import 2. peer filter-policy import 3. peer as-path-acl import 4. peer ip-prefix import 5. peer route-policy import Only routes passing all the configured policies can be received. |
Enabling BGP and IGP route synchronization
By default, when a BGP router receives an IBGP route, it only checks the reachability of the route’s next hop before advertisement. With BGP and IGP synchronization enabled, the BGP router cannot advertise the IBGP route to EBGP peers unless the route is also available in the IGP routing table.
To enable BGP and IGP synchronization:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable synchronization between BGP and IGP. |
synchronization |
Not enabled by default |
Limiting prefixes received from a peer/peer group
To configure the maximum number of prefixes allowed to be received from a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the maximum number of prefixes allowed to be received from a peer/peer group. |
·
Apporach 1: ·
Apporach 2: ·
Apporach 3: |
Use one of the approaches. No limit is configured by default. If the specified maximum number is reached: · For approach 1, the router breaks down the BGP connection to the peer. · For approach 2, the router outputs alert information but does not break down the BGP connection to the peer. · For approach 3, the router breaks down the BGP connection to the peer and then reestablishes a BGP connection to the peer. |
Configuring BGP route dampening
By configuring BGP route dampening, you can suppress unstable routes from being added to the local routing table or being advertised to BGP peers.
To configure BGP route dampening:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP route dampening. |
dampening [ half-life-reachable half-life-unreachable reuse suppress ceiling | route-policy route-policy-name ] * |
Not configured by default |
Configuring a shortcut route
An EBGP route received has a priority of 255, lower than a local route. This task allows you to configure an EBGP route as a shortcut route that has the same priority as a local route and is more likely to become the optimal route.
To configure a shortcut route:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure a shortcut route. |
network ip-address [ mask | mask-length ] short-cut |
Optional. By default, an EBGP route received has a priority of 255. |
Configuring BGP route attributes
Configuration prerequisites
Create BGP connections.
|
CAUTION: · Using a routing policy can set preferences for routes matching it. Routes not matching it use the default preferences. · If other conditions are identical, the route with the smallest MED value is selected as the best external route. · Using the peer next-hop-local command can specify the router as the next hop for routes to 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. · In a “third party next hop" network—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. · 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. · You can specify a fake AS number to hide the real one as needed. The fake AS number applies to routes to EBGP peers only, that is, EBGP peers in other ASs can only find the fake AS number. · The peer substitute-as command is used only in specific networking environments. Inappropriate use of the command may cause routing loops. · 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/peer group, the routing policy sets the specified 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 specified in the routing policy is zero, the routes matching it will also use the value set with the peer { group-name | ip-address } preferred-value value command. For how to use a routing policy to set a preferred value, see the command peer { group-name | ip-address } route-policy route-policy-name { export | import } command and the apply preferred-value preferred-value command. |
Specifying a preferred value for routes received
By default, routes received from a peer have a preferred value of 0. Among multiple routes that have the same destination/mask and are learned from different peers, the one with the greatest preferred value is selected as the route to the destination.
To specify a preferred value for routes from a peer or peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Specify a preferred value for routes received from a peer or peer group. |
peer { group-name | ip-address } preferred-value value |
Optional. By default, the preferred value is 0. |
Configuring preferences for BGP routes
A router may run multiple routing protocols with each having a preference. If they find the same route, the route found by the routing protocol with the highest preference is selected.
This task allows you to configure preferences for external, internal, and local BGP routes, and reference a routing policy to set preferences for matching routes as needed.
To configure preferences for BGP routes:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure preferences for external, internal, local BGP routes. |
preference { external-preference internal-preference local-preference | route-policy route-policy-name } |
Optional. The default preferences of external, internal, and local BGP routes are 255, 255, and 130 respectively. |
Configuring the default local preference
The local preference 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 preference as the best route.
This task allows you to specify the default local preference for routes sent to IBGP peers.
To specify the default local preference:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the default local preference. |
default local-preference value |
Optional 100 by default |
Configuring the MED attribute
MED is used to determine the best route for traffic going into an AS. When a BGP router obtains from EBGP peers multiple routes to the same destination but with different next hops, it considers the route with the smallest MED value as the best route if other conditions are the same.
Configuring the default MED value
To configure the default MED value:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the default MED value. |
default med med-value |
Optional 0 by default |
Enabling the comparison of MED of routes from different ASs
To enable the comparison of MED of routes from different ASs:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable the comparison of MED of routes from different ASs. |
compare-different-as-med |
Not enabled by default |
Enabling the comparison of MED of routes from each AS
Route learning sequence may affect optimal route selection.
Figure 16 Route selection based on MED
As shown in Figure 16, Router D learns network 10.0.0.0 from both Router A and Router B. Because Router B has a smaller router ID, the route learned from it is optimal.
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.0.0.0 2.2.2.2 50 0 300e
* i 3.3.3.3 50 0 200e
When Router D learns network 10.0.0.0 from Router C which has a smaller router ID than Router B, the route from Router C becomes optimal.
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.0.0.0 1.1.1.1 60 0 200e
* i 10.0.0.0 2.2.2.2 50 0 300e
* i 3.3.3.3 50 0 200e
However, Router C and Router B reside in the same AS, and BGP will compare the MEDs of them. Since Router C has a greater MED, network 10.0.0.0 learned from it is not optimal.
You can configure the bestroute compare-med command on Router D. After that, Router D will put routes received from the same AS into a group. For the same group, the route with the lowest MED is selected. Then, it compares routes from different groups. This mechanism avoids the above-mentioned problem. The following output is the BGP routing table on Router D after the comparison of MED of routes from each AS is enabled. Network 10.0.0.0 learned from Router C is the optimal route.
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.0.0.0 3.3.3.3 50 0 200e
* i 10.0.0.0 2.2.2.2 50 0 300e
* i 1.1.1.1 60 0 200e
BGP load balancing cannot be implemented because load balanced routes must have the same AS-path attribute.
To enable the comparison of MED of routes from each AS:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable the comparison of MED of routes from each AS. |
bestroute compare-med |
Optional Not enabled by default |
Enabling the comparison of MED of routes from confederation peers
To enable the comparison of MED of routes from confederation peers:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable the comparison of MED of routes from confederation peers. |
bestroute med-confederation |
Optional Not enabled by default |
|
NOTE: The MED attributes of routes from confederation peers are not compared if their AS-path attributes contain AS numbers that do not belong to the confederation, such as these three routes: AS-path attributes of them are 65006 65009, 65007 65009 and 65008 65009, and MED values of them are 2, 3, and 1. Because the third route contains an AS number that does not belong to the confederation, the first route becomes the optimal route. |
Configuring the next hop attribute
By default, when advertising routes to an IBGP peer/peer group, a BGP router does not set itself as the next hop. However, to ensure a BGP peer can find the correct next hop in some cases, you need to configure the router as the next hop for routes sent to the peer.
For example, as shown in Figure 17, Router A and Router B establish an EBGP neighbor relationship, and Router B and Router C establish an IBGP neighbor relationship. When Router B advertises a network learned from Router A to Router C, if Router C has no route to IP address 1.1.1.1/24, you need to configure Router B to set itself as the next hop (3.1.1.1/24) for the route to be sent to Router C.
Figure 17 Next hop attribute configuration
If a BGP router has two peers on a common broadcast network, it does not set itself as the next hop for routes sent to an EBGP peer by default. As shown in Figure 18, Router A and Router B establish an EBGP neighbor relationship, and Router B and Router C establish an IBGP neighbor relationship. They are on the same broadcast network 1.1.1.0/24. When Router B sends EBGP routes to Router A, it does not set itself as the next hop by default. However, you can configure Router B to set it as the nexthop (1.1.1.2/24) for routes sent to Router A by using the peer next-hop-local command as needed.
Figure 18 Next hop attribute configuration
If you have configured BGP load balancing on a BGP router, the router will set it as the next hop for routes sent to an IBGP peer/peer group regardless of whether the peer next-hop-local command is configured.
To configure the next hop attribute:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Specify the router as the next hop of routes sent to a peer/peer group. |
peer { group-name | ip-address } next-hop-local |
Optional. By default, the router sets it as the next hop for routes sent to an EBGP peer/peer group, but does not set it as the next hop for routes sent to an IBGP peer/peer group. |
Configuring the AS-PATH attribute
Permitting local AS number to appear in routes from a peer/peer group
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.
To permit local AS number to appear in routes from a peer/peer group and specify the appearance times.
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Permit local AS number to appear in routes from a peer/peer group and specify the appearance times. |
peer { group-name | ip-address } allow-as-loop [ number ] |
Optional. By default, the local AS number is not allowed. |
Disabling BGP from considering AS_PATH during best route selection
To disable BGP from considering AS_PATH during best route selection:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Disable BGP from considering AS_PATH during best route selection. |
bestroute as-path-neglect |
Optional. By default, BGP considers AS_PATH during best route selection. |
Specifying a fake AS number for a peer/peer group
When Router A in AS 2 is moved to AS 3, you can configure Router A to specify a fake AS number of 2 for created connections to EBGP peers/peer groups. In this way, these EBGP peers still think Router A is in AS 2 and need not change their configurations. This feature ensures uninterrupted BGP services.
To specify a fake AS number for a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Specify a fake AS number for a peer/peer group. |
peer { group-name | ip-address } fake-as as-number |
Optional Not specified by default |
|
NOTE: This command is only applicable to an EBGP peer or peer group. |
Configuring AS number substitution
In MPLS L3VPN, if EBGP is used between PE and CE, sites in different geographical areas should have different AS numbers assigned to ensure correct route advertisement. If different CEs use the same AS number, you must configure the relevant PE to replace the AS number of the CE as its own AS number. This feature is used for route advertisement only.
Figure 19 AS number substitution configuration
As shown in the above figure, CE 1 and CE 2 use the same AS number of 800. If AS number substitution for CE 2 is configured on PE 2, and PE 2 receives a BGP update sent from CE 1, PE 2 replaces AS number 800 as its own AS number 100. Similar configuration must also be made on PE 1.
To configure AS number substitution for a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Replace the AS number of a peer/peer group in the AS_PATH attribute as the local AS number. |
peer { group-name | ip-address } substitute-as |
Not configured by default |
|
CAUTION: Improper AS number substitution configuration may cause route loops; use this command with caution. |
Removing private AS numbers from updates to a peer/peer group
To remove private AS numbers from updates to a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP to remove private AS numbers from the AS_PATH attribute of updates to a peer/peer group. |
peer { group-name | ip-address } public-as-only |
By default, BGP updates carry private AS numbers. |
Ignoring the first AS number of EBGP route updates
Typically, BGP checks the AS_PATH attribute of a route update received from a peer. If the first AS number is not that of the BGP peer, the BGP router discards the route update.
To ignore the first AS number of EBGP route updates:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP to ignore the first AS number of EBGP route updates. |
ignore-first-as |
By default, BGP checks the first AS number of EBGP route updates. |
Tuning and optimizing BGP networks
Configuration prerequisites
Create BGP connections.
|
CAUTION: · To run BGP, a router must have a router ID, which is an unsigned 32-bit integer, the unique ID of the router in the AS. · You can specify a router ID manually. Otherwise, the system selects the highest IP address among loopback interface addresses as the router ID. If no loopback interface addresses are available, the system selects the highest IP address among physical interface IP addresses as the router ID. It is recommended to specify a loopback interface address as the router ID to enhance network reliability. If the interface whose IP address is selected as the router ID or the manual router ID is deleted, the system selects a new router ID for the router. · For how to create a peer group and configure basic functions for it, see “Configuring BGP peer groups.” · To establish multiple BGP connections to another BGP router, you are recommended to manually specify respective source interfaces for establishing TCP connections to the peers on the peering BGP router. 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. · 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/peer group, the routing policy sets the specified 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 specified in the routing policy is zero, the routes matching it will also use the value set with the command. For how to use a routing policy to set a preferred value, see the command peer { group-name | ip-address } route-policy route-policy-name { export | import } command and the apply preferred-value preferred-value command. |
Configuring BGP keepalive interval and holdtime
After establishing a BGP connection, two routers send keepalive messages periodically to each other to keep the connection. If a router receives no keepalive or update message from the peer within the holdtime, it tears down the connection.
You can configure the keepalive interval and holdtime globally or for a specific peer or peer group. The actual keepalive interval and holdtime depend on the following cases:
· If the holdtime settings on the local and peer routers are different, the smaller one is used.
· If the keepalive interval is 0 and the negotiated holdtime is not 0, the actual keepalive interval equals one-third of the holdtime.
· If the keepalive interval is not 0, the actual keepalive interval is the smaller one between one third of the holdtime and the keepalive interval.
To configure BGP keepalive interval and holdtime:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure BGP keepalive interval and holdtime. |
·
Configure the global keepalive interval and
holdtime: ·
Configure the keepalive interval and holdtime
for a peer/peer group: |
Optional. By default, the keepalive interval is 60 seconds, and holdtime is 180 seconds. |
|
NOTE: · The maximum keepalive interval should be one third of the holdtime and no less than 1 second. The holdtime is no less than 3 seconds unless it is set to 0. · The intervals set with the peer timer command are preferred to those set with the timer command. · If the router has established a neighbor relationship with a peer, you must reset the BGP connection to validate the new set timers. · The timer command takes effect for only new connections. · After peer timer command is executed, the peer connection is closed at once, and a new connection to the peer is negotiated using the configured hold time. |
Configuring the interval for sending the same update
To configure the interval for sending the same update to a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the interval for sending the same update to a peer/peer group. |
peer { group-name | ip-address } route-update-interval interval |
Optional. The intervals for sending the same update to an IBGP peer and an EBGP peer default to 15 seconds and 30 seconds respectively. |
Configuring BGP soft-reset
After modifying the route selection policy, you have to reset BGP connections to make the new one take effect.
The current BGP implementation supports the route-refresh feature that enables dynamic route refresh without tearing down BGP connections.
However, if a peer not supporting route-refresh exists in the network, you must configure the peer keep-all-routes command to save all routes from the peer, which are used during applying the new route selection policy.
Configuring automatic soft-reset
After route refresh is enabled for peers and a policy is modified, the router advertises a route-refresh message to the peers, which then resend their routing information to the router. After receiving the routing information, the router performs dynamic route update by using the new policy.
To enable BGP route refresh for a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable BGP route refresh for a peer/peer group. |
peer { group-name | ip-address } capability-advertise route-refresh |
Optional Enabled by default |
Configuring manual soft-reset
If a BGP peer does not support route-refresh, you must save updates from the peer on the local router by using the peer keep-all-routes command, and use the refresh bgp command to refresh the BGP routing table.
Following these steps to save all route updates from a peer/peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Disable BGP route-refresh and multi-protocol extension capability for a peer/peer group. |
peer { group-name | ip-address } capability-advertise conventional |
Enabled by default |
4. Save all routes from a peer/peer group. |
peer { group-name | ip-address } keep-all-routes |
Not saved by default |
5. Return to user view. |
return |
N/A |
6. Perform manual soft reset on BGP connections. |
refresh bgp { all | ip-address | group group-name | external | internal } { export | import } |
N/A |
|
NOTE: If the BGP peer does not support route-refresh and the peer keep-all-routes command is not configured for it, you must decide whether to manually disconnect the peer to learn routes again according to the impact of the new policy. |
Enabling the BGP ORF capability
The BGP Outbound Route Filtering (ORF) feature allows a BGP speaker to send its BGP peer a set of ORFs through route-refresh messages. The peer then applies the ORFs, in addition to its local routing policies (if any), to filter updates to the BGP speaker, reducing the number of exchanged Update messages and saving network resources.
After you enable the BGP ORF capability, the local BGP router negotiates the ORF capability with the BGP peer through Open messages (determines whether to carry ORF information in messages, and if yes, whether to carry non-standard ORF information in the packets). After completing the negotiation process and establishing the neighboring relationship, the BGP router and its BGP peer can exchange ORF information through specific route-refresh messages.
For the parameters configured on both sides for ORF capability negotiation, see Table 2.
To enable the BGP ORF capability:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable BGP route refresh for a peer/peer group. |
peer { group-name | ip-address } capability-advertise route-refresh |
Enabled by default. |
4. Enable the non-standard ORF capability for a BGP peer/peer group. |
peer { group-name | ip-address } capability-advertise orf non-standard |
Optional. By default, standard BGP ORF capability defined in RFC 5291 and RFC 5292 is supported. If the peer supports only non-standard ORF, you need to configure this command. |
5. Enable the ORF capability for a BGP peer/peer group. |
peer { group-name | ip-address } capability-advertise orf ip-prefix { both | receive | send } |
Disabled by default. |
Table 2 Description of the both, send, and receive parameters and the negotiation result
Local parameter |
Peer parameter |
Negotiation result |
send |
· receive · both |
The ORF sending capability is enabled locally and the ORF receiving capability is enabled on the peer. |
receive |
· send · both |
The ORF receiving capability is enabled locally and the ORF sending capability is enabled on the peer. |
both |
both |
Both the ORF sending and receiving capabilities are enabled locally and on the peer, respectively. |
Enabling 4-byte AS number suppression
The device supports 4-byte AS numbers and uses 4-byte AS numbers by default. If the peer devices support only 2-byte AS numbers, you must enable the 4-byte AS number suppression function on the device.
To enable 4-byte AS number suppression:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable 4-byte AS number suppression. |
peer { group-name | ip-address } capability-advertise suppress-4-byte-as |
Disabled by default |
|
NOTE: If the peer device supports 4-byte AS numbers, do not enable the 4-byte AS number suppression function; otherwise, the BGP peer relationship cannot be established. |
Enabling quick EBGP session reestablishment
If the router receives no keepalive messages from a BGP peer within the holdtime, it disconnects from the peer.
With quick EBGP connection reestablishment enabled, the router, when the link to a directly connected EBGP peer is down, will reestablish a session to the EBGP peer immediately.
To enable quick EBGP session reestablishment:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable quick EBGP session reestablishment. |
ebgp-interface-sensitive |
Optional Not enabled by default |
Enabling MD5 authentication for TCP connections
BGP employs TCP as the transport protocol. To enhance security, you can configure BGP to perform MD5 authentication when establishing a TCP connection. The two parties must have the same password configured to establish TCP connections.
BGP MD5 authentication is not for BGP packets, but for TCP connections. If the authentication fails, no TCP connection can be established.
To enable MD5 authentication for TCP connections:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable MD5 authentication when establishing a TCP connection to the peer/peer group. |
peer { group-name | ip-address } password { cipher | simple } password |
Optional Not enabled by default |
Configuring BGP load balancing
If multiple paths to a destination exist, you can configure load balancing over such paths to improve link utilization.
To configure BGP load balancing:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the maximum number of BGP routes for load balancing. |
balance number |
Optional. By default, load balancing is not enabled. |
Forbiding session establishment with a peer or peer group
To forbid session establishment with a peer or peer group:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Forbid session establishment with a peer or peer group. |
peer { group-name | ip-address } ignore |
Optional Not forbidden by default |
Configuring a large scale BGP network
In a large-scale BGP network, configuration and maintenance may become difficult due to large numbers of BGP peers. To facilitate configuration, you can configure peer group, community, route reflector or confederation as needed.
Configuration prerequisites
Peering nodes are accessible to each other at the network layer.
Configuring BGP peer groups
A peer group is a group of peers with the same route selection policy.
In a large scale network, many peers may use the same route selection policy. You can configure a peer group and add these peers into this group. In this way, peers can share the same policy as the peer group. When the policy of the group is modified, the modification also applies to peers in it, simplifying configuration.
A peer group is an IBGP peer group if peers in it belong to the same AS, and is an EBGP peer group if peers in it belong to different ASs.
If a peer group has peers added, you cannot remove its AS number using the undo form of the command or change its AS number.
Configuring an IBGP peer group
After you create an IBGP peer group and then add a peer into it, the system creates the peer in BGP view and specifies the local AS number for the peer.
To configure an IBGP peer group:
Step |
Command |
1. Enter system view. |
system-view |
2. Enter BGP view. |
bgp as-number |
3. Create an IBGP peer group. |
group group-name [ internal ] |
4. Add a peer into the IBGP peer group. |
peer ip-address group group-name |
Configuring an EBGP peer group
If peers in an EBGP group belong to the same external AS, the EBGP peer group is a pure EBGP peer group; if not, it is a mixed EBGP peer group.
Use one of the following approaches to configure an EBGP peer group:
· Create the EBGP peer group, specify its AS number, and add peers into it. All the added peers share the same AS number.
· Create the EBGP peer group, specify an AS number for a peer, and add the peer into the peer group.
· Create the EBGP peer group and add a peer into it with an AS number specified.
To configure an EBGP peer group using the first approach:
Step |
Command |
1. Enter system view. |
system-view |
2. Enter BGP view. |
bgp as-number |
3. Create an EBGP peer group. |
group group-name external |
4. Specify the AS number for the group. |
peer group-name as-number as-number |
5. Add the peer into the group. |
peer ip-address group group-name |
|
NOTE: · Do not specify any AS number for a peer before adding it into the peer group. · All the added peers have the same AS number as that of the peer group. |
To configure an EBGP peer group using the second approach:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Create an EBGP peer group. |
group group-name external |
N/A |
4. Specify an AS number for a peer. |
peer ip-address as-number as-number |
N/A |
5. Add the peer into the group. |
peer ip-address group group-name [ as-number as-number ] |
The AS number can be either specified or not specified in the command. If specified, the AS number must be the same as that specified for the peer with the peer ip-address as-number as-number command. |
|
NOTE: Peers added in the group can have different AS numbers. |
To configure an EBGP peer group using the third approach:
Step |
Command |
1. Enter system view. |
system-view |
2. Enter BGP view. |
bgp as-number |
3. Create an EBGP peer group. |
group group-name external |
4. Add a peer into the group and specify its AS number. |
peer ip-address group group-name as-number as-number |
|
NOTE: · Do not specify any AS number for a peer before adding it into the peer group. · Peers added in the group can have different AS numbers. |
Configuring BGP community
A BGP community is a group of destinations with the same characteristics. It has no geographical boundaries and is independent of ASs.
You can configure a routing policy to define which destinations belong to a BGP community and then advertise the community attribute to a peer/peer group.
You can apply a routing policy to filter routes advertised to/received from a peer/peer group according to the community attribute. This way helps simplify policy configuration and management.
For how to configure a routing policy, see the chapter “Configuring routing policies.”
To configure BGP community:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Advertise the community attribute to a peer/peer group. |
·
Advertise the community attribute to a
peer/peer group: ·
Advertise the extended community attribute to
a peer/peer group: |
Not configured by default |
4. Apply a routing policy to routes advertised to a peer/peer group. |
peer { group-name | ip-address } route-policy route-policy-name export |
Not configured by default |
Configuring a BGP route reflector
If an AS has many BGP routers, you can configure them as a cluster and configure one of them as a route reflector and others as clients to reduce IBGP connections.
To enhance network reliability and prevent single point of failure, specify multiple route reflectors for a cluster. The route reflectors in the cluster must have the same cluster ID to avoid routing loops.
To configure a BGP route reflector:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Configure the router as a route reflector and specify a peer/peer group as its client. |
peer { group-name | ip-address } reflect-client |
Not configured by default. The peer reflect-client command can be configured in both BGP view and BGP-VPNv4 subaddress family view. In BGP view, the command enables the router to reflect routes of the public network; in BGP-VPNv4 subaddress family view, the command enables the router to reflect routes of the private network. (You can enter BGP-VPNv4 subaddress family view by executing the ipv4-family vpnv4 command in BGP view. For more information about the ipv4-family vpnv4 command, see MPLS Command Reference.) |
4. Enable route reflection between clients. |
reflect between-clients |
Optional. Enabled by default. |
5. 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: · 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, disable route reflection between clients to reduce routing costs. · 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. To avoid routing loops, specify the same cluster ID for these route reflectors by using the reflector cluster-id command. |
Configuring a BGP confederation
Configuring a BGP confederation is another way for reducing IBGP connections in an AS.
A confederation contains sub ASs. In each sub AS, IBGP peers are fully meshed. Between sub ASs, EBGP connections are established.
If routers not compliant with RFC 3065 exist in the confederation, use the confederation nonstandard command to make the local router compatible with these routers.
Configuring a BGP confederation
After you split an AS into multiple sub ASs, you can configure a router in a sub AS in the following way:
1. Enable BGP and specify the AS number of the router.
2. Specify the confederation ID. From an outsider’s perspective, the sub ASs of the confederation is a single AS, which is identified by the confederation ID.
3. If the router needs to establish EBGP connections to other sub ASs, specify the peering sub ASs in the confederation.
A confederation contains 32 sub ASs at most. The AS number of a sub AS is effective only in the confederation.
To configure a BGP confederation:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable BGP, and enter BGP view. |
bgp as-number |
N/A |
3. Configure a confederation ID. |
confederation id as-number |
Not configured by default |
4. Specify peering sub ASs in the confederation. |
confederation peer-as as-number-list |
Not specified by default |
Configuring confederation compatibility
If some other routers in the confederation do not comply with RFC 3065, you must enable confederation compatibility to allow the router to work with those routers.
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable compatibility with routers not compliant with RFC 3065 in the confederation. |
confederation nonstandard |
Optional Not enabled by default |
Configuring BGP GR
Perform the following configuration on the GR Restarter and GR Helper respectively.
|
NOTE: A router can act as a GR Restarter and GR Helper at the same time. |
To configure BGP GR:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable BGP, and enter its view. |
bgp as-number |
N/A |
3. Enable GR Capability for BGP. |
graceful-restart |
Disabled by default |
4. Configure the maximum time allowed for the peer to reestablish a BGP session. |
graceful-restart timer restart timer |
Optional 150 seconds by default |
5. Configure the maximum time to wait for the End-of-RIB marker. |
graceful-restart timer wait-for-rib timer |
Optional 180 seconds by default |
|
NOTE: · In general, the maximum time allowed for the peer (the GR restarter) to reestablish a BGP session should be less than the Holdtime carried in the Open message. · The End-Of-RIB (End of Routing-Information-Base) indicates the end of route updates. |
Enabling Trap
After Trap is enabled for BGP, BGP generates Level-4 traps to report important events. The generated traps are sent to the information center of the router. The output rules of the traps (whether to output the traps and the output direction) are determined according to the information center configuration. (For information center configuration, see Network Management and Monitoring Configuration Guide.)
To enable Trap:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable Trap for BGP. |
snmp-agent trap enable bgp |
Optional Enabled by default |
Enabling logging of peer state changes
To enable the logging of peer state changes:
Step |
Command |
Remarks |
||
1. Enter system view. |
system-view |
N/A |
||
2. Enter BGP view. |
bgp as-number |
N/A |
||
3. Enable the logging of peer state changes globally. |
log-peer-change |
Optional Enabled by default |
||
4. Enable the logging of peer state changes for a peer or peer group. |
peer { group-name | ip-address } log-change |
Optional Enabled by default |
||
Configuring BFD for BGP
BGP maintains neighbor relationships based on the keepalive timer and holdtime timer, which are set in seconds. BGP defines that the holdtime interval must be at least three times the keepalive interval. This mechanism makes link failure detection rather slow; once a failure occurs on a high-speed link, a large quantity of packets will be dropped. BFD is introduced to solve this problem. It detects links between neighbors quickly to reduce convergence time upon link failures.
To enable BFD for a BGP peer:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter BGP view. |
bgp as-number |
N/A |
3. Enable BFD for the specified BGP peer. |
peer ip-address bfd |
Not enabled for any BGP peer by default |
Displaying and maintaining BGP
Displaying BGP
Resetting BGP connections
Task |
Command |
Remarks |
Reset all BGP connections. |
reset bgp all |
Available in user view |
Reset the BGP connections to an AS. |
reset bgp as-number |
Available in user view |
Reset the BGP connection to a peer. |
reset bgp ip-address [ flap-info ] |
Available in user view |
Reset all EBGP connections. |
reset bgp external |
Available in user view |
Reset the BGP connections to a peer group. |
reset bgp group group-name |
Available in user view |
Reset all IBGP connections. |
reset bgp internal |
Available in user view |
Reset all IPv4 unicast BGP connections. |
reset bgp ipv4 all |
Available in user view |
Clearing BGP information
Task |
Command |
Remarks |
Clear dampened MBGP routing information and release suppressed routes. |
reset bgp dampening [ ip-address [ mask | mask-length ] ] |
Available in user view |
Clear route flap information. |
reset bgp flap-info [ ip-address [ mask-length | mask ] | as-path-acl as-path-acl-number | regexp as-path-regular-expression ] |
Available in user view |
BGP configuration examples
BGP basic configuration example
Network requirements
In Figure 20, run EBGP between Router A and Router B and IBGP between Router B and Router C so that Router C can access the network 8.1.1.0/24 connected to Router A.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure IBGP:
¡ To prevent route flapping caused by port state changes, this example uses loopback interfaces to establish IBGP connections.
¡ Because loopback interfaces are virtual interfaces, you need to use the peer connect-interface command to specify the loopback interface as the source interface for establishing BGP connections.
¡ Enable OSPF in AS 65009 to make sure that Router B can communicate with Router C through loopback interfaces.
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.3.3.3 as-number 65009
[RouterB-bgp] peer 3.3.3.3 connect-interface loopback 0
[RouterB-bgp] quit
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] network 9.1.1.1 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 2.2.2.2 as-number 65009
[RouterC-bgp] peer 2.2.2.2 connect-interface loopback 0
[RouterC-bgp] quit
[RouterC] ospf 1
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0
[RouterC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
[RouterC] display bgp peer
BGP local router ID : 3.3.3.3
Local AS number : 65009
Total number of peers : 1 Peers in established state : 1
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
2.2.2.2 65009 7 10 0 0 00:06:09 Established
The output information shows that Router C has established an IBGP peer relationship with Router B.
3. Configure EBGP:
¡ The EBGP peers, Router A and Router B (usually belong to different ISPs), are located in different ASs. Typically, their loopback interfaces are not reachable to each other, so directly connected interfaces are used for establishing BGP sessions.
¡ To enable Router C to access the network 8.1.1.0/24 connected directly to Router A, inject network 8.1.1.0/24 to the BGP routing table of Router A.
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] network 8.1.1.1 24
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] peer 3.1.1.2 as-number 65008
[RouterB-bgp] quit
# Display BGP peer information on Router B.
[RouterB] display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 65009
Total number of peers : 2 Peers in established state : 2
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
3.3.3.3 65009 12 10 0 3 00:09:16 Established
3.1.1.2 65008 3 3 0 1 00:00:08 Established
The output shows that Router B has established an IBGP peer relationship with Router C and an EBGP peer relationship with Router A.
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - 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
# Display the BGP routing table on Router B.
[RouterB] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 2.2.2.2
Status codes: * - valid, ^ - VPNv4 best, > - 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 3.1.1.2 0 0 65008i
# Display the BGP routing table on Router C.
[RouterC] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - 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.1.1.0/24 3.1.1.2 0 100 0 65008i
|
NOTE: From the outputs, you can find Router A has learned no route to AS65009, and Router C has learned network 8.1.1.0 but the next hop 3.1.1.2 is unreachable, and thus the route is invalid. |
4. Redistribute direct routes:
Configure BGP to redistribute direct routes on Router B, so that Router A can obtain the route to 9.1.1.0/24 and Router C can obtain the route to 3.1.1.0/24.
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] import-route direct
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 4
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? – incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 2.2.2.2/32 3.1.1.1 0 0 65009?
* 3.1.1.0/24 3.1.1.1 0 0 65009?
*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.1.1.0/24 3.1.1.1 0 0 65009?
Two routes 2.2.2.2/32 and 9.1.1.0/24 have been added in Router A’s routing table.
# Display the BGP routing table on Router C.
[RouterC] display bgp routing-table
Total Number of Routes: 4
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - 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 2.2.2.2/32 2.2.2.2 0 100 0 ?
*>i 3.1.1.0/24 2.2.2.2 0 100 0 ?
*>i 8.1.1.0/24 3.1.1.2 0 100 0 65008i
* i 9.1.1.0/24 2.2.2.2 0 100 0 ?
The output shows that the route 8.1.1.0 becomes valid with the next hop as Router A.
5. Verify the configuration:
# Ping 8.1.1.1 on Router C.
[RouterC] 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=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=2 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=3 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=5 ttl=254 time=2 ms
--- 8.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/2 ms
BGP and IGP synchronization configuration example
Network requirements
As shown in Figure 21, all routers of company A belong to AS 65008 while all routers of company B belong to AS 65009. AS 65008 and AS 65009 are connected through Router A and Router B. It is required that Router A can access network 9.1.2.0/24 in AS 65009, and Router C can access network 8.1.1.0/24 in AS 65008.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure OSPF:
Enable OSPF in AS 65009, so that Router B can obtain the route to 9.1.2.0/24.
# Configure Router B.
<RouterB> system-view
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf 1
[RouterC-ospf-1] import-route direct
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 9.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
3. Configure the EBGP connection:
Configure the EBGP connection and inject network 8.1.1.0/24 to the BGP routing table of Router A, so that Router B can obtain the route to 8.1.1.0/24.
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] network 8.1.1.0 24
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.1.1.2 as-number 65008
4. Configure BGP and IGP synchronization:
¡ Configure BGP to redistribute routes from OSPF on Router B, so that Router A can obtain the route to 9.1.2.0/24.
¡ Configure OSPF to redistribute routes from BGP on Router B, so that Router C can obtain the route to 8.1.1.0/24.
# Configure BGP to redistribute routes from OSPF on Router B.
[RouterB-bgp] import-route ospf 1
[RouterB-bgp] quit
[RouterB] ospf 1
[RouterB-ospf-1] import-route bgp
[RouterB-ospf-1] quit
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 3.3.3.3/32 3.1.1.1 1 0 65009?
*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.1.2.0/24 3.1.1.1 1 0 65009?
# Display the routing table on Router C.
[RouterC] display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
2.2.2.2/32 OSPF 10 1 9.1.1.1 GE4/1/2
3.3.3.3/32 Direct 0 0 127.0.0.1 InLoop0
8.1.1.0/24 O_ASE 150 1 9.1.1.1 GE4/1/2
9.1.1.0/24 Direct 0 0 9.1.1.2 GE4/1/2
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 GE3/1/1
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. Verify the configuration:
# Use ping for verification.
[RouterA] 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
[RouterC] ping -a 9.1.2.1 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=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=2 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=3 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 8.1.1.1: bytes=56 Sequence=5 ttl=254 time=2 ms
--- 8.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/2 ms
BGP load balancing configuration example
Network requirements
This example describes how to configure BGP load balancing.
As shown in Figure 22, all routers run BGP, and Router A resides in AS 65008, Router B and Router C in AS 65009. Between Router A and Router B, Router A and Router C are EBGP connections, and between Router B and Router C is an IBGP connection. Two routes are configured on Router A for load balancing.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure BGP connections:
¡ On Router A, establish EBGP connections with Router B and Router C respectively; configure BGP to advertise network 8.1.1.0/24 to Router B and Router C, so that Router B and Router C can access the internal network connected to Router A.
¡ On Router B, establish an EBGP connection with Router A and an IBGP connection with Router C; configure BGP to advertise network 9.1.1.0/24 to Router A, so that Router A can access the intranet through Router B; configure a static route to interface loopback 0 on Router C (or use a routing protocol like OSPF) to establish the IBGP connection.
¡ On Router C, establish an EBGP connection with Router A and an IBGP connection with Router B; configure BGP to advertise network 9.1.1.0/24 to Router A, so that Router A can access the intranet through Router C; configure a static route to interface loopback 0 on Router B (or use another protocol like OSPF) to establish the IBGP connection.
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 3.1.1.1 as-number 65009
[RouterA-bgp] peer 3.1.2.1 as-number 65009
[RouterA-bgp] network 8.1.1.1 24
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 3.1.1.2 as-number 65008
[RouterB-bgp] peer 3.3.3.3 as-number 65009
[RouterB-bgp] peer 3.3.3.3 connect-interface loopback 0
[RouterB-bgp] network 9.1.1.0 24
[RouterB-bgp] quit
[RouterB] ip route-static 3.3.3.3 32 9.1.1.2
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 3.1.2.2 as-number 65008
[RouterC-bgp] peer 2.2.2.2 as-number 65009
[RouterC-bgp] peer 2.2.2.2 connect-interface loopback 0
[RouterC-bgp] network 9.1.1.0 24
[RouterC-bgp] quit
[RouterC] ip route-static 2.2.2.2 32 9.1.1.1
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - 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 65009i
* 3.1.2.1 0 0 65009i
¡ From the output, you can find two valid routes to destination 9.1.1.0/24: the route with next hop 3.1.1.1 is marked with a greater-than sign (>), indicating it is the best route; the route with next hop 3.1.2.1 is marked with only an asterisk (*), indicating it is a valid route, but not the best.
¡ By using the display ip routing-table command, you can find only one route to 9.1.1.0/24 with next hop 3.1.1.1 and outbound interface GE4/1/2.
3. Configure load balancing:
Since Router A has two routes to reach AS 65009, configuring load balancing over the two BGP routes on Router A can improve link utilization.
# Configure Router A.
[RouterA] bgp 65008
[RouterA-bgp] balance 2
[RouterA-bgp] quit
4. Verify the configuration:
# Display the BGP routing table on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 3
BGP Local router ID is 1.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - 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 65009i
*> 3.1.2.1 0 0 65009i
¡ From the above output information, you can find two valid routes to the destination 9.1.1.0/24, and both of them are marked with a greater-than sign (>), indicating they are the best routes.
¡ By using the display ip routing-table command, you can find two routes to 9.1.1.0/24: one with next hop 3.1.1.1 and outbound interface GE4/1/2, the other with next hop 3.1.2.1 and outbound interface GE4/1/1.
BGP community configuration example
Network requirements
As shown in Figure 23, Router B establishes EBGP connections with Router A and Router C. Configure No_Export community attribute on Router A to make routes from AS 10 not advertised by AS 20 to any other AS.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure EBGP connections:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 10
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.2.2 as-number 20
[RouterA-bgp] network 9.1.1.0 255.255.255.0
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 20
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 200.1.2.1 as-number 10
[RouterB-bgp] peer 200.1.3.2 as-number 30
[RouterB-bgp] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 30
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 200.1.3.1 as-number 20
[RouterC-bgp] quit
# Display BGP routing table information on Router B.
[RouterB] 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
Router B has advertised the route to Router C in AS 30.
# Display BGP routing table information on Router C.
[RouterC] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 3.3.3.3
Status codes: * - valid, ^ - VPNv4 best, > - 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 0 20 10i
Router C has learned the route to the destination 9.1.1.0/24 from Router B.
3. Configure BGP community attribute:
# Configure a routing policy.
[RouterA] route-policy comm_policy permit node 0
[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit
# Apply the routing policy.
[RouterA] bgp 10
[RouterA-bgp] peer 200.1.2.2 route-policy comm_policy export
[RouterA-bgp] peer 200.1.2.2 advertise-community
# Display BGP routing table information on Router B.
[RouterB] 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
You can find the No-export community attribute in the above output information. In this case, the route of 9.1.1.0/24 is not available in the routing table of Router C.
BGP route reflector configuration example
Network requirements
In Figure 24, all routers run BGP.
· Between Router A and Router B is an EBGP connection, and between Router C and Router B, and between Router C and Router D are IBGP connections.
· Router C is a route reflector with clients Router B and D.
· Router D can learn route 1.0.0.0/8 from Router C.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure BGP connections: (Details not shown)
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 100
[RouterA-bgp] peer 192.1.1.2 as-number 200
# Inject network 1.0.0.0/8 to the BGP routing table.
[RouterA-bgp] network 1.0.0.0
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 200
[RouterB-bgp] peer 192.1.1.1 as-number 100
[RouterB-bgp] peer 193.1.1.1 as-number 200
[RouterB-bgp] peer 193.1.1.1 next-hop-local
[RouterB-bgp] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.2 as-number 200
[RouterC-bgp] peer 194.1.1.2 as-number 200
[RouterC-bgp] quit
# Configure Router D.
<RouterD> system-view
[RouterD] bgp 200
[RouterD-bgp] peer 194.1.1.1 as-number 200
[RouterD-bgp] quit
3. Configure the route reflector:
# Configure Router C as the route reflector.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.2 reflect-client
[RouterC-bgp] peer 194.1.1.2 reflect-client
[RouterC-bgp] quit
4. Verify the configuration:
# Display the BGP routing table on Router B.
[RouterB] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 200.1.2.2
Status codes: * - valid, ^ - VPNv4 best, > - 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 on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 200.1.2.1
Status codes: * - valid, ^ - VPNv4 best, > - 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
Router D learned the route 1.0.0.0/8 from Router C.
BGP confederation configuration example
Network requirements
As shown in Figure 25, to reduce IBGP connections in AS 200, split it into three sub-ASs, AS65001, AS65002 and AS65003. Routers in AS65001 are fully meshed.
Device |
Interface |
IP address |
Device |
Interface |
IP address |
Router A |
POS2/1/2 |
200.1.1.1/24 |
Router D |
GE1/1/1 |
10.1.3.2/24 |
|
GE1/1/1 |
10.1.1.1/24 |
|
GE1/1/2 |
10.1.5.1/24 |
|
GE1/1/2 |
10.1.2.1/24 |
Router E |
GE1/1/1 |
10.1.4.2/24 |
|
GE1/1/3 |
10.1.3.1/24 |
|
GE1/1/2 |
10.1.5.2/24 |
|
GE1/1/4 |
10.1.4.1/24 |
Router F |
GE1/1/1 |
9.1.1.1/24 |
Router B |
GE1/1/1 |
10.1.1.2/24 |
|
POS2/1/1 |
200.1.1.2/24 |
Router C |
GE1/1/1 |
10.1.2.2/24 |
|
|
|
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure the BGP confederation:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 65001
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp] peer 10.1.1.2 as-number 65002
[RouterA-bgp] peer 10.1.1.2 next-hop-local
[RouterA-bgp] peer 10.1.2.2 as-number 65003
[RouterA-bgp] peer 10.1.2.2 next-hop-local
[RouterA-bgp] quit
# Configure Router B.
<RouterB> system-view
[RouterB] bgp 65002
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] confederation id 200
[RouterB-bgp] confederation peer-as 65001 65003
[RouterB-bgp] peer 10.1.1.1 as-number 65001
[RouterB-bgp] quit
# Configure Router C.
<RouterC> system-view
[RouterC] bgp 65003
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001 65002
[RouterC-bgp] peer 10.1.2.1 as-number 65001
[RouterC-bgp] quit
3. Configure IBGP connections in AS65001:
# Configure Router A.
[RouterA] bgp 65001
[RouterA-bgp] peer 10.1.3.2 as-number 65001
[RouterA-bgp] peer 10.1.3.2 next-hop-local
[RouterA-bgp] peer 10.1.4.2 as-number 65001
[RouterA-bgp] peer 10.1.4.2 next-hop-local
[RouterA-bgp] quit
# Configure Router D.
<RouterD> system-view
[RouterD] bgp 65001
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] confederation id 200
[RouterD-bgp] peer 10.1.3.1 as-number 65001
[RouterD-bgp] peer 10.1.5.2 as-number 65001
[RouterD-bgp] quit
# Configure Router E.
<RouterE> system-view
[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] peer 10.1.5.1 as-number 65001
[RouterE-bgp] quit
4. Configure the EBGP connection between AS100 and AS200:
# Configure Router A.
[RouterA] bgp 65001
[RouterA-bgp] peer 200.1.1.2 as-number 100
[RouterA-bgp] quit
# Configure Router F.
<RouterF> system-view
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] network 9.1.1.0 255.255.255.0
[RouterF-bgp] quit
5. Verify the configuration:
# Display BGP routing table information on Router B.
[RouterB] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 2.2.2.2
Status codes: * - valid, ^ - VPNv4 best, > - 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
[RouterB] 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 BGP routing table information on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 4.4.4.4
Status codes: * - valid, ^ - VPNv4 best, > - 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
[RouterD] 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
The output information shows that:
¡ Router F can send route information to Router B and Router C through the confederation by establishing only an EBGP connection with Router A.
¡ Router B and Router D are in the same confederation, but belong to different sub ASs. They obtain external route information from Router A and generate the same BGP route entries; it seems like that they reside in the same AS although they have no direct connection in between.
BGP path selection configuration example
Network requirements
· In Figure 26, all routers run BGP. Between Router A and Router B, and between Router A and Router C are EBGP connections. Between Router B and Router D, and between Router D and Router C are IBGP connections.
· OSPF is the IGP protocol in AS 200.
· Configure routing policies to make Router D give priority to the route 1.0.0.0/8 learned from Router C.
Device |
Interface |
IP address |
Device |
Interface |
IP address |
Router A |
GE1/1/1 |
1.0.0.0/8 |
Router D |
POS2/1/1 |
195.1.1.1/24 |
|
POS2/1/1 |
192.1.1.1/24 |
|
POS2/1/2 |
194.1.1.1/24 |
|
POS2/1/2 |
193.1.1.1/24 |
Router C |
POS2/1/1 |
195.1.1.2/24 |
Router B |
POS2/1/1 |
192.1.1.2/24 |
|
POS2/1/2 |
193.1.1.2/24 |
|
POS2/1/2 |
194.1.1.2/24 |
|
|
|
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure OSPF on routers B, C and D:
# Configure Router B.
<RouterB> system-view
[RouterB] ospf
[RouterB-ospf] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospf
[RouterC-ospf] area 0
[RouterC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# Configure Router D.
<RouterD> system-view
[RouterD] ospf
[RouterD-ospf] area 0
[RouterD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
[RouterD-ospf-1] quit
3. Configure BGP connections:
# Configure Router A.
<RouterA> system-view
[RouterA] bgp 100
[RouterA-bgp] peer 192.1.1.2 as-number 200
[RouterA-bgp] peer 193.1.1.2 as-number 200
# Inject network 1.0.0.0/8 into the BGP routing table of Router A.
[RouterA-bgp] network 1.0.0.0 8
[RouterA-bgp] quit
# Configure Router B.
[RouterB] bgp 200
[RouterB-bgp] peer 192.1.1.1 as-number 100
[RouterB-bgp] peer 194.1.1.1 as-number 200
[RouterB-bgp] quit
# Configure Router C
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.1 as-number 100
[RouterC-bgp] peer 195.1.1.1 as-number 200
[RouterC-bgp] quit
# Configure Router D
[RouterD] bgp 200
[RouterD-bgp] peer 194.1.1.2 as-number 200
[RouterD-bgp] peer 195.1.1.2 as-number 200
[RouterD-bgp] quit
4. Configure different attribute values for the route 1.0.0.0/8 to make Router D give priority to the route learned from Router C:
¡ Method I
Specify a higher MED value for the route 1.0.0.0/8 advertised to 192.1.1.2 to make Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterA-acl-basic-2000] quit
# Define routing policy apply_med_50 that sets the MED value of route 1.0.0.0/8 to 50, and routing policy apply_med_100 that sets the MED value of route 1.0.0.0/8 to 100.
[RouterA] route-policy apply_med_50 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA-route-policy] quit
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
[RouterA-route-policy] quit
# Apply routing policy apply_med_50 to the route advertised to 193.1.1.2 (Router C), and apply routing policy apply_med_100 to the route advertised to 192.1.1.2 (Router B).
[RouterA] bgp 100
[RouterA-bgp] peer 193.1.1.2 route-policy apply_med_50 export
[RouterA-bgp] peer 192.1.1.2 route-policy apply_med_100 export
[RouterA-bgp] quit
# Display the BGP routing table on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 2
BGP Local router ID is 194.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - 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
The route 1.0.0.0/8 learned from Router C is the optimal.
¡ Method II
Specify different local preferences for route 1.0.0.0/8 on Router B and C to make Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8 on Router C.
[RouterC] acl number 2000
[RouterC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterC-acl-basic-2000] quit
# Define routing policy localpref on Router C to set the local preference of route 1.0.0.0/8 to 200 (the default is 100).
[RouterC] route-policy localpref permit node 10
[RouterC-route-policy] if-match acl 2000
[RouterC-route-policy] apply local-preference 200
[RouterC-route-policy] quit
# Apply the routing policy localpref to the route from the peer 193.1.1.1 on Router C.
[RouterC] bgp 200
[RouterC-bgp] peer 193.1.1.1 route-policy localpref import
[RouterC-bgp] quit
# Display the BGP routing table on Router D.
[RouterD] display bgp routing-table
Total Number of Routes: 2
BGP Local router ID is 194.1.1.1
Status codes: * - valid, ^ - VPNv4 best, > - 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
The route 1.0.0.0/8 learned from Router C is the optimal.
BGP GR configuration example
Network requirements
In Figure 27 are all BGP routers. Between Router A and Router B is an EBGP connection. Router B and Router C are connected over an IBGP connection. Enable GR capability for BGP so that the communication between Router A and Router C cannot be affected when an active/standby main board switchover occurs on Router B.
Configuration procedure
1. Configure Router A:
# Configure IP addresses for interfaces. (Details not shown)
# Configure the EBGP connection.
<RouterA> system-view
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# Inject network 8.0.0.0/8 to the BGP routing table.
[RouterA-bgp] network 8.0.0.0
# Enable GR capability for BGP.
[RouterA-bgp] graceful-restart
2. Configure Router B:
# Configure IP addresses for interfaces. (Details not shown)
# Configure the EBGP connection.
<RouterB> system-view
[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 200.1.1.2 as-number 65008
# Configure the IBGP connection.
[RouterB-bgp] peer 9.1.1.2 as-number 65009
# Inject networks 200.1.1.0/24 and 9.1.1.0/24 to the BGP routing table.
[RouterB-bgp] network 200.1.1.0 24
[RouterB-bgp] network 9.1.1.0 24
# Enable GR capability for BGP.
[RouterB-bgp] graceful-restart
3. Configure Router C:
# Configure IP addresses for interfaces. (Details not shown)
# Configure the IBGP connection.
<RouterC> system-view
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 9.1.1.1 as-number 65009
# Enable GR capability for BGP.
[RouterC-bgp] graceful-restart
4. Verify the configuration:
Ping Router C on Router A. Meanwhile, perform an active/standby main board switchover on Router B. The ping operation is successful during the whole switchover process.
BFD for BGP configuration example
Network requirements
As shown in Figure 28,
· Configure OSPF as the IGP in AS 200.
· Establish two IBGP connections between Router A and Router C. When both links are working, Router C adopts the link Router A<—>Router B<—>Router C to exchange packets with network 1.1.1.0/24. Configure BFD over the link. Then if the link fails, BFD can quickly detect the failure and notify it to BGP. Then the link Router A<—>Router D<—>Router C takes effect immediately.
Configuration procedure
1. Configure IP addresses for interfaces. (Details not shown)
2. Configure OSPF so that Router A and Router C are reachable to each other. (Details not shown)
3. Configure BGP on Router A:
# Establish two IBGP connections between Router A and Router C.
<RouterA> system-view
[RouterA] bgp 200
[RouterA-bgp] peer 3.0.2.2 as-number 200
[RouterA-bgp] peer 2.0.2.2 as-number 200
[RouterA-bgp] quit
# When the two links between Router A and Router C are both up, Router C adopts the link Router A<—>Router B<—>Router C to exchange packets with network 1.1.1.0/24. (Set a higher MED value for route 1.1.1.0/24 sent to peer 2.0.2.2 on Router A.)
¡ Create ACL 2000 to permit 1.1.1.0/24 to pass.
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule permit source 1.1.1.0 0.0.0.255
[RouterA-acl-basic-2000] quit
¡ Create two route policies, apply_med_50 and apply_med_100. Policy apply_med_50 sets the MED for route 1.1.1.0/24 to 50. Policy apply_med_100 sets that to 100.
[RouterA] route-policy apply_med_50 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA-route-policy] quit
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
[RouterA-route-policy] quit
¡ Apply routing policy apply_med_50 to routes outgoing to peer 3.0.2.2, and apply routing policy apply_med_100 to routes outgoing to peer 2.0.2.2.
[RouterA] bgp 200
[RouterA-bgp] peer 3.0.2.2 route-policy apply_med_50 export
[RouterA-bgp] peer 2.0.2.2 route-policy apply_med_100 export
# Configure BFD over the link to peer 3.0.2.2 so that when the link Router A<—>Router B<—>Router C fails, BFD can quickly detect the failure and notify it to BGP, and then the link Router A<—>Router D<—>Router C takes effect immediately.
[RouterA-bgp] peer 3.0.2.2 bfd
[RouterA-bgp] quit
4. Configure BGP on Router C:
<RouterC> system-view
[RouterC] bgp 200
[RouterC-bgp] peer 3.0.1.1 as-number 200
[RouterC-bgp] peer 3.0.1.1 bfd
[RouterC-bgp] peer 2.0.1.1 as-number 200
[RouterC-bgp] quit
5. Configure BFD parameters (you can use default BFD parameters instead):
# Configure Router A.
[RouterA] bfd session init-mode active
[RouterA] interface GigabitEthernet 3/1/2
¡ Configure the minimum interval for transmitting BFD control packets as 500 milliseconds.
[RouterA-GigabitEthernet3/1/2] bfd min-transmit-interval 500
¡ Configure the minimum interval for receiving BFD control packets as 500 milliseconds.
[RouterA-GigabitEthernet3/1/2] bfd min-receive-interval 500
¡ Configure the detect multiplier as 7.
[RouterA-GigabitEthernet3/1/2] bfd detect-multiplier 7
[RouterA-GigabitEthernet3/1/2] quit
# Configure Router C.
[RouterC] bfd session init-mode active
[RouterC] interface GigabitEthernet 3/1/1
[RouterC-GigabitEthernet3/1/1] bfd min-transmit-interval 500
[RouterC-GigabitEthernet3/1/1] bfd min-receive-interval 500
[RouterC-GigabitEthernet3/1/1] bfd detect-multiplier 7
[RouterC-GigabitEthernet3/1/1] return
6. Verify the configuration:
The following operations are made on Router C. Operations on Router A are similar and are thus not shown.
# Display detailed BFD session information.
<RouterC> display bfd session verbose
Total Session Num: 1 Init Mode: Active
IP Session Working Under Ctrl Mode:
Local Discr: 17 Remote Discr: 13
Source IP: 3.0.2.2 Destination IP: 3.0.1.1
Session State: Up Interface: GigabitEthernet3/1/1
Min Trans Inter: 500ms Act Trans Inter: 500ms
Min Recv Inter: 500ms Act Detect Inter: 3500ms
Recv Pkt Num: 57 Send Pkt Num: 53
Hold Time: 2200ms Connect Type: Indirect
Running Up for: 00:00:06 Auth mode: Simple
Protocol: BGP
Diag Info: No Diagnostic
The above output shows that a BFD session is established between Router A’s GigabitEthernet 3/1/2 and Router C’s GigabitEthernet 3/1/1 and that BFD runs properly.
# Display BGP peer information on Router C, and you can see that Router C has established two BGP neighborships with Router A.
<RouterC> display bgp peer
BGP local router ID : 1.1.1.1
Local AS number : 200
Total number of peers : 2 Peers in established state : 2
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
2.0.1.1 200 7 10 0 0 00:01:05 Established
3.0.1.1 200 7 10 0 0 00:01:34 Established
# Display route 1.1.1.0/24 on Router C, and you can see that Router A and Router C communicate through Router B.
<RouterC> display ip routing-table 1.1.1.0 24 verbose
Routing Table : Public
Summary Count : 2
Destination: 1.1.1.0/24
Protocol: BGP Process ID: 0
Preference: 0 Cost: 50
NextHop: 3.0.1.1 Interface: GigabitEthernet3/1/1
BkNextHop: 0.0.0.0 BkInterface:
RelyNextHop: 3.0.2.1 Neighbor : 3.0.1.1
Tunnel ID: 0x0 Label: NULL
State: Active Adv Age: 00h08m54s
Tag: 0
Destination: 1.1.1.0/24
Protocol: BGP Process ID: 0
Preference: 0 Cost: 100
NextHop: 2.0.1.1 Interface: GigabitEthernet3/1/2
BkNextHop: 0.0.0.0 BkInterface:
RelyNextHop: 2.0.2.1 Neighbor : 2.0.1.1
Tunnel ID: 0x0 Label: NULL
State: Invalid Adv Age: 00h08m54s
Tag: 0
The above output shows that Router C has two routes to reach network 1.1.1.0/24: Router C<—>Router B<—>Router A, which is the currently active route; Router C<—>Router D<—>Router A, which is the backup route.
# Enable BFD debugging on Router C.
<RouterC> debugging bfd scm
<RouterC> debugging bfd event
<RouterC> debugging bgp bfd
<RouterC> terminal monitor
<RouterC> terminal debugging
# The following debugging information shows that: when the link between Router A and Router B fails, Router C can quickly detect the link failure.
%Nov 5 11:42:24:172 2009 RouterC BFD/5/BFD_CHANGE_FSM: Sess[3.0.2.2/3.0.1.1,13/17, GigabitEthernet3/1/1,Ctrl], Sta: UP->DOWN, Diag: 1
%Nov 5 11:42:24:172 2009 RouterC BGP/5/BGP_STATE_CHANGED: 3.0.1.1 state is changed from ESTABLISHED to IDLE.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Recv BFD DOWN msg, Src IP 3.0.2.2, Dst IP 3.0.1.1, Instance ID 0.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Reset BGP session 3.0.1.1 for BFD session down.
*Nov 5 11:42:24:187 2009 RouterC RM/6/RMDEBUG: BGP_BFD: Send DELETE msg to BFD, Connection type DIRECT, Src IP 3.0.2.2, Dst IP 3.0.1.1, Instance ID 0.
# Display route 1.1.1.0/24 on Router C, and you can see that Router A and Router C communicate through Router D.
<RouterC> display ip routing-table 1.1.1.0 24 verbose
Routing Table : Public
Summary Count : 1
Destination: 1.1.1.0/24
Protocol: BGP Process ID: 0
Preference: 0 Cost: 100
NextHop: 2.0.1.1 Interface: GigabitEthernet3/1/2
BkNextHop: 0.0.0.0 BkInterface:
RelyNextHop: 2.0.2.1 Neighbor : 2.0.1.1
Tunnel ID: 0x0 Label: NULL
State: Active Adv Age: 00h09m54s
Tag: 0
The above output shows that Router C has one route to reach network 1.1.1.0/24, that is, Router C<—>Router D<—>Router A.
Troubleshooting BGP
BGP peer relationship not established
Symptom
Display BGP peer information by using the display bgp peer command. The state of the connection to a peer cannot become established.
Analysis
To become BGP peers, any two routers must establish a TCP session using port 179 and exchange Open messages successfully.
Solution
1. Use the display current-configuration command to check that the peer’s AS number is correct.
2. Use the display bgp peer command to check that the peer’s IP address is correct.
3. If a loopback interface is used, check that the loopback interface is specified with the peer connect-interface command.
4. If the peer is a non-direct EBGP peer, check that the peer ebgp-max-hop command is configured.
5. If the peer ttl-security hops command is configured, check that the command is configured on the peer, and the hop-count values configured on them are greater than the number of hops between them.
6. Check that a valid route to the peer is available.
7. Use the ping command to check the connectivity to the peer.
8. Use the display tcp status command to check the TCP connection.
9. Check whether an ACL disabling TCP port 179 is configured.