Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

BGP Overview

Understanding BGP

BGP is an exterior gateway protocol (EGP) that is used to exchange routing information among routers in different autonomous systems (ASs). BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain a database of network reachability information, which it exchanges with other BGP systems. BGP uses the network reachability information to construct a graph of AS connectivity, which enables BGP to remove routing loops and enforce policy decisions at the AS level.

Multiprotocol BGP (MBGP) extensions enable BGP to support IP version 6 (IPv6). MBGP defines the attributes MP_REACH_NLRI and MP_UNREACH_NLRI, which are used to carry IPv6 reachability information. Network layer reachability information (NLRI) update messages carry IPv6 address prefixes of feasible routes.

BGP allows for policy-based routing. You can use routing policies to choose among multiple paths to a destination and to control the redistribution of routing information.

BGP uses TCP as its transport protocol, using port 179 for establishing connections. Running over a reliable transport protocol eliminates the need for BGP to implement update fragmentation, retransmission, acknowledgment, and sequencing.

The Junos OS routing protocol software supports BGP version 4. This version of BGP adds support for Classless Interdomain Routing (CIDR), which eliminates the concept of network classes. Instead of assuming which bits of an address represent the network by looking at the first octet, CIDR allows you to explicitly specify the number of bits in the network address, thus providing a means to decrease the size of the routing tables. BGP version 4 also supports aggregation of routes, including the aggregation of AS paths.

This section discusses the following topics:

Autonomous Systems

An autonomous system (AS) is a set of routers that are under a single technical administration and normally use a single interior gateway protocol and a common set of metrics to propagate routing information within the set of routers. To other ASs, an AS appears to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.

AS Paths and Attributes

The routing information that BGP systems exchange includes the complete route to each destination, as well as additional information about the route. The AS path is the sequence of autonomous systems the route traversed, and additional route information is included in path attributes. BGP uses the AS path and the path attributes to completely determine the network topology. Once BGP understands the topology, it can detect and eliminate routing loops and select among groups of routes to enforce administrative preferences and routing policy decisions.

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 IBGPASs, 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.

Multiple Instances of BGP

You can configure multiple instances of BGP at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Multiple instances of BGP are primarily used for Layer 3 VPN support.

IGP peers and external BGP (EBGP) peers (both nonmultihop and multihop) are all supported for routing instances. BGP peering is established over one of the interfaces configured under the routing-instances hierarchy.

Note:

When a BGP neighbor sends BGP messages to the local routing device, the incoming interface on which these messages are received must be configured in the same routing instance that the BGP neighbor configuration exists in. This is true for neighbors that are a single hop away or multiple hops away.

Routes learned from the BGP peer are added to the instance-name.inet.0 table by default. You can configure import and export policies to control the flow of information into and out of the instance routing table.

For Layer 3 VPN support, configure BGP on the provider edge (PE) router to receive routes from the customer edge (CE) router and to send the instances’ routes to the CE router if necessary. You can use multiple instances of BGP to maintain separate per-site forwarding tables for keeping VPN traffic separate on the PE router.

You can configure import and export policies that allow the service provider to control and rate-limit traffic to and from the customer.

You can configure an EBGP multihop session for a VRF routing instance. Also, you can set up the EBGP peer between the PE and CE routers by using the loopback address of the CE router instead of the interface addresses.

Allow Protocol Traffic for Interfaces in a Security Zone

On SRX Series Firewalls, you must enable the expected host-inbound traffic on the specified interfaces or all interfaces of the zone. Otherwise inbound traffic destined to this device is dropped by default.

For example, to allow BGP traffic on a specific zone of your SRX Series Firewall, use the following step:

(All interfaces) (Specified interface)

See Also

BGP Routes Overview

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.

See Also

BGP Route Resolution Overview

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.

See Also

BGP Messages Overview

All BGP messages have the same fixed-size header, which contains a marker field that is used for both synchronization and authentication, a length field that indicates the length of the packet, and a type field that indicates the message type (for example, open, update, notification, keepalive, and so on).

This section discusses the following topics:

Open Messages

After a TCP connection is established between two BGP systems, they exchange BGP open messages to create a BGP connection between them. Once the connection is established, the two systems can exchange BGP messages and data traffic.

Open messages consist of the BGP header plus the following fields:

  • Version—The current BGP version number is 4.

  • Local AS number—You configure this by including the autonomous-system statement at the [edit routing-options] or [edit logical-systems logical-system-name routing-options] hierarchy level.

  • Hold time—Proposed hold-time value. You configure the local hold time with the BGP hold-time statement.

  • BGP identifier—IP address of the BGP system. This address is determined when the system starts and is the same for every local interface and every BGP peer. You can configure the BGP identifier by including the router-id statement at the [edit routing-options] or [edit logical-systems logical-system-name routing-options] hierarchy level. By default, BGP uses the IP address of the first interface it finds in the router.

  • Parameter field length and the parameter itself—These are optional fields.

Update Messages

BGP systems send update messages to exchange network reachability information. BGP systems use this information to construct a graph that describes the relationships among all known ASs.

Update messages consist of the BGP header plus the following optional fields:

  • Unfeasible routes length—Length of the withdrawn routes field

  • Withdrawn routes—IP address prefixes for the routes being withdrawn from service because they are no longer deemed reachable

  • Total path attribute length—Length of the path attributes field; it lists the path attributes for a feasible route to a destination

  • Path attributes—Properties of the routes, including the path origin, the multiple exit discriminator (MED), the originating system’s preference for the route, and information about aggregation, communities, confederations, and route reflection

  • Network layer reachability information (NLRI)—IP address prefixes of feasible routes being advertised in the update message

Keepalive Messages

BGP systems exchange keepalive messages to determine whether a link or host has failed or is no longer available. Keepalive messages are exchanged often enough so that the hold timer does not expire. These messages consist only of the BGP header.

Notification Messages

BGP systems send notification messages when an error condition is detected. After the message is sent, the BGP session and the TCP connection between the BGP systems are closed. Notification messages consist of the BGP header plus the error code and subcode, and data that describes the error.

Route-Refresh Messages

BGP systems send route-refresh messages to a peer only if they have received the route refresh capability advertisement from the peer. A BGP system must advertise the route refresh capability to its peers using BGP capabilities advertisement if it wants to receive route-refresh messages. This optional message is sent to request dynamic, inbound, BGP route updates from BGP peers or to send outbound route updates to a BGP peer.

Route-refresh messages consist of the following fields:

  • AFI—Address Family Identifier (16-bit).

  • Res—Reserved (8-bit) field, which must be set to 0 by the sender and ignored by the receiver.

  • SAFI—Subsequent Address Family Identifier (8-bit).

If a peer without the route-refresh capability receives a route-refresh request message from a remote peer, the receiver ignores the message.

See Also

Understanding BGP RIB sharding and BGP Update IO thread

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.

Understanding BGP Path Selection

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.

    Prefer routes learned via BGP.

    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

The shortest AS path step of the algorithm, by default, evaluates the length of the AS path and determines the active path. You can configure an option that enables Junos OS to skip this step of the algorithm by including the as-path-ignore option.

Note:

Starting with Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6, and 16.1R1, the as-path-ignore option is supported for routing instances.

The routing process path selection takes place before BGP hands off the path to the routing table to makes its decision. To configure routing table path selection behavior, include the path-selection statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Routing table path selection can be configured in one of the following ways:

  • Emulate the Cisco IOS default behavior (cisco-non-deterministic). This mode evaluates routes in the order that they are received and does not group them according to their neighboring AS. With cisco-non-deterministic mode, the active path is always first. All inactive, but eligible, paths follow the active path and are maintained in the order in which they were received, with the most recent path first. Ineligible paths remain at the end of the list.

    As an example, suppose you have three path advertisements for the 192.168.1.0 /24 route:

    • Path 1—learned through EBGP; AS Path of 65010; MED of 200

    • Path 2—learned through IBGP; AS Path of 65020; MED of 150; IGP cost of 5

    • Path 3—learned through IBGP; AS Path of 65010; MED of 100; IGP cost of 10

    These advertisements are received in quick succession, within a second, in the order listed. Path 3 is received most recently, so the routing device compares it against path 2, the next most recent advertisement. The cost to the IBGP peer is better for path 2, so the routing device eliminates path 3 from contention. When comparing paths 1 and 2, the routing device prefers path 1 because it is received from an EBGP peer. This allows the routing device to install path 1 as the active path for the route.

    Note:

    We do not recommend using this configuration option in your network. It is provided solely for interoperability to allow all routing devices in the network to make consistent route selections.

  • Always comparing MEDs whether or not the peer ASs of the compared routes are the same (always-compare-med).

  • Override the rule that If both paths are external, the currently active path is preferred (external-router-id). Continue with the next step (Step 12) in the path-selection process.

  • Adding the IGP cost to the next-hop destination to the MED value before comparing MED values for path selection (med-plus-igp).

    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.

BGP Table path selection

The following parameters are followed for BGP's path selection:

  1. Prefer the highest local-preference value.

  2. Prefer the shortest AS-path length.

  3. Prefer the lowest origin value.

  4. Prefer the lowest MED value.

  5. Prefer routes learned from an EBGP peer over an IBGP peer.

  6. Prefer best exit from AS.

  7. For EBGP-received routes, prefer the current active route.

  8. Prefer routes from the peer with the lowest Router ID.

  9. Prefer paths with the shortest cluster length.

  10. Prefer routes from the peer with the lowest peer IP address. Steps 2, 6 and 12 are the RPD criteria.

Effects of Advertising Multiple Paths to a Destination

BGP advertises only the active path, unless you configure BGP to advertise multiple paths to a destination.

Suppose a routing device has in its routing table four paths to a destination and is configured to advertise up to three paths (add-path send path-count 3). The three paths are chosen based on path selection criteria. That is, the three best paths are chosen in path-selection order. The best path is the active path. This path is removed from consideration and a new best path is chosen. This process is repeated until the specified number of paths is reached.

See Also

Supported Standards for BGP

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

  • 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 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 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)

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.2R1
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.
14.1R8
Starting with Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6, and 16.1R1, the as-path-ignore option is supported for routing instances.