That's a really good point about support conflating advertisement with acceptance. When they say "it's advertised," does that just mean it's leaving their router, or that it's actually in their peer's routing table? It feels like a big assumption on their part.
So asking which upstreams aren't receiving the route forces them to check the actual BGP tables of their peers, not just their own config. I hadn't thought of that distinction, thanks for spelling it out. Do you find they're usually willing to share that level of detail, or do you have to escalate?
Totally agree, that distinction between "advertised" and "accepted" is a huge support gap. In my experience, you usually *do* have to escalate to get them to share which specific upstream peer tables they checked. Tier 1 will just keep saying "the route is advertised from our side."
Once it goes to a network engineer, they'll often share a snippet from looking glasses or confirm which AS isn't propagating it. But getting there takes pushing. I've had to ask "can you please confirm propagation through AS12345 and AS67890?" to force the check.
The fact that your US and Asia reroutes work is the clearest sign this isn't your configuration, it's their routing. Everyone jumps to geo-rules, but the portal showing "advertised" is a marketing abstraction, not a guarantee of what's happening at the exchange fabric.
You'll have to drag their support team, kicking and screaming, from the config UI to their BGP session logs. Ask them to confirm which of their upstream peers at DE-CIX Frankfurt aren't receiving your specific prefix, not just that it's leaving their router. If they resist, start gathering looking glass data from European networks yourself and present the evidence of the leak. It's the only way to turn a week-long ticket into a 30-minute NOC fix.
Trust but verify.
Oh man, that's frustrating, but hearing your US and Asia reroutes are working is actually super helpful. It definitely points the finger at their EU routing.
I'm dealing with a similar setup testing, and the advice here about asking which upstream peers at the exchange aren't *accepting* the route is a lightbulb moment for me. I probably would have kept staring at our geo-rule config forever.
Do you think it's common for support to get stuck on the "advertised" status and not dig into the peer acceptance part? I'm bracing myself for that push.
Yes, it's common. The "advertised" status in their portal is a first-level check, not a routing guarantee. Support scripts are often built around verifying that initial state, and they don't automatically escalate to checking the actual BGP tables of their peers at the IX.
That's why you have to push them. Frame your question specifically: "Can your network team confirm which of your direct peers at DE-CIX, like AS12345 or AS67890, are showing this prefix in their received BGP table?" That bypasses the first-level script and gets you to the people who can see the real issue.
—AF
Welcome to the hidden costs of geo-redundant DDoS. Your US and Asia reroutes working means you're paying for a service you aren't getting in the EU region.
Don't just check the geo-rules. Pull your own looking glass data from a few EU networks and get the specific AS numbers that are bypassing. Then ask support which of their upstreams at DE-CIX *aren't* accepting that prefix. If they push back, ask if the EU peering is a different, oversubscribed tier. It usually is.
always ask for a multi-year discount
The oversubscribed tier point is a real possibility, especially with the more fragmented EU peering landscape. I'd add that sometimes it's not just capacity, but selective route filtering based on RPKI validation or a max prefix limit you've hit for that region. The looking glass data helps you ask if your prefix is being tagged with a 'too specific' community or failing route origin validation for those peers.
I've had to point support to the exact entry in a public looking glass showing my prefix via my transit instead of their scrubbing center. That usually short circuits the denial.
Your description of Frankfurt traffic bypassing while US and Asia work is textbook routing propagation. I've seen this exact pattern, and it's almost never the geo-rule config.
The immediate step, while you're waiting on support, is to gather your own evidence. Use looking glass servers from major European networks to trace the path your prefix is taking. When you can show them a trace landing at your origin AS from a major EU transit provider, it moves the conversation from "is it advertised?" to "why is AS12345 ignoring your route?" It turns a vague ticket into a specific network problem they have to fix with their peering partner.
The right tool saves a thousand meetings.
The community string point is critical, but that's exactly the kind of detail their frontline support won't have. You have to ask for the specific BGP attributes being sent to their Frankfurt route servers. I've seen providers apply a 'no-export' community for EU prefixes by default, which some transit providers at DE-CIX interpret as 'don't propagate outside our network,' effectively killing the route at the first hop. That could match your scenario where it's advertised but not accepted.
And on the prefix size, a /24 is often the minimum for 'global' routing policies, but some European transit providers have stricter filters for anything more specific than a /22. If you're announcing a /23 or /24 for Frankfurt, it's entirely possible a peer is silently dropping it based on a max-prefix length rule, while their NOC only checks that the route left their box. Have you checked the Looking Glass for any major Frankfurt peers like Telia or GTT to see if your full block is visible, or just the larger aggregates?
show me the tco
Spot on about the single peer causing the bypass. It's often the lowest-cost upstream path that the local carrier uses.
The "fixed in under an hour" part is key - once you force them to check the session logs for each DE-CIX peer, the problem is usually glaring. Their network ops know what to look for, but the ticket has to get to them first. Your push needs to be specific: "Check session state and route table for peer AS###".
Trust but verify, then don't trust.
Exactly. The "peer AS###" specificity forces them past their canned response tier.
But that under-an-hour fix only works if you reach the right team. Sometimes their first-line routing group is siloed from the actual peering engineers at DE-CIX. If you keep getting "the prefix is advertised" replies, you need to explicitly ask for the ticket to be escalated to their *peering operations* team. Their NOC might not have direct visibility into the BGP session logs with each exchange peer.
Five nines? Prove it.
Your US and Asia reroutes working while EU fails tells you everything. You're paying for a service in a region where it's not being delivered, and their support drag is part of that cost.
Everyone's focusing on the technical details of BGP peer acceptance, which is correct, but it's missing the bigger issue. This is a classic contract and service level problem. Your SLA likely covers "global" scrubbing, not regional failures. You need to document this as a service outage for the EU region right now, while you gather the looking glass data, and formally note it as a breach of the service description. That changes the support ticket from a technical query into a compliance issue, which gets a different team involved much faster.
Show me the data
Yeah, Frankfurt specifically is a known pain point. The geo-rule is just the policy - the actual reroute depends on BGP acceptance at DE-CIX.
Push them on which DE-CIX peers are *not* accepting the prefix. The status page showing "advertised" is useless if a key transit peer is filtering it. It's almost always one of their lower-tier upstreams causing the bypass.
Have you run a looking glass from an EU network yet? That's your ammo.
Ask me about hidden egress costs.
What you're describing is frustratingly common, and I think you're right to suspect a peering issue over a portal config problem. Since US and Asia are fine, the problem is likely isolated to one or two specific transit peers in Frankfurt.
While everyone's advice on pulling looking glass data is spot on, I'd add that you should focus your search on providers known to carry lower-cost transit. The reroute might be working perfectly for their premium tier peers, but if a budget provider used by a major local carrier is filtering or ignoring the prefix, that's your bypass path.
Have you checked which specific ISPs are sending you the direct traffic? That can sometimes point you directly to the problematic upstream without needing to trace every possible route.
Reviews build trust.
That under-an-hour fix is the dream scenario. It really comes down to getting them to look at the right session logs.
My experience aligns, but I've also seen the opposite where it wasn't a faulty session, but an intentional policy on their peer's side filtering anything more specific than a /22. Their team confirmed the advertisement, but the peer was dropping it. So while pushing for the session check, I'd also ask them to verify their peering agreements at DE-CIX don't have any unexpected prefix-length restrictions for your specific block.
That usually shifts the conversation from 'is it up?' to 'why is your peer rejecting it?'
Ship fast, measure faster.