BGP: A Complete Guide to Border Gateway Protocol

What BGP is and why it runs the internet

Border Gateway Protocol, defined in RFC 4271 (the current standard, updated from RFC 1771), is the glue that holds the internet together. Every major network on the planet uses BGP to tell its neighbors which IP prefixes it can reach and to listen for the same information from others. Without BGP, there would be no way for a packet leaving your home router to find its way to a server in another country.

BGP is a path-vector protocol. Unlike an interior gateway protocol (IGP) such as OSPF or IS-IS, which computes shortest paths inside a single organization, BGP exchanges reachability information between autonomous systems (ASes). An AS is a network under a single administrative domain with a unique 32-bit AS number (RFC 6793). When AS 64500 tells AS 64501 that it can reach 203.0.113.0/24, it also passes along the AS path, a list of every AS the route has traversed. That path vector is BGP's most fundamental loop-prevention mechanism.

The "why BGP runs the internet" part is straightforward: it is the only protocol that scales to the global routing table. As of early 2025, the full table has approximately 1,000,000 IPv4 prefixes and around 150,000 IPv6 prefixes (DFZ RIB size). ISPs, content providers, and enterprises all use BGP to control how traffic enters and leaves their networks. BGP gives each operator the ability to apply local policies, preferring lower cost paths, shorter AS paths, or more reliable links using attributes like MULTI_EXIT_DISC (MED), LOCAL_PREF, and AS_PATH prepending.

BGP runs on TCP port 179, established between two routers (peers) in different ASes for eBGP or the same AS for iBGP. The session uses a finite-state machine (IDLE, CONNECT, ACTIVE, OPENSENT, OPENCONFIRM, ESTABLISHED) to negotiate capabilities before exchanging routes. After the initial exchange, only changes are sent using UPDATE messages, keeping bandwidth low.

Path-vector routing in plain English

BGP is neither a distance-vector protocol like RIP nor a link-state protocol like OSPF or IS-IS. It belongs to a third family: path-vector routing. The name tells you the key idea: instead of advertising just a metric (distance) or the full topology (link state), BGP advertises the entire path of Autonomous System numbers that a route has passed through.

When a BGP router learns a route to 203.0.113.0/24, the update carries an AS_PATH attribute like 64500 64496 64321. That string means the route originated in AS 64321, passed through AS 64496, and then reached AS 64500 before being sent to the current router. This path vector is the core innovation that lets BGP scale to the global Internet. It solves the loop-detection problem without complex math: if a router sees its own AS number in the AS_PATH, it discards the update immediately. No counting to infinity, no split horizon tricks, just a simple list check.

Why BGP does not calculate shortest paths

Distance-vector protocols pick the route with the lowest hop count. Link-state protocols run Dijkstra's algorithm to find the shortest path. BGP does neither. Every operator can define its own policy for which path is best. A route with a longer AS_PATH may be preferred over a shorter one if the shorter path goes through an untrusted provider. BGP gives the administrator freedom to rank routes by local preference, MED, communities, or dozens of other attributes defined in RFC 4271 and later extensions.

This policy-driven design is what makes the Internet work as a confederation of competing networks. A transit provider can decide to prefer its own customers over peers. A content network can prepend its AS multiple times to discourage inbound traffic on a backup link. BGP's path-vector model makes all of that possible without any central authority dictating the forwarding table.

How updates propagate

A BGP speaker stores routes in a Adj-RIB-In table from each neighbor. The Local-RIB holds the best routes selected after applying the decision process, and the Adj-RIB-Out contains what the router will advertise to its peers. When a route is withdrawn, the router removes it and recalculates its best path. This incremental update behavior keeps bandwidth usage low compared to periodic full-table dumps, but it also creates the possibility of cascading failures if a router misbehaves.

The practical consequence: every prefix on the Internet has at least one active path vector attached. By inspecting the AS_PATH you can see the exact sequence of networks a packet would traverse in the data plane (assuming no MPLS or traffic engineering tricks). Tools like bgp.he.net and looking glass servers display these paths so operators can debug reachability issues.

eBGP vs iBGP: the two BGP modes explained

BGP appears in two distinct operational modes: External BGP (eBGP) and Internal BGP (iBGP). The difference is not a software toggle. It is a fundamental design rule that changes how routes are propagated, how the protocol treats the next-hop attribute, and how loops are prevented.

eBGP: The glue between autonomous systems

eBGP runs between routers in different autonomous systems (AS). When AS 64496 peers with AS 64497 across a direct link, both routers speak eBGP. The default TTL for eBGP packets is 1, meaning the peer must be directly connected (on Cisco IOS, ebgp-multihop changes this, but 1 is RFC 1771 default). Every eBGP route carries the AS path of the originating AS. If a router receives a route that already contains its own AS number in the path, it discards the route. This is the loop prevention mechanism specific to eBGP.

eBGP imposes a default administrative distance of 20 on Cisco gear (110 on Juniper). Most importantly, when an eBGP route is advertised, the next-hop IP is set to the IP address of the advertising router. There is no reason to change it, because the two peers are directly connected.

iBGP: Routing inside an autonomous system

iBGP runs between routers inside the same AS. The TTL is set to 255, so iBGP peers do not need to be directly connected. They can peer across the network using loopback interfaces, which is the recommended design. The killer rule of iBGP is RFC 4456: an iBGP speaker must not re-advertise a route learned from one iBGP peer to another iBGP peer. This is the split-horizon rule. It prevents routing loops within the AS. The consequence is that every router in the AS must have a full mesh of iBGP sessions, or use route reflection (RFC 4456) or confederations (RFC 5065).

iBGP also changes the next-hop behavior. By default, iBGP preserves the next-hop address set by the eBGP edge router. If you do not redistribute the eBGP-learned next hop into your IGP (OSPF or IS-IS), the iBGP route is unusable because the router has no route to the next hop. This is a common pitfall: configure next-hop-self on the eBGP border router or redistribute the connected subnet.

Key operational differences at a glance

The administrative distance for iBGP is 200 on Cisco hardware, higher than eBGP, reflecting the bias that external routes are often considered more reliable (they represent a direct connection to the internet). The AS path behavior is also different: iBGP does not prepend or check the AS path within the same AS. Loop prevention relies entirely on the split-horizon (or, in route reflection, on the cluster-list and originator-id attributes).

In production, you almost always run both modes. A BGP border router runs eBGP with your transit providers and iBGP with your internal routers. The internal routers run iBGP to receive the full internet table or a default route, plus iBGP to exchange customer prefixes internally. The two modes work together; confusing their rules causes unreachable routes or routing loops.

How a BGP best-path is chosen

A single BGP router may receive multiple paths to the same destination prefix from different peers. It must select exactly one path to install in its routing table, and that decision follows a deterministic, step by step sequence defined in RFC 4271. Cisco, Juniper, Arista, and other vendors implement the same basic order of operations. They may differ on tiebreakers, but the core logic is industry standard.

The best-path selection algorithm

The router evaluates paths in this order, stopping at the first tiebreaker that produces a single winner:

1. Highest Weight (Cisco proprietary). The local router assigns weight. Higher weight wins. This never leaves the router.
2. Highest Local Preference. iBGP propagates this attribute across the AS. Default is 100. Higher is better. Operators use local pref to prefer a specific upstream.
3. Prefer locally originated routes. Routes injected via network or aggregate-address statements beat learned routes.
4. Shortest AS_PATH. Count the number of AS numbers in the path. Fewer AS hops wins. This is the most common tiebreaker for simple choices.
5. Lowest origin type. IGP (i) beats EGP (e), EGP beats incomplete (?).
6. Lowest Multi-Exit Discriminator (MED). The MED is exchanged between AS peers. A lower MED value is preferred. MED only applies when the paths come from the same neighboring AS.
7. eBGP over iBGP. An external path wins over an internal path.
8. Lowest IGP metric to the next-hop. The router picks the path whose next-hop address is closest by IGP cost.
9. Route age. Cisco prefers the oldest path. Juniper uses the youngest path. This step rarely decides production traffic.
10. Lowest peer router ID. The IP address of the advertising router. Lower is better. This is the final tiebreaker.

Why the order matters

The algorithm always runs on the set of paths that the router considers valid. A path with an unreachable next-hop is removed before selection. A path rejected by inbound policy never reaches the decision process. Operators manipulate attributes like local preference and MED to influence where traffic enters and exits their network. You cannot skip steps. The router always works through the list from top to bottom.

Caveats for load balancing

If multiple paths tie after step 8 (lowest IGP metric to next-hop) and the router supports multipath, it installs multiple equal paths. The default behavior on most platforms still requires the paths to be identical up to step 8. AS_PATH length and MED must match for the paths to be considered equal for load sharing. You can configure bgp bestpath as-path multipath-relax to ignore AS_PATH length in the tiebreaker.

BGP attributes you actually need to know

Every BGP update carries a set of attributes attached to the prefix. The BGP decision process (described in the prior section) uses these attributes to choose a single best path. You don't need to memorize all 20+ attribute types defined across RFC 4271 and later extensions. But there are seven attributes that network engineers encounter daily in configuration, troubleshooting, and traffic engineering.

AS_PATH

This is the list of AS numbers a route has traversed. It is the core loop-prevention mechanism. When a router receives a route whose AS_PATH already contains its own ASN, the router discards the update. Longer AS_PATHs are generally worse, so the decision process prefers shorter paths. Operators sometimes prepend fake ASN copies to make a path look longer, purposely sending traffic away. Example prepend on a Cisco router:

route-map PREPEND permit 10
 set as-path prepend 64496 64496 64496

NEXT_HOP

For eBGP, the NEXT_HOP is the IP address of the neighbor that sent the update. For iBGP, the NEXT_HOP remains the eBGP peer address unless changed with next-hop-self. The router must have a valid IGP route to the NEXT_HOP address before the BGP route can be installed. Broken NEXT_HOP reachability is one of the most common BGP troubleshooting mistakes.

LOCAL_PREF

LOCAL_PREF is a whole-AS attribute exchanged only across iBGP sessions. It has no meaning in eBGP updates. Higher values win. The default is 100 (RFC 4271) but many implementations default to 100. Operators raise LOCAL_PREF on routes received from a preferred upstream provider. Example setting on a Juniper router:

set policy-options policy-statement SET-LOCAL-PREF term 10 from neighbor 198.51.100.1
set policy-options policy-statement SET-LOCAL-PREF term 10 then local-preference 150

MULTI_EXIT_DISC (MED)

MED tells a neighboring AS which peering point to use for inbound traffic. Lower MED values are preferred. MED is propagated across the directly adjacent AS only (unless bgp deterministic-med is configured). Common use: a network with two peering links sets MED 100 on one link and MED 200 on the other to signal the neighbor to prefer the first link.

ORIGIN

This attribute tells how BGP learned the route. Three values exist: IGP (i), EGP (e), incomplete (?). i means the route was injected via the network statement. e is obsolete (EGP protocol, no longer used). ? means the route was redistributed from another routing protocol. The decision process prefers i over e over ?.

Weight (Cisco proprietary)

Weight is not part of the RFC but appears on most Cisco and some other vendors as a local attribute that never leaves the router. Higher weight wins and is evaluated before LOCAL_PREF in the decision process. Weight 32768 is the default for locally injected routes. Weight is the fastest way to prefer one eBGP path over another on a single router.

Community

A community is a 32-bit tag (often written as two 16-bit numbers, ASN:value) carried in an update. Communities are not used in the best-path selection algorithm itself. But they are the primary mechanism for signaling policy between networks. Transit providers use them to control route propagation, local preference changes, and prefix filtering. The well-known communities (NO_EXPORT, NO_ADVERTISE, LOCAL_AS) are defined in RFC 1997. Community usage is covered in full detail in a later section of this guide.

Common BGP security problems (route hijacks, leaks)

BGP was designed in the late 1980s when the internet had a few hundred networks and trust was a reasonable assumption. That trust is now the root cause of BGP's biggest security problems. There are two principal categories: route hijacks and route leaks. They sound similar but work differently, and both can take down large parts of the internet with nothing more than a single misconfigured router.

Route hijacks: stealing someone else's IP space

A route hijack occurs when a network announces an IP prefix it does not legitimately own. Because BGP has no built-in mechanism to verify that an AS is authorized to originate a prefix, neighboring routers simply accept the most specific or best-path advertisement. The hijack can be intentional (an attacker trying to intercept traffic) or accidental (an engineer typing the wrong prefix into a prefix-list).

A famous example happened in 2008 when Pakistan Telecom attempted to block YouTube internally. Their BGP announcement for YouTube's prefix was more specific than the real originator, so the hijack propagated globally. YouTube was unreachable for roughly two hours for most of the internet. More recently, in 2018, attackers used a BGP hijack to redirect traffic intended for Amazon's DNS infrastructure (the Route 53 service) to a malicious server, allowing them to steal cryptocurrency from MyEtherWallet users.

Route leaks: violating the path's promise

Route leaks look accidental more often than not, but they are just as damaging. A leak happens when an AS advertises a route it learned from one neighbor to another neighbor in violation of the intended business relationship. The classic scenario: a customer advertises a full Internet table to a transit provider that it received from a different transit provider. This forces traffic to take a path that violates the BGP path selection rules and can cause massive link congestion or blackholes.

The most damaging leakage event to date was the 2019 Verizon route leak. A small ISP in Pennsylvania (DQE Communications) leaked roughly 30,000 routes it had learned from one upstream (Verizon) to another upstream (Altoas). The resulting propagation of those routes redirected traffic from hundreds of large networks through a small ISP infrastructure, causing outages at Amazon, Google, Cloudflare, and others for several hours.

Why these problems keep happening

BGP's trust model is the biggest reason. A router treats every BGP UPDATE as honest until shown otherwise. There are no origin checks, no signature verifications, no path-validation mechanisms embedded in the protocol itself. Filtering (prefix lists, AS-path ACLs) helps limit the damage between known peers, but the global mesh is too large and too dynamic for manual filters alone.

Prefix hijacks exploit the fact that BGP has no origin authorization. Leaks exploit the absence of path-purpose validation. IETF documents RFC 7908 (Problem Definition and Classification of BGP Route Leaks) and RFC 7454 (BGP Operations and Security) describe both problems in detail. They provide classification taxonomies, but they do not fix the missing security properties at the protocol level.

RPKI and how it stops origin hijacks

Route hijacks happen when a network announces a prefix it does not own. The classic example is the 2008 Pakistan Telecom hijack of YouTube's 208.65.152.0/22. Pakistan Telecom announced a more specific /24, and traffic from around the world followed. The attacker did not break encryption, but they could intercept or drop traffic. For years, the only defense was manual filtering and operator trust. Resource Public Key Infrastructure (RPKI) changes that by adding cryptographic verification to BGP origin announcements.

RPKI ties an IP prefix to an Autonomous System Number (ASN) through a signed digital object called a Route Origin Authorization (ROA). A ROA states: "AS 64496 is authorized to originate 203.0.113.0/24 with a maximum prefix length of /24." The ROA is signed using the private key of the prefix holder's certificate, which chains up to one of the five Regional Internet Registries (RIRs). The public key is published in the RPKI repository, a distributed database of signed objects. Any network can fetch the repository and validate ROAs.

The validation happens in three states. If a route matches a ROA exactly or is a less specific prefix within the ROA's max length, it is Valid. If a route is more specific than the ROA allows, or the ASN does not match, it is Invalid. If no ROA exists for the prefix, it is NotFound. Routers running RPKI-enabled BGP implementations, such as Cisco IOS XR, Juniper Junos, or Bird 2.x, can import these states and apply local policy. A common practice is to set a lower local preference on Invalid routes or discard them entirely.

Deploying RPKI requires three components. First, a Relying Party (RP) software, like Routinator, OctoRPKI, or RIPE NCC's RPKI Validator, fetches and validates the signed objects from the RIRs. Second, the RP exports the validated ROA payload to routers via the RPKI-to-Router (RTR) protocol, defined in RFC 6810 and updated by RFC 8210. Routers connect to the RP on TCP port 323 and receive a stream of prefix-to-ASN mappings. Third, the router applies the validation state in its BGP decision process. The RPKI state is checked during the best-path selection, typically after the highest local preference and before the shortest AS path.

The effect is measurable. As of early 2025, RIPE NCC reports that over 40% of all IPv4 and IPv6 prefixes in the global table have a ROA. Major transit providers, including NTT, Cogent, and Lumen, deploy RPKI-based filtering. When a hijack attempt occurs, networks that validate RPKI will reject the Invalid route, preventing the hijack from propagating. RPKI does not stop route leaks, which involve valid origins but invalid paths. It also does not prevent a prefix holder from accidentally authorizing a rogue ASN. But for origin hijacks, RPKI is the most practical cryptographic defense available today.

BGP communities, why operators love them

BGP communities are an optional transitive attribute defined in RFC 1997. A community is a 32-bit value, traditionally written as two 16-bit halves: the AS number of the operator that defines the community, and a locally significant tag. For example, 1234:100 means AS 1234 defines tag 100. RFC 8092 later introduced BGP Large Communities, which use a 96-bit value (three 32-bit fields) to accommodate 32-bit AS numbers.

Communities are not used in path selection. Instead, they tag a route so that a receiving router can apply a policy based on the tag. This is the core reason operators love them. A customer can send a route with a community, and the upstream provider's router will match that community and perform an action: prepend ASes, set local preference, filter the route, or mark it for no-export. The customer controls traffic engineering without needing to negotiate per-session policies.

Well-known communities

RFC 1997 defines a few well-known communities that any BGP implementation must support:

• NO_EXPORT (0xFFFFFF01): Do not advertise this route to any eBGP peer outside the local confederation.
• NO_ADVERTISE (0xFFFFFF02): Do not advertise this route to any peer, internal or external.
• NO_EXPORT_SUBCONFED (0xFFFFFF03): Do not advertise outside the local AS (but can be advertised within a confederation).
• NO_PEER (0xFFFFFF04): Do not advertise to a specific type of peer (rarely used).

Why operators love them

First, communities enable traffic engineering at scale. A transit provider like NTT (AS2914) publishes a list of community tags that customers can attach to their prefixes. For example, 2914:420 might instruct NTT to prepend the route once to all peers. 2914:3200 might set local preference to 200 inside NTT's network. The customer does not need to open a ticket or change peering agreements. The policy is pre-configured and automated.

Second, communities simplify multi-homing. A network that connects to two or more upstreams can use provider-specific communities to influence which path is preferred for inbound traffic. For example, a route tagged with 174:200 (Cogent) might be prepended to make the other provider more attractive. Operators can script these tags into route maps based on prefix length, origin AS, or other criteria.

Third, communities support operational automation. Many networks use communities internally to signal route origin, geography, or service type. An internal community like 65000:1 might mark a customer prefix, while 65000:2 marks a peering prefix. The edge routers then apply different export policies based on these tags. This reduces manual configuration and human error.

Fourth, communities allow fine-grained control over route propagation. The NO_EXPORT community is widely used to keep a route within a single AS. Operators also define custom communities to limit advertisement to specific regions or peer groups. For instance, a community 1239:100 (Sprint) might mean "advertise only to North American peers."

The flexibility of communities comes with a warning. Because communities are not authenticated, a malicious or misconfigured peer can inject arbitrary tags. Providers must validate incoming communities and only honor those from trusted customers. Communities are a tool for cooperation, not security.

Real outages: when BGP misconfiguration broke the internet

BGP failures are not theoretical. Every few years a single typo, a fat-fingered config change, or a deliberate hijack takes down major websites, banks, or entire countries. These incidents are worth studying because they reveal exactly how fragile the trust model of BGP is and why defenses like RPKI and prefix filtering matter.

The 2008 Pakistan YouTube hijack

On February 24, 2008, Pakistan Telecom (AS17557) intended to block YouTube within Pakistan. It advertised a more specific route for YouTube's IP block (208.65.153.0/24) to its upstream transit provider, PCCW (AS3491). The problem: PCCW did not filter the announcement and propagated it to the rest of the internet. Because BGP prefers the most specific prefix, traffic from around the world began flowing to Pakistan Telecom, which had no way to serve it. YouTube was effectively offline for roughly two hours. This incident is the canonical example of a route leak caused by a lack of prefix-level filtering and the absence of RPKI at the time.

The 2017 Google route leak

On August 25, 2017, a small Nigerian ISP, MainOne (AS37282), accidentally announced 65,000 prefixes belonging to Google, YouTube, Gmail, and other Google services. MainOne's upstream, China Telecom (AS4809), accepted the routes and propagated them globally. For about 30 minutes, traffic destined for Google services was routed through Nigeria and China. The leak did not cause a full outage but resulted in severe latency and packet loss for users worldwide. Google's own BGP monitoring systems detected the anomaly and worked with operators to withdraw the bogus routes. The root cause: a misconfigured BGP session that leaked the full global routing table instead of only MainOne's own prefixes.

The 2019 Facebook (Meta) outage

On March 13, 2019, Facebook suffered a 14-hour outage that took down Facebook, Instagram, and WhatsApp. The cause was a routine BGP configuration change that inadvertently withdrew all of Facebook's prefixes from the global routing table. Facebook's network engineers were locked out of their own systems because the DNS servers for the corporate network were hosted on the same IP blocks that had been withdrawn. Recovery required physical access to data centers and manual reconfiguration of routers. This incident highlights a critical operational lesson: when your control plane depends on the same infrastructure you are reconfiguring, you can create a self-inflicted denial of service.

The 2021 BGP hijack of MyEtherWallet

On April 24, 2018, a malicious actor hijacked Amazon Route 53's DNS traffic for MyEtherWallet, a cryptocurrency wallet service. The attacker used a BGP hijack to redirect users to a phishing site that stole approximately $17 million in Ethereum. The hijack exploited the fact that Amazon's DNS servers were reachable via a /23 prefix that an attacker could more specifically announce. This incident is often cited as a textbook case of a prefix hijack combined with DNS spoofing, and it directly motivated the push for RPKI deployment among cloud providers.

What these incidents teach us

Every one of these outages could have been prevented or mitigated with three practices: strict prefix filtering on upstream sessions, deployment of RPKI to validate origin AS ownership, and implementation of BGP Flowspec or similar mechanisms to quickly withdraw hijacked routes. The common thread is that BGP trusts every announcement by default. Until the internet adopts widespread route validation, operators must assume that any prefix they receive could be a mistake or an attack.

BGP for buyers: what to look for in a transit provider

If you are buying IP transit for a data center, an office, or a cloud region, the BGP configuration your provider offers matters as much as the port speed and price. Not all transit providers expose the same BGP knobs. Some give you fine-grained control over routing policy. Others give you a default route and little else. Here is what to ask for before you sign the contract.

Full tables vs default route

The first decision is whether you need the full Internet BGP table (currently around 1 million IPv4 routes and 150,000 IPv6 routes) or a default route. If you have a single upstream, a default route is simpler and consumes almost no router memory. If you have two or more providers and want to control outbound path selection, you need full tables so your router can compare paths and choose the best exit. Ask the provider whether they offer full tables, partial tables, or default-only. Most tier 1 and tier 2 providers give full tables at no extra cost.

BGP communities

BGP communities are tags you attach to routes you advertise to your provider. The provider reads the tag and modifies its routing behavior. Common community actions include: do not advertise to peers, do not advertise to a specific region, or prepend a certain number of AS hops. For example, a provider might use community 1239:70 to tell its routers "do not advertise this route to Asia." Without communities, you have no way to influence how your traffic flows once it leaves your network. Ask the provider for their community documentation. If they do not publish a community list, that is a red flag.

RPKI and IRR filtering

Your provider should validate your route announcements using the Internet Routing Registry (IRR) and Resource Public Key Infrastructure (RPKI). This prevents you from accidentally hijacking someone else's prefix and prevents others from hijacking yours. Ask: "Do you filter my announcements against IRR data? Do you drop RPKI Invalid routes?" A provider that does not filter is exposing you and itself to route hijacks. Look for providers that publish their filtering policy in a PeeringDB entry or an RPSL document.

Prefix limits and session reset behavior

If you accidentally announce too many routes (a common misconfiguration), your provider may reset the BGP session. Some providers apply a hard limit that drops the session immediately. Others apply a soft limit that logs a warning but keeps the session up. Ask what the default prefix limit is and whether you can adjust it. Also ask whether the provider supports the soft-reconfiguration inbound option, which lets you see all received routes even after a policy change without resetting the session.

Support for BGP multipath and load balancing

If you connect to the same provider at multiple points, ask whether they support BGP multipath (sometimes called "equal cost multipath" or ECMP). This lets your router send traffic across both links simultaneously instead of using one as a backup. Not all providers configure their routers to accept multipath from customers. If load balancing across multiple circuits matters to you, confirm this before ordering.

SLA and maintenance windows

Finally, ask about BGP session maintenance. Some providers schedule router software upgrades during announced maintenance windows and will gracefully shut down the BGP session so traffic shifts to your backup link. Others simply reboot the router, causing a hard reset and packet loss. A provider that follows BGP Graceful Shutdown procedures (RFC 8326) is preferable.