[HN Gopher] BGP zombies and excessive path hunting
       ___________________________________________________________________
        
       BGP zombies and excessive path hunting
        
       Author : emot
       Score  : 43 points
       Date   : 2025-10-31 18:20 UTC (10 days ago)
        
 (HTM) web link (blog.cloudflare.com)
 (TXT) w3m dump (blog.cloudflare.com)
        
       | pm2222 wrote:
       | 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 wrote:
         | Interesting that this comment was added 9 days ago all of a
         | sudden it pops up now with a 3hour stamp.
        
           | amenghra wrote:
           | A zombie comment? How appropriate...
        
           | metadat wrote:
           | 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 wrote:
         | 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 wrote:
           | /32 is not gonna matter when /48 is present. When /48 is not
           | present, why wouldn't /32 be advertised?
        
             | toast0 wrote:
             | 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)
        
       | great_wubwub wrote:
       | > 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 ---
        
       ___________________________________________________________________
       (page generated 2025-11-10 23:02 UTC)