Bgp Zombies and Excessive Path Hunting

Posted2 months agoActiveabout 2 months ago

emot

49 points

9 comments

blog.cloudflare.comTechstory

calmpositive

Debate

20/100

BgpNetworkingInternet Infrastructure

Key topics

Bgp

Networking

Internet Infrastructure

Cloudflare's blog post discusses BGP zombies and excessive path hunting, with the community engaging in a technical discussion around the issues and potential solutions.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

Day 10

Avg / period

Key moments

01Story posted
Oct 31, 2025 at 2:20 PM EDT
2 months ago
Step 01
02First comment
Oct 31, 2025 at 6:51 PM EDT
5h after posting
Step 02
03Peak activity
5 comments in Day 10
Hottest window of the conversation
Step 03
04Latest activity
Nov 10, 2025 at 8:26 PM EST
about 2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (9 comments)

Showing 9 comments

pm2222

2 months ago

2 replies

I thought the bigger /32 prefix should be advertised from AS64511 to both AS13335 and AS64510.

Is there free BGP peering for the purpose of only passing on the NLRIs?

It's interesting that on the "open positions" page, the location filter appears to be strictly string matching, e.g. "US" does not cover "New York, US"

pm2222

about 2 months ago

2 replies

Interesting that this comment was added 9 days ago all of a sudden it pops up now with a 3hour stamp.

amenghra

about 2 months ago

A zombie comment? How appropriate…

metadat

about 2 months ago

This happens when a story is revitalized through the second chance pool.

https://news.ycombinator.com/item?id=26998308

https://news.ycombinator.com/pool

toast0

about 2 months ago

1 reply

I don't think it makes sense for AS64511 (example customer) to advertise the /32 to AS13335 (Cloudflare) when they only want the /48 to be routed through Cloudflare.

pm2222

about 2 months ago

1 reply

/32 is not gonna matter when /48 is present. When /48 is not present, why wouldn’t /32 be advertised?

toast0

about 2 months ago

1 reply

The /32 is going to matter for the addresses outside the /48. The customer only wants one /48 to go through Cloudflare; from the article context, probably because that /48 is under DDoS. DDoS scrubbing services are expensive in dollars and latency (and sometimes network features), so you only want to expose your traffic to that when necessary. When the DDoS is over, you don't want any of your traffic going through Cloudflare, so you withdraw the /48, you wouldn't want to advertise the /32 through Cloudflare at that point either.

Using the article's example ranges:

If the customer's IP 2001:db8::1 is being DDoSed, then they advertise 2001:db8::/48 through cloudflare, but 2001:db8:1::1 doesn't want that; it'll be handled by their 2001:db8::/32 announcement on their usual ISP(s)

pm2222

about 2 months ago

You are right I missed the DDoS part and that cf is not a typical uplink in this use case.

great_wubwub

about 2 months ago

> Things get more interesting when AS64510 signals for 2001:db8::/48 to be withdrawn by Cloudflare (AS13335)

Typo - shouldn't that be AS64511?

...and...

> The MRAI specifies the minimum amount of time ... between each BGP advertisement update.

Each update _per prefix, per peer_. RFC4271 sec.9.2.1.1 says

--- [MRAI] determines the minimum amount of time that must elapse between an advertisement and/or withdrawal of routes to a particular destination by a BGP speaker to a peer ---

View full discussion on Hacker News

ID: 45775051Type: storyLast synced: 11/20/2025, 1:20:52 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN