cloudflareJul 24, 2026

BGP ORIGIN attribute manipulation and its impact on the Internet (opens in new tab)

BGP’s ORIGIN attribute is intended to describe how a route entered the protocol and should remain unchanged after being set by the originating AS. However, the investigation found that roughly 70% of observed paths had an ORIGIN value different from the original, often because transit providers manipulate it to influence route selection and attract traffic. This widespread practice turns a supposedly stable routing signal into a tool in a revenue-driven competition between networks. ## What the BGP ORIGIN Attribute Means - ORIGIN describes how a route was injected into BGP, rather than identifying the originating Autonomous System. - It has three values: - **IGP (0):** The route originated within the AS. - **EGP (1):** A historical value associated with the obsolete Exterior Gateway Protocol. - **INCOMPLETE (2):** The route was learned through an unknown or external mechanism. - Across routes visible through RIPE RIS and RouteViews: - 89.8% used IGP. - 3.5% used EGP. - 6.7% used INCOMPLETE. - When Local Preference and AS_PATH length are equal, BGP prefers the lower ORIGIN value, making IGP preferable to EGP and INCOMPLETE. - RFC 4271 states that ORIGIN is generated by the originating speaker and **should not be changed** by other speakers. ## How Providers Use ORIGIN Manipulation - A transit provider can rewrite a route’s ORIGIN to IGP, making its path more attractive during BGP route selection. - In the example: - AS64501 announces a route with ORIGIN INCOMPLETE. - AS64502 and AS64503 propagate the route to AS64504. - AS64503 changes the ORIGIN to IGP. - Because both paths have equal AS_PATH lengths, AS64504 selects the path through AS64503. - This manipulation redirects traffic—and potentially transit revenue—toward the provider that altered the attribute. - Some operators also rewrite routes to EGP or INCOMPLETE to make them less preferred than customer routes. - The practice has been discussed at RIPE and LACNIC meetings and has contributed to proposals recommending that ORIGIN be deprecated. ## Measuring ORIGIN Rewriting - The researchers announced: - Three IPv4 prefixes. - Three IPv6 prefixes. - Each prefix used a different ORIGIN value: IGP, EGP, or INCOMPLETE. - Announcements were made from multiple peering locations using BGP Anycast. - After propagation, the prefixes were withdrawn to trigger BGP path hunting, exposing additional routes. - Researchers analyzed: - MRT UPDATE messages from RIPE RIS and RouteViews. - Local BMP data from their border routers. - BGPKIT tools for parsing the data. - UPDATE messages were chosen over routing-table snapshots because they reveal more paths during both announcements and withdrawals. ## Visibility Challenges - Public collectors cannot observe every AS involved in a route’s propagation. - The growth of hyperscalers, CDNs, and direct local peering has flattened the traditional transit hierarchy. - As a result, many paths bypass publicly visible transit networks. - Conclusions about which AS changed an attribute therefore carry some uncertainty, especially beyond directly observed peers. ## Direct-Peer Findings - The first analysis examined two-AS paths such as `ASX AS13335`, where ASX was a direct peer of the researchers. - Because the researchers controlled the original ORIGIN value, any different value observed from a direct peer indicated that peer had rewritten it. - Among 352 IPv4 direct peers: - Three ASes consistently changed routes to EGP. - Four changed routes to INCOMPLETE, potentially attempting to deprioritize them. - One contacted operator confirmed that it rewrote peer- and provider-learned routes to EGP so customer routes would be preferred. - Several ASes advertised both the original ORIGIN and IGP for non-IGP prefixes, likely because they received the routes at multiple locations and altered the value to steer traffic through preferred sites. - Combining these behaviors, the researchers found that nearly 10% of direct peers were rewriting ORIGIN, while the broader experiment detected changes on approximately 70% of observed paths. Network operators should treat ORIGIN rewriting as a significant deviation from BGP’s intended behavior, since it can alter routing decisions, distort traffic engineering, and create commercial incentives for further manipulation.

bgpipv6autonomous-systemsipv4+4

cloudflareJun 3, 2026

Enforcing the First AS in BGP AS PATHs (opens in new tab)

Forged BGP AS_PATHs can let attackers impersonate legitimate networks, misdirect traffic, and conceal their true origin. Recent hijacks suggest some providers accept routes whose first AS does not match the customer peer that advertised them. Enforcing this “First AS” relationship check is a straightforward defense that complements RPKI and ASPA. ## Route Hijacks Involving Forged Paths - A reported hijack of Orange’s `90.98.0.0/15` included the path: `48237 1299 199524 270118 17072 41128`. - The path implied implausible commercial relationships: - `AS41128` was an unused Orange ASN. - `AS17072` was a Mexican ISP. - `AS270118` was a Mexican hosting provider. - `AS199524` was Gcore. - `AS1299` was Arelion, a Tier 1 provider. - Another hijack included Cloudflare’s ASN in the path: `199524 270118 17072 13335 36429`. - Cloudflare confirmed it had no adjacency with the unused `AS36429`, indicating that the path was fabricated. - The routes appeared to terminate behind Gcore rather than actually traversing the networks listed in the forged path. - The suspected attack sequence was: - Announce parked or unused prefixes. - Completely forge the AS_PATH without including the attacker’s ASN. - Send the route to Gcore. - Rely on the provider accepting the route without verifying its first AS. - Once accepted, the forged route could be propagated to upstream providers and peers. ## Why First AS Checking Matters - The BGP AS_PATH records the networks a route is expected to traverse. - It supports: - Route selection. - Loop prevention. - Operator routing policies. - BGP permits AS_PATH manipulation for legitimate purposes, such as AS prepending, but the same flexibility enables attackers to shorten or fabricate paths. - First AS enforcement verifies that the first AS in an advertised path matches the ASN of the customer or peer that sent the update. - Without this check, a customer can advertise a path that appears to originate from another network. ## Limits of RPKI and ASPA Alone - RPKI ROAs validate whether an origin ASN is authorized to announce a prefix. - ASPA validates provider-to-customer relationships. - However, an attacker may still bypass these mechanisms by: - Claiming an RPKI-valid origin ASN. - Including a legitimate ASPA provider in the forged path. - Omitting the attacker’s own ASN when the receiving provider does not enforce First AS. - In the example, a route forged to appear as though it originated from `AS64506` could remain RPKI-valid and attract traffic if `AS64502` accepted it without checking the peer’s first AS. ## Practical Recommendation Network operators should enable strict First AS checking on BGP sessions, alongside RPKI route-origin validation and ASPA deployment. These controls address different parts of the attack: RPKI validates the origin, ASPA checks authorized provider relationships, and First AS enforcement prevents a peer from presenting a path that does not begin with its own ASN.

bgpnetwork-securityasparpki+2

cloudflareApr 10, 2026

500 Tbps of capacity: 16 years of scaling our global network (opens in new tab)

Cloudflare’s network has grown from a single transit provider in 2010 to more than 500 Tbps of provisioned external capacity across 330+ cities. The company argues that this scale is not merely about bandwidth: it enables security decisions, application execution, and routing validation to happen locally on every server. Its distributed architecture can absorb massive attacks automatically while supporting edge computing and emerging Internet protocols. ## From Transit Provider to Global Network - Cloudflare began with nLayer Communications as its first transit provider. - Expansion required city-by-city work: colocation contracts, fiber installation, hardware deployment, and Internet exchange peering. - In 2018, Cloudflare opened 31 cities in 24 days, despite logistical challenges such as customs delays and missing equipment. - The network now spans more than 330 cities and protects over 20% of the web. - The 500 Tbps figure represents provisioned interconnection capacity across transit, private peering, Internet exchanges, and Cloudflare Network Interconnect ports—not peak traffic. ## Turning the Network into a Security Layer - Cloudflare expanded from caching websites to securing employees and enterprise networks. - Its systems establish secure tunnels to private subnets and advertise customer IP space through BGP. - In 2025, Cloudflare mitigated a 31.4 Tbps DDoS attack lasting 35 seconds. - The attack was part of more than 5,000 attacks blocked that day, without paging an engineer. - Distributed automation allows attacks that once required nation-state resources to be handled in seconds. ## Packet-Level DDoS Mitigation - Incoming packets enter an XDP program chain in driver mode immediately after reaching the network interface card. - The `l4drop` eBPF program applies mitigation rules generated by `dosd`, Cloudflare’s denial-of-service daemon. - Each server identifies heavy traffic sources and shares the information across its colocation facility. - Mitigation rules spread globally through Quicksilver, Cloudflare’s distributed key-value store. - Only legitimate traffic reaches Unimog, the Layer 4 load balancer; Magic Transit traffic receives additional stateful inspection through `flowtrackd`. - The 31.4 Tbps attack was stopped at line rate without centralized scrubbing or human intervention. - Sufficient physical port capacity remains essential: software defenses cannot work if the network cannot first absorb the traffic. ## A Developer Platform at the Edge - Because Cloudflare already runs software on every server for packet filtering, it extended the same infrastructure to customer code through Workers. - Workers, KV, and Durable Objects run across Cloudflare’s global footprint rather than in a small number of cloud regions. - Workers Containers, introduced in 2025, support heavier workloads at the edge. - V8 isolates and custom filesystem layers reduce cold-start times. - Applications run on the same servers that discard malicious traffic before it reaches the network stack. ## Securing Routing with RPKI and ASPA - Cloudflare uses IPv6 and RPKI to reduce the risk of BGP hijacks. - It signs Route Origin Authorizations and rejects routes that fail Route Origin Validation, even when misconfigured networks become temporarily unreachable. - ASPA will extend protection by validating the network path, not just the organization authorized to originate a prefix. - The post compares RPKI to checking a destination passport and ASPA to verifying the entire flight manifest. - Cloudflare says 867,000 prefixes now have valid RPKI certificates, compared with nearly none a decade ago. - The company promotes early adoption of routing security standards because delays leave the Internet exposed to hijacks and route leaks. ## AI Agents and Internet Traffic - AI crawlers, training systems, and autonomous agents now generate more than 4% of HTML requests on Cloudflare’s network. - Human-initiated “user action” crawling increased more than 15-fold in 2025. - Unlike browsers, crawlers may retrieve every linked resource at maximum speed, making legitimate activity difficult to distinguish from attacks. - Cloudflare uses verified bot IP ranges, TLS fingerprints, behavioral analysis, and robots.txt signals to classify AI crawlers. - These signals help site owners decide which automated agents to permit. Cloudflare’s central lesson is that a global network must combine abundant capacity with intelligence distributed across every server. Its continued investment in automated mitigation, edge execution, routing security, and traffic classification is intended to make the Internet faster, safer, and more resilient as traffic patterns evolve.

bgpcloudflaredistributed-systemsnetwork-security+4

cloudflareFeb 27, 2026

ASPA: making Internet routing more secure (opens in new tab)

ASPA (Autonomous System Provider Authorization) extends RPKI-based routing security from verifying a route’s destination to validating the path it takes. By publishing cryptographically signed lists of authorized providers, networks can detect BGP route leaks and some forged-origin hijacks. Cloudflare Radar now tracks ASPA adoption and records across the five Regional Internet Registries. ## From Origin Validation to Path Validation - RPKI uses Route Origin Authorizations (ROAs) to verify that an Autonomous System (AS) is authorized to announce specific IP prefixes. - ROAs protect against origin hijacks, where an attacker falsely claims ownership of someone else’s address space. - ASPA complements ROAs by validating the AS_PATH—the sequence of networks through which a route propagates. - Each AS publishes its authorized upstream providers, allowing other networks to check whether the observed path follows approved relationships. ## Detecting Route Leaks - Normal Internet routing generally follows a “valley-free” pattern: - Traffic moves upward from a customer through providers. - It may cross a peering connection near the top. - It then moves downward through providers toward the destination. - A route leak creates a “valley,” such as traffic traveling down to a customer and then back up to another provider. - ASPA evaluates the path from both directions: - The “up-ramp” is checked from the route origin toward its providers. - The “down-ramp” is checked backward from the destination. - A path is valid when both authorized chains meet. If they leave a gap, the route is considered ASPA Invalid, indicating a likely leak or unauthorized propagation. ## Example of ASPA Validation - In the example, AS65539 receives a route from customer AS65538. - AS65538 improperly propagates traffic received from provider AS65537 toward another provider, acting as a bridge between providers. - The upstream validation chain ends at AS65537, while the downstream chain ends at AS65538. - Because the two chains do not connect, ASPA identifies the route as invalid. ## Protection Against Forged-Origin Hijacks - ASPA can detect attacks in which the legitimate origin AS is retained but the attacker fabricates the path leading to it. - The victim’s signed provider list reveals that the attacker is not an authorized provider, allowing the route to be rejected. - ASPA is not universal protection: the article notes that a provider may still forge a path advertisement to its customer, a case the supplied text does not fully explain. ## Monitoring ASPA Adoption - Cloudflare Radar’s ASPA deployment monitoring feature shows adoption trends across all five RIRs. - It also lets users inspect ASPA records and changes for individual Autonomous Systems. ASPA provides an important second layer of routing security: ROAs verify where traffic should end, while ASPA helps verify how it gets there. Wider publication and validation of ASPA records should make route leaks and path manipulation easier to detect and prevent.

bgpnetwork-securityaspainternet-routing+3

cloudflareFeb 21, 2026

Cloudflare outage on February 20, 2026 (opens in new tab)

Cloudflare suffered a 6-hour, 7-minute outage on February 20, 2026, after a software change unintentionally withdrew Internet routes for some Bring Your Own IP (BYOIP) customers. The incident was not related to a cyberattack; a buggy automated cleanup task altered customer prefix and service configurations. Cloudflare reverted the change, restored affected prefixes, and is revising its Addressing API workflows to reduce production risk. ## Customer Impact - Approximately 1,100 of Cloudflare’s 6,500 advertised prefixes were withdrawn between 17:56 and 18:46 UTC. - This affected about 25% of the 4,306 BYOIP prefixes advertised globally. - Impacted applications became unreachable from the Internet and experienced connection failures and timeouts. - Customers initially encountered BGP Path Hunting, where networks repeatedly searched for a route until connections timed out. - The `one.one.one.one` website returned HTTP 403 errors and an “Edge IP Restricted” message. - DNS resolution through the 1.1.1.1 resolver, including DNS over HTTPS, was not affected. - The incident did not affect every BYOIP customer because the configuration change was applied incrementally and was reverted before reaching everyone. ## Recovery Efforts - Engineers detected the issue through failures involving `one.one.one.one` and reverted the change. - Cloudflare published dashboard guidance at 19:19 UTC, allowing many customers to re-advertise their prefixes themselves. - Around 800 prefixes were restored by approximately 20:20 UTC. - About 300 prefixes could not be restored through the dashboard because their service configurations had been removed from edge servers. - Engineers manually restored those remaining prefixes at 23:03 UTC. - Some customers continued to experience latency and failures while addressing configuration state propagated back to the edge. ## The Addressing API - Cloudflare’s Addressing API is the authoritative dataset for IP addresses present on its network. - Changes to the API drive workflows that propagate address and routing updates across Cloudflare’s edge. - The normal process is: - Customers request advertisement or withdrawal through the Addressing API or BGP Control. - The API instructs machines to change prefix advertisements. - Routers update BGP after enough machines receive the change. - Customers bind Cloudflare products to their BYOIP ranges. - Because the API is closely connected to production systems, manual changes are risky. - Cloudflare’s “Code Orange: Fail Small” initiative aims to replace manual Addressing API operations with safer, automated, health-checked workflows. ## Root Cause: Faulty BYOIP Cleanup Automation - The failed change automated the removal of prefixes from BYOIP, a task that had previously been performed manually. - A recurring cleanup sub-task searched for BYOIP prefixes marked for deletion and removed them. - The cleanup task issued the API request: ```go /v1/prefixes?pending_delete ``` - The request contained a bug in how the API query was interpreted. - As a result, the cleanup process unintentionally withdrew customer prefixes and removed related service configurations from some edge servers. - The incident lasted much longer than the initial withdrawal because restoring both advertisements and edge configuration state required extensive automated and manual recovery. Cloudflare’s main corrective direction is to make Addressing API changes safer through incremental, health-mediated deployment, stronger safeguards around automated deletion, and elimination of risky manual production workflows.

bgpgoapi-designdns+3

cloudflareJan 26, 2026

Cable cuts, storms, and DNS: a look at Internet disruptions in Q4 2025 (opens in new tab)

In Q4 2025, Internet disruptions were driven primarily by submarine cable cuts, power failures, extreme events, technical problems, and one government-directed shutdown. Tanzania experienced a prolonged election-related blackout, while damaged international cables disrupted connectivity in Haiti, Pakistan, Cameroon, and the Dominican Republic. Cloudflare’s analysis uses major deviations in network traffic and routing announcements to identify these incidents, though it is not exhaustive. ## Government-Directed Shutdown ### Tanzania - Internet traffic fell by more than 90% on October 29 during violent protests surrounding the presidential election. - The initial shutdown lasted about 26 hours, but a second near-total outage began shortly after service briefly returned. - Connectivity did not substantially recover until November 3. - Announced IPv4 and IPv6 address space declined slightly but never disappeared entirely, indicating that Tanzania was not completely disconnected from the global Internet. - Internet and social media restrictions had also occurred ahead of Tanzania’s 2020 elections. ## Submarine and Fiber Cable Cuts ### Digicel Haiti - Digicel Haiti suffered two international fiber cuts during the quarter. - On October 16, traffic fell to nearly zero; the provider reported two cuts and restored the first fiber within several hours. - On November 25, another cut along National Road 1 caused a complete outage lasting roughly six hours. - Service was restored after repairs to the international optical fiber infrastructure. ### Cybernet/StormFiber in Pakistan - Traffic dropped to about half its expected level on October 20, while announced IPv4 address space fell by more than one-third. - The cause was a cut to the PEACE submarine cable in the Red Sea near Sudan. - Pakistan has multiple international cable routes, including IMEWE and SEA-ME-WE-4, which helped enable rapid recovery. - Traffic and address announcements returned close to normal by October 21, ahead of the provider’s October 27 restoration target. ### Cameroon and the WACS Cable - Camtel, MTN Cameroon, and Orange Cameroun experienced major disruptions on October 23 because of an incident involving the West Africa Cable System (WACS). - Traffic initially fell around 05:00 local time and recovered by approximately 22:00, although it fluctuated dramatically and sometimes dropped by 90–99%. - MTN and Orange also saw reductions in announced IP address space, while Camtel’s announcements remained stable. - The volatility may have reflected attempts to reroute traffic over other submarine cables. - Connectivity in the Central African Republic and Republic of Congo was reportedly affected as well. ### Claro Dominicana - Claro Dominicana experienced two sharp traffic declines on December 9. - Traffic eventually fell 77% below the comparable level from the previous week. - The provider attributed the disruption to two severed fiber-optic cables, which caused intermittent service and slow speeds. - Technicians restored nationwide service after repairing the cables. ## Power-Related Disruption ### Dominican Republic - A transmission-line outage on November 11 caused a major national power interruption. - Internet traffic fell by nearly 50% compared with the previous week and remained depressed until December 12. - The electrical operator later reported that 96% of national demand had been restored. - A technical report traced the blackout to a manually disconnected live line at the 138 kV San Pedro de Macorís I substation. - The resulting short circuit triggered protection systems and disconnected nearby lines, separating 575 MW of generation. ## Overall Pattern - More than 180 Internet disruptions were observed globally during 2025. - Q4 included only one government-directed shutdown, but several international cable failures caused severe regional outages. - Traffic measurements and BGP address announcements helped distinguish partial connectivity loss from complete national disconnection. - The incidents demonstrate how dependent national networks remain on a limited number of submarine cables, fiber routes, and reliable electrical infrastructure. Cloudflare’s findings suggest that network operators should diversify international cable routes, improve redundancy, and prepare for power and infrastructure failures. The Cloudflare Radar Outage Center provides a broader list of verified anomalies and confirmed outages.

bgpdnsipv6internet-routing+4

cloudflareJan 23, 2026

Route leak incident on January 22, 2026 (opens in new tab)

On January 22, 2026, a routing-policy automation error caused Cloudflare to leak IPv6 BGP prefixes from its Miami data center. For 25 minutes, external traffic was redirected through Miami, congesting backbone links, increasing latency and packet loss, and causing some traffic to be dropped by firewall filters. The incident resulted from removing prefix-list constraints, leaving a Juniper policy that accepted and externally advertised unintended internal routes. ## What a BGP Route Leak Is - A route leak occurs when an autonomous system advertises routes it is not supposed to forward. - This violates valley-free routing principles, such as sending routes learned from a peer onward to another peer or provider. - The leaking network may lack the capacity or firewall rules to handle the redirected traffic. - Cloudflare’s incident involved a mixture of Type 3 and Type 4 route leaks under RFC 7908. ## Incident Impact and Timeline - The triggering automation change was merged at **19:52 UTC**. - At **20:25 UTC**, it ran on a single Miami edge router and caused unexpected advertisements to peers and transit providers. - The network team began investigating at **20:40 UTC** and formally coordinated the incident at **20:44 UTC**. - At **20:50 UTC**, an operator reverted the bad configuration and paused automation on the router. - The leak lasted approximately **25 minutes**, causing: - Congestion on Miami backbone infrastructure - Increased packet loss and latency for some Cloudflare customers - Traffic from unrelated external networks to be funneled through Miami - Packet drops from firewalls configured to accept only Cloudflare-related traffic - The triggering code change was reverted at **21:47 UTC**, and automation was later verified and resumed. ## The Configuration Error - Cloudflare intentionally removed Miami advertisements for a Bogotá data center after infrastructure changes made the Miami-to-Bogotá forwarding path unnecessary. - The change removed `6-BOG04-SITE-LOCAL` prefix-list conditions from multiple export policies. - Those prefix lists had constrained policies to specific Bogotá prefixes. - Once removed, policies such as `6-TELIA-ACCEPT-EXPORT` still matched routes with `route-type internal` and accepted them for export. - On Juniper JunOS and JunOS EVO, `route-type internal` matches any non-external route, including Internal BGP (IBGP) routes. - Consequently, routes that should have remained internal were treated as exportable and advertised to external peers and providers. - The problem affected IPv6 traffic only. ## Response and Remediation - Operators manually reverted the generated router configuration. - Automation was paused on the affected Miami router to prevent the faulty policy from being reapplied. - The source-code change was reverted, and the router was checked before automation resumed. Cloudflare’s incident demonstrates that removing seemingly obsolete route filters can unintentionally broaden a policy. Export policies should explicitly constrain acceptable prefixes and include validation or safeguards that prevent internal routes from being advertised externally.

bgpnetworkingipv6route-leak+2

cloudflareJan 13, 2026

What we know about Iran’s Internet shutdown (opens in new tab)

Iran’s government effectively disconnected the country from the global Internet on January 8, 2026, amid escalating nationwide protests. Cloudflare observed a near-total loss of traffic after major Iranian networks withdrew most announced IPv6 address space and then lost connectivity almost entirely. Brief access windows on January 9 quickly ended, and the shutdown remained in place through January 10. ## Background and Earlier Shutdowns - Iran has previously restricted Internet access during protests: - More than five days of disruption followed fuel-price protests in November 2019. - Connectivity was disrupted across multiple providers during protests after Mahsa/Zhina Amini’s death in September 2022. - Internet traffic had already been below normal at the beginning of 2026, suggesting connectivity problems preceded the complete shutdown. ## Connectivity Collapsed on January 8 - At 11:50 UTC, Iranian networks reduced announced IPv6 address space by 98.5%, from over 48 million `/48` blocks to roughly 737,000. - This caused IPv6’s share of human-generated traffic to fall from about 12% to 2%, before IPv6 traffic nearly disappeared later that afternoon. - Between 16:30 and 17:00 UTC, overall traffic dropped by nearly 90%. - Major providers affected included: - MCCI (AS197207) - IranCell (AS44244) - TCI (AS58224) - By approximately 18:45 UTC, traffic from Iran had fallen effectively to zero, indicating a nationwide disconnection from the global Internet. ## Brief Connectivity on January 9 - Internal traffic remained below 0.01% of pre-shutdown peaks. - Access to Cloudflare’s `1.1.1.1` DNS resolver briefly returned around 10:00 UTC, producing a short-lived spike in requests. - Several universities also regained connectivity temporarily, including the University of Tehran, Sharif University of Technology, Tehran University of Medical Science, and Tarbiat Modares University. - Traffic from these networks disappeared again by roughly 15:00 UTC. ## Filtering Changes Before the Shutdown - HTTP/3 and QUIC usage declined sharply before the full outage. - On IranCell, HTTP/3 usage fell from as high as 40% to 5% by December 31 and continued declining. - On TCI, HTTP/3 dropped below 5% around January 3. - These changes may indicate increasingly severe filtering and upgraded whitelisting, according to MahsaNet. ## Ongoing Disconnection - Since January 10, Iran’s Internet traffic has shown no significant recovery. - Traffic remains at only a fraction of one percent of previous levels. - Cloudflare continues monitoring the situation through Radar’s traffic and routing data. The available measurements strongly indicate a deliberate, nationwide Internet shutdown rather than an ordinary network failure. Cloudflare Radar’s traffic and routing pages provide the most practical way to follow any restoration or further changes.

bgpdnsipv6quic+4

cloudflareJan 6, 2026

A closer look at a BGP anomaly in Venezuela (opens in new tab)

The post examines a January 2 BGP anomaly involving Venezuela’s CANTV network (AS8048). Although the event prompted speculation about government-directed surveillance, the broader pattern—eleven leaks since December—more strongly suggests inadequate BGP import and export filtering. The affected routes, provider-customer relationships, and heavy AS-path prepending are consistent with a configuration or operational error rather than clear malicious activity. ## Background: How BGP Route Leaks Work - BGP directs traffic between autonomous systems (ASes) according to business relationships: - **Customer-provider:** Providers advertise broad Internet routes to customers; customers advertise their own and downstream routes. - **Peer-peer:** Networks exchange their own and customer routes without payment. - These rules produce “valley-free” paths, where traffic generally moves from customers toward providers and then back down toward customers. - A **route leak**, formally defined in RFC 7908, occurs when routing announcements are propagated beyond their intended scope. - A typical leak happens when a customer receives routes from one provider and incorrectly advertises them to another provider, causing traffic to take an inefficient or overloaded path. ## The AS8048 Route Leak - Cloudflare Radar identified AS8048, operated by Venezuelan ISP CANTV, as the leaking network. - CANTV learned routes from AS6762, Italian telecom Sparkle, and redistributed them to AS52320, Colombia’s V.tal GlobeNet. - The leaked prefixes were originated by AS21980, Dayco Telecom, and belonged to the same `200.74.224.0/20` subnet. - Since AS8048 appears to be a provider for AS21980, the leak may reflect incorrect route export policies involving a customer’s prefixes. - The post emphasizes that route leaks are common and are usually caused by mistakes or weak routing controls rather than deliberate attacks. ## Evidence from Routing Relationships - Cloudflare Radar, bgp.tools, and BGPKIT data all indicate a provider-customer relationship between AS8048 and AS21980. - BGPKIT’s relationship analysis showed: - AS8048 was identified as the upstream provider in 9.4% of observations. - AS21980 was almost never identified as upstream. - Although only 9.9% of route collectors saw the two ASes as directly adjacent, the available paths strongly supported AS8048 being AS21980’s provider. ## Significance of AS-Path Prepending - Many leaked routes included repeated instances of AS8048 in their paths. - AS-path prepending is normally used to make a route less attractive and shift traffic away from a particular connection. - A path such as `52320,8048,8048,8048,...,21980` does not mean traffic physically traversed AS8048 repeatedly; the repeated entries are routing-policy padding. - The heavy prepending would have made the leaked routes less preferred, which weakens the case that AS8048 was intentionally trying to attract large volumes of traffic for interception. - The available evidence therefore points more toward poor routing configuration or operational practice than a purposeful man-in-the-middle operation. CANTV’s repeated route leaks and apparent lack of effective routing policies should still be treated as a serious reliability and security concern. However, the post’s evidence supports interpreting this incident as an example of recurring BGP misconfiguration unless further data demonstrates intentional manipulation.

bgpcloudflare-radarautonomous-systemsinternet-routing+4