Packet-Level Visibility for Magic Transit and BYOIP

Cloudflare’s analytics platform has grown steadily since the launch of Firewall Analytics in 2019. Initially focused on HTTP security events for Enterprise customers, the platform was later expanded to Business and Pro plans and extended to services like DNS, Load Balancing, and Account Analytics. All of these dashboards are built on a GraphQL framework that customers can use to create custom reports and dashboards.

Until recently, however, all of those dashboards provided visibility into Layer 7 attributes: user agents, hosts, cached resources, and similar HTTP traffic characteristics. That works well for customers whose traffic is proxied at the application layer. But Magic Transit takes a different path—it routes traffic at Layer 3 over BGP Anycast. Traffic arrives at the closest Cloudflare point of presence, is filtered by customer-defined network firewall rules and automatic DDoS mitigation systems, and then clean traffic is forwarded to customer data centers via GRE Anycast tunnels.

Because that architecture operates at the packet layer, higher-layer HTTP visibility simply isn't available. To give Magic Transit and Bring Your Own IP (BYOIP) customers insight into what's happening with their traffic and attacks, Cloudflare needed to extend its analytics platform down to Layer 3.

What Network Analytics Shows

Released on January 16, 2020, the Network Analytics dashboard provides near real-time visibility into network- and transport-layer traffic patterns and DDoS attacks blocked at the Cloudflare edge across more than 200 cities. The dashboard is packet- and bit-oriented, with views covering:

  • Packet and bit rates over time
  • Traffic distribution by source and destination IP, port, and protocol
  • TCP flag distributions, which can reveal anomalous patterns indicating an attack
  • A configurable activity log showing dropped or rate-limited traffic with attack attributes

One Year of Historical Data

The underlying data architecture supports up to a year of historical insight. Traffic is sampled at edge data centers and turned into IP flow logs—similar to SFlow—with one-minute buckets grouped by destination IP, port, and protocol. Those flow records include attributes such as TCP flags, source IPs and ports, and the Cloudflare data center where traffic was ingested.

Source IP addresses are treated as PII, so they're retained for just 30 days. After that, the flow logs are rolled up into one-hour groups, then one-day groups. The hourly rollups are stored for six months; daily rollups are kept for a full year.

Attack data is stored as summaries with start and end timestamps, min/max/average/total bits and packets per second, attack type, and action taken. Since a single DDoS attack can involve billions of packets, summary storage keeps read and write loads manageable and preserves attack logs for up to one year.

GraphQL Access

Network Analytics is exposed through the same GraphQL API used elsewhere in the platform. For example, an attack report query can return top attacker IPs, the Cloudflare data centers and countries where the attack was observed, IP version distribution, attacker ASNs, and ports. The query operates at the account level, so it reports across all of your IP ranges unless you filter by a specific destination IP or port range—the same filters available in the UI.

Designing From Customer Workflows

Cloudflare's product definition process started with internal, customer-facing teams—Support, Solution Engineering, and others—followed by direct conversations with network and security engineers and leaders. Those discussions surfaced two dominant use cases: incident response and reporting.

Incident Response

The core question was simple: what do you do when you're paged? For a security operations engineer monitoring traffic on Black Friday, the goal is quick resolution: determine whether the traffic spike is legitimate or an attack, whether it's been mitigated, and whether action like shifting traffic to another data center is required. Customers identified these metrics as most valuable:

  1. Top destination IP and port—what services are being impacted
  2. Top source IPs, ports, ASNs, and data centers—where traffic originates
  3. Real-time packet and bit rates—current traffic levels
  4. Protocol distribution—what type of traffic is abnormal
  5. TCP flag distribution—anomalies here could indicate an attack
  6. Attack log—what traffic is being dropped or rate-limited

Because network- and transport-layer attacks are often highly distributed with spoofed packet attributes, blocking individual IPs is rarely practical. Instead, the dashboard is designed to reveal patterns—an abnormal frequency of a specific TCP flag, or a surge in traffic from one country. Once identified, packet-level filtering can drop or rate-limit the malicious traffic. If Cloudflare's automated systems already mitigated the attack, that appears in the activity log along with the attack attributes; filtering by the attack ID turns the entire dashboard into an attack report.

Reporting

Security teams can spend over a third of their time—roughly three hours per day—processing data and generating reports for managers, leadership, and law enforcement. Reporting is also one of the most frequent DDoS-related requests Cloudflare receives from customers. The dashboard supports this with customizable filters, time range selection, and print or share options.

A dynamic summary line reflects your recent activity at a glance: whether there's an active attack and how many attacks have been blocked. It changes based on your traffic, giving security leaders a single line they can copy into an update to a CISO.

Customers say their reports are meant to demonstrate the value of the service: how much potential downtime and bandwidth Cloudflare saved, which IPs and ports were most attacked, and where attacks came from with trends over time.

One notable design decision concerns geographic maps. Source IPs can be trivially spoofed, so plotting packet distribution by source location would produce misleading data. Instead, the map shows geographic distribution based on the Cloudflare data center where the traffic was ingested—a more accurate representation given the network's footprint of over 200 cities.

The dashboard is currently available to existing Magic Transit and BYOIP customers. As with the rest of Cloudflare's analytics offerings, the intent is to streamline the investigation and reporting process rather than add another source of raw data to sort through.