You're absolutely right about intentional filtering being the cause, and it's often more insidious than a session down. I've seen this exact /22 policy from a major German carrier at DE-CIX that wasn't documented in the scrubbing provider's general peering policy. They'd accept the advertisement from Prolexic's route server but then apply their own ingress filter, dropping anything more specific before it propagated to their downstream customers.
> verify their peering agreements at DE-CIX
This is the key escalation. When you phrase it this way, you're asking them to check a business relationship, not just a technical config. Their peering team will have a matrix of exactly what each bilateral peer accepts. If they come back and say "our agreement with AS##### has a max-prefix of /22," then you've found your answer and the fix is either a prefix aggregation on their side or a renegotiation.
Mike
Wow, so the problem could be on the *other* network's side, not even Prolexic's? That's a new angle I hadn't considered.
So even if Prolexic says everything's fine on their end, a peer could just be silently filtering our prefix. That feels like a much harder thing to get them to acknowledge.
When you ask them to verify peering agreements, how do they usually react? Is that something their support can actually answer, or does it always require a huge escalation?
Frankfurt is a known trouble spot for exactly this. Your US/Asia success confirms the portal config is fine, so it's 100% a routing issue at DE-CIX.
Stop checking the portal. Get a looking glass from an EU network, like an ISP in Germany or NL. That'll show you which upstreams are *not* accepting the prefix. Then push support with the specific peer AS numbers that are failing.
If they say "it's advertised," ask them to verify the BGP session state for each individual DE-CIX peer, not just their route servers. One faulty session with a cheap transit provider is all it takes.
Benchmarks don't lie.
That under-an-hour fix is the outlier, not the rule. In my experience, getting them to even look at individual session logs requires jumping through three tiers of support and threatening to involve your account manager.
The bigger issue is that a single faulty session with a "major local carrier" shouldn't be able to break your regional DDoS protection. It points to a fragile, undersized peering fabric at that scrubbing center. Relying on every single peer to accept your prefix for the service to work is a design flaw.
-- bb
Frankfurt is notoriously tricky for this exact scenario. Since US and Asia are working, your portal config is definitely correct. It's almost certainly a routing acceptance issue at DE-CIX, like others said.
Push support hard on their individual BGP session states with Frankfurt peers, not just the route server. In my last gig, we had the same thing, and it was one cheap transit provider silently filtering the /24. A looking glass from a German VPS provider gave us the AS number we needed to shove at them.
Once you have that specific peer, they usually fix it pretty fast. Good luck, it's frustrating.
—b
Ugh, Frankfurt. You've got all my sympathy.
Everyone's spot on about the looking glass and checking specific peer sessions. One thing I'd add from our own headache last year - after you get that looking glass data, check if the traffic bypassing you is coming from a mobile carrier network specifically. We found one German mobile ISP was the sole source of our "leaked" traffic, because they bought transit from the exact budget provider that was filtering our prefix.
It turned the support ticket from "why isn't this working?" to "why is Peer AS##### at DE-CIX filtering our /24?". That got it escalated to their peering team within hours.
That's a smart addition, focusing on the source of the leaked traffic. Finding it's all from, say, Vodafone mobile users quickly turns a vague routing problem into a clear peering issue with a specific network.
One caveat, though: sometimes support will try to dismiss a mobile carrier as an 'edge case' or 'end user network.' It's important to frame it as a problem with *their peer* that carries that mobile traffic, not the mobile network itself. That's what gets the peering team's attention.
Keep it civil, keep it real