Introduction
The Border Gateway Protocol (BGP) uses a path-vector routing algorithm to exchange routing information between BGP speakers. The routing information includes the actual route prefix for a destination, the path of autonomous systems to the destination, and additional path attributes.
Path Selection and Load Balancing
BGP selects a single path, by default, as the best path to a destination host or network. You can influence BGP path selection by altering some attributes through configuring BGP policies. BGP also supports load balancing or equal-cost multipath (ECMP), which allows for load-balancing traffic over multiple best paths.
Version Support
Cisco NX-OS supports BGP version 4, which includes multiprotocol extensions for carrying routing information for IP multicast routes and multiple Layer 3 protocol address families. BGP uses TCP (Port 179) as a reliable transport protocol to create TCP sessions with other BGP-enabled devices.
Autonomous Systems
The BGP autonomous system (AS) is a network controlled by a single administration entity, forming a routing domain with one or more Interior Gateway Protocols (IGPs) and a consistent set of routing policies. BGP supports both 16-bit and 32-bit autonomous system numbers.
Internal and External BGP
BGP speakers within the same autonomous system can exchange routing information through internal BGP (iBGP) peering sessions, while those in external BGP autonomous systems dynamically exchange routing information through external BGP (eBGP) peering sessions.
AS Number Formats
BGP supports 2-byte or 4-byte AS numbers. Cisco NX-OS displays 4-byte AS numbers in plain-text notation (that is, as 32-bit integers). You can configure 4-byte AS numbers as either plain-text notation (for example, 1 to 42,94,967,295) or AS.dot notation (for example, 1.0)
BGP PEERING
Introduction
A BGP speaker does not discover and peer with another BGP speaker automatically. Relationships between BGP speakers must be configured manually. A BGP peer is a BGP speaker that has an active TCP connection to another BGP speaker.
Connection and Data Exchange
BGP uses TCP port 179 to create a TCP session with a peer. Once a TCP connection is established, each BGP peer initially exchanges all of its routes, the complete BGP routing table, with the other peer. After this initial exchange, BGP peers send only incremental updates when a change in network topology or a routing policy change occurs. Between updates, peers exchange special messages called keepalives.
Hold Time
The hold time is the maximum time that can elapse between receiving consecutive BGP update or keepalive messages.
Peer Configuration
Cisco NX-OS supports various peer configuration options, including individual IPv4 or IPv4 addresses, IPv4 or IPv6 prefix peers for a single AS number, and dynamic AS number prefix peers. Cisco NX-OS accepts a range or list of AS numbers to establish BGP sessions but does not categorize prefix peers with dynamic AS numbers as iBGP or eBGP sessions until after the session is established.
Router ID
To establish BGP sessions between peers, BGP must have a router ID, which is a unique 32-bit value often represented by an IPv4 address. This router ID is sent to BGP peers in the OPEN message when a BGP session is established. By default, Cisco NX-OS sets the router ID to the IPv4 address of a loopback interface on the router. If no loopback interface is configured, the software chooses the highest IPv4 address configured to a physical interface on the router to represent the BGP router ID.
Note on Router ID
If BGP does not have a router ID, it cannot establish any peering sessions with BGP peers.
BGP Path Selection
The best-path algorithm runs each time a path is added or withdrawn for a given network.
PATH SELECTION
Introduction
The best-path algorithm in BGP runs each time a path is added or withdrawn for a given network, and when there’s a change in BGP configuration. The algorithm selects the best path from the set of valid paths available.
Step 1: Comparing Pairs of Paths
Cisco NX-OS uses several criteria to compare two paths and determine the better one. These include the path’s validity, its weight, local preference, whether it is locally originated, AS-path length, origin type, MED (multi-exit discriminator), peer type (internal vs. external), IGP metric to next-hop, previous selection status, router ID, cluster length, and the IP address of the peer.
Step 2: Determining the Order of Comparisons
Paths are partitioned into groups, and MEDs compared within each group, resulting in a chosen group for each neighbor AS. The best path within each group is determined through iterative comparison, and the overall best path selected from the set of best paths from each group.
Step 3: Determining the Best-Path Change Suppression
The new best path may be suppressed to avoid route changes, continuing with the existing best path if identical. Suppression can be turned off to always prefer the new best path. However, suppression is not possible under certain conditions such as when the existing best path is no longer valid, when paths have different weights, preferences, origins, IGP metrics, or MEDs.
Note
The order of comparison is important as some BGP metrics apply only among paths from the same neighboring AS. The path selection uses the BGP AS-path attribute, which includes the list of AS numbers traversed in the path.
MBGP
Multiprotocol BGP (MBGP) allows BGP to carry different types of network protocol routes depending on the address family in use. This means that BGP could handle one set of routes for IPv4 unicast routing, another set for IPv4 multicast routing, and yet another set for IPv6 multicast routing.
- MBGP expands BGP’s capabilities beyond the standard IPv4 unicast routing, enabling it to carry routing information for multiple network protocols and address families. Examples include IPv4 multicast, IPv6 unicast, and IPv6 multicast routes.
- MBGP plays a crucial role in IP multicast networks, assisting in Reverse Path Forwarding (RPF) checks, which help prevent looping in multicast routing. However, for multicast state information, another protocol like Protocol Independent Multicast (PIM) is required.
- MBGP maintains separate Routing Information Bases (RIBs) for each configured address family. This could include a unicast RIB and a multicast RIB for BGP.
- To use MBGP, you need to configure ‘router address-family‘ and ‘neighbor address-family‘ modes. MBGP is backward compatible, which means it can operate with peers that don’t support multiprotocol extensions. However, such peers cannot forward routing information that these extensions carry, like address family identifier information.
BGP CONFIGURATIONS
BGP (Border Gateway Protocol) is a protocol used to exchange routing information across autonomous systems (AS) on the internet. It has various default parameters and requires specific configurations for its proper functioning.
Default BGP Parameters
BGP feature: Disabled by default
Keepalive interval: 60 seconds
Hold timer: 180 seconds
BGP PIC core: Enabled
Auto-summary: Always disabled
Synchronization: Always disabled
BGP and NX-OS Feature Licenses:
Cisco NX-OS requires specific licenses for enabling BGP. These licenses differ based on the platform (Cisco Nexus series). The Enterprise Services Package (LAN_ENTERPRISE_SERVICES_PKG) is commonly used across various platforms to enable BGP.
BGP Configuration Limitations:
BGP comes with certain limitations that are important to keep in mind while configuring. Some of them are:
- Dynamic AS number prefix peer configuration overrides the individual AS number configuration inherited from a BGP template.
- In AS confederation, BGP only establishes sessions with the AS numbers within the local confederation if a dynamic AS number for prefix peers is configured.
- BGP sessions created through a dynamic AS number prefix peer ignore any configured eBGP multihop TTL value or a disabled check for directly connected peers.
- It’s advised to configure a router ID for BGP to avoid automatic router ID changes and session flaps.
- Use the maximum-prefix configuration option per peer to restrict the number of routes received and system resources used.
- Configure the update source for establishing a session with BGP/eBGP multihop sessions.
- A BGP policy should be specified if you configure redistribution.
- The BGP router ID should be defined within a VRF.
- If the keepalive and hold timer values are decreased, BGP session flaps might occur.
- The BGP minimum route advertisement interval (MRAI) value for all iBGP and eBGP sessions is zero and is not configurable.
BFD
Bidirectional Forwarding Detection (BFD) is a network protocol used for quick detection of faults in the path between two forwarding engines. BFD provides sub-second failure detection between two neighboring devices. It can be less CPU-intensive than protocol hello messages because some of the BFD load can be offloaded onto the data plane on supported modules.
In Cisco NX-OS, BFD operates in asynchronous mode, which involves sending BFD control packets between two adjacent devices to activate and maintain BFD neighbor sessions. Both devices, or BFD neighbors, must be configured with BFD.
Once BFD is enabled on the interfaces and the appropriate protocols, Cisco NX-OS establishes a BFD session, negotiates session parameters, and starts sending BFD control packets to each BFD neighbor at the agreed interval.
Key BFD session parameters include:
Desired minimum transmit interval: This is the interval at which the device wishes to send BFD hello messages.
Required minimum receive interval: This is the minimum interval at which this device can accept BFD hello messages from another BFD device.
Detect multiplier: This is the number of missed BFD hello messages from another BFD device that triggers the local device to detect a fault in the forwarding path.
RAPID DETECTION
Rapid Detection of Failures employs Bidirectional Forwarding Detection (BFD) sessions for fast failure identification. Once a BFD session is established and timer negotiations are done, BFD neighbors exchange BFD control packets similarly to an Interior Gateway Protocol (IGP) hello protocol, but at a higher rate. While BFD detects a failure, the protocol itself must act to circumvent a failed peer.
Upon detecting a failure in the forwarding path, BFD sends a failure detection notice to the BFD-enabled protocols. The local device can then trigger the protocol recalculation process, minimizing the overall network convergence time.
There are some constraints to consider when configuring BFD:
- Cisco NX-OS supports BFD version 1.
- Cisco NX-OS only supports IPv4.
- BFD supports single-hop BFD, including both single-hop EBGP and iBGP peers for BFD in BGP.
- BFD relies on Layer 3 adjacency information to discover changes in topology, including Layer 2 topology changes. For instance, a BFD session on a VLAN interface (SVI) may not be up after the convergence of the Layer 2 topology if no Layer 3 adjacency information is accessible.
- When using port channels for BFD, the Link Aggregation Control Protocol (LACP) must be enabled on the port channel.
- While Hot Standby Router Protocol (HSRP) for IPv4 is compatible with BFD, HSRP for IPv6 does not support BFD.