On Mon, 8 Feb 2021, Justin Wilson (Lists) wrote:
Folks,
Have a gremlin we have been chasing around for several months now and
it’s becoming a major issue as we are getting tighter on IPV4 and
needing to give some provider assigned space back.
In June we received a /22 from ARIN. As is my workflow I started
announcing it but waited a month while I checked out the geolocation
databases for correct info, did testing ,etc. All this time our test
accounts could browse web-sites, etc.
We put one of the pools into production and things ran good for awhile.
Then we started getting the occasional web-site was not working. After
several of these we started assigning the customer an IP out of one of
our other ARIN blocks and the web-site would be fine and reachable. The
issue seems to reside just on this /22. We have other blocks from ARIN
and they are just fine. We can assign an IP out of this new block and
can’t reach certain web-sites. We turn around and assign out of another
block and web-site works just fine.
Been there, and done that back in 2003.
https://web.archive.org/web/20030722022858/http://69box.atlantic.net/
https://web.archive.org/web/20060214055930/http://not69box.atlantic.net/
Unfortunately, I've moved on from that job and don't have any of the code
that I developed for not69box/69box (and AFAIK, the box itself is long
gone), but you can get an idea from the above page what I did. i.e. The
two names resolved to an IP in 69.28.64/19 or an IP in 209.208/17. One of
the cooler (at least at the time) features was a dual-frame traceroute
that visitors could run and watch the box traceroute to a destination from
a each of it's IP's, thus showing where in the path their traceroute
broke, if it did, from the "69 space".
----------------------------------------------------------------------
Jon Lewis, MCP :) | I route
StackPath, Sr. Neteng | therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________