[HN Gopher] BGP.Tools: Browse the Internet Ecosystem
       ___________________________________________________________________
        
       BGP.Tools: Browse the Internet Ecosystem
        
       Author : RGBCube
       Score  : 281 points
       Date   : 2025-07-24 01:12 UTC (21 hours ago)
        
 (HTM) web link (bgp.tools)
 (TXT) w3m dump (bgp.tools)
        
       | dapperdrake wrote:
       | This tool looks really good. It seems like soon ASN level bot-
       | curbing will become common.
        
         | RGBCube wrote:
         | It is really good for blocking whole Chinese & LLM scraper
         | ASNs!
        
           | LohnChen wrote:
           | why u have to mention Chinese?
        
             | RGBCube wrote:
             | Anyone who has operated a public webserver knows that the
             | vast majority of the rabid, robots.txt ignoring
             | hyperscrapers are from Chinese autonomous systems
        
         | ranger_danger wrote:
         | cidr-report.org has been around for over 20 years, curious why
         | you think this site now will make a difference with blocking
         | bots?
        
           | supriyo-biswas wrote:
           | Most people don't know about it; in fact most of the IP
           | geolocation providers pull their data from cidr-report.org or
           | thyme.apnic.net.
        
             | zinekeller wrote:
             | I'm not shocked. ASN blocking is well-known among people
             | who I can easily called experts (veterans which can set up
             | a reasonable-ish firewall from base principles) and ASN
             | control is exposed in major cloud firewalls, but younger
             | people (except those who were trained with deep networking
             | skills) don't really understand ASNs for some reason.
        
       | TheBoozyGenius wrote:
       | Pretty zany.
        
       | ddtaylor wrote:
       | A while ago there was a large data center outage that effected a
       | lot of popular services and I speculated it might have been BGP,
       | but it wasn't.
       | 
       | During that time I was trying to learn BGP on-the-fly enough to
       | know if this was a thing and I didn't have a lot of luck.
       | 
       | What are some good methods or tools to know if BGP is causing a
       | large scale outage before other experts have reported it?
        
         | dgl wrote:
         | https://radar.cloudflare.com/routing might be of interest for
         | aggregated data that doesn't require a complete understanding
         | of the internet. The global looking glass that bgp.tools has is
         | pretty powerful too, but it gives you a lot of data, so if you
         | don't know what you're looking for or what it should look like
         | it's hard to say something is wrong.
        
         | Hikikomori wrote:
         | Its usually not BGP, its some operator misconfiguring BGP, and
         | there's loads of ways of doing that and its hard to know what
         | that would look like from a remote view like your own network.
         | Most efficient way is to just compare current bad state to
         | previous good state and look at the diff, ie what changed for
         | some prefix in your table compared to previous version of your
         | table.
        
       | rumblefrog wrote:
       | I find the map the most interesting map: https://map.bgp.tools/
       | 
       | And did not know Mercedes holds such a large block (53.0.0.0/8),
       | and it appears to be mostly dark or unused.
        
         | mike_d wrote:
         | The map also does a good job showing why we need to do away
         | with multicast/class E and reuse the address space.
        
           | kortilla wrote:
           | You can't use multicast because multicast addresses work
           | today on private networks
        
           | doughecka wrote:
           | Lol, then what do we do with all the multicast traffic?
        
           | ranger_danger wrote:
           | Surely something from
           | https://en.wikipedia.org/wiki/Reserved_IP_addresses could be
           | repurposed?
        
             | teaearlgraycold wrote:
             | Holy cow. Didn't realize there is an entire /4 reserved for
             | future use.
        
             | yardstick wrote:
             | 240/4 can be hijacked/used as private IP space currently by
             | a lot of devices. I think Windows might be the hold out.
             | But for internal routing and IoT it's very useful. Can
             | never be used as publicly routable space.
             | 
             | I'd like to see it added to the official list of private
             | space alongside RFC1918.
        
               | globular-toast wrote:
               | Not sure why you'd need more than 10/8, but I suppose it
               | looks even cooler too those who know and find such things
               | cool.
               | 
               | Does Windoze prevent you from using certain IPv4
               | addresses?
        
               | Hikikomori wrote:
               | Aws sized companies, we also use them in aws. And no
               | doesn't work on windows.
        
               | throw0101b wrote:
               | > _Not sure why you 'd need more than 10/8_
               | 
               | Large organizations have moved to IPv6 because they, and
               | everyone else, are using 10/8, and so when mergers and
               | acquisitions happen trying to connect the networks
               | together becomes a nightmare.
               | 
               | See this talk from Wells Fargo as an example:
               | 
               | * https://www.youtube.com/watch?v=EzTWjNUb4H4
        
               | mrbluecoat wrote:
               | https://www.ietf.org/archive/id/draft-schoen-intarea-
               | unicast... is a nice historical overview of 240/4
        
             | teddyh wrote:
             | Why? It would be to the benefit of relatively few and be an
             | enormous technical problem for decades for everyone. If we
             | did this, the IPv4 addresses would run out again after a
             | few months at most, leaving us all in the same position we
             | are in today, but also with a huge technical problem of
             | fixing all the old devices which had these now-repurposed
             | networks hardcoded.
             | 
             | If you are fine with doing the work of obsoleting old
             | equipment, then just _start using IPv6_.
        
           | Faaak wrote:
           | and what, earn 5 more years till we have the same problem?
        
             | RedShift1 wrote:
             | That's a problem for the people in 5 years
        
           | icedchai wrote:
           | At this point, time would be better spent moving to IPv6,
           | don't you think?
        
             | mike_d wrote:
             | We have been trying to deploy IPv6 for 20 years now. This
             | would be comparatively easier and buy us another 20 years
             | to finish v6 deployment.
        
               | zamadatix wrote:
               | And 50% of the internet traffic is IPv6. The proposal
               | here is to introduce a separate (arguably harder) change
               | which would start at 0% support again. Beyond that, it'd
               | just be a temporary fix.
               | 
               | Just 240/4 allowed specifically for private network use
               | (like the 10/8 range)... that I could get behind though.
               | This would still exclude 255.255.255.255/32 of course.
        
               | icedchai wrote:
               | A ton of old equipment would need to be upgraded to use
               | 240/4 for IPv4 unicast. We'd run into weird issues where
               | it works for some people and not others. I'm not
               | convinced. If this was done 25 years ago, maybe.
        
         | 9dev wrote:
         | Does anyone know what the red striped sections are? Hovering
         | them only yields < _< range> is excluded from scanning_, but
         | that doesn't say much
        
           | gnfargbl wrote:
           | They're part of AS749, which is US Department of Defense IP
           | space that appears to be unused and which, based on public
           | statements made by the Pentagon, might just be safely parked
           | or might be part of a network scanning observatory [1].
           | Either way, scanning that space is probably a waste of
           | bandwidth.
           | 
           | [1] https://blog.benjojo.co.uk/post/ip-address-squatting
        
             | wereHamster wrote:
             | > Either way, scanning that space is probably a waste of
             | bandwidth
             | 
             | That's what the DoD wants you to think ;)
        
             | blahlabs wrote:
             | Maybe a bit off topic, but years ago I had a home linux
             | server, used for usenet/torrenting. I was just poking about
             | on it one day and ran some variation of netstat and could
             | see a connection with a 6.x.x.x range IP address, which
             | stood out. I didn't know a whole lot about networking at
             | the time (still don't), couldn't say if I had
             | misinterpreted what I saw in the netstat output. But it
             | stood out so I looked it up and hoo-boy, it was a shock to
             | see who owned that IP range, Army Information Systems
             | Centre. I chalked it up to them maybe running a torrent
             | tracker or something, or was the DoD in my PC?
        
               | bugsMarathon88 wrote:
               | Service providers (especially mobile ones) often squat on
               | large, unused IP blocks (of which the DoD has plenty of),
               | especially at peak capacity. I suspect this is what
               | occurred here.
        
         | Cthulhu_ wrote:
         | I'd guess they bought a whole block early on because they could
         | and it wasn't too expensive yet. I wonder if they could be
         | compelled to auction it off. But they might be using it a lot
         | internally.
         | 
         | (a lot of guesswork in this comment, I don't know anything lol)
        
           | bananapub wrote:
           | no, no one bought anything, they just emailed some dude and
           | said "hey we're connecting to The Internet, we need some IPs"
           | and the reply was "here is the 2^24 IP addresses dedicated to
           | you".
        
           | everfrustrated wrote:
           | In the early days no money changed hands at all. You just
           | asked for a block and got one.
        
         | jaza wrote:
         | See "List of assigned /8 blocks to commercial organizations"
         | at:
         | https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
         | 
         | Mercedes-Benz isn't the only corporation with its own /8 block
         | - although it is the only non-US one; and it's a pretty small
         | exclusive list, only six in total. I guess someone at Mercedes-
         | Benz just happened to hear about this Internet thing relatively
         | early (53.0.0.0/8 was registered Oct 1993 according to
         | Wikipedia - the relevant European authority, RIPE NCC, was only
         | founded in Apr 1992), and/or happened to have a buddy at IANA /
         | RIPE NCC, and the rest is history.
        
         | justusthane wrote:
         | The XKCD Map of the Internet is good too (2006):
         | https://www.xkcd.com/195/
        
       | tomhow wrote:
       | Previously:
       | 
       |  _BGP.Tools: Browse the Internet Ecosystem_ -
       | https://news.ycombinator.com/item?id=36531988 - June 2023 (17
       | comments)
        
       | thisisgvrt wrote:
       | https://www.youtube.com/watch?v=83NJllv0q9U was a nice behind the
       | cover peek into how the data is collected and parsed.
        
       | j4nek wrote:
       | bgp.tools is one of my most used sites - thanks to ben for doing
       | this so great!
        
       ___________________________________________________________________
       (page generated 2025-07-24 23:01 UTC)