Linked Image Example Become a Network Expert for Top Product Companies
BGP Cheatsheet - Part 1 (Detailed Content)
sprintgrad.com

BGP CHEATSHEET (Detailed Version)

Introduction to BGP

Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among Autonomous Systems (ASes) on the Internet.

Core Functions & Features:

  • Inter-AS Routing: Primary protocol for routing between different ASes.
  • Path Vector Protocol: Makes routing decisions based on paths (sequences of ASes) and policies (defined by path attributes).
  • Policy Control: Offers extensive mechanisms (Path Attributes) to influence routing decisions for both inbound and outbound traffic.
  • Scalability: Designed to handle the vast scale of the Internet routing table (millions of routes). Features like Route Reflectors, Confederations enhance scalability.
  • Reliability: Uses TCP (port 179) for reliable transport of BGP messages. Employs loop avoidance mechanisms.
  • Stability: Includes features like Minimum Advertisement Interval (MAI), Route Dampening, and Summarization to minimize routing churn.

Internet Terminology Relevant to BGP:

  • Autonomous System (AS): A collection of IP networks and routers under a single administrative domain. Each AS has a unique AS Number (ASN).
  • IP Transit Link: A paid service where a customer AS connects to a provider AS for internet connectivity.
  • Peering Link: A settlement-free interconnection where two ASes exchange traffic destined for each other's networks and customers, but not for transiting to the broader internet.
    • Private Peering: Direct physical connection.
    • Public Peering: Occurs at an Internet Exchange Point (IXP).
  • Internet Exchange Point (IXP): A facility where different ASes connect to exchange traffic locally, reducing latency and transit costs.
  • Tiered ISPs (1, 2, 3): Describe an ISP's position in the internet hierarchy regarding transit and peering. Tier 1 ISPs form the global backbone.

EBGP vs. IBGP

EBGP (External BGP)

  • Peering between routers in different Autonomous Systems.
  • TTL for BGP messages is 1 by default. Use ebgp-multihop [ttl_value] if peers are not directly connected (e.g., loopback peering over multiple physical hops).
  • AS_PATH attribute is updated: the local ASN is prepended to the AS_PATH list when sending an update to an EBGP peer.
  • Next-hop address is changed to the IP address of the sending router's egress interface by default when advertising a route to an EBGP peer.

IBGP (Internal BGP)

  • Peering between routers in the same Autonomous System.
  • Used to propagate external routes (learned via EBGP) throughout the local AS to all IBGP speakers.
  • AS_PATH attribute is not modified when sending updates to an IBGP peer.
  • Next-hop address is not changed by default when an EBGP-learned route is advertised to an IBGP peer.
    • This means internal routers need a route to the original EBGP next-hop. Use neighbor next-hop-self on the border router (or RR) to advertise itself as the next-hop to IBGP peers.
  • IBGP sessions are often established between loopback interfaces for stability. This requires:
    • neighbor update-source loopback
    • An IGP (like OSPF or EIGRP) providing reachability to the loopback addresses within the AS.

Loop Avoidance Mechanisms

EBGP Loop Avoidance

The primary mechanism is the AS_PATH attribute. When a BGP router receives an UPDATE message from an EBGP peer, it examines the AS_PATH list. If the router sees its own AS number already present in the AS_PATH, it means the route has looped back. The router will discard this update to prevent a routing loop.

IBGP Loop Avoidance

Since the AS_PATH is not modified when updates are sent between IBGP peers, it cannot be used for loop prevention within an AS.

BGP Split Horizon Rule for IBGP: An UPDATE message learned from one IBGP peer will not be advertised to another IBGP peer. This rule is fundamental to preventing loops within an AS where AS_PATH isn't changing.

The IBGP split-horizon rule necessitates a full mesh of IBGP sessions among all routers within an AS if all routers are to receive all externally learned routes. For large ASes, this is not scalable. Solutions like Route Reflectors or Confederations are used to overcome this limitation.

BGP Messages

BGP communication uses TCP port 179 and involves several message types:

  1. OPEN: The first message sent after the TCP three-way handshake is complete. It is used to establish and negotiate BGP session parameters. Key contents:
    • BGP Version (typically v4)
    • Sender's AS Number (My AS Number)
    • Hold Time (default 180 seconds; the lower of the two peers' proposed values is used)
    • BGP Identifier (the sender's Router ID, must be unique between peers)
    • Optional Parameters (e.g., Capabilities like MP-BGP support, Route Refresh, 4-octet ASN support)
  2. UPDATE: Used to exchange routing information (advertise new routes or withdraw old ones). Key contents:
    • Withdrawn Routes: A list of NLRI (Network Layer Reachability Information - Prefix/Length) for routes that are no longer reachable and should be removed.
    • Path Attributes: A list of attributes (e.g., AS_PATH, NEXT_HOP, ORIGIN, LOCAL_PREF, MED, COMMUNITY) associated with the NLRI being advertised. These attributes describe the path and are used for policy and best-path selection.
    • NLRI: A list of prefixes (Prefix/Length) being advertised as reachable.
  3. KEEPALIVE: Sent periodically (default 60 seconds, typically 1/3 of the negotiated Hold Time) to ensure the BGP session remains active, especially if no UPDATE messages are being exchanged. If a peer does not receive a KEEPALIVE or an UPDATE message within its Hold Time, it will tear down the BGP session.
  4. NOTIFICATION: Sent to signal that an error condition has been detected (e.g., malformed message, unsupported capability, hold timer expiry). After sending or receiving a NOTIFICATION message, the BGP session is immediately closed. The message contains an Error Code and an Error Subcode to specify the nature of the error.
  5. ROUTE-REFRESH: (RFC 2918) An optional capability that allows a BGP speaker to request its peer to re-advertise its routes for a specific Address Family (AFI/SAFI) without needing to reset the entire BGP session. This is particularly useful for applying inbound policy changes.

BGP Neighbor States (FSM)

BGP uses a Finite State Machine (FSM) to manage the lifecycle of a neighbor relationship:

  1. Idle: In the BGP Idle state, the router initializes resources for a specific neighbor and clears any prior session data, effectively resetting the connection process. It's a passive state with no active TCP session. While prepared, the actual attempt to establish a connection (moving to Active/Connect) hasn't started. Failure to progress from Idle typically points to problems reaching the peer's IP.
  2. Connect: The BGP Connect state is entered when the router passively receives an incoming TCP SYN from a peer attempting to connect. In this state, the router responds (typically sending a SYN+ACK) to complete the TCP three-way handshake. Upon successful TCP connection establishment, it sends a BGP OPEN message and transitions to the OpenSent state. This passive listening role distinguishes it from the Active state.
  3. Active: The BGP Active state is where the router initiates a TCP connection to a neighbor by sending a SYN packet. Success leads to sending a BGP OPEN message and moving to the OpenSent state. Failure triggers a fallback to the Idle state, clearing previous context and starting a random timer before retrying.

    Frequent toggling between Idle, Connect, and Active states often indicates underlying TCP connectivity problems, such as incorrect peer IP, port 179 being blocked by a firewall, or no route to the peer.

  4. OpenSent: BGP has sent an OPEN message and is now waiting to receive an OPEN message from its peer. When the peer's OPEN message is received, BGP validates the parameters (e.g., AS number, BGP version, router ID uniqueness). If the parameters are acceptable, BGP sends a KEEPALIVE message and transitions to the OpenConfirm state. If there's a mismatch or error, BGP sends a NOTIFICATION message and transitions to the Idle state.
  5. OpenConfirm: BGP has received and validated the peer's OPEN message, and has also sent its own KEEPALIVE message as a confirmation of its parameters. In this state, BGP is waiting to receive a KEEPALIVE message from the peer. Receipt of a KEEPALIVE from the peer indicates that the peer has also successfully processed BGP's OPEN message. If a KEEPALIVE is received, the session transitions to the Established state. If the Hold Timer expires or another error occurs, a NOTIFICATION message is sent, and the state transitions to Idle.
  6. Established: The BGP peering session is fully operational. In this state, the peers can exchange UPDATE messages (to advertise or withdraw routes), KEEPALIVE messages (to maintain the session), and NOTIFICATION messages (if errors occur). This is the desired, stable state for a BGP session. In show ip bgp summary, when a neighbor is established, this column typically shows the number of prefixes received from that neighbor.

Path Attributes (PAs) - Overview

Path Attributes are pieces of information attached to BGP routes that describe the characteristics of a path to a destination network. They are carried in BGP UPDATE messages and are fundamental to BGP's policy enforcement and best path selection process.

Categories of Path Attributes:

  • Well-known Mandatory: These attributes must be recognized by all BGP implementations and must be present in all UPDATE messages for a route to be considered valid. If a mandatory attribute is missing, a NOTIFICATION message is sent, and the session may be reset.
    • Examples: AS_PATH, ORIGIN, NEXT_HOP.
  • Well-known Discretionary: These attributes must also be recognized by all BGP implementations, but they might not necessarily be present in every UPDATE message. If present, they are processed.
    • Examples: LOCAL_PREFERENCE, ATOMIC_AGGREGATE.
  • Optional Transitive: These attributes may or may not be recognized by a BGP implementation. If an implementation recognizes the attribute, it will process it according to its definition. If it does not recognize the attribute but it is marked as transitive, the router must pass it along unchanged to its other BGP peers.
    • Examples: AGGREGATOR, COMMUNITY.
  • Optional Non-transitive: These attributes also may or may not be recognized. If an implementation recognizes it, it's processed. If it does not recognize an optional non-transitive attribute, it must be discarded (ignored) and not passed along to other BGP peers.
    • Examples: MED (Multi-Exit Discriminator), ORIGINATOR_ID, CLUSTER_LIST.

PA: Weight

  • Type: Cisco proprietary. It is locally significant to the router on which it is configured.
  • Purpose: Used to influence outbound path selection from the local router. It is the very first attribute checked in Cisco's BGP best path selection algorithm.
  • Value Range: 0 to 65,535.
  • Preference: A path with a higher weight value is preferred over a path with a lower weight value.
  • Scope: Weight is not advertised to any BGP peers (neither EBGP nor IBGP). Its influence is strictly limited to the local router's path selection decisions.
  • Default Value (Cisco):
    • For routes learned from a BGP peer: 0.
    • For routes originated locally by the router (e.g., using the network command or redistribution): 32,768.
  • Configuration Methods:
    1. Per-neighbor basis:
      router bgp
      neighbor weight

      This assigns the specified weight to all routes learned from that particular neighbor.

    2. Per-prefix basis using a route-map: (Typically applied in the inbound direction)
      ip prefix-list TARGET_ROUTES permit 192.168.1.0/24
      !
      route-map SET_ROUTE_WEIGHT permit 10
      match ip address prefix-list TARGET_ROUTES
      set weight 500
      !
      route-map SET_ROUTE_WEIGHT permit 20 ! Optional: To permit other routes without specific weight setting
      !
      router bgp
      neighbor route-map SET_ROUTE_WEIGHT in

      This allows setting specific weights for specific prefixes learned from a neighbor.

PA: Local Preference

  • Type: Well-known Discretionary.
  • Purpose: Used within an Autonomous System (AS) to influence outbound path selection. It allows an AS to express a preference for one exit point (border router) over another when multiple exit points exist to reach external destinations.
  • Value Range: 0 to 4,294,967,295.
  • Preference: A path with a higher Local Preference value is preferred.
  • Scope: Local Preference is advertised to all IBGP peers within the same AS. It is not advertised to EBGP peers (i.e., it does not cross AS boundaries).
  • Default Value: 100 (for routes learned from any BGP peer or locally originated routes, if no other local preference is explicitly set).
  • Configuration Methods:
    1. Set a global default Local Preference on a router:
      router bgp
      bgp default local-preference

      This value will be applied to routes learned from EBGP peers before they are advertised to IBGP peers, and also to locally originated routes advertised to IBGP peers.

    2. Per-prefix basis using a route-map: (Typically applied in the inbound direction on an EBGP session to tag specific routes with a certain Local Preference before they are propagated via IBGP).
      ip prefix-list PREFERRED_EXIT_ROUTES permit 8.8.8.0/24
      !
      route-map APPLY_LOCAL_PREF_IN permit 10
      match ip address prefix-list PREFERRED_EXIT_ROUTES
      set local-preference 200
      !
      route-map APPLY_LOCAL_PREF_IN permit 20 ! Allow other routes (they'll get default LP or global default LP)
      !
      router bgp
      neighbor route-map APPLY_LOCAL_PREF_IN in
  • Local Preference is checked after Weight in the BGP route selection process.

PA: AS_PATH

  • Type: Well-known Mandatory.
  • Purpose:
    1. EBGP Loop Prevention: This is its primary loop prevention role. When a BGP router receives an UPDATE from an EBGP peer, it checks the AS_PATH. If the router's own AS number is found within the AS_PATH list, it indicates that the route has looped back to its originating AS (or an AS it has already transited in a more complex loop scenario). The router will discard such an update.
    2. Path Selection: BGP prefers paths with a shorter AS_PATH length. The length is the number of AS numbers in the AS_SEQUENCE. An AS_SET segment (used in aggregation) counts as length 1 for path selection, regardless of the number of ASNs within the set.
  • Behavior:
    • When a BGP router sends an UPDATE to an EBGP peer, it prepends (adds to the beginning) its own AS number to the AS_PATH list.
    • The AS_PATH is not modified when an UPDATE is sent to an IBGP peer.
  • AS_PATH Prepending:
    • A technique used to influence inbound traffic from other ASes.
    • By artificially lengthening the AS_PATH (adding its own AS number multiple times) when advertising routes to a specific EBGP peer, an AS can make that path appear less attractive to downstream ASes, encouraging them to choose an alternate path into the local AS (if one exists).
    • Configuration:
      ip prefix-list ROUTES_TO_PREPEND permit 192.168.0.0/16
      !
      route-map MAKE_PATH_LONGER out permit 10
      match ip address prefix-list ROUTES_TO_PREPEND
      set as-path prepend ! Prepend local AS twice
      !
      route-map MAKE_PATH_LONGER out permit 20 ! Allow other routes without prepending
      !
      router bgp
      neighbor route-map MAKE_PATH_LONGER out
  • AS_PATH Segments:
    • AS_SEQUENCE: An ordered list of ASNs that the route advertisement has traversed. Each AS in the sequence represents a hop.
    • AS_SET: An unordered set of ASNs. This typically arises when routes with different AS_PATHs are aggregated. The AS_SET contains all the ASNs from the AS_PATHs of the aggregated routes. For path length calculation in best path selection, an AS_SET segment counts as 1.
    • AS_CONFED_SEQUENCE / AS_CONFED_SET: Used within BGP Confederations to represent the path through member sub-ASes. This information is stripped and replaced by the public confederation identifier when routes are advertised outside the confederation.

PA: Origin Code

  • Type: Well-known Mandatory.
  • Purpose: Indicates the origin of the path information – how the route was initially injected into the BGP routing domain.
  • Values (listed in order of preference for best path selection):
    1. IGP (code 0, often displayed as 'i'): The route was originated within an AS using the network command in the BGP process. This is generally the most preferred origin type.
    2. EGP (code 1, often displayed as 'e'): The route was learned via the Exterior Gateway Protocol (EGP). EGP is an obsolete predecessor to BGP, so this origin code is rarely, if ever, seen in modern networks.
    3. Incomplete (code 2, often displayed as '?'): The origin of the route is unknown or learned through some other means, typically via redistribution from another routing protocol (e.g., OSPF, EIGRP, static routes) into BGP using the redistribute command. This is the least preferred origin type.
  • The preference order (IGP > EGP > Incomplete) reflects a historical view of route reliability and control. Routes advertised with the network command (IGP origin) are considered to be explicitly and authoritatively advertised by an AS, whereas redistributed routes (Incomplete origin) might have lost some path information or fidelity during the redistribution process.

PA: MED (Multi-Exit Discriminator)

  • Type: Optional Non-transitive. Also referred to as the "metric".
  • Purpose: Used to influence how a neighboring AS chooses to enter your AS when there are multiple BGP connections (multiple exit/entry points) between your AS and that specific neighboring AS. It's a hint to the neighbor about which entry point into your AS is preferred for traffic destined to prefixes you advertise. It primarily influences inbound traffic flow from that specific neighbor.
  • Value Range: 0 to 4,294,967,295.
  • Preference: A path with a lower MED value is preferred by the receiving AS (when comparing MEDs from the same neighboring AS).
  • Scope and Comparison:
    • MED is advertised between EBGP peers.
    • By default, a BGP router only compares MED values for paths received from the same neighboring AS. MEDs from different neighboring ASes are not compared against each other unless explicitly configured to do so.
    • The command bgp always-compare-med on a Cisco router allows it to compare MEDs from different neighboring ASes. This should be used with caution and only when there's an understanding or agreement that MEDs from those different ASes are comparable (e.g., they represent similar cost structures).
    • The command bgp deterministic-med (often enabled by default on modern Cisco IOS) ensures that MED comparison happens at a consistent point in the best path algorithm, before other tie-breakers that might be influenced by the order in which routes are received.
  • Default Behavior: If MED is not explicitly set when advertising a route, it might be sent with a MED of 0, or (in some Cisco IOS versions when redistributing from an IGP) it might be set to the IGP metric of the route.
  • Configuration (to influence a neighbor's inbound path choice by advertising a specific MED):
    route-map SEND_LOWER_MED_THIS_WAY out permit 10
    match ip address prefix-list PREFIXES_VIA_THIS_LINK
    set metric 50 ! Advertise with MED 50 (lower is better for neighbor)
    !
    route-map SEND_LOWER_MED_THIS_WAY out permit 20 ! Allow other routes (perhaps with default or higher MED)
    !
    router bgp
    neighbor route-map SEND_LOWER_MED_THIS_WAY out

NOTE: If AS1 sends a MED value to AS2, AS2 will use this MED for its internal decision-making when choosing paths from AS1. However, when AS2 advertises this route further to AS3, AS2 will not propagate AS1's MED value. Instead, AS2 would set it to 0 for the route advertised to AS3.

BGP Route Selection Process

When a BGP router learns multiple paths to the same destination prefix, it uses a sequential decision process (algorithm) to select a single best path. The first criterion in the list that allows the router to differentiate between paths and choose one as superior is used. The selected best path is then installed in the BGP table (marked as best) and offered to the main IP Routing Information Base (RIB).

The general order for Cisco routers is as follows (can be influenced by certain configurations):

  1. Prefer path with the highest WEIGHT. (Cisco proprietary, local to the router, not advertised).
  2. Prefer path with the highest LOCAL_PREFERENCE. (AS-wide significance, exchanged between IBGP peers).
  3. Prefer path that was locally originated by this router (via network or redistribute command, or an aggregate route created on this router). Routes with a next-hop of 0.0.0.0 often indicate local origination.
  4. Prefer path with the shortest AS_PATH length. The length is the number of AS numbers in the AS_SEQUENCE. An AS_SET segment counts as a length of 1 for this comparison.
  5. Prefer path with the lowest ORIGIN code: IGP (i) is preferred over EGP (e), which is preferred over Incomplete (?).
  6. Prefer path with the lowest MED (Multi-Exit Discriminator).
    • By default, MEDs are only compared if the paths are learned from the same neighboring AS.
    • bgp deterministic-med ensures MED is compared before checking if paths are EBGP or IBGP.
    • bgp always-compare-med allows comparison of MEDs from different neighboring ASes.
  7. Prefer EBGP paths over IBGP paths.
  8. Prefer path with the lowest IGP metric to the BGP NEXT_HOP address. This is primarily used to choose among multiple IBGP paths to an external destination, selecting the path through the IBGP peer that is "closest" according to the IGP.
  9. If BGP Multipath is enabled (e.g., maximum-paths [ibgp] ) and paths are considered equal up to this point (and meet multipath criteria), multiple paths can be installed.
  10. Prefer the oldest (most stable) path for EBGP paths. This helps prevent route flapping if paths are otherwise equal.
  11. Prefer path from the BGP peer with the lowest BGP Router ID. This is a common tie-breaker.
  12. Prefer path with the shortest CLUSTER_LIST length (relevant in Route Reflector environments).
  13. Prefer path from the BGP peer with the lowest Neighbor IP Address. This is usually the final tie-breaker.

Route Reflectors (RR)

Route Reflectors (RRs) are a BGP feature used to address the scalability limitations of the IBGP full-mesh requirement. An RR relaxes the IBGP split-horizon rule (which states that routes learned from an IBGP peer cannot be advertised to another IBGP peer) by selectively reflecting IBGP-learned routes to other IBGP peers.

Key Terminology:

  • RR Server: A BGP router configured to perform route reflection.
  • RR Client: An IBGP peer of the RR server. The RR can reflect routes between its clients and between clients and non-clients. RR clients do not require any special configuration; they operate as standard IBGP peers.
  • Non-Client Peer: An IBGP peer of the RR that is not configured as an RR client. The RR treats non-client peers more like standard IBGP peers regarding the split-horizon rule when reflecting routes learned from other non-clients.
  • Cluster: Logically, an RR server and its set of configured RR clients form a "cluster." Each cluster is typically identified by a Cluster ID.
    • By default, the Cluster ID is the Router ID of the RR server itself. It can be manually configured using bgp cluster-id .
    • For redundant RRs serving the same group of clients (forming a single logical cluster), it's crucial they are configured with the same Cluster ID to prevent routes reflected by one RR from being accepted and re-reflected by the other redundant RR.

Route Reflection Rules (Simplified):

  1. A route learned from an EBGP peer by the RR is advertised to all its RR Clients, all its Non-Client IBGP peers, and all its other EBGP peers.
  2. A route learned from an RR Client by the RR is reflected to:
    • All other RR Clients.
    • All Non-Client IBGP peers.
    • All EBGP peers.
  3. A route learned from a Non-Client IBGP peer by the RR is reflected to:
    • All RR Clients only.
    • It is not reflected to other Non-Client IBGP peers (this upholds a form of split-horizon between non-client peers connected to the same RR, assuming RRs are not fully meshed or part of a higher RR tier).

Loop Prevention Attributes in RR Environments:

When an RR reflects a route, it adds or modifies these Path Attributes:

  • ORIGINATOR_ID (Optional Non-transitive): Set by the first RR that reflects a route originating from within the AS (or from a client). It contains the Router ID of the IBGP peer that originally advertised the route into the cluster (or from which the RR learned the route if it came from another cluster). An RR will not reflect a route back towards its originator, and a router will not accept a reflected route if the ORIGINATOR_ID is its own Router ID.
  • CLUSTER_LIST (Optional Non-transitive): A list of Cluster IDs that the route has traversed. When an RR reflects a route, it prepends its own Cluster ID to this list. An RR will discard a received IBGP route if it sees its own Cluster ID already present in the CLUSTER_LIST. This prevents loops between RRs, especially in designs with multiple RRs or hierarchical RRs.

Configuration:

router bgp
! On the RR Server:
neighbor remote-as
neighbor route-reflector-client
!
! Optionally, to set a specific Cluster ID (useful for redundant RRs):
bgp cluster-id

Hierarchical Route Reflection is also possible, where an RR acts as a client to a higher-level RR, further improving scalability in very large AS designs.

BGP Confederations

BGP Confederations offer another approach to manage IBGP scalability in large Autonomous Systems. The main AS (the confederation) is divided into multiple smaller, private sub-ASes (member ASes). To the outside world, the entire confederation appears as a single, public AS.

Key Concepts:

  • Confederation Identifier (or Confederation ID): This is the "real" public AS number that the entire group of sub-ASes presents to external BGP peers.
  • Sub-AS (Member AS): Each sub-AS uses a private AS number (typically from the private AS range 64512 to 65534). Within each sub-AS, standard IBGP rules apply: either a full mesh of IBGP sessions is required, or Route Reflectors can be used within the sub-AS.
  • Confederation EBGP (CEBGP): BGP sessions established between routers in different sub-ASes but within the same confederation are termed Confederation EBGP.
    • CEBGP sessions behave much like IBGP sessions for the purpose of path attribute propagation. For example, attributes like NEXT_HOP, MED, and LOCAL_PREFERENCE are typically passed unchanged across CEBGP links, similar to IBGP.
    • The standard AS_PATH (which tracks public ASNs) is not modified with the sub-AS numbers when crossing CEBGP links. Instead, a separate mechanism or attribute like AS_CONFED_SEQUENCE (or AS_CONFED_SET) is used internally to track the path through the sub-ASes and prevent loops within the confederation.

When BGP routes are advertised from a router within the confederation to a true external BGP peer (outside the confederation), the internal sub-AS path information (e.g., AS_CONFED_SEQUENCE) is stripped off. Only the public Confederation Identifier is prepended to the AS_PATH that is seen by the external world.

Configuration:

! On a router within a sub-AS:
router bgp ! Use the private sub-AS number for this BGP process
bgp confederation identifier ! Defines the public AS for the entire confederation
bgp confederation peers ... ! Lists other sub-ASes in this confederation
!
! IBGP peering within this sub-AS (to peers in the same )
neighbor remote-as
!
! CEBGP peering to another sub-AS (to peers in an )
neighbor remote-as
!
! True EBGP peering to an external AS (outside the confederation)
neighbor remote-as

While confederations solve the IBGP full-mesh problem, they introduce their own complexity in terms of design and management. Route Reflectors are often considered a simpler and more widely adopted solution for IBGP scalability today.

Route Summarization (Aggregation)

Route summarization, or aggregation, in BGP is the process of combining multiple specific (more granular) BGP routes into a single, less-specific summary route. This is a critical mechanism for reducing the size of global and internal BGP routing tables, which in turn improves routing stability (by hiding flaps of individual specific routes) and reduces the processing load on routers.

Configuration Command (Cisco IOS):

router bgp
aggregate-address [summary-only] [as-set] [advertise-map ] [attribute-map ] [suppress-map ]

Key Options and Behaviors:

  • summary-only:
    • If this keyword is present, the router will advertise only the aggregate (summary) route and will suppress (not advertise) all the more specific routes that fall within the range of this aggregate.
    • If summary-only is omitted, the router will advertise both the aggregate route and its more specific component routes.
  • as-set:
    • When an aggregate is created from routes that originated in different ASes (or have different AS_PATHs), this option causes the AS_PATH attribute of the aggregate route to include an AS_SET segment. The AS_SET lists all the unique AS numbers from the AS_PATHs of the contributing specific routes.
    • Using as-set is crucial for loop prevention when aggregating routes with diverse origins and helps preserve AS path information, albeit in an unordered set.
    • If as-set is not used and routes with different AS_PATHs are aggregated, detailed path information is lost, and the ATOMIC_AGGREGATE attribute is typically set.

Associated Path Attributes with Aggregation:

  • ATOMIC_AGGREGATE (Well-known Discretionary): This attribute is added to an aggregate route by the aggregating router if information from one or more of the specific routes has been lost during the aggregation process. This typically occurs if as-set is not used and the aggregated routes had different AS_PATH attributes or other conflicting attributes that couldn't be cleanly merged. It signals to downstream BGP speakers that the aggregate route might not represent the full path information of all its components.
  • AGGREGATOR (Optional Transitive): This attribute identifies the AS number and the BGP Router ID of the router that performed the aggregation. It is usually included if the as-set option is used, or if the ATOMIC_AGGREGATE attribute is set.

Null0 Route for Aggregates: When a BGP router generates an aggregate route (as a result of the aggregate-address command), it automatically installs a route for that aggregate prefix pointing to the Null0 interface in its own local IP Routing Information Base (RIB). This is an important loop-prevention mechanism. If the router receives traffic destined for an IP address within the aggregate range, but for which it does not have a more specific component route (e.g., that component route is down), this Null0 route ensures the traffic is dropped locally rather than potentially being routed back out based on a less specific route learned from elsewhere, which could cause a routing loop.

Summarization can affect fine-grained traffic engineering if specific routes are suppressed. A common enterprise-to-ISP strategy:

  1. Advertise more specific routes to the immediate ISP(s), often tagged with the NO_EXPORT community. This allows the ISP to make more granular routing decisions towards the enterprise.
  2. Concurrently, advertise a summary route (aggregate) to the ISP(s).
  3. The ISP will then typically only advertise the summary route to the broader internet, helping to reduce the size of the global routing table, while still using the specifics for its own pathing to the enterprise.

BGP Communities

BGP Communities are an optional transitive path attribute. They are essentially "tags" or labels that can be attached to BGP routes to signal specific routing policies or convey additional information about the route. Communities provide a flexible and scalable way to group routes and apply policies to them, often more manageable than matching on numerous individual prefixes or complex AS_PATH patterns.

To enable a Cisco IOS router to send community attributes to a neighbor:

router bgp
neighbor send-community [standard | extended | both]

To display standard communities in the newer AA:NN format (rather than just a decimal number) on Cisco IOS:

ip bgp-community new-format (global configuration mode)

Types of BGP Communities:

  1. Standard Communities (RFC 1997):
    • These are 32-bit numerical values.
    • They are often represented in the format AA:NN, where AA (Autonomous System part, first 16 bits) is typically the AS number of the organization defining the community, and NN (Number part, last 16 bits) is a locally significant number defined by that AS to represent a specific policy or meaning.
    • Well-known Standard Communities (Globally Understood Meaning):
      • NO_EXPORT (Value: 0xFFFFFF01 or 4294967041, often displayed as no-export): When a BGP router receives a route with this community, it should use the route but not advertise it to any EBGP peers (i.e., not outside its own AS, or outside its confederation sub-AS to another confederation sub-AS or true external AS). The route can still be advertised to IBGP peers within the same AS.
      • NO_ADVERTISE (Value: 0xFFFFFF02 or 4294967042, often displayed as no-advertise): When a BGP router receives a route with this community, it should use the route but not advertise it to ANY BGP peer (neither EBGP nor IBGP). The route is essentially kept local to the receiving router and not propagated further.
      • LOCAL_AS (Value: 0xFFFFFF03 or 4294967043, also known as NO_EXPORT_SUBCONFED, often displayed as local-AS): Primarily used within BGP confederations. When a router in a sub-AS receives a route with this community, it should not advertise this route to EBGP peers outside its own sub-AS, including true external ASes and other sub-ASes that are part of different confederations. It can be advertised to peers within the same sub-AS (IBGP) and to peers in other sub-ASes that are part of the *same* confederation (CEBGP).
      • INTERNET: This is a conceptual community often used to signify that a route should be advertised to all BGP peers. It often represents the default behavior if no restrictive communities are present. Some ISPs might use a specific numerical value for this.
    • Custom Communities: These are defined by network operators, particularly ISPs, for their own internal use or for their customers to influence routing policies. For example, an ISP (AS 65000) might define:
      • 65000:100 -> Set Local Preference to 100 for this route.
      • 65000:200 -> Set Local Preference to 200 for this route.
      • 65000:666 -> Signal for blackholing (Remotely Triggered Black Hole - RTBH).
      • 65000:1001 -> Prepend our AS 65000 once to the AS_PATH.
  2. Extended Communities (RFC 4360 and others):
    • These are 64-bit values, offering a much larger namespace and a more structured format than standard communities. They are essential for many advanced BGP features.
    • An extended community is typically composed of a type field (which indicates the purpose or format of the community) and a value field.
    • Common uses include:
      • MPLS Layer 3 VPNs: Route Target (RT) communities control the import/export of VPN routes into VRFs. Site of Origin (SoO) communities prevent routing loops in VPNs with backdoor links.
      • Ethernet VPN (EVPN).
      • BGP Flow Specification (FlowSpec) for distributing firewall-like rules.
      • Two-octet AS specific, Four-octet AS specific, IP-address specific types allow for more granular definitions.
  3. Large Communities (RFC 8092):
    • These are 96-bit values, structured as Global Administrator:Local Data Part 1:Local Data Part 2, where each part is a 32-bit number.
    • They were introduced to overcome limitations of standard communities, especially with the widespread adoption of 32-bit (4-octet) ASNs, which do not fit into the 16-bit "AA" part of the standard AA:NN format. Large communities allow an AS to define a vast number of its own globally unique communities using its full 32-bit ASN as the Global Administrator part.

Common Use Cases for BGP Communities:

  • Dynamic Customer Policy: ISPs publish a list of communities their customers can set on routes advertised to the ISP. Based on these communities, the ISP's routers automatically apply predefined policies (e.g., adjust Local Preference for certain routes, control AS_PATH prepending, select specific egress points, or signal regional preferences).
  • Prefix Origin Tracking & Traffic Engineering: ISPs and large enterprises often tag routes internally with communities to indicate their origin (e.g., learned from a customer, a peer, a transit provider, or a specific geographic region/city). This information is then used for internal traffic engineering, applying appropriate policies, and for easier troubleshooting.
  • Signaling for Blackholing (RTBH): A specific community (often a well-known one within an ISP's network or a pre-agreed one) can be used to tag a prefix that is under attack (e.g., DDoS). When upstream providers receive this prefix with the blackhole community, they route traffic for that prefix to a null interface, effectively dropping the attack traffic.
  • Controlling route propagation in complex network topologies, for example, using NO_EXPORT to keep certain routes within an AS or LOCAL_AS to keep routes within a confederation sub-AS.
! Example of setting a standard and a well-known community in a route-map
route-map SET_CUSTOMER_COMMUNITIES permit 10
match ip address prefix-list CUSTOMER_PREFIXES
set community 65001:250 NO_EXPORT additive ! 'additive' keyword adds to any existing communities
! otherwise, it replaces all existing communities.
!
router bgp
neighbor route-map SET_CUSTOMER_COMMUNITIES out

Route Filtering Techniques

Route filtering in BGP is the process of selectively controlling which BGP routes are advertised to neighbors or accepted from neighbors. This is a fundamental aspect of BGP policy implementation and is typically applied on a per-neighbor basis, in either the inbound (in) or outbound (out) direction.

Common Tools for BGP Route Filtering:

  1. Distribute List (using Access Control Lists - ACLs):
    • This is an older method for route filtering in BGP, but still supported.
    • It uses standard IP Access Control Lists (ACLs) or extended IP ACLs to match routes.
      • When a Standard ACL is used with a distribute-list in BGP, the "source IP address" field in the ACL statement is used to match the Network ID (prefix) of the BGP route. The wildcard mask in the ACL statement defines the range of Network IDs to be matched. It cannot match on prefix length (subnet mask).
      • When an Extended ACL is used, it can match BGP routes based on both their Network ID (prefix) and their Subnet Mask (prefix length). The "source IP address and wildcard" part of the extended ACL statement is used to match the Network ID of the route, and the "destination IP address and wildcard" part is used to match the Subnet Mask of the route. The protocol field in the extended ACL statement should be set to ip for this purpose.
    • In the ACL, a permit statement means the route matches the criteria for the distribute-list's filtering action (i.e., if the distribute-list is denying, this permitted route in ACL will be denied by BGP). An ACL deny statement means the route does not match that specific ACL line and processing continues to the next ACL line. (The final action is determined by how the distribute-list is applied if it's part of a larger deny/permit policy).

      More simply: The ACL's permit/deny logic selects which routes the distribute-list itself will then act upon with its implicit permit or deny action based on the overall policy design.

    • Configuration:
      router bgp
      neighbor distribute-list [in|out]
    • For BGP route filtering, prefix-lists are generally preferred over distribute-lists with ACLs because prefix-lists are specifically designed for prefix/length matching and are often more efficient and easier to read for this purpose.

  2. Prefix List:
    • Prefix-lists are the recommended tool for filtering routes based on network prefixes and their lengths. They are more flexible and purpose-built for this task than ACLs.
    • Configuration:
      ip prefix-list seq [permit|deny] [ge ] [le ]
      • : Specifies the base network and its prefix length.
      • ge (optional): "Greater than or equal to". Matches prefixes that are more specific than or equal to ge_length, but still fall within the base .
      • le (optional): "Less than or equal to". Matches prefixes that are less specific than or equal to le_length, but also more specific than or equal to the base prefix_length. The route's prefix length must be between prefix_length and le_length (inclusive) AND also between ge_length (if specified) and le_length (inclusive), and the network portion must match.
      • If only is specified, it requires an exact match of both the network and the prefix length.
      • Example: ip prefix-list MY_CUSTOMER_ROUTES permit 10.1.0.0/16 ge 24 le 24 would match only /24 prefixes within the 10.1.0.0/16 range (e.g., 10.1.1.0/24, 10.1.2.0/24).
      • Example: ip prefix-list DEFAULT_ROUTE_ONLY permit 0.0.0.0/0 matches only the default route.
    • Application to a BGP neighbor:
      router bgp
      neighbor prefix-list [in|out]
  3. Filter List (using AS_PATH Access Lists):
    • Used to filter BGP routes based on the content of their AS_PATH attribute.
    • AS_PATH Access Lists employ Regular Expressions (Regex) to define patterns that are matched against the AS_PATH string of a route.
    • Configuration of AS_PATH ACL:
      ip as-path access-list [permit|deny]
    • Application to a BGP neighbor:
      router bgp
      neighbor filter-list [in|out]
  4. Route Map:
    • The most powerful and flexible tool for implementing BGP policies, including complex route filtering and attribute manipulation.
    • Route maps consist of a sequence of clauses (identified by sequence numbers), each with a permit or deny action.
    • Each clause can contain one or more match statements (e.g., match ip address prefix-list ..., match as-path ..., match community ...) to define the criteria for selecting routes. If multiple match statements are in a single clause, they are typically ANDed (all must match).
    • If a route matches the criteria in a clause, the action of that clause (permit or deny) is taken, and by default, no further clauses in the route-map are processed for that route (unless the continue keyword is used in a set action).
    • If a route does not match any explicit clause, it is caught by an implicit deny all at the end of the route-map. To allow routes that don't match any specific filtering clause, a final explicit permit clause (often with no match statements, which means "match all remaining routes") is necessary.
    • Application to a BGP neighbor:
      router bgp
      neighbor route-map [in|out]
    • When an ACL, prefix-list, or AS_PATH ACL is called within a match statement of a route-map, a permit statement within that called list indicates that the route *matches the criteria* defined by that list. The route-map clause's own permit or deny action then determines what happens to those routes that have satisfied the match criteria.

On Cisco IOS, a distribute-list (ACL-based filtering) and a prefix-list cannot be applied simultaneously to the same BGP neighbor in the same direction (either both in or both out). If both are configured, typically the prefix-list takes precedence or an error might be indicated. Route-maps are generally the most comprehensive and recommended tool for most BGP filtering and policy tasks.

Regular Expressions (Regex) for AS_PATH Filtering

Regular Expressions (Regex) are powerful patterns used within AS_PATH Access Lists to match sequences of Autonomous System Numbers (ASNs) in the BGP AS_PATH attribute. This enables fine-grained control over route filtering based on the route's origin or transit path through various ASes.

Common Regex Metacharacters and Constructs for AS_PATHs:

  • ^ (Caret): Matches the beginning of the AS_PATH string. Indicates that the following pattern must appear at the start of the path.
    • Example: ^65001_ matches AS_PATHs that originate from AS 65001 (AS 65001 is the very first AS in the path). The underscore _ acts as a delimiter.
  • $ (Dollar sign): Matches the end of the AS_PATH string. Indicates that the preceding pattern must appear at the end of the path.
    • Example: _65002$ matches AS_PATHs where AS 65002 is the direct upstream neighbor (i.e., AS 65002 is the last AS in the path before the local AS).
  • _ (Underscore): Matches an AS_PATH delimiter. In BGP regex, delimiters can be a space (between ASNs), the beginning of the string (^), or the end of the string ($). Using underscores around an ASN ensures you match that specific ASN and not a part of a larger ASN.
    • Example: _65003_ matches AS_PATHs that contain AS 65003 anywhere as a complete AS number in the transit path.
  • . (Dot): Matches any single character. While less common for directly matching AS numbers (which are multi-digit), it can be used in conjunction with quantifiers for more flexible matching.
  • * (Asterisk): Matches zero or more occurrences of the preceding character or grouped expression.
    • Example: .* (dot star) matches any AS_PATH string, including an empty AS_PATH (which represents a route locally originated within the current AS). This is often used in a final "permit all else" statement.
  • + (Plus sign): Matches one or more occurrences of the preceding character or grouped expression.
    • Example: _65001(_65001)*_ or more simply _65001+ (depending on regex engine specifics) could match one or more occurrences of AS 65001 (used for AS_PATH prepending detection).
  • ? (Question mark): Matches zero or one occurrence of the preceding character or grouped expression.
  • [AS_NUMBER] or just AS_NUMBER: To match a literal AS number, you typically just type the number (e.g., 65001). Square brackets are used for character sets (e.g., [123] matches '1', '2', or '3') or to escape metacharacters if an ASN somehow contained one (very rare). For ASNs, literal numbers are standard.
  • ( ) (Parentheses): Groups characters or sub-expressions together. This is useful when applying quantifiers (*, +, ?) to a sequence of characters or for capturing parts of the match (though capturing is less relevant for simple filtering).
  • | (Pipe/Vertical bar): Acts as an OR operator, allowing a match if either the pattern on its left OR the pattern on its right is found.
    • Example: ^65001_|_65002_ matches routes originated by AS 65001 OR routes that transit through AS 65002.

Practical Examples for AS_PATH Access Lists:

  • ip as-path access-list 1 permit ^$ : Matches routes that are locally originated within the current AS (AS_PATH is empty).
  • ip as-path access-list 2 permit ^65001_ : Matches routes that originated directly from AS 65001.
  • ip as-path access-list 3 permit _65002$ : Matches routes where the direct upstream (advertising) peer is in AS 65002.
  • ip as-path access-list 4 permit _65003_ : Matches routes that transit through AS 65003 at any point in their path.
  • ip as-path access-list 5 permit ^65001_65002_65003$ : Matches an exact AS_PATH sequence of 65001 -> 65002 -> 65003.
  • ip as-path access-list 6 permit ^65001_.*_65003$ : Matches routes originating in AS 65001, having any number of transit ASes (or none) in between, and where AS 65003 is the direct upstream peer.
  • ip as-path access-list 99 permit .* : Matches any AS_PATH. This is often used as a final statement in a filter-list to permit all other routes not explicitly denied by preceding statements.
! Applying an AS_PATH filter-list to a neighbor
router bgp
neighbor filter-list [in|out]

For testing and building BGP Regex patterns, you can use the show ip bgp regexp command on a router that has a BGP table. Online regex testers (like regex101.com, selecting a compatible flavor such as PCRE or Python) are also invaluable, allowing you to test your patterns against sample AS_PATH strings.

Multi-Protocol BGP (MP-BGP)

Multi-Protocol BGP (MP-BGP), primarily defined in RFC 4760 (which obsoletes RFC 2858), extends the capabilities of BGP to carry routing information for multiple network layer protocols and various types of address information, not just the original IPv4 unicast routes. This is achieved by introducing the concepts of Address Family Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI).

  • During the BGP OPEN message exchange, peers negotiate their MP-BGP capabilities. If a peer does not announce support for a particular AFI/SAFI combination, it will not send or process routes for that address family.
  • Address Family Identifier (AFI): A 16-bit field that identifies the primary network layer protocol being addressed.
    • Examples: AFI 1 for IPv4, AFI 2 for IPv6.
  • Subsequent Address Family Identifier (SAFI): An 8-bit field that provides additional specification about the type of Network Layer Reachability Information (NLRI) being carried for the given AFI.
    • Examples: SAFI 1 for Unicast, SAFI 2 for Multicast, SAFI 4 or 128 for MPLS-labeled VPN routes.

Common AFI/SAFI Combinations and Their Uses:

  • AFI 1, SAFI 1: IPv4 Unicast (This is the traditional, default BGP capability).
  • AFI 2, SAFI 1: IPv6 Unicast (For exchanging standard IPv6 routing information).
  • AFI 1, SAFI 4 (or SAFI 128): IPv4 MPLS-labeled VPN routes (VPNv4 routes, used in MPLS L3VPNs). SAFI 128 is often used interchangeably with SAFI 4 for VPNs.
  • AFI 2, SAFI 4 (or SAFI 128): IPv6 MPLS-labeled VPN routes (VPNv6 routes, used in MPLS L3VPNs for IPv6).
  • AFI 1, SAFI 2: IPv4 Multicast (Used by Multicast BGP - MBGP - to distribute multicast routing information, e.g., for inter-domain multicast).
  • AFI 2, SAFI 2: IPv6 Multicast.
  • AFI 25, SAFI 65: L2VPN VPLS (Virtual Private LAN Service).
  • (Many other combinations exist for technologies like EVPN, BGP Flow Specification, etc.)

New Path Attributes for MP-BGP:

To accommodate the diverse information for different address families, MP-BGP introduces two crucial path attributes (these are themselves BGP path attributes with specific type codes, typically Optional Non-transitive):

  • MP_REACH_NLRI (Multiprotocol Reachable NLRI - Type Code 14): This attribute is used to advertise reachable routes for a specific AFI/SAFI combination (other than IPv4 unicast, which uses the original NLRI fields). It contains:
    • The AFI/SAFI pair to which the NLRI applies.
    • The Next-Hop address information relevant to that AFI/SAFI (e.g., an IPv6 next-hop address for IPv6 routes). The length and format of the next-hop field can vary.
    • The NLRI itself, which is a list of prefixes for that address family.
  • MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI - Type Code 15): This attribute is used to withdraw previously advertised routes for a specific AFI/SAFI combination. It contains:
    • The AFI/SAFI pair to which the withdrawn NLRI applies.
    • The NLRI to be withdrawn (a list of prefixes).

Configuration (Cisco IOS Example for IPv6):

In Cisco IOS and similar CLIs, BGP configuration is often structured into address-family sub-modes. A neighbor relationship is defined globally, and then it must be "activated" under each specific address family for which routes are to be exchanged with that neighbor.

router bgp
bgp router-id
!
! Global neighbor definition (can be IPv4 or IPv6 address)
neighbor remote-as
!
address-family ipv4 unicast
! IPv4 unicast specific configurations (this is the default address family)
neighbor activate ! Activates the neighbor for IPv4 unicast
network 10.0.0.0 mask 255.0.0.0
! Other IPv4 unicast policies (route-maps, prefix-lists, etc.)
exit-address-family
!
address-family ipv6 unicast
! IPv6 unicast specific configurations
neighbor activate ! Activate the same neighbor for IPv6 unicast
! BGP can carry IPv6 (AFI 2) over an IPv4 (AFI 1) TCP session.
network 2001:db8:abcd::/48
! Other IPv6 unicast policies (route-maps, prefix-lists, etc.)
exit-address-family

When advertising, for example, IPv6 routes over an IPv4-transported BGP session, the MP_REACH_NLRI attribute for the IPv6 routes will contain an IPv6 next-hop address (usually the advertising router's IPv6 address on the link shared with the peer, either link-local or global). The receiving BGP peer must have a way to resolve this IPv6 next-hop to forward traffic. If the IPv4 BGP peer is not also the direct Layer 3 next-hop for the IPv6 traffic (e.g., if the actual IPv6 next-hop is another router on the same segment), then the advertising router might need to use a route-map with set ipv6 next-hop to specify the correct IPv6 next-hop address of the BGP peer on that link. For simplicity and clearer separation, if a link supports both IPv4 and IPv6 routing, establishing separate BGP sessions (one using IPv4 transport for IPv4 AFI, and another using IPv6 transport for IPv6 AFI) is often a preferred design, though not strictly necessary for MP-BGP to function.

BGP Groups & Templates

BGP peer groups and peer templates are configuration mechanisms designed to simplify the management of BGP configurations when dealing with multiple BGP neighbors that share a significant number of common configuration parameters and routing policies. They help reduce configuration redundancy, minimize errors, and make the overall BGP setup more maintainable.

Peer Groups (Older Method)

  • A BGP peer group is a collection of BGP neighbors that are configured to share a common set of outbound routing policies. While outbound policies must be identical for all members, inbound policies can still be customized on a per-neighbor basis.
  • Common configuration commands (e.g., remote-as, update-source, outbound route-map, filter-list, prefix-list, BGP timers) are applied once to the peer group name.
  • Individual BGP neighbors are then declared as members of this peer group, thereby inheriting all the configurations defined for the group.
  • Primary Benefit Today: The main advantage of using peer groups in modern BGP implementations is the reduction in the number of configuration lines. This makes the BGP configuration more concise, easier to read, and less prone to inconsistencies.
  • Historically, peer groups also provided a significant performance benefit by optimizing the BGP update generation process (an UPDATE message was formatted only once for the entire group). However, this update optimization role has largely been superseded by dynamic Update Groups, which BGP routers form automatically even if explicit peer groups are not configured.
  • Key Limitation: All members of a traditional peer group *must* have identical outbound policies. If any neighbor requires even a minor deviation in its outbound policy, it cannot be part of that peer group or would require complex workarounds (like overriding with more specific route-maps, which diminishes the simplicity benefit).
! Example of a BGP Peer Group configuration
router bgp
neighbor MY_IBGP_PEERS peer-group
neighbor MY_IBGP_PEERS remote-as ! All members are in the same AS (IBGP)
neighbor MY_IBGP_PEERS update-source Loopback0
neighbor MY_IBGP_PEERS route-map COMMON_IBGP_OUT_POLICY out
neighbor MY_IBGP_PEERS send-community both
!
neighbor 10.0.0.1 peer-group MY_IBGP_PEERS
neighbor 10.0.0.1 description IBGP_Peer_R1
neighbor 10.0.0.1 route-map SPECIFIC_IN_POLICY_FOR_R1 in ! Inbound policy can be unique
!
neighbor 10.0.0.2 peer-group MY_IBGP_PEERS
neighbor 10.0.0.2 description IBGP_Peer_R2
neighbor 10.0.0.2 route-map SPECIFIC_IN_POLICY_FOR_R2 in ! Different unique inbound policy

Dynamic Peer Groups: This feature allows a BGP router to be configured to "listen" on a specified range of IP addresses. If an incoming BGP OPEN message (connection attempt) is received from an IP address that falls within this listen range, the router can dynamically establish a BGP neighbor session with that peer and automatically assign it to a pre-defined peer group. This is particularly useful in scenarios like DMVPN (Dynamic Multipoint VPN) or at Internet Exchange Points (IXPs) where the IP addresses of all potential BGP neighbors might not be known or configured statically in advance.

! Example of a Dynamic Peer Group
router bgp
bgp listen range 172.16.0.0/16 peer-group DMVPN_SPOKES
neighbor DMVPN_SPOKES peer-group
neighbor DMVPN_SPOKES remote-as
neighbor DMVPN_SPOKES password
... ! Other common policies for dynamically discovered DMVPN spokes

Peer Templates (Newer, More Flexible Method - Primarily Cisco IOS/XR/NX-OS)

Peer templates offer a more granular, flexible, and powerful way to manage common BGP configurations using an inheritance model. They are generally preferred over traditional peer groups in modern Cisco network designs.

  • Templates are defined for different categories of BGP configuration parameters:
    • Session Templates (template peer-session ): These are used to configure parameters related to the BGP session itself, such as remote-as, update-source, BGP timers (keepalive, holdtime), authentication (password), ebgp-multihop, transport connection settings.
    • Policy Templates (template peer-policy ): These are used to configure parameters related to BGP routing policy application, such as inbound/outbound route-maps, filter-lists, prefix-lists, send-community, default-originate, soft-reconfiguration.
  • A BGP neighbor can then be configured to inherit its settings from these predefined templates:
    • A neighbor can inherit from one session template.
    • A neighbor can inherit from multiple policy templates (up to a platform-specific limit, e.g., 8 policy templates on some Cisco platforms).
  • The inheritance model allows for a base configuration to be defined in the templates. If a specific parameter is configured directly on the neighbor itself, that direct configuration will take precedence and override the value inherited from the template for that particular parameter. This provides great flexibility for common settings with per-neighbor exceptions.
! Example of BGP Peer Templates
router bgp
template peer-session STANDARD_EBGP_PARAMETERS
update-source Loopback0
ebgp-multihop 2
timers 30 90 ! Keepalive 30s, Holdtime 90s
exit-peer-session
!
template peer-policy CUSTOMER_A_POLICY
route-map IN_FROM_CUSTOMER_A in
route-map OUT_TO_CUSTOMER_A out
send-community both
exit-peer-policy
!
template peer-policy GENERIC_FILTERING
prefix-list BLOCK_BOGONS in
exit-peer-policy
!
neighbor 10.1.1.2
remote-as ! This must be set per neighbor if it varies
inherit peer-session STANDARD_EBGP_PARAMETERS
inherit peer-policy CUSTOMER_A_POLICY
inherit peer-policy GENERIC_FILTERING
description EBGP_to_Customer_A
password ! Overrides/adds to template

Update Groups (Dynamic & Internal BGP Process)

  • Independently of whether explicit peer groups or peer templates are configured, BGP routers (especially modern implementations) perform an internal optimization by dynamically grouping BGP peers that share identical outbound routing policies into "update groups."
  • When a BGP UPDATE message needs to be generated (e.g., due to advertising a new route, withdrawing a route, or a change in path attributes), the BGP process formats the UPDATE message only once for each unique update group.
  • This single, formatted UPDATE message is then replicated and sent to all BGP peers that are members of that specific update group.
  • This mechanism significantly optimizes CPU utilization during the BGP update generation process, as it avoids the redundant work of formatting the exact same update message multiple times for different peers that require the same outbound policy treatment.
  • This is largely an automatic, internal process managed by the BGP software itself. While traditional peer groups historically claimed this as one of their main benefits, dynamic update groups now handle this optimization more efficiently and adaptively.
  • Diagnostic commands like show ip bgp update-group (Cisco IOS) can be used to view these dynamically formed update groups, their members, and statistics related to update generation. show ip bgp replication can provide insights into how many messages were formatted versus replicated.
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x