BGP Overview

This section discusses the following topics:

• Autonomous Systems
• AS Paths and Attributes
• External and Internal BGP
• Multiple Instances of BGP
• Allow Protocol Traffic for Interfaces in a Security Zone

External and Internal BGP

BGP supports two types of exchanges of routing information: exchanges among different ASs and exchanges within a single AS. When used among ASs, BGP is called external BGP (EBGP) and BGP sessions perform inter-AS routing. When used within an AS, BGP is called internal BGP (IBGP) and BGP sessions perform intra-AS routing. Figure 1 illustrates ASs, IBGP, and EBGP.

Figure 1: ASs, EBGP, and IBGP

A BGP system shares network reachability information with adjacent BGP systems, which are referred to as neighbors or peers.

BGP systems are arranged into groups. In an IBGP group, all peers in the group—called internal peers—are in the same AS. Internal peers can be anywhere in the local AS and do not have to be directly connected to one another. Internal groups use routes from an IGP to resolve forwarding addresses. They also propagate external routes among all other internal routers running IBGP, computing the next hop by taking the BGP next hop received with the route and resolving it using information from one of the interior gateway protocols.

In an EBGP group, the peers in the group—called external peers—are in different ASs and normally share a subnet. In an external group, the next hop is computed with respect to the interface that is shared between the external peer and the local router.

A BGP route is a destination, described as an IP address prefix, and information that describes the path to the destination.

The following information describes the path:

• AS path, which is a list of numbers of the ASs that a route passes through to reach the local router. The first number in the path is that of the last AS in the path—the AS closest to the local router. The last number in the path is the AS farthest from the local router, which is generally the origin of the path.

• Path attributes, which contain additional information about the AS path that is used in routing policy.

BGP peers advertise routes to each other in update messages.

BGP stores its routes in the Junos OS routing table (inet.0). The routing table stores the following information about BGP routes:

• Routing information learned from update messages received from peers

• Local routing information that BGP applies to routes because of local policies

• Information that BGP advertises to BGP peers in update messages

For each prefix in the routing table, the routing protocol process selects a single best path, called the active path. Unless you configure BGP to advertise multiple paths to the same destination, BGP advertises only the active path.

The BGP router that first advertises a route assigns it one of the following values to identify its origin. During route selection, the lowest origin value is preferred.

• 0—The router originally learned the route through an IGP (OSPF, IS-IS, or a static route).

• 1—The router originally learned the route through an EGP (most likely BGP).

• 2—The route's origin is unknown.

An internal BGP (IBGP) route with a next-hop address to a remote BGP neighbor (protocol next hop) must have its next hop resolved using some other route. BGP adds this route to the rpd resolver module for next-hop resolution. If RSVP is used in the network, then the BGP next hop is resolved using the RSVP ingress route. This results in the BGP route pointing to an indirect next hop, and the indirect next hop pointing to a forwarding next hop. The forwarding next hop is derived from the RSVP route next hop. There is often a large set of internal BGP routes that have the same protocol next hop, and in such cases, the set of BGP routes would reference the same indirect next hop.

Prior to Junos OS Release 17.2R1, the resolver module of the routing protocol process (rpd) resolved routes within the IBGP received routes in the following ways:

1. Partial route resolution—The protocol next hop is resolved based on helper routes, such as RSVP or IGP routes. The metric values are derived from the helper routes, and the next hop is referred to as the resolver forwarding next hop inherited from helper routes. These metric values are used for selecting routes in the routing information base (RIB), also known as the routing table.

2. Complete route resolution—The final next hop is derived and is referred to as the kernel routing table (KRT) forwarding next hop based on the forwarding export policy.

Starting in Junos OS Release 17.2R1, the resolver module of rpd is optimized to increase the throughput of inbound processing flow, accelerating the learning rate of RIB and FIB. With this enhancement, the route resolution is affected as follows:

• The partial and complete route resolution methods are triggered for each IBGP route, although each route might inherit the same resolved forwarding next hop or KRT forwarding next hops.

• The BGP path selection is deferred until complete route resolution is performed for network layer reachability information (NLRI) received from a BGP neighbor, which might not be the best route in the RIB after route selection.

The benefits of the rpd resolver optimization include:

• Lower RIB resolution lookup cost—The output of the resolved path is saved in a resolver cache, so that the same derived next hop and metric values can be inherited to another set of routes sharing the same path behavior instead of performing both partial and complete route resolution flow. This reduces the route resolution lookup cost by maintaining only the most frequent resolver state in a cache with limited depth.

• BGP route selection optimization—The BGP route selection algorithm is triggered twice for every IBGP route received—first, while adding the route in the RIB with the next hop as unusable, and second, while adding the route with a resolved next hop in the RIB (after route resolution). This results in selecting the best route twice. With the resolver optimization, the route selection process is triggered in the receive flow only after getting the next-hop information from the resolver module.

• Internal caching to avoid frequent lookup—The resolver cache maintains the most frequent resolver state, and as a result, the lookup functionality, such as next-hop lookup and route lookup is done from the local cache.

• Path equivalence group—When different paths share the same forwarding state, or are received from the same protocol next hop, the paths can belong to one path equivalence group. This approach avoids the need to perform of complete route resolution for such paths. When a new path requires complete route resolution, it is first looked up in the path equivalence group database, which contains the resolved path output, such as indirect next hop and forwarding next hop.

This section discusses the following topics:

• Open Messages
• Update Messages
• Keepalive Messages
• Notification Messages
• Route-Refresh Messages

BGP route processing usually has several pipeline stages such as receiving update, parsing update, creating route, resolving next-hop, applying a BGP peer group's export policy, forming per peer updates and sending updates to peers.

BGP RIB sharding splits a unified BGP RIB into several sub-RIBs and each sub-RIB handles a subset of BGP routes. Separate RPD thread termed BGP shard thread serves each sub-RIB by to achieve concurrency. BGP shard threads are responsible for all the BGP route processing pipeline stages with the exception of forming per peer updates and sending updates to peers. BGP shard threads receive the updates sent by peers from the BGP Update IO threads with the BGP Update IO threads hashing the prefixes in the updates and sends the updates to the applicable BGP shard threads based on the hash computation. BGP shard thread processes the configuration in the same manner as the RPD main thread, creates peers, groups, route-tables, and uses the configuration information for BGP route processing.

BGP Update IO threads are responsible for the tail end of this BGP pipeline, involving generating per peer updates for individual BGP group(s) and sending them to the peer(s). One update thread might serve one or more BGP groups. BGP Update IO threads construct updates for groups in parallel and independent of other groups that are being serviced by other update threads. This might offer significant convergence improvement in a write-heavy workload, that involves advertising to many peers spread across many groups. BGP Update IO threads are also responsible for writing to and reading from the BGP peers’ TCP sockets which was previously provided by BGPIO threads (hence the suffix IO in BGP Update IO).

BGP Update IO threads can be configured independent of RIB sharding feature but are mandatory to use with RIB sharding, in order to achieve better prefix packing efficiency in outbound BGP update message. BGP sharding splits the RIB into several sub RIBs that are served by separate RPD threads. Hence, prefixes that could have gone into a single outbound update end up in different shards. To be able to construct BGP updates with prefixes with the same outgoing attribute that might belong to different RPD shard threads, all shard threads send compact advertisement information for prefixes to be advertised to an Update thread serving that BGP peer group. This allows the update thread, serving this BGP peer group, to pack prefixes with the same attributes, potentially belonging to different shards in the same outbound update message. This minimizes the number of updates to be advertised and thus helps improve convergence. Update IO thread manages local caches of peer, group, prefix, TSI and RIB containers.

BGP update thread and BGP RIB sharding are disabled by default. If you configure update-threading and rib-sharding on a routing engine, RPD creates update threads. By default, the number of update threads and shard threads created is the same as the number of CPU cores on the routing engine. Update threading is only supported on a 64 bit routing protocol process (rpd). Optionally, you can specify the number-of-threads you want to create by using set update-threading <number-of-threads> and set rib-sharding <number-of-threads> statements at the [edit system processes routing bgp] hierarchy level. For BGP update thread, the range is currently 1 through 128 and for BGP RIB sharding, the range is currently 1 through 31.

When you configure NSR for the BGP RIB sharding and BGP Update IO features, the backup RPD creates the same number of BGP shard and BGP Update IO threads in the backup routing engine. The backup RPD BGP Update IO threads read the replicated BGP update, other messages received from the peers as well as replicated BGP update, and other messages sent to the peers. Based on hashing of prefixes, the backup RPD BGP Update IO threads send these BGP messages to the applicable BGP shard and RPD main threads. The BGP shard and the RPD main threads in the backup RPD creates the received and advertised route state using these replicated BGP messages. When the primary routing engine fails, the backup routing-engine becomes the primary routing engine and the backup RPD becomes the primary RPD seamlessly without impacting the BGP sessions with the peers.

For each prefix in the routing table, the routing protocol process selects a single best path. After the best path is selected, the route is installed in the routing table. The best path becomes the active route if the same prefix is not learned by a protocol with a lower (more preferred) global preference value, also known as the administrative distance. The algorithm for determining the active route is as follows:

1. Verify that the next hop can be resolved.

2. Choose the path with the lowest preference value (routing protocol process preference).

   Routes that are not eligible to be used for forwarding (for example, because they were rejected by routing policy or because a next hop is inaccessible) have a preference of –1 and are never chosen.

3. Prefer the path with higher local preference.

   For non-BGP paths, choose the path with the lowest preference2 value.

4. If the accumulated interior gateway protocol (AIGP) attribute is enabled, add the IGP metric and prefer the path with the lower AIGP attribute.

5. Prefer the path with the shortest autonomous system (AS) path value (skipped if the as-path-ignore statement is configured).

   A confederation segment (sequence or set) has a path length of 0. An AS set has a path length of 1.

6. Prefer the route with the lower origin code.

   Routes learned from an IGP have a lower origin code than those learned from an exterior gateway protocol (EGP), and both have lower origin codes than incomplete routes (routes whose origin is unknown).

7. Prefer the path with the lowest multiple exit discriminator (MED) metric.

   Depending on whether nondeterministic routing table path selection behavior is configured, there are two possible cases:

   • If nondeterministic routing table path selection behavior is not configured (that is, if the path-selection cisco-nondeterministic statement is not included in the BGP configuration), for paths with the same neighboring AS numbers at the front of the AS path, prefer the path with the lowest MED metric. To always compare MEDs whether or not the peer ASs of the compared routes are the same, include the path-selection always-compare-med statement.

   • If nondeterministic routing table path selection behavior is configured (that is, the path-selection cisco-nondeterministic statement is included in the BGP configuration), prefer the path with the lowest MED metric.

   Confederations are not considered when determining neighboring ASs. A missing MED metric is treated as if a MED were present but zero.

   Note:

   MED comparison works for single path selection within an AS (when the route does not include an AS path), though this usage Is uncommon.

   By default, only the MEDs of routes that have the same peer autonomous systems (ASs) are compared. You can configure routing table path selection options to obtain different behaviors.

8. Prefer strictly internal paths, which include IGP routes and locally generated routes (static, direct, local, and so forth).

9. Prefer strictly external BGP (EBGP) paths over external paths learned through internal BGP (IBGP) sessions.

10. Prefer the path whose next hop is resolved through the IGP route with the lowest metric. BGP routes that are resolved through IGP are preferred over unreachable or rejected routes.

    Note:

    A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered.

    BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

11. If both paths are external, prefer the oldest path, in other words, the path that was learned first. This is done to minimize route-flapping. This rule is not used if any one of the following conditions is true:

    • path-selection external-router-id is configured.

    • Both peers have the same router ID.

    • Either peer is a confederation peer.

    • Neither path is the current active path.

12. Prefer a primary route over a secondary route. A primary route is one that belongs to the routing table. A secondary route is one that is added to the routing table through an export policy.

13. Prefer the path from the peer with the lowest router ID. For any path with an originator ID attribute, substitute the originator ID for the router ID during router ID comparison.

14. Prefer the path with the shortest cluster list length. The length is 0 for no list.

15. Prefer the path from the peer with the lowest peer IP address.

• Routing Table Path Selection
• BGP Table path selection
• Effects of Advertising Multiple Paths to a Destination

Junos OS substantially supports the following RFCs and Internet drafts, which define standards for IP version 4 (IPv4) BGP.

For a list of supported IP version 6 (IPv6) BGP standards, see Supported IPv6 Standards.

Junos OS BGP supports authentication for protocol exchanges (MD5 authentication).

• RFC 1745, BGP4/IDRP for IP—OSPF Interaction

• RFC 1772, Application of the Border Gateway Protocol in the Internet

• RFC 1997, BGP Communities Attribute

• RFC 2283, Multiprotocol Extensions for BGP-4

• RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option

• RFC 2439, BGP Route Flap Damping

• RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

• RFC 2796, BGP Route Reflection – An Alternative to Full Mesh IBGP

• RFC 2858, Multiprotocol Extensions for BGP-4

• RFC 2918, Route Refresh Capability for BGP-4

• RFC 3065, Autonomous System Confederations for BGP

• RFC 3107, Carrying Label Information in BGP-4

• RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition

• RFC 3392, Capabilities Advertisement with BGP-4

• RFC 4271, A Border Gateway Protocol 4 (BGP-4)

• RFC 4273, Definitions of Managed Objects for BGP-4

• RFC 4360, BGP Extended Communities Attribute

• RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

• RFC 4486, Subcodes for BGP Cease Notification Message

• RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

• RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

• RFC 4684, Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)

• RFC 4724, Graceful Restart Mechanism for BGP

• RFC 4760, Multiprotocol Extensions for BGP-4

• RFC 4781, Graceful Restart Mechanism for BGP with MPLS

• RFC 4798, Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)

  Option 4b (eBGP redistribution of labeled IPv6 routes from AS to neighboring AS) is not supported.

• RFC 4893, BGP Support for Four-octet AS Number Space

• RFC 5004, Avoid BGP Best Path Transitions from One External to Another

• RFC 5065, Autonomous System Confederations for BGP

• RFC 5082, The Generalized TTL Security Mechanism (GTSM)

• RFC 5291, Outbound Route Filtering Capability for BGP-4 (partial support)

• RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4 (partial support)

  Devices running Junos OS can receive prefix-based ORF messages.

• RFC 5396, Textual Representation of Autonomous System (AS) Numbers

• RFC 5492, Capabilities Advertisement with BGP-4

• RFC 5512, The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute

• RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop

• RFC 5575, Dissemination of flow specification rules. Covers RFC 8955 and RFC 8956.

  RFC-8955 - Provides a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic flow specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services.

  RFC8956 - Provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow specifications for the purpose of rate limiting or filtering IPv6 protocol data packets.

• RFC 5668, 4-Octet AS Specific BGP Extended Community

• RFC 5701, IPv6 Address Specific BGP Extended Community Attribute

• RFC 5925, The TCP Authentication Option

• RFC 6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4- fully compliant

• RFC 6368, Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 6774, Distribution of Diverse BGP Paths

• RFC 6793, BGP Support for Four-Octet Autonomous System (AS) Number Space

• RFC 6810, The Resource Public Key Infrastructure (RPKI) to Router Protocol

• RFC 6811, BGP Prefix Origin Validation

• RFC 6996, Autonomous System (AS) Reservation for Private Use

• RFC 7300, Reservation of Last Autonomous System (AS) Numbers

• RFC 7311, The Accumulated IGP Metric Attribute for BGP

• RFC 7404, Using Only Link-Local Addressing inside an IPv6 Network

• RFC 7432, BGP MPLS-Based Ethernet VPN (eVPN)

• RFC 7606, Revised Error Handling for BGP UPDATE Messages

• RFC 7611, BGP ACCEPT_OWN Community Attribute

  We support the RFC by enabling Juniper routers to accept routes received from a route reflector with the accept-own community value.

• RFC 7752, North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP

• RFC 7854, BGP Monitoring Protocol (BMP)

• RFC 7911, Advertisement of Multiple Paths in BGP

• RFC 8097, BGP Prefix Origin Validation State Extended Community

• RFC 8210, The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1

• RFC 8212, Default External BGP (EBGP) Route Propagation Behavior without Policies- fully compliant

  Exceptions:

  The behaviors in RFC 8212 are not implemented by default in order to avoid disruption of existing customer configuration. The default behavior is still kept to accept and advertise all routes with regard to EBGP peers.

• RFC 8277, Using BGP to Bind MPLS Labels to Address Prefixes

• RFC 8326, Graceful BGP session Shutdown

• RFC 8481, Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)

• RFC 8538, Notification Message Support for BGP Graceful Restart

• RFC 8571, BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions

• RFC 8584, Framework for Ethernet VPN Designated Forwarder Election Extensibility

• RFC 8642, Policy Behavior for Well-Known BGP Communities

• RFC 8669, Segment Routing Prefix Segment Identifier Extensions for BGP

• RFC 8810, Revision to Capability Codes Registration Procedures

• RFC 8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State (partial support)

• RFC 8950, Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

• RFC 8955

• RFC 8956

• RFC 9003, Extended BGP Administrative Shutdown Communication

• RFC 9012, The BGP Tunnel Encapsulation Attribute

• RFC 9029, Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries

• RFC 9069, Support for Local RIB in the BGP Monitoring Protocol (BMP)

• RFC 9085, Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing

• RFC 9117, Revised Validation procedure for Dissemination of BGP Flow Specifications. This enables the Flow Specifications to be originated within the same autonomous system as the BGP peer performing the validation.

• RFC 9384, A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)

• Internet draft draft-idr-rfc8203bis-00, BGP Administrative Shutdown Communication (expires October 2018)

• Internet draft draft-ietf-grow-bmp-adj-rib-out-01, Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) (expires September 3, 2018)

• Internet draft draft-ietf-idr-aigp-06, The Accumulated IGP Metric Attribute for BGP (expires December 2011)

• Internet draft draft-ietf-idr-as0-06, Codification of AS 0 processing (expires February 2013)

• Internet draft draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expires July 2013)

• Internet draft draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (partial support) (expires May 2011)

  The extended community (origin validation state) is supported in Junos OS routing policy. The specified change in the route selection procedure is not supported.

• Internet draft draft-kato-bgp-ipv6-link-local-00.txt, BGP4+ Peering Using IPv6 Link-local Address

The following RFCs and Internet draft do not define standards, but provide information about BGP and related technologies. The IETF classifies them variously as “Experimental” or “Informational.”

• RFC 1965, Autonomous System Confederations for BGP

• RFC 1966, BGP Route Reflection—An alternative to full mesh IBGP

• RFC 2270, Using a Dedicated AS for Sites Homed to a Single Provider

• RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition

• RFC 3562, Key Management Considerations for the TCP MD5 Signature Option

• Internet draft draft-ietf-ngtrans-bgp-tunnel-04.txt, Connecting IPv6 Islands across IPv4 Clouds with BGP (expires July 2002)