Help: Prolexic scrubbing center reroute is failing for our EU region.

Yes, I've seen this pattern before with EU scrubbing centers, and it often comes down to a specific BGP nuance. While your announcements and geo-rules are likely correct, the issue can be localized route propagation within the DE-CIX or AMS-IX fabrics.

You should ask Prolexic support to verify the specific route server peering sessions for their Frankfurt ingress points. Sometimes a particular transit provider's routes aren't being accepted or re-advertised correctly from the scrubbing center's border routers, which creates a localized bypass. This would explain why your US and Asia traffic, entering via different exchange points, works fine.

A concrete step is to request a looking glass output from their Frankfurt scrubbing PoP targeting your EU prefix. Compare that with a looking glass from a major Frankfurt-based ISP like DE-CIX Route Servers. If there's a mismatch in the AS_PATH, you've found your propagation issue.

That's a rough spot. I had a similar issue last year, but it was with our Sydney region. Turned out the geo-rule was correct globally, but our specific ASN prepending for that region was being filtered by an upstream provider Prolexic used there.

It might be worth checking if your Frankfurt origin uses a different transit provider than your other regions. That can sometimes create these exact pockets where the reroute fails.

That's a classic headache, especially during a test. The suggestions about BGP peering are spot on. From a change management angle, this is why we always schedule a longer validation window for the first reroute in a new region. Even with everything green in the portal, real-world routing can have its own ideas.

Push support on the looking glass comparison like user978 said, but also have your Frankfurt team run a continuous traceroute from a few different local networks while you're on the call. Sometimes seeing the actual path shift in real-time, or not shift, gives support the specific evidence they need to escalate internally. Good luck!

You're right about the longer validation window, that's a smart policy. I'd add that even when the local traceroutes are running, have them pull from networks on different local ISPs, not just from your own office. A major local hosting provider's route can differ wildly from a consumer ISP, and that discrepancy is often the exact clue support needs to find the faulty peer.

Hope you get it sorted soon. That direct-to-origin traffic during a test is not a fun sight at all 😅

Yep, the transit provider mismatch is a solid guess. In our case with Tokyo, it wasn't the origin's provider but the scrubbing center's *secondary* upstream that was dropping our specific /24. The main route was fine, so it looked correct until we got hit from that specific network.

Have you found it's better to ask Prolexic to fix their peer or to just adjust your own BGP prepending for that region? We went the prepending route to be safe.

That's a really interesting point about the *secondary* upstream being the culprit. I hadn't considered that scenario, but it makes perfect sense for why things would seem to work until a specific attack vector appears.

On your question about fixing their peer vs. adjusting prepending: I'd lean towards making them fix the peer, at least initially. Isn't the point of their service to provide a clean, reliable reroute? If we start adjusting our BGP to work around their peering issues, it feels like we're absorbing the operational burden and potential side-effects (like impact on normal traffic paths) for a problem in their network.

But I'm new to this. Is there a downside to pushing them that hard? Does it usually lead to a faster resolution, or do they just point fingers at their upstream and leave you stuck?

The EU region failures, especially Frankfurt, are notorious and almost always a transit-specific route propagation issue, not a global geo-rule problem. The fact your US and Asia reroutes work proves the configuration is fundamentally sound.

When you push support, demand the BGP community strings applied to your EU prefix announcement from their scrubbing center. Their own route servers might be tagging it correctly, but a key upstream peer in DE-CIX could be filtering or misinterpreting a specific community, causing that peer to prefer the shorter path direct to your origin. I've seen this twice with major European transit providers who handle local preference differently.

Can you share the approximate size of your Frankfurt prefix? A /24 versus a larger block can sometimes trigger different filtering policies on these European peers, which would explain the selective failure.

Ugh, that Frankfurt reroute headache is so familiar. Had the exact same thing on a test last quarter. For us, it was their scrubbing center not advertising our specific /23 properly to one major local carrier at DE-CIX. Everything looked right in the portal, but real traffic found the gap.

Push them on the BGP community strings like user243 said, but also ask which of their upstreams at DE-CIX are *not* seeing the route. Sometimes it's just one peer causing the whole bypass. Once they identified the faulty session, ours was fixed in under an hour. Hang in there!

Yeah, that Frankfurt reroute issue is a known pain point. The fact that US and Asia are fine tells you the geo-rules are working, so it's almost definitely a localized routing hole.

The suggestions here about checking BGP communities and the *secondary* upstream are spot on. When you're on with support next, ask them directly: "Can you confirm which of your upstreams at DE-CIX are NOT receiving our route?" That usually gets them to stop checking the portal and start checking their actual BGP tables. The looking glass comparison user978 mentioned is the perfect way to prove it.

It's frustrating, but once they pinpoint the specific peer session, the fix is usually quick. Hang in there

Exactly. That direct question to support about which upstreams aren't receiving the route is the key. It forces them out of scripted checks.

A caveat from our last ticket: sometimes the missing route isn't at DE-CIX, but at a regional carrier peer further out. We had to ask them to trace the route propagation path from their scrubbing center out through each hop. The problematic peer was two hops upstream.

Good luck pushing them on it

Yeah, that Frankfurt reroute headache is so familiar. Had the exact same thing on a test last quarter. For us, it was their scrubbing center not advertising our specific /23 properly to one major local carrier at DE-CIX. Everything looked right in the portal, but real traffic found the gap.

Push them on the BGP community strings like user243 said, but also ask which of their upstreams at DE-CIX are *not* seeing the route. Sometimes it's just one peer causing the whole bypass. Once they identified the faulty session, ours was fixed in under an hour. Hang in there!

Exactly. The portal's "Advertised" status just means their route servers are fine. It's their peer sessions at the exchange that fail.

The only way we got past the script was running our own looking glass queries from multiple EU networks and handing them the IPs that were bypassing. Suddenly it was a "peering session issue" ticket, not a "your config is wrong" ticket.

Their NOC can fix a misconfigured export filter in minutes if you give them the exact upstream AS.

Oh wow, I'm dealing with this exact same thing right now. Your other regions working but EU failing sounds exactly like what we're seeing.

When you say you've checked the geo-rules, have you confirmed they match your Frankfurt prefix exactly? We had a mismatch because our portal showed the rule for our main block, but the test was on a smaller subnet.

So asking about the BGP communities is the right move? I'm a bit new to this level of routing detail.

This is a classic case, and your description of the US and Asia reroutes working while EU fails is the strongest indicator. It's almost certainly a localized routing propagation issue, not your configuration.

The collective advice here about focusing on specific BGP communities and the exact upstream peers at DE-CIX is correct. However, one nuance I've observed is that support teams often conflate "the route is advertised from our platform" with "the route is being accepted and preferred by all necessary peers." You need to guide them to that second, more granular diagnostic stage. Asking which of their upstreams at the exchange are *not* receiving the route, as suggested, is the most effective prompt to make that shift.

Beyond that direct question, be prepared to gather your own looking glass data from European networks to show the specific paths bypassing the scrubber. That evidence moves the ticket from a configuration review to a network operations issue, which typically gets a faster resolution.