For customers who understand their own network traffic patterns, rigid DDoS protection can be more of a limitation than a safeguard. That’s why Gcore supports BGP Flowspec: a flexible, standards-based method for defining granular filters that block or rate-limit malicious traffic in real time…before it reaches your infrastructure.
In this article, we’ll walk through:
- What Flowspec is and how it works
- The specific filters and actions Gcore supports
- Common use cases, with example rule definitions
- How to activate and monitor Flowspec in your environment
What is the BGP Flowspec?
BGP Flowspec (RFC 8955) extends Border Gateway Protocol to distribute traffic filtering rules alongside routing updates. Instead of static ACLs or reactive blackholing, Flowspec enables near-instantaneous propagation of mitigation rules across networks.
BGP tells routers how to reach IP prefixes across the internet. With Flowspec, those same BGP announcements can now carry rules, not just routes. Each rule describes a pattern of traffic (e.g., TCP SYN packets >1000 bytes from a specific subnet) and what action to take (drop, rate-limit, mark, or redirect).
What are the benefits of the BGP Flowspec?
Most traditional DDoS protection services react to threats after they start, whether by blackholing traffic to a target IP, redirecting flows to a scrubbing center, or applying rigid, static filters. These approaches can block legitimate traffic, introduce latency, or be too slow to respond to fast-evolving attacks.
Flowspec offers a more flexible alternative.
- Proactive mitigation: Instead of waiting for attacks, you can define known-bad traffic patterns ahead of time and block them instantly. Flowspec lets experienced operators prevent incidents before they start.
- Granular filtering: You’re not limited to blocking by IP or port. With Flowspec, you can match on packet size, TCP flags, ICMP codes, and more, enabling fine-tuned control that traditional ACLs or RTBH don’t support.
- Edge offloading: Filtering happens directly on Gcore’s routers, offloading your infrastructure and avoiding scrubbing latency.
- Real-time updates: Changes to rules are distributed across the network via BGP and take effect immediately, faster than manual intervention or standard blackholing.
You still have the option to block traffic during an active attack, but with Flowspec, you gain the flexibility to protect services with minimal disruption and greater precision than conventional tools allow.
Which parts of the Flowspec does Gcore implement?
Gcore supports twelve filter types and four actions of the Flowspec.
Supported filter types
Gcore supports all 12 standard Flowspec match components.
Filter Field | Description |
---|---|
Destination prefix | Target subnet (usually your service or app) |
Source prefix | Source of traffic (e.g., attacker IP range) |
IP protocol | TCP, UDP, ICMP, etc. |
Port / Source port | Match specific client or server ports |
Destination port | Match destination-side service ports |
ICMP type/code | Filter echo requests, errors, etc. |
TCP flags | Filter packets by SYN, ACK, RST, FIN, combinations |
Packet length | Filter based on payload size |
DSCP | Quality of service code point |
Fragment | Match on packet fragmentation characteristics |
Supported actions
Gcore DDoS Protection supports the following Flowspec actions, which can be triggered when traffic matches a specific filter:
Action | Description |
---|---|
Traffic-rate (0x8006) | Throttle/rate limit traffic by byte-per-second rate |
redirect | Redirect traffic to alternate location (e.g., scrubbing) |
traffic-marking | Apply DSCP marks for downstream classification |
no-action (drop) | Drop packets (rate-limit 0) |
Rule ordering
RFC 5575 defines the implicit order of Flowspec rules. The crucial point is that more specific announcements take preference, not the order in which the rules are propagated.
Gcore also respects Flowspec rule ordering per RFC 5575. More specific filters override broader ones. Future support for Flowspec v2 (with explicit ordering) is under consideration, pending vendor adoption.
Blackholing and extended blackholing (eBH)
Remote-triggered blackhole (RTBH) is a standardized protection method that the client manages via BGP by analyzing traffic, identifying the direction of the attack (i.e., the destination IP address). This method protects against volumetric attacks.
Customers using Gcore IP Transit can trigger immediate blackholing for attacked prefixes via BGP, using the well-known blackhole community tag 65000:666. All traffic to that destination IP is dropped at Gcore’s edge.
The list of supported BGP communities is available here.
BGP extended blackhole
Extended blackhole (eBH) allows for more granular blackholing that does not affect legitimate traffic. For customers unable to implement Flowspec directly, Gcore supports eBH. You announce target prefixes with pre-agreed BGP communities, and Gcore translates them into Flowspec mitigations.
To configure this option, contact our NOC at noc@gcore.lu.
Monitoring and limitations
Gcore can support several logging transports, including mail and Slack.
If the number of Flowspec prefixes exceeds the configured limit, Gcore DDoS Protection stops accepting new announcements, but BGP sessions and existing prefixes will stay active. Gcore will receive a notification that you reached the limit.
How to activate
Activation takes just two steps:
- Define rules on your edge router using Flowspec NLRI format
- Announce rules via BGP to Gcore’s intermediate control plane
Then, Gcore validates and propagates the filters to border routers. Filters are installed on edge devices and take effect immediately.
If attack patterns are unknown, you’ll first need to detect anomalies using your existing monitoring stack, then define the appropriate Flowspec rules.
Need help activating Flowspec? Get in touch via our 24/7 support channels and our experts will be glad to assist.
Related articles
Subscribe to our newsletter
Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.