Signal the attacked host or subnet with a standard BGP community and let TurkIX enforce the drop inside the exchange.
BGP Blackholing
Fast DDoS containment over public peering
BGP Blackholing
TurkIX BGP Blackholing gives public peering participants a fast way to signal attacked prefixes over their existing route server sessions and have matching traffic discarded inside the TurkIX fabric. It is designed for live DDoS response, keeping mitigation targeted to the affected destination while preserving capacity for the rest of the network.
65535:666
required BGP community
/25 - /32
accepted IPv4 prefixes
/49 - /128
accepted IPv6 prefixes
Operational outcome
Contain attacked destinations without disrupting healthy services
When a member announces a qualifying blackhole prefix, TurkIX drops matching packets on egress toward that member's port(s). The control stays local to the requesting member and does not alter traffic handling for other participants.
- Uses existing TurkIX route server sessions
- One route server announcement is sufficient
- Applies only to public peering traffic
- Blackhole routes are not redistributed to other members
The blackhole applies only to the attacked destination and only for the member requesting protection, helping preserve unaffected services.
Because the routes are not redistributed, other members do not receive extra blackhole prefixes or unexpected routing changes.
A direct control plane for urgent traffic suppression
Members announce the attacked host or subnet as a more-specific prefix tagged with the TurkIX blackhole community. If the prefix length matches policy, TurkIX suppresses matching traffic inside the exchange before it reaches the congested member-facing edge.
- Supports IPv4 and IPv6 more-specific announcements within policy
- Mitigation still works even when traffic sources peer bilaterally rather than through route servers
- Helps relieve overload during large-scale DDoS events
Built to protect other members from accidental impact
- TurkIX applies the drop outbound only to the port(s) of the member that sent the announcement.
- A mistaken but syntactically valid announcement cannot blackhole traffic for another member.
- Because blackhole routes are not redistributed, other members' prefix-length filters do not affect the feature.
- P2P Private VLANs and other TurkIX services continue to operate normally.
Required community and accepted prefix lengths
To activate BGP Blackholing, tag the attacked prefix with the TurkIX blackhole community and announce it through an existing route server session. Announcements outside the accepted ranges are ignored.
BGP community
65535:666
IPv4 policy
/25 to /32
Use the narrowest attacked host or subnet that fits inside the accepted IPv4 more-specific range.
IPv6 policy
/49 to /128
Announce the impacted IPv6 destination within the allowed range for blackhole signaling.
A single announcement to either TurkIX route server is enough for activation.
Practical guidance for safe day-to-day use
The route servers treat blackhole announcements like standard routes, so the same operational discipline still matters.
Prefer the smallest attacked host or subnet allowed by policy so healthy prefixes remain reachable.
If the announcement does not satisfy the accepted community or prefix-length policy, TurkIX will not activate the blackhole.
A high number of active blackhole routes is discouraged because they count toward route server max-prefix limits and can drop sessions if abused.
The feature affects only public peering traffic and does not change forwarding for private interconnect services.
Blackholing is applied inside the TurkIX public peering environment and is not intended to interfere with private service delivery.
Other members do not receive blackhole announcements, which keeps their routing tables unchanged and avoids extra prefix pressure.
The drop is enforced toward the announcing member's port(s), keeping the action isolated even if a request is made in error.
Operators can activate the signal during an event and withdraw it when the attack subsides, using their existing BGP operations model.
A clean operator runbook for live incidents
A typical BGP Blackholing workflow at TurkIX follows a short, predictable sequence during an attack event.
Confirm the impacted host or subnet and choose the narrowest more-specific prefix allowed by policy.
Tag the selected prefix with community 65535:666 and announce it to an existing TurkIX route server session.
Matching packets are discarded inside the exchange fabric before they continue toward the affected member-facing edge.
Remove the announcement after the event so normal traffic to the destination resumes through the standard routing path.
Next step
Plan your TurkIX blackholing workflow before the next incident
If your network plans to use BGP Blackholing, our team can help you validate prerequisites, align route server policy, and prepare an incident response workflow that is ready when needed.
Copyright © 2026 TurkIX Communications Ltd