Configuring a BGP Router ID
The router ID should be configured first when you configure BGP. The router ID is a string similar to the IP address, and is the identifier of a BGP router in an AS. You should not change the router ID after completing the configuration. By default, the BGP router ID is not configured.
Configuring BGP Local-AS
The local AS (autonomous system) should be configured first when you configure BGP.
The AS_Path attribute records to all the AS's that a route passes through, from the source to the destination, following the order of vectors.
Configuring External BGP Peering
If the AS number of the specified peer is different from the local AS number during the configuration of BGP peers, an EBGP peer is configured. To establish point-to-point connections between peer autonomous systems, configure a BGP session on each interface of a point-to-point link. Generally, such sessions are made at network exit points with neighboring hosts outside the AS.
Configuring Internal BGP Peering
If the AS number of the specified peer is the same as the local AS number during the configuration of BGP peers, an IBGP peer is configured.
Configuring the BGP Local Preference
Internal BGP (IBGP) sessions use a metric called the local preference, which is carried in IBGP update packets in the path attribute LOCAL_PREF. When an autonomous system (AS) has multiple routes to another AS, the local preference indicates the degree of preference for one route over the other routes. The route with the highest local preference value is preferred.
Configuring BGP MED
The multi-exit discriminator (MED) helps determine the optimal route for the incoming traffic of an AS, and is similar to the metric used in IGP. When a BGP device obtains multiple routes to the same destination address but with different next hops from EBGP peers, the BGP device selects the route with the smallest MED value as the optimal route.
Configuring BGP Next Hop
When an Autonomous System Boundary Router (ASBR) forwards the route learned from an EBGP peer to an IBGP peer, the ASBR, by default, does not change the next hop of the route. When the IBGP peer receives this route, it finds the next hop unreachable, sets the route to inactive, and does not use this route to guide traffic forwarding.
To enable the IBGP peer to use this route to guide traffic forwarding, configure the ASBR to set its IP address as the next hop of the route when the ASBR forwards this route to the IBGP peer. After the IBGP peer receives this route from the ASBR, it finds the next hop of the route reachable, sets the route to active, and uses this route to guide traffic forwarding.
When a BGP route changes, BGP needs to iterate the indirect next hop of the route again. If no restriction is imposed on the iterated route, BGP may iterate the next hop to an incorrect forwarding path, causing traffic loss. Configure routing policy-based route iteration to prevent traffic loss.
Configuring BGP Route Reflectors
To ensure the connectivity between IBGP peers within an AS, you need to establish full-mesh connections between the IBGP peers. When there are many IBGP peers, it is costly to establish a fully meshed network. A route reflector (RR) can solve this problem.
A cluster ID can help prevent routing loops between multiple RRs within a cluster, and between clusters. When a cluster has multiple RRs, the same cluster ID must be configured for all RRs within the cluster.
If full-mesh IBGP connections are established between clients of multiple RRs, route reflection between clients is not required and wastes bandwidth resources. In this case, prohibit route reflection between clients to reduce the network burden.
Within an AS, an RR transmits routing information and forwards traffic. When an RR connects to a large number of clients and non-clients, many CPU resources are consumed if the RR transmits routing information and forwards traffic simultaneously. This also reduces route transmission efficiency. To improve route transmission efficiency, prohibit BGP from adding preferred routes to IP routing tables on the RR, enabling the RR to only transmit routing information.
Configuring BGP Confederations
A confederation divides an AS into sub-AS's, which establish EBGP connections. Within each sub-AS, IBGP peers establish full-mesh connections or have an RR configured. On a large BGP network, configuring a confederation can reduce the number of IBGP connections, simplify routing policy management, and improve route advertisement efficiency.
Configuring the BGP Connect Timer
Hold timers can be configured for all peers. The proper maximum interval at which 'keep alive' messages are sent is one third the hold time.
Configuring MD5 Authentication for TCP Connections
Configure Message Digest5 (MD5) authentication on a TCP connection between two BGP peers. The two peers must have the same configured password to establish TCP connections.
Configuring EBGP Fast-External-Fallover
This feature allows BGP to immediately respond to a fault on an interface, and delete the direct EBGP sessions on the interface without waiting for the hold timer to expire. It implements rapid BGP network convergence. By default, EBGP fast-external-fallover is disabled.
Configuring BGP Route Summarization
BGP supports both automatic and manual route summarization. Manual route summarization takes precedence over automatic.
Configure automatic route summarization as follows:
BGP auto-summary true summarizes the routes exported by BGP.
To configure manual route summarization:
Configuring BGP to Advertise Default Routes to Peers
The BGP device can be configured to send only a default route, with the local address as the next hop address, to its peer, regardless of whether there are default routes in the local routing table.
Configuring BGP to Remove Private AS Numbers
Private autonomous system (AS) numbers that range from 64512 to 65535 are used to conserve globally unique AS numbers. BGP can remove private AS numbers from updates to a peer.
Configuring BGP AS Loop
Repeated local AS numbers are allowed in routes. In the default setting, however, repeated local AS numbers are not allowed.
Configuring BGP Load Balancing
If multiple paths to a destination exist, you can configure load balancing over such paths to improve link utilization.
Enable BGP load balancing:
BGP will not load balance across multiple paths by default. This is acceptable if you are multi-homed to a single AS, but if multi-homed to different AS path, you cannot load balance across theoretically equal paths.
Enter the BGP multipath path-relax command: