Skip to main content

BGP - Key concepts

 BGP Overview – RFC 4271

BGP (Border Gateway Protocol) is an Exterior Gateway Protocol (EGP) that exchanges routing information between autonomous systems (AS), distinguishing it from IGPs (e.g., RIP, EIGRP, OSPF). It relies on TCP (port 179) for communication and can establish peering relationships between routers across multiple hops. BGP is ideal for managing routes in a multi-homed environment, offering fine control over route selection through its robust best path algorithm, which considers various Path Attributes (PAs) like AS_PATH, LOCAL_PREF, and more.

Autonomous System (AS)

An AS is a connected group of one or more IP prefixes managed by one or more network operators with a single routing policy. BGP uses the AS Path (a unique identifier) to track the number of ASs a route passes through. Each AS is identified by a unique ASN (Autonomous System Number).

When to Use BGP

  • BGP is most useful when there are at least two Internet connections and you want to control outbound traffic by choosing specific paths for different destinations.
  • It is also effective for internal networks where multiple routers use iBGP to communicate BGP routes.

Technical Tip: The interior routing within an AS can be handled by a combination of BGP and static routes.

BGP Address Family (AFI/SAFI)

BGP was initially designed for IPv4 routing. Multi-Protocol BGP (MP-BGP) was introduced with RFC 2858, allowing the protocol to support different network protocols such as IPv6 and multicast through the use of the Address Family Identifier (AFI) and the Sub Address Family Identifier (SAFI). This separation is achieved using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes, which carry network reachability information for different address families.

BGP Path Selection and Peer Relationships

BGP uses a step-by-step decision process based on various PAs to determine the best route to a destination. It does not calculate a metric for each alternative route like IGPs but instead compares PAs.

  1. Highest Weight: Local to the router and only applicable on Cisco routers.
  2. Highest Local Preference: Preference across the AS.
  3. Route Originated by the Local Router: Routes originated by the router itself.
  4. Shortest AS Path: The route with the fewest AS hops.
  5. Lowest Origin Code: IGP < EGP < Incomplete.
  6. Lowest MED (Multi-Exit Discriminator): Used to prefer one path over another between different ASs.
  7. Prefer eBGP over iBGP: External paths are preferred over internal ones.
  8. Lowest IGP Metric: For iBGP routes, prefer the path with the lowest IGP metric.
  9. Oldest eBGP Path: For eBGP routes, prefer the oldest path (longest uptime).
  10. Lowest Neighbor BGP Router ID.
  11. Lowest Neighbor IP Address: In case of multiple paths to the same neighbor.

Troubleshooting Tip: Routes received from one iBGP neighbor are not advertised to another iBGP neighbor. eBGP routes are preferred over iBGP routes because of lower AD (Administrative Distance), with eBGP having an AD of 20, iBGP having 200, and locally injected routes also having an AD of 200.

BGP Update Messages

BGP update messages contain three main parts: Withdrawn Routes, Path Attributes (PAs), and NLRI (Network Layer Reachability Information). BGP does not calculate a metric for routes but uses PAs like AS_PATH and LOCAL_PREF to make routing decisions. Routes that share the same PAs are bundled in the same update, reducing CPU load and bandwidth consumption.

Technical Tip: BGP doesn’t advertise incremental updates. Instead, it sends full updates with routes that share the same set of PAs.

BGP Attributes

  • AS_PATH (Well Known, Mandatory): A list of ASNs that shows the path taken to reach the destination network.
  • NEXT_HOP (Well Known, Mandatory): The next-hop router IP address to reach the destination.
  • MED (Optional, Non-transitive): The BGP metric, used to influence path selection between ASs.
  • LOCAL_PREF (Well Known, Discretionary): Used to influence exit points within an AS. Higher values are preferred.
  • ATOMIC_AGGREGATE (Well Known, Discretionary): Indicates that information was lost when summarizing routes.
  • AGGREGATOR (Optional, Transitive): Used when a router aggregates a range of prefixes.

BGP Troubleshooting

Common commands for BGP troubleshooting include:

  • show ip bgp summary: Displays the status of BGP neighbors.
  • show ip bgp neighbor x.x.x.x advertised-routes: Shows the routes advertised to a specific neighbor.
  • ping x.x.x.x: Checks connectivity to the neighbor.
  • telnet neighbor-ip 179: Verifies if the BGP session can be established.
  • traceroute neighbor-ip: Checks the hop count and identifies TTL issues.
  • debug ip bgp and debug ip icmp: Detects errors such as TTL expiry.
  • show tcp statistics and show ip traffic: Provides insights into TCP and BGP statistics.

Troubleshooting Tip: If TTL is expiring, ensure you increase the TTL value using the neighbor ebgp-multihop command when establishing peering with eBGP neighbors across multiple hops.

BGP Route Reflectors

In a typical iBGP setup, all routers within an AS must be fully meshed, which can be inefficient. Route reflectors are used to reduce the need for a full mesh of iBGP peers. Route reflectors reflect routes learned from client peers to other clients and non-clients.

  1. Routes learned from eBGP peers: Can be sent to both clients and non-clients.
  2. Routes learned from client peers: Can be sent to eBGP peers, other client peers, and non-client peers.
  3. Routes learned from non-client peers: Can be sent to eBGP peers and client peers, but not to other non-client peers.

Technical Tip: Only routes that the route reflector considers “best” are reflected to other peers. This limits redundant routes being advertised, improving efficiency.

BGP Filtering and Manipulation

BGP allows advanced route filtering through various methods:

  • Distribution Lists: Filters routes using access lists.
  • Prefix Lists: Filters based on IP prefixes.
  • AS_PATH Access Lists: Filters based on AS paths.
  • Route Maps: Used to apply filtering policies and manipulate PAs.

Technical Tip: Use AS_PATH filters with regular expressions to fine-tune which routes are accepted or advertised.

Prepending ASNs

In cases where you want to influence inbound traffic, you can prepend your ASN multiple times to the AS_PATH. This increases the AS_PATH length, making the route less preferred to remote ASs.

Technical Tip: Prepending can be useful when managing multiple connections between ASs and preferring one path over another for inbound traffic.

BGP Default Route Injection

BGP supports four methods of injecting a default route:

  1. Network 0.0.0.0: Injects a default route only if it already exists in the routing table.
  2. Redistribution: Redistributes the default route if it exists and is learned from another routing protocol.
  3. Default-Information Originate: Injects a default route into BGP regardless of its existence in the routing table.
  4. Neighbor Default Originate: Injects a default route only to a specific neighbor.

Technical Tip: The neighbor default-originate command does not install the default route in the BGP RIB of the router itself, but it is advertised to the specified neighbor.

BGP Soft Reconfiguration and Route Refresh

BGP soft reconfiguration allows policy changes without resetting BGP sessions. By enabling neighbor soft-reconfiguration inbound, routers store pre-filtered routes and can reprocess them when a policy change occurs. The clear ip bgp command with the soft keyword can perform a soft reset.

Technical Tip: Soft resets are less disruptive and should be preferred over hard resets (clear ip bgp *), which bring down the TCP session and remove all BGP-learned routes from the peer.

Route Reflectors and Confederations

Confederations divide an AS into sub-ASs, reducing the number of iBGP sessions required. Confederation eBGP sessions act like regular eBGP sessions in most respects, including using TTL=1 by default. Confederation ASNs are removed from the AS_PATH when advertised outside the confederation, preventing confusion in external ASs.

Technical Tip: Route reflectors and confederations help scale BGP in large autonomous systems by reducing peer connection overhead while maintaining full route visibility.

BGP Best Path Selection – Tie Breakers

If BGP cannot determine the best path using the main criteria (weight, local preference, etc.), it uses the following tie-breakers:

  1. Prefer the oldest eBGP path.
  2. Prefer the smallest BGP router ID.
  3. Prefer the path with the lowest neighbor IP address.

Technical Tip: BGP adds only one best path to the IP routing table unless multiple paths are tied after the main decision-making steps.

Additional Features: Multipath and Add-Path

BGP supports multipath, allowing multiple equal-cost paths to be added to the routing table for load balancing. The maximum-paths command is used to enable this feature.

Technical Tip: BGP does not load balance across multiple paths by default. You must configure it explicitly using the maximum-paths command to allow multiple routes to the same destination.

BGP Synchronization and Route Reflectors

BGP synchronization is a concept that requires iBGP-learned routes to be present in the IGP routing table before they can be considered the "best" route. This ensures that routers in the AS can reach the destination. However, BGP synchronization can be disabled if iBGP is enabled on all routers in the AS, preventing routing issues like blackholes.

  • Sync Exception with OSPF: If the OSPF RID differs from the BGP RID for the same prefix, BGP will not consider the route as the best. Configuring the same RID for OSPF and BGP on the same router helps avoid this issue.

Technical Tip: Disabling BGP synchronization and running BGP on all routers is a common method to ensure the network is free of blackholes. However, doing so increases the iBGP peering overhead.

Route Reflectors

Route reflectors (RRs) reduce the need for a full iBGP mesh within an AS by allowing a route reflector to reflect routes to its clients. The route reflector modifies the following attributes:

  • Cluster List: Prevents loops by tracking the route reflectors that handled the route.
  • ORIGINATOR_ID: Identifies the BGP router that first advertised the route into the AS.

Technical Tip: Configure the bgp cluster-id command to manually set the cluster ID. The cluster ID prevents routing loops by tracking where the route has been reflected.

BGP Aggregation and AS_PATH Manipulation

BGP supports route aggregation, allowing multiple prefixes to be summarized into a single prefix. When using aggregation, you can optionally include an AS_SET to retain the AS_PATH information from the component routes. This is useful for loop prevention.

  • Suppress Map: Suppresses specific subnets from being advertised while still aggregating them into a larger prefix. This is done with the suppress-map command, which references a route map to filter the suppressed subnets.

Technical Tip: The aggregate-address command with the summary-only keyword creates a summary route while suppressing specific component subnets. Be cautious when using route aggregation to ensure that the routing policies meet your network's requirements.

BGP Conditional Advertisement

BGP allows conditional advertisements based on the presence or absence of other routes. The advertise-map and non-exist-map commands are used for conditional advertisement.

  • Example: Advertise a route to a specific network only if another route is down.

Technical Tip: Conditional advertisements are useful for controlling route advertisements based on the availability of other networks. Use the advertise-map and non-exist-map options to define these conditions.

BGP Filtering

BGP supports filtering routes through a variety of mechanisms:

  • Distribution Lists: Filter routes based on access lists.
  • Prefix Lists: Filter based on IP prefixes.
  • AS_PATH Filters: Match routes based on AS_PATH regular expressions.
  • Route Maps: Apply policy-based routing using matching conditions and set commands.

Technical Tip: BGP filters using AS_PATH regular expressions provide fine-grained control over which routes to accept or reject. Example: Use ^$ to match local routes (routes originated in the same AS).

AS_PATH Prepending

AS_PATH prepending is a method to make a route less attractive by artificially increasing the AS_PATH length. This is done by repeating your own ASN multiple times in the AS_PATH, causing remote ASs to prefer a different path.

Technical Tip: Prepending is often used to influence inbound traffic, making one path less preferred than another by increasing the AS_PATH length artificially.

BGP Confederations

Confederations divide an AS into smaller sub-ASs. Within a sub-AS, iBGP rules apply, but between sub-ASs, the confederation acts like eBGP. Confederations reduce the number of iBGP peers required in large networks, allowing more scalable BGP deployments.

  • Confederation ASNs: Private ASNs (64512–65535) are used within the confederation, and these ASNs are stripped from the AS_PATH when advertised externally.

Technical Tip: Confederations are useful in large-scale BGP deployments where scaling full iBGP meshes is challenging. They reduce the number of iBGP peer connections required, improving network manageability.

BGP Backdoor Routes

The network backdoor command allows BGP to treat specific routes as internal (with an AD of 200) instead of external (AD of 20). This causes the router to prefer the IGP route over the BGP-learned route for specific prefixes.

Technical Tip: Use the network backdoor command for prefixes where you want to prioritize IGP-learned routes over eBGP-learned routes. This is useful when you want to use a private link to reach certain networks.

BGP Dampening

BGP dampening reduces the impact of route flapping by suppressing routes that change state frequently. It assigns a penalty to flapping routes, and when the penalty exceeds a threshold, the route is suppressed for a specific duration.

Technical Tip: Use bgp dampening to prevent flapping routes from affecting network stability. Fine-tune the parameters based on your network’s tolerance for route instability.

BGP Route Reflector Clusters

Route reflectors can be grouped into clusters to prevent loops within a network. Each cluster is identified by a Cluster ID, and the CLUSTER_LIST attribute tracks the reflectors that have handled the route to prevent loops.

  • ORIGINATOR_ID: Identifies the first router to advertise the route into the AS, helping prevent routing loops.

Technical Tip: Configure the bgp cluster-id to manually set the Cluster ID for route reflectors. This attribute prevents routing loops when using multiple route reflectors in a network.

BGP Route Reflector Configuration

  • On the Route Reflector: Configure clients using the neighbor x.x.x.x route-reflector-client command.
  • On the Client: No changes are required on the client; the route reflector manages the changes.

Technical Tip: Only route reflectors modify attributes; clients and non-client peers operate normally. RRs advertise only the best routes to peers, reducing unnecessary routing updates.

Route Maps and Filtering

Route maps are essential for applying BGP routing policies. They allow you to match specific route attributes (e.g., prefix, AS_PATH) and then modify the PAs to influence BGP’s decision process.

  • Filtering Subnets: Use the aggregate-address command with route maps to filter specific subnets while advertising aggregated routes.

Technical Tip: Route maps are powerful tools for BGP policy enforcement. They allow detailed control over which routes are advertised, accepted, or manipulated.

BGP Decision Process – Path Selection

The BGP decision process selects the best path based on the following attributes in order:

  1. Highest Weight (local to router)
  2. Highest Local Preference (global within AS)
  3. Route originated by the local router
  4. Shortest AS Path
  5. Lowest Origin Code (IGP < EGP < Incomplete)
  6. Lowest MED
  7. Prefer eBGP over iBGP
  8. Lowest IGP Metric to the NEXT_HOP
  9. Oldest eBGP Path
  10. Lowest BGP Router ID
  11. Lowest Neighbor IP Address

If the decision process reaches steps 10 or 11, tie-breaking logic applies, often leading to choosing the route with the lowest router ID or IP address.

Technical Tip: Only one route is typically advertised to neighbors, even if multiple routes are considered best by the router.

Soft Reconfiguration and Route Refresh

Soft reconfiguration allows routers to apply policy changes without tearing down BGP sessions. The clear ip bgp x.x.x.x soft command refreshes the BGP session, reapplying the inbound or outbound policies without resetting the TCP connection.

  • Route Refresh: If the BGP session supports the route refresh capability, soft resets can be performed, and the peer will re-advertise routes based on the new policies.

Technical Tip: The neighbor x.x.x.x soft-reconfiguration inbound command is required to see pre-filtered BGP updates. This command stores all inbound updates, consuming additional memory.

Removing Private ASNs

Private ASNs (64512–65535) are not advertised to the public Internet. Use the remove-private-as command to strip private ASNs from the AS_PATH when advertising routes externally.

Technical Tip: Removing private ASNs is essential when connecting to the public Internet. Ensure your router removes these ASNs before advertising routes to an upstream provider.

BGP Multi-Homing and Load Balancing

BGP supports multi-homing for organizations with multiple connections to different ISPs. Load balancing can be achieved using equal-cost multipath routing, which requires the maximum-paths command.

Technical Tip: BGP does not perform load balancing by default. Configure the maximum-paths command to allow multiple equal-cost paths for redundancy and load sharing.

Conclusion

BGP is a powerful and flexible routing protocol essential for managing large-scale networks, multi-homed connections, and complex route policies. It uses a stepwise path selection process, robust filtering mechanisms, and features like route reflectors, confederations, and AS_PATH manipulation to ensure efficient and loop-free routing across autonomous systems.

Comments

Popular posts from this blog

Basic MPLS BGP and L3VPN Lab Setup

In this lab, we’ve set up a basic MPLS, BGP, and L3VPN environment, which is a great foundation for understanding how service providers build scalable networks. The lab uses the EVE-NG simulator along with Router IOS C7200-ADVENTERPRISEK9-M, Version 15.2(4)M8 to emulate a realistic MPLS environment. Below is a summary of the key components and roles of each router in the lab. MPLS Core Routers : The MPLS core consists of the routers responsible for label switching and forwarding customer traffic through the network: PE1 (Provider Edge 1) : Connects customer networks to the MPLS core and handles both MPLS and BGP routing. It also hosts VRF (Virtual Routing and Forwarding) instances for customers. PE2 (Provider Edge 2) : Functions similarly to PE1, connecting another customer network to the MPLS core. P1 (Core Router 1) and P2 (Core Router 2) : These routers serve as MPLS core routers and handle label switching but do not store or process customer routes directly. They simply f

OSPF Adjacency Stuck in EXSTART on Cisco IOS XR – Issue and Solution

In a recent lab setup using Cisco IOS XR on EVE-NG, I faced a common but frustrating issue with OSPF adjacencies getting stuck in the EXSTART state. After spending considerable time troubleshooting interface MTUs and configurations, I discovered that the root cause was related to the virtual network interface type being used. This post outlines the issue, troubleshooting steps, and the eventual solution that got everything working. Issue: While configuring OSPF between two routers running Cisco IOS XR in my lab, OSPF adjacencies were getting stuck in the EXSTART state. I verified that interface configurations, MTU settings, and OSPF parameters were correct, but the problem persisted. I tried adjusting the MTU size, using the mtu-ignore command, and even checked for ACLs, but nothing seemed to resolve the issue. Troubleshooting Steps: MTU Settings: I started by verifying that both sides of the OSPF adjacency had matching MTUs. I used the default MTU and even tried different values wit

How to Properly Clone an EVE-NG Lab with Configurations

Cloning labs in EVE-NG is a great way to duplicate setups and expand or experiment on a new copy without affecting the original lab. However, if not done correctly, the cloned lab may only copy the topology without configurations. In this guide, I’ll show you how to properly clone a lab in EVE-NG with all configurations using the EVE-NG GUI . Follow these steps to ensure that both the topology and router configurations are retained when cloning your lab. Steps to Clone an EVE-NG Lab with Configurations Save Running Configuration on All Devices In your original lab, make sure all devices have their configurations saved to NVRAM. Go into the CLI of each router and run the command: copy running-config startup-config Export All Configurations (CFGs) On the left sidebar in the EVE-NG Web UI , click on the "More Actions" option. Then select "Export all CFGs" . This step exports the configurations of all devices in the lab. Shutdown All Devices After exporting the confi